3 ms·

The evolution of a programming language over four years

35 points by nkurz 11y ago

joe_the_user 11y ago
I tend to think that in producing something like a programming language, it is really worthwhile spending a lot of time thinking and rethinking. The language is a complex "artifact" with many surprises waiting within it. Wanting to go as quickly to implementation as possible seems like mistake - better to spend "debugging" one's syntax and semantics and underlying data structures.
- mpweiher 11y ago
  Like many other things in code: you get better information about your design from running code than from thought experiments. "There is no difference between theory and practice. In theory."
  - joe_the_user 11y ago
    One certainly gets some new information about one's code when one runs it. But there are plenty of pieces of information about an application that one won't get by running a bit of code. Running part of a language implementation won't tell you if the language itself has a flaw that will annoy user because it won't run the entire language. Running a single module won't tell you if there's a flaw in the way information flows in your application because the different modules aren't interacting. And if you writing an application and find flaws in a user interface or similar large-scale aspects, you may find that you have to rewrite much of the application or jury-rig existing code to make things work. And iteratively jury-rigging code is a practice that guarantees extra effort latter.
    - nostrademons 11y ago
      The way to find flaws in a programming language is to write real programs that do useful things in that language. It's usually hard to write real programs that do useful things before the programming language has an implementation.
      - joe_the_user 11y ago
        All I'm saying really is that the language syntax/semantics/etc is a "functional part of the system" that needs testing to various degrees even if that's hard pre-implementation. Having fallen into the trap myself, I think it's easy for someone who's just cooking their own little language to think of the syntax as being just a matter of taste and intuition instead and do virtually no testing of these parts. Obviously, producing a full implementation and then using that implementation fully is the ideal way to find flaws. But considering that often everyone is too committed to change a language at that point, the result is simply that we right now have mostly languages that many consider flawed.
allard 11y ago
The name of the language doesn't appear until the fifth paragraph?!
- panic 11y ago
  For the curious, the programming language is called "Lily". There is a website at http://jesserayadkins.github.io http://jesserayadkins.github.io.
deleted 11y ago
[deleted]

35 points by nkurz 11y ago

I tend to think that in producing something like a programming language, it is really worthwhile spending a lot of time thinking and rethinking. The language is a complex "artifact" with many surprises waiting within it. Wanting to go as quickly to implementation as possible seems like mistake - better to spend "debugging" one's syntax and semantics and underlying data structures.

mpweiher 11y ago
Like many other things in code: you get better information about your design from running code than from thought experiments. "There is no difference between theory and practice. In theory."
- joe_the_user 11y ago
  One certainly gets some new information about one's code when one runs it. But there are plenty of pieces of information about an application that one won't get by running a bit of code. Running part of a language implementation won't tell you if the language itself has a flaw that will annoy user because it won't run the entire language. Running a single module won't tell you if there's a flaw in the way information flows in your application because the different modules aren't interacting. And if you writing an application and find flaws in a user interface or similar large-scale aspects, you may find that you have to rewrite much of the application or jury-rig existing code to make things work. And iteratively jury-rigging code is a practice that guarantees extra effort latter.
  - nostrademons 11y ago
    The way to find flaws in a programming language is to write real programs that do useful things in that language. It's usually hard to write real programs that do useful things before the programming language has an implementation.
    - joe_the_user 11y ago
      All I'm saying really is that the language syntax/semantics/etc is a "functional part of the system" that needs testing to various degrees even if that's hard pre-implementation. Having fallen into the trap myself, I think it's easy for someone who's just cooking their own little language to think of the syntax as being just a matter of taste and intuition instead and do virtually no testing of these parts. Obviously, producing a full implementation and then using that implementation fully is the ideal way to find flaws. But considering that often everyone is too committed to change a language at that point, the result is simply that we right now have mostly languages that many consider flawed.

allard 11y ago

The name of the language doesn't appear until the fifth paragraph?!

panic 11y ago
For the curious, the programming language is called "Lily". There is a website at http://jesserayadkins.github.io http://jesserayadkins.github.io.

deleted 11y ago

[deleted]