4 ms·

> there is no way in the language's design to pass a string to a function that only accepts a number, for example, because the "blocks just don't fit together.

by bpizzi 7y ago

> there is no way in the language's design to pass a string to a function that only accepts a number, for example, because the "blocks just don't fit together." Which is easily achieved by the first typed language that comes to hand, no?

shadowgovt 7y ago
Not without an IDE. It's still extremely possible (in all text-based languages I'm familiar with) to write the program with a typecheck error; the typechecker will gleefully catch it for you. At typecheck time. Often (depending on my toolchain) minutes after I've written the offending code and mounds of code depending on it. It's possible, with many languages, to write IDEs that will make this hard, but I've yet to find one that makes it impossible. Certainly not in the same way that, for example, Scratch will simply refuse to let the offending blocks click together. I certainly don't advocate transitioning from text languages to Scratch, but I think there's meat on the bones of asking the question "Why, when I'm editing code in text-based languages, am I even allowed to reference a variable that is demonstrably the wrong type? What benefit is that gaining me?" Because I think the answer in a lot of cases is "No real benefit; editing, typechecking, and compilation have just historically been disjoint concerns with no feedback channel because writing those is hard."
- pwinnski 7y ago
  Are you suggesting that you can do visual development without anything more than a text editor? Apples to apples would mean comparing your Scratch experience with a nice IDE for a typed language.
  - shadowgovt 7y ago
    "It's possible, with many languages, to write IDEs that will make this hard, but I've yet to find one that makes it impossible."
- zokier 7y ago
  I'm strong believer, even if that belief doesn't come up often, in structured editing[1] which sort of bridges the gap and makes writing invalid programs impossible, at least syntatically but I don't think adding type level checking is a big jump and I haven't kept up with research so that might already be there. Unfortunately I don't know any successful examples of that beyond research projects that I could point out. I remember hearing rumors that some of the LISP machines might have veered to that direction, but idk Even more I don't believe in plain monospaced ASCII being the ultimate format for code. Luckily there I know one example that goes at least a bit further: Fortress[2], a language from Sun that had richer rendering format available (although the underlying form was still afaik textual). And of course APL is another example, albeit bit less easily approachable. Raku also has some cute tricks (of course it does) with unicode characters[3], but they are more really just tricks that radical revolution in design. There are also lots of other interesting ideas on how to format and layout code in the research, just one random example is "code bubbles"/"debugger canvas"[4] While I think all this and so much more has great potential, there is huge cultural entrenchment around simple text based programming that seems unlikely to be overcome any time soon. As for graphical programming, I think the common failure there is being often also heavily mouse-driven, while keyboard is really powerful input device. [1] https://en.wikipedia.org/wiki/Structure_editor https://en.wikipedia.org/wiki/Structure_editor also known as projectional editor [2] https://web.archive.org/web/20060819201513/http://research.sun.com/projects/plrg/PLDITutorialSlides9Jun2006.pdf https://web.archive.org/web/20060819201513/http://research.s... has some examples, slide 33 [3] https://docs.raku.org/language/unicode_ascii https://docs.raku.org/language/unicode_ascii for example "The atomic operators have U+269B ATOM SYMBOL incorporated into them. Their ASCII equivalents are ordinary subroutines, not operators". Obviously. [4] https://www.microsoft.com/en-us/research/publication/debugger-canvas-industrial-experience-with-the-code-bubbles-paradigm/ https://www.microsoft.com/en-us/research/publication/debugge... paper has few screenshots
  - lizmat 7y ago
    Re: "The atomic operators have U+269B ATOM SYMBOL incorporated into them. Their ASCII equivalents are ordinary subroutines, not operators". Obviously." Except for the short-circuiting operators (such as || and &&) and the assignment operator, all operators in Raku are just subs with a special name. Adding your own operator to the language is as simple as adding a subroutine, e.g.: sub prefix:<√>($value) { sqrt($value) } say √9; # 3
- deleted 7y ago
  [deleted]

by bpizzi 7y ago

shadowgovt 7y ago

Not without an IDE. It's still extremely possible (in all text-based languages I'm familiar with) to write the program with a typecheck error; the typechecker will gleefully catch it for you. At typecheck time. Often (depending on my toolchain) minutes after I've written the offending code and mounds of code depending on it. It's possible, with many languages, to write IDEs that will make this hard, but I've yet to find one that makes it impossible. Certainly not in the same way that, for example, Scratch will simply refuse to let the offending blocks click together. I certainly don't advocate transitioning from text languages to Scratch, but I think there's meat on the bones of asking the question "Why, when I'm editing code in text-based languages, am I even allowed to reference a variable that is demonstrably the wrong type? What benefit is that gaining me?" Because I think the answer in a lot of cases is "No real benefit; editing, typechecking, and compilation have just historically been disjoint concerns with no feedback channel because writing those is hard."

pwinnski 7y ago
Are you suggesting that you can do visual development without anything more than a text editor? Apples to apples would mean comparing your Scratch experience with a nice IDE for a typed language.
- shadowgovt 7y ago
  "It's possible, with many languages, to write IDEs that will make this hard, but I've yet to find one that makes it impossible."
zokier 7y ago
I'm strong believer, even if that belief doesn't come up often, in structured editing[1] which sort of bridges the gap and makes writing invalid programs impossible, at least syntatically but I don't think adding type level checking is a big jump and I haven't kept up with research so that might already be there. Unfortunately I don't know any successful examples of that beyond research projects that I could point out. I remember hearing rumors that some of the LISP machines might have veered to that direction, but idk Even more I don't believe in plain monospaced ASCII being the ultimate format for code. Luckily there I know one example that goes at least a bit further: Fortress[2], a language from Sun that had richer rendering format available (although the underlying form was still afaik textual). And of course APL is another example, albeit bit less easily approachable. Raku also has some cute tricks (of course it does) with unicode characters[3], but they are more really just tricks that radical revolution in design. There are also lots of other interesting ideas on how to format and layout code in the research, just one random example is "code bubbles"/"debugger canvas"[4] While I think all this and so much more has great potential, there is huge cultural entrenchment around simple text based programming that seems unlikely to be overcome any time soon. As for graphical programming, I think the common failure there is being often also heavily mouse-driven, while keyboard is really powerful input device. [1] https://en.wikipedia.org/wiki/Structure_editor https://en.wikipedia.org/wiki/Structure_editor also known as projectional editor [2] https://web.archive.org/web/20060819201513/http://research.sun.com/projects/plrg/PLDITutorialSlides9Jun2006.pdf https://web.archive.org/web/20060819201513/http://research.s... has some examples, slide 33 [3] https://docs.raku.org/language/unicode_ascii https://docs.raku.org/language/unicode_ascii for example "The atomic operators have U+269B ATOM SYMBOL incorporated into them. Their ASCII equivalents are ordinary subroutines, not operators". Obviously. [4] https://www.microsoft.com/en-us/research/publication/debugger-canvas-industrial-experience-with-the-code-bubbles-paradigm/ https://www.microsoft.com/en-us/research/publication/debugge... paper has few screenshots
- lizmat 7y ago
  Re: "The atomic operators have U+269B ATOM SYMBOL incorporated into them. Their ASCII equivalents are ordinary subroutines, not operators". Obviously." Except for the short-circuiting operators (such as || and &&) and the assignment operator, all operators in Raku are just subs with a special name. Adding your own operator to the language is as simple as adding a subroutine, e.g.: sub prefix:<√>($value) { sqrt($value) } say √9; # 3
deleted 7y ago
[deleted]