pull down to refresh

  • In the C/C++ world: will Carbon catch on? I feel the enthusiasm from the community is mixed
  • Rust? So many people are real fans of Rust and rewrites in Rust happen surprisingly often. However I feel that many developers don't bother learning it since the learning curve is steep and the compile-time memory management is disappointing to me
  • Java/Kotlin world: In the early days the JVM was a dream for compability - but do we still need this? Should Java just die? People hate the performance and prefer Docker Kubernetes everything or Apps in native or Electron. It's neither here nor there. And so many Apps in Java 8 where nobody wants to pay for a Kotlin of Java 17 rewrite.
  • Frontends in Angular/React. Do you think this is the be-all-end-all? I certainly don't.
  • Python seems to have blurred the borders on what a programming language and what a User-tool is. And I'm sceptical about non-global interpreters.
  • Go? I still can't figure out where it's place in the landscape is or will be
Overall I think we live in interesting times for programming languages - what do you think?
I expect the continuation of functional programming concepts, like abstract data types, Maybe/Optional, and immutability to be adopted by non-functional languages. Java will probably live on, but in the likes of COBOL; Usage will probably drop and the few programmers who still bother with it will get paid handsomely. I think Elm does a better job than Angular/React, but Angular/React will probably persist. Perhaps Python will be the next Perl. What I would like to see is more Haskell and less of everything else.
reply
I expect the continuation of functional programming concepts
In my first semester of university we began with a functional programming language.
I do appreaciate inline for loops in python or stream mapping in Java (which both aren't really functional programming but give of the same "vibes") but I don't think they don't make for maintainable code.
reply
Natural language.
reply
You think this will actually happen and replace tradtional programming? I don't see it escaping the "proofreading phase" anytime soon
reply
Not anytime soon but eventually.
This is the problem with discussing the future. Do we mean a year from now or ten or a hundred?
reply
I think the last hurdle including the need to proofread is a classical 80/20 problem. Due to the progress of the last 2 years people estimate the x-day to be in 10 years while I think it will be much longer.
reply
Recently I have been working with LLMs and it's really heavy on building natural language text queries to get it to do what you want. It's mainly about injecting blobs of text to make it change its mind. Also what I find funny is that when you ask it to first think through the execution plan and you also append "please", then the results are much (much!) better.
reply
I think it's a good thing that natural language takes over too.
It's another basket of skills that we can offload from human understanding. Let the AI we create learn the technicals and get good at interpreting our own language.
It's the same way a calculator works. Takes care of the nitty gritty work for us based on our inputs. Calculators can easily perform complex tasks that we don't need to understand.
It makes coding, and thus creating, more efficient and accessible to everyone.
reply
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.
Go? I still can't figure out where it's place in the landscape is or will be
imho a java replacement, ie a reasonably fast and unexpressive programming language for enterprises that enables program and library authors to be easily replaced.
Frontends in Angular/React. Do you think this is the be-all-end-all? I certainly don't.
No but the design patterns are here to stay.
reply
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
I think although it is in early stages a lot of the grind and tedium of programming will be reduced with AI stub generators that can build any kind of thing and make sure all the pieces are there so all you have to do is write a bug free implementation. It should eventually happen, maybe in a decade, that all programming languages get sucked up into an AI transformer matrix and let you use any programming language system for any part as you like, all to the strict standard set at some year or other.
Maybe in 30 years time you will just have one little small core AI system that has all the info to create a completely bespoke, easily customisable, mostly bug free operating system and applications, just by giving prompts and feedbacks. And every computer will be like part of or isolated unit of what amounts to a global mainfraim computer as all the barriers between things are dissolved, a process we see accelerating now already.
Humans will never be replaced, we will just always do more with less as we advance our knowledge.
reply
Have you looked at Elixir?
IMHO, like Bitcoin, it is seriously undervalued.
It’s more about the platform and ecosystem than the language itself.
The language syntax itself is similar to Ruby. Very approachable with some neat new features.
But the platform is outstanding. It runs on Erlang and its BEAM Virtual Machine. A stunning piece of technology that is especially well suited for today’s web services!
Functional, fault tolerance, scales to thousands and millions of connections pretty easily.
And then there is projects like Phoenix and Phoenix LiveView.
Brings real-time to the web in a pretty nice way.
Some of the highlights I‘ve seen over the last couple of years:
  • BEAM VM
  • Functional, immutable
  • Process Architecture
  • Easy to write fault tolerant systems
  • Easy to write (big) systems that recover („self-heal“) in case of error
  • Phoenix Framework
  • Oban, a job worker framework
  • Absinthe, for GraphQL
  • Ash, a holistic framework that reduces most boilerplate for your typical CRUD operations and a framework that actually allows to escape the framework if it doesn’t solve a problem right away for you
We‘ve recently built a system that handles quite a tricky process and where lots of external services are involved. I wouldn’t have wanted to implement this process in, say, Node.js. With Elixir and Oban, it was rather straightforward.
Hard to describe. The process model and functional approach is the game changer for me.
All in all, I am really happy to have discovered Elixir a couple of years ago.
It changed how I write software a lot.
Still happy with the choice.
reply
Other highlights I forgot to mention:
  • documentation is actually good 😄
  • the community is awesome, very helpful and responsive
If you are curious to learn more and see Elixir in action, I can only recommend watching this fantastic talk:
„The Soul of Erlang and Elixir“ by Saša Jurić 🧡
reply
The future of programming languages is likely to involve continued advancements in existing languages, as well as the emergence of new languages to address specific needs or challenges. Trends may include increased focus on performance, security, and concurrency, as well as better support for machine learning and artificial intelligence applications. Additionally, we may see more languages designed for specific domains, such as data science, IoT, and blockchain. As technology evolves, programming languages will adapt to meet the demands of developers and the industries they serve.
reply
Go is still the best. All modern apps and servers need concurrency. None of the others listed have first class coroutines and atomic FIFO queues, all are libraries, if you are lucky to find them. Rust brags about memory safety but go achieves this also with less code and complexity for the programmer. Rust is better than C/C++ for speed and safety. But it is more than 2x as complex. You can jump to Go and write something useful before a week trying. Rust you are still fighting the borrow checker after a month. It took me 2 weeks to make a microservice that took 3 days in go.
reply
Agree this is an exciting time for developers. I first worked with Unix in 1985 and worked full time as a developer from 1993-2018. Pythonista from 1997. I am most excited about Typescript and supporting tools like deno these days.
reply