Alternative Title: Most people who see far aren't giants
Most developers don’t really know any computer language
21–23 of 23 posts
Re: Most developers don’t really know any computer language
#22I 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…
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 environm…
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.
Re: Most developers don’t really know any computer language
#23I 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 h…
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--);
}
int sum(int* arr, int count) {
int sum = 0;
int i = 0;
loop:
if (i == count)
return sum;
sum += arr[i];
i++;
goto loop;
}
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 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.