The point is that if you write complex algorithms its a lot easier to keep the overview if you use a high level language.
Yes, higher level languages are easier for most things.
Look, have you ever done a complex project?
Not yet, but define complex, or better yet, give some concrete examples of what creates the kind of complexity that is so hard to manage in assembly language (for software that would run well on 68020/30).
You seem to say "everything is in assembler, so you can do everything in assembler in first place".
For anything that's worth implementing on 68020/30 certainly.
That's simply not correct.
It is. It simply depends on ones ability. Maybe I can't do it, maybe you can't do it, but that doesn't make it impossible.
If you do the same in assembly, you would need to re-adjust the objects, re-check the interfaces. register assignments, scratch-registers...
And how exactly is that a problem? What I see as the main problem is when you're changing things all the time. Tells me that you didn't think it through thoroughly enough, and we've all been there.
In other words, your daily work is so much tight up in low-level details that you are losing any type of control on the *real* work, and you're lost in problems usually not worth mentioning.
You can also try to get it mostly right from the start, so that you can focus on writing actual functional code. Anyone who's lost in the details all the time is simply doing it wrong.
Software engineering means using the right tools to get the job done as best as possible.
That's only one part of it, and it's not the most important one. True software engineering means that you don't write a single line of code until you have a proper design. Something that works, and won't break when you want to add or change things. It's this part that's the hard part, and it can make the actual implementation process almost seem trivial in comparison. That's why when you're changing a lot of things you're not doing it right. You shouldn't have to, except when designing the software.
Well, anyhow, just for the means of it, my offer was already that you probably start writing a JPEG 2000 from scratch from the specs in assembler.
Yes, but why JPEG 2000? I'd rather do something that's more interesting. Same for the MPEG decoder you suggested in the other thread. JPEG 2000 isn't widely used, and MPEG on 68020/30s isn't very useful. I suggested a new GUI system, but that's not complex enough. So the big question is what would be really worthwhile to do on 68020/30 that's also reasonably complex? An HTML/CSS engine maybe?
In the end, if you're lucky, you probably get something that works, but most likely because you have forced program structures together that are sub-optimal, without understanding that your selection of algorithms was more due to low-level ease of implementation than high-level analysis of the problem.
I don't pick algorithms just because they're easier to implement in assembly language. I look for algorithms that get the job done properly and efficiently, and if implementing them sucks, then it sucks and I do it anyway (or I don't because I'm lazy).
Professional software is something different than rewriting the "List" command in assembler.
I don't doubt it, but we're also not talking about ten million line programs here, we're talking about software that will run well on 68020/30s. Such constraints automatically limit the complexity of a project, because programs that are so huge and heavy won't run well on 68k anyway.
