> The downside of Clojure is that you need good, wise developers...
Is there a language that, for a sufficiently large application, you don't need wise developers? What is it? How?
Is there a language that, for a sufficiently large application, you don't need wise developers? What is it? How?
I've written C, C++, C#, Java, JS ES5+, ActionScript, HTML5 and CSS since IE6, many various compile-toJS languages, many different frameworks and more. Elm is the only language where I can jump into a foreign code base or my own months later and feel confident that I can change something, push to production, and not break things.
edit: I've also written Perl and Ruby in production too.
edit2: How does it help? When you make a change that isn't valid, like adding a new argument to a function, the compiler can tell you everywhere you need to make a fix and sometimes even suggest how to fix things. Add on top of that the editor tooling in Intellij or with the elm-langauge-server in VSCode and other editors and it's just super smooth. Build times are also crazy fast. There's no waiting for the compiler. The whole notion of "If it compiles, it works" I find to be true 99% of the time.
You literally posted that using a statically typed language prevented breaking changes?
I can say from experience for every language above, save C++ (with which I have never worked), that they will fail to compile if you change a function signature in a backwards-incompatible way and fail to update all call sites.
The purpose of static typing as a method of program verification is to enforce type constraints at compile-time for all possible executions of that program. A function signature is, you guessed it, a type constraint.
"The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt." [1]
[1] https://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Fr...
Basically I think that Go makes it easy to open and read almost any file, regardless of what you know about the rest of the project. I think that's great, but I also don't really think that it prevents you from building bad software.
Fixed it for you
Certainly not when they are spending hundreds of hours writing the next great LRU Cache or Bubble Sort so they can pass interviews every other year.
I think that Java might have benefited the most from the industry hellbent on making microservices, in that Java applications are less frequently built as gigantic unmaintainable messes, but instead much smaller more easily digestible messes.
I am clearly biased against Java, but having worked with it at several jobs I just don't think it's a good idea.
Java is weak in small scope and gets stronger with larger applications as it scales quite well in maintainability.
In that sense adoption of microservice has hurt Java since you still need to do a lot of Java ceremony, tomcat + spring boot still starts up slow, you can't leverage superior IDEs to refactor interfaces across services etc.
For thin microservices I would probably tend to use something like node.js, for traditional monoliths (IMHO still have their place) with a lot of complex logic I would use Java (or Kotlin, C#).