Is programming now much different than during the Amiga Era

[Thorham]

Originally Posted by absence

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.

Yes, it's about a simple text searching algorithm (the simplest possible, more or less). When I wrote this by hand completely it was painfully slow, and was only improved by using more built in .net functionality. The same algorithm in assembler on a 50mhz '030 is faster than on a 550mhz Pentium 3 (6 mb text file, takes a '030 seconds to search through). Write this in FreeBasic, and the result can be lightning fast (which is why I switched to FreeBasic).

Note that this routine was a place holder routine for a proper search function.

While there should be enough functionality in the .net framework to get nice results, I like writing things by hand (it's a hobby ), and with Visual Basic Express, there seems to be little point in doing so. Also, .net is big, and I hated how I had to search for many things to get things done properly.

Originally Posted by absence

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.

Not necessarily about those. I only know FireFox and Photoshop anyway. It's about programs that are light in nature but which are often not implemented as such.

Anyway, this is basically a feeling I've had for a long time now. I feel most things aren't written half as fast as they could be. I can't lay my finger on it, but I'm sure that there is at the very least some truth to it.

Originally Posted by absence

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.

Yep, they sure do care about profit! The problem is that the highest quality software isn't necessarily the best selling product. Windows 3.11 ring a bell? I don't think it's about making the best software they can make, but about making software that people find useful and that they can sell, and I highly dislike this, speaking from a hobbyist point of view, of course.

Originally Posted by absence

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.

And all this has to lead to bloated software? Well, I don't like it

Originally Posted by absence

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).

Possible, but I don't really do that, and if I did, I would take it in account

Originally Posted by absence

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.

Yes, I strongly feel this development sucks, and I think (feel?) it can be done better. That said, what fancy things that are functional (not eye candy) are necessarily heavy, in the case of, say, Word?

[Maccara]

Originally Posted by Thorham

I don't think it's about making the best software they can make, but about making software that people find useful and that they can sell, and I highly dislike this, speaking from a hobbyist point of view, of course.

And I think this is the crux of why there is a disagreement between different approaches.

You find reward in doing "the job" itself, whereas most already have a defined problem which needs to be solved and "how" is not the real question as long as it "works" (fast enough) and delivers the results wanted.

For me personally, I sometimes have fun finding 'the "best" way to do something', but most often I just have a set of results I need to achieve and I have to balance on when "enough is enough".

Of course, I usually work with other coders too, and that means I can't usually write the most convoluted & efficient piece of code imaginable, instead I have to keep it maintainable and extendable.

[absence]

It's definitely an issue of hobbyist versus commercial development.

Originally Posted by Thorham

While there should be enough functionality in the .net framework to get nice results, I like writing things by hand (it's a hobby ), and with Visual Basic Express, there seems to be little point in doing so. Also, .net is big, and I hated how I had to search for many things to get things done properly.

A commercial developer can't waste time reinventing wheels simply because he or she enjoys it. Frameworks like .NET, Java, Qt, and so on are full of solutions to common problems precisely for this reason, which is why they are big. If you constantly had to search for everything in VB.NET, perhaps you didn't spend enough time learning it (which could explain why your search algorithm ran slowly as well). It's tempting to believe that VB.NET is an easy language to pick up because of its name, but it's virtually the same as C# (and thus Java), and requires the same amount of learning and skill.

Originally Posted by Thorham

The problem is that the highest quality software isn't necessarily the best selling product. Windows 3.11 ring a bell? I don't think it's about making the best software they can make, but about making software that people find useful and that they can sell, and I highly dislike this, speaking from a hobbyist point of view, of course.

Windows 3.1 does ring a bell. While I'm sure you're thinking of its less than impressive multitasking and stability, its font support, hardware abstraction, and selection of available business software are examples of areas where it was ahead of AmigaOS 3.0. "Quality" and "best software" really depend on what you need. These examples are both developed from a commercial point of view though, so it makes little sense to criticise them from a hobbyist one.

Originally Posted by Thorham

Yes, I strongly feel this development sucks, and I think (feel?) it can be done better. That said, what fancy things that are functional (not eye candy) are necessarily heavy, in the case of, say, Word?

Software (or hardware, or anything at all, really) is of course never perfect and can always be done better. The question is whether it's worth it. If you pay a programmer to make something better, will the improvement increase the revenue enough to cover said programmer's paycheck?

As for Word I honestly couldn't tell, as I very rarely need or use word processors. If I was to hazard a guess I'd say that inserting objects from an Excel spreadsheet that depends on lots of macro code and database access is a bit heavy, but there are probably better examples. Some companies do really crazy stuff with Office ...

[Maccara]

Originally Posted by absence

Software (or hardware, or anything at all, really) is of course never perfect and can always be done better. The question is whether it's worth it. If you pay a programmer to make something better, will the improvement increase the revenue enough to cover said programmer's paycheck?

Well, you could actually write provable code. Fat chance of that happening, as most coders I've seen don't even have a f'ing clue what that actually means. (confuse it with unit testing etc)

I wish it was done at least for some core technologies, but it's simply too expensive. (can't bother to look up details now, but one microcode kernel was proved by some aussies a while back: took ab 4 years to prove 7500 lines of code and the proof was ab 200000 lines)

(of course, even proved code isn't perfect - it could still be faster/smaller/prettier/tastier/sexier )

[gilgamesh]

You mean the seL4 microkernel. Another verified microkernel is Coyotos, which was written in BitC. BitC takes a modern, functional approach on low level programming. Funny how this keeps circling back. In fact, the *ML languages were used originally for automated verification.

But I don't know if the end user profits from a verified system. IBM reached 99.999% uptime in its mainframes without it. Modern Linux and BSDs are stable enough imo.

That reminds me. Techniques such as extreme programming, design by contract (a rudimentary form of verification) and such are new.

[Maccara]

Yup, seL4 was what I was referring to. Thanks for the reminder.

Originally Posted by gilgamesh

But I don't know if the end user profits from a verified system. IBM reached 99.999% uptime in its mainframes without it. Modern Linux and BSDs are stable enough imo.

This is true. Which probably is one of the reasons why it's almost never done. Diminishing returns and all that.

[absence]

Mathematically proving that code follows some spec doesn't help you if the spec is wrong in the first place. Mathematical correctness also doesn't necessarily do anything for performance.

[gilgamesh]

Plus you have to differentiate between partial and total correctness. Partial correctness means that your code does what it is supposed to do and total correctness means that it does so in a finite number of steps. The latter can be impossible to prove for a given program.

Frustrating, isn't it?