> You need a VERY good reason to use anything except TypeScript/C#/Java/Golang/Python/React/Vue/Postgres/MySQL/SQL server/Oracle. Perhaps Rust. These technologies are good enough to get almost anything done these days. There's exceptions of course for example games tend to written in C++ and embedded is often C.
I'm not sure what you're suggesting.
Are we expected to rewrite everything every decade when a new flavor of language comes out?
It seems like, with the exception of Rust, you've named a lot of "lowest common denominator" languages. These languages, while productive, tend to lack expressiveness. It is my opinion that expressiveness is seen as a bad thing in the "professional" community because it takes significant cerebral evolution over the course of a career to learn which tool in the toolbox to use. In other words since the explosion of programming as a career there are more idiots in the proverbial gene pool, and so more companies prefer more idiot-proof languages because the average developer can't help but hurt themselves. This doesn't mean we should prefer "new safe technologies", it means our recruiting should far more stringent and our education far more formal (as in an actual useful programming degree).
I for one would quit if I could program, for example, common lisp and make even 3/4 of my current salary.
Here's, in my opinion, a better and less controversial hot take. Use what works. If you have a team of erlang developers do it in erlang (or whatever). Who cares about the market. If it means spending even more time (and money) learning to write another more popular language correctly it may not be worth the investment. If you build it, they will come. You will have no problem finding an endless stream of developers you can build from the ground up.
As a side note: Kotlin, Ruby, and F# are extremely popular. TIOBE is not a real measure.
> This doesn't mean we should prefer "new safe technologies", it means our recruiting should far more stringent and our education far more formal (as in an actual useful programming degree).
I think the ironic thing here is that these "approved" languages are both less safe and less expressive. Statically typed functional languages like Haskell and OCaml allow much more correct code and reject much more wrong code compared to something like Java or Go. I'd even go as far as to argue that in some ways, Haskell is more expressive than the mainstream dynamic languages (Ruby, Python, JS etc).
Now, if your developers are really "idiots" (which to me is a very condescending thing to assume, but that's a different story...), then maybe they won't even be able to get their code to type check in the first place and ship no code at all :)
> Statically typed functional languages like Haskell and OCaml allow much more correct code and reject much more wrong code
In functional code, sure. In a predominantly mutable algorithm, you fight the language more than what you gain, and sometimes, yes, the mutable approach is simpler and easier to reason about. Especially local mutability can be very readable/maintainable.
> If you have a team of erlang developers do it in erlang (or whatever). Who cares about the market
As an IC, I care about the market. I go to work exclusively to exchange my labor for money to support my addiction to food and shelter. When it was time to change jobs as your bog standard enterprise dev, it was much easier to throw my resume in the air and get a job offer by being an experienced C# developer than it would have been if I had spent three years writing software in Erlang.
And most job interviews outside of tech companies where most developers work are not going to be language agnostic nor are they going to have you reversing binary trees on the whiteboard while juggling bowling balls and riding a unicycle on a tightrope.
As a reformed former dev lead, why would I hire an Erlang developer when I could throw a rock and hit a good enough C#/Java JavaScript/React developer to push out some CRUD SaaS app or line of business app?
Idiot proof languages are popular. If you want assured money learn an idiot proof LCD language. In fact, everyone should have one in their tool belt to put food on the table.
However, if you're actually a talented engineer these languages will hamstring you and your art. You will probably eventually gravitate to something more heady (such as the less popular languages) and probably even leave your nice cushy gig to give a professional life in that stack a shot. This isn't, however, to say talented engineers don't exist in lowest common denominator language pools. It's just esoteric/less-used languages tends to cause the best quality of talent to come from them owing from many of their problems. If you can be proficient and productive in a language that you can't easily google a solution for, you're probably an excellent candidate for promotion into the higher echelons.
This is a similar phenomenon to editor choice. My anecdata in a little over 10 years of a career has given me the impression that I can tell what kind of developer someone is by their editor. People who use raw vim/emacs tend to better developers. Why? It's not the editor itself. It's that these editors pull no punches and require time and expertise. That dedication is not taught. The easier an editor is to use for a beginner, the more average a programmer tends to be. Again, there are a lot of very talented developers using VSCode or full blown IDEs. But with those editors your signal to noise ratio is quite low. It's anecdata but mixed with the information above you can gather a lot of "metadata" about a person without much effort.
It's like the equivalent of judging a carpenter for using power tools because he's just not dedicated and gritty enough to use a manual twist drill.
My anecdata, people who overly focus on language and tools tend to be the worse developers. It's the developers that effectively address the universal problems of writing software people want to use, like api usability, reliability, data consistency, maintainability that have the most props in my book. The best developers I've known weren't particularly attached to any editor, language, or framework.
> It's like the equivalent of judging a carpenter for using power tools because he's just not dedicated and gritty enough to use a manual twist drill.
I think this is an apt analogy. Mostly because carpenters who use hand tools produce more beautiful, unique works of art. When everything you do is on rails (no pun intended) you don't have the flexibility or creativity to make works of art. It's like saying Ikea tables (the equivalent of an idiot proof language) are just as nice to look at and functional as a purpose-driven hand crafted table. I have my doubts, despite using Ikea when I "just need something done".
Nice one, being it elucidates the art being lost in other fields (and perhaps all over).
Your analogy doesn't make sense. There's nothing about the programming languages you consider "least common denominator" that lock you into a specific design, unlike your Ikea table. Actually those LCD programming languages are generally the least opinionated in how you use them.
> It's like the equivalent of judging a carpenter for using power tools because he's just not dedicated and gritty enough to use a manual twist drill.
Serious question: all else equal and without any additional information, between two carpenters who produced the same output in the same time, one with power tools the other without, is there any reason whatsoever to assume one of them is any better than the other?
No, drilling holes doesn't make you a good carpenter, use the most convenient tool you have available. Designing a good chair that people want to sit in then producing it from idea to reality does.
I'd think manual carpenter is going to have to retire early due to repetitive strain injury.
Same but for a different reason. Being able to overcome the learning curve and become comfortable using power tools to achieve equivalent results makes you a valuable employee as a human, it raises you to a higher level of control and increases your capabilities beyond what you could do with bare hands. (The only benefit of being capable without power tools is if there's no electricity for example. IANAC)
The same with "easy"/mainstream languages: something like OCaml/Haskell/Nim/Nix/etc. is a power tool with a steeper learning curve compared to something like Python/JavaScript/shell scripting; you being able (and willing) to handle it without abundance of learning resources says something about your mental capacity and potential value as an employee.
This is like one (non tech) company that I was hired at as a dev lead where they were about to embark on writing an “address validation module”. I quickly put an end to the entire project and worked with a vendor to license CASS software.
Companies pay employees to add business value. Not to get into their own flights of fancy to do things the hard way. As you mature, you learn only to focus on things that “make the beer taste better”.
I have yet to see an argument by any of the proponents of “obscure” languages where their choice adds business value.
And the “hard problems” that are being solved by the large companies at a scale that has never been solved are doing so by using mainstream languages.
I’ve never seen a report of a job interview where they asked you to reverse a binary tree in Erlang.
The vast majority of problems that developers are being asked to solve are not that hard technically. They are business problems.
I mean more having learned to be productive in an obscure language as a positive marker regarding your mental capacity, intrinsic motivation, autonomy and initiative. If you then insist on using it for everything, business value be damned, that is a red flag. Choosing an obscure language to tickle your fancy would be negative value to me as a business owner since I need to hire and maintain a team of developers who are all comfortable and proficient in it. However, there are circumstances in which an obscure language might just be the right tool for the job (and overall architecture that can accommodate a small cohesive component written in a different language has its benefits).
You think it’s a red flag for a business to hire people who can add business value?
I’m motivated to get up everyday for the same reason most people are - money.
I bet you’re looking for people with “passion” and who are willing to consistently put in more than 40 hours a week aren’t you? Out of all the millions of things I can do and have done in my free time over my career (including a working hobby as a part time fitness instructor back in my younger days an avid runner and a weightlifter) spending more time sitting at a computer outside of work isn’t one of them.
And the obscure language would hardly ever outweigh the need to recruit developers easily.
> You think it’s a red flag for a business to hire people who can add business value?
Where have you seen that?
> I’m motivated to get up everyday for the same reason most people are - money.
You are quite mistaken. Once they have enough to exist comfortably, people tend to seek meaning not money. The emergence of OSS ecosystem is the best example -- a lot of it, including the most popular OS in the world, came about as hobby projects people did in their spare time. If you're a software engineer, I bet you use products of their passion a lot in your money-making activities.
> I bet you’re looking for people with “passion” and who are willing to consistently put in more than 40 hours a week aren’t you?
Again, all else equal, if I need to make a decision as to who would be a better, more capable employee in absence of other information, the one who managed to be productive in an obscure language would be higher on my list. Just that. Everything else, making people work overtime, etc., is your addition.
My question was not answered. In that scenario you have access to the work both of them do, so it speaks for itself, and it is equivalent work done in equivalent time. Use or non-use of power tools is the only difference. Do you factor that in your judgement or you flip a coin when choosing an employee or supplier?
Okay, so this means it's not relevant to you which is... an interesting take. I guess you better operate your business in at-will employment legal landscape (and not feel bad for your employees' families after you fire them left and right this way).
For me I would definitely make use of this extra information before hiring. Hiring a carpenter who's able to work with power tools is likely better, unless I need to foresee a situation where they must work without electricity. Even if they are physically fit, power tools can enable a human to do something not possible at all with bare hands.
For a programmer it's the reverse, if we assume "power tool" is an "easy" language compared to something like OCaml, or maybe tools like VS Code and Copilot compared to vim. These tools don't help overcome a physical limitation, like the power tools of a carpenter, but a mental one. Being able to set up vim fully to be as productive and produce as few bugs as someone with VS Code, or being able to pick up Haskell without being able to immediately get a human answer your every question, exemplifies the type of higher-level skills and learning capability that is the primary value of a human employee compared to a robot.
In other words, in context of this discussion, the equivalent of carpenter's power tools might be much closer to Haskell + bespoke vim/tmux setup than JavaScript + VSC.
> Idiot proof languages are popular. If you want assured money learn an idiot proof LCD language.
You saw that whole spiel about my desire to exchange my labor for money to support my addiction to food and shelter?
> However, if you're actually a talented engineer these languages will hamstring you and your art.
I have no desire to be a starving artist. I turn requirements into code so businesses with money will give me some of it by adding business value. I don’t program to create the next Picasso.
I stopped considering programming “fun” after doing it for 10 years across 4 assembly languages (65C02, 68K, PPC, x86) before I graduated from college in 1996.
> and probably even leave your nice cushy gig to give a professional life in that stack a shot
So tell me again why I would leave my “cushy gig” (and it is the cushiest gig you can imagine in any BigTech company)?
> you can be proficient and productive in a language that you can't easily google a solution for, you're probably an excellent candidate for promotion into the higher echelons.
Every single leveling guideline I have seen at any tech company doesn’t mention “ability to code in an esoteric language well”. It’s all about “scope”, “impact”, “managing ambiguity”, etc. “Coding ability” really only comes into play from junior to mid. After that it is about system design even at the interviews.
> I stopped considering programming “fun” after doing it for 10 years across 4 assembly languages (65C02, 68K, PPC, x86) before I graduated from college in 1996.
this makes me sad to hear. I fell in love with programming at age 7 and still love it at 32. I'm extremely fortunate to enjoy something that pays well, rather than languishing at a cushy job that leaves me empty.
> Every single leveling guideline I have seen at any tech company don’t mention “ability to code in an esoteric language well”. It’s all about “scope”, “impact”, “managing ambiguity”, etc. “Coding ability” really only comes into play from junior to mid. After that it is about system design even at the interviews.
if you're hiring plumbers, sure. it's not all plumbing, though. there's algorithm design, compiler engineering, formal verification, program synthesis, numerical methods, etc. etc.
the really effective people in those fields use (or make) weird languages. Isabelle's written in HOL, Coq in OCaml, Agda in Haskell. having a knack for weird languages is a plus for brainy jobs working on that kind of stuff.
> I'm extremely fortunate to enjoy something that pays well, rather than languishing at a cushy job that leaves me empty.
My job paying well allowed my wife to buy a vacation home/investment property for the winter and starting at the end of the month fly around the country and stay in mid tier hotels and do the whole “digital nomad thing”.
I spent the first fifteen years out of college having a great time outside of work as a part time fitness instructor (more of hobby) and training and running with friends.
It's very good and healthy to have a life outside of work, but you're still going to spend anywhere between 25 to 60 hours a week working.
Making sure that you actually enjoy those hours has a massive impact on your quality of life.
For an extreme example, what pay cut would you be willing to take if you were able to do fitness training full-time?
> My job paying well allowed my wife to buy a vacation home/investment property for the winter and starting at the end of the month fly around the country and stay in mid tier hotels and do the whole “digital nomad thing”.
This is somewhat off-topic and I don't know you or your wife personally, but I find it flabbergasting that a spouse would choose to do the "digital nomad thing" when their partner can't or won't follow them. Even more so when they're being bankrolled by said partner.
> However, if you're actually a talented engineer these languages will hamstring you and your art.
Early in my career I thought of software as art. I was wrong.
The very last thing I want in any production software team is an artist looking to express themselves. I want the worlds most talented engineers who want to use consistent proven methods to create solid maintainable code with zero surprises.
Code as art has its place, granted, but that place is in the privacy of your own time in a repository with one single contributor. I occasionally still go back to writing lisp for fun, but it has no place in production.
Perhaps it's just a generalization, but I don't think there's such a clear separation between "code as art" and "code as engineering".
The very best engineers are like artists, in that they harness their creativity to solve problems efficiently and effectively, often in innovative and personal ways.
And artists who are respected in the field of software can use consistent methods to produce solid maintainable code. I wouldn't say "zero surprises" though, I'm often surprised by reading the code of an artist, how they achieve extraordinary results with mundane code that a child can understand.
The example that comes to mind is Fabrice Bellard. He's one of the most talented engineers - and I'm sure many of us would agree that his software is a work of art.
Well, as someone who has to manage a team, I completely agree that what's needed are engineers who can consistently produce predictable results. We don't want someone who chooses (or worse, creates!) an esoteric language to pursue their art. But I myself am of the latter persuasion, "writing lisp for fun". And having a team of only non-artistic engineers would be so boring. But then again, boring is what we need most of the time.
> The very best engineers are like artists, in that they harness their creativity to solve problems efficiently and effectively
As a reformed former dev lead, I wanted a consistent industry standard idiomatic method of writing code and I used a combination of static analysis tools and code reviews to establish a culture to do just that.
I don’t want my C# developers who came from Java writing an AbstractFactoryFacadeBeanProxyDecaratorSingleton.
“Fun” for me is doing anything except being in front of a computer after hours. Between time with my wife, exercise, learning Spanish and just vegging out, computers are the last thing on my mind. I don’t even have a personal computer anymore.
> Code as art has its place, granted, but that place is in the privacy of your own time in a repository with one single contributor. I occasionally still go back to writing lisp for fun, but it has no place in production.
> Every programmer occasionally, when nobody’s home, turns off the lights, pours a glass of scotch, puts on some light German electronica, and opens up a file on their computer. It’s a different file for every programmer. Sometimes they wrote it, sometimes they found it and knew they had to save it. They read over the lines, and weep at their beauty, then the tears turn bitter as they remember the rest of the files and the inevitable collapse of all that is good and true in the world.
> This file is Good Code. It has sensible and consistent names for functions and variables. It’s concise. It doesn’t do anything obviously stupid. It has never had to live in the wild, or answer to a sales team. It does exactly one, mundane, specific thing, and it does it well. It was written by a single person, and never touched by another. It reads like poetry written by someone over thirty.
> Every programmer starts out writing some perfect little snowflake like this. Then they’re told on Friday they need to have six hundred snowflakes written by Tuesday, so they cheat a bit here and there and maybe copy a few snowflakes and try to stick them together or they have to ask a coworker to work on one who melts it and then all the programmers’ snowflakes get dumped together in some inscrutable shape and somebody leans a Picasso on it because nobody wants to see the cat urine soaking into all your broken snowflakes melting in the light of day. Next week, everybody shovels more snow on it to keep the Picasso from falling over.
I feel this is true. If a person has a few esoteric languages under their belt it says a lot about their drive and passion. If anything if I wanted to find talented devs I would put some more esoteric languages on the requirements lists even if we wouldn't use those languages internally. It's a pretty effective filter.
So where do they gain that passion if not from developing off hours?
If you look at the leveling or hiring guidelines for any major tech company, what separates “senior developers” and up from mid level developers are system design, “handling ambiguity”, leadership, “scope”, “impact” and in the case of Google did you write a messaging app.
Even the largest tech companies realize “coding ability” only gets you so far and most developers who want to get ahead would be far better off focusing on the other aspects of software engineering.
System design, handling ambiguity, scope and impact are all things that are taught extremely well by just coding a lot. I'm not even sure why you are arguing. Someone who does something more and likes doing it in general will be better at it then someone who spends less time on it and doesn't like it.
So how do you learn “system design” - infrastructure, proper data storage for the problem domain, balancing the trade offs between costs, RPO and RTO, security, caching, sharding to handle scale, scaling, disaster recovery or the stereotypical “how would you design Twitter” System Design tech interview.
Coding has little to do with handling ambiguity.
While I have never been through a BigTech coding interview, I have been through (and passed) a BigTech system design interview, it has little to do with coding.
Designing (and redesigning) systems for large organizations is my $DayJob where I have to be able to explain those concepts.
I would like to see any form of objective evidence for “if you're actually a talented engineer these languages will hamstring you and your art”.
Even in C that lacks any form of sane abstraction capabilities, people have come up with object systems and what not if they fit a problem domain better. While I think that the language optimum is well past C, there is no significant difference between modern managed languages in any way besides ecosystems — and that is the most important thing.
Because the average Erlang developer is probably a better developer than the average in those languages and still quite capable of writing in any of those languages, at least with a little study and practice.
Are we really to believe that the average Javascript developer is going to be able to be dropped in an Erlang shop (or any of the other "weird" languages) and be productive any time soon?
The “language” is the easy part. Every language has an ecosystem around it and foot guns and best practices and frameworks. Take C# for instance, sure the language is decently easy. But, the first and third party frameworks around it are huge.
I’m sure I could (re)learn Java that I haven’t touched since shortly after it was first introduced in the 90s in a few weeks. That doesn’t mean I would be a competent Android developer.
The average JavaScript developer would be an idiot to ever step foot in Erlang shop if he knew what was good for his career.
My resume was sacrosanct when I was in the enterprise dev world until mid 2020. Why would I reduce my optionality by not using the most marketable technologies?
It seems like a case of different incentives for different people.
If the incentive is to ship product then choosing the language you already have a team for makes the most sense.
If you are choosing based on hiring a new team, then the current flavors work. 20 years ago that was Java. Today it's C#. 20 years from now it'll be something else.
If you are a developer looking to grow a resume for the next job, then it's a double-edged sword. Sure it's easier to get a C# gig. But it pays less because you're in a bigger pool. It's harder to stand out. Conversely it's harder to get say a Cobol gig. But it's easier to build a profile in the Cobol community (simply by being under 80 years old) and there is a Lot of work around, and is very well paid.
Equally something that's marginally popular now will have a long tail and can be very lucrative. Erlang might be obscure, but there are plenty of shops who would love to pick up another experienced, capable, erlang developer. You're a bigger fish in a smaller pond.
So yeah, language is like most things, dependant on your point of view. That's why we gave so many of them.
20 years ago, Java was already becoming pretty big in the enterprise. Today there are plenty of Java jobs from your bog standard banks and insurance companies all the way up to the BigTech companies. The biggest ponds don’t have fish using Erlang.
BTW, what languages do you think all of those BigTech companies that pay well are using?
I just keep bringing up C# because that’s the language I have the most experience with. But substitute $any popular language.
Erlang might be slightly more obscure, but there are plenty of big household names using the language - Klarna, Bet365, and William Hill are all household names. And that's excluding the obvious cases of Ericsson or WhatsApp.
I don't think it's always easy. it's been quite a struggle becoming proficient in Haskell, just drinking from the firehose of type theory you need to get things done.
also note that Jane Street does everything in OCaml. I can't believe it's bad for their employees' careers. probably because they're not looking for the same jobs as the average JavaScript pleb.
I would be more likely to hire a JS dev if they have Elixir experience not less, but I am not in the enterprise world.
Work is not only about money for me. My best work environments have been a small team of skilled people tackling a big problem. For this we would use whatever is the best tool for the job, regardless of its outside popularity.
The language is only easy if you have basically learned the language already. Java, C#, C++, Python, Go etc. all differ but fundamentally they are all the same language with different amounts of window dressing. So yeah if you know one of them it's easy to "learn" the others. But I wouldn't really call this learning a new language.
It's a fundamentally different ask to learn Haskell, datalog, SaC. You are actually learning a new language instead of just the flavour of the week imperative programming.
The last time I had a job where I only had to learn “the language” to be effective was 1999 programming in C and FORTRAN on VAX and Stratus mainframes. By 2000, “knowing C or C++” didn’t do any good without knowing MFC, COM, etc.
What good is a language in 2022 without a complete ecosystem of frameworks for most jobs?
Haskell is not particularly esoteric, but heavily opinionated.
Libraries cannot change that basic fact - there are just problems it will be extremely unsuited for.
Java has some of the same problem by the way in reverse. (Package handling, forced garbage collection and unknown real time and memory usage characteristics.)
The difference being that Java's core has much less important opinions about algorithms, while Haskell tries to make everything functional or it is awkward.
So, while Haskell will be hard to use for problems best described in an imperative way (in addition to other issues say Java has), Java will only have serious problems where memory and runtime determinism are paramount.
It so happens that a lot of the programming is done in imperative way. Including the libraries.
Say I’m developing an application that needs to interact with cloud services.
The last time the third party Haskell SDK for AWS was updated was in 2014. I do see a third party GCP SDK. But if GCP and Azure works like AWS, as soon as a new API is released by a service team, all of the officially supported SDKs automatically get updated.
I am sure there are other service providers that have SDKs and code samples for popular languages.
I believe the list for GCP and Azure are about the same. What are the chances that your problem is such a special snowflake that it can’t be solved with one of those languages? What are the chances that any new developer could ramp up faster or already knows Boto3 (the AWS SDK for Python)? If they have an issue, they can go to StackOverflow or raise a ticket with their TAM.
Which would have more assurances are designed correctly, the one from the vendor or yours? I was able to take advantage of new APIS for one of AWS services the day it was introduced, no need to waste cycles on creating my own wrapper. Creating a wrapper around my cloud providers APIS, “doesn’t make the beer taste better”
AWS’s SDKs automatically take care of retries, exponential back offs, wrapping the APIs to be idiomatic including logical exceptions being thrown, any underlying changes, etc.
> How much more “productive” do you think they would be just by being able to import a module in any of the supported languages?
The same language? Maybe a few % considering a client is a small part of what you need to create. A different language? Depends on the comparison. I would be tens to hundreds % more efficient in Haskell then in Go or Python.
> I believe the list for GCP and Azure are about the same. What are the chances that your problem is such a special snowflake that it can’t be solved with one of those languages?
Of course it can be solved in those languages. I can also solve it in Assembly or brainfuck with enough elbow grease. What matters is speed of implementation and correctness. With the exception of Rust all these language have debilitating flaws.
> Which would have more assurances are designed correctly, the one from the vendor or yours? I was able to take advantage of new APIS for one of AWS services the day it was introduced, no need to waste cycles on creating my own wrapper. Creating a wrapper around my cloud providers APIS, “doesn’t make the beer taste better”
> AWS’s SDKs automatically take care of retries, exponential back offs, wrapping the APIs to be idiomatic including logical exceptions being thrown, any underlying changes, etc.
Did you ever try openapi generated clients? They can handle retries and exponential backoffs as well. There is no design to be done here. It just exposes the API as designed.
None of the cloud providers provide the internal specifications used to autogenerate the SDKs for the languages I listed. In the case of Boto3 (the Python AWS SDK), while there are one to one generated mappings from the spec, there are also higher level constructs for the most popular services like S3 and DynamoDB and also helper functions like Waiters for asynchronous operations where you need to poll for an operation to be complete and Pagers that handle get request where the requests are being polled. Sure you could do all of this yourself. But again, “does it make the beer taste better”?
This isn’t meant to be a rah rah AWS is the bees knees. It’s just the cloud provider I know the best (and the one I work for), I’m sure knowing MS, the developer experience is just as good as AWS. I just don’t have experience with it.
> Of course it can be solved in those languages. I can also solve it in Assembly or brainfuck with enough elbow grease. What matters is speed of implementation and correctness. With the exception of Rust all these language have debilitating flaws.
What’s the old saying about it’s a poor craftsman that blames his tools? If you can’t be productive in any of the nine languages that are popular enough to be supported by the major cloud providers, does that say more about the tools or the craftsmen?
If the language is the hard part, something is wrong with it.
Usually. I've seen and user a whole slew of opinionated languages, and they almost always have a big chunk of problems they will be awkward to use for, or even almost insoluble.
Every succesful one supports multiple programming paradigms, better or worse, usually decently.
Now the real stuff that can cause problems is bad tooling and lack of support. You cannot code your things when you're trying to fix the compiler, build tools or the debugger.
And I assure you that someone who needs an Android app written wouldn’t care about your distinction or are you claiming that a Java developer who never wrote an application for Android would be just as effective as one who had?
Who would you rather lead the development of your Android app? Someone with no experience with Android or someone with previous experience.
That depends on the team leader and how well they can take suggestions. It's a team, not everyone will have the same background and, probably, nor would it be best that they did.
So if the team lead that I’m hiring to be the subject matter expert can’t be the go to person for technical solutions based on relevant experience in the domain, who should it be?
a) the most experienced amongst the team in any particular language
b) the most experienced amongst the team in any particular domain
c) the go-to person for any particular problem
The whole point of a team is to cover several different sets of knowledge and experience because no one person can know it all or do it all. A leader does their best to enable this collective to produce the best it can.
Conversely, if you spent 3 years writing Erlang, you are suddenly not one of a hundreds of thousands of candidates, but a part of a much smaller pool, and having an expertise in a semi-esoteric language along whatever mainstream languages you know is a strong signal that you’re not just an average bear.
It also means you’re competing in a much smaller market and people looking for strong Erlang developers will be suddenly very interested in you specifically, because it’s tough to find strong candidates with this expertise.
It also might mean (depending on your interests) that positions that are open are in a more intellectually interesting problem space, because boring problems tend to be solved in the lowest common denominator languages, and if an unusual language is chosen, it might be chosen because it’s a being used in a unique context.
Ok, but do you really think you’d have a hard time finding work with your xx years of experience, regardless of what language you have been most recently working in?
As in, reductio ad absurdum, “if only I had been working in Java, I’d be safe, but because I worked in Ruby, I am going have to go flip burgers, as no one will let me near their precious production code now?”
I mean, yeah, ok, there was the dotcom bust, and I suppose another could happen at any point, but somehow I get the impression that you’re arguing that using any language except the most mainstream option (whatever that might be for a given industry) is too risky? Or am I misreading?
Well, I wouldn’t have a hard time finding a job in my current speciality cloud architect/cloud dev because of where I work and what I do. No one would ignore my resume.
But in the boring enterprise dev world where I came from especially during the latter part where I was specifically being hired to lead initiatives, of course they wanted someone with relevant experience.
From my experience the shops using esoteric languages aren't recruting based on knowledge of a specific tool. They're hunting for very experienced candidates. It's assumed you'll learn the language. Knowledge of a specific language does not necessarily mean you're a good developer.
And why would an “experienced candidate” ever step foot in those shops when they could easily get a job using a more marketable language that probably paid just as much and would make it easier for them to get their next job?
Because that "marketable language" is dull and frustrating?
If you want top talent then you've got to offer something they want; sure you can always pay more, but past a certain point that might not be enough, plus it gets expensive. Using better languages is one of the most effective ways to get noticed by the candidates you really want.
It’s more frustrating to want to leave a job and not be able to find one quickly because your experience is in some obscure language.
When I was in the Enterprise/Corp dev world until a couple of years ago, I could call a few recruiters and have 8 interviews and two or three offers within less than a month. It’s easy to pattern match when you use a popular technology.
Ehh maybe. Sure, if you use a bland corporate language then you can pick up a bland corporate job whenever you want. But what's bland corporate job B going to give you that bland corporate job A didn't?
Taking a dull job so that it's easier to change to a better paying dull job doesn't seem like a great tradeoff to me. Bullshit definitely happens but again, dealing with a crappy language's bullshit from day 1 so that it's easier for me to switch to another job that will definitely have at least that floor level of bullshit doesn't feel like a great option.
The biggest companies largely use dull languages, sure, although you sometimes find pockets within them that are doing something at least a little nicer (e.g. OCaml at Facebook). So much the worse for the big companies.
You saw my original spiel about going to work to exchange labor for money? I don’t go to work to find excitement. I go to work to provide food and shelter.
My excitement during the first decade of my career came from my working hobby as a fitness instructor and running with friends. In less than a month my “excitement” is going to come from my wife and I living out of two suitcases flying across the country staying in mid tier hotels for a few years.
I could spend my free time learning a new programming language. But I am finding it much more “exciting” learning Spanish so when we stay in Mexico for a few weeks, I can at least be able to communicate somewhat.
If you want a job you can easily switch for an equivalent job, which seemed to be your pitch for using a boring language, then that job is at best going to be a 9-5, which will take up something like half your waking life (at least for the decades when you're the most healthy). I'm a big believer in life and hobbies outside of work (and when I want to learn a new programming language, I look for a way to do it on the clock), but an engaging, interesting job that pays less is often a very worthwhile tradeoff.
I went the other direction. Took a job that paid half as much as my previous one, but it's interesting work, and I'm a lot happier. Grass is always greener I guess.
Because comp is similar and it's fun. Plus I fail to see how working in a less popular language hurts future job prospects. If anything my experience with less popular languages usually leads to a fairly lively, informal discussion during interviews.
Because when you throw your resume out there and a hiring manager is looking for a “full stack developer who knows (Java || C# || Python) && Typescript” why would he choose you over someone who could hit the ground running and add immediate value?
Probably because I'm competent and there is more to adding value than memorizing specific tech. I can't speak to your experience, but as far as mine goes I've never had a problem landing a job.
I'm zero worried about it as it's never been an issue.
To be fair I have no idea about the full stack life. I, however, am also not convinced they add "immediate" value. Once you're beyond mid-level being a so-called generalist is not as useful. Most of my work at high senior, and now staff level requires actual deep knowledge of the preferred stack. I have yet to meet a reformed full stack developer in our ranks and there are tons we hire, and even more that come through the door.
I don’t touch the front end development. But I am very much a “generalist”.
- back end development in a few popular languages
- about an average “data architect” for lack of a better word. I’ve led implementations on every type of database imaginable including ETL type jobs and online systems.
- “DevOps” (at least if you give me an AWS account) including setting up networking infrastructure, logging, monitoring, CI/CD, etc.
I’ve led plenty of pre-sales meetings, writing SOWs, pretty PowerPoint slides and architecture diagrams etc.
The “generalist” is very useful when you need someone to lead projects and to understand how everything fits together. I’ve had to wear all of the above hats at startups. Now I wear those same hats at a cloud provider I’m sure you have heard of. I specifically targeted my current position because I wanted to be a generalist.
I’m no special snowflake. Many of my coworkers who came up the ranks in startups and have similar experience can do the same.
I have “prior experience” in any many languages. But I know the ecosystem has changed to the point where someone who has recent experience would be more valuable. That would be like me (hypothetically) saying I had prior experience in JavaScript from a decade ago and I can write JQuery with the best of them.
An organization that prefers ecosystem knowledge to deep knowledge and ecosystem familiarity hints at poor planning and needing someone to "hit the ground running" to fix their mistakes.
I'd pass on such a position.
Also you talk about only having experience in a less popular language as a death sentence.
I've been only writing Haskell professionally for a decade, but I get endless amounts of interview invites for prior experience.
Out of curiosity I went through some of the better invitations interview process and had no issue getting offers either.
If anything mentioning my professional Haskell experience gets me an offer faster no matter the positions requirements.
If a company is looking for senior developers who are to serve as team leads and lead initiatives, why would they hire someone without previous experience in the technology? I’m sure you could eventually get up to speed. But the reason I haven’t had to do a coding interview in well over a decade of working at companies from your standard Corp dev jobs, to companies where they wanted a “tiger team” to lead green field initiatives, to a startup where the then new CTO was looking for someone to lead “cloud native projects” to my current job in the cloud consulting department at BigTech is because I knew the ecosystem well.
When I spoke to CxOs and directors, they wanted someone with a proven track record that could solve their problems. When I was being hired as a dev lead to lead junior C# developers he inherited, what would he look like hiring someone who knew Haskell?
How was i suppose to go from an empty git repo to a fully fleshed out MVP or later from an empty AWS account to infrastructure, CI/CD, to a fully fledged out MVP if I didn’t have prior experience?
If someone is looking to create a new iOS app. Who should they hire? Someone with iOS experience or someone with Erlang experience?
I personally would be hesitant to hire someone who only listed popular technologies on their resume. I’d be worried they would suggest using technologies that improve their resume rather than ones that are good for my business.
Your business is probably not a special snowflake and probably would be served by using the most popular relevant technology. It would be much easier to recruit and to find help.
I personally hate the clusterfuck of the modern front end ecosystem and would avoid it like the plague. But, if I was responsible for choosing the framework to use, I would choose React any day just for recruitment reasons.
> C#/Java JavaScript/React developer to push out some CRUD SaaS app or line of business app?
Because of this: "The Python Paradox" [1].
Replace Python (which has become mainstream in the meantime) with any other "weird" language from the article and I think the point still stands.
If it matters I had started learning Python just about when this article was being written/published, and in my early to mid-career that advice of using a "weird" language (Python, at the time) was really good for me, got me into a couple of small companies where I really enjoyed working.
Granted, now I'm already over 40 years of age with a mortgage to pay, I'm a little more flexible when it comes to the technologies being used (even though I would cry myself to work in the early hours of morning were I to use Java, and I'm not kidding), but for people who are quite early in their careers letting them explore and use those "weird" languages will still do them a lot of good in terms of them enjoying their programming work, they might even land on a forum written in Arc.
People early in their career are the last ones that should do anything in obscure languages. Most of the time the biggest leap in salary comes in your first few years. Once you break the can’t get a job <-> don’t have experience cycle, you need to be able to jump ship.
When I first started in my career over two and a half decades ago, my focus was on being able to be aligned with the market and being able to support myself. I was young, single, had no responsibilities and just moved to a major city. The last thing I considered “fun” was programming.
Yes, you leave money on the table if you do that (I know I did, I have friends the same age as me who earn a lot more than I do because they went the non-obscure language path early in their career), but at the same time you also bring some purpose into your professional life, which cannot be entirely bought with money.
Or maybe I was the weak one when I didn't see myself programming in something like Java for a living for my entire career (30 to 40 years), again, that would have literally caused me to cry before going to work, in which case, yes, those persons that can surpass that type of feeling should definitely go for the "more money/less interesting programming stuff" route.
Well, I restarted my career in 2008 after staying at my second job for 9 years and becoming an “expert beginner” - I was doing VB6 (discontinued in 2001) and C++/MFC (Windows). After the struggle I had finding another job when I was ready to leave, I said never again. I completely concentrated on technologies that were marketable.
By 2016, I knew I didn’t want to be “just a developer”. I enjoyed working with customers, leading projects, mentoring and teaching. But I still wanted to stay hands on
I belatedly discovered “the cloud” and realized I wanted to specialize in true “Devops” bringing developers and operations together and working with companies to show their developers how to be “cloud native” (application modernization)
When $BigTech came calling about a pure software engineer position, I really wasn’t interested. I kept talking to the recruiter and she told me about a cloud consulting position where I would be able to be involved in the full life cycle from pre-sales, to delivering a finished product including infrastructure. I jumped at the chance.
I'm not sure what you're suggesting.
Are we expected to rewrite everything every decade when a new flavor of language comes out?
It seems like, with the exception of Rust, you've named a lot of "lowest common denominator" languages. These languages, while productive, tend to lack expressiveness. It is my opinion that expressiveness is seen as a bad thing in the "professional" community because it takes significant cerebral evolution over the course of a career to learn which tool in the toolbox to use. In other words since the explosion of programming as a career there are more idiots in the proverbial gene pool, and so more companies prefer more idiot-proof languages because the average developer can't help but hurt themselves. This doesn't mean we should prefer "new safe technologies", it means our recruiting should far more stringent and our education far more formal (as in an actual useful programming degree).
I for one would quit if I could program, for example, common lisp and make even 3/4 of my current salary.
Here's, in my opinion, a better and less controversial hot take. Use what works. If you have a team of erlang developers do it in erlang (or whatever). Who cares about the market. If it means spending even more time (and money) learning to write another more popular language correctly it may not be worth the investment. If you build it, they will come. You will have no problem finding an endless stream of developers you can build from the ground up.
As a side note: Kotlin, Ruby, and F# are extremely popular. TIOBE is not a real measure.