Hacker News Reader

Comment by nemo1618 | Hacker News Reader

The distinction between "hacking" and "protective" languages is a good one. If you want to be balanced as a programmer, you need to deeply understand at least one language in both categories. Protective languages are wonderful for large-scale projects (true "software engineering"), but they tend to lack the whimsy that drew so many of us to programming in the first place.

View on HN

A similar distinction was made by Yegge before [1], which he (unfortunately) labeled as "liberal" and "conservative". It was quite controversial [2].

Another similar idea is Fowler's software development attitude [3]. He uses the terms "enabling" and "directing" instead.

[1] https://plus.google.com/110981030061712822816/posts/KaSKeg4v...

[2] https://news.ycombinator.com/item?id=4365255

[3] https://www.martinfowler.com/bliki/SoftwareDevelopmentAttitu...

It's hard to describe, but the discourse on hn in 2012 just felt different in some weird way.

The tone of the posts seems about the same as now to me, but the top level comments do seem to be longer and with more analysis than most top level comments lately.

Can you elaborate? What languages would fall in either category (I’m assuming python would be hacking and haskell would be protective)? Does static vs dynamic typing play a role?

Not the original poster. But I would call C and C++ hacking languages. They were designed to make really low level work possible. You haven't written low level code until you had to access hardware registers by memory address :). This is such a completely different experience from really high level languages that I feel that the distinction should effectively be closer to the compiled/interpreted (JITed) divide.

Low-level languages are almost always "hacking" languages, since direct hardware access inevitably brings with it a degree of unsafety. But the reverse is not true: "hacking" does not imply "low-level," as exemplified by Python, Lisp, etc. I'd be really interested to a low-level "protective" language, if such a thing is even possible. Something like Hoon, maybe?

Any language that has a C FFI (and that his a whole lot of them) provides easy access to low-level features. The managed languages (Java especially) make this harder than it should be.

At any rate Rust and Swift are both good examples of efficient languages that can easily make use of low-level system and processor features and which offer a good C FFI.

I would argue that C++ (or at least, modern C++) aims to /enable/ one to treat it as either. It gives the programmer the power to write very low level code if they wish, but also to define type safe interfaces and high level abstractions which allow the programmer to trust the glue that binds together their blocks of code.

Reply on news.ycombinator.com