Isn't it usual to quote something interesting a person says and then provide the context in which they are saying? I see the headline quote at the top, and then halfway down the page in its own box, but nowhere in the actual article?
If I click on a headline that interests me it'd be nice to actually see some discussion of it.
Closest I can find is "But I quickly got the hang of it because I knew all the important concepts from other languages and frameworks."
Reminds me of a song by a band named Clinic: IPC Subeditors Dictate Our Youth.
A caustic reminder of effect on the reader, not of the content of the article, but of the headline and pull quotes which are considered part of the editorial domain.
Amusingly the song title had nothing to do with the lyrics of the song.
I'll admit to finding a guilty pleasure in the usual, "Why Rust is Awesome and Go Sucks" blogtrash... when the content actually DOES reflect the title. However, when someone slaps an inflammatory title onto a piece that doesn't really even address that subject, it's the worst of all worlds. Makes me form a negative opinion of the author, of the hosting site, and in this case even of the person being interviewed (rightly or wrongly). Since the majority of people don't actually read the content, all of the comments just deal with the title anyway.
I think with all languages you can achieve more or less the same things. There are some languages that match better your way of thinking than others...it's just that. Every language can be fast enough, clean enough and have enough tooling to achieve your goal.
ps: I realised at some point that "java all the way", "haskell all the way", "php all the way" is definitely not the way :P
I read a post on here the other day that suggested good senior developers care about languages. I beg to differ and actually agreee with this quote more and largely believe that the languages are unimportant. It is more nuanced than that though and really depends on what you're working on.
If you're writing an app that's going to be able to run on a single small vm, you might as well write everything in the language your developer is most comfortable in and will deliver fastest with. If you have ten developers but 50,000 servers, you might want to pick a faster language, but the math is pretty simple, hosting costs vs development costs, what's greater?
Of course it's more complicated than that, because your ops guy can make a meal of the scaling, your java developer can write slow code, and your PHP developer can write efficient code (within the constraints of the language, of course).
For me the general problems with hiring based on tech is if you go for the new and shiney, you'll deal with people who'll never finish anything, and if you go with old and reliable, you'll get people who are slower because they aren't following resonable practices.
Most companies just need someone who'll deliver though, so there's nothing wrong with them picking old reliable $foo for everything, and I'd suggest your good senior developer shouldn't care about anything else than delivering, both long term and short, and if the advice is that everything needs to be rewritting in flavour of the month, I'd suggest said developer may be good, but they're probably not mature enough to be senior.
Here's the problem of a serious expectations mismatch in the industry. On the one hand, companies want someone who'll deliver, and they'll pick technology based on how cheap programmers you can find (reminds me of my ex-boss's answer to the question why won't they upgrade the tech stack - "well, we could go with something else, for example Ruby, but non-PHP programmers are too expensive"). Or they'll pick whatever platform upper-level management already decided to buy. On the other hand, a lot - if not most - developers learned the profession out of joy of programming (the recent trend of learning programming because of a career choice is a domain of the new generation). Learning something new, or using tools that are efficient and convenient, is an important part of the development process, because without enjoyment, developers burn out. Companies want to treat programmers as replaceable cogs. Developers think of themselves as artisans.
There are a half-dozen different groups of mainstream programming languages (and a bunch of oddballs). Within those groups, it's relatively uniform. Going between -- not the same.
Most people who make comments like this have only seen languages which differ in syntax, but many do differ in semantics.
Actually, I'd say mainstream programming languages differ more in syntax than in semantics. They're all ALGOL-like imperative, structured, procedural languages. Java, C# and Python might stick your objects on the heap while C and C++ might stick them on the stack, but the code looks and functions the same. And sure, some of these have classes and others don't, but it's not really a big difference.
Yes, one can be reductive to the extreme and lump all programming languges into a Turing Tarpit[1].
However, the more interesting comparisons happens above that level. There are real differences in the implied semantics, the lightness/heaviness of the syntaxes for common tasks, the division of labor between the programmer and the compiler (aka static vs dynamic typing, unit tests vs compiler error, etc.) A language with deep metaprogramming (Lisp, Ruby, etc) will feel different than a language that requires writing adhoc custom code generation tools to approximate the safe effect.
Discussion about languages at a layer above the Turing Tarpit means Lisp, Haskell, Prolog, C++, Python, Java, Bash, x86-assembly, BASIC, etc are all very different.
For an interesting dive into one formal definition of the expressiveness of different features, see [1]. It defines expressiveness of features by asking questions like (I'm really simplifying here) "If I add this feature to my language and start plugging it into programs that didn't use that feature before, can I write any programs that I couldn't before?"
This is a useful definition because a feature like an enhanced for-loop doesn't have global effects on the program if it's plunked into some local context -- the same program could have been written without it. But adding something like, say, exceptions does have interesting nonlocal effects, and allows for differently-shaped computations than before.
The useful point here is that the feature is added as an incremental change on an already-existing language, so its effects can be measured relative to the original language. The original and extended language can both be Turing-complete, and this is still a useful definition.
> 1936 - Alan Turing invents every programming language that will ever be but is shanghaied by British Intelligence to be 007 before he can patent them.
> 1936 - Alonzo Church also invents every language that will ever be but does it better. His lambda calculus is ignored because it is insufficiently C-like. This criticism occurs in spite of the fact that C has not yet been invented.
I realized at some point that all programming languages are the same.
I did bite for the click-bait title because I expected something tongue-in-cheek. But there's no explanation or context for that in the article.
A dubious quote, presented in the worst possible way, all that leaves a bad taste in my mouth. How can someone say such a thing without explanation and expect to be taken seriously?
Of course. Every single mainstream programming language looks and works like ALGOL, without exception. They all use structured programming (while, for and if instead of goto), are imperative (assign here, branch here, do some side effect) and are all procedural (programs consist of functions with side effects). They all have similar syntax with = or := for assignment, infix mathematical operations and block syntax. There are some minor differences (e.g. execution), and some of them have an OOP layer on top of this, but that's it mostly.
Now, are all programming languages the same? Most definitely not. Lisps exist, functional languages exist, heck, BASIC exists, to name some other language families. But all mainstream languages are virtually the same.
Nope, even the mainstream languages aren't the same. If their differences didn't amount to more than lipstick-on-a-pig there would only be one mainstream language. (JS is on the way there, so if we wait long enough we might still witness this mythical event)
> Nope, even the mainstream languages aren't the same. If their differences didn't amount to more than lipstick-on-a-pig there would only be one mainstream language.
How so? There's a lot of choice, but quite little diversity. There are more languages than there are big differences between them. You could combine Python, PHP, JavaScript, Lua, and Ruby, then C++ and C, then C# and Java. There'd only be 3 mainstream programming languages left, but you'd have lost almost no diversity.
Even with the differences between them, an algorithm implemented in any of them will look nearly identical.
Flow based visual programming languages, like Pure Data[1], are good examples of programming languages that really differ from the rest.
Interestingly, Pure Data is not all a fad (but neither a growing trend!).
In the art community, I have friends that are very proficient with Pure Data, using it for creating various visual and audio programs. A lot of them are still using it more than a decade after they first started.
31 comments
[ 3.0 ms ] story [ 85.3 ms ] threadIf I click on a headline that interests me it'd be nice to actually see some discussion of it.
Closest I can find is "But I quickly got the hang of it because I knew all the important concepts from other languages and frameworks."
A caustic reminder of effect on the reader, not of the content of the article, but of the headline and pull quotes which are considered part of the editorial domain.
Amusingly the song title had nothing to do with the lyrics of the song.
I'll admit to finding a guilty pleasure in the usual, "Why Rust is Awesome and Go Sucks" blogtrash... when the content actually DOES reflect the title. However, when someone slaps an inflammatory title onto a piece that doesn't really even address that subject, it's the worst of all worlds. Makes me form a negative opinion of the author, of the hosting site, and in this case even of the person being interviewed (rightly or wrongly). Since the majority of people don't actually read the content, all of the comments just deal with the title anyway.
Material like this belongs in a "spam" folder.
https://github.com/ghc/ghc
ps: I realised at some point that "java all the way", "haskell all the way", "php all the way" is definitely not the way :P
If you're writing an app that's going to be able to run on a single small vm, you might as well write everything in the language your developer is most comfortable in and will deliver fastest with. If you have ten developers but 50,000 servers, you might want to pick a faster language, but the math is pretty simple, hosting costs vs development costs, what's greater?
Of course it's more complicated than that, because your ops guy can make a meal of the scaling, your java developer can write slow code, and your PHP developer can write efficient code (within the constraints of the language, of course).
For me the general problems with hiring based on tech is if you go for the new and shiney, you'll deal with people who'll never finish anything, and if you go with old and reliable, you'll get people who are slower because they aren't following resonable practices.
Most companies just need someone who'll deliver though, so there's nothing wrong with them picking old reliable $foo for everything, and I'd suggest your good senior developer shouldn't care about anything else than delivering, both long term and short, and if the advice is that everything needs to be rewritting in flavour of the month, I'd suggest said developer may be good, but they're probably not mature enough to be senior.
Technically it's all machine code all the way anyway. :)
Most people who make comments like this have only seen languages which differ in syntax, but many do differ in semantics.
However, the more interesting comparisons happens above that level. There are real differences in the implied semantics, the lightness/heaviness of the syntaxes for common tasks, the division of labor between the programmer and the compiler (aka static vs dynamic typing, unit tests vs compiler error, etc.) A language with deep metaprogramming (Lisp, Ruby, etc) will feel different than a language that requires writing adhoc custom code generation tools to approximate the safe effect.
Discussion about languages at a layer above the Turing Tarpit means Lisp, Haskell, Prolog, C++, Python, Java, Bash, x86-assembly, BASIC, etc are all very different.
[1] https://en.wikipedia.org/wiki/Turing_tarpit
This is a useful definition because a feature like an enhanced for-loop doesn't have global effects on the program if it's plunked into some local context -- the same program could have been written without it. But adding something like, say, exceptions does have interesting nonlocal effects, and allows for differently-shaped computations than before.
The useful point here is that the feature is added as an incremental change on an already-existing language, so its effects can be measured relative to the original language. The original and extended language can both be Turing-complete, and this is still a useful definition.
[1] http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.51.4...
> 1936 - Alan Turing invents every programming language that will ever be but is shanghaied by British Intelligence to be 007 before he can patent them.
> 1936 - Alonzo Church also invents every language that will ever be but does it better. His lambda calculus is ignored because it is insufficiently C-like. This criticism occurs in spite of the fact that C has not yet been invented.
(from http://james-iry.blogspot.nl/2009/05/brief-incomplete-and-mo...)
As someone who appreciates both C and FP languages, I can't upvote this enough :)
I did bite for the click-bait title because I expected something tongue-in-cheek. But there's no explanation or context for that in the article.
A dubious quote, presented in the worst possible way, all that leaves a bad taste in my mouth. How can someone say such a thing without explanation and expect to be taken seriously?
Now, are all programming languages the same? Most definitely not. Lisps exist, functional languages exist, heck, BASIC exists, to name some other language families. But all mainstream languages are virtually the same.
How so? There's a lot of choice, but quite little diversity. There are more languages than there are big differences between them. You could combine Python, PHP, JavaScript, Lua, and Ruby, then C++ and C, then C# and Java. There'd only be 3 mainstream programming languages left, but you'd have lost almost no diversity.
Even with the differences between them, an algorithm implemented in any of them will look nearly identical.
Interestingly, Pure Data is not all a fad (but neither a growing trend!). In the art community, I have friends that are very proficient with Pure Data, using it for creating various visual and audio programs. A lot of them are still using it more than a decade after they first started.
[1] https://en.wikipedia.org/wiki/Pure_Data