17 ms·

“Screw it, I'll make my own” – The story of a new programming language

139 points by chrismonsanto 11y ago

deleted 11y ago
[deleted]
- lisper 11y ago
  > I don't understand why people would use a dash "-" inside a symbol No need to use the shift key. At the levels of efficiency that a good language can reach, this matters. Also, dashes match established lexicographical conventions better than underscores because dashes look like hyphens.
  - deleted 11y ago
    [deleted]
  - ternaryoperator 11y ago
    In COBOL, dashes are the way of joining words. Very readable actually.
  - oldmanjay 11y ago
    I'm all for efficiency but based on my experience reading the code people write, the last thing we need is getting them to type faster. I'd prefer if some people slowed down a whole heck of a lot to think more about what it is they're doing.
    - terminalcommand 11y ago
      I always thought autocomplete suggestions and snippets preserved brain cycles. IMHO if you prevent developer exhaustion your code gets better-looking and more maintainable. But then again I'm a single developer, working on personal projects...
- adrusi 11y ago
  Well camel-case does reduce the length of the identifier without sacrificing clarity. This can help reduce line length, which, in turn, allows more files to be viewed on a single screen in splits, without wrapping or scrolling. I think this solidifies camel-case as the most practical style, if you ignore aesthetics. The underscore was invented to allow people using typewriters to underline text. I think that the hyphen is more pleasing, aesthetically, but overall I think that it's a poor tradeoff.
  - zem 11y ago
    why would you ignore aesthetics? I'd much rather spend my time poring over pleasant looking code than ugly looking code.
    - bhrgunatha 11y ago
      Beauty is in the eye of the beholder? Look at the never-ending discussions about s-expressions in Lisp and all its variants.
  - dalke 11y ago
    The underscore in computing was developed to be able to separate words used as part of a variable name on computers with only upper-case. Quoting https://en.wikipedia.org/wiki/Underscore#History https://en.wikipedia.org/wiki/Underscore#History : > IBM's report on NPL (the early name of what is now called PL/I) leaves the character set undefined, but specifically mentions the break character, and gives RATE_OF_PAY as an example identifier It links to the 1964 report at http://bitsavers.informatik.uni-stuttgart.de/pdf/ibm/npl/320-0908_NPL_Technical_Report_Dec64.pdf http://bitsavers.informatik.uni-stuttgart.de/pdf/ibm/npl/320... which defines the "_" as the "break" character, on page 22, and on p23 says "[A]n identifier is a string of alphabetic characters, igis, and break characters with the initial character always alphabetic. Any number of break characters are allowed within an identifier; however, consecutive break characters are not permitted. Also, a break character cannot be the final character of an identifier." (To verify the timing, "_" was not in X3.4 1963 (see http://worldpowersystems.com/archives/codes/X3.4-1963/page6.JPG http://worldpowersystems.com/archives/codes/X3.4-1963/page6.... ) and that ASCII code point was instead "left arrow".) You argument regarding "more files to be viewed on a single screen" is valid, but incomplete. It's more a question of total program comprehension rather than a single metric. This is hard to measure. We can look to related metrics of speed-of-identification and accuracy to see how messy the subject is. The report at http://www.cs.kent.edu/~jmaletic/papers/ICPC2010-CamelCaseUnderScoreClouds.pdf http://www.cs.kent.edu/~jmaletic/papers/ICPC2010-CamelCaseUn... says that programmers who are trained in underscore style can recognize underscore style more quickly than camel case, while https://www.researchgate.net/publication/221219628_To_camelcase_or_under-score https://www.researchgate.net/publication/221219628_To_camelc... says that camel case is all around better. At the very least it suggests that "most practical style" is hard to determine.
- Avshalom 11y ago
  Hyphenated words are a common/familiar feature of English underscores are not. https://en.wikipedia.org/wiki/Hyphen#Joining https://en.wikipedia.org/wiki/Hyphen#Joining
Learn2win 11y ago
In Racket, you can use "-" and "?" in variable names and I love it.
- Xophmeister 11y ago
  And "/" and ":" and all manner of others. It's a Lisp thing, where the syntax of S-expressions removes any ambiguity.
- legulere 11y ago
  x-y and x - y meaning different things seems like a great source of errors to me
  - jorams 11y ago
    That's not a problem because subtraction in Racket, as in any Lisp-like, looks like this: (- x y)
  - breuleux 11y ago
    It depends on a couple of factors. Personally I always write subtraction as "x - y", so I never have any issues. Also, if undeclared variables are a compile-time error, the compiler will (probably) complain loudly about "x-y". So you can fix that quickly and easily, it's not too bad. The one error that might be problematic depending on the language's semantics is if you write something like "x.y-z" intending to subtract "z" from "x.y", but in fact you are going to get the "y-z" property of "x". I must say that in Earl Grey you'll unfortunately end up with "undefined" as the result of that expression (saner languages would raise an exception on a missing property). I have never had that issue in practice, but then again, I always space subtraction.
    - Uncompetative 11y ago
      I don't have a problem with "x - y" and approve of hyphenated names if you can't support spaces within names. I had initially jumped to the conclusion that your language would use a postfix notation and be more influenced by Forth than LISP. This is because I assumed it's name alluded to the way that Captain Jean Luc Picard would program his replicator.
dochtman 11y ago
Nice story. I have similar feelings about my own attempt, Runa (https://github.com/djc/runa https://github.com/djc/runa), in particular about just how large a language (ecosystem) has to be in order to be viable to a few more people. Still, just the journey is quite interesting. It makes you understand other programming languages and their tradeoffs better, and I'm now much less afraid of parsers and lexers and so on. :)
xjay 11y ago
Curious. Are there examples of programming languages that allow spaces in identifiers? Obviously, it would need to be designed for that. I'm against the case-sensitive nature of some programming languages, and file systems for that matter. While it makes sense in a computing context (faster), you invent a new mode, just for the computer.. (Fortran was probably case-insensitive because upper-case letters were used first, and when lower-case letters were introduced, care was taken to neatly map them into the character set bit-wise, so one could simply clear the sixth binary digit to turn a lower-case letter into its upper-case equivalent, then continue the string comparison.) Of course, with Unicode, you need a more complicated check, or you could just ignore Unicode in the language itself for identifiers, yet allow it in literals, data types, etc.
- pwg 11y ago
  > Curious. Are there examples of programming languages that allow spaces in identifiers? Obviously, it would need to be designed for that. At least Tcl allows spaces in identifiers, but to 'use' such identifiers one does have to add a bit of extra 'sugar' to prevent the code parser from interpreting the spaces as token separators: Example of spaces in a variable name: $ rlwrap tclsh % set "var name with spaces" "contents of the variable" contents of the variable % puts ${var name with spaces} contents of the variable % set "var name with spaces" contents of the variable Example of spaces in a procedure (function) name (the first line defines the procedure): % proc {my space proc} {string} {puts "'my space proc' called with string='$string'"} % {my space proc} "hello how are you" 'my space proc' called with string='hello how are you' % "my space proc" "the quick brown fox" 'my space proc' called with string='the quick brown fox' % set pn "my space proc" my space proc % $pn "this that and the other" 'my space proc' called with string='this that and the other' So there you have at least one example.
- jejones3141 11y ago
  Algol 68 allows spaces in identifiers. That means one has to use one of the "stropping" techniques to distinguish keywords from identifiers--case stropping (IF p THEN foo ELSE bar FI), quote stropping a la the old IBM Algol F Algol 60 compiler ('if' p 'then' foo 'else' bar 'fi'), and at least one other I don't remember offhand.
lmm 11y ago
> There is a bit of a catch-22 in language design where the more a language is used, the clearer it becomes which parts of it are problematic and should change, but the harder it gets to actually change them. To hone a language you must use it, but applications require that a language's features remain stable, robust, set in stone, and therefore as imperfect as they were at that moment. Furthermore, the more delays are suffered in fixing flaws or plugging holes, the more likely it gets that a dependency is fostered upon them. The options you do not explicitly and insistently leave open, tend to close and seal themselves before you know it. This rings very true. I look at Ceylon and the features I'm most jealous of are things that Scala would and should just do, except for the need to retain compatibility with 10 years of existing applications and libraries, so instead they're enhancement proposals for the version after the version after the next version, and in the meantime we get by with macros that more-or-less cover the most important use cases. And Scala is relatively young as languages go - its warts are nothing to those of, say, C++. Sometimes I wonder if language design can only advance by new languages killing existing languages - past a certain point it seems impossible to change a language in the ways that it needs to be changed to become good.
- akkartik 11y ago
  I've been trying to break this catch-22 by experimenting with a language/VM/codebase without any backwards-compatibility guarantees. Instead of freezing interfaces for others to use, I'm going to guarantee instead that I'll have tests showing how to use my mechanisms, and you need to have tests for the programs you write using them. I'll try to make breakage happen in obvious rather than subtle ways, but if you don't write tests you'll be in a world of hurt. If you write thorough tests, however, it might be a grand adventure as we hopefully keep the language supple over time. Who's with me? Probably nobody :) Oh well, I'll be here by myself getting muddy in this foot path next to the highway. But it might be entertaining to read about what I've been up to. http://akkartik.name/post/libraries2 http://akkartik.name/post/libraries2 http://akkartik.name/post/readable-bad http://akkartik.name/post/readable-bad http://akkartik.name/about http://akkartik.name/about http://akkartik.name/post/mu http://akkartik.name/post/mu
  - 11y ago
mikerichards 11y ago
None of the languages I typically use allow hyphens in identifiers, but I find that kebab-case to be the easiest on the eyes.
- DrScump 11y ago
  heck, even COBOL '75 (maybe even '68) allowed hyphens in identifiers.
vorg 11y ago
> I chose to compile Earl Grey to JavaScript Some programming languages generate code much deeper down the abstraction stack, e.g. Haskell generating machine code, whereas others generate code to a much shallower depth, e.g. most languages generating JavaScript. A language generating lisp code from some syntax could even be shunting code up the abstraction stack. How deep does the generated code need to be down the stack for some syntax to earn the name "programming language"?
- z92 11y ago
  If you look at the code, and can't identify it as language X, then it probably deserves a new name.
  - MatthewMcDonald 11y ago
    This sounds pretty similar to the definition of a species. If two organisms of appropriate gender can't reproduce with each other, then they probably aren't the same species. If code from two samples can't be interspersed, then it's probably not the same language.
    - labster 11y ago
      Under that definition, Perl and Python have finally merged, given Perl 6's Inline::Python. Peace at last! I'd probably go with a definition more like "mutual intelligibility" like for natural languages, but that doesn't seem right either. Sometimes I have to turn on the subtitles for British TV.
      - Tiksi 11y ago
        Yeah, under that definition everything that supports FFI has merged into a massive unholy mess with C. I guess if it can't be "natively" compiled/interpreted as the same language without inlining or including, I'd say it's a different language.
deleted 11y ago
[deleted]
WalterBright 11y ago
> it is still unsettling when you feel like you can't participate in discussions about programming languages without indulging into self-promotion Ahem, cough, cough, er, ...
decafbad 11y ago
Unfortunately, I can't say this is unexpected: http://breuleux.github.io/earl-grey/repl/ http://breuleux.github.io/earl-grey/repl/
- mbil 11y ago
  Are you looking for http://breuleux.github.io/earl-grey/repl.html http://breuleux.github.io/earl-grey/repl.html ?
- breuleux 11y ago
  Ah, yeah, the link to the REPL in the GitHub repository was broken (I figure that's where you got it). I fixed it. As the other commenter pointed out, the real link is http://breuleux.github.io/earl-grey/repl.html http://breuleux.github.io/earl-grey/repl.html
itscharlieb 11y ago
Very interesting account of your experience. I've been toying with the my ideal programming language for some time and am interested. You bring up a good point about people favoring the styles of their most recently used language. For that reason I worry that any language I'd create would merely be a combination of languages I've used previously and not something original. I'm excited to take a look at your work.
bhrgunatha 11y ago
It's not surprising that changing a language would be difficult. It does, after all, include a software component, and pretty much all large software projects suffer the same. It can be easy to change minor technical details, but a deep, far-reaching design decision is very often fixed in place. Even with a good test-suite, that kind of change is rarely undertaken. At least in my experience. I suspect we've all worked on software that you would desperately love to change something fundamental in the design but no matter how painful leaving it alone is, it is preferable to live with the pain than to tear it all down. I've known a few writers for example that say they wish they could change their characters, but it's too late. I wonder if that's analogous.
cle 11y ago
I'm curious, would it have been easier to change design decisions if you hadn't bootstrapped it?
- breuleux 11y ago
  Probably a little, but I don't think it would have made a big difference. It takes a certain amount of code before it becomes clear that the design has a flaw, and it's going to be the same amount of effort to adapt it, whether that code is in the compiler or elsewhere. A bootstrapped compiler just requires a bit more boilerplate in the transition.
mcnamaratw 11y ago
Well that's the problem that needs solving all right. Yet again today I have a Python project that is already (at 200 lines!) obviously massively compressible if I had macros. Maybe I can get there by returning functions & building up the functionality that way, but it feels like I'm trying to scratch that spot in the middle of my back, where I can't quite reach.
- mcnamaratw 11y ago
  Rapid prototyping is this alternating process of building stuff up and then boiling it down. The building up is easier in Python, but the boiling down is easier in Lisp. Sure would be nice to have both on tap.

139 points by chrismonsanto 11y ago

deleted 11y ago

[deleted]

lisper 11y ago
> I don't understand why people would use a dash "-" inside a symbol No need to use the shift key. At the levels of efficiency that a good language can reach, this matters. Also, dashes match established lexicographical conventions better than underscores because dashes look like hyphens.
- deleted 11y ago
  [deleted]
- ternaryoperator 11y ago
  In COBOL, dashes are the way of joining words. Very readable actually.
- oldmanjay 11y ago
  I'm all for efficiency but based on my experience reading the code people write, the last thing we need is getting them to type faster. I'd prefer if some people slowed down a whole heck of a lot to think more about what it is they're doing.
  - terminalcommand 11y ago
    I always thought autocomplete suggestions and snippets preserved brain cycles. IMHO if you prevent developer exhaustion your code gets better-looking and more maintainable. But then again I'm a single developer, working on personal projects...
adrusi 11y ago
Well camel-case does reduce the length of the identifier without sacrificing clarity. This can help reduce line length, which, in turn, allows more files to be viewed on a single screen in splits, without wrapping or scrolling. I think this solidifies camel-case as the most practical style, if you ignore aesthetics. The underscore was invented to allow people using typewriters to underline text. I think that the hyphen is more pleasing, aesthetically, but overall I think that it's a poor tradeoff.
- zem 11y ago
  why would you ignore aesthetics? I'd much rather spend my time poring over pleasant looking code than ugly looking code.
  - bhrgunatha 11y ago
    Beauty is in the eye of the beholder? Look at the never-ending discussions about s-expressions in Lisp and all its variants.
- dalke 11y ago
  The underscore in computing was developed to be able to separate words used as part of a variable name on computers with only upper-case. Quoting https://en.wikipedia.org/wiki/Underscore#History https://en.wikipedia.org/wiki/Underscore#History : > IBM's report on NPL (the early name of what is now called PL/I) leaves the character set undefined, but specifically mentions the break character, and gives RATE_OF_PAY as an example identifier It links to the 1964 report at http://bitsavers.informatik.uni-stuttgart.de/pdf/ibm/npl/320-0908_NPL_Technical_Report_Dec64.pdf http://bitsavers.informatik.uni-stuttgart.de/pdf/ibm/npl/320... which defines the "_" as the "break" character, on page 22, and on p23 says "[A]n identifier is a string of alphabetic characters, igis, and break characters with the initial character always alphabetic. Any number of break characters are allowed within an identifier; however, consecutive break characters are not permitted. Also, a break character cannot be the final character of an identifier." (To verify the timing, "_" was not in X3.4 1963 (see http://worldpowersystems.com/archives/codes/X3.4-1963/page6.JPG http://worldpowersystems.com/archives/codes/X3.4-1963/page6.... ) and that ASCII code point was instead "left arrow".) You argument regarding "more files to be viewed on a single screen" is valid, but incomplete. It's more a question of total program comprehension rather than a single metric. This is hard to measure. We can look to related metrics of speed-of-identification and accuracy to see how messy the subject is. The report at http://www.cs.kent.edu/~jmaletic/papers/ICPC2010-CamelCaseUnderScoreClouds.pdf http://www.cs.kent.edu/~jmaletic/papers/ICPC2010-CamelCaseUn... says that programmers who are trained in underscore style can recognize underscore style more quickly than camel case, while https://www.researchgate.net/publication/221219628_To_camelcase_or_under-score https://www.researchgate.net/publication/221219628_To_camelc... says that camel case is all around better. At the very least it suggests that "most practical style" is hard to determine.
Avshalom 11y ago
Hyphenated words are a common/familiar feature of English underscores are not. https://en.wikipedia.org/wiki/Hyphen#Joining https://en.wikipedia.org/wiki/Hyphen#Joining

Learn2win 11y ago

In Racket, you can use "-" and "?" in variable names and I love it.

Xophmeister 11y ago
And "/" and ":" and all manner of others. It's a Lisp thing, where the syntax of S-expressions removes any ambiguity.
legulere 11y ago
x-y and x - y meaning different things seems like a great source of errors to me
- jorams 11y ago
  That's not a problem because subtraction in Racket, as in any Lisp-like, looks like this: (- x y)
- breuleux 11y ago
  It depends on a couple of factors. Personally I always write subtraction as "x - y", so I never have any issues. Also, if undeclared variables are a compile-time error, the compiler will (probably) complain loudly about "x-y". So you can fix that quickly and easily, it's not too bad. The one error that might be problematic depending on the language's semantics is if you write something like "x.y-z" intending to subtract "z" from "x.y", but in fact you are going to get the "y-z" property of "x". I must say that in Earl Grey you'll unfortunately end up with "undefined" as the result of that expression (saner languages would raise an exception on a missing property). I have never had that issue in practice, but then again, I always space subtraction.
  - Uncompetative 11y ago
    I don't have a problem with "x - y" and approve of hyphenated names if you can't support spaces within names. I had initially jumped to the conclusion that your language would use a postfix notation and be more influenced by Forth than LISP. This is because I assumed it's name alluded to the way that Captain Jean Luc Picard would program his replicator.

dochtman 11y ago

Nice story. I have similar feelings about my own attempt, Runa (https://github.com/djc/runa https://github.com/djc/runa), in particular about just how large a language (ecosystem) has to be in order to be viable to a few more people. Still, just the journey is quite interesting. It makes you understand other programming languages and their tradeoffs better, and I'm now much less afraid of parsers and lexers and so on. :)

xjay 11y ago

Curious. Are there examples of programming languages that allow spaces in identifiers? Obviously, it would need to be designed for that. I'm against the case-sensitive nature of some programming languages, and file systems for that matter. While it makes sense in a computing context (faster), you invent a new mode, just for the computer.. (Fortran was probably case-insensitive because upper-case letters were used first, and when lower-case letters were introduced, care was taken to neatly map them into the character set bit-wise, so one could simply clear the sixth binary digit to turn a lower-case letter into its upper-case equivalent, then continue the string comparison.) Of course, with Unicode, you need a more complicated check, or you could just ignore Unicode in the language itself for identifiers, yet allow it in literals, data types, etc.

pwg 11y ago
> Curious. Are there examples of programming languages that allow spaces in identifiers? Obviously, it would need to be designed for that. At least Tcl allows spaces in identifiers, but to 'use' such identifiers one does have to add a bit of extra 'sugar' to prevent the code parser from interpreting the spaces as token separators: Example of spaces in a variable name: $ rlwrap tclsh % set "var name with spaces" "contents of the variable" contents of the variable % puts ${var name with spaces} contents of the variable % set "var name with spaces" contents of the variable Example of spaces in a procedure (function) name (the first line defines the procedure): % proc {my space proc} {string} {puts "'my space proc' called with string='$string'"} % {my space proc} "hello how are you" 'my space proc' called with string='hello how are you' % "my space proc" "the quick brown fox" 'my space proc' called with string='the quick brown fox' % set pn "my space proc" my space proc % $pn "this that and the other" 'my space proc' called with string='this that and the other' So there you have at least one example.
jejones3141 11y ago
Algol 68 allows spaces in identifiers. That means one has to use one of the "stropping" techniques to distinguish keywords from identifiers--case stropping (IF p THEN foo ELSE bar FI), quote stropping a la the old IBM Algol F Algol 60 compiler ('if' p 'then' foo 'else' bar 'fi'), and at least one other I don't remember offhand.

lmm 11y ago

> There is a bit of a catch-22 in language design where the more a language is used, the clearer it becomes which parts of it are problematic and should change, but the harder it gets to actually change them. To hone a language you must use it, but applications require that a language's features remain stable, robust, set in stone, and therefore as imperfect as they were at that moment. Furthermore, the more delays are suffered in fixing flaws or plugging holes, the more likely it gets that a dependency is fostered upon them. The options you do not explicitly and insistently leave open, tend to close and seal themselves before you know it. This rings very true. I look at Ceylon and the features I'm most jealous of are things that Scala would and should just do, except for the need to retain compatibility with 10 years of existing applications and libraries, so instead they're enhancement proposals for the version after the version after the next version, and in the meantime we get by with macros that more-or-less cover the most important use cases. And Scala is relatively young as languages go - its warts are nothing to those of, say, C++. Sometimes I wonder if language design can only advance by new languages killing existing languages - past a certain point it seems impossible to change a language in the ways that it needs to be changed to become good.

akkartik 11y ago
I've been trying to break this catch-22 by experimenting with a language/VM/codebase without any backwards-compatibility guarantees. Instead of freezing interfaces for others to use, I'm going to guarantee instead that I'll have tests showing how to use my mechanisms, and you need to have tests for the programs you write using them. I'll try to make breakage happen in obvious rather than subtle ways, but if you don't write tests you'll be in a world of hurt. If you write thorough tests, however, it might be a grand adventure as we hopefully keep the language supple over time. Who's with me? Probably nobody :) Oh well, I'll be here by myself getting muddy in this foot path next to the highway. But it might be entertaining to read about what I've been up to. http://akkartik.name/post/libraries2 http://akkartik.name/post/libraries2 http://akkartik.name/post/readable-bad http://akkartik.name/post/readable-bad http://akkartik.name/about http://akkartik.name/about http://akkartik.name/post/mu http://akkartik.name/post/mu
- 11y ago

mikerichards 11y ago

None of the languages I typically use allow hyphens in identifiers, but I find that kebab-case to be the easiest on the eyes.

DrScump 11y ago
heck, even COBOL '75 (maybe even '68) allowed hyphens in identifiers.

vorg 11y ago

> I chose to compile Earl Grey to JavaScript Some programming languages generate code much deeper down the abstraction stack, e.g. Haskell generating machine code, whereas others generate code to a much shallower depth, e.g. most languages generating JavaScript. A language generating lisp code from some syntax could even be shunting code up the abstraction stack. How deep does the generated code need to be down the stack for some syntax to earn the name "programming language"?

z92 11y ago
If you look at the code, and can't identify it as language X, then it probably deserves a new name.
- MatthewMcDonald 11y ago
  This sounds pretty similar to the definition of a species. If two organisms of appropriate gender can't reproduce with each other, then they probably aren't the same species. If code from two samples can't be interspersed, then it's probably not the same language.
  - labster 11y ago
    Under that definition, Perl and Python have finally merged, given Perl 6's Inline::Python. Peace at last! I'd probably go with a definition more like "mutual intelligibility" like for natural languages, but that doesn't seem right either. Sometimes I have to turn on the subtitles for British TV.
    - Tiksi 11y ago
      Yeah, under that definition everything that supports FFI has merged into a massive unholy mess with C. I guess if it can't be "natively" compiled/interpreted as the same language without inlining or including, I'd say it's a different language.

deleted 11y ago

[deleted]

WalterBright 11y ago

> it is still unsettling when you feel like you can't participate in discussions about programming languages without indulging into self-promotion Ahem, cough, cough, er, ...

decafbad 11y ago

Unfortunately, I can't say this is unexpected: http://breuleux.github.io/earl-grey/repl/ http://breuleux.github.io/earl-grey/repl/

mbil 11y ago
Are you looking for http://breuleux.github.io/earl-grey/repl.html http://breuleux.github.io/earl-grey/repl.html ?
breuleux 11y ago
Ah, yeah, the link to the REPL in the GitHub repository was broken (I figure that's where you got it). I fixed it. As the other commenter pointed out, the real link is http://breuleux.github.io/earl-grey/repl.html http://breuleux.github.io/earl-grey/repl.html

itscharlieb 11y ago

Very interesting account of your experience. I've been toying with the my ideal programming language for some time and am interested. You bring up a good point about people favoring the styles of their most recently used language. For that reason I worry that any language I'd create would merely be a combination of languages I've used previously and not something original. I'm excited to take a look at your work.

bhrgunatha 11y ago

It's not surprising that changing a language would be difficult. It does, after all, include a software component, and pretty much all large software projects suffer the same. It can be easy to change minor technical details, but a deep, far-reaching design decision is very often fixed in place. Even with a good test-suite, that kind of change is rarely undertaken. At least in my experience. I suspect we've all worked on software that you would desperately love to change something fundamental in the design but no matter how painful leaving it alone is, it is preferable to live with the pain than to tear it all down. I've known a few writers for example that say they wish they could change their characters, but it's too late. I wonder if that's analogous.

cle 11y ago

I'm curious, would it have been easier to change design decisions if you hadn't bootstrapped it?

breuleux 11y ago
Probably a little, but I don't think it would have made a big difference. It takes a certain amount of code before it becomes clear that the design has a flaw, and it's going to be the same amount of effort to adapt it, whether that code is in the compiler or elsewhere. A bootstrapped compiler just requires a bit more boilerplate in the transition.

mcnamaratw 11y ago

Well that's the problem that needs solving all right. Yet again today I have a Python project that is already (at 200 lines!) obviously massively compressible if I had macros. Maybe I can get there by returning functions & building up the functionality that way, but it feels like I'm trying to scratch that spot in the middle of my back, where I can't quite reach.

mcnamaratw 11y ago
Rapid prototyping is this alternating process of building stuff up and then boiling it down. The building up is easier in Python, but the boiling down is easier in Lisp. Sure would be nice to have both on tap.