4 ms·

You've most likely already seen this, but, if not, it's a relevant, great read: http://discuss.joelonsoftware.com/default.asp?joel.3.219431 http://discuss.joe

by twp 14y ago

You've most likely already seen this, but, if not, it's a relevant, great read: http://discuss.joelonsoftware.com/default.asp?joel.3.219431 http://discuss.joelonsoftware.com/default.asp?joel.3.219431

LnxPrgr3 14y ago
It's said that Lisp programmers often work by first building a domain-specific language for solving their problem, then solving the problem in that new language. Some object-oriented programmers do something similar, where their programs are expressed in a domain-specific language written as an object relationship graph. Only they skip the part where that language is supposed to make it easier to solve the problem. What do I mean? Here's my (somewhat ancient) attempt at parody: http://pastebin.com/TyNrvRmB http://pastebin.com/TyNrvRmB It has all the hallmarks of production code I've seen in this style: it's about 20 times more than the necessary amount of code, it's subtly buggy, and it needs explanation because what it does is completely non-obvious. It is arguably slightly easier to extend than the obvious solution, but at a great cost, and in a silly one-off program at that. The worst part? This doesn't scream parody in some circles. This is just how things are done, as if anything less involved is fundamentally broken.
- stcredzero 14y ago
  > It's said that Lisp programmers often work by first building a domain-specific language for solving their problem, then solving the problem in that new language. This is precisely how good Smalltalkers operated. It was very doable, because even constructs like conditional logic and "looping" (really iterators) were just ordinary calls. For example, if you wanted to implement "fuzzy logic" in Smalltalk it would just take a mere minutes to implement some methods like: ifTrue:ifFalse:ifMaybe: Then define a Maybe class and use it as the Maybe value and park some methods like that on it. Then this would let you write code like: result ifTrue: [ "condition 1" ] ifFalse: [ "something else" ] ifMaybe: [ "handle maybe" ].
- sage_joch 14y ago
  I'm a bit worried at how easily I was able to follow that code. And that my initial reaction was to think "Iterator.next() should throw a NoSuchElementException if there is no next element!"

by twp 14y ago

You've most likely already seen this, but, if not, it's a relevant, great read: http://discuss.joelonsoftware.com/default.asp?joel.3.219431 http://discuss.joelonsoftware.com/default.asp?joel.3.219431

LnxPrgr3 14y ago

It's said that Lisp programmers often work by first building a domain-specific language for solving their problem, then solving the problem in that new language. Some object-oriented programmers do something similar, where their programs are expressed in a domain-specific language written as an object relationship graph. Only they skip the part where that language is supposed to make it easier to solve the problem. What do I mean? Here's my (somewhat ancient) attempt at parody: http://pastebin.com/TyNrvRmB http://pastebin.com/TyNrvRmB It has all the hallmarks of production code I've seen in this style: it's about 20 times more than the necessary amount of code, it's subtly buggy, and it needs explanation because what it does is completely non-obvious. It is arguably slightly easier to extend than the obvious solution, but at a great cost, and in a silly one-off program at that. The worst part? This doesn't scream parody in some circles. This is just how things are done, as if anything less involved is fundamentally broken.

stcredzero 14y ago
> It's said that Lisp programmers often work by first building a domain-specific language for solving their problem, then solving the problem in that new language. This is precisely how good Smalltalkers operated. It was very doable, because even constructs like conditional logic and "looping" (really iterators) were just ordinary calls. For example, if you wanted to implement "fuzzy logic" in Smalltalk it would just take a mere minutes to implement some methods like: ifTrue:ifFalse:ifMaybe: Then define a Maybe class and use it as the Maybe value and park some methods like that on it. Then this would let you write code like: result ifTrue: [ "condition 1" ] ifFalse: [ "something else" ] ifMaybe: [ "handle maybe" ].
sage_joch 14y ago
I'm a bit worried at how easily I was able to follow that code. And that my initial reaction was to think "Iterator.next() should throw a NoSuchElementException if there is no next element!"