184 sats \ 4 replies \ @k00b 23 Jun 2023 \ on: What's the Future of Programming Languages in Your Opinion? tech
My model for predicting the future is roughly: more of what we want biased by the network effects of what we already have.
wrt programming languages: more functional/declarative libraries and frameworks and programming languages that support those patterns. Naive programmers love state and side effects so the programming languages that thrive will also need to provide state and side effects or equivalents.
I'd personally love to see more popular languages with first class meta-programming, but the history of such meta-programming languages (eg lisp) is that the expressiveness causes the language's community to diverge. It also tends to scare away novice programmers. Perhaps someone will figure out a way to prevent those byproducts.
imho a java replacement, ie a reasonably fast and unexpressive programming language for enterprises that enables program and library authors to be easily replaced.
No but the design patterns are here to stay.
Can agree to most if not all 👌
However, I‘d love for more devs having a decent look at Elixir.
It solves many of the tricky parts of writing maintainable code and systems in a functional language.
I think the process model does the trick.
Elixir also has a decent way for meta-programming.
You can write powerful functions and frameworks. Ash is a particularly good example.
Though, I‘m hoping meta-programming won’t lead to a mess in general.
As you described, it can scare away new programmers from Elixir (IMHO not just novice ones).
Any DSL introduces new terms and sometimes comes with a different meaning of an existing term.
reply
Naive programmers love state and side effects so the programming languages that thrive will also need to provide state and side effects or equivalents.
Wdym? Side effect as opposed to return values? I'd argue that depending on the context this is just what heppend when dependencies/frameworks get more powerful and do more stuff
reply
Side effects as opposed to what are colloquially called pure functions.
reply
Pure functions have no state. Side effects are caused by hidden state. Visible state only needs concurrency locking, mutex and atomic. If you can't have state then what is the application going to look like? Configuration? Nah, we don't need no stinkin state.
Functional gave us functions as variables. The rest is obvious, but has the wrong focus. It shouldn't be a remarkable comment to say hidden state causes nondeterministic execution. I think determinism is the key not the 'cleanliness'. Systems have state, and need state. Systems are usually at least two independent threads, thus synchronisation is required.
Functional theory was born in a Von Neumann machine and will stay there because this ideal serial event stream is irrelevant to real world applications.
reply