Normally we'd merge the comments into the main thread but nearly all of them here are about the title of this one.
(Currently reading https://www.manning.com/books/functional-programming-in-c-sh... and greatly enjoying it)
But I guess 'developers love trendy [programming] languages' is like saying 'teenagers love trendy teenager apps'. aka, if developers love the language, then it pretty much is by definition trendy.
What isn't represented to remove a bias from the numbers is the number of years of experience and education. It's highly unlikely that bootcamp graduates will be working in OCaml/Erlang since these will bias to people with CS degrees who understand the why behind functional.
More accurate conclusion:
If you didn't explicitly control for it, your results probably only reflect selection bias.
For instance, let's a dev with a really unremarkable resume gets paid significantly less than his coworkers in a really hot subfield because all his coworkers have a top-10 stem degree, research with top professors, and work experience at really hot startups. It's likely if he is a decent negotiator the underpaid dev's compensation will eventually revert to the mean. That will be the compensation of an extremely marketable dev if he can sell himself as a dev with really valuable experience.
we've placed a good amount of functional engineers from a Math, Physics, Logic sometimes even Biology background that had a strong affinity for functions and found OOP generally painful.
I think it's that functional programming is more of a niche with an even more disparity between demand/supply regarding the salaries.
Oh, and usually HR people have a pretty bad filter when it comes to functional engineers, so they only filter by keywords
Edit: oh, finance. Right.
It is still overwhelmimgly dominated by C++ and core Java with some Python in there too.
It's shocking to me that people would blame the invention of the idea. I think talking about unethical ways of doing business before they're adopted is useful, because it gives society a chance to frame the debate and possibly even criminalize the behavior before entire companies depend on it for their business model. Most unethical business behaviors are semi-obvious anyway, in the sense that they're going to occur to many people right away rather than waiting on a genius stroke of inspiration that might come this year or five years from now. If you think of an unethical idea at work, odds are that five other people are already thinking of it too, and one of them is planning how to implement it. Seize the initiative. Talk about the idea and frame it as evil. Make it a joke among the engineers. "Of course if we were really evil, we could do X." "Nice, what a way to fuck our customers over and make money from it." "Not that I could actually bring myself to do it." "Where's Martin Shkreli when you need him?" (Reference a company that went down in flames, a person who went crying to prison. It doesn't matter if Facebook or Mark Zuckerberg is a better comparison; don't mention a company with a thriving business or a person making bank with impunity. Success gives everything a halo.)
If you do this effectively, then the company has to consider the cost of embracing an idea that has already been framed as evil. They'll have to consider that they won't have the most enthusiastic cooperation from some of the engineers, that it will decrease people's pride and job satisfaction, that some engineers who have other opportunities might decide to leave so they can still be proud of their work. They will have to consider morale outside of engineering as well, because people in other departments will be saying, "What is the deal here? The engineers seem to think that what we're doing is really slimy. Am I going to be embarrassed to tell my friends about this?" Management might still go ahead with it, but on the other hand they might decide to do something else instead. And if they do it, they'll at least profit a little bit less because of the friction you created.
While this has not been true in my personal experience, I must say that I've been very fortunate in life. I can totally understand and see how this may be true for some programmers.
I wonder if, as an industry, there was a better way for us to handle such situations.
I live in a market where finding a job quickly makes it another shitty job, and only after amply signaling your submissiveness (ah, Europe). You get no unemployment money, because it's you who quit, of course.
There's also the fact that you're the good guy and yet you're the one getting shafted, while the arses above keep doing what they do. Anyone with a brain will sense something's wrong, and will rethink their ethics.
I may agree that it is not a convincing argument for anyone, doing any job, but I'm not sure the programmer part makes any difference.
Moving isn't realistic within the span of a week. Remote might be an option, but brings its own challenges.
I see that React is also a niche, but it a rather less narrow one than most.
Don't know about F# but the job market for OCaml consists of about 2 companies. What good is high average when you can count job openings on one hand?
I like OCaml, I wish it was more popular.
and some of the ones on the trendy list are functional (Rust)
Rust does have a lot of features that a lot of other functional languages have, Algebraic Data Types, closures. But one thing Rust misses is purity. Although you do have to be explicit about when you are mutating state, I think it would be very hard to actually write a program that doesn't, and it certainly wouldn't make for idiomatic Rust code.
I guess we are going into the definition of what makes a language functional. Rust is a great language and it does attempt to solve the same sort of problems that functional languages solve - multi threading, no surprising mutations.. It just uses a different paradigm to functional in order to solve them.
Modern OO has adopted many things from FP, but I'm sure there's an old Smalltalker waiting in the wings, ready to come out and observe that a lot of this is equivalent to Renaissance Europeans rediscovering a lot of ancient Roman texts by reading their Arabic translations.
My baseline for a "functional language" is ML; wikipedia's description of it opens "Features of ML include a call-by-value evaluation strategy, first-class functions, automatic memory management through garbage collection, parametric polymorphism, static typing, type inference, algebraic data types, pattern matching, and exception handling." Kotlin notably has all of those, and equally notably doesn't really have any other central, language-defining features (with the possible exception of delegation); in many ways the core languages is no more or less than ML.
> Modern OO has adopted many things from FP, but I'm sure there's an old Smalltalker waiting in the wings, ready to come out and observe that a lot of this is equivalent to Renaissance Europeans rediscovering a lot of ancient Roman texts by reading their Arabic translations.
Disagree; these ideas are not borrowed from Smalltalk, they were present in ML (ML and Smalltalk are contemporaries but quite independent of each other) which retains its own distinct lineage. Scala and Rust are openly of ML descent, and I think Swift also acknowledges an ML influence.
Moreover, as far as language-defining features, it's hard to ignore how OO the type system is. Working with Kotlin, you won't be dealing exclusively with algebraic types and modules; you'll be dealing heavily in classes and interfaces and extension methods and all that.
For similar reasons, I hesitate to call Scala a true ML descendant. It takes a lot of obvious inspiration from ML, but the standard libraries are all intensely OO in their idiom, the type inference is still quite limited, etc. You can program in a very functional style in Scala if you want, but Odersky is pretty explicit about that not being what he was really about, and if you want to have a good time of it you'll want to be importing Scalaz or Cats rather than relying too much on the standard libraries.
It's especially disappointing that the supposed reason was it was "too complex"
Markets have weird corners that move over time and for a while I made all my money doing React.js work. I make more than all of my peers, probably because I have a great portfolio, another correlation-but-not-causation. But does it really surprise anyone that the 24 year old who read Haskell books instead of netflix-n-chill, grew up to find more competitive opportunities?
I did eventually break through the freelancing rate ceiling by building a Clojure ecosystem product and offering product-related consulting now.
More seriously, I think at this point it really is dominated by the Jane Street monoculture. Which is getting to be worrisome, because it means that the ecosystem is getting to be pretty optimized for the needs of a trading firm. ML was also originally designed for writing new languages (it stands for MetaLanguage), so it stands up well there, too, but I think that SML might still be more popular for the purpose. And a lot of "trying new ideas" stuff has moved to Haskell because the compiler is so easy to hack on.
With the same reasoning management could say that ethics is the responsibility of investors who decide about how ethical a company should be and customers who may pay for the non-ethical product.
58.5% would not write code for an unethical purpose, and only 4.8% would unconditionally say yes. 79.6% think that they have to consider the ethical implications of code they write.
The 57.5% who said that management is most responsible for ethical decisions would probably agree that developers are responsible as well, just maybe not as much as management (who have far more agency to just assign the task to someone more willing if anyone refuses). Since the options were limited to be mutually exclusive, those considerations were not captured by the survey.
Young FP adepts, especially converts in their early 20s, especially those who are "in trend", are a pure disaster.. don't pay them too much..
Developers love trendy new languages (like C and Basic), but earn more with Cobol.
C and Basic... trendy? One doesn't often see those words in the same sentence. Or is this like bellbottom trousers, where I've waited long enough and they've come back around to fashion???
Those developers also have valuable knowledge of the systems they work on, something new Cobol developers won't have.