3 ms·

All the currently successful languages became so because of their universal character: you can write server, a GUI app, or code a ML library that implements a n

by nnq 14y ago

All the currently successful languages became so because of their universal character: you can write server, a GUI app, or code a ML library that implements a neural network in either C or C++ or Java - they all offer the balance of abstraction tools and performance needed to be universal. The proper tool for the task way is pushing things backwards! By going this way you're running towards a brick wall, the wall of your limited brainpower: at one point you will not have enough brainpower to keep juggling the increasing number of "proper tools" and you'll have to stop growing, stop learning and enclose yourself in warm niche/bubble. Yeah, this is exactly what your manager wants - you'll become a good but replaceable "programmer specializing in X, Y and Z" instead of the "uncathegorizable freak" that embeds a Scheme interpreter only he understands in his C++ code, can do in a day what the rest of the team does in a month, but that may bring the whole company close to bankruptcy if he's hit by a bus because, well ...nobody can replace him :) "Universal" tools are always better overall even if they are worse for every particular situation you can imagine because the "problem space" in software is expanding. I an "all is open-ended" world universal tools are the only to avoid being trapped in a "bubble" (yeah, you may have warm and cozy in a "web dev with rails" bubble or "frontend dev in javascript" bubble, but you're still in a bubble!).

venomsnake 14y ago
Let me get this straight - the guy that can write high performance scalable async code in erlang/go for the backend, design snappy and responsive UI in javascript or C# and modeling/analytics/stat tools in R,Haskell,Python all with easily defined and usable and language agnostic interfaces is easily replaceable living in a bubble, but write all of this only in Java and you are a programming god? The pipeline was what make Unix great - the ability to chain different small stuff together. Huge monolithic is something I dislike. Personal taste.
- nnq 14y ago
  I don't mean monolithic, I mean homogeneous / not heterogeneous. The Unix way was great while all the tools were written using a small set of languages and techs (C, Bash, maybe C++ here and there...) because a guy with a certain set of skills could just pop the hood up, get the code, and delve into the guts of any program... now you have "shit, I chose Ruby but that cool lib is Python" or "why is that huge Perl script used to configure and start this Erlang program?". By "Java" (bad example, I agree) I mean any multi-paradigm, multi-platform, general purpose language: it can just as well be Scala on the JVM or Python if its performance is good enough for you and you can put up with the way it annoys you out of your mind if you try to do functional programming in it. All languages claim to be so now but in practice they are not! If you use Haskell for something, Erlang for something else and integrate with some R code by means of some Python or C code, you pay a huge price in increased complexity and you'd better make sure the advantages given by using "the right tool for the job" are worth this price... If you can master the kind of polyglot skills you talk about, great, you're definitely not in a bubble, but this is because you are one of the top 0.1% in terms of "brainpower", not because you used you bp efficiently - imagine what you could do if all the mental energy spend understanding all the little tech details for all those things were focused on solving just one problem and with a smaller number of tools!
gyepi 14y ago
>By going this way you're running towards a brick wall, the wall of your limited brainpower: at one point you will not have enough brainpower to keep juggling the increasing number of "proper tools" and you'll have to stop growing, stop learning and enclose yourself in warm niche/bubble. I couldn't disagree more with this statement; it seems to me you have this backwards. The purpose of "proper tools" is exactly to encapsulate the complexity and provide a simpler interface with which we can address the problems. In fact, as the level of complexity rises, you need tools that provide the right level of abstraction. In many cases, those tools are specialized because they address specific aspects of the problem. Each such tool pushes out the boundaries of our limited brain power. For instance, I use a lot of code generation in my work. A complicating factor in code generation is the fact that you are working at two or more levels simultaneously; the code generator and the target language. However, with the proper tools, the problem becomes very tractable. In this case, I am referring to explicit code generation, but exactly the same issues arise when generating code with Lisp style macros. As to the universality of languages, I can only say that the practice gives lie to the theory. Once you've used enough languages, their differences (and fitness for particular problems) become clearer.

by nnq 14y ago

venomsnake 14y ago

Let me get this straight - the guy that can write high performance scalable async code in erlang/go for the backend, design snappy and responsive UI in javascript or C# and modeling/analytics/stat tools in R,Haskell,Python all with easily defined and usable and language agnostic interfaces is easily replaceable living in a bubble, but write all of this only in Java and you are a programming god? The pipeline was what make Unix great - the ability to chain different small stuff together. Huge monolithic is something I dislike. Personal taste.

nnq 14y ago
I don't mean monolithic, I mean homogeneous / not heterogeneous. The Unix way was great while all the tools were written using a small set of languages and techs (C, Bash, maybe C++ here and there...) because a guy with a certain set of skills could just pop the hood up, get the code, and delve into the guts of any program... now you have "shit, I chose Ruby but that cool lib is Python" or "why is that huge Perl script used to configure and start this Erlang program?". By "Java" (bad example, I agree) I mean any multi-paradigm, multi-platform, general purpose language: it can just as well be Scala on the JVM or Python if its performance is good enough for you and you can put up with the way it annoys you out of your mind if you try to do functional programming in it. All languages claim to be so now but in practice they are not! If you use Haskell for something, Erlang for something else and integrate with some R code by means of some Python or C code, you pay a huge price in increased complexity and you'd better make sure the advantages given by using "the right tool for the job" are worth this price... If you can master the kind of polyglot skills you talk about, great, you're definitely not in a bubble, but this is because you are one of the top 0.1% in terms of "brainpower", not because you used you bp efficiently - imagine what you could do if all the mental energy spend understanding all the little tech details for all those things were focused on solving just one problem and with a smaller number of tools!

gyepi 14y ago

>By going this way you're running towards a brick wall, the wall of your limited brainpower: at one point you will not have enough brainpower to keep juggling the increasing number of "proper tools" and you'll have to stop growing, stop learning and enclose yourself in warm niche/bubble. I couldn't disagree more with this statement; it seems to me you have this backwards. The purpose of "proper tools" is exactly to encapsulate the complexity and provide a simpler interface with which we can address the problems. In fact, as the level of complexity rises, you need tools that provide the right level of abstraction. In many cases, those tools are specialized because they address specific aspects of the problem. Each such tool pushes out the boundaries of our limited brain power. For instance, I use a lot of code generation in my work. A complicating factor in code generation is the fact that you are working at two or more levels simultaneously; the code generator and the target language. However, with the proper tools, the problem becomes very tractable. In this case, I am referring to explicit code generation, but exactly the same issues arise when generating code with Lisp style macros. As to the universality of languages, I can only say that the practice gives lie to the theory. Once you've used enough languages, their differences (and fitness for particular problems) become clearer.