Live data from Hacker News

Torvalds' quote about good programmers

programmers.stackexchange.com

101–108 of 108 posts

Re: Torvalds' quote about good programmers

#101
post #87
post #55

Earlier quoted context omitted.

You're completely neglecting how the data will be used, by using an rcs like data storage of deltas you penalize the common case of wanting to query the current state efficiently. A better way would be to store a person table without name and a marital status but use it a a primary key into a detail table that has multiple rows for any individual along with dates so you have a row representing the persons state, marr…

What you describe is just a denormalization of my solution. You are already optimizing a proposal that was designed as a very short example of a better data structure. That's absurd. If you need to access often the current marital status you can cache it, store it on the client, use a materialized view, write it in a file along with other info, etc. I would advice personally against the plain denormalization you prop…

If you want to keep marital status history, then the marital status is a SCD [0]

With Rails-like conventions, here's a minimalist Type II SCD definition:

    +--------+    +-----------------+    +----------+
    | people | -> | people_statuses | 
where person_statuses.until is the last date where this relationship is valid.

The logic follows from the data structure definition in a natural manner.

'WHERE person_statuses.until IS NULL' will immediately give you the last status of someone/everyone. You can trivially update one's status by UPDATEing 'until' and INSERTing a new record, wrapped in a transaction. Additionally, you can use until as a guard WHERE clause for such an update to implement a form of optimistic locking.

You can also add a column relating a person to another. With a slightly more complex query you can easily make the relation symmetric and remove the need for 'duplicate' reciprocal records.

Handling name changes and preserving navigable history in the people table is not much harder.

The wikipedia page about SCDs gives interesting cases.

[0] http://en.wikipedia.org/wiki/Slowly_changing_dimension

Re: Torvalds' quote about good programmers

#102
post #101
post #87

Earlier quoted context omitted.

What you describe is just a denormalization of my solution. You are already optimizing a proposal that was designed as a very short example of a better data structure. That's absurd. If you need to access often the current marital status you can cache it, store it on the client, use a materialized view, write it in a file along with other info, etc. I would advice personally against the plain denormalization you prop…

If you want to keep marital status history, then the marital status is a SCD [0] With Rails-like conventions, here's a minimalist Type II SCD definition: +--------+ +-----------------+ +----------+ | people | -> | people_statuses | where person_statuses.until is the last date where this relationship is valid. The logic follows from the data structure definition in a natural manner. 'WHERE person_statuses.until IS NUL…

That's interesting, thanks. I still wonder if a simpler event table is not a better data structure, mostly because it is a read write only structure, no need for updates. Granted, getting the current status is a bit slower but keeping pointers to the latest event plus chaining events can fix it.

Re: Torvalds' quote about good programmers

#103
IMHO: That's why good programmers love Lisp.

Lisp is all about data structures. Data can be expressed so easily no matter how complex it is. Lisp coding is merely writing minimum code to handle data structures. Even code is data. So it's no problem to extend Lisp with new commands. That's precisely coding around data.

In Java or C# however you have a lot of libraries to handle data but you don't have such freedom of data expression. You have to write a lot of code to express and handle complex data.

Re: Torvalds' quote about good programmers

#104

My only problem with this quote is it equates "new" programmers with "bad" programmers. Yes if you still have these problems after 10 years of professional work, then you're a bad programmer, but if you show these symptoms after 6 months it just means you're still learning. There's got to be a better way of stating this.

A new programmer is a bad programmer. There's no shame in that. In fact it's better for a new programmer to realise that; the worst programmers are those that don't even realise they are bad. A new programmer may still be learning, but that doesn't mean they aren't bad. It just means they are bad now, and hopefully won't be bad later.

Even an experienced programmer can still be a bad programmer.

I realized that myself when I learned Ada. You cannot imagine how humbling an Ada compiler can be :-) This is possibly the reason why Ada is not popular at all. It exposes how bad you really are. Java, C#, and even C++ are much more tolerant and can easily give you the illusion of being a good programmer

I am experienced in really many programming styles and languages. Ada and Lisp and their programming paradigms advanced my programming skills the most. Ada, because of its merciless requirement of discipline, and Lisp because it teached me to focus on data instead of code.

Re: Torvalds' quote about good programmers

#105
post #98

Earlier quoted context omitted.

I think that, to some degree, becoming an effective APL programmer almost required becoming good at data representation. If you want to do things the "APL way" you have to think about structures that work well with array, matrix and tensor processing ideas. When you could represent your data in the most optimal way you could sometimes write a function with only a few operators that could do what needed to be done to…

Interesting comments. I've been working with an APL-derivative and this sounds similar to how I have been thinking about things. It's a matter of massaging the data to get in into a certain representation, e.g. a matrix, then from there it's very, very easy to work with using APL. As you say a few operators is all you need. The code is very terse. Very powerful. The real work seems to be shaping the data into the rig…

Right. I remember having fun with this doing an APL application to aid in DNA sequencing. There were a number of ways to represent the data provided by the sequencer. At one point it almost became a game to see how small of an expression one could create to process the data by changing the representation.

With APL one has to be careful not to create monsters that cause geometric expansion in memory needs.

If the data set is large and the expressions processing the data cause frequent expansion into matrices or tensors (n-dimensional data structures where n > 2) one could end-up with geometric or exponential memory requirements. This, again, is another case of having to understand and fit data representation to the programming language AND the approach one will use to work with the data.

While languages like APL can be great, they can be disastrous in the hands of a programmer who does not understand what might be going on at a lower level. Sometimes there's nothing better than good-old low-level C.

Re: Torvalds' quote about good programmers

#106
post #88
post #82

Earlier quoted context omitted.

Try to implement the game Asteroids without a thought about data structures, just start programming it procedurally as it comes to you. See how far you get in, say four hours. Find a graphics library, of course. Then, use a very simple object oriented model, where everything on-screen (asteroids, ships, enemy ships, shots) has a draw method, a move method, a create method, and an I'm-hit method, together with logical…

This is the power of designing before you code. Nothing to do with data structures. Data structures are part of the design but you're focusing on the object oriented design aspect.

You know, I put in a caveat anticipating this objection, but since you raised it, let me offer the following counterpoint:

You could implement the approach I described in a language without any OO support, and still come out ahead.

Just do it in plain C using function pointers for methods, and write your own dispatcher. Or, do it in assembly (I implemented this approach in PDP-11 assembly).

If you do it this way, it really is all about the data structure -- the methods are subordinate to the data structure, acting just like other state. You could even change the methods after objects have been created -- for example, swap in the "evasive maneuver" move method once you fire on an alien ship, so that the alien goes from lazy drifting to taking evasive action.

Re: Torvalds' quote about good programmers

#107
post #51

This seems to apply to all kinds of "writing" (symbol sequence generation), from math to poetry, though the terms differ, e.g.: Bad novelists worry about the plot. Good novelists worry about the characters and their relationships.

That's more a value judgement. As Samuel Johnson said, "No man but a blockhead ever wrote, except for money." "Bad" novelists who worry about the plot can make a lot of money.
Post reply on HN