4 ms·

Ooh, I like this. Too many people start projects at the logical beginning. But what you really want early on in a project is to maximize speed of exploration of

Ooh, I like this. Too many people start projects at the logical beginning. But what you really want early on in a project is to maximize speed of exploration of the interesting parts. To me there's a clear analogy with startups. The naive conception of starting a company is that you get a pile of money so you can hire a bunch of people and create important infrastructure. But with startups, you're trying something new, so the most efficient use of time is to find the riskiest hypotheses and test them as directly as possible. That often involves doing things that seem wrong if you proceed in the "logical" way. E.g., I knew a successful UGC company that didn't implement accounts and logins until like 6 months in. But that was fine, because actual accounts were not needed to figure out whether the business worked.

dcz_self 3y ago
Start in the middle. It's the most interesting part, too. After all, that's the core of your idea. I don't know where I heard this, but the idea is so important to me that I saved it on my blog: https://dorotac.eu/posts/in_the_middle/ https://dorotac.eu/posts/in_the_middle/
- mjcohen 3y ago
  That is also a good way to start an improv scene. Figure out later, if at all, what is really going on.
- lelanthran 3y ago
  > Start in the middle. It's the most interesting part, too. After all, that's the core of your idea. For a programming language? Maybe if you are designing your language by feature list. What if you are designing a programming language for ergonomics instead? Let's be real - the differentiating factor in any modern language design is the syntax, not the features. They all mostly support a similar cross-section of features, in terms of "getting things done". What you are really designing is a competitor to the existing languages, in which case it is beyond the scope and effort of a lone developer to match feature-for-feature of modern languages. My experience of lone-wolf programming languages is all the same ... namely ... Even if you do have one, single, differentiating feature, people aren't going to adopt unless you have all the other features they want. Doesn't matter how good your feature is if your language is missing some feature that people like in current mainstream languages. You should also be careful of thinking that a single good feature will cause a little adoption; if it's any good the existing languages will simply adopt it! Another path into darkness is thinking that the batteries included is so different to current offerings that people will adopt it, such as that recent post on HN about a language developed for cloud by the author of CDK. There's nothing in that language that can't be implemented as a library for existing languages. For programming languages alone, going feature-first is a good way to produce an obscure language that no one is interested in. Without even a small community, the original dev themselves won't use it. Where a new language makes sense is in ergonomics, not in features. Can you make the syntax such that people onboard quickly? Can your syntax support something complicated in a manner that the most simple-minded developer can understand? Is your syntax amenable to collaboration? Can it be easily parsed in pieces for IDEs? Will the output be package-distributable or module-distributable? Can you ensure easy GDB integration? What build mechanism can be used (for reading the sources and figuring out dependencies). Syntax is the major difference between writing in Kotlin and writing in Java. My new language project, I'm still trying to nail down what the syntax should look like. I have no problem documenting the tree to support features I want, but I find that settling on what good syntax looks like to the majority of corporate developers is really really difficult. Compare with, from an AST, emitting code for some advanced language constructs. That's almost a mechanical effort that I think I can delegate a lot of to ChatGPT. Designing universally acceptable syntax, on the other hand, is a lot more complex and requires actual human decision-making.
  - wpietri 3y ago
    As far as I can tell, this author is writing a language just for the experience of writing a language, without much regard to getting it used, so it sounds like their success criteria may be a fair bit different than yours.
    - lelanthran 3y ago
      > As far as I can tell, this author is writing a language just for the experience of writing a language, without much regard to getting it used, so it sounds like their success criteria may be a fair bit different than yours. Actually, his criteria was exactly the same as mine when I first started writing my own languages - learning experience, bragging rights, whatever.[1] At some point, though, even I didn't use my own languages, because without a community of users, it soon became pointless. That's the thing about some projects - they take off even when the objective is not to build something that takes off. It's why I admire (and maybe slightly jealous of, as well) Andreas Kling's SerenityOS. It's the only project I can think of in recent years that was totally superflous and unnecessary (any solo OS or PL project is, at this point in time), and yet its gathering steam and shaping up to be a real contender. But that type of thing is like winning the lottery - the odds are against it. [1] One of my comments on HN last week mentioned that I want to write a Forth type language, and telling one of the responders to my comment that it isn't because there doesn't exist a quality Forth implementation.
danybittel 3y ago
That is sort of the idea of the MVP (minimum viable product). I prefer the analogy of painting. You start with collecting references, exploring ideas in a sketchbook, make color tests, draw outlines on canvas, use big brushes for colors, refine with smaller and smaller details. The problem is, that programming is all details / only details. There is no easy way to use big brushstrokes, so you have to improvise and not loose the overview. It doesn't help that engineers love details.

dcz_self 3y ago

Start in the middle. It's the most interesting part, too. After all, that's the core of your idea. I don't know where I heard this, but the idea is so important to me that I saved it on my blog: https://dorotac.eu/posts/in_the_middle/ https://dorotac.eu/posts/in_the_middle/

mjcohen 3y ago
That is also a good way to start an improv scene. Figure out later, if at all, what is really going on.
lelanthran 3y ago
> Start in the middle. It's the most interesting part, too. After all, that's the core of your idea. For a programming language? Maybe if you are designing your language by feature list. What if you are designing a programming language for ergonomics instead? Let's be real - the differentiating factor in any modern language design is the syntax, not the features. They all mostly support a similar cross-section of features, in terms of "getting things done". What you are really designing is a competitor to the existing languages, in which case it is beyond the scope and effort of a lone developer to match feature-for-feature of modern languages. My experience of lone-wolf programming languages is all the same ... namely ... Even if you do have one, single, differentiating feature, people aren't going to adopt unless you have all the other features they want. Doesn't matter how good your feature is if your language is missing some feature that people like in current mainstream languages. You should also be careful of thinking that a single good feature will cause a little adoption; if it's any good the existing languages will simply adopt it! Another path into darkness is thinking that the batteries included is so different to current offerings that people will adopt it, such as that recent post on HN about a language developed for cloud by the author of CDK. There's nothing in that language that can't be implemented as a library for existing languages. For programming languages alone, going feature-first is a good way to produce an obscure language that no one is interested in. Without even a small community, the original dev themselves won't use it. Where a new language makes sense is in ergonomics, not in features. Can you make the syntax such that people onboard quickly? Can your syntax support something complicated in a manner that the most simple-minded developer can understand? Is your syntax amenable to collaboration? Can it be easily parsed in pieces for IDEs? Will the output be package-distributable or module-distributable? Can you ensure easy GDB integration? What build mechanism can be used (for reading the sources and figuring out dependencies). Syntax is the major difference between writing in Kotlin and writing in Java. My new language project, I'm still trying to nail down what the syntax should look like. I have no problem documenting the tree to support features I want, but I find that settling on what good syntax looks like to the majority of corporate developers is really really difficult. Compare with, from an AST, emitting code for some advanced language constructs. That's almost a mechanical effort that I think I can delegate a lot of to ChatGPT. Designing universally acceptable syntax, on the other hand, is a lot more complex and requires actual human decision-making.
- wpietri 3y ago
  As far as I can tell, this author is writing a language just for the experience of writing a language, without much regard to getting it used, so it sounds like their success criteria may be a fair bit different than yours.
  - lelanthran 3y ago
    > As far as I can tell, this author is writing a language just for the experience of writing a language, without much regard to getting it used, so it sounds like their success criteria may be a fair bit different than yours. Actually, his criteria was exactly the same as mine when I first started writing my own languages - learning experience, bragging rights, whatever.[1] At some point, though, even I didn't use my own languages, because without a community of users, it soon became pointless. That's the thing about some projects - they take off even when the objective is not to build something that takes off. It's why I admire (and maybe slightly jealous of, as well) Andreas Kling's SerenityOS. It's the only project I can think of in recent years that was totally superflous and unnecessary (any solo OS or PL project is, at this point in time), and yet its gathering steam and shaping up to be a real contender. But that type of thing is like winning the lottery - the odds are against it. [1] One of my comments on HN last week mentioned that I want to write a Forth type language, and telling one of the responders to my comment that it isn't because there doesn't exist a quality Forth implementation.

danybittel 3y ago

That is sort of the idea of the MVP (minimum viable product). I prefer the analogy of painting. You start with collecting references, exploring ideas in a sketchbook, make color tests, draw outlines on canvas, use big brushes for colors, refine with smaller and smaller details. The problem is, that programming is all details / only details. There is no easy way to use big brushstrokes, so you have to improvise and not loose the overview. It doesn't help that engineers love details.