51–60 of 108 posts
Bad novelists worry about the plot. Good novelists worry
about the characters and their relationships.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…
I always start my Haskell projects by laying out the data types. The type declarations are very readable--you can just skim over them to see what's going on. This means that you can get a very good overview of what the project wants to do just by quickly looking over what types it declared, and then looking through functions' type signatures.
Then, after you have the data types defined, the resulting code is not only easier to read but reflects the data operations it is doing. I've found the type signatures above each function--which are optional but highly recommended--really help tie the code back to the data it operates on. Additionally, pattern-matching against the data makes the structure of most functions clearly reflect the exact data it is working on.
The low overhead of creating Haskell types also makes it very easy to add aliases to existing types. So perhaps you use a `Map Int String` in your code; you then give it a domain specific name:
type IdMap = Map Int String
So if you really like a more type/data directed style of programming but are getting tired of OOP, you should definitely check out Haskell (or something similar like OCaml).
quality of code indicator = [code changes] / [database schema changes]
Related quote:
"Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowcharts; they’ll be obvious." (Fred Brooks)
Earlier 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.
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…
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 correctness-preserving transformations. That is, without even knowing what the code is doing. I even spotted some bugs in the process.
Earlier quoted context omitted.
any concrete examples you can point to?
Suppose you want to manage the marital status of some people. You could have one data structure, here a table in a database, where you keep (name, status) tuples. This is bad, for many reason: what if someone changes name? If you need to allow undoing, how can you know which was the previous status before "maried" has been entered (widow? Single?) A better data structure here is an event table (who, did what, when),…
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, married, name from, to.
But there are also about a dozen othe better solutions than the one you describe.
Algorithms + Data Structures = Programs A 1976 book written by Niklaus Wirth, designer of Pascal http://en.wikipedia.org/wiki/Algorithms_%2B_Data_Structures_...
The problem with code quality is that there's so much AND-ing that most people give up on understanding this massively difficult problem that is as much social and industrial as it is technical. One of the first things you learn about systems is that parallel dependencies (OR-gates) are better than serial dependencies (AND-gates). The first has redundancy, the second has multiple single points of failure. That's also…
The fact is that one person armed with clear understanding of quality code can be the seed of change. Even under siege from bad data structures and opaque processes, it is possible for a programmer to carve out a small niche, to normalize (at least in his mind) the system he's been given to modify, and apply his knowledge correctly.
If he can execute projects quickly and relatively error-free, this programmer will do well in any organization, and he will probably be given a team of his own, and that team will probably be a good one, and the codebase will continue to change slowly, organically.
If the programmer leaves, then the bad code will grow again. That is the nature of life!
In any event, I just want to emphasize that there is great value in understanding and doing good work, even if (perhaps especially if) the constraints you're working under don't encourage it. YOU are the seed of change.
Earlier quoted context omitted.
10 people learn about techniques A, B, and C who didn't before. 10 other people start thinking in terms of metrics N1 and N2 who weren't before. We learn and improve collectively. I think that is a pretty amazing thing about the internet and boards like this. That's not to say that some things don't get passed around a lot , but that's generally because they're worthwhile enough to make sure that everyone gets a look…
I agree 100%. To me, one of the downsides of many internet discussion is that it seems complicated issues get reduced to a single dimension just to get enough traction to have the conversation. And then most of the conversation is between the camps that have internalized and accepted the simplified mental model of the problem and those that haven't. Maybe that's is a good thing for the reasons you highlight. In my op…
Well, who's fault is that? Pick a perspective and follow it deeply, write about it, and fish deeper. All it requires is commitment.
You could certainly pick a worse position that the OP's! Data is far more important than code - although I fear that this point is obscured by the "web service" trend that tends to spread data across many legal/economic/technical 'zones of control'.
Anyway, I hope that rather than just lament the state of things, that you take action to change it, at least for yourself.
So I think a program's conceptualisation of a problem is the most important thing - more important than data structures or code. Though, data structures are usually closer to it, by representing the concepts you model.
However, it's really hard to get these things right. Linus created both his great successes (linux and git) after experience with similar systems (unix/minix and bitkeeper). Being able to play with an implementation, experience its strengths and weaknesses, gives you a concrete base to use, reason with, push against, and come up with new insights - it's enormously helpful in seeing the problem.
But that's a grand vision - I wonder if Linus is also talking about programming in the small, each step of the way, as a low-level pragmatic guide. I don't like git's interface or docs much, but the concepts are great, it is implemented really well, very few bugs, and even on ancient hardware boy is it fast.
This is one of the few programming quotes that is not just abstract crap, but one thing you can use to improve your programming skills 10x IMHO. Something like 10 years ago I was lucky enough that a guy told me and explained me this stuff, that I was starting to understand myself btw, and programming suddenly changed for me. If you get the data structures right, the first effect is that the code becomes much simpler…
any concrete examples you can point to?
Or I can decompose my application so that I maintain only one number, and modify the update mechanism to support firing off routines when it updates.
So, we went from two numbers, to one number and a lookup table (the table that tracks which routines need to fire). And the code will be vastly simpler in the second case.
(This is probably not the best example - there are probably some nice database normalization problems that highlight the benefits of good data structures a lot better).