verdax_1

Maybe the code base contains a bunch of edge cases where they assume 140 and trying to do anything else causes crashes or other poorly defined misbehavior. (Not what you were talking about but also a legitimate but unfortunate answer)

My guess is that if they make a general purpose programming AI then all other jobs will also be nonexistent besides being famous and doing YouTube reviews of movies. My thought is that the problems in the way of AI programming are more difficult and can be generalised to enough other jobs that programming is going to be the last job automated.

I think something like this actually happened with one of the first scheme implementations, but that was because they wrote the GC in scheme so they had to do it that way for a very small subset of the system (is the GC code). But yeah other than that I can't think of any examples (and my example is kind of the exception that proves the rule).

I don't see it as one. It just happens to be the one I encountered that had the feature. Please suggest better, I wasn't that fond of R.

Haskell for lazy FP, pattern matching, and monads; ocaml for strict FP and a crazy expressive module system; C# for industry OO; lua for dynamic language and prototype inheritance; ruby for runtime meta programming; lisp for macros; forth for stack language; erlang for actor module, byte pattern matching, and dynamic unification pattern matching; prolog for logic programming; c for low level; c++ for templates and destructors; rust for linear types; idris for dependent types; R for rank polymorphism. After that languages started to seem like variations of things I've seen before.

It seems that a few years ago several big name tech companies found themselves at the limit of what they could do with the c#/java style languages. But they weren't willing to go back to c/c++. Facebook started experimenting with D, apple created swift, google created go, Mozilla created rust, Microsoft had a rumored system language that never seemed to materialise, and even c++ is trying to get away from itself.

It is sort of looking like the industry as a whole is starting to see if there isn't a better way to do things and I think we will see how things shake out in the next five years or so.

I actually found myself factoring my code differently after learning lambda calc. It at the very least seemed to result in better code (c#) so I would say there is practical benefits.

I might go a step further and append "an appropriately implemented macro". Just because something has a good name doesn't mean it's not filled with crazy.

Otherwise I totally agree with your point.

This is really emphasized in things like dmfea and other failure mode analysis documents or regulated industry. They want you to document the likelihood, your ability to recover from the failure, as well as the cost o the failure. You can say that you didn't want to pay for someone fixing some unlikely fail mode but that's small consultation to the people whose lives your product is ruining.

I like the way you're thinking, but that sort of thing probably doesn't get past a committee. "Hey we might not be able to think of an application but that doesn't mean our users won't have a legitimate reason for doing it ... Motion passed."

Also worth considering that our processors are handling billions of ops per second. One in a million might be happening all the time even for one user.