7 ms·

Most developers don’t really know any computer language

20 points by johndcook 14y ago

orangethirty 14y ago
Site is crippling under traffic.
- Pwntastic 14y ago
  Yeah, it's 404'd now, but Google still has it cached: http://bit.ly/QN6XTt http://bit.ly/QN6XTt edit: Actually it looks like the entire article is still visible right on the blog landing page: http://shape-of-code.coding-guidelines.com/ http://shape-of-code.coding-guidelines.com/
- thaumaturgy 14y ago
  Yeah, most webmasters don't really know anything about web servers. /snark
pyalot2 14y ago
Most developers don't really know how to host websites.
codgercoder 14y ago
and yet, they still get hired..
nathan_f77 14y ago
I haven't worked with enough programmers to either agree or disagree, but I personally try to become really fluent in the languages that I use. For example, participating in the ruby-core mailing list has really increased my knowledge of Ruby methods and internals. It also really pays to know a language when you're using something that compiles into it. You're going to have a bad time with Coffeescript if you're not already fluent in Javascript, and you need to be able to understand the patterns and conventions in the compiled code.
- ajross 14y ago
  The last bit is sort of true and not. Obviously you don't have to know Javascript to write Coffeescript any more than you have to know C to write Javascript (or how your machine architecture works to write C). But it certainly helps. And you'll never write good code without a solid understanding of the runtime your syntax is sitting on. But I don't think that's any more true of CS/JS than it is for any other environment. Java progammers need to understand the JVM, C people want some ability to read disassembly and understand calling conventions, people writing code generators need to understand the hardware pipeline they are optimizing for. It's turtles all the way down.
  - benaiah 14y ago
    It is more true for Coffeescript, because Coffeescript is so closely tied to specific Javascript problems and idioms that it makes it more of JS shorthand than an actual new language. It's very different than understanding .NET (or Mono, for that matter) to write C#, or understanding the JVM to write Clojure.
- pfisch 14y ago
  Wouldn't it be better if you instead knew a good bit of c++/obj-c, c#/java, php, matlab, python, etc. It's just like investing, you are putting all your eggs in one basket. I don't think Ruby's future is especially in trouble, but it is certainly not as secure as the basket of languages I included above. Also ruby is only really used for a small subset of tasks. With the basket of languages I included you could really do anything from microcontroller programming to making video games to website dev.
ataggart 14y ago
Perhaps I missed it, but I don't see where the author defines what he thinks it means to "really know any computer language."
- andrewcooke 14y ago
  well, he implies you need to have written a compiler front end for one. and i'm glad i can answer this question as i kinda stopped at that point...
bithive123 14y ago
Just like there are more musicians than people who understand music theory, formalism is not required for software development. This is neither surprising nor bad.
- pacaro 14y ago
  Indeed, this makes me think of http://www.codinghorror.com/blog/2007/11/mort-elvis-einstein-and-you.html http://www.codinghorror.com/blog/2007/11/mort-elvis-einstein...
  - jwdunne 14y ago
    You know, as irrelevant as my comment is, this comment means a great deal to me. I haven't read it before but I did make the following Ask HN finally provoked by another of Atwood's posts: http://news.ycombinator.com/item?id=4785581 http://news.ycombinator.com/item?id=4785581 For me, this is very reassuring so I thank you :)
- prodigal_erik 14y ago
  Unlike music, software can be (and almost always is) grotesquely defective in ways that aren't obvious to the user right away.
  - bithive123 14y ago
    I'm not so sure; there is plenty of popular music I find grotesquely defective in ways that aren't obvious to the people who appreciate it. Like it or not, software quality is entirely subjective and in the eye of the beholder. There is no other way to explain the continued ubiquity of things like PHP, Windows, iTunes, <insert bane of your existence>, etc.
JasonFruit 14y ago
This article gets lost in matters of measurement, drifts off, and in the end fails to say anything worthwhile. Hopefully some of you will read the discussion first and skip the article.
kev009 14y ago
Not really sure where the article is going but I will throw out two things: * "Never memorize something that you can look up in a book." * We may know about 10k-40k words depending on the study, person, etc, but can generally communicate any idea with those that we do. There's a ton of overlap and specialization that can be worked around with smaller, simpler pieces (Guy Steele's recently linked '98 OOPSLA talk on growing a language comes to mind...). The second point is pretty familiar when it comes to programming. Maybe you don't know the most efficient algorithm, the most maintainable strategy, the whizbang idiomatic language construct, etc. but that doesn't mean you can't "communicate" useful work to/through the code you do "know".
dbecker 14y ago
This article starts by claiming developers have only a superficial knowledge of the languages they use, and on that basis, it argues we should teach languages in a more superficial way. But it's unclear what benefit we'd supposedly reap by teaching languages in a more superficial way? If there is a substantive point to this article (aside from the pretentious suggestion has a deeper knowledge of programming than everyone else), I failed to understand his point.
btilly 14y ago
I completely believe the conclusion. And I believe that it applies to most of the people reading this thread. Let me demonstrate with a real example. Perl by default passes by reference, copies by value, and mutates in place. How many Perl programmers have any clue of what I said? By contrast Python by default passes by reference, copies by reference, and does not mutate values in place. How many Python programmers have any clue what that means? And how many programmers who have programmed both languages professionally (or other commenters in this discussion) can discuss some of the differences in the languages that arise from this difference? Can you write a concrete piece of code which will demonstrate consequences of this difference? My guess is that few really understand what I'm talking about. Nor do you need to because the memorized patterns for writing loops, functions, etc work perfectly well whether or not you understand this internal design decision.
- beatgammit 14y ago
  I have so far successfully avoided Perl, but I have programmed a little in Python. I completely understand those statements, and I can make guesses about difference in some corner cases. I think it's relatively common to know what those statements mean. I agree that a programmer that doesn't know how variables are passed probably doesn't understand the language. I don't agree with the conclusion though. I think that a programmer "knows" a language if he/she understands the idiomatic way of representing an idea. For example, if a functional language programmer comes to C, perhaps he/she might write a summing function this way: int sum(int* arr, int count) { if (count == 0) { return 0; } return *arr + res(arr++, count--); } And an assembly programmer might do it this way: int sum(int* arr, int count) { int sum = 0; int i = 0; loop: if (i == count) return sum; sum += arr[i]; i++; goto loop; } Neither are writing idiomatic C code, but both show they know different corners of the syntax. I would argue that one does not "know" a language until their first reflex in solving a problem is to write it the most idiomatic way for that language. When I write code in a language, I try to follow the idioms of that language: * Go: multiple return values and interfaces * Java: small, polymorphic classes with tons of getters and setters * Javascript: prototypes, callbacks and array methods * Python: list comprehensions, generators, and tuples * D: templates, "auto" and parameter storage classes (in, out, ref, inout) A programmer doesn't have to know the nitty gritty details of a language to "know" the language. I think the programmer can omit omit learning crazy #define macro foo, the "comma" operator, type coercion rules, bit alignment in structs (for cheap struct serialization) and the like and still "know" the language. Conversely, the more of these details you know, the more likely it is that you won't write idiomatic code. If you know, for example, that x << 0 is faster than parseInt(i, 10) is faster in Javascript, you'll tend to use that more often than the more idiomatic way. This is an implementation detail and shows that you don't understand the idiomatic way of writing Javascript code. I use a language depending on the problem domain. Some languages lend themselves to certain problems better than others. I don't, however, know the implementation details that only a compiler designer should know, but I don't feel that precludes me from "knowing" a language.
KMcHugh 14y ago
Alternative Title: Most people who see far aren't giants

20 points by johndcook 14y ago

orangethirty 14y ago

Site is crippling under traffic.

Pwntastic 14y ago
Yeah, it's 404'd now, but Google still has it cached: http://bit.ly/QN6XTt http://bit.ly/QN6XTt edit: Actually it looks like the entire article is still visible right on the blog landing page: http://shape-of-code.coding-guidelines.com/ http://shape-of-code.coding-guidelines.com/
thaumaturgy 14y ago
Yeah, most webmasters don't really know anything about web servers. /snark

pyalot2 14y ago

Most developers don't really know how to host websites.

codgercoder 14y ago

and yet, they still get hired..

nathan_f77 14y ago

I haven't worked with enough programmers to either agree or disagree, but I personally try to become really fluent in the languages that I use. For example, participating in the ruby-core mailing list has really increased my knowledge of Ruby methods and internals. It also really pays to know a language when you're using something that compiles into it. You're going to have a bad time with Coffeescript if you're not already fluent in Javascript, and you need to be able to understand the patterns and conventions in the compiled code.

ajross 14y ago
The last bit is sort of true and not. Obviously you don't have to know Javascript to write Coffeescript any more than you have to know C to write Javascript (or how your machine architecture works to write C). But it certainly helps. And you'll never write good code without a solid understanding of the runtime your syntax is sitting on. But I don't think that's any more true of CS/JS than it is for any other environment. Java progammers need to understand the JVM, C people want some ability to read disassembly and understand calling conventions, people writing code generators need to understand the hardware pipeline they are optimizing for. It's turtles all the way down.
- benaiah 14y ago
  It is more true for Coffeescript, because Coffeescript is so closely tied to specific Javascript problems and idioms that it makes it more of JS shorthand than an actual new language. It's very different than understanding .NET (or Mono, for that matter) to write C#, or understanding the JVM to write Clojure.
pfisch 14y ago
Wouldn't it be better if you instead knew a good bit of c++/obj-c, c#/java, php, matlab, python, etc. It's just like investing, you are putting all your eggs in one basket. I don't think Ruby's future is especially in trouble, but it is certainly not as secure as the basket of languages I included above. Also ruby is only really used for a small subset of tasks. With the basket of languages I included you could really do anything from microcontroller programming to making video games to website dev.

ataggart 14y ago

Perhaps I missed it, but I don't see where the author defines what he thinks it means to "really know any computer language."

andrewcooke 14y ago
well, he implies you need to have written a compiler front end for one. and i'm glad i can answer this question as i kinda stopped at that point...

bithive123 14y ago

Just like there are more musicians than people who understand music theory, formalism is not required for software development. This is neither surprising nor bad.

pacaro 14y ago
Indeed, this makes me think of http://www.codinghorror.com/blog/2007/11/mort-elvis-einstein-and-you.html http://www.codinghorror.com/blog/2007/11/mort-elvis-einstein...
- jwdunne 14y ago
  You know, as irrelevant as my comment is, this comment means a great deal to me. I haven't read it before but I did make the following Ask HN finally provoked by another of Atwood's posts: http://news.ycombinator.com/item?id=4785581 http://news.ycombinator.com/item?id=4785581 For me, this is very reassuring so I thank you :)
prodigal_erik 14y ago
Unlike music, software can be (and almost always is) grotesquely defective in ways that aren't obvious to the user right away.
- bithive123 14y ago
  I'm not so sure; there is plenty of popular music I find grotesquely defective in ways that aren't obvious to the people who appreciate it. Like it or not, software quality is entirely subjective and in the eye of the beholder. There is no other way to explain the continued ubiquity of things like PHP, Windows, iTunes, <insert bane of your existence>, etc.

JasonFruit 14y ago

This article gets lost in matters of measurement, drifts off, and in the end fails to say anything worthwhile. Hopefully some of you will read the discussion first and skip the article.

kev009 14y ago

Not really sure where the article is going but I will throw out two things: * "Never memorize something that you can look up in a book." * We may know about 10k-40k words depending on the study, person, etc, but can generally communicate any idea with those that we do. There's a ton of overlap and specialization that can be worked around with smaller, simpler pieces (Guy Steele's recently linked '98 OOPSLA talk on growing a language comes to mind...). The second point is pretty familiar when it comes to programming. Maybe you don't know the most efficient algorithm, the most maintainable strategy, the whizbang idiomatic language construct, etc. but that doesn't mean you can't "communicate" useful work to/through the code you do "know".

dbecker 14y ago

This article starts by claiming developers have only a superficial knowledge of the languages they use, and on that basis, it argues we should teach languages in a more superficial way. But it's unclear what benefit we'd supposedly reap by teaching languages in a more superficial way? If there is a substantive point to this article (aside from the pretentious suggestion has a deeper knowledge of programming than everyone else), I failed to understand his point.

btilly 14y ago

I completely believe the conclusion. And I believe that it applies to most of the people reading this thread. Let me demonstrate with a real example. Perl by default passes by reference, copies by value, and mutates in place. How many Perl programmers have any clue of what I said? By contrast Python by default passes by reference, copies by reference, and does not mutate values in place. How many Python programmers have any clue what that means? And how many programmers who have programmed both languages professionally (or other commenters in this discussion) can discuss some of the differences in the languages that arise from this difference? Can you write a concrete piece of code which will demonstrate consequences of this difference? My guess is that few really understand what I'm talking about. Nor do you need to because the memorized patterns for writing loops, functions, etc work perfectly well whether or not you understand this internal design decision.

beatgammit 14y ago
I have so far successfully avoided Perl, but I have programmed a little in Python. I completely understand those statements, and I can make guesses about difference in some corner cases. I think it's relatively common to know what those statements mean. I agree that a programmer that doesn't know how variables are passed probably doesn't understand the language. I don't agree with the conclusion though. I think that a programmer "knows" a language if he/she understands the idiomatic way of representing an idea. For example, if a functional language programmer comes to C, perhaps he/she might write a summing function this way: int sum(int* arr, int count) { if (count == 0) { return 0; } return *arr + res(arr++, count--); } And an assembly programmer might do it this way: int sum(int* arr, int count) { int sum = 0; int i = 0; loop: if (i == count) return sum; sum += arr[i]; i++; goto loop; } Neither are writing idiomatic C code, but both show they know different corners of the syntax. I would argue that one does not "know" a language until their first reflex in solving a problem is to write it the most idiomatic way for that language. When I write code in a language, I try to follow the idioms of that language: * Go: multiple return values and interfaces * Java: small, polymorphic classes with tons of getters and setters * Javascript: prototypes, callbacks and array methods * Python: list comprehensions, generators, and tuples * D: templates, "auto" and parameter storage classes (in, out, ref, inout) A programmer doesn't have to know the nitty gritty details of a language to "know" the language. I think the programmer can omit omit learning crazy #define macro foo, the "comma" operator, type coercion rules, bit alignment in structs (for cheap struct serialization) and the like and still "know" the language. Conversely, the more of these details you know, the more likely it is that you won't write idiomatic code. If you know, for example, that x << 0 is faster than parseInt(i, 10) is faster in Javascript, you'll tend to use that more often than the more idiomatic way. This is an implementation detail and shows that you don't understand the idiomatic way of writing Javascript code. I use a language depending on the problem domain. Some languages lend themselves to certain problems better than others. I don't, however, know the implementation details that only a compiler designer should know, but I don't feel that precludes me from "knowing" a language.

KMcHugh 14y ago

Alternative Title: Most people who see far aren't giants