4 ms·

And what with "syntax doesn't matter" people? You know, the ones that now both Perl and at least three Lisps, and then twenty other languages, the ones that say

And what with "syntax doesn't matter" people? You know, the ones that now both Perl and at least three Lisps, and then twenty other languages, the ones that say that syntax is just a minor detail, and if you're irritated enough you can always write a "transpiler"? Where did all these people go (long time ago)? Also, I prefer maths from before 20th century. You could get knowledge out of it without relying on an additional skill, which math-reading nowadays is. On a related note: I don't believe that "you spend more time using the language than learning it". I need to think it about it some more, but I have a feeling that almost everything we do as a programmers is learning.

kbenson 14y ago
On a related note: I don't believe that "you spend more time using the language than learning it". I need to think it about it some more, but I have a feeling that almost everything we do as a programmers is learning. Yes, but how much of that is learning the language, and how much is learning about programming and/or computer science in general?
smacktoward 14y ago
But how much of that learning is really empirically necessary, and how much is just keeping up with industry fads and trends just to stay marketable? I've learned way too many languages over the last fifteen years just in the process of being a web developer. I'm not sure if any of them by themselves made me a radically better at web development. More frequently they were learned to get access to a bit of tooling or some other benefit that only one language had. Think of all the people who learned Ruby in order to use Rails, for instance, or who learned JavaScript to do front-end scripting. Is it really something about Ruby-the-language or JS-the-language that made them so compelling? Not really. It was the productivity gains you could get by getting access to their ecosystems, rather than the languages themselves. For this reason I have some envy for the folks you meet who've been working in Lisp, or Perl, or C, or COBOL, or some other language consistently for decades. They get to reach a level of proficiency and sophistication in how they use their tools that are out of reach when you're constantly bouncing from language to language.
- webjprgm 14y ago
  I agree that I'd like to have the chance to get really good in a language that I use for a long time. (As long as it's enjoyable, e.g. I wouldn't want to be stuck in VB forever.) At one point I worked almost entirely in Java (up until around Java 1.5). Another few years it was mostly PHP. But since then it's been a bit of everything. Useful lessons from learning: - Javascript -> Callback passing for an asynchronous computing paradigm. Object-array duality and prototype-based inheritance. - Ruby -> Rubyists often like to be clever with chaining several functions on one line to do something succinctly. This is kinda like functional programming (operations like map, inject, fold, etc.) but just one small piece of it. Ruby also has lots of metaprogramming magic to make DSLs, but that can bite you really bad when you have to debug RoR GEMs.
  - snaky 14y ago
    Perl's http://en.wikipedia.org/wiki/Schwartzian_transform http://en.wikipedia.org/wiki/Schwartzian_transform is much more functional-style, I suppose, and it's here from 1994.
- klibertp 14y ago
  "Is it really something about Ruby-the-language or JS-the-language that made them so compelling?" Well... It obviously depends on a person. What is compelling to you may not be so for me and the other way around. And in this instance it depends on what you know already. So, in other words, are JS and Ruby compelling to someone who learned Pascal or C in school and writes PHP for a living? Hell yes! Are they going to make him a better developer? There's a high chance they will. Ruby sports an object system that is somewhat similar to Smalltalk, with many idioms borrowed from it. That's completely different Object Orientation and learning it can have benefits. If nothing more, it gives you another way of modeling problem domains, which is always a good thing. JavaScript was an objective-functional mesh long before Scala. Coming from C or PHP, seeing first class functions with implicit state (closures) can open your eyes for yet another way of modeling things. Building, in essence, your own object system when you use a language is a valuable experience, too. Different languages have different semantics and knowing many of them helps in expressing yourself. I hear that what we think is constrained by the language we know. That's true for programming languages too.
webjprgm 14y ago
It also partly depends on how often you switch jobs that require you to learn a new programming language. So far in my career I've had to learn new languages quite often, esp. on hacked-together projects with 3+ languages. It's not just learning the syntax but also the common idioms. Still, I'm pretty sure at least more than 50% of the time was using the language and not learning it, so the original statement stands.
ohyes 14y ago
I'm still here. I mostly do s-expression -> language, because it lets me do code generation. The thing is, writing your own code generation tools is only really useful if you are capable of applying 'more difficult' to grok computer science concepts. For example, the intersection of 'working programmers' and 'people who really understand state machines' is (sadly) tiny. I'd even say that the syntax doesn't bother me because I don't really 'write' lisp code. The lisp code I write is solely done in order to generate much more complex code. So I would never actually implement an entire piece of software in common lisp (for example). I implement it in a variety of lisp-like dialects which accurately represent the problems presented by different modules inside the piece of software. Unfortunately this requires some forethought, some skill at language design, and an unwavering faith in ontology. To me, this is the best type of process for implementing a unique piece of software from scratch, and is the approach that should be taken in any language. (It's basically the logical conclusion of the idea of structured programming... except you don't implement 'loops' and 'if' statements).

kbenson 14y ago

On a related note: I don't believe that "you spend more time using the language than learning it". I need to think it about it some more, but I have a feeling that almost everything we do as a programmers is learning. Yes, but how much of that is learning the language, and how much is learning about programming and/or computer science in general?

smacktoward 14y ago

But how much of that learning is really empirically necessary, and how much is just keeping up with industry fads and trends just to stay marketable? I've learned way too many languages over the last fifteen years just in the process of being a web developer. I'm not sure if any of them by themselves made me a radically better at web development. More frequently they were learned to get access to a bit of tooling or some other benefit that only one language had. Think of all the people who learned Ruby in order to use Rails, for instance, or who learned JavaScript to do front-end scripting. Is it really something about Ruby-the-language or JS-the-language that made them so compelling? Not really. It was the productivity gains you could get by getting access to their ecosystems, rather than the languages themselves. For this reason I have some envy for the folks you meet who've been working in Lisp, or Perl, or C, or COBOL, or some other language consistently for decades. They get to reach a level of proficiency and sophistication in how they use their tools that are out of reach when you're constantly bouncing from language to language.

webjprgm 14y ago
I agree that I'd like to have the chance to get really good in a language that I use for a long time. (As long as it's enjoyable, e.g. I wouldn't want to be stuck in VB forever.) At one point I worked almost entirely in Java (up until around Java 1.5). Another few years it was mostly PHP. But since then it's been a bit of everything. Useful lessons from learning: - Javascript -> Callback passing for an asynchronous computing paradigm. Object-array duality and prototype-based inheritance. - Ruby -> Rubyists often like to be clever with chaining several functions on one line to do something succinctly. This is kinda like functional programming (operations like map, inject, fold, etc.) but just one small piece of it. Ruby also has lots of metaprogramming magic to make DSLs, but that can bite you really bad when you have to debug RoR GEMs.
- snaky 14y ago
  Perl's http://en.wikipedia.org/wiki/Schwartzian_transform http://en.wikipedia.org/wiki/Schwartzian_transform is much more functional-style, I suppose, and it's here from 1994.
klibertp 14y ago
"Is it really something about Ruby-the-language or JS-the-language that made them so compelling?" Well... It obviously depends on a person. What is compelling to you may not be so for me and the other way around. And in this instance it depends on what you know already. So, in other words, are JS and Ruby compelling to someone who learned Pascal or C in school and writes PHP for a living? Hell yes! Are they going to make him a better developer? There's a high chance they will. Ruby sports an object system that is somewhat similar to Smalltalk, with many idioms borrowed from it. That's completely different Object Orientation and learning it can have benefits. If nothing more, it gives you another way of modeling problem domains, which is always a good thing. JavaScript was an objective-functional mesh long before Scala. Coming from C or PHP, seeing first class functions with implicit state (closures) can open your eyes for yet another way of modeling things. Building, in essence, your own object system when you use a language is a valuable experience, too. Different languages have different semantics and knowing many of them helps in expressing yourself. I hear that what we think is constrained by the language we know. That's true for programming languages too.

webjprgm 14y ago

It also partly depends on how often you switch jobs that require you to learn a new programming language. So far in my career I've had to learn new languages quite often, esp. on hacked-together projects with 3+ languages. It's not just learning the syntax but also the common idioms. Still, I'm pretty sure at least more than 50% of the time was using the language and not learning it, so the original statement stands.

ohyes 14y ago

I'm still here. I mostly do s-expression -> language, because it lets me do code generation. The thing is, writing your own code generation tools is only really useful if you are capable of applying 'more difficult' to grok computer science concepts. For example, the intersection of 'working programmers' and 'people who really understand state machines' is (sadly) tiny. I'd even say that the syntax doesn't bother me because I don't really 'write' lisp code. The lisp code I write is solely done in order to generate much more complex code. So I would never actually implement an entire piece of software in common lisp (for example). I implement it in a variety of lisp-like dialects which accurately represent the problems presented by different modules inside the piece of software. Unfortunately this requires some forethought, some skill at language design, and an unwavering faith in ontology. To me, this is the best type of process for implementing a unique piece of software from scratch, and is the approach that should be taken in any language. (It's basically the logical conclusion of the idea of structured programming... except you don't implement 'loops' and 'if' statements).