7 ms·
Ask HN: Is the architecture of programming tools historical accident?
It seems like if we were to build the first program editor/compiler now, with modern software engineering knowledge, it would be natural to use generic 'program models', which would be used to generate source and machine code as 'views'.
The more I've thought about this, the more benefits to structuring things this way appear (e.g. you could have multiple source views for single programming languages, and easier language feedback from tools)
Is there some intrinsic reason that the basic concept behind our program authoring tools is parsing text into ASTs? Is it just historical accident + inertia now? The only concrete thing I can think of is for program exchange, pasting snippets on Stack Overflow or whatever—but there are solutions for that.
I'm thinking about building some kind of editor based on generic program models, but would like to save myself the waste of lots of time and energy if there are fundamental reasons this is a bad idea. I've written in much more detail on the architectural variation I'd be employing here: http://westoncb.blogspot.com/2015/06/how-to-make-view-independent-program.html —and more on the problem/motivation here: http://westoncb.blogspot.com/2015/06/why-programming-languages-dont-have.html
To be clear, I'm NOT advocating visual languages here—it could open up the grounds for different source representations, including those with visual elements, but the architectural change I'm contemplating is independent of those sorts of decisions. I'd still want 90% text personally.
Thanks for any suggestions.
- perfmode 10y agoYou're overfitting to your knowledge of MVC.
- flukus 10y agoYes it's a historical accident. But so far no one has offered anything better, visual programming sucks. As far as inter operability go, nothing beats text.
- westoncb 10y agoI don't mean to advocate visual programming. This is more a question of whether text is used to produce a model, or if the model is used to produce text. In any case, it would enable a wide middle ground of languages that incorporate visual elements and richer interaction, while still being largely (or totally) text-based. Or just variation in text views: for instance, it would be pretty easy to just toggle using curly braces or white space depending on user preference. For interoperability, the program models could also be text, or there could be a canonical text view for particular languages (when you copy a program segment, it copies the corresponding text from the canonical view).
- wmf 10y agoThere are a lot of historical accidents in computing, but OTOH there are also a lot of ideas that seem good but aren't. Non-textual programming has been tried a bunch of times and never really took off but I'm not familiar with the details.
- corysama 10y agoIt's a shame the Intentional Software crew have been nearly silent for the a decade or so they've been in business. They've been doing projections-of-ASTs based programming for a very long time. They bragged a lot about it early on and I haven't heard much of anything since. Here are a couple of demo vids from well over 10 years ago: https://www.youtube.com/watch?v=tSnnfUj1XCQ https://www.youtube.com/watch?v=tSnnfUj1XCQ https://www.youtube.com/watch?v=ZZDwB4-DPXE https://www.youtube.com/watch?v=ZZDwB4-DPXE Here's an interview from 2009 where one of the crew members talks about an annotated S-expression as the core code representation (IIRC, it's been a long time since I listened to it) http://www.se-radio.net/2009/12/episode-151-intentional-software-with-shane-clifford/ http://www.se-radio.net/2009/12/episode-151-intentional-soft...
- westoncb 10y agoInteresting! I'll have to try and figure out what happened with it—sounds very similar to what I'm thinking of. Thanks.