Uncle Bob has a post on his blog from a while back called "The Dark Path".
I've personally had an interesting journey with this post. It's taken another turn as I read about the new programming language "V".
Unlike Uncle Bob; I've not done more than read and think about the languages. He's dabbled in the ones the post is about. I've also dabbled in those. V feels very much like GoLang. Particularly around the "puesdo-object"-ness of the language.
It's interesting and an opportunity to really dive into those languages would be awesome. That's not the point of the post here though.
You should really read the post if you haven't. Overall I really enjoy and value reading Uncle Bob's posts. Even, if not especially, when I disagree with them. I want disagreement. I want to be forced to dig deeper into my reasonings. An echo chamber is a problem for a reason - I want new things that make me look in new places.
Anyway - Assuming you've read it - I don't agree. Not entirely. Somewhat though.
I disagree
When I first read the post, I fundamentally disagreed. I think the constructs Kotlin (hadn't done Swift at the time) put in were great. There's a lot of language features that would have significantly cleaned up.
I felt that new languages allowed us to be more effective.
As Uncle Bob links to - I was caught up in "The Churn". Another great post to read. It's about how the next new shiny thing is going to solve this one problem I have, it'll be great! Less problems!!!
The Churn is part of what I disagreed with. Kotlin gave me many improvements I kept trying to use in Java.
I agree
Since then I've learned more about actual object oriented programming and have seen that the languages are just making up for developers bad practices.
The Churn is trading a known problem for unknown problems in an unknown space with unknown complications. ... It solved X, but who knows what else it brings in, and how much slower it'll cause us to be.
Read his Churn post.
The langauges we have don't address everything. They never will. They all have positive and negative qualities; tradeoffs. New langauges spring up to account for the negatives that someone didn't like. The cost is that they are moving some positives into the negatives with the new langauge. Positives they don't care about, but maybe you do.
I don't agree
It's not that I disagree, but that I don't agree. I think he's right in a lot of ways.
_We need to choose a language, or two, or three. A small set of simple frameworks. Build up our tools. Solidify our processes. And become a goddam _profession.
I agree with this. We're a floundering fuck-up right now as a profession.
Does that mean we shouldn't invent new languages? I don't know Uncle Bob's position on this; so I cease directly (dis)agreeing at this point.
My answer though, "No".
We need to invent new languages. We need to try new things.
We need to see what happens when X, Y, and Z are strictly applied. It's the opportunity to look at how to do things differently. Find some painpoints of how we want to do things without the ability to fall back and say, "it's hard here, I'll let this slide". Figure out a solution when you can't break the rules you want to see.
Murk
It's a damn murky path.
As you saw ('cause you read it); uncle Bob asks a question a few times
The question is: Whose job is it to manage that risk? Is it the language’s job? Or is it the programmer’s job.
This is a fabulous question. Slightly rephrased, "Who has responsibility for ensuring the program does what it should?". I think this phrasing brings out a much more obvious answer.
Managing risk is ensuring that the program does what it should in areas that may be uncertain.
The first example in the post is around exceptions. Exceptions are risky and cause great uncertainity in a system. The standout scenarios for me are:
* Can this throw exceptions?
* Should I handle it?
My answer to these are to throw as few exceptions as possible and handle as few as possible.
If your system is throwing exceptions; you've got a problem. Exception handling is a 'fire and forget' version of "goto".
I've made efforts to port my IMock framework into swift. I don't have it online yet (apparently).
The exception handling in Swift has made me almost give up. A component of the IMock framework is being able to make a method throw an exception. Any method.
Which means, ANY method it mocks out needs to take a lambda that throws. I don't remember the solution right now, but "WOW" it was a problem for a few weeks.
Swift's efforts to control exceptions is the language taking choice away from the engineer. Who's decision should it be on how to use exceptions? Swift declares itself the arbiter of that. As a language, it can.
We learn techniques from the new stuff that we can apply to the old stuff. Honestly though - We learn nothing new, because we don't know the past.
Nothing these languages do is new. The 60's and 70's thought out so much. They wrote it down. It's there for us to learn from, to apply in the languages we use today.
We don't apply it though, we build it as part of something new.
Continue
I want to see the experimentation. The promotion of new ideas and new ways. Let's be honest about the tradeoffs though. Let's recongize what problem we're trying to solve and why, and what we had to sacrifice to get there.
No language solves it all, and there are tradeoffs where you CAN'T have both.
I enjoy seeing null-less languages. But I don't think it's the languages place to try and control that. It's beyond our control sometimes; we don't get a value. What do we get instead? The language now answers that for us. We lose a little bit of control over our system. We have to be explicit if we have a null or not - but as Uncle Bob asks
The question is: Whose job is it to manage the nulls. The language? Or the programmer?
The languages we have that start to bring in these "fixes" for what developers DON'T account for complicate the language. It adds complexity for the bad practices and, likely, ignorance of the users. Instead of education, it's langauge design. Instead of better practices, it's a new feature.
I agree that new languages for the purpose of becoming a dominant language is terrible.
Google made GoLang. They made it to solve a problem they had. They had tradeoffs and compromises and decisions that explicitly reduced their pain.
GoLang is for Google to reduce their pain of development. It just so happens it's useful for others too. That's not why they made it.
V, is made for others. It's an attempt to make a "better" language. There's not an obivious "Why create V?" Just comparrison to other langauges.
It's because the person behind it wants to mitigate the tradeoffs of the other languages, but not do it through disciplined practices; instead - He wrote a language.
He has a list of features he wants in a language and none exist with them. V is a language which isn't solving a problem, it's creating a problem.
I'm not going to rip into V. I approve of the effort and the awareness of bad practices the other languages allow. Creating "another" language may not be the best option.
It's an effort to make others do as you want, but can't convince them it's a better way.
Ummmm
I've been writing this over the course of about 6 hours while interrupted with other stuff. A lot of trains got derailed.
So why? Why did I blather on about all of this? Because of the change I had.
I disagreed because the languages gave me things I wanted.
I agreed because using the language is a crutch instead of having discipline.
I neither agree nor disagree because we shouldn't use the language as a crutch, but we should create things that solve specific problems and explore concepts.
As a profession, we need to standardize and stabalize and find ways to make us excel. As an industry we need to create tools to remove the pain points that are cheaper to solve with new tools than with better discipline.
There is no answer; there are tradeoffs. Positives and Negatives. Let's find those and see how we can improve our existing tools to be better instead of building new tools to do it different.