4 ms·
I think his point about the language-oriented approach is interesting. My fear is that the create-an-appropriate-DSL-and-your-problem-takes-little-code approach
by michaelochurch 15y ago
I think his point about the language-oriented approach is interesting. My fear is that the create-an-appropriate-DSL-and-your-problem-takes-little-code approach would actually be disastrous if used by mediocre programmers. Instead of having to read their bad code, we'd be stuck trying to read their bad code in their shitty DSLs.
Object-oriented programming probably wouldn't suck so bad if it had stuck to his vision. Objects are great in some circumstances (the biological metaphor of complexity encapsulated behind a simple interface applies) but they've utterly failed as the default means of abstraction. The default abstractions should be (1) pure functions, and (2) simple and sound mutable state primitives (STM, Agents, etc.)
- pwpwp 15y agoRegarding your first point about mediocre programmers: I find this patronizing. True, DSLs have the potential to obscure your code, but so does every construct that allows abstraction - even the humble subroutines ("If mediocre programmers give names like bongoBong() to a subroutine, then how can we tell what the program does?").
- DanielRibeiro 15y agoCould not agree more. Or, as said on Five Questions about Language Design[1]: Give the Programmer as Much Control as Possible [1] http://www.paulgraham.com/langdes.html http://www.paulgraham.com/langdes.html
- famousactress 15y agoYes yes yes. Further, I think 'safe' processes, languages, and approaches play a strong part in making mediocre programmers.
- gruseom 15y agoThis objection -- "but bad programmers will make a mess of it" -- is the stock objection everybody makes to every unorthodox programming construct. Since it is an objection to everything, it is an objection to nothing.
- michaelochurch 15y agoThis is why I like strong static typing. Instead of bad programmers making a mess of the language, the compiler makes a mess of them. (I'm half-joking, since there are a variety of bad programmers and not all are of the "can't get code to compile" variety. Actually, the most dangerous bad programmers are the high-IQ bad programmers, but that's another rant. Still, I think it's true that the discipline enforced by languages like ML and Haskell turns a lot of bad programmers away.)
- andrewflnr 15y agoJust because people overuse it doesn't mean it isn't true sometimes. I don't know if there's a name for that fallacy, but it definitely is one.
- gruseom 15y agoThat what isn't true? That bad programmers will make a mess? Of course that's true. But if you can't show how and why it's more true of construct X than in general, you've said nothing. Meanwhile, it sounds like you've made a serious objection to X when you haven't.
- cageface 15y agoThe big problem with DSLs is that they are not composable. Writing expressions in one DSL within expressions of another is often very tricky, if not impossible. DSLs also tend to be leaky abstractions. If I need to drop down a layer of abstraction in the middle of an expression of your DSL suddenly I have to understand all the mechanics of your DSL.
- andrewflnr 15y agoMaybe DSL's make more sense in the context of a master/junior programmer setup, where the master programmer creates the DSL and the junior programmers write in it. I don't have enough experience to say with any confidence. Do you think that would work?