OSDev.org

Hi,

Rusky wrote:Macros can also be used for embedded domain-specific languages (typically called EDSLs), which can make your program significantly clearer by essentially creating a new scripting-ish language within the main one for a particular library. They can also be used to add new "language" constructs that would be overly verbose, repetitive, or executed at runtime without them. As long as you don't go overboard with them and make something unreadable for an outsider (this is helped in Rust by making it very clear where a macro!() is used, and by the culture of how often to use them defined by the standard library).

Generics and traits do have their place when used judiciously, as do well-designed conditional compilation and closures/lambdas. I notice you're not complaining about owned/borrowed or standard library tasks/vectors or recursive types...

This is like listening to someone with leprosy who thinks it's awesome and is trying to convince other people that they should have leprosy too.

All this high level wizardry (that's meant to make programming easier) just over-complicates everything and makes everything harder. Each year academic morons shovel more layers worthless trash on top, and each year the idea of an average person being able to write good useful code becomes more insane because of it.

It's not a cure, it's a disease.

To put this in context; I started programming when I was 12. I'd never used a computer before; and learnt Commodore 64 BASIC in about 2 weeks (in my spare time) because it seemed like fun. A few months later I was playing my own platform game.

For the "about 30 years" since then I've watched the entire industry bury itself under its own faeces. To do the same simple platform game you're going to need 2 or more languages, half a dozen libraries, a computer with 100 times as much RAM and CPU power; and a few years of university and 6 months or more experience after that.


Cheers,

Brendan

Brendan wrote:To put this in context; I started programming when I was 12. I'd never used a computer before; and learnt Commodore 64 BASIC in about 2 weeks (in my spare time) because it seemed like fun. A few months later I was playing my own platform game.

To do the same simple platform game you're going to need 2 or more languages, half a dozen libraries, a computer with 100 times as much RAM and CPU power; and a few years of university and 6 months or more experience after that.

That is simply not true, and even if it were it's not related. Macros, generics, and closures have nothing to do with people over-complicating their projects with extra languages, libraries, or processing power. I could at least understand if you made the argument that they encourage people to over-complicated their code, but people do that regardless.

When I or beginners I see (in high school intro to programming classes, or just for fun) write simple platformers today, it takes around the same amount of time, using a single language and one or two libraries. The games are easier and faster to write per-feature, cross-platform, and pushing about 100 times more pixels/entities, without even taxing the computer.

Indie game developers today are also capable of far more than they were on the Commodore 64, because languages, libraries, and tools are now available that enable them far more than BASIC. You sound like a classic Blub programmer.

Hi,

Rusky wrote:

Brendan wrote:To put this in context; I started programming when I was 12. I'd never used a computer before; and learnt Commodore 64 BASIC in about 2 weeks (in my spare time) because it seemed like fun. A few months later I was playing my own platform game.

To do the same simple platform game you're going to need 2 or more languages, half a dozen libraries, a computer with 100 times as much RAM and CPU power; and a few years of university and 6 months or more experience after that.

That is simply not true, and even if it were it's not related. Macros, generics, and closures have nothing to do with people over-complicating their projects with extra languages, libraries, or processing power. I could at least understand if you made the argument that they encourage people to over-complicated their code, but people do that regardless.

It's nothing to do with the project itself; and everything to do with over-complicated languages, over-complicated tool-chains, over-complicated build systems, over-complicated file formats, etc. Go and find yourself a 12 year-old kid and see how quickly they learn Rust with the programmer's manual, no experience, no programmers to talk to, no internet, no tutorials and nothing else.

Rusky wrote:Indie game developers today are also capable of far more than they were on the Commodore 64, because languages, libraries, and tools are now available that enable them far more than BASIC. You sound like a classic Blub programmer.

A bowl of ice-cream is nice on a hot day; therefore it must be a good idea to eat 500 bowls of ice-cream on every day that is over 25 degrees Celsius. In related news, programming should be so high level that it takes 20 years just to learn, because then instead of spending 2 minutes writing "hello world" with a simpler language it will only take you 90 seconds (plus another 30 more seconds to figure out why it didn't work the first time).

A Blub programmer is happy with Blub. I'm not happy with any language.


Cheers,

Brendan

There is a lot of unnecessary complexity in toolchains, build systems (especially), and interfaces. None of that will be solved by dropping useful features from programming languages.

Are you really saying that giving programmers macros and generics, etc. causes those problems?

Hi,

Rusky wrote:There is a lot of unnecessary complexity in toolchains, build systems (especially), and interfaces. None of that will be solved by dropping useful features from programming languages.

Are you really saying that giving programmers macros and generics, etc. causes those problems?

No. I'm saying that they're all symptoms of a larger shifting baseline problem; where everything gradually gets more complex over time while everyone thinks "it's only slightly different this year compared to last year" and nobody ever does anything to stop the continually increasing complexity.

The only area in the entire IT industry where this hasn't happened is user interfaces (which haven't really improved much in the last 20 years, but haven't become more complex either).


Cheers,

Brendan

So what's the problem with these language features, other than "waaaaah they're too complicated"? We've gone over their advantages, including making things easier and faster, and that's all you can come up with.

Hi,

Rusky wrote:So what's the problem with these language features, other than "waaaaah they're too complicated"? We've gone over their advantages, including making things easier and faster, and that's all you can come up with.

Which one made anything easier or faster (enough to justify the disadvantages)?


Cheers,

Brendan

What disadvantages? You're the one who put them on a puke list.

It would appear the thread i'm riding on has derailed! Send help!!

Hi,

Rusky wrote:What disadvantages? You're the one who put them on a puke list.

Surely this is obvious? The extra time it takes to learn the language, the extra little mistakes experienced programmers make (typos, etc) that cost them time, the extra hassles it causes for people joining a new project (becoming familiar with an existing code base), the extra complexity of writing the compiler/s (and extra bugs in the compiler), the additional problems they cause for auxiliary tools (debugger, IDE), the problems it can cause for future tools (source code and data visualisation, source code generators), etc.

Then (for language designers) there's also the "seemed like a good idea at the time, but now we know it's bad and it can't be removed because it'd break existing projects" problem that ends up plaguing all languages that start out complex (you can add features, but can't remove them).


Cheers,

Brendan

Butterflies and machine code- no tools to cause problems for.

Hi,

I prefer this one:


Note that when I said "I'm not happy with any programming language" earlier, that includes both assembly and C.


Cheers,

Brendan

Brendan wrote:For the "about 30 years" since then I've watched the entire industry bury itself under its own faeces. To do the same simple platform game you're going to need 2 or more languages, half a dozen libraries, a computer with 100 times as much RAM and CPU power; and a few years of university and 6 months or more experience after that.

There is more that. Beginners are also directed to their own playground that contains only toys not meant for any serious work. Advanced programmers keep the keys for their own workplace and think that beginners should be kept away from there. They think it is better to let beginners to be "safe" and make sure beginners would not make their work look bad (e.g. inventing something better).

Brendan wrote:Note that when I said "I'm not happy with any programming language" earlier, that includes both assembly and C.

May be it's about how to use a language? An axe isn't ideal, but skillful workers can build a house with it. Yes, beginners just can't do that, but them also can't do it with more advanced tools.

There should be an optimum. It's somewhere in between of beginners and aces. And there is a need for learning. And even skilled worker can benefit from learning. But beginner must learn to be able to build a house. And it's not an axe problem, it's problem of any human - the brain must be trained.

So, the language is a necessary evil. And while in search for an ideal axe we still can use an ordinary one. But the effort distribution in the search and usage areas should be optimal. However, it is viable to say - never stop searching and never stop using.

It seems Brendan's way a bit skewed to the search while Rusky's way is a bit skewed to the usage. But together they represent some optimum

Antti wrote:Beginners are also directed to their own playground that contains only toys not meant for any serious work.

It's just collaboration mis-organization. Some projects are in such state, but there also are some others.