[0] https://www.mercurylang.org/information/doc-latest/mercury_r...
There are quite a few very interesting and solid languages out there. One example for something that's not nearly well enough utilised or used widely is OCaml -- although in its case the lack of true multicore CPU support definitely cripples interest. But the language has an amazing type system that catches a _TON_ of errors (maybe even more than Rust's compiler, not entirely sure). And its compiler is just lightning-fast, fastest I've ever seen in fact. And it is multi-paradigm language (OOP and functional, and a lot of interesting typing constructs on top, half of which I don't even understand). Etc.
Not advocating for OCaml by the way (I work with Elixir and am looking to get better at Rust lately). It's just an example demonstrating that, again, there are a good amount of very solid languages and runtimes out there but we the programmers are so busy either (a) belonging to tribes or (b) being so damn busy we can't look beyond the tech we do our daily job with -- and then a lot of excellent tech gets left in the dust. :(
Mercury might be one of these tech pieces. And it's definitely not the only one.
Mercury came about as the OG was wondering about a mix between Haskell and Prolog.
Not to mention manually written algorithms are, in many cases, more accurate than ML heuristics (for a terrible yet relevant example in the finance industry, identifying the correct sum of a set of numbers).
I kind of disagree with this based on intuition alone. Most developers, professional developers, are using web tech (JS stack in particular - Node and hyped front-end frameworks). Yet we"re seeing "interest" in compiled languages such as Rust, despite almost nobody using it professionally and almost nobody doing much with it outside of simple proof of concepts.
To me it points toward a developing sense of insecurity in modern professional developers that simply being a JS dev isn't really programming/development and they've to "prove" themselves with lower level tech.
Something that indicates that, for me, is in StackOverflow's 2019 survey [0] the most used tech was JS and that which surrounds it, followed by Python and other easy-to-get-going-well-supported tech. Yet the "Most Loved" was Rust.
I could be wrong, and I'm open to being, but I intuitively I don't believe the interest in performant technologies is in the face of the sheer bloat we've seen, particularly from the web-front.
>Programmer skill will become more important in the future.
My prediction on this, not so AI specific, is that developing and deploying web-tech will continue to become easier and easier, meaning it'll take less people to do it. Sure, work may arise from developing countries/economies to supplant a drop in demand for it in the developed world, but maybe not.
Combined with a potential bubble burst in tech, I think those relying on web dev for a living could be in trouble in the coming decade.
I don't foresee much in terms of companies trying to optimize operational costs by instructing their devs to write their code more efficiently with memory/performance in mind to reduce operating costs, and thus spur a push toward jumping on compiled languages. If anything, cloud computing will continue to get cheaper and cheaper as the big 3 continue to try and absorb as much marketshare as possible.
When we could, we optimized for ease of writing code, and it lead to bloated and slow systems. This is the current status of things.
We are optimizing again for performance, but we want to have our cake and eat it, we want both the performance and the ease of writing code. And the reduction of bugs in the end result.
This change takes time, perhaps decades. Longer than bubbles and market growth. It takes time because we are curious, and we want to test all possibilities. We want fast games, easy abstractions, zero bugs, the whole package.
But it will happen, at some point. Rust, Go, D, may be one of these languages will replace Javascript, or may be it will be a totally new language.
The way to maintain the easy abstractions, or even increase the level of abstraction while still increasing performance is to ditch the proliferation of massive general purpose programming languages and adopt specific DSLs that fit the problem domain. I feel like the language-oriented programming paradigm that Felliesen of Racket champions is certainly in this spirit, but I would like to see a language core that is specifically tailored to performance concerns.
Not that this is important to the general concept, but this is the current focus of my language design efforts, hoping for first public showing in April 2020,
Although, in re-reading the above, I have made a grave mistake above, contrasting most used with most loved. SO's "most loved" is measured by "of those professional using this language, how many responded that they love using it", so in the case of Rust it's 83.5% of the 3% using it professionally.
In retrospect I think my point would be better made by pointing at the difference between the technologies being used professionally and the technologies "most wanted", where Go and Rust are in the top 20% of wanted but the bottom 40% for Go and bottom 20% for Rust.
I'll leave the original intact for posterity but what's cited is done so erroneously.
> I expect that programming in the future will be more about getting the AI to do what you want rather than writing code directly.
This is the clear endgame. The question is how long it takes to get there.
If this is universally qualified, where are the scientific HPC simulations written in python, AAA video games written in Haskell, and fin tech trading apps written in Lisp?
I am not stating that there are no places where compiled vs interpreted can never produce acceptable results, it’s just more nuanced than a forall type proposition.
Addendum: I am aware C# could sort of be ‘interpreted’ and Unity is C#, so there is at least some evidence in the game category, but I’d quibble over the best-in-class C#/Unity game being considered 100% C#.
This is where I see the SRE (site reliability engineers) role. The developers making changes are put into a position where they measure the cost impact of a decision.
It's these feedback loops, and the practices they instill, that I believe we need. New programmers can help break the mold, but without good feedback they'll fall into the same traps.