Torvalds' quote about good programmers • Hacker News Board

Re: Torvalds' quote about good programmers

#41

Post by ryanmolden » Sun, Sep 23, 2012, 3:19 PM UTC

hermannj314 wrote: post #13

mtkd wrote: post #12

You can normally fix bad code - fixing bad data structures is not usually easy or even possible. It's why I've still not fully bought in to 'release early release often'. I prefer to defer releasing for production use until really satisfied with the structures - this way you have no barrier to ripping the foundations up. If not 100% comfortable with the model - prototype a bare metal improved one (schemaless DBs ftw)…

I'm in the position of maintaining a legacy codebase. I feel like I've shown up half-way through a game of Jenga and management still wants me to play the game with the same speed as the guy who played the 1st half. Meanwhile, he's been promoted to start work on a brand-new Jenga tower since he's demonstrated such remarkable success in the past. I just want everyone to stop playing Jenga.

I've always, only half-snarkily, said that if you have never had to maintain/modify someone else's code then you probably write code like an asshole. Writing code that is both easy to understand and maintain and correct can be difficult, lots of people just go for the latter.

Unfortunately as you pointed out, especially in large companies, people can get promoted before the deficiencies of their previous work become clear. This leads to people never learning because the feedback loop is too long, or worse, they never deal with their past code so are oblivious to all its shortcomings and just think they are awesome. Also management tends to reward based on accomplishments today without an eye for costs to be born down the road, which gives perverse incentives to "get it done" programmers who leave mountains of technical debt in their wake for others to deal with.

Re: Torvalds' quote about good programmers

#42

Post by antidoh » Sun, Sep 23, 2012, 3:20 PM UTC

barrkel wrote: post #40

antidoh wrote: post #35

Earlier quoted context omitted.

"This is approximately the same reason as why I start out writing most of my programs by creating a bunch of types, and why I find dynamic programming languages uncomfortable to use." Classes. There are your types. Python has them. Ruby has them. Javascript has them. . . .

If you can't see see the qualitative difference between algebraic data types and Javascript classes, there's no point discussing things.

OK.

Re: Torvalds' quote about good programmers

#43

Post by KevinMS » Sun, Sep 23, 2012, 3:21 PM UTC

I think this can be distilled down to: "bad programmers worry about how, good programmers worry about why"

Re: Torvalds' quote about good programmers

#44

Post by dasil003 » Sun, Sep 23, 2012, 3:46 PM UTC

antidoh wrote: post #35

barrkel wrote: post #17

This is approximately the same reason as why I start out writing most of my programs by creating a bunch of types, and why I find dynamic programming languages uncomfortable to use. I'm less and less a fan of the ceremony of object orientation, but I think there's a lot to be said for having a succinct formalized statement of your data structures up front. Once you understand the data structures, the code is usually…

"This is approximately the same reason as why I start out writing most of my programs by creating a bunch of types, and why I find dynamic programming languages uncomfortable to use." Classes. There are your types. Python has them. Ruby has them. Javascript has them. . . .

Javascript only has Objects not Classes.

Re: Torvalds' quote about good programmers

#45

Post by auggierose » Sun, Sep 23, 2012, 3:46 PM UTC

barrkel wrote: post #38

hcarvalhoalves wrote: post #37

Earlier quoted context omitted.

Data structures != Types Dynamic languages are not an argument to make bad use of data structures in any way, it changes nothing.

I think you missed my point. I wasn't arguing against bad use of data structures; just for a formalized, checked description of the data structures used in the program. I have in the past written preprocessors for this purpose. A simple language just to describe the types used in the program, with the output being the implementation language's definition of the type, as necessary. I've even done it in Javascript, in…

I totally get what you are saying. I also have the difficulty that when programming in Clojure and starting on a new problem, there is no really good way of writing down the data structure. I still love the flexibility of Clojure, though, so now I am trying to work around this by writing down proper documentation of the data structure instead of representing them exclusively with types.

Re: Torvalds' quote about good programmers

#46

Post by antidoh » Sun, Sep 23, 2012, 3:53 PM UTC

dasil003 wrote: post #44

antidoh wrote: post #35

Earlier quoted context omitted.

"This is approximately the same reason as why I start out writing most of my programs by creating a bunch of types, and why I find dynamic programming languages uncomfortable to use." Classes. There are your types. Python has them. Ruby has them. Javascript has them. . . .

Javascript only has Objects not Classes.

Thanks, I stand adjusted. And of course you can use prototypes (objects) for the same intent as classes, which was the source of my error.

Re: Torvalds' quote about good programmers

#47

Post by robomartin » Sun, Sep 23, 2012, 3:59 PM UTC

Absolutely right. I was lucky enough to learn this in college. Although, I did not learn it from the CS professors but rather my physics prof. He was a champion for a language called APL and he actually cut a deal with the CS department to accept credits for taking an APL class he was teaching as a substitute for the FORTRAN class. APL was an amazing mind-opening experience.

Throughout the APL 101 and 102 courses he would repeat this mantra: "Work on your data representation first. Once you have fully understood how to represent your data start thinking about how to manage it with code."

He would throw this at us permanently. At the time it sounded like our Physics prof had lost his marbles (he was a very, shall we say, eccentric guy). It would take a few years after college for me to realize the value of that advise.

Put another way, our business is managing data of some sort. Whether you work on embedded systems or web applications, you are always dealing with data. You can make your programs far more complicated than necessary by neglecting to choose the right (or a good) representation of your problem space (data).

I equate it to designing an assembly line. Anyone who's watched a show like "How it's Made" cannot escape the realization that efficient manufacturing requires engineering an efficient assembly process. Sometimes far more engineering work goes into the design of the manufacturing process and equipment than the part that is actually being made. The end result is that the plant run efficiently and with fewer defects than alternative methods.

In programming, data representation can make the difference between a quality, stable, bug-free and easy to maintain application and an absolute mess that is hard to program, maintain and extend.

Re: Torvalds' quote about good programmers

#48

Post by kobolt » Sun, Sep 23, 2012, 4:13 PM UTC

This is similar to the rule of representation from the Unix philosophy, covered here: http://www.faqs.org/docs/artu/ch01s06.html

"Rule of Representation: Fold knowledge into data so program logic can be stupid and robust."

Re: Torvalds' quote about good programmers

#49

Post by jt2190 » Sun, Sep 23, 2012, 4:17 PM UTC

mtkd wrote: post #12

You can normally fix bad code - fixing bad data structures is not usually easy or even possible. It's why I've still not fully bought in to 'release early release often'. I prefer to defer releasing for production use until really satisfied with the structures - this way you have no barrier to ripping the foundations up. If not 100% comfortable with the model - prototype a bare metal improved one (schemaless DBs ftw)…

You're just hung up on your definition of "release", which is "release for production use". "Release early release often" doesn't dictate how you release your application, just that you expose it in some form (private beta, public beta, pre-release) to the real world for vetting. Projects that fail to vet their assumptions are more prone to poor data structures and over-engineering.

Re: Torvalds' quote about good programmers

#50

Post by nahname » Sun, Sep 23, 2012, 4:24 PM UTC

mtkd wrote: post #12

You can normally fix bad code - fixing bad data structures is not usually easy or even possible. It's why I've still not fully bought in to 'release early release often'. I prefer to defer releasing for production use until really satisfied with the structures - this way you have no barrier to ripping the foundations up. If not 100% comfortable with the model - prototype a bare metal improved one (schemaless DBs ftw)…

The whole point of continuous delivery is that correcting things like data structures is no longer the big deal it once was because it happens frequently. Rather than letting months (or years!) of data migrations pile up, you have a few days worth (or weeks). In my opinion, it is best to ship something that works today and have a system in place that makes correcting it as painless as possible.

That's the real problem with the current model. The data structures will never be perfect and you cannot know how they will change. Yet they do. Then all the FUD from the last migration that scared everyone prevents the team from due diligence and correcting issues when they are discovered. The team waits until the problem comes to a head, management has to be involved, new FUD is created and people dream about perfect data structures to prevent this whole mess.

Remember,

Shipping > Shipping Shit > Not Shipping