This is the first time I've clicked on a StackExchange thread and not seen "closed - not a real question".
give it time...
Torvalds' quote about good programmers
91–100 of 108 posts
Re: Torvalds' quote about good programmers
#92Earlier quoted context omitted.
> Writing code that is both easy to understand and maintain and correct can be difficult, lots of people just go for the latter. They believe they go for the latter, but actually they don't. If their code was easy to understand and correct, it would have fewer defects to begin with. Your second paragraph I totally agree with. I've dealt with such code. Sometimes, I can halve its volume simply by applying local correc…
'correct' is always only about a given specification, that is right for a limited period of time, assuming needs are well understood. It is very well possible to write satisfactory code one day that becomes inadequate the next. I won't deny the presence of bugs though, there is endless evidence that bugs always exist.
Correct, I was talking mainly about code that 'works' (i.e. is 'correct', for the given spec) but is highly sub-optimal, confusing, tightly coupled with other code, etc...
Re: Torvalds' quote about good programmers
#93Absolutely 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…
Your prof was onto something that seems to be very in the zeitgeist today. To "understood how to represent your data" you have to understand what it is you're trying to represent. Eric Evans popularized this notion with Domain-Driven Design. If you follow this line of thinking far enough, you realize that computer programming is just applied analytic philosophy. You have your metamodel (logic/programming language) an…
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 that data.
This means that, to some extent, data representation might have several local minima (in terms of being optimal) with each population of possible representations exists around the language or toolset you are going to use to process this data.
What I mean is that the optimal data representation for an embedded system (as an example) written in assembler might be different than that of the same system written in C or Forth.
I don't use APL very much any more. Back when I did I was also programming in Forth, C and Assembler. I know that the decisions I would make --in terms of optimal data representation-- varied from language to language. This is partly true because each language, in my case, was being used to deal with different problem domains. For example, APL could do high-level computations while Forth was great for low-level, real-time stuff.
Re: Torvalds' quote about good programmers
#94To paraphrase, if I may, a novice imagines that the goal of programming is to create code which solves a problem. This is true, but limited. The real goal is to create an abstract model which can be used to solve a problem and then to implement that model in code.
I really hope that people reading this know to apply Ockham's Razor to their abstract models (lest they write a lot of AbstractSingletonProxyFactoryBeans).
Re: Torvalds' quote about good programmers
#95Earlier quoted context omitted.
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…
That article summarizes parts of the book Coders at Work, which has all sorts of other interesting stuff in it. The book's web site gives brief bios for all the programmers who are interviewed in it: http://codersatwork.com
Re: Torvalds' quote about good programmers
#96Earlier quoted context omitted.
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.
If only there was a way to measure programmers on the robustness and potential of their code, and not just on "they wrote a lot of it." The system seems to be that it is much more advantageous to your career to rapidly produce gobs of spaghetti -- and confound everyone around you -- than to build elegant code that enables everyone around you. You look better when everyone but you is confounded; you look replaceable w…
The more code I see, the lower my estimation of the coder. The mark of a talented engineer is how much code they delete.
Re: Torvalds' quote about good programmers
#97Earlier quoted context omitted.
There's other options than "release early release often" and "waterfall".
What might those be? Honest question. My inexperience is probably showing, but I have a hard time picturing what the middle ground might look like.
Lifecycles are either sequential or iterative. But there's a lot of differences in the lifecycles, and many more models than usually assumed. For example spiral development, throwaway prototyping, evolutionary prototyping, staged delivery, design-to-tools, design-to-schedule, modified waterfall (a sequential, iterative process) and more.
Read McConnell's 'Rapid development' for a walkthrough of the ones above and then some.
Re: Torvalds' quote about good programmers
#98Earlier quoted context omitted.
Your prof was onto something that seems to be very in the zeitgeist today. To "understood how to represent your data" you have to understand what it is you're trying to represent. Eric Evans popularized this notion with Domain-Driven Design. If you follow this line of thinking far enough, you realize that computer programming is just applied analytic philosophy. You have your metamodel (logic/programming language) an…
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 right representation first, a matrix. I use non-APL-descendent programs, the usual UNIX utilities, to do this for now.
Re: Torvalds' quote about good programmers
#99I always do it the other way around (when starting software from scratch):
0. write the simplest mock/pseudo-code I can think of for the business logic that needs to be implemented
1. extract from this ideal code the data structure that it needs in order to actually be so simple and write real code that implements these ideal data structures
2. write the real code that actually does the work
I think Linus means the same thing, but he doesn't get it that in order to imagine those "perfect data structures" he has to start with some idea of the code that will be using them, otherwise they will not be "perfect" for his program. I'm sure he's just smart enough to go through my "0" step in his mind without actually writing things down.
It's an obvious case of very smart people omitting the steps that are obvious/implicit to them when expressing their ideas to "lesser minds"...
Re: Torvalds' quote about good programmers
#100He's dissing OO there.
Why would he do that? Large parts of the kernel are designed using OO concepts :S