4 ms·

Sure, but those runtimes are EXTERNAL to their editors! BTW, are you familiar with Literate Programming by Donald Knuth? And the reason I'm mentioning the web

Sure, but those runtimes are EXTERNAL to their editors! BTW, are you familiar with Literate Programming by Donald Knuth? And the reason I'm mentioning the web is because, well, it's a nearly universal runtime and the best thing we've got that might get a lot of really important and forgotten about concepts from Smalltalk back in to the mainstream of computing! Also, are you familiar with Don Knuth's Literate Programming? Thoughts on that? (And yes, I realize this thread is going absolutely everywhere, but I've got a lot of questions!)

icebraining 13y ago
Sure, but those runtimes are EXTERNAL to their editors! No more than than the web browser vis-à-vis the kind of editors you're talking about. They're built on top of the graphical APIs, much like web apps are built on top of HTML/CSS/JS. (Note that I'm referring to graphical editors like Eclipse or Sublime, not ncurses editors in a graphical terminal emulator) And the reason I'm mentioning the web is because, well, it's a nearly universal runtime and the best thing we've got that might get a lot of really important and forgotten about concepts from Smalltalk back in to the mainstream of computing! Maybe, but without a concrete example / vision, I find it hard to believe that I'd be willing to lose the comfort of my development environment for the hack-y, keyboard-hostile world of web applications. Also, are you familiar with Don Knuth's Literate Programming? Thoughts on that? In a very vague way; it didn't really appeal to me, sorry.
- Myrmornis 13y ago
  > In a very vague way; it didn't really appeal to me, sorry. +1 The more prose can be kept out of code the better.
  - williamcotton 13y ago
    I'm curious, how do you document your code? Or are you strictly in the camp that if it is machine-readable and works properly that you've done your job?
    - Myrmornis 13y ago
      Function/method/class docstrings (sorry, my comment may have been misleading) to document the purpose/contract/API, terse inline comments for the implementation only when something is not obvious to a skilled developer. And of course carefully-chosen variable names. I'm not at all a fan of heavily commented code. It just adds more bytes to comprehend, more bytes to maintain, and worst of all a high probability than the code doesn't exactly match the documentation, which causes a significant mental load. Also sometimes leads to people showing off in their natural language descriptions of their code. Same for literate programming: I want as few characters as possible that I have to understand, with that statement appropriately qualified :)

icebraining 13y ago

Sure, but those runtimes are EXTERNAL to their editors! No more than than the web browser vis-à-vis the kind of editors you're talking about. They're built on top of the graphical APIs, much like web apps are built on top of HTML/CSS/JS. (Note that I'm referring to graphical editors like Eclipse or Sublime, not ncurses editors in a graphical terminal emulator) And the reason I'm mentioning the web is because, well, it's a nearly universal runtime and the best thing we've got that might get a lot of really important and forgotten about concepts from Smalltalk back in to the mainstream of computing! Maybe, but without a concrete example / vision, I find it hard to believe that I'd be willing to lose the comfort of my development environment for the hack-y, keyboard-hostile world of web applications. Also, are you familiar with Don Knuth's Literate Programming? Thoughts on that? In a very vague way; it didn't really appeal to me, sorry.

Myrmornis 13y ago
> In a very vague way; it didn't really appeal to me, sorry. +1 The more prose can be kept out of code the better.
- williamcotton 13y ago
  I'm curious, how do you document your code? Or are you strictly in the camp that if it is machine-readable and works properly that you've done your job?
  - Myrmornis 13y ago
    Function/method/class docstrings (sorry, my comment may have been misleading) to document the purpose/contract/API, terse inline comments for the implementation only when something is not obvious to a skilled developer. And of course carefully-chosen variable names. I'm not at all a fan of heavily commented code. It just adds more bytes to comprehend, more bytes to maintain, and worst of all a high probability than the code doesn't exactly match the documentation, which causes a significant mental load. Also sometimes leads to people showing off in their natural language descriptions of their code. Same for literate programming: I want as few characters as possible that I have to understand, with that statement appropriately qualified :)