9 ms·
It Can Be Done (2003)
- quickthrower2 3y agoAs well as a bit of genius the key here is being able to understand every layer of the stack from the chip upwards which was probably more achievable then.
- agumonkey 3y agodidn't know about andre bensoussan, but here's a pic of him with louis pouzin (of cyclade and RUNCOM fame) https://multicians.org/shell.html https://multicians.org/shell.html that said, i always love stories of people taking time to find aesthetics and quality with pen and paper
- rokkitmensch 3y agoI don't even smoke, and think that photo is amazing.
- agumonkey 3y agoThere's a clint eastwood western style to it I guess
- 331c8c71 3y agoIt can be done no doubt (with some training as any other skill). And probably not by everyone (in the same way as not everyone has the will, motivation and means to, say, completely master a musical instrument or certain sport). The issue is that this way of working would be even less acceptable in 2024 than in 2003. That being said, even now there are places where you can work the way you like but the irony is those places won't be on the radar and of much interest to your run-of-the-mill career developer.
- raverbashing 3y agoThis is a bit of a specific idiosyncrasy I just can't plan things on paper. Sure, I can try to plan then, but then I see I have no idea how things can/should work or how to best arrange things unless I'm actually typing code Also the planning on paper usually looks nice but doesn't consider all the real-world imperfections, so your beautiful planning becomes "ugly" quickly
- jpgvm 3y agoMy experience is that it's a skill like any other, I was bad at it, I wanted to be better at it so I did it more often and now I'm good at it. Being able to anticipate and find nice design level general solutions for hairy real-world problems is where systems design becomes most rewarding.
- Megranium 3y agoIt might also have to do with how programming was taught to a certain generation? At least from my own experience, when I was at university OOP and UML was all the rage, so we had to specify through diagrams in fancy diagram editors, then generate the code from that, and then still re-write everything by hand because it never really worked out quite that well. I never touched UML again after university ...
- kunley 3y agoUML was an abomination, and it's a relief it's completely dead.
- bux93 3y agoWell, the code generation was a mistake, but drawing diagrams is explicitly what the guy in this story did: He started by sitting at his desk and drawing a lot of diagrams. I was the project coordinator, so I used to drop in on him and ask how things were going. "Still designing," he'd say. He wanted the diagrams to look beautiful and symmetrical as well as capturing all the state information.
- Cthulhu_ 3y agoI think the modern-day equivalent would be test-driven development; in both cases (unless I don't get it) is that you make sure you understand the problem and write verifications before you start on a solution. Of course, this doesn't work for every problem / task.
- onion2k 3y agoI imagine the main reason he could do that is because he had a very clearly defined set of requirements. Most of what makes software buggy and slow today is that no one actually knows what they're building, and even if they do it keeps changing because "agile". Give a dev a clear API and a well defined set of criteria, and most will write code that works very well.
- temac 3y agoDepending on the definition of "dev", they can be the ones who define the requirements and API.
- deleted 3y ago[deleted]
- OtomotO 3y agoThat plus a thousand special cases, that are quite often absolutely meaningless to implement in code, but still have to be done. What do I mean by that: I work for big corporations mostly and quite often there is the average case that is about 90%-99% of all incoming work. Then there is a myriad of special cases some of which happen every third year on a blood moon, if an eclipse is happening at the same time and the witches chant in the woods... Instead of managing these unicorn-cases by hand, they have to be implemented in code and lead to bugs and a ton more code to review and maintain. Speaking of maintenance... oh, don't get me started on that one, it's a sore spot!
- makeitdouble 3y agoTBF, the current dev team might right now is aware of the edge case how to deal with it, the poor shmuck three years down the line when blood moon eclipse witch chant happens probably wont. In particular, these edge cases tend to be more complex, require more knowledge and have less margin of errors than the standard errors happening 90% of the time. Leaving them as a gift for the future maintainers is a special kind of dick move.
- OtomotO 3y ago
- musiciangames 3y agoI worked with a defector from the Soviet Union. He told me the reason Soviet programmers were so good was that they had very limited access to computers. If you had to program using pencil and paper, you wanted to make it work first time. (Coincidentally we were working for Honeywell).
- viraptor 3y agoAlternatively: only people who were into it enough to handle doing things on paper and with limited access to computers kept working afterwards. So: was it a good way to teach or a good way to filter out less motivated people?
- Megranium 3y agoI guess it was at a time when computers weren't ubiquitous as they're today, and an average non-technical person might have never touched one. In that days, designing on paper was probably just the default mode of working ...
- littlestymaar 3y agoIt cannot be the only effect, since this pen-and-paper effect manifests itself in other places: when you kook at old industrial systems' plans (nuclear power plant in the example I have in mind) you're very surprised to see how small the number of revision is for the plans: because it's very tedious to re-do the entire plan from scratch by hand, people used to be extremely cautious when design them. Today with CAD software, revisions are cheap and producing half backed plans that need later correction is the norm. Maybe the new way of doing thing is still more efficient in the end, but maybe not.
- ew6082 3y agoI am an Engineer and have done things both ways throughout my career. What is easy to miss in digital are the overall holistic design and the way it all fits together, because you are always zoomed in on a particular piece of the puzzle and rarely see the whole thing on screen in a meaningful way. There is just something about seeing a full design laid out on paper, spread out on the table, that lets many little things jump out at you. If it's important print it out, in large format.
- xeyownt 3y ago> How did André do this, with no tool but a pencil? Using his brain. Intensively ;-) Reminds me a story that happened to me. I was doing some heavy changes to some library, then started running the tests. The tests were failing, and without looking at log I knew immediately where the bug was. So I fixed that, launch the test and again same story. And again. At the 4th time, the cause was not immediate so I was considering looking at the log when I noticed I was not actually running the program at all, but was executing something else! So to find bug, you just need to ask yourself where it will fail, and fix that ;-)
- euroderf 3y agopebkac ?
- defrost 3y agoProgrammer Exists, Bug Kausing Almost Certain.
- virtualbluesky 3y agoProblem Exists Between Keyboard And Chair
- ChrisArchitect 3y ago(1994)
- necovek 3y agoWell, the systems are way more interconnected today, esp over less stable interconnects (internet!), with nothing really being done serially. That in itself makes programming multiple times harder. Add to that that devs are usually dealing with external, badly documented interfaces (eg. The Cloud, frameworks...), and it's impossible to know how something will work without trying it out (just like they had with the error handling bug they hit: now multiply that by 1000 or 10000 of today's usual external API usage in a non-trivial program). But the other missing piece to this is how much time did this actually take (there is an implication "designing" took its sweet time)? Would the modern way of coding on a computer be faster with the same number of incidents?
- szundi 3y agoBack then it was possible with the human brain.
- dang 3y agoRelated: It Can Be Done (2003) - https://news.ycombinator.com/item?id=18415231 https://news.ycombinator.com/item?id=18415231 - Nov 2018 (18 comments)
- countWSS 3y agoThe software at that time was just much smaller. The size of most projects, anything above a toy program is in megabytes and will be impossible to "write down" as single file.
- tgv 3y agoOTOH, there were practically no examples to draw from. There was no virtual memory class in their OS-101 course. These people pioneered OS design.
- LAC-Tech 3y agoI'm sorry but the line of business software most of us work on is not more impressive than writing a major component of a file system from scratch.
- kragen 3y agoi was surprised to find that my natural-language notes from my electronics notebook from the last month total a quarter megabyte already. about 37000 words of markdown a small fraction of that is urls for electronic parts, but nearly all (90%, say) is just english text. another 10% is stuff i quoted from other people (web pages, manufacturer app notes, books, etc.) it is a single file and will probably continue to be a single file forever, at least for the rest of the year. if i continue at the same pace, that will be 12 megabytes. there is nothing impossible about that at all (if you're interested, git clone http://canonical.org/~kragen/sw/leatherdrink.git http://canonical.org/~kragen/sw/leatherdrink.git. it's currently almost 200 megs because i checked in the avr toolchain. there are also photos and videos and schematics and stuff) in a programming language the growth would be fewer bytes per month, but perhaps by a factor of five
- kandelt 3y agoEverytime something impressive is posted, a real feat, the comments mostly pick on it. Please stop
- Etheryte 3y agoEvery time comments are posted, a real interactive discussion, other commenters pick on it. Please stop.
- kybernetyk 3y agoModern devs are frustrated. They don't do anything of importance or significance anymore. They're not the guy designing a virtual memory manager for a novel OS. They're just some cog in a machine converting SQL queries into HTML to show ads to kids and old people. One can only become cynical and bitter.
- kome 3y agospot on. plus using a lot of js because they don't know html and css (or just very superficially). :-)
- antihipocrat 3y agoJS is necessary to maintain state, can this be done with CSS and HTML? Also, I'd say that manipulation of CSS classes and HTML elements with JS gives the developer quite a strong understanding of them.
- 3y ago
- frozenwind 3y agoAs I sat down at my desk to start the work day and finish a dreaded task, my mind of course immediately drifted away and felt the urge to check some news on reddit or HW. I opened HW and this is the first title. "It can be done". Thanks for the motivation! P.S. Of course, I also read the article :).
- siwatanejo 3y agos/HW/HN/?
- frozenwind 3y agoHN.... I have an app on my phone that's called "Hews". It's morning and everything is confusing :(
- namtab00 3y agoThere's a "Hews 2".. Also "Hacki" and "HACK". All similar (of course), but all in some way lacking..
- DeathArrow 3y ago>How did André do this, with no tool but a pencil? When I was 14 and went to highschool, for programming classes I did most of my code on paper. I was a poor kid in a poor country, so not only I did not have a PC at home, but the few "computers" we had in the computer lab at school were ZX Spectrum clones which didn't run Turbo Pascal, the programming language we used at that time.
- Jakesbeb 3y ago[flagged]
- LAC-Tech 3y agoI would love a more systematic approach to this none-coding part of coding. I mean I doodle little diagrams and write notes on scrap paper but nothing so rigorous as what Andre is doing.
- Donaldbendo 3y ago[flagged]
- revskill 3y agoGiven the input, the correct data structure, you can.
- i_am_proteus 3y agoThere's a good comment from account jrd259, who worked with Andre, in the previous HN thread about this article (https://news.ycombinator.com/item?id=18415231 https://news.ycombinator.com/item?id=18415231). It relates the importance of a private work space with large desks and no notifications.
- sssilver 3y agoThis comment really deserves more attention.
- Multicomp 3y agoAgreed, here's the quoted copy/paste for those scrolling by: > Former Multician here. Andre was super-smart, but it is perhaps also relevant that even the most junior developers (as I was then) had quiet private space to work with large desks. All design was done offline. Multics terminals were like type-writers (although video did show up near the end), hence no stream of popups. The environment both allowed for and demanded focus and concentration. This is no longer so.
- paganel 3y ago> Multics operating system at Honeywell in Cambridge Still surprising how much entrenched the computer industry was (and probably still is) within the military complex. I'm curious if there is a list somewhere with big, consequential IT/computer programming stuff that has NOT had any direct connection with the military.
- p_l 3y agoScams and ad-pushing? Persistent Invigilation by ad-serving companies also surprisingly started out in commercial space, not military, from what I know.
- Timwi 3y agoThis is reminding me of two times in my life that I was programming on paper. The first time I was maybe 10–12 years old. We were visiting my grandparents, who had no computer (and there were no smartphones). They did, however, have a (mechanical) typewriter that had the ability to type in both black and red with a switch. Back then my main hobby was Turbo Pascal, so I used the typewriter to write a Pascal program that I would later type up into the PC and run when we got back home. We spent a week at my grandparents, so I had plenty time to think it through, debug it by hand, and re-type sections that were faulty. The second time relates to an esoteric programming language I invented called Ziim (https://esolangs.org/wiki/Ziim https://esolangs.org/wiki/Ziim), and more specifically, the binary addition function you see on that page. It's huge and complicated... and it had a bug, which I knew because I ran it in an interpreter, but I had no idea where the bug was and how to fix it. — Around that time, I had a long bus ride coming up; sitting in a coach for like 6 hours or so. That was a perfect opportunity to debug this. I transferred the Ziim addition function to square-ruled paper using a pencil, and then, on the bus, I executed it by hand, step by step. I found the bug and was able to fix it. It required redoing the entire function layout. I guess the moral of the story is that restricting your own ability to do things the “easy” way can sometimes lead to well thought out code. Despite, I don't do this regularly at all. I will just as soon write half-arsed snippets and iterate, grab a debugger to step through code, etc. Maybe I should rethink that?
- donkeybeer 3y agoIt works because normally you do most of the thinking in your head, so the few occasions you are doing deep thinking using paper and pen, you have the discipline and care to only write what is important and keep the rest in your head. If you do everything on paper, it will start being not much different than doing everything directly on computer because you will be writing everything and you will lose that abstraction and care.
- lqet 3y agoHere is the code written by André Bensoussan: https://multicians.org/vtoc_man.html https://multicians.org/vtoc_man.html
- coldtea 3y agoHmm, have never seen much of PL/1. Control flow aside, the syntax looks surprisingly clean.
- smikhanov 3y agoSo the answer to "how did he do it?" is obvious -- it simply wasn't too complex of a task (by modern standards).
- abecedarius 3y agoI wouldn't measure difficulty of a design problem by the complexity of a solution. "This is so much simpler than I expected" is some of the highest praise. (About this particular problem I have no idea.)
- gwern 3y agoI don't know about that: is it 'not complex' or did he succeed at the design? Implementing core components of a file system in a few pages sounds quite complex to me - I'm getting a bit scared just reading that comment explaining why the race condition is harmless.
- ChrisMarshallNY 3y agoWell, when I started, it was the waning days of "big iron." In Ye Olde Days, "programmers," were usually little more than data entry clerks (often, women). The people who wrote the software would be in offices, filled with smoke, writing the programs on paper. Compute time was expensive and precious. If you got a bug during your run, you wouldn't get a chance to fix it, until you could schedule another data entry session, and another CPU run. It encouraged a "measure twice, cut once" approach. Since most software, in those days, was fairly humble, compared to the de rigueur, these days, it was easier to do. Also, software usually had extremely restricted I/O. UI was not even a term, and peripheral connection was a big deal. These days, I often "throw stuff at the wall, and see what sticks," when writing software. It's easier for me to write some half-baked crap, and debug it in the IDE. My software development tends to be "iterative." I write about that, here: https://littlegreenviper.com/miscellany/evolutionary-design-specification/ https://littlegreenviper.com/miscellany/evolutionary-design-...
- stavros 3y agoThis is exactly it. People are lamenting the bygone days of having to think a lot about your software before you wrote it, but the truth is that, today, the same programmer would have been able to iterate his way to the same program in perhaps half the time. I remember an assignment in my university course, where I had to write a (simple, admittedly) OS kernel. I didn't know C very well, and I didn't know what kernels did beyond the theory, but we had to write a few hundred lines of C code to manage tasks. I knew that there would be absolutely no way I could debug this program if it didn't work, as it was all parallel code and a bug would mean mysterious race conditions. I reasoned about the system as a whole, and I spent a few days writing small, self-contained functions that I thought a lot about. I then compiled and ran it, and, after the obligatory "missing semicolon" compilation errors, it worked first try.
- virtualritz 3y agoMy first exposure to programming was GWBASIC on the 8086 PC clone of my uncle. I was 12. My uncle lived over 500km away from my home. I saw him once a year, when my family came together for xmas at his house. In the 12 months in-between I wrote tons of BASIC code with pencil. And then typed it in at xmas. That lasted for two years, until I had saved enough pocket money to buy my first PC. The experience was very similar. Stuff just ran & worked as expected. If you write code by pencil you just think a lot more before putting anything down on paper. As any corrections are a nightmare -- except for the last line. You can't just insert a code block etc.
- alphazard 3y agoCertain kinds of systems really have to be designed ahead of time. The alternative is an incomplete system. You might never get anything working without a design. Observability and trial-and-error tooling are a big deal. They enable the workflows that allow developers with a poor conception of the system to brute force their way to fitting requirements. The popular ethos around shipping the first thing that works, often, only works when you can see what you're doing, and the cost of bugs in production is low. That's software in 2024: mostly unimportant garbage. For this kind of system at this point in time, a full design was the only way. The article hints at a touch of perfectionism (which probably didn't help the timeline), but it's not like he would have been more likely to guess and check his way to a working memory management system in less time with the sans-design development style popular today.
- RugnirViking 3y agoWow, that sounds like a dream work environment. Sounds like he had a good amount of time to get it right, a well defined but tough task, and near total freedom to architect it. Gotta admire everyone involved.
- andai 3y agoA friend told me that when she was in school, they'd hand in their programming assignments on paper, and a week later they'd get the output. She said week-long "compilation times" make you learn to double check your work!
- deely3 3y agoIm not sure that I like this approach. Documentation very rarely cover all 100% of nuances. There always will be "test and see" part of learning in my opinion. For me its like you can use paper for drawing but only 10 minutes a day. Or piano but only every second Monday for few hours.
- shermantanktop 3y agoI love the idea of this but it is so, so far from the iterative approach I normally use. When I have taken this approach - pencil and paper - I find that it accelerates the initial big decisions (e.g. "what will this module's responsibility be?") but sometimes causes rework when I discover that I was optimistic or unaware of how two areas of the code interact. Perhaps I'm just not doing it thoroughly enough.
- tanseydavid 3y agoHow did he do it? Simple. Agile/Scrum had not yet been conceived of.
- edub 3y agoMany great anecdotes in this thread. Many regarding lack of access to a computer while designing code. Mine is as a child wanting to try to work on the computer every moment I was awake, but parents insisting that it is important for me to got to bed so I can go to school the next day. My solution to continue to working on the computer when I was expected to be in my bedroom was to keep writing code from my room but on paper. I'd often stay awake with pen and paper until 4am, and maybe sleep during class the next day. But without the computer to give you the feedback of compiling your code and being able to test it, it forced my mind to try to reason the code I wrote on paper to think through if it would work as I expected. So maybe 15 minutes writing on paper what I thought the code should be, and 45 minutes reasoning with myself if what I wrote would work the next day when I typed it into the computer. It kinda trained me to compile code in my head, and it was a practice of mine for years throughout middle school and high school. I'm not sure I would have had the same understanding today as I do now if I had access to the computer throughout the night and could keep doing trial and error with the computer to get my code to work. Even though I was working with BASIC at the time, I think it shaped how I think about working with the languages I use today.