4 ms·

Great question. On second thoughts, is there much to say except "Combine the parts you like from existing languages and the new things you want"? And, read stuf

Great question. On second thoughts, is there much to say except "Combine the parts you like from existing languages and the new things you want"? And, read stuff about how existing languages were designed.

ndrewxie 9y ago
Yes, I've been combining features from different languages (Smalltalk and Haskell), but all I have now is this huge mess that I don't know how to fix.
- ndrewxie 9y ago
  They're opposites, I know. I'm trying to put strong, static typing and laziness onto Smalltalk and clean up it's syntax a bit (it's already pretty clean, just a few things could be improved) - essentially a faster Smalltalk.
  - DonaldFisk 9y ago
    > I'm trying to put strong, static typing and laziness onto Smalltalk This actually sounds quite interesting. You're starting from a good language (Smalltalk) and adding a feature absent from it but widely regarded as desirable (strong static typing). > and clean up its syntax a bit (it's already pretty clean, just a few things could be improved) If you go for type inference instead of having types explicitly declared, you might be able to avoid both run-time type checks and changes to Smalltalk's syntax. > essentially a faster Smalltalk. Bryce Kampjes (http://www.kampjes.demon.co.uk/index.html http://www.kampjes.demon.co.uk/index.html) was working on compiling Smalltalk byte code into machine code to speed it up, but that didn't involve changes to the language, so I think run-time type checks would still have been necessary. Making static type checks would result in a further speed-up. Good luck.
    - woolybully 9y ago
      Have a look at StrongTalk.
      - ndrewxie 9y ago
        Yes, I saw that. I'm planning to make something similar, but still pretty different.
    - blt 9y ago
      how can laziness be reconciled with the statefulness of Smalltalk? wouldn't it require an incredibly smart compiler to reason about the order in which different parts of the code can modify state?
      - ndrewxie 9y ago
        Well, most variables are immutable in my language (took the lazy way out). The few mutable ones are "owned" by one scope, and must operate on the same thread.
    - ndrewxie 9y ago
      Not to bother you with this REALLY long mess, but I've been working on it for a while already, so could you please review it for me? Some flaws just won't work out correctly, and I need a pair of fresh eyes to look at it. Laziness isn't added yet, and there are a lot of flaws that make it not ready for any sort of use (recreational or otherwise). Thanks! Report can be found at https://gist.github.com/ndrewxie/54d3299c998569c27e281d2320b43dc3 https://gist.github.com/ndrewxie/54d3299c998569c27e281d2320b...
ndrewxie 9y ago
I googled about the origins of many common languages, but most of them were just based off of another language. I tried finding out how those languages were made, but it just goes on...
- DonaldFisk 9y ago
  I identified eleven ground breaking languages here: http://web.onetel.com/~hibou/blog/GroundBreakingLanguages.html http://web.onetel.com/~hibou/blog/GroundBreakingLanguages.ht... There's a family tree of languages here: http://www.digibarn.com/collections/posters/tongues/tongues.jpg http://www.digibarn.com/collections/posters/tongues/tongues....
- PeterisP 9y ago
  Well, that's still the right direction that you should pursue. The buck stops somewhere, the history is not that long - if you trace all the ancestors and key influencers of a single language, that's generally 10 at most; and if you trace another language, half of them will overlap. You can't really skip that step anyway, it's not like you can make an informed decision about a particular syntax feature if you haven't taken a serious look on how that feature works or doesn't work in a dozen languages; and the more obscure languages tend to be very useful in this regard because they explore a larger variety of features and their combinations. Getting a short overview of syntax of at least some 25 languages would be a reasonable prerequisite before designing another one, and that overview would still be the easy and straightforward part.
  - ndrewxie 9y ago
    OK, I'll follow the chain to the end :)

ndrewxie 9y ago

Yes, I've been combining features from different languages (Smalltalk and Haskell), but all I have now is this huge mess that I don't know how to fix.

ndrewxie 9y ago
They're opposites, I know. I'm trying to put strong, static typing and laziness onto Smalltalk and clean up it's syntax a bit (it's already pretty clean, just a few things could be improved) - essentially a faster Smalltalk.
- DonaldFisk 9y ago
  > I'm trying to put strong, static typing and laziness onto Smalltalk This actually sounds quite interesting. You're starting from a good language (Smalltalk) and adding a feature absent from it but widely regarded as desirable (strong static typing). > and clean up its syntax a bit (it's already pretty clean, just a few things could be improved) If you go for type inference instead of having types explicitly declared, you might be able to avoid both run-time type checks and changes to Smalltalk's syntax. > essentially a faster Smalltalk. Bryce Kampjes (http://www.kampjes.demon.co.uk/index.html http://www.kampjes.demon.co.uk/index.html) was working on compiling Smalltalk byte code into machine code to speed it up, but that didn't involve changes to the language, so I think run-time type checks would still have been necessary. Making static type checks would result in a further speed-up. Good luck.
  - woolybully 9y ago
    Have a look at StrongTalk.
    - ndrewxie 9y ago
      Yes, I saw that. I'm planning to make something similar, but still pretty different.
  - blt 9y ago
    how can laziness be reconciled with the statefulness of Smalltalk? wouldn't it require an incredibly smart compiler to reason about the order in which different parts of the code can modify state?
    - ndrewxie 9y ago
      Well, most variables are immutable in my language (took the lazy way out). The few mutable ones are "owned" by one scope, and must operate on the same thread.
  - ndrewxie 9y ago
    Not to bother you with this REALLY long mess, but I've been working on it for a while already, so could you please review it for me? Some flaws just won't work out correctly, and I need a pair of fresh eyes to look at it. Laziness isn't added yet, and there are a lot of flaws that make it not ready for any sort of use (recreational or otherwise). Thanks! Report can be found at https://gist.github.com/ndrewxie/54d3299c998569c27e281d2320b43dc3 https://gist.github.com/ndrewxie/54d3299c998569c27e281d2320b...

ndrewxie 9y ago

I googled about the origins of many common languages, but most of them were just based off of another language. I tried finding out how those languages were made, but it just goes on...

DonaldFisk 9y ago
I identified eleven ground breaking languages here: http://web.onetel.com/~hibou/blog/GroundBreakingLanguages.html http://web.onetel.com/~hibou/blog/GroundBreakingLanguages.ht... There's a family tree of languages here: http://www.digibarn.com/collections/posters/tongues/tongues.jpg http://www.digibarn.com/collections/posters/tongues/tongues....
PeterisP 9y ago
Well, that's still the right direction that you should pursue. The buck stops somewhere, the history is not that long - if you trace all the ancestors and key influencers of a single language, that's generally 10 at most; and if you trace another language, half of them will overlap. You can't really skip that step anyway, it's not like you can make an informed decision about a particular syntax feature if you haven't taken a serious look on how that feature works or doesn't work in a dozen languages; and the more obscure languages tend to be very useful in this regard because they explore a larger variety of features and their combinations. Getting a short overview of syntax of at least some 25 languages would be a reasonable prerequisite before designing another one, and that overview would still be the easy and straightforward part.
- ndrewxie 9y ago
  OK, I'll follow the chain to the end :)