This is the first time I've clicked on a StackExchange thread and not seen "closed - not a real question".
Torvalds' quote about good programmers
61–70 of 108 posts
Re: Torvalds' quote about good programmers
#62You 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)…
As a new programmer I know I should ship a lot faster than I do, but focussing on data structures makes me really slow. I can usually jump a hurdle with a hack on my extant structures, but this introduces code complexity and leaves me at square one when a similar hurdle appears elsewhere. I try to be disciplined about fixing stuff at a data structure level, but changes there set off change propagations throughout the code. Or I introduce hacks into the data structures, which then become convoluted and start acquiring code of their own.
I find unit testing does help with all this. It forces exposure of the data stuctures, essentially documenting them. And good coverage gives a list of breakages and sometimes helps find elegant repairs. But I also find myself wanting high level-tests, I guess essentially integration tests, that check not components but overall behavior, and I find writing and maintaining these becomes a real problem.
But I really, really wish I had better tools / procedures for thinking through the problems and designing a proper data model for solving them.
Re: Torvalds' quote about good programmers
#63He's dissing OO there.
Re: Torvalds' quote about good programmers
#64This brings up a burning question that I have been pondering for a while. I still don't get how to properly design good APIs. I have been programming but as a scientific research not as a professional developer, and I have found I cannot remember how to use my code a day after writing that code.
Take my current project as an example. I have some samples, each of which are observations along a sequence of non-overlapping segments. My objective is to extract observations over arbitrary intervals for all samples. So I have a segment defined as a pair of start and end position plus its observation, a sample as a vector of segments, and all samples as a dictionary of samples. There are various utility functions to make segments, collect samples, and scan individual samples. The problem is I have to remember all three levels of data structures to use this code. I wonder whether it is better to define an interface for those data structures as well so I just need to remember the interface. My objections to formal definition of interfaces is that everything is so simple and obvious and formal interfaces smack of overengineering.
I got to this point because in my previous projects I put every identifiable thing as a class and found too much coupling in classes and convoluted interfaces.
Re: Torvalds' quote about good programmers
#65I believe Rich Hickey believes in keeping data really simple and writing the code around that. Could someone explain this philosophy to me?
Re: Torvalds' quote about good programmers
#66You 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)…
Agree, fixing bad data structures is much more painful than fixing bad code. The reason is that the deployment of the refactoring has the complexity of a new deployment, or even higher.
However, given that at large organizations updates and deployments can easily become political issues, it's a good habit to deploy often. That makes your life easier when trying to deploy new changes because those who are watching or performing the deployments get used to it - and the errors occuring during such deployments.
Re: Torvalds' quote about good programmers
#67This brings up a burning question that I have been pondering for a while. I still don't get how to properly design good APIs. I have been programming but as a scientific research not as a professional developer, and I have found I cannot remember how to use my code a day after writing that code. Take my current project as an example. I have some samples, each of which are observations along a sequence of non-overlapp…
Hi, I used to have a similar problem: seeing that when I do architectures they become difficult to maintain. Or difficult to talk about, to be honest, I don't understand your second paragraph :)
What really helped me is the approach to program API-driven. Don't start with your algorithms but start with what kind of functions you probably need and what would be the easiest way to use them. (In fact this is not so far from this data-centric approach as the most basic functions of APIs are usually function to retrieve or modify data.)
Try to read some good code from one of your favorite open-source projects. At some point some code may catch your attention because it's so simple and elegant. Why is it so elegant? Often because the underlying structures are just simple and made from common-sense. Don't over-engineer stuff, the simpler solution is often superior to the full-featured solution. And often you should ask yourself: do I really need this features currently to show some progresS? Shouldn't I not rather post-pone it?
Re: Torvalds' quote about good programmers
#68My 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.
Amen.
Re: Torvalds' quote about good programmers
#69So you are at some "Source" and you want to get to the required "Destination"(goal) -- what do you do ???? --- you plan your journey well. Let your plan take into considerations all the possibilities --- all pros an cons.
Good Programmers - well they plan; understand the requirements of the problem; case study or analyze the problem space; consider all(or most) of the possibilities to reach their goal(destination); then make a design (create a plan) and decide on the path(s) to be taken i.e. choose data structures, algorithms, programming language, and other factors. Having understood the pros and cons of their design; they begin to code. This process generally works most of the time; but there are times when you go mid way and then change the design or might consider another alternative(like data-structures); this generally happens when you've missed some problem space to analyze earlier while planning. None-the-less; planning well ahead of time; before you begin coding helps get a good product and helps save a lot of time, money and effort.
Bad programmers on the other hand know about their Destination(goal) but do not know how to get there; they simply jump into coding hoping that they would someday get to their destination. This too works, but it takes more time; and when one realizes that one has made a mistake; it becomes very difficult to come up with a new plan to move forward from that point. The product loses its quality. Often you land up starting again from square zero.
Re: Torvalds' quote about good programmers
#70You 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)…
As a new programmer I know I should ship a lot faster than I do, but focussing on data structures makes me really slow. I can usually jump a hurdle with a hack on my extant structures, but this introduces code complexity and leaves me at square one when a similar hurdle appears elsewhere. I try to be disciplined about fixing stuff at a data structure level, but changes there set off change propagations throughout the…
This article was an eye opener for me:
http://www.dodgycoder.net/2012/07/old-school-developers-achi...
"Old school developers - achieving a lot with little"
I'll quote:
> [Ken Thompson] debugs only via printf statements, hardly ever uses unit tests, starts his projects by designing the data structures and then works bottom up, with throwaway test stubs.
Also, Joe Armstrong, the father of Erlang:
> He uses prototypes to solve the hard problems first, and for debugging, just uses print statements. He is a critic of Object Oriented Programming, and favours functional programming languages like Haskell. He never uses an IDE, preferring just Emacs and the command line (no mouse required).
Also, Jamie Zawinski:
> During development he hardly ever uses unit tests, believing it slows things down - he thinks there's a lot to be said for getting the code right first time. In his view, its a matter of priorities, "do you want this to be good software or do you want it to be done next week - pick one because you can't have both".