I'm not so sure about the "don't touch other people's code, and don't allow them to touch yours" bit. What if someone gets hit by a truck? Or leaves the company? Or shrug makes a promotion? I've been pretty comfortable about the "collective code ownership" approach, within small enough teams, in the last 4 years. You can talk issues over with a colleague and he knows what you're on about, code reviews become effective, and getting something important changed does not mean you have to wait for the 'owner' to have time for it. What's wrong with that?
Holding a Program in One's Head (2007)
51–60 of 104 posts
Re: Holding a Program in One's Head (2007)
#52Earlier quoted context omitted.
That's begging the question. To come up with the abstractions in the first place requires understanding the whole problem. There's no getting around this. I can't tell you how many programs I've seen where the wrong abstraction is never perturbed, and as a result all feature development pays a huge cost in reliability and functionality. To create or change an abstraction, you have to get your mind around all sides of…
The "whole problem" is simply a process. Processes in the real world are composed of 1-* sub-processes, and ultimately distill down into transformations (input -> transformation -> output). You don't need to understand every low-level process to make a start. You raise two interesting points though. Yes, revisiting an architecture is required when you've not solved a similar problem before. Consider though that in th…
> Consider though that in this community 99.9% of the time others have solved your problem before. You could reinvent the wheel (which is arrogant), or you could do some research to see which architecture has been successful for others.
The best way to learn something is to come up with it yourself. If you base your architecture on what you read in books or elsewhere, you probably only have a limited understanding of it. And that's especially bad when you're talking about the architecture of a program.
So maybe a better idea in terms of the end result is to first come up with your own solution, implement at least a functioning prototype, and then do some research, to improve upon your idea based on what you have discovered (or throw it away, in the worst case, but of course keep what you've learned doing it).
Re: Holding a Program in One's Head (2007)
#53Earlier quoted context omitted.
What about Haskell? The type system tells you exactly what's going on.
Some tools are better than others. I'm not familiar with Haskell but can tell you that in the .NET world LINQ is bad, because it forces the melding of process components with data access logic.
Haskell has it's own warts of course, but the functional straightjacket you're forced into makes it very easy to understand the scope of a computation.
Re: Holding a Program in One's Head (2007)
#54You should never need to hold the entire program in your head ! (except when you actually begin coding it - for this early stage of development I agree with PG). Needing to hold a whole mature program in your head every time you work on it is a code smell that tells you your solution ended up in the shape of the most popular software architecture of all time: the "big ball of mud" ( http://www.laputan.org/mud/ ). Now…
Holding the entirety of the problem in your head is a necessity when the program is an algorithm, and especially if its a hermetic algorithm.
...that's probably why algorithms are never too big to hold in your head (except crypto, for my head at least :) ), at least once you understand them ...and software tends to be "overgrown" at the interfaces, be it UI or IPC or some networking protocol, not where the "complex" algorithms are anyway (probably because if you can find a mathematically expressible algorithm to do something it doesn't overgrow like a mad bush, even if you add a dozen branches for special cases...)
...and I'm not entirely sure that most algorithms are truly "hermetic" ...maybe in some areas most of them are, dunno...
Re: Holding a Program in One's Head (2007)
#55It's actually an indictment of our programming tools that they require one to hold so much of the design context in one's head. If they were better (more expressive, easier to interact with) they would help to solve the problems rather than require superhuman feats of endurance. pg does mention that succinct programming languages help, which is true, but they don't go nearly as far as they could. Like him, I use Lisp…
> It's actually an indictment of our programming tools that they require one to hold so much of the design context in one's head. No, it's not, because we will keep looking for the limits. Once a programming tool allows you to do alone what you need 10 engineers for now, some genius will use those tools to do what you need 10 engineers for then , and then teams of 10 engineers will try to copy that. We'll always be d…
Does not follow. Holding stuff in our heads is not the only bottleneck in programming. For example, it's not the bottleneck when solving almost any Olympiad style problem, and yet those exams seem to do a good job of stratifying people.
Re: Holding a Program in One's Head (2007)
#56Earlier quoted context omitted.
The "whole problem" is simply a process. Processes in the real world are composed of 1-* sub-processes, and ultimately distill down into transformations (input -> transformation -> output). You don't need to understand every low-level process to make a start. You raise two interesting points though. Yes, revisiting an architecture is required when you've not solved a similar problem before. Consider though that in th…
> Consider though that in this community 99.9% of the time others have solved your problem before. You could reinvent the wheel (which is arrogant), or you could do some research to see which architecture has been successful for others. The best way to learn something is to come up with it yourself. If you base your architecture on what you read in books or elsewhere, you probably only have a limited understanding of…
You're describing semantics of moving from a solution concept to an implementation. How you get there is entirely up to you.
What I was suggesting is that a design that separates concerns will obviate the need to keep the entire thing in your head. This is problem solving through the composition of discrete components. AKA managing complexity.
Re: Holding a Program in One's Head (2007)
#57Peter Naur wrote on this subject in 85 and came to much the same conclusions.
Here is the paper for anyone interested http://www.google.dk/url?sa=t&source=web&cd=1&ve...
Re: Holding a Program in One's Head (2007)
#58Earlier quoted context omitted.
One way to solve the ambiguity problem of natural languages is using a controlled natural language, which is a limited subset of a natural language[1]. Some of those are machine transformable to logic. There's even some work to encode legal knowledge using them. [1] http://en.wikipedia.org/wiki/Controlled_natural_language
Thanks, interesting! Not mentioned on that page, but a notable natural language which is similar in its goals is Lojban [1]. It's actually based on predicate language, which is actually what Inform 7 uses as well in order to derive the actual meaning from natural language sentences. It manages this because it is based on a limited subset of English. But I'll note that we humans manage to understand each other just fi…
I'd just like to point out that Lojban is a constructed language, not a natural language. It was designed and built from the ground up, as opposed to the GP's controlled natural languages which are pre-existing human languages with a bunch of stuff stripped out of them.
Re: Holding a Program in One's Head (2007)
#59It's actually an indictment of our programming tools that they require one to hold so much of the design context in one's head. If they were better (more expressive, easier to interact with) they would help to solve the problems rather than require superhuman feats of endurance. pg does mention that succinct programming languages help, which is true, but they don't go nearly as far as they could. Like him, I use Lisp…
* why hasn't the state of the art advanced since then?
The Fred Brooks essay "No Silver Bullet" is a good place to start:
http://www.cs.nott.ac.uk/~cah/G51ISS/Documents/NoSilverBulle...
Re: Holding a Program in One's Head (2007)
#60Earlier quoted context omitted.
> It's actually an indictment of our programming tools that they require one to hold so much of the design context in one's head. No, it's not, because we will keep looking for the limits. Once a programming tool allows you to do alone what you need 10 engineers for now, some genius will use those tools to do what you need 10 engineers for then , and then teams of 10 engineers will try to copy that. We'll always be d…
Does not follow. Holding stuff in our heads is not the only bottleneck in programming. For example, it's not the bottleneck when solving almost any Olympiad style problem, and yet those exams seem to do a good job of stratifying people.
Those types of problems are not programming problems per se, but more like riddles for math inclined. Once you know the solution, the coding tends to be rather trivial with regard to control and data structures.