5 ms·

This is at least part of the reason that reasonably strong engineers can learn a new programming language in under a day. The paradigms just aren’t that differe

by sfblah 5y ago

This is at least part of the reason that reasonably strong engineers can learn a new programming language in under a day. The paradigms just aren’t that different. I realize there’s a cottage industry of folks creating new languages all the time. But when you read the docs they all bucket into a few categories, and the differences are syntax, tooling and how system services are accessed. All that being said, these three categories do matter. Programming using tools like autocompletion, syntax highlighting and the like does speed productivity. But, like human language, at some point the “right” set of primitives are discovered. From that point on changes become more about culture and fads than concepts.

gcanyon 5y ago
Try learning J in a day. It...won't go well -- but in a good way. :-) As you say, for many languages the paradigm is some variation of C, and the concepts are largely interchangeable. Then you approach something like J, where (trivial example) +/%# returns the average of a list by composing three functions: + sums; % divides; # counts; with a modifier / that distributes + throughout the list; and you begin to realize you're not in Kansas anymore. https://en.wikipedia.org/wiki/J_(programming_language) https://en.wikipedia.org/wiki/J_(programming_language) I don't think the "right" set of primitives is as obvious as you say. Obviously branching and loops are foundational to many languages, but even those are optional given the right design, and they can be implemented in very different ways.
- raxxorrax 5y ago
  ÅF - Fibonacci in 05AB1E that are less than the current number on the stack - Good tip for when you get THAT code interview and can pick the language. Just need to know the code for Å if you are not from Denmark.
- dahfizz 5y ago
  That's just a syntax over map() and reduce(). There are no new / different primitives in J, just a new syntax that emphasizes the use of arrays.
  - gcanyon 5y ago
    It's a bit ironic that we're essentially having a blub language debate on ycombinator's web site. I'll defer to Paul Graham's response: http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html
- IncRnd 5y ago
  J is essentially APL. I think the point is that J is functionally equivalent with many other languages, only differing in syntax but not in paradigm.
  - karmakaze 5y ago
    I would say that you have to think in a different style so would classify as a different paradigm and not just syntax.
    - blacktriangle 5y ago
      Going back to the original comment, the statement was that any experienced engineer could learn a language in a day. At risk of gatekeeping, I'd argue that by definition any experienced engineer would have some experience with an array based language like APL or MATLAB so that no, J does not qualify as a different paradigm.
      - goatlover 5y ago
        I guess it depends on how much past experience they had with an array-based, stack-based, logic-based, pure functional or lisp family language, and how long ago that was. I can believe an experienced engineer can learn the basics of any language in a day. But being proficient and idiomatic is another matter.
      - gcanyon 5y ago
        The implication of the original comment was that any C-style language engineer could learn any C-style language in a day. I'd even argue that point, but it definitely doesn't get you J in a day, except that an supports most C-style syntax. So you can program in J like a C-programmer in a day. You definitely can't program like a J-programmer. And to say a competent engineer would already have array-language experience sidesteps the point.
        IncRnd 5y ago
        The original comment said nothing about C-style languages. That must be something you read into their comment. Learning J is like learning Perl or regular expressions. Nobody really wants to engage in such an activity, but people do what they need to do. Depending on their level of experience, a person who understands imperative and declarative paradigms along with the language's execution model can absolutely learn J within a day, because it only differs in syntax from the existing languages.
- karmakaze 5y ago
  But even this is an example of finding 'a' (not 'the') right set of primitives as APL is from 1966.
- derefr 5y ago
  Definition by function/combinator composition isn’t weird to a modern programmer (Haskell does a lot weirder); and vector processing isn’t really weird either — even Java programmers are familiar with chaining transformations and reductions on Streams these days. Instead, not knowing J, the only† thing that’s weird about that J expression to me, is that both +/ and # are receiving the same implicit vector argument, without any Forth-like “dup” operator needing to precede them. Are these operators defined to take an implicit single receiver vector? (Maybe whichever one’s on top of a “vector result stack” separate from a “scalar result stack”? Maybe the first one passed to the implicit lambda expression this code would be wrapped in?) Or is syntax sugar here hiding the argument, the way Smalltalk hides the receiver in successive expressions chained using ; ? What would a compact-as-possible J expression look like, to sum up the contents of one vector, and then divide the result by the cardinality of a different vector? ————— † Well, there is one other, more technical thing that’s “weird” about the expression above: it’s the fact that, unless +/ is a identifier separate from +, then the lexeme-sequence + / has to either derive its AST by lookahead, or by + being a stack literal and / an HOF. But then % is, seemingly, a binary infix operator. You don’t usually find both of those syntax features in the same grammar, both operating on arbitrary identifier-class lexemes, as it would usually cause an LALR parser for the language to have shift-reduce ambiguity. Unless, I suppose, the lexeme / isn’t lexed as “an identifier” terminal, but rather its own terminal class—and one that’s illegal anywhere but postfix of an identifier.
  - gcanyon 5y ago
    Frankly, I suck at J. I've solved a few dozen project Euler problems with it, but that's about it. If you want to see how deep the weeds get, check out this essay on solving the n-queens problem: https://code.jsoftware.com/wiki/Essays/N_Queens_Problem https://code.jsoftware.com/wiki/Essays/N_Queens_Problem J programmers just think differently.
  - gcanyon 5y ago
    + is a "verb" / is an "adverb" -- it modifies the functionality of whatever verb it is applied to. Almost all verbs can be binary or unary, sometimes with surprising (to me, a newbie) consequences. I have no idea how it gets handled underneath the hood.
raxxorrax 5y ago
But you don't know common compiler/interpreter pitfalls, tooling, frameworks... so in the end you still need a long time to get familiar with it for productive work. Sure, you know the vocabulary, but it will still take time to learn the rest.

by sfblah 5y ago

gcanyon 5y ago

Try learning J in a day. It...won't go well -- but in a good way. :-) As you say, for many languages the paradigm is some variation of C, and the concepts are largely interchangeable. Then you approach something like J, where (trivial example) +/%# returns the average of a list by composing three functions: + sums; % divides; # counts; with a modifier / that distributes + throughout the list; and you begin to realize you're not in Kansas anymore. https://en.wikipedia.org/wiki/J_(programming_language) https://en.wikipedia.org/wiki/J_(programming_language) I don't think the "right" set of primitives is as obvious as you say. Obviously branching and loops are foundational to many languages, but even those are optional given the right design, and they can be implemented in very different ways.

raxxorrax 5y ago
ÅF - Fibonacci in 05AB1E that are less than the current number on the stack - Good tip for when you get THAT code interview and can pick the language. Just need to know the code for Å if you are not from Denmark.
dahfizz 5y ago
That's just a syntax over map() and reduce(). There are no new / different primitives in J, just a new syntax that emphasizes the use of arrays.
- gcanyon 5y ago
  It's a bit ironic that we're essentially having a blub language debate on ycombinator's web site. I'll defer to Paul Graham's response: http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html
IncRnd 5y ago
J is essentially APL. I think the point is that J is functionally equivalent with many other languages, only differing in syntax but not in paradigm.
- karmakaze 5y ago
  I would say that you have to think in a different style so would classify as a different paradigm and not just syntax.
  - blacktriangle 5y ago
    Going back to the original comment, the statement was that any experienced engineer could learn a language in a day. At risk of gatekeeping, I'd argue that by definition any experienced engineer would have some experience with an array based language like APL or MATLAB so that no, J does not qualify as a different paradigm.
    - goatlover 5y ago
      I guess it depends on how much past experience they had with an array-based, stack-based, logic-based, pure functional or lisp family language, and how long ago that was. I can believe an experienced engineer can learn the basics of any language in a day. But being proficient and idiomatic is another matter.
    - gcanyon 5y ago
      The implication of the original comment was that any C-style language engineer could learn any C-style language in a day. I'd even argue that point, but it definitely doesn't get you J in a day, except that an supports most C-style syntax. So you can program in J like a C-programmer in a day. You definitely can't program like a J-programmer. And to say a competent engineer would already have array-language experience sidesteps the point.
      - IncRnd 5y ago
        The original comment said nothing about C-style languages. That must be something you read into their comment. Learning J is like learning Perl or regular expressions. Nobody really wants to engage in such an activity, but people do what they need to do. Depending on their level of experience, a person who understands imperative and declarative paradigms along with the language's execution model can absolutely learn J within a day, because it only differs in syntax from the existing languages.
karmakaze 5y ago
But even this is an example of finding 'a' (not 'the') right set of primitives as APL is from 1966.
derefr 5y ago
Definition by function/combinator composition isn’t weird to a modern programmer (Haskell does a lot weirder); and vector processing isn’t really weird either — even Java programmers are familiar with chaining transformations and reductions on Streams these days. Instead, not knowing J, the only† thing that’s weird about that J expression to me, is that both +/ and # are receiving the same implicit vector argument, without any Forth-like “dup” operator needing to precede them. Are these operators defined to take an implicit single receiver vector? (Maybe whichever one’s on top of a “vector result stack” separate from a “scalar result stack”? Maybe the first one passed to the implicit lambda expression this code would be wrapped in?) Or is syntax sugar here hiding the argument, the way Smalltalk hides the receiver in successive expressions chained using ; ? What would a compact-as-possible J expression look like, to sum up the contents of one vector, and then divide the result by the cardinality of a different vector? ————— † Well, there is one other, more technical thing that’s “weird” about the expression above: it’s the fact that, unless +/ is a identifier separate from +, then the lexeme-sequence + / has to either derive its AST by lookahead, or by + being a stack literal and / an HOF. But then % is, seemingly, a binary infix operator. You don’t usually find both of those syntax features in the same grammar, both operating on arbitrary identifier-class lexemes, as it would usually cause an LALR parser for the language to have shift-reduce ambiguity. Unless, I suppose, the lexeme / isn’t lexed as “an identifier” terminal, but rather its own terminal class—and one that’s illegal anywhere but postfix of an identifier.
- gcanyon 5y ago
  Frankly, I suck at J. I've solved a few dozen project Euler problems with it, but that's about it. If you want to see how deep the weeds get, check out this essay on solving the n-queens problem: https://code.jsoftware.com/wiki/Essays/N_Queens_Problem https://code.jsoftware.com/wiki/Essays/N_Queens_Problem J programmers just think differently.
- gcanyon 5y ago
  + is a "verb" / is an "adverb" -- it modifies the functionality of whatever verb it is applied to. Almost all verbs can be binary or unary, sometimes with surprising (to me, a newbie) consequences. I have no idea how it gets handled underneath the hood.

raxxorrax 5y ago

But you don't know common compiler/interpreter pitfalls, tooling, frameworks... so in the end you still need a long time to get familiar with it for productive work. Sure, you know the vocabulary, but it will still take time to learn the rest.