[sumanthvepa]

The renewed interest in C++ and other compiled languages is an indication of the need to get more efficient. Programmer skill will become more important in the future. But they won't be today's skills. I expect that programming in the future will be more about getting the AI to do what you want rather than writing code directly.

[thechao]

I’m already an AI you can pay to get a computer to do what you “want”; the problem is ‘what you want’ is so poorly specified, there’s no way to turn it into an actionable set of steps!

[meztez]

This comment has to be the most insightful I have ever read. It is true on so many levels and captures perfectly the mentality that some senior decision makers have about AI.

[archi42]

Other dev: "I wish I could just tell an AI to do $implementation for me", me: "You know what our boss just did?". ;-)

[papermachete]

Agreed. Hopefuly a fusion between prolog and haskell comes by - a modern declarative language to end all languages. Let it decide what's best for cache locality and profile your performance. Let it choose the best data structures based on your constraints - compile time and maybe runtime.

[WhyNott]

FYI, a fusion between prolog and haskell already exists: its called mercury. Its a statically compiled language with decent performance characteristics (at least, in its category).

[tluyben2]

Mercury was pretty good last I tried and a very interesting language at that; I like Prolog and did quite a lot of work in it in the 90s (mostly research). I like how clean it looks (that's from Prolog) and the performance is great due to the fact that you give quite a lot of info to the compiler when you are programming (see for instance [0]). It has many backends it compiles to (Java, .NET, Erlang, native; not sure how well they are all maintained). It is a shame that not more people are working on the language and that not more people use it; I think there was not enough hype surrounding it. I gave up as it could not produce native code for ARM, a platform I always need for everything I do (for many years already), so to take a language seriously as something to dive in, it needs to have ARM support. Not sure what the state of that is now; this is many years ago.

[0] https://www.mercurylang.org/information/doc-latest/mercury_r...

[pdimitar]

As a general comment and talking about myself exclusively, it's a new kind of fatigue that I would call "oh look, another programming language".

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.

[tluyben2]

Interestingly (and I did not know this) Mercury is actually one year older than OCaml. Both are fine languages that are underused/under-appreciated; OCaml did much better (PR wise so to say) than Mercury but both should have, imho, more market share.

Mercury came about as the OG was wondering about a mix between Haskell and Prolog.

[falcolas]

Identifying the right characteristics in data, and creating properly tagged corpuses of data that correspond with the right characteristics is no less work than writing code.

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).

[cmdshiftf4]

>The renewed interest in C++ and other compiled languages is an indication of the need to get more efficient.

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.

[0] https://insights.stackoverflow.com/survey/2019#overview

[Shorel]

At first we optimized languages for memory and CPU use, because there was so little of it.

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.

[throwaway17_17]

The following is not a particularly deep thought, and that is why it is stated simply:

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,

[steveklabnik]

Rust is used for far more than proofs of concept, and is deployed at some of the largest tech companies in some of their key products.

[cmdshiftf4]

Not disagreeing with that.

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.

[steveklabnik]

Yeah, it’s tough; the “most loved” thing is interesting. It’s name kinda indicates a scope that’s different from what it’s measuring, but I’m also not sure what else I’d call it.

[quotemstr]

I don't think the new interest in compiled language reflects anything other than ongoing cyclical changes in fashion. Neither "compiled" nor "interpreted" language families (the terms are vague and the same language can fall in both categories) has a slam dunk performance advantage over the other.

> 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.

[throwaway17_17]

It’s a small semantic nitpick, but I think that you have to qualify the domain of conversation in stating: ‘neither “compiled” or “interpreted” language families ... has a slam dunk performance advantage over the other.’

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#.

[sudosysgen]

Unity is also quite far from being known for the best performance.

[crazypython]

It seems to me that if we can merge https://github.com/Syniurge/Calypso into LDC, we can get a language that is easier to understand and compiles faster than C++, Dlang.

[Forge36]

Using the data we what have would already be a big gain. I think that's AI's biggest contribution. I've seen a lot of time and complexity go into improving functionality beat by someone who wrote code to track what actions were taken, and adjust based on frequency of use. The first option is needed if you have no data and cannot gather the data, the second is great because it can adjust itself over time.

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.

[jobseeker990]

What about Rust or D? OR even Go-lang?

[c-cube]

I'm hopeful about Crystal filling this niche in the future.

[sly010]

Why not both?