4 ms·

> and the necessity for domain knowledge beyond the bare minimum required to produce correct syntax is always more important than the language itself. I can't

> and the necessity for domain knowledge beyond the bare minimum required to produce correct syntax is always more important than the language itself. I can't help but feel you are agreeing with the parent poster. In your examples you changed the domain. The parent was talking about the shift in language being the least important factor. It's not entirely true but as a web dev I have written a web app in x86 assembler and cgi-bin without too much trouble. It took longer but I never really felt stuck.

carlmr 9y ago
Exactly, it's a classic rhetoric device to destroy an argument by extending it so much that it sounds silly and addressing the silly proposition instead. There are some languages which are very interchangeable where someone from a similar family will be able to get up to speed quickly. e.g. C# developers can be hired for F#/Java/Scala/Kotlin/... positions. They're all GC'd, statically typed and don't require much familiarity with computer architecture. C and C++ devs can be hired for Rust positions, it's both non GC and requires some understanding of what you're doing with your memory, even if Rust is taking your footguns away. Sure, I wouldn't hire a JavaScript developer to do C, because they can do a lot of damage there. But I'd consider a C dev for a JavaScript position, even though I'd have to ask them why they want to do that to themselves. Levels of abstraction might be a better "metric". ASM < C/C++ < ADA, Rust < C#, F#, Java, Scala, Kotlin < Python, JavaScript, Perl < DSLs < GUIs It's easy to move up in the abstraction layers. It's harder to move down, because you have to think about things you haven't thought about before.
- sanxiyn 9y ago
  > C and C++ devs can be hired for Rust positions In my experience, this is very untrue. Knowing C++ does not make learning Rust any easier than knowing Java.
  - carlmr 9y ago
    I find it does, at the very least familiarity with RAII concepts and smart pointers will make the whole borrow checking business seem very familiar.
- gkya 9y ago
  The domain is more important, I think; i.e. you can hire a web dev to work with almost any language/framework, but you may not hire a Django dev for a statistics heavy project written in Python.
  - carlmr 9y ago
    Yeah, that's true. For that statistics project I'd look at their academic background. If there's not much math in what they studied I wouldn't consider them.
- krapp 9y ago
  > Exactly, it's a classic rhetoric device to destroy an argument by extending it so much that it sounds silly and addressing the silly proposition instead. That's not what I was attempting to do. > Sure, I wouldn't hire a JavaScript developer to do C, because they can do a lot of damage there. But I'd consider a C dev for a JavaScript position, even though I'd have to ask them why they want to do that to themselves. But it's a problem either way. A C developer likely is going to want Javascript to work like C, and they're going to hate that it doesn't, and they're going to write bad Javascript as a result. And understanding modern Javascript means understanding the DOM and how to efficiently interact with it, and the whole horrible mess that is NPM, and compile-to-js languages. My argument is that outside of a textbook, the domain and the language seem to be inseparable, or at least very tightly coupled. Abstraction is one dimension (and I'm not entirely sure it's true that it's easy to move up, since abstractions carry their own debt) but it's likely not one that really matters to a business.

carlmr 9y ago

Exactly, it's a classic rhetoric device to destroy an argument by extending it so much that it sounds silly and addressing the silly proposition instead. There are some languages which are very interchangeable where someone from a similar family will be able to get up to speed quickly. e.g. C# developers can be hired for F#/Java/Scala/Kotlin/... positions. They're all GC'd, statically typed and don't require much familiarity with computer architecture. C and C++ devs can be hired for Rust positions, it's both non GC and requires some understanding of what you're doing with your memory, even if Rust is taking your footguns away. Sure, I wouldn't hire a JavaScript developer to do C, because they can do a lot of damage there. But I'd consider a C dev for a JavaScript position, even though I'd have to ask them why they want to do that to themselves. Levels of abstraction might be a better "metric". ASM < C/C++ < ADA, Rust < C#, F#, Java, Scala, Kotlin < Python, JavaScript, Perl < DSLs < GUIs It's easy to move up in the abstraction layers. It's harder to move down, because you have to think about things you haven't thought about before.

sanxiyn 9y ago
> C and C++ devs can be hired for Rust positions In my experience, this is very untrue. Knowing C++ does not make learning Rust any easier than knowing Java.
- carlmr 9y ago
  I find it does, at the very least familiarity with RAII concepts and smart pointers will make the whole borrow checking business seem very familiar.
gkya 9y ago
The domain is more important, I think; i.e. you can hire a web dev to work with almost any language/framework, but you may not hire a Django dev for a statistics heavy project written in Python.
- carlmr 9y ago
  Yeah, that's true. For that statistics project I'd look at their academic background. If there's not much math in what they studied I wouldn't consider them.
krapp 9y ago
> Exactly, it's a classic rhetoric device to destroy an argument by extending it so much that it sounds silly and addressing the silly proposition instead. That's not what I was attempting to do. > Sure, I wouldn't hire a JavaScript developer to do C, because they can do a lot of damage there. But I'd consider a C dev for a JavaScript position, even though I'd have to ask them why they want to do that to themselves. But it's a problem either way. A C developer likely is going to want Javascript to work like C, and they're going to hate that it doesn't, and they're going to write bad Javascript as a result. And understanding modern Javascript means understanding the DOM and how to efficiently interact with it, and the whole horrible mess that is NPM, and compile-to-js languages. My argument is that outside of a textbook, the domain and the language seem to be inseparable, or at least very tightly coupled. Abstraction is one dimension (and I'm not entirely sure it's true that it's easy to move up, since abstractions carry their own debt) but it's likely not one that really matters to a business.