Hacker News new | ask | show | jobs
by Joel_Mckay 539 days ago
In general, I tend to observe languages that are minimally challenging for amateurs tend to build less sustainable mutagenic ecosystems.

Example:

* Prolog generated the worlds most functional 1 liner code, as it is bewildering for hope-and-poke programmers

* Pythons ease of use combined with out-of-band library packages became a minefield of compatibility, security, and structural problems (i.e. became the modern BASIC)

* NodeJS was based on a poorly designed clown JavaScript toy language, so naturally became a circus

* Modern C++ template libraries became unusable as complexity and feature creep spiraled out of control to meet everyone's pet use-case

* Rust had a massive inrush of users that don't understand why llvm compilers are dangerous in some use-cases. But considering 99% of devs are in application space, they will unlikely ever need to understand why C has a different use-case.

While "Goto" could just be considered a euphemism for tail-recursion in some languages. We have to remember the feature is there for a reason, but most amateurs are not careful enough to use it in the proper edge-case.

I really hope Julia becomes more popular, as it is the first fun language I've seen in years that kind of balances ease of use with efficient parallelism.

wrote a lot of RISC Assembly at one time... where stacks were finite, and thus one knew evil well... lol =3

1 comments

Why are LLVM compilers "dangerous in some use-cases", and what are those use-cases?
Any Real-Time or mcu system that relies on repeatable code-motion behavior, and clock domain crossing mitigation (a named problem with finite solutions.) Many seem to wrongly conflate this with guaranteed-latency schedulers... However, the danger occurs when a compiler fails to account for concurrent event order dependent machine states that do not explicitly lock (i.e. less efficient un-optimized gcc will reproduce consistent register op ordered in time behavior for the same source-code.)

The llvm abstraction behavior is usually fine in multitasking application spaces, but can cause obscure intermittent failure modes if concurrent register states are externally dependent on the architecture explicitly avoiding contention. I would recommend having a look at zynq DMA kernel module memory mapped to hardware io examples.

It seems rather trivial, Best of luck =3

But if you depend on specific ordering of register operations, isn't this kind of code best hand-written in assembly anyway?
In general, assembly code escape blocks are often used with macros for ease of understanding architecture specific builds.

There are binary optimizers and linkers that can still thrash Assembly objects in unpredictable ways.

Best of luck =3