work in long stretches
Nope, that idiotic open offices isn't conducive for that.
Holding a Program in One's Head (2007)
11–20 of 104 posts
Re: Holding a Program in One's Head (2007)
#12It'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…
Sounds like you have a number of tangible, palpable, feasible ideas for such super-smarter next-gen programming tools -- care to share?
(Just hoping what you have in mind isn't UML + SOAP + some unintelligable über-abstracted-meta-code-gen...)
Re: Holding a Program in One's Head (2007)
#13I agree with the power of holding a program in one's head, but I also consider this a (the?) serious bottleneck in the software engineering. I hope we discover a scalable alternative to holding a program in one's head. It doesn't need to be as good as holding a program in one's head, it just needs to approximate it. (Edit: see also Design Beyond Human Abilities by Richard P. Gabriel.)
We have - it's called an API. The way to work on big programs, too big to hold in your head all at once, is to break them into a bunch of little programs, each of which does something you can hide behind a simple interface. Then you hold all of the library in your head at once, and possibly repeat the same process. The complexity comes in that this really does just approximate holding the whole program in your head,…
It's also the primary driver behind the principles of object oriented programming - but those are almost dirty words these days. Somehow OO tried and failed in many ways to solve this problem, but I think it gets too little credit for at least having its heart in the right place.
Re: Holding a Program in One's Head (2007)
#14I agree with the power of holding a program in one's head, but I also consider this a (the?) serious bottleneck in the software engineering. I hope we discover a scalable alternative to holding a program in one's head. It doesn't need to be as good as holding a program in one's head, it just needs to approximate it. (Edit: see also Design Beyond Human Abilities by Richard P. Gabriel.)
Even more powerful approach is minimalistic design with objects placed where they belong, to achieve harmony. Design, that among other things, minimizes a number of objects required to hold in one's head.
Personally I call it a design with good Feng Shui :) When things and objects are in their right locations, and in harmony, one don't have to remember where they are! One can just remember the harmony and find them in their places.
That's precisely why Python is so damn good, by the way.
Re: Holding a Program in One's Head (2007)
#15I completely disagree with his idea that one should hack for "36 hours straight". Not only is this extremely unhealthy for your wrists, it depletes your mental energy and will cause you to make more mistakes. I guarantee that if I managed my coding time in short 1-2 hour bursts working on the same project as Paul, given that he is working 8-16 hour shifts nonstop, that my code will not only run more efficiently but have fewer bugs.
Is someone like Paul actually advocating such an idiotic and self-destructive practice? Perhaps his idea of "working on a program" also includes the time you spend thinking of it. While it's not so stupid thinking of it this way, his notion that one can achieve a higher level of productivity by working long hours are still incorrect, as many of the best ideas have come from breaking out of long coding sessions to "recalibrate" the mind and think about the problem differently.
Re: Holding a Program in One's Head (2007)
#16It'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…
This is why I like Ruby...it feels like Lisp under the hood but is actually useful because it can model real-world objects.
Re: Holding a Program in One's Head (2007)
#17It'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…
I think programming tools and technology have become much better over the decades (more expressive and easier to interact with). Programmers today are building far larger and more complex software than ever before.
Programmers will always be working at the limit of their abilities -- if the tools make anything easier then we'll just start tackling harder problems.
Re: Holding a Program in One's Head (2007)
#18I wonder what the most complex system is, to date, that has been made and that can all fit in one head.
A recent example, though not a program, is Mochizuki's proposed proof of the ABC conjecture. I wonder what program would be comparable to that in complexity.
Re: Holding a Program in One's Head (2007)
#19It'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…
Mumble mumble Clojure mumble simple made easy mumble mumble immutable values mumble concurrency.
Re: Holding a Program in One's Head (2007)
#20Earlier quoted context omitted.
We have - it's called an API. The way to work on big programs, too big to hold in your head all at once, is to break them into a bunch of little programs, each of which does something you can hide behind a simple interface. Then you hold all of the library in your head at once, and possibly repeat the same process. The complexity comes in that this really does just approximate holding the whole program in your head,…
It's also the primary driver behind the principles of object oriented programming - but those are almost dirty words these days. Somehow OO tried and failed in many ways to solve this problem, but I think it gets too little credit for at least having its heart in the right place.
I think OO was a first (and pretty good) stab at the problem. The primary goal was recursion, so having things be self-similar, and Alan's insight was to make the small things look like the big things (lots of little computers interacting), rather than making the big things look like the small things (everything is a function,...)
http://www.smalltalk.org/smalltalk/TheEarlyHistoryOfSmalltal...
Back in 1972, we obviously didn't have a lot of "big things" (e.g. large distributed systems) to look at, so instead analogies and intuition were used. Considering, the results are not too shabby, IMHO.
Nowadays we have the Interwebs, a huge distributed system that appears to work most of the time, and so one might ask if we can apply the same principle and get newer and possibly better results: if we want self-similarity, should our computations internally look like the web?
We also have lots of experience with the systems we've built, and things like the Patterns books that tell us where our means of capturing common behavior fall short (if it's a pattern, it's repetitive; if it's repetitive, I should have been able to factor out the common parts).
So I am not sure "failed" is the right way to describe it. As another poster pointed out, we are now capable of building much larger systems than before, and OO seems to be largely responsible for that.
Another perspective is that Smalltalk (again) was never intended to be something final, but rather a basis for obsoleting itself, so describing OO as failed seems akin to calling the first stage of a Saturn V a failure because it didn't get to the moon.
Where I do see a failure is that we entered an age of stagnation, and rather than see OO as a first stage to build even better things on top of, we pretty much stopped. And in that sense, I guess OO did fail, because the second and third stages that were supposed to get us to the moon didn't really get built.