Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

"Even with a principled approach, I think I managed to build a system that only I can really get around in."

Interesting. Power vs difficulty in debugging.

" BOT filled its goals of an architecture that is infinitely extensible and runtime modifiable, but that degree of power came at a cost - despite its simplicity the resulting program is very hard to follow. I've recently come to understand that this is because mixins are fundamentally an anti-pattern and BOT is basically dynamic mixins."

BOT is described here: http://www.chris-granger.com/2013/01/24/the-ide-as-data/



>Interesting. Power vs difficulty in debugging.

Reminds me of this statement by Brian W. Kernighan, "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it."


This is all too harsh though. When you are doing something new, you aren't that sure what kind of extensibility and modularity you need internally, so you wind up over engineering and over architecting. Imagine you wanted to build a bridge without no one ever doing that before. It is an open problem, the resulting bridge might work, but it won't be pretty and probably used way too many materials, meaning it will be difficult to repair and upgrade.

But your next bridge will be better, benefiting from the experience of the previous one, and you might be able to even do some design up front for the third one that actually sticks.

Tl;dr get started on your first bridge early.


Your second bridge might not be better if this turns out to be true: http://en.wikipedia.org/wiki/The_Mythical_Man-Month#The_seco...


The error is not building the second bridge, it's trying to create a new design from the ground up rather than improving on the first one.


True, but in research it is expected. I would guess development is much more conservative.


> Reminds me of this statement by Brian W. Kernighan, "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it."

A corollary is that if you are writing code with minimum repetition, you are effectively a compression algorithm, not a programmer.


> A corollary is that if you are writing code with minimum repetition, you are effectively a compression algorithm, not a programmer.

I do not understand why that follows. Can you elaborate, please ?


One developer writing code by themselves for 2 years will almost always produce a system that they can only understand.

I did it with the Scala IDE back in 2006/2007, unfortunately, complete with mixin layer overuse.




Consider applying for YC's Winter 2027 batch! Applications are open till November 2.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: