Hacker News Reader

Every average programmer with a passing knowledge of computer architecture should be able to pick up pointer "arithmetic" in a couple of hours.

It's not rocket science, really, it has more to do with the "I don't know what it is and I'm absolutely fine with that" kind of attitude.

As an electronic-engineer-turned-embedded-C-programmer I never had anything to do (and likely will in the immediate future) with things like closures, prototypal inheritance or web frameworks, but at least I should be able to know what they are and the concepts they are based upon.

By willingly limit your toolbox to one tool you limit your possibilities and usefulness. Maybe you'll come up with a problem that an other tool solves better than the one you are used to, and you'll never know.

Correct me if I am wrong, but any one of these "toolbox"es will take enormous effort to master fully. Some person may really want to do web development for his/her whole life, nothing wrong with that. But to do that they will have to master many many skills to even say "I know everything about web development".

The core argument of phrakture is that the toolboxes are more complicated than the underlying mechanism they hide. If he's right, learning them is worse than useless.

Kurtz isn't talking about those. He's talking about basic knowledge about programming. Even if he only does C, he at least has an escape hatch when he needs more powerful thoughts than what C alone can give him.

This is one of my beefs with ORM -- in order to use the database layer properly, you need to expose at least as much complexity as the database itself provides. We use Sequel, which is fine as far as it goes, but it ships with a stupid DSL that is a) as complex as SQL and b) significantly less capable. You end up with shitass queries and many more database round trips and for what? Method call syntax?

Sorry. Rant.

Speed of development. I know perfectly well how to write SQL, but I would rather write "Post.where(:published => true).first.comments.count" and move on to the next thing.

If I need to later on I can go back and write a raw SQL query, but why do it unless I need to?

Complexity/simplicity isn't everything. If an abstraction layer is more complex than its substrate but is also more consistent, intuitive, bug-resilient, maintainable, etc. then it may be a net win.

Do you have any example of such an abstraction layer?

A CPU is a lot more complex than wiring up your own NAND gates, but it's easier to write programs for the former.

It's impossible to "know everything about web development". That's not the point; nobody is demanding you become supreme master of every programming discipline.

But by being afraid of dabbling outside your comfort zone (because mastering things fully is "hard"), you inherently restrict the solutions you can possibly even conceive of to an incredibly limited set.

It's a sort-of Dunning-Kruger: You don't even have the basic knowledge to evaluate how often a better solution than "throw more javascript at it" was available to you and you didn't know it.

Computers store information in parking lots. Each space has a number. Most cars fit in one space, but some RVs and busses take up two or four spaces. If two cars are parked next to each other, one might be in space 4, and the next in space 5. But if two RVs are parked next to each other, one takes up spaces 4 and 5, so the other takes spaces 6 and 7.

A stupid parking attendant might count cars by asking: "what car is in space 4?" "An RV." "What is in space 5?" "The same RV."

But a smart parking attendant would obviously just ask "what care is in space 4?" "An RV." "Ok, so what car is in space 6?"

There, now you don't have a toolbox but at least it's a squeaky toy hammer.

When you want to upgrade to a solid rubber toy hammer, see:

http://baetzler.de/humor/paging_game.html

Speaking about pointers, it is just an abstraction about addresses which itself is an abstraction of the bit pattern generated to access a memory location, which is an abstraction of the analog electrical voltages on those physical wires, which is an abstraction of ......

abstraction of...ya go on i realy want to know what's beneath that if there is. would be very happy if you could recommend a book which goes so deep.(deeper then that preferebly!!)

Limiting yourself to a domain is one thing. It's like having narrow goals, which is fine. Limiting yourself to a set of programming languages is different. It's like using nothing but a given set of means, which is silly. So, you're a front-end web developer? Fine. You're a JavaScript programmer? Stupid.

Programming languages are tools, in the sense that they are mostly means to ends. But they are not ordinary tools, because they have a tremendous influence over the way you think. I reckon The sentence "PLs are tools" is improperly used most of the time, but not here.

As a side note, if you actually don't have a clue how pointer arithmetic works, check if you really understand plain ordinary variables. Pointers are just a second level of indirection away.

I'd say saying "I'm a C programmer" is more analogous to saying "I'm a helicopter pilot." You can probably fly a commercial jet or fighter, but they are very different aircraft, with very different use cases and operation.

And there will always be a market for helicopter pilots.

Training a pilot on a new aircraft is extremely expensive. Teaching a competent programmer a new language is dirt cheap in comparison (a week for the basics, 2 or 3 more for decent proficiency). So your analogy don't apply.

Plus, I bet I bet many pilots would get a kick out of learning a new aircraft, but can't afford it.

Sometimes language specialization is a result of domain specialization. If you're an embedded programmer or a game engine programmer, there is a good chance that you will use very little in your job other than C or C++. People don't necessarily set out to become proficient in a particular technology, it just happens that the technology is the best tool in their domain.

Yeah, it is interesting how chosing methaphors change the outcome. For example change 'carpenter' to 'artist' and 'hammer carpenter' to 'painter', 'musician' or 'sculptor' and you have different outcome. Or change carpenter to scientist. Or even change to mathematician: a set theorist is really dealing with different things than a number theorists. These metaphors really have their limitations.

Metaphors are necessarily colored by our perceptions and preferences. For instance, I'd say a set theorist is more equivalent to, say, an area specialist like an embedded systems developer, whereas a "javascript programmer" is like a mathematician who insists he's "only an addition guy".

I think the claim in the title still stands, though. Carpenters never call themselves hammerists, but there are cabinetmakers. The point inherent is that there's some truth to saying that a true programmer's skillset is only informed by but not demarcated by the languages he or she is fluent in. It's the Sapir-Whorf hypothesis in another form!

I'm an embedded programmer, and I had to write an XML parser for work. I've also written operating system code, 3d graphics, whatever. And ECMAScript too. Having such a narrow view limits were you can go, and what you can do. I specialize in a few things, but there's no programming task I'm truly afraid of, with at least being given a little time to read some documentation. "Specialization is for Insects."

I know so many people who've just done basic CRUD business programming. Smart people, really smart people, but they limit themselves; don't try to do anything deep and interesting, and it's sad.

I know so many people who've just done basic CRUD business programming. Smart people, really smart people, but they limit themselves; don't try to do anything deep and interesting, and it's sad.

I don't know much about CRUD business programming, but I do know in every field there are many levels of difficulties. Maybe these smart people are trying to solve those problems? If a system has simple atomic parts, it does not mean that every problem will be easy.

Edit: "Specialization is for Insects.", wow if you believe that, why do you live in an society. If you know every general thing, then you must be able to make your meal right? It will include farming, harvesting, cleaning of wheat, making your own bread (with equipments that you make on your own) and then slicing it and serving it. And that is just bread ;)

Re: "Specialization is for Insects"... Two extremes in one thread. :) There is a middle ground, where we have different levels of knowledge on a great multitude of things.

The other day, for example, I patched a hole in my own tire, rather than taking it to a shop. What if (a hypothetical) I, a self-proclaimed C programmer, needed a bugfix in a tool written in python? I can get my job done much quicker if I make a quick patch on my own, rather than wait for someone else to fix it for me.

Specialization is great; it is nice to have experts. Knowing many things is great; it is nice to have people who can do more than one thing effectively.

Just as a basic life survival thing, btw, you probably want to learn the basics of hunting, gathering, and farming. Some things are more important to know than others. :) Insects survive well as a species and much less well as individuals.

I do occasionally make my own bread, and I grew up on a farm. So? I'm not an expert in either, but I can dabble. Why keep yourself from learning something new?

An embedded systems programmer has absolutely no need to understand the intricacies of XML schema or the finer points of CSS parser bugs

They may not have a need, but they should be able to dig through all that because it's all just functions + data + dealing with some other idiot's code.

I have been witness to many JavaScript programmers who could have greatly benefited from good old fashioned pointer arithmetic.

Take the following code for example:

  /** BEGIN **/
  var f = new Array(3000000);
  console.time(1);
  for (var i = 0; i < f.length; i++) {
    if (f[i] === 'foobar' ||
            f[i] === 'foobaz' ||
            f[i] === 'baz' ||
            f[i] === 'barfoo') {
        // Do something
    }
  }
  console.timeEnd(1);
  /** END **/

On my comp, in Firefox, this executes in 7478 ms.

Now, if there is one thing that pointer arithmetic has taught me to be especially aware of is that array index lookups are expensive, usually regardless of the language. With this knowledge, I am empowered to refactor my code to look like this:

  /** BEGIN **/
  var f = new Array(3000000);
  console.time(1);
  for (var i = 0, _i = f.length; i < _i; i++) {
    x = f[i];
    if (x === 'foobar' ||
            x === 'foobaz' ||
            x === 'baz' ||
            x === 'barfoo') {
        // Do something
    }
  }
  console.timeEnd(1);
  /** END **/

On my comp, in Firefox, this runs in 6235 ms. Now, I have achieved almost a 20% performance increase due to my expanded world view.

This is a very simple example, but the list goes on. One certainly should not limit themself to one language.

It's a good example of how coming from different language can both help and inhibit programmer's thinking. Knowing C certainly helps to understand that repetitive array size and index access is likely to be more expensive than using local variables. At the same time C programmer is more likely to adopt an imperative programming style, which is in this case more error prone, verbose and doesn't allow for code re-use.

More ideomatic JavaScript would look like this:

    Array.prototype.foreach = function (f) {
       for (var i = 0, _i = this.length; i < _i; i++) f(this[i])
    }


    /** BEGIN **/
    var f = new Array(3000000);
    console.time(1);
    f.foreach( function (el) {
           if (el === 'foobar' ||
               el === 'foobaz' ||
               el === 'baz' ||
               el === 'barfoo')  // Do something

    })
    console.timeEnd(1);
    /** END **/

Well, describing oneself as a working programmer (as opposed to a computer scientist) is a valid position, but why does it invalidate the "programming language as tool" metaphor?

A basic message of CS is that most general-purpose programming languages are to a large extent isomorphic in their expressive power, and that many computing problems can be solved efficiently in the mathematical language of sets, matrices, or abstract nodes sending each other abstract messages. The translation to a real language is then the easier step (though it still can be time-consuming and error-prone, for sure).

If only we all worked this way - there would be fewer language wars, and less terrible code resulting from "thinking in the language" rather than "thinking about the problem".

The reason is that the programming language, in this usage, is not analogous to a single tool (like a hammer).

People build all kinds of complete things with just "C" -- where by this term, I mean the compiler, standard library, build and debug system (make/gdb, say).

There are few things of interest you can build with just a hammer. The evidence for this is that no craftsman builds with just a hammer.

The better analogy to the concept of "C" above is "wood shop" (as opposed to, say, "metal shop", "polymer shop", "electronics shop"). You still get the point, which is that everything out of the wood shop to some degree "looks the same" but it's not so clearly leading the reader to the hoped-for conclusion ("the statement is stupid").

So you're saying that the "language is a tool" metaphor breaks down because C is "complete" in a way that a hammer isn't. True, but that's taking the metaphor too far; it's original meaning is that the tool matters less than what you're building.

I was saying that the OP ("hammer carpenter") is taking the metaphor too far, which is why the phrase "hammer carpenter" sounds silly, and we seem to agree on this.

I have no problem with the conclusion that the tool matters less than what you're building.

I'd go farther and say that there is a certain tendency for C projects to "look the same" and that lispy projects "look the same" in a different way (e.g., surprisingly extensible, incorporating a language).

I think the point is, you'd have no problem learning pointer arithmetic if you needed it. It's not hard.

No the point is, he doesn't need it right now and as he has projected his future interest, in the future.

No, the point is, he can never evaluate if he'll ever need to know it, now or in the future, as long as he doesn't know anything about it.

It's impossible to evaluate the utility and applicability of knowledge you don't have.

While this may be strictly and pedantically true, the fact remains to declare ignorance of something, even complete ignorance, means you must have minimal knowledge of it. (even if the knowledge is merely existential). Paradoxically, this minimal knowledge is frequently be enough to deduce potential utility and applicability. (particularly with a descriptive name such as pointer arithmetic).