4 ms·

Maybe I am biased, I work with Clojure since 2012, I use elixir and go, but still, I believe that once you master the paradigm (OOP, FP, or procedural) then it

by siscia 11y ago

Maybe I am biased, I work with Clojure since 2012, I use elixir and go, but still, I believe that once you master the paradigm (OOP, FP, or procedural) then it always the same deal, the syntax may change, but find a value in am hash map will always be faster than find a value in an unsorted list. For a programmer, once the basis are solid, learn a "new" language should be matter of a couple of weeks...

derefr 11y ago
I think the big problem with the idea of "learning a language" is that most programmers conflate a language with any bits of CS theory that are only to be found in that language. For example, when most people say they have a hard time "learning Erlang", it's not the syntax they're complaining about (no, really!); they're really complaining about trying to wrap their heads around the actor model, which writing idiomatic Erlang code requires. Personally, I think the two efforts should be decoupled. If you actually want people to learn Erlang, then instead of teaching "Erlang and the actor model" all in one go, you should strive to make some actor-model framework or another available in the languages people are already familiar with. People could then experiment with the unfamiliar CS theory first in a comfortable syntax—and then, having done so, Erlang would become just another of those mundane "matter of a couple of weeks" languages. --- The real further step we could take, if we wanted to advance the field as a whole, would be to decouple syntax, from "taxonomy", from platform—such that there's no single thing known as a "language" to learn. * platforms are choices about sets of runtime VM features like GC and threading, where things on the same platform have native interop (e.g. Java and Clojure); * taxonomies (or if you prefer, "vocabularies" or "dialects") are choices about the contents and organization of the stdlib, and which native types get used as "lowest-common denominator" types for passing to stdlib functions (e.g. whether you pass dicts or lists-of-pairs for options; whether closures are used for everything or some things or nothing; whether {tuples, sets, monads} exist as a thing the stdlib accepts where appropriate, or whether it uses some other lower-level abstraction instead even though the more abstract type is there.) The idiomatic style of a "language" today is mostly about its taxonomy, because library writers take their cues from the stdlib. So things with the same taxonomy can share package ecosystems with no impedance (e.g. JavaScript and CoffeeScript); "siblings" with a mostly-shared taxonomy can share packages with some small effort to speak in LCD types (e.g. Erlang and Elixir.) Unrelated taxonomies need "glue" libraries to explicitly map the impedance, as you see in e.g. Clojure's Java-wrapping libs. * syntaxes are (hopefully bijective) mappings between tokens and ASTs—as in LISP's original secondary "m-expr" syntax. There's nothing stopping you from mapping any syntax you like to any taxonomy—save for the fact that some syntaxes include operators that do something sensible in one taxonomy (e.g. circumfix operators to create different types of containers; Erlang's "async send" operator) and make no sense for another. I would compare this to the buttons on game controllers: if you use the "wrong" syntax, then some "games" will need "buttons" you don't have on your controller—but with just a bit more fiddling (e.g. typing Set[] vs. #{}) you can still get your meaning across. People talk about "syntax vs. semantics", but that's a muddle because parts of "semantics" are inextricably represented within syntax. But when you split things this way, you get a clean break: a "language" becomes mostly about taxonomy, where you can port that taxonomy to various platforms, and then target that taxonomy with various syntaxes. In my ideal world, we'd have a universally-agreed-upon AST format to use as the canonical representation of checked-in code. Each file would mark what taxonomy its identifiers refer to, but would use no taxonomy-specific syntax. Then you'd use something like a FUSE server to map those AST files into a workable representation in a syntax you enjoy. Your text editor wouldn't know the difference; but saving the (syntax'ed) file would pass it to the FUSE filesystem, which would parse it and use it to modify the AST. (Obviously, we could also have IDEs that worked with the AST directly, and thus exposed more interesting paradigms than character-wise editing of purely-textual syntax. But the first step is the same: getting a universal taxonomy-neutral AST format adopted by a majority of today's "languages", to effectively commoditize themselves.)
- rapha22_1 11y ago
  Agreed. On one of the first classes I had in college, a teacher said we should favor "knowledge" (that is, concepts) over "technics" (that is, knowing a specific way to apply knowledge), and never confuse one with the other. That stuck with me and, in retrospect, was one of the best advises I've had in my career.
AnimalMuppet 11y ago
Depends on your definition of "learn". Learn it well enough to write it? Sure, a couple of weeks, maybe less. Learn it well enough to write professional-quality code? That takes longer, because you have to learn what the pitfalls are. (Writing professional code, in large part, boils down to knowing what not to write.) Learn it well enough to be as productive as you were with the previous language? Maybe three to six months? And that's the real problem, IMHO. It's going to take me three months of lower productivity to make the switch to the new language/framework/tool/whatever. How long will the new thing take to pay me back for that time it costs? If it's not significantly better than what I'm using now, it's not worth the cost.

by siscia 11y ago

derefr 11y ago

I think the big problem with the idea of "learning a language" is that most programmers conflate a language with any bits of CS theory that are only to be found in that language. For example, when most people say they have a hard time "learning Erlang", it's not the syntax they're complaining about (no, really!); they're really complaining about trying to wrap their heads around the actor model, which writing idiomatic Erlang code requires. Personally, I think the two efforts should be decoupled. If you actually want people to learn Erlang, then instead of teaching "Erlang and the actor model" all in one go, you should strive to make some actor-model framework or another available in the languages people are already familiar with. People could then experiment with the unfamiliar CS theory first in a comfortable syntax—and then, having done so, Erlang would become just another of those mundane "matter of a couple of weeks" languages. --- The real further step we could take, if we wanted to advance the field as a whole, would be to decouple syntax, from "taxonomy", from platform—such that there's no single thing known as a "language" to learn. * platforms are choices about sets of runtime VM features like GC and threading, where things on the same platform have native interop (e.g. Java and Clojure); * taxonomies (or if you prefer, "vocabularies" or "dialects") are choices about the contents and organization of the stdlib, and which native types get used as "lowest-common denominator" types for passing to stdlib functions (e.g. whether you pass dicts or lists-of-pairs for options; whether closures are used for everything or some things or nothing; whether {tuples, sets, monads} exist as a thing the stdlib accepts where appropriate, or whether it uses some other lower-level abstraction instead even though the more abstract type is there.) The idiomatic style of a "language" today is mostly about its taxonomy, because library writers take their cues from the stdlib. So things with the same taxonomy can share package ecosystems with no impedance (e.g. JavaScript and CoffeeScript); "siblings" with a mostly-shared taxonomy can share packages with some small effort to speak in LCD types (e.g. Erlang and Elixir.) Unrelated taxonomies need "glue" libraries to explicitly map the impedance, as you see in e.g. Clojure's Java-wrapping libs. * syntaxes are (hopefully bijective) mappings between tokens and ASTs—as in LISP's original secondary "m-expr" syntax. There's nothing stopping you from mapping any syntax you like to any taxonomy—save for the fact that some syntaxes include operators that do something sensible in one taxonomy (e.g. circumfix operators to create different types of containers; Erlang's "async send" operator) and make no sense for another. I would compare this to the buttons on game controllers: if you use the "wrong" syntax, then some "games" will need "buttons" you don't have on your controller—but with just a bit more fiddling (e.g. typing Set[] vs. #{}) you can still get your meaning across. People talk about "syntax vs. semantics", but that's a muddle because parts of "semantics" are inextricably represented within syntax. But when you split things this way, you get a clean break: a "language" becomes mostly about taxonomy, where you can port that taxonomy to various platforms, and then target that taxonomy with various syntaxes. In my ideal world, we'd have a universally-agreed-upon AST format to use as the canonical representation of checked-in code. Each file would mark what taxonomy its identifiers refer to, but would use no taxonomy-specific syntax. Then you'd use something like a FUSE server to map those AST files into a workable representation in a syntax you enjoy. Your text editor wouldn't know the difference; but saving the (syntax'ed) file would pass it to the FUSE filesystem, which would parse it and use it to modify the AST. (Obviously, we could also have IDEs that worked with the AST directly, and thus exposed more interesting paradigms than character-wise editing of purely-textual syntax. But the first step is the same: getting a universal taxonomy-neutral AST format adopted by a majority of today's "languages", to effectively commoditize themselves.)

rapha22_1 11y ago
Agreed. On one of the first classes I had in college, a teacher said we should favor "knowledge" (that is, concepts) over "technics" (that is, knowing a specific way to apply knowledge), and never confuse one with the other. That stuck with me and, in retrospect, was one of the best advises I've had in my career.

AnimalMuppet 11y ago

Depends on your definition of "learn". Learn it well enough to write it? Sure, a couple of weeks, maybe less. Learn it well enough to write professional-quality code? That takes longer, because you have to learn what the pitfalls are. (Writing professional code, in large part, boils down to knowing what not to write.) Learn it well enough to be as productive as you were with the previous language? Maybe three to six months? And that's the real problem, IMHO. It's going to take me three months of lower productivity to make the switch to the new language/framework/tool/whatever. How long will the new thing take to pay me back for that time it costs? If it's not significantly better than what I'm using now, it's not worth the cost.