Is programming now much different than during the Amiga Era

[telbee]

Originally Posted by methodman

It seems that even programming during the Amiga years was challenging. Today the programming doesn't seem to be that different.Have I not looked at good programming books. Are agolrithms being used now in programming that different. Are the new languages drastically different than the Amiga Languages for example E vs Python or Visual Studio vs CanDo or Amos. or Mathematica Isn't it mostly that just more libraries exist. or are there fundamnetally different concepts attached?

With the exception of photoshop type software and Reakto r2. 0 construction could that have ever been implemented on an Amiga. It doesn't seem programming has evolved that much.:

Since then, the interweb has proliferated slightly, giving programmers the ability to instantly share the knowledge of thousands of other programmers. Oh, and about 18 more layers of high-level interdependent crap between the programmer and the processor!!

btst.b #6, $bfe001 - Now available as a 40Mb .NET app on Windows!!



T

[NewDeli]

Originally Posted by gilgamesh

I think you should check out these engines. They are completely free, open sourced and fairly professional

Certainly. Heard of Allegro btw ?

Allegro is a game programming library for C/C++ developers distributed freely, supporting many platforms. It provides many functions for graphics, sounds, player input (keyboard, mouse and joystick) and timers. It also provides fixed and floating point mathematical functions, 3d functions, file management functions, compressed datafile and a GUI.

There are a few prototypes of games made with Allegro (and C++ usually) on YouTube. Didn't have to time to peruse the Projects pages yet.

[gilgamesh]

Allegro has been around for a long time. The first version was for the Atari ST. But I think it is very low level, comparable rather to SDL than any of the above.

[Jgames]

I think that programming now is much better, and one must absolutly avoid assembler, it's a waste of time and creativity;
The importance is not the language, it's the end result, and from a programming point of view, it's the design/data structures and algorithms going into a program.
All great researchers works with high level languages, and then publish papers that change the computer world; (ex: BSP trees and CSG (Constructive solid geometry))

If someone is seduced/impressed by assembler, a way better way to do something meaningfull is to design one's self cpu and computer, this way, one can learn about logic gates, flip flops, transistors, registers, multiplexers,etc...that is digital electronics. And as bonus, you get to design your own assembler, and understand it all inside out.

This is what i try to do nowdays, it's not an easy thing to grasp. (at least for me)
Here is someone who built his own computer out of TTL chips.
http://www.homebrewcpu.com/
This is the shit!

There are others who went on something like this.

[Thorham]

Originally Posted by Jgames

I think that programming now is much better

Absolutely! And that's why we have all that lovely bloatware today.

Originally Posted by Jgames

and one must absolutly avoid assembler, it's a waste of time and creativity;

That's a subjective viewpoint. I like programming in 68K assembler, and it causes me to think more creatively then when I use a higher level programming language. Of course it helps that I don't program professionally

Originally Posted by Jgames

The importance is not the language

It is if you want high performance. Let's try Visual Basic Express. Last time I tried that was on a 550 Mhz Pentium 3, and the performance was less than a 68030 No kidding. Languages are important.

Originally Posted by Jgames

If someone is seduced/impressed by assembler, a way better way to do something meaningfull is to design one's self cpu and compute

I have always enjoyed programming in assembler, and I would absolutely hate to design my own computer. First I would have to learn how, and then the best I can do is design a useless machine, which I won't even enjoy using. Again this is subjective.

People should program in a language that they enjoy programming in

[gilgamesh]

Originally Posted by Thorham

That's a subjective viewpoint.

Disagree. If somebody had to recode, say, Amazon's web store in assembler from scratch that would have a measurable impact.

Originally Posted by Thorham

Languages are important.

Yes, but not neccessarily speedwise. Maybe that the implementation of the VB program was bad, maybe M$ sucks at implementig the interpreter. Both could be amended. But different languages give you a different mind set. Try programming Towers of Hanoi in C (or assembler if you like) and then in Prolog. You'll be stunned.

Originally Posted by Thorham

People should program in a language that they enjoy programming in

Totally agree, but they should try as many as possible.

[TCD]

I'd say there a language for every platform + purpose. Seeing another thread where someone asks about porting an emulator that still has x86 ASM 'in it', it's possible 'in theory' to port it to the native ASM of the platform, but it not feasible. Someone mentioned that you lose the speed gain if you port those bits to C and he's most probably right. I've seen some attempts to code Windows apps in ASM and it just looks funny to see all those API calls, which really look odd. There's certainly a 'weapon of choice' like gligamesh said.

[Thorham]

Originally Posted by gilgamesh

Disagree. If somebody had to recode, say, Amazon's web store in assembler from scratch that would have a measurable impact.

It is subjective depending on the platform. When dealing with 68K, you need assembler or a good C compiler. And what's so creative about a web shop?

Originally Posted by gilgamesh

Yes, but not neccessarily speedwise. Maybe that the implementation of the VB program was bad, maybe M$ sucks at implementig the interpreter.

Sure, but what other implementation of VB Express is there?

Note: VB Express is compiled, which considering the slowness (might have been solved now, but I doubt it) is ridiculous. Also, interpreters are always slow compared to compiled code (and are only useful for writing small scripts, which should also be compilable in my opinion)

Originally Posted by gilgamesh

But different languages give you a different mind set.

Which I don't like much. I like low and mid level programming.

Originally Posted by gilgamesh

Try programming Towers of Hanoi in C (or assembler if you like) and then in Prolog. You'll be stunned.

I think I'll pass on Prolog

Originally Posted by gilgamesh

Totally agree, but they should try as many as possible.

Most certainly not! What's the purpose in wasting (subjective!) my time with things like Python, Ruby and more of that stuff? I have absolutely no interest in languages like those.

Anyway, many things I see today can easily be done in 68K or C, but they're not written in proper languages (although C needs a replacement badly) and thus those things are often laughably slow. Do it right in 68K and a '030 can do most of those things.

With todays ridiculously fast machines many programmers don't seem to care about speed anymore. Computers become faster and software becomes slower

Imagine how that would work in all other industries. Everything would come crashing down. Why so many programmers accept this is beyond reason (mine anyway) and there's clearly a need for a programming revolution. Will it happen? Probably not

[TCD]

Originally Posted by Thorham

Note: VB Express is compiled, which considering the slowness (might have been solved now, but I doubt it) is ridiculous.

Well, I guess you're talking about VB.Net Express, which isn't really 'compiled', but rather 'bytecode' which still runs through the framework 'interpreter'. It's not that bad, but surely nowhere near native C or even x86 ASM

[gilgamesh]

Originally Posted by Thorham

And what's so creative about a web shop?

Building a thing that can do billions of monetary transactions in a fast, efficient and reliable way is not trivial. It's like you're telling a fine carpenter that his work is not art, because he is not using brushes and in the end there is no picture.

Originally Posted by Thorham

Sure, but what other implementation of VB Express is there?

There are lots of Basic dialects, and I'd say OOBasic comes expecially close. (I don't like Basic either, though.)

Originally Posted by Thorham

Also, interpreters are always slow compared to compiled code (and are only useful for writing small scripts, which should also be compilable in my opinion)

In fact, interpreted GNU Common Lisp is faster in the benchmarks that I have seen than when it is compiled (and it is not slow at all). An interpreter can adapt to situations that a compiler just can't foresee. That's the cool thing about LLVM. It seems like the clear distinction between compilation and interpretation is getting lost.

Originally Posted by Thorham

What's the purpose in wasting (subjective!) my time with things like Python, Ruby and more of that stuff? I have absolutely no interest in languages like those.

Remember what I've wrote about mind set? It will be changed. You discover new ways of approaching problems. Some people say that programmers who learn Lisp usually write better C, too.

I mean, if you like assembler that is fine, but there are things beyond that you will never see.

Originally Posted by Thorham

With todays ridiculously fast machines many programmers don't seem to care about speed anymore. Computers become faster and software becomes slower

Oh come on, that is simply not true in general. You couldn't realistically compress a video sream to MPEG on the fly before y2k (without dedicated hardware). Try Linux without fancy stuff and with a custom made kernel. That will be fast.

[eLowar]

This is what we call a deterministic discussion, we all know exactly what arguments will be used and we all know exactly where it's going, i.e. nowhere.

[NewDeli]

Deterministic or not, recurring or not, I for one find it interesting.

Just a remark, is "the Amiga" implied in this thread's question ?
"Is programming the Amiga now much different than during the Amiga Era ?"
or is it a wholly different topic ?

I've heard the differences have to do with the way the code taps directly (sometimes even unsafely) into the hardware, things like that.

[Thorham]

Originally Posted by TheCyberDruid

Well, I guess you're talking about VB.Net Express, which isn't really 'compiled', but rather 'bytecode' which still runs through the framework 'interpreter'

Actually the byte code is compiled to native code at runtime by a JIT compiler

Originally Posted by gilgamesh

Building a thing that can do billions of monetary transactions in a fast, efficient and reliable way is not trivial.

Okay, I suppose that's true.

Originally Posted by gilgamesh

There are lots of Basic dialects, and I'd say OOBasic comes expecially close. (I don't like Basic either, though.)

I like FreeBasic

Originally Posted by gilgamesh

In fact, interpreted GNU Common Lisp is faster in the benchmarks that I have seen than when it is compiled (and it is not slow at all).

That seems ass backwards at first glance. What I want to know is if that's really necessary?

Originally Posted by gilgamesh

An interpreter can adapt to situations that a compiler just can't foresee.

Could you give an example?

Originally Posted by gilgamesh

Remember what I've wrote about mind set? It will be changed. You discover new ways of approaching problems. Some people say that programmers who learn Lisp usually write better C, too.

Sounds interesting. Too bad I don't feel like learning languages such as Lisp

Originally Posted by gilgamesh

I mean, if you like assembler that is fine, but there are things beyond that you will never see.

Could you give an example?

Originally Posted by gilgamesh

Oh come on, that is simply not true in general. You couldn't realistically compress a video sream to MPEG on the fly before y2k (without dedicated hardware). Try Linux without fancy stuff and with a custom made kernel. That will be fast.

I mean programs that are heavy while they don't have to be. Perhaps I just have a pessimistic viewpoint

[TCD]

Originally Posted by Thorham

Actually the byte code is compiled to native code at runtime by a JIT compiler

That's what they want you to believe No really, I meant the JIT compilation, which of course adds to the runtime for short programs. Anyway, I should really do other stuff and let you Amiga coders do your thing here

[gilgamesh]

I guess may answer is all predetermined, but the free will is an illusion anyway.

Originally Posted by Thorham

Could you give an example?

Concerning interpreters:
You can have adaptive optimizations, like any modern JIT does. (JITs are byte code interpreters to me.) A very simple example: Imagine a standard C switch construct. They are equivalent to something like

if(A){} else if(B){} else if(C){} ... else{}

An interpreter could choose to reorder A,B,C, ... according to their probability, which might even change in the course of execution.

And for mindf...:
The first example that comes to my mind is recursion. Many people who program C (and I bet that holds true for assembler programmers as well) know what recursion is, but they don't like it. People who are used to Lisp, Prolog etc. where it is "natural", use recursion to solve many problems in a more elegant way. Just a simple example, very probably not really good.

But I think this is really getting off topic. (Prolog and Lisp were already supported on Amiga, but I think no one seriously made anything with them.)

[absence]

Originally Posted by Thorham

It is if you want high performance. Let's try Visual Basic Express. Last time I tried that was on a 550 Mhz Pentium 3, and the performance was less than a 68030 No kidding. Languages are important.

Do you have any details on this comparison? It sounds very unlikely unless you included cold start of .NET and the JIT compilation in the benchmark, or compared apples to oranges.

Originally Posted by Thorham

Anyway, many things I see today can easily be done in 68K or C, but they're not written in proper languages (although C needs a replacement badly) and thus those things are often laughably slow. Do it right in 68K and a '030 can do most of those things.

What things precisely? Firerfox? Photoshop? x264? Cubase? Mathematica? The already mentioned web shop? Its database system? It would be interesting to see any of those implemented in 68k assembly and benchmarked on a 68030 against their original "bloatware" counterparts on a pc.

Originally Posted by Thorham

With todays ridiculously fast machines many programmers don't seem to care about speed anymore. Computers become faster and software becomes slower

They probably don't care about cutting all the corners that were necessary in the old days because computers were so limited. I think they do care about speed, as long as it's profitable. It's far more important for a commercial developer to obtain a result that does the customer's job "fast enough" than to hand-optimise assembly code that provides infinitesimal speed benefits in exchange for insane increases in development cost. Hardware is cheap, programmer time is not, so it makes economical sense to trade off some speed to make programmers' lives easier. Feel free to start a software company and prove the world wrong if you disagree.

Furthermore, I think you exaggerate the performance situation. It's true that the casually observed speed of some of today's software hasn't increased proportionally with that of hardware, but on the other hand today's software has a billion more features, higher extensibility and portability (due to "bloated" abstractions), better integration with the OS and/or other applications, higher accuracy, and probably more that doesn't immediately come to my mind. There's also a tendency to run a whole bunch of heavy software at the same time (except for very basic home users who panic if their document "goes missing" behind another application).

You may feel that this evolution sucks if you don't need any of the modern fancy schmancy stuff that eats CPU cycles, and you're of course entitled to that opinion. Just saying that one man's bloat is another's killer feature. That said, I'm sure most home users could do with a simpler word processor than Word, even if a lot of businesses can't.

[Samurai_Crow]

The problems with .NET are that the static compiler doesn't do enough optimization and leaves too much to the JIT. Effective compilers are slow. Especially when it comes to doing tricks like stuffing two 16-bit words in a 32-bit register like the experimental PBQP register allocator does on LLVM.

For that reason I think whole-program LLVM Bitcodes should be statically compiled at install time after some generic optimization at the programmer's machine. The link-time optimizations it does are vital to dynamic binding to make the bitcodes run on any system that LLVM supports. The JIT shouldn't be used unless absolutely necessary because using lazy compilation interferes with the execution of the program (eg. running a function that isn't compiled yet triggers a compile with a whole slug of optimizations to slow down the system until the function is compiled, never mind that it eliminates the possibility of cross-function optimization).

[absence]

This is actually similar to how .NET works if you choose to do ahead-of-time compilation during installation. While the optimiser probably has room for the improvements you suggest and others, it does whole program optimisation rather than per method, and the JIT is only invoked if necessary.

[NovaCoder]

IDE's, context sensitive help....Google. Yep it's a bit easier now!

[Maccara]

I'm with NovaCoder! Much easier to find the info you need when you need it.

It's nice you don't have to go asm everytime you want even a bit of performance nowadays - just throw more hardware at it. Saves my time as a coder, which means more money.

That isn't saying asm isn't still very useful. Often needed to squeeze out the last bit of performance in en/decoders, for example. Compilers are still stupid (and will be for long, AI needed) and can't do autovectorization etc well. VC often screws even intrinsics (problematic register allocator), so even those aren't too useful. GCC needs a lot of coaching too to do the right thing.

Wouldn't bother to write a whole program in asm in any situation today, though. And shouldn't be used for optimization either until other options are exhausted first (algorithmic improvements etc). Should stay HLL as long as possible during development cycle.