I've been going through many, many programming languages over the years. Many of them I can't even remember anymore. Some of them I have stuck with for a long time, simply because they were most suitable for the kind of problems I was trying to solve at the time.
Originally I was very much in favour of finding the 'One language to rule them all'. Being able to do everything with a single language seemed like a no-brainer. But what all these years of try-outs have taught me is that such a language simply does not exist. And I will go one step further to state that they shouldn't exist.
The problem with every single language which tries to be good at everything, is that it inevitably ends up being mediocre at best and a major clusterf*ck at worst (I am looking at you, c++). Yes, it may be able to solve every problem out there, but not at significant cost to the programmer and development cycle. Inordinate amounts of complexity make the whole business of writing a useful application nothing short of a nightmare. A nightmare that you just do not have to put up with.
Lately I have come to realize that the quest for that one language has been a monumental waste of time. I have since settled on a DSL strategy. Pick a problem and then find a language/toolset that is uniquely suited to solve that problem in the most efficient way possible. Not only does this make the development cycle less painful, it teaches you a great deal about the problem domain your are facing, without having to deal with all the superfluous nonsense that a general-purpose language would impose upon you.
By adhering to this strategy, the obvious side effect is that there is no such thing as a favourite programming language. It all depends on what you are trying to accomplish. For the time being, my focus lies on Go. Not because I think it's the best thing that ever happened to the world, but because it solves /my problems/ elegantly and (almost) painlessly. This doesn't mean I will be using it for everything though. I would not even consider using it for something UX/UI related. For the simple reason that it is definitely not the ideal tool for this job. Just like I won't consider using Javascript to build servers and other distributed systems.
Use the right tool for the right job.
Edit: When it comes to DSLs, I would even add this: If you can't find a suitable toolset/language for your problem, consider creating your own.
At Goldman, this was the precise approach in the group I worked in. Create a DSL that prices equity derivatives. Create a DSL that handles bond math. Create a DSL that lets junior traders whip up custom swing UIs of their exposures.
One big problem with this approach is what happens when you get hit by a truck ? The programmers you hire to replace you don't want to learn your DSL, nor want to write code in some custom DSL. Its not a transferable skill. I cannot put a bullet point in my resume saying - I wrote bond math code in GS custom DSL. What would that even mean ? Maybe I just invoked some routine and it did all the bond math for me, so what specific skill did I learn other than memorizing your DSL's syntactical conventions ?
So this sort of approach doesn't work for anybody in the long run, except the DSL creator who can justifiably be very proud of accomplishing a shitload of tasks using 2 lines of a custom DSL.
You worked with bond math -- that's what goes on the resume. It doesn't matter a lot whether it was a custom DSL or a custom library in a common language. Nobody trusts your resume anyway. It just has to start the conversation in the right direction.
Whether it's good for the organization is situational. Wherever you go, new hires have to learn the codebase before they can be really effective. It helps if it uses common tools and languages, but it also helps if it is well-factored. If using a custom DSL results in much better-factored code, it can be a net win.
There are so many languages out there. It's hard to get a job by leveraging your skill in the small subset you know without passing up a lot of opportunities involving the ones you don't.
"Lately I have come to realize that the quest for that one language has been a monumental waste of time."
A question that arises from this, how can you communicate this with too many intelligent developers that foam at the mouth for what they use, and don't waste a moment to scoff, snide or look down on others?
That behaviour, itself is kind of ironic, because in school I'm sure most of us weren't very popular or cool because no one knew what the internet was, nor were computers universally cool(er).
I wonder sometimes if it's not like continuing the uppity behaviour some may not have gotten over and instead turn on their fellow developers.
Comments
I've been going through many, many programming languages over the years. Many of them I can't even remember anymore. Some of them I have stuck with for a long time, simply because they were most suitable for the kind of problems I was trying to solve at the time.
Originally I was very much in favour of finding the 'One language to rule them all'. Being able to do everything with a single language seemed like a no-brainer. But what all these years of try-outs have taught me is that such a language simply does not exist. And I will go one step further to state that they shouldn't exist.
The problem with every single language which tries to be good at everything, is that it inevitably ends up being mediocre at best and a major clusterf*ck at worst (I am looking at you, c++). Yes, it may be able to solve every problem out there, but not at significant cost to the programmer and development cycle. Inordinate amounts of complexity make the whole business of writing a useful application nothing short of a nightmare. A nightmare that you just do not have to put up with.
Lately I have come to realize that the quest for that one language has been a monumental waste of time. I have since settled on a DSL strategy. Pick a problem and then find a language/toolset that is uniquely suited to solve that problem in the most efficient way possible. Not only does this make the development cycle less painful, it teaches you a great deal about the problem domain your are facing, without having to deal with all the superfluous nonsense that a general-purpose language would impose upon you.
By adhering to this strategy, the obvious side effect is that there is no such thing as a favourite programming language. It all depends on what you are trying to accomplish. For the time being, my focus lies on Go. Not because I think it's the best thing that ever happened to the world, but because it solves /my problems/ elegantly and (almost) painlessly. This doesn't mean I will be using it for everything though. I would not even consider using it for something UX/UI related. For the simple reason that it is definitely not the ideal tool for this job. Just like I won't consider using Javascript to build servers and other distributed systems.
Use the right tool for the right job.
Edit: When it comes to DSLs, I would even add this: If you can't find a suitable toolset/language for your problem, consider creating your own.
At Goldman, this was the precise approach in the group I worked in. Create a DSL that prices equity derivatives. Create a DSL that handles bond math. Create a DSL that lets junior traders whip up custom swing UIs of their exposures. One big problem with this approach is what happens when you get hit by a truck ? The programmers you hire to replace you don't want to learn your DSL, nor want to write code in some custom DSL. Its not a transferable skill. I cannot put a bullet point in my resume saying - I wrote bond math code in GS custom DSL. What would that even mean ? Maybe I just invoked some routine and it did all the bond math for me, so what specific skill did I learn other than memorizing your DSL's syntactical conventions ? So this sort of approach doesn't work for anybody in the long run, except the DSL creator who can justifiably be very proud of accomplishing a shitload of tasks using 2 lines of a custom DSL.
You worked with bond math -- that's what goes on the resume. It doesn't matter a lot whether it was a custom DSL or a custom library in a common language. Nobody trusts your resume anyway. It just has to start the conversation in the right direction.
Whether it's good for the organization is situational. Wherever you go, new hires have to learn the codebase before they can be really effective. It helps if it uses common tools and languages, but it also helps if it is well-factored. If using a custom DSL results in much better-factored code, it can be a net win.
There are so many languages out there. It's hard to get a job by leveraging your skill in the small subset you know without passing up a lot of opportunities involving the ones you don't.
This is an argument against proprietry languages, not DSLs.
"Lately I have come to realize that the quest for that one language has been a monumental waste of time."
A question that arises from this, how can you communicate this with too many intelligent developers that foam at the mouth for what they use, and don't waste a moment to scoff, snide or look down on others?
That behaviour, itself is kind of ironic, because in school I'm sure most of us weren't very popular or cool because no one knew what the internet was, nor were computers universally cool(er).
I wonder sometimes if it's not like continuing the uppity behaviour some may not have gotten over and instead turn on their fellow developers.