7 ms·

> I'm extremely interested in the idea of taking the syntax highlighting, formatting, and code completion OUT of these specialized IDEs and plugins and into som

> I'm extremely interested in the idea of taking the syntax highlighting, formatting, and code completion OUT of these specialized IDEs and plugins and into some kind of standard "bidirectional channel" between a language processor or compiler, its macro system, and the user's editor of choice. Well maybe if we stopped using ASCII files as our source code and used a richer type of document we could start to make some improvements! What kind of rich document? Well, what about HTML? Did you know you can even embed interactive elements in such documents? What if we started embedding our source code and editors in our documents instead of the other way around? The whole model is inverted, but mainly for historical reasons, because you know, in 1979 all we had was VT100 to interface with our machines... it's like we never moved on... why is my "code" a splattering of ASCII files in a directory? A package definition, tests, dotfiles for this and for that... ship the editor, the tests, the docs, the examples, and the source ALL as one document!

gertef 13y ago
HTML is ASCII.
- williamcotton 13y ago
  Sure, but compare "HTML + Web Browser + HTTP" to "ASCII + VT100"... Right now the terminal is our window and it is nothing but colored ASCII. You can create something interactive and "graphical" like vim or emacs inside of it, but then you can't ship that complete dev environment very easily... it has to be rebuilt from scratch by the individual programmer. The web makes it very easy to ship interactive, dynamic documents and environments around.
  - jlgreco 13y ago
    You're not the first to have this idea, nor will you be the last. Think about why it has not succeeded already.
    - williamcotton 13y ago
      I have thought long and hard about why Smalltalk failed and have had numerous discussions with people and the general ideas are: * poor marketing * expensive, closed license * not enough effort put in to tooling But almost everyone agrees that there is a LOT that was lost when Smalltalk didn't take over the marketplace... the point is, it wasn't because they didn't go with the concept of a filesystem...
  - icebraining 13y ago
    (I think everyone downvoting you is an idiot) I understand what you're saying, but the problem is, I don't want to have to use the preferred editor of the person that happens to be maintaining some random projects I'm editing. I like my VIM and my grep, and my colleague likes her Eclipse and her InstaSearch. Now, that doesn't mean we should eschew all metadata, but I rather see some structured data formats that can be interpreted by the editor and fitted to the user, instead of the other way around. In fact, I'd rather see the web itself move more in that direction. HTML/CSS may be wonderful in terms of the freedom they give to the developer, but it's no free lunch: we lost a lot of potential interoperability by going with free-form, unstructured formats instead of more content and less design driven ones.
    - williamcotton 13y ago
      Why can't we embed vim or emacs in a web document? Can I please point out that building graphical interfaces in ASCII is just about as bone-headed as my suggestion? :)
      - icebraining 13y ago
        Why can't we embed vim or emacs in a web document? We can, that's not the issue. The problem is that if you embed an editor - any editor - into the project, you're forcing everyone to use it, while currently each developer has the freedom to choose his own. And if don't embed the editor, then there's nothing to discuss; one can already use web based editors if one wants to, and I can use VIM ;) Can I please point out that building graphical interfaces in ASCII is just about as bone-headed as my suggestion? :) The whole reason I like VIM is because it barely has any graphical interface. The whole experience is extremely content focused, without a mess of buttons and toolbars obstructing the vision. I talk to it[1], it does what I tell it, and it stays out of my way. So I agree, but it doesn't apply in this case :) [1] http://yanpritzker.com/2011/12/16/learn-to-speak-vim-verbs-nouns-and-modifiers/ http://yanpritzker.com/2011/12/16/learn-to-speak-vim-verbs-n...
        williamcotton 13y ago
  - cantankerous 13y ago
    If you're trying to write code, what to HTTP bring to the game? I think in this case, HTTP would be equivalent to a really, really, really long cord for your keyboard to wherever your code is. Also, if you're using characters or glyphs to write code. It's always ASCII (or your character set of choice). It doesn't matter if it's in the browser or in a terminal. HTML presenting the code that your writing is just cruft.
    - williamcotton 13y ago
      Right now I'm looking at my terminal. It has a bunch of tabs. Each one of those tabs is a little "runtime". However, it is a runtime made up of ascii characters. That's what runs inside of it. Little letters, sometimes colored, sometimes made to look like borders for windows. And I've got this other thing called my web browser. It also has a bunch of tabs, and each one of those tabs is a little "runtime" as well. This one just happens to support embedding images, video, audio, non mono-spaced fonts... My terminal runtime communicates through the filesystem. (it's UNIX, files all the way down...) My web browser "runtime" communicates through HTTP. That's all I'm sayin'. --- Also, I KNOW why UNIX is all files and I get the whole concept of piping ASCII around... yeah, it's fucking awesome! And it's why UNIX is STILL around. It'll be around forever, and man, I DO like it, but should we use it for everything? Why? Piping ASCII around only gets you so far. :) Why am I getting so much HN downvote love for talking about some of the downsides of the UNIX-way?
      - icebraining 13y ago
        But most developers are already using runtimes that support images, videos, audio and non-monospaced fonts: they're called Qt, GTK, Cocoa, etc. So that's not really a reason to switch to the web.
        williamcotton 13y ago
        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!)
- jwilliams 13y ago
  ¿Is it? The HTML that contains your comment is UTF-8.
  - gertef 13y ago
    Sorry, you're right. HTML is text.
- ygra 13y ago
  I'd seriously hope it's Unicode these days.
jacobwcarlson 13y ago
> What if we started embedding our source code and editors in our documents instead of the other way around? We all agreed that was a bad idea: http://en.wikipedia.org/wiki/Opendoc http://en.wikipedia.org/wiki/Opendoc
- gngeal 13y ago
  All? I'm sure Alan Kay would disagree. The problem with OpenDoc is that it emerged at an unfortunate time and asked you to work with vastly inferior languages than what you'd actually need to make this work without getting insane in the process.
t1m 13y ago
That may have been the case in 1979, but in 1980, we got Smalltalk. This environment was (almost) completely without the concept of a file. Code was stored in a persistent 'image', like everything else, and was accessible through normal object based data structures. This, and the fact that all of the source code for the system was immediately available, made it extremely easy to build and extend language level tools like browsers and debuggers. I would say the downside of this 'rich' environment is that your tools tend to become language dependent. Early Smalltalk code versioning tools were fairly easy to build (I'm guessing), but would definitely be Smalltalk centred. The unfortunate advantage of an ASCII text file is that it very difficult to have more than one interpretation of it's non-existent meta-data.
- williamcotton 13y ago
  Thank you for mentioning Smalltalk! My comment was heavily inspired by that "computing environment". If you look at JavaScript and the web browser... well, it's more like a Smalltalk system than a UNIX system! There are no files! It has a weird little dynamic multi-paradigm language! The web browser become the spiritual offspring of Smalltalk as soon as Brendan tacked on JS. :) Look how WEIRD package management gets for JS when you try and make it supported by UNIX and the filesystem! As for tools becoming language dependent... what about sourceMaps? Look at how CoffeeScript integrates with our workflow tools these days! The biggest problem with Smalltalk was that it was made for Personal Computing, and ALWAYS had issues running other people's code or integrating well with collaborators. The web browser and JavaScript solve a lot of these issues with the whole sandboxed code environment... The web has NOTHING to do with files, so it seems like the perfect place to just forget about them and move forward... Relays and switches only got us so far... Machine code only got us so far... UNIX only got us so far... Why have we lost the courage to continue looking for better solutions and being brave enough to throw away certain concepts? I mean, look at mobile and touch computing! iOS and Android are completely abandoning the concept of files! Why? Because they don't really have to be there... Again, look at Smalltalk... and I know, it "failed", but do you really think it failed because it didn't have files? Is that the one reason? Is it even a reason at all??
  - 13y ago

gertef 13y ago

HTML is ASCII.

williamcotton 13y ago
Sure, but compare "HTML + Web Browser + HTTP" to "ASCII + VT100"... Right now the terminal is our window and it is nothing but colored ASCII. You can create something interactive and "graphical" like vim or emacs inside of it, but then you can't ship that complete dev environment very easily... it has to be rebuilt from scratch by the individual programmer. The web makes it very easy to ship interactive, dynamic documents and environments around.
- jlgreco 13y ago
  You're not the first to have this idea, nor will you be the last. Think about why it has not succeeded already.
  - williamcotton 13y ago
    I have thought long and hard about why Smalltalk failed and have had numerous discussions with people and the general ideas are: * poor marketing * expensive, closed license * not enough effort put in to tooling But almost everyone agrees that there is a LOT that was lost when Smalltalk didn't take over the marketplace... the point is, it wasn't because they didn't go with the concept of a filesystem...
- icebraining 13y ago
  (I think everyone downvoting you is an idiot) I understand what you're saying, but the problem is, I don't want to have to use the preferred editor of the person that happens to be maintaining some random projects I'm editing. I like my VIM and my grep, and my colleague likes her Eclipse and her InstaSearch. Now, that doesn't mean we should eschew all metadata, but I rather see some structured data formats that can be interpreted by the editor and fitted to the user, instead of the other way around. In fact, I'd rather see the web itself move more in that direction. HTML/CSS may be wonderful in terms of the freedom they give to the developer, but it's no free lunch: we lost a lot of potential interoperability by going with free-form, unstructured formats instead of more content and less design driven ones.
  - williamcotton 13y ago
    Why can't we embed vim or emacs in a web document? Can I please point out that building graphical interfaces in ASCII is just about as bone-headed as my suggestion? :)
    - icebraining 13y ago
      Why can't we embed vim or emacs in a web document? We can, that's not the issue. The problem is that if you embed an editor - any editor - into the project, you're forcing everyone to use it, while currently each developer has the freedom to choose his own. And if don't embed the editor, then there's nothing to discuss; one can already use web based editors if one wants to, and I can use VIM ;) Can I please point out that building graphical interfaces in ASCII is just about as bone-headed as my suggestion? :) The whole reason I like VIM is because it barely has any graphical interface. The whole experience is extremely content focused, without a mess of buttons and toolbars obstructing the vision. I talk to it[1], it does what I tell it, and it stays out of my way. So I agree, but it doesn't apply in this case :) [1] http://yanpritzker.com/2011/12/16/learn-to-speak-vim-verbs-nouns-and-modifiers/ http://yanpritzker.com/2011/12/16/learn-to-speak-vim-verbs-n...
      - williamcotton 13y ago
- cantankerous 13y ago
  If you're trying to write code, what to HTTP bring to the game? I think in this case, HTTP would be equivalent to a really, really, really long cord for your keyboard to wherever your code is. Also, if you're using characters or glyphs to write code. It's always ASCII (or your character set of choice). It doesn't matter if it's in the browser or in a terminal. HTML presenting the code that your writing is just cruft.
  - williamcotton 13y ago
    Right now I'm looking at my terminal. It has a bunch of tabs. Each one of those tabs is a little "runtime". However, it is a runtime made up of ascii characters. That's what runs inside of it. Little letters, sometimes colored, sometimes made to look like borders for windows. And I've got this other thing called my web browser. It also has a bunch of tabs, and each one of those tabs is a little "runtime" as well. This one just happens to support embedding images, video, audio, non mono-spaced fonts... My terminal runtime communicates through the filesystem. (it's UNIX, files all the way down...) My web browser "runtime" communicates through HTTP. That's all I'm sayin'. --- Also, I KNOW why UNIX is all files and I get the whole concept of piping ASCII around... yeah, it's fucking awesome! And it's why UNIX is STILL around. It'll be around forever, and man, I DO like it, but should we use it for everything? Why? Piping ASCII around only gets you so far. :) Why am I getting so much HN downvote love for talking about some of the downsides of the UNIX-way?
    - icebraining 13y ago
      But most developers are already using runtimes that support images, videos, audio and non-monospaced fonts: they're called Qt, GTK, Cocoa, etc. So that's not really a reason to switch to the web.
      - williamcotton 13y ago
        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!)
jwilliams 13y ago
¿Is it? The HTML that contains your comment is UTF-8.
- gertef 13y ago
  Sorry, you're right. HTML is text.
ygra 13y ago
I'd seriously hope it's Unicode these days.

jacobwcarlson 13y ago

> What if we started embedding our source code and editors in our documents instead of the other way around? We all agreed that was a bad idea: http://en.wikipedia.org/wiki/Opendoc http://en.wikipedia.org/wiki/Opendoc

gngeal 13y ago
All? I'm sure Alan Kay would disagree. The problem with OpenDoc is that it emerged at an unfortunate time and asked you to work with vastly inferior languages than what you'd actually need to make this work without getting insane in the process.

t1m 13y ago

That may have been the case in 1979, but in 1980, we got Smalltalk. This environment was (almost) completely without the concept of a file. Code was stored in a persistent 'image', like everything else, and was accessible through normal object based data structures. This, and the fact that all of the source code for the system was immediately available, made it extremely easy to build and extend language level tools like browsers and debuggers. I would say the downside of this 'rich' environment is that your tools tend to become language dependent. Early Smalltalk code versioning tools were fairly easy to build (I'm guessing), but would definitely be Smalltalk centred. The unfortunate advantage of an ASCII text file is that it very difficult to have more than one interpretation of it's non-existent meta-data.

williamcotton 13y ago
Thank you for mentioning Smalltalk! My comment was heavily inspired by that "computing environment". If you look at JavaScript and the web browser... well, it's more like a Smalltalk system than a UNIX system! There are no files! It has a weird little dynamic multi-paradigm language! The web browser become the spiritual offspring of Smalltalk as soon as Brendan tacked on JS. :) Look how WEIRD package management gets for JS when you try and make it supported by UNIX and the filesystem! As for tools becoming language dependent... what about sourceMaps? Look at how CoffeeScript integrates with our workflow tools these days! The biggest problem with Smalltalk was that it was made for Personal Computing, and ALWAYS had issues running other people's code or integrating well with collaborators. The web browser and JavaScript solve a lot of these issues with the whole sandboxed code environment... The web has NOTHING to do with files, so it seems like the perfect place to just forget about them and move forward... Relays and switches only got us so far... Machine code only got us so far... UNIX only got us so far... Why have we lost the courage to continue looking for better solutions and being brave enough to throw away certain concepts? I mean, look at mobile and touch computing! iOS and Android are completely abandoning the concept of files! Why? Because they don't really have to be there... Again, look at Smalltalk... and I know, it "failed", but do you really think it failed because it didn't have files? Is that the one reason? Is it even a reason at all??
- 13y ago