6 ms·

Apple Dylan IDE (2014)

131 points by atjamielittle 9y ago

DaiPlusPlus 9y ago
What I like the most is the abstraction-away from plaintext source files. Imagine a C and C++ IDE that hid the (often ugly) source files from you put only exposed individual function definitions - it could automatically keep header files in-sync, for example, and automatically place each free-function or class member in the right file without manual refactoring. (I still think it's outrageous that C is still a single-pass language - we shouldn't need separate simultaneous declaration and definitions any more)
- atjamielittle 9y ago
  I think I would love this.
- jsmthrowaway 9y ago
  Extremely relevant, particularly his remarks: https://youtu.be/8pTEmbeENF4?t=1174 https://youtu.be/8pTEmbeENF4?t=1174 (19:34 if t= doesn't work).
- tcbawo 9y ago
  Unfortunately, preprocessing would make this difficult or impossible. Even with modern C++, people still rely on it.
- jitl 9y ago
  This is what Lighttable aimed to do - create an extensible, abstracted code editor for many languages. See also CodeBubbles (Java) and most Smalltalk environments. http://lighttable.com/2012/04/12/light-table-a-new-ide-concept/ http://lighttable.com/2012/04/12/light-table-a-new-ide-conce...
  - melloclello 9y ago
    > It’s no secret that I really like Clojure and as a lisp, it was the easiest language for me to start the prototype with, but there’s no reason this couldn’t be done for any language with a dynamic runtime. The rest is mostly simple analysis of an AST and some clever inference. I have looked into this. It is kind of criminal that for most real world languages (Ruby[1], C[2] etc), it's not possible to just define a grammar and throw it at a standard parser generator for them - they generally have one or two quirks which make this infeasible. In my ideal alternate universe it would be considered unthinkable to publish a language without also publishing a grammar in a standard format for said language, which can then be plugged into your favourite text/semantic/tree editor. Our tools should dictate our languages, not the other way around. [1] http://programmingisterrible.com/post/42432568185/how-to-parse-ruby http://programmingisterrible.com/post/42432568185/how-to-par... [2] https://en.wikipedia.org/wiki/The_lexer_hack https://en.wikipedia.org/wiki/The_lexer_hack
    - dom0 9y ago
      Most programming languages are context-sensitive [1] (at least with unbounded nesting), so parsing them correctly and efficiently is mathematically impossible. All practical implementations have to take shortcuts. [1] Mainly due to begin..end blocks, curly braces or indentation (as in Python)
      - wtetzner 9y ago
        Context free grammars are perfectly capable of expressing matched curly braces, even with unbounded nesting. Am I missing something?
        dom0 9y ago
        Yes, thinking about it that alone is not sufficient. Still, I'd claim that most languages are not context free. CPP (Pre-processor) aside, C is not context free due to typedef making identifiers ambiguous. Also if-then-else? Since C++ templates are turing-complete, the grammar is probably unrestricted. Python is not context free due to if ...: stmt1 if ...: stmt2 stmt3 stmt3 and stmt1 have to share the same level of indentation to form a valid Python program, but they might contain arbitrary indentation within brackets.
  - munificent 9y ago
    The RealBASIC IDE also give you a function-based editing experience instead of storing entire text files full of code. It was kind of neat, but also led to a lot of clicking around. It's one of those Holy Grail ideas people have been talking about forever, but I'm not convinced it's actually that superior given all of the ecosystem downsides there are to moving away from text. I think you probably could do something better than text files, but it has to be a lot better to get over the chasm of losing all of your familiar editors, command line text utilities like grep, easy copy/paste, etc. Text is a lowest common denominator medium. People get hung up on the "lowest" part, but the "common" part is pretty damn convenient.
    - carussell 9y ago
      Previously: http://graydon2.dreamwidth.org/193447.html http://graydon2.dreamwidth.org/193447.html https://news.ycombinator.com/item?id=8451271 https://news.ycombinator.com/item?id=8451271
  - masklinn 9y ago
    And Self's Morphic, which went even further ("static" objects would be defined via UI elements with only the method bodies being written in small editors)
- nuopnu 9y ago
  You are thinking of a structured editor. But as to the single feature you mentioned, see for example Code Bubbles: https://www.youtube.com/watch?v=PsPX0nElJ0k https://www.youtube.com/watch?v=PsPX0nElJ0k
- tjoff 9y ago
  (I still think it's outrageous that C is still a single-pass language - we shouldn't need separate simultaneous declaration and definitions any more) Maybe not, but I have a hard time to believe that it can be considered even a slight annoyance to anyone but people just learning how to program. The same people that are annoyed by it probably benefits from it anyway, forces them to actually think about what they are doing. Also makes it easier to get an overview of the code using just a text editor. KISS.
  - coldtea 9y ago
    >Maybe not, but I have a hard time to believe that it can be considered even a slight annoyance to anyone but people just learning how to program. Slight annoyances pile up. Ergonomics matter even for seasoned pros. Just because they have learned to ignore the garbage, doesn't mean their room is clean.
    - tjoff 9y ago
      True, but this truly is a non-issue.
  - dTal 9y ago
    Seems like status quo bias. If C did not have this wart, no one would suggest adding it just to "force beginners to think about what they are doing" or "make it easier to get an overview of the code using a text editor". And human factors matter. In the context of language design, they're the only things that matter - the entire function of a programming language is to make a complicated task fit a human brain as neatly as possible.
    - tjoff 9y ago
      no one would suggest adding it Disagree.
- tajen 9y ago
  Visual Basic / Excel VBA does that, and I thought it was the way to go until 18yo. But when you can only see one function/event handler at a time, you lose the understanding of how programming works. If only I had been exposed to plain-text programming (Maven + .java) instead of using Windows/visual editors for years...
  - meredydd 9y ago
    Old-school VB actually shows you all your code (sorry, best video I could find quickly: https://youtu.be/zmyZCmX2LWQ?t=2m21s https://youtu.be/zmyZCmX2LWQ?t=2m21s). They were aware of the issue you raised, having tried separate-function editing as far back as QuickBasic for DOS. The usability engineering of old-school VB (of which VBA is the modern representative) was frankly top-notch, and I feel no shame following their footsteps in the https://anvil.works https://anvil.works code editor.
- dontyouremember 9y ago
  This has all been available in Visual Studio for as long as I can remember.
whyenot 9y ago
Macintosh Common Lisp is another one. It was so much fun to use and worked so well with MacOS. Echoing etchalon's comment, sometimes I miss OS 8 (also 9). https://en.wikipedia.org/wiki/Macintosh_Common_Lisp https://en.wikipedia.org/wiki/Macintosh_Common_Lisp
- mikek 9y ago
  Command-E for Execute!
- lispm 9y ago
  Note that the Apple Dylan IDE is written mostly in Macintosh Common Lisp. Only its Interface Builder was written in Dylan, IIRC.
  - dreamcompiler 9y ago
    MCL had its own interface builder. Didn't Dylan just use MCL's?
    - lispm 9y ago
      No, it had its own - at least in the 'released' technology preview. The Dylan Interface Builder was written in Dylan itself and was loaded directly into the running Dylan application. The Apple Dylan IDE itself was running as a separate MCL application. You can see from the screenshots that the IB also had a different look&feel.
cm2187 9y ago
It's funny because this is basically the VBA editor. You have a tree on the left with classes and modules, then in the main pane you have a drop down at the top to select functions and the text editor (if configured that way) will show a single function. I wonder when Microsoft will do any work on the VBA editor. It's not like VBA is going away. Office users still write new VBA every day. They need it.
- DaiPlusPlus 9y ago
  It clear Microsoft intends to replace VBA with JavaScript that will run both in desktop Office and Office Online - we have it already with "Office Apps", but Office Apps are sandboxed pretty bad and have zero access to COM and legacy Office components. Assuming Microsoft eventually brings JS-in-Office to feature-parity with VBA then they can kill off the old editor.
  - cm2187 9y ago
    It will take many years before they can do that. First because they haven't provided an alternative yet (javascript is used to create addins, not for users to create scripts or make new functions available). Second because you have millions of business processes that rely on VBA. So as far as I can tell the transition hasn't even started.
etchalon 9y ago
Some days, I still miss OS 8.
- cm2187 9y ago
  What I miss the most is the extension system. Where installing something (driver, new feature, etc) on the OS is as simple as dropping a file in a folder. And uninstalling it deleting this file. And you know there is nothing left after you removed the extension.
  - mattkevan 9y ago
    What I don't miss is when the extensions conflict, crashing the machine on boot. I also don't miss the process of removing each extension one by one, rebooting each time to find the culprit.
    - cm2187 9y ago
      That's still way better than trying to figure out which driver is causing a BSOD on windows today. Let's keep in mind this was a pre-protected memory OS.
  - deleted 9y ago
    [deleted]
- linux2647 9y ago
  Me too.
- lispm 9y ago
  What I don't miss is the single address space memory without any protection or the relatively primitive multitasking.
threeseed 9y ago
It's always interesting to look back on those days at Apple when they were so innovative and took so many risks when it came to software. Technologies like OpenDoc, Cyberdog, Hypercard, AppleScript, Taligent were really quite unique.
- atjamielittle 9y ago
  I've really been enjoying reading Brent Simmons blog about his efforts to get Frontier running on modern macOS: http://inessential.com/frontierdiary http://inessential.com/frontierdiary I suppose that Apple Dylan was similar to Frontier in the sense that they were programming environments built around an object databases. Frontier was a shipping product though!
- Volt 9y ago
  Back when they actually had an R&D department.
- frozenport 9y ago
  Hypercard should not be on that list, it was succeful despite official neglect.
- gilgoomesh 9y ago
  You clearly never used Taligent and OpenDoc. They were innovation by committee and completely revolting. You can read the introductory Taligent tutorial here: https://root.cern.ch/TaligentDocs/TaligentOnline/DocumentRoot/1.0/Docs/books/PF/PF_1.html https://root.cern.ch/TaligentDocs/TaligentOnline/DocumentRoo... As for Hypercard... it wasn't Apple's innovation but Bill Atkinson's (he designed and wrote the whole thing). Once Bill left (6 months later), no one else was really able to manage the codebase and it rotted for a decade or two until it was finally cancelled.
borplk 9y ago
In case people don't know, this is often referred to as a "projectional editor" and the paradigm is also known as "Intentional Programming" in the sense that the programming environment helps capture the intent of the authors. Popularised (if we can call it popular!) by Charles Simonyi of Microsoft's fame who created the company called Intentional Software that was recently purchased by Microsoft. There was interesting editor called Isomorf that demonstrates the benefits of a non-text-based editor. (site is down https://isomorf.io/ https://isomorf.io/) (youtube demo https://www.youtube.com/watch?v=awDVuZQQWqQ https://www.youtube.com/watch?v=awDVuZQQWqQ) I would really like to see something like this take off. I firmly believe we can only unlock the next generation of software engineering by breaking free from plaintext. Think about it, how many more ASCII symbols can we mangle together to create meaning and context? A structural editor takes all of that away. Suddenly syntax becomes a choice just like the colour theme of your editor. Plaintext programming puts us into a fight with the computers because on one hand we need to keep the syntax parsable and on one hand humans need to read and write it. It's a huge conflict of interest. You want to provide information to the compiler now the syntax becomes hard and complicated (rough example: Java). You want to keep the syntax human-friendly now the program becomes weak from the compiler's point of view (rough example: Python). Our editors need to be context aware so they can hide/show relevant information and to encourage the people to provide as much information about the context/domain as possible. If you look around you see we have been doing a lot of this stuff in the past decades but for some reason we just half-ass it by baking stuff on top of plaintext. For example embedding documentation or even unit tests (python "doctests") in comment blocks in ad-hoc languages. Or we embed naming conventions and so on to relate concepts with each other. For example a "User.js" file and "User.spec.js" file for a test. If we kept information in a structured manner suddenly so many of our problems would go away. For example we will get structured version control. No need to have something like git tracking lines in files. We will get unit testing that is always correctly tied to its relevant components. We will get documentation that is structurally accurate. The editor could switch between programming and "documentation" mode. But the documentation would be a first-class object of the program not just some text that is shoved into it somewhere. We will get much smarter re-factoring. We will get much better compatibility across versions. Because there's no syntax to worry about breaking from a textual perspective. Because the program becomes a semantic tree and older programs can be "transformed" to fix them or make them compatible or something similar. Because we are text-free the environment can encourage the programmer to provide a lot more information because it can get folded/hidden/etc. The "units" will all have unique identifiers so confusion in naming and so on will be significantly reduced. Perhaps you could create and publish modules/units in some central repository then use them in your projects. Kind of like NPM for example but a lot more structured. So you could import a bunch of "units"/functions from someone else's catalogue. Because everything could have metadata attached to it you could imagine for example "security advisories" could be attached to certain units such as a function and published. The environment would know exactly in which places you are calling that exact function and it could alert you to the fact. You could do semantic find and replace ("show me all sql queries", "show me all untested functions", "show me all functions modified by John Smith since last 14 days", "show me all undocumented functions", etc...). You could do smarter CI/CD by way of defining rules and constraints on the structure of the program. Made-up Examples: - If the changeset involves objects tagged with "security" require approval before deploy - If the changeset introduces new SQL queries ping the DBA team - If the changeset introduces more than 1 function without corresponding documentation show warning - If more than 50% of the new objects introduced in the changeset lack corresponding test cases fail the build - You get the idea.. The point is, all the cool stuff we'd like to do depends on us having a lot more structured information and context about our programs and a plaintext environment is not suitable and is hostile towards that.
hydandata 9y ago
https://discuss.atom.io/t/the-deuce-editor-architecture/2218 https://discuss.atom.io/t/the-deuce-editor-architecture/2218 goes into a bit of detail regarding the editor, deuce. Note, you can download and play with the IDE, and read the source code, it is part of OpenDylan distribution, but sadly only works on windows right now https://opendylan.org/ https://opendylan.org/
- BruceM 9y ago
  I wrote that on the Atom forums ... that's the editor in Open Dylan, which used to be Harlequin Dylan (and was Functional Developer after Harlequin folded and before being open sourced). I had parts of Deuce up and running as a terminal-based editor at some point. Well, I didn't do input which is clearly a very important thing ... but I'd made good progress on the output side of things. :)

131 points by atjamielittle 9y ago

What I like the most is the abstraction-away from plaintext source files. Imagine a C and C++ IDE that hid the (often ugly) source files from you put only exposed individual function definitions - it could automatically keep header files in-sync, for example, and automatically place each free-function or class member in the right file without manual refactoring. (I still think it's outrageous that C is still a single-pass language - we shouldn't need separate simultaneous declaration and definitions any more)

atjamielittle 9y ago
I think I would love this.
jsmthrowaway 9y ago
Extremely relevant, particularly his remarks: https://youtu.be/8pTEmbeENF4?t=1174 https://youtu.be/8pTEmbeENF4?t=1174 (19:34 if t= doesn't work).
tcbawo 9y ago
Unfortunately, preprocessing would make this difficult or impossible. Even with modern C++, people still rely on it.
jitl 9y ago
This is what Lighttable aimed to do - create an extensible, abstracted code editor for many languages. See also CodeBubbles (Java) and most Smalltalk environments. http://lighttable.com/2012/04/12/light-table-a-new-ide-concept/ http://lighttable.com/2012/04/12/light-table-a-new-ide-conce...
- melloclello 9y ago
  > It’s no secret that I really like Clojure and as a lisp, it was the easiest language for me to start the prototype with, but there’s no reason this couldn’t be done for any language with a dynamic runtime. The rest is mostly simple analysis of an AST and some clever inference. I have looked into this. It is kind of criminal that for most real world languages (Ruby[1], C[2] etc), it's not possible to just define a grammar and throw it at a standard parser generator for them - they generally have one or two quirks which make this infeasible. In my ideal alternate universe it would be considered unthinkable to publish a language without also publishing a grammar in a standard format for said language, which can then be plugged into your favourite text/semantic/tree editor. Our tools should dictate our languages, not the other way around. [1] http://programmingisterrible.com/post/42432568185/how-to-parse-ruby http://programmingisterrible.com/post/42432568185/how-to-par... [2] https://en.wikipedia.org/wiki/The_lexer_hack https://en.wikipedia.org/wiki/The_lexer_hack
  - dom0 9y ago
    Most programming languages are context-sensitive [1] (at least with unbounded nesting), so parsing them correctly and efficiently is mathematically impossible. All practical implementations have to take shortcuts. [1] Mainly due to begin..end blocks, curly braces or indentation (as in Python)
    - wtetzner 9y ago
      Context free grammars are perfectly capable of expressing matched curly braces, even with unbounded nesting. Am I missing something?
      - dom0 9y ago
        Yes, thinking about it that alone is not sufficient. Still, I'd claim that most languages are not context free. CPP (Pre-processor) aside, C is not context free due to typedef making identifiers ambiguous. Also if-then-else? Since C++ templates are turing-complete, the grammar is probably unrestricted. Python is not context free due to if ...: stmt1 if ...: stmt2 stmt3 stmt3 and stmt1 have to share the same level of indentation to form a valid Python program, but they might contain arbitrary indentation within brackets.
- munificent 9y ago
  The RealBASIC IDE also give you a function-based editing experience instead of storing entire text files full of code. It was kind of neat, but also led to a lot of clicking around. It's one of those Holy Grail ideas people have been talking about forever, but I'm not convinced it's actually that superior given all of the ecosystem downsides there are to moving away from text. I think you probably could do something better than text files, but it has to be a lot better to get over the chasm of losing all of your familiar editors, command line text utilities like grep, easy copy/paste, etc. Text is a lowest common denominator medium. People get hung up on the "lowest" part, but the "common" part is pretty damn convenient.
  - carussell 9y ago
    Previously: http://graydon2.dreamwidth.org/193447.html http://graydon2.dreamwidth.org/193447.html https://news.ycombinator.com/item?id=8451271 https://news.ycombinator.com/item?id=8451271
- masklinn 9y ago
  And Self's Morphic, which went even further ("static" objects would be defined via UI elements with only the method bodies being written in small editors)
nuopnu 9y ago
You are thinking of a structured editor. But as to the single feature you mentioned, see for example Code Bubbles: https://www.youtube.com/watch?v=PsPX0nElJ0k https://www.youtube.com/watch?v=PsPX0nElJ0k
tjoff 9y ago
(I still think it's outrageous that C is still a single-pass language - we shouldn't need separate simultaneous declaration and definitions any more) Maybe not, but I have a hard time to believe that it can be considered even a slight annoyance to anyone but people just learning how to program. The same people that are annoyed by it probably benefits from it anyway, forces them to actually think about what they are doing. Also makes it easier to get an overview of the code using just a text editor. KISS.
- coldtea 9y ago
  >Maybe not, but I have a hard time to believe that it can be considered even a slight annoyance to anyone but people just learning how to program. Slight annoyances pile up. Ergonomics matter even for seasoned pros. Just because they have learned to ignore the garbage, doesn't mean their room is clean.
  - tjoff 9y ago
    True, but this truly is a non-issue.
- dTal 9y ago
  Seems like status quo bias. If C did not have this wart, no one would suggest adding it just to "force beginners to think about what they are doing" or "make it easier to get an overview of the code using a text editor". And human factors matter. In the context of language design, they're the only things that matter - the entire function of a programming language is to make a complicated task fit a human brain as neatly as possible.
  - tjoff 9y ago
    no one would suggest adding it Disagree.
tajen 9y ago
Visual Basic / Excel VBA does that, and I thought it was the way to go until 18yo. But when you can only see one function/event handler at a time, you lose the understanding of how programming works. If only I had been exposed to plain-text programming (Maven + .java) instead of using Windows/visual editors for years...
- meredydd 9y ago
  Old-school VB actually shows you all your code (sorry, best video I could find quickly: https://youtu.be/zmyZCmX2LWQ?t=2m21s https://youtu.be/zmyZCmX2LWQ?t=2m21s). They were aware of the issue you raised, having tried separate-function editing as far back as QuickBasic for DOS. The usability engineering of old-school VB (of which VBA is the modern representative) was frankly top-notch, and I feel no shame following their footsteps in the https://anvil.works https://anvil.works code editor.
dontyouremember 9y ago
This has all been available in Visual Studio for as long as I can remember.

whyenot 9y ago

Macintosh Common Lisp is another one. It was so much fun to use and worked so well with MacOS. Echoing etchalon's comment, sometimes I miss OS 8 (also 9). https://en.wikipedia.org/wiki/Macintosh_Common_Lisp https://en.wikipedia.org/wiki/Macintosh_Common_Lisp

mikek 9y ago
Command-E for Execute!
lispm 9y ago
Note that the Apple Dylan IDE is written mostly in Macintosh Common Lisp. Only its Interface Builder was written in Dylan, IIRC.
- dreamcompiler 9y ago
  MCL had its own interface builder. Didn't Dylan just use MCL's?
  - lispm 9y ago
    No, it had its own - at least in the 'released' technology preview. The Dylan Interface Builder was written in Dylan itself and was loaded directly into the running Dylan application. The Apple Dylan IDE itself was running as a separate MCL application. You can see from the screenshots that the IB also had a different look&feel.

cm2187 9y ago

It's funny because this is basically the VBA editor. You have a tree on the left with classes and modules, then in the main pane you have a drop down at the top to select functions and the text editor (if configured that way) will show a single function. I wonder when Microsoft will do any work on the VBA editor. It's not like VBA is going away. Office users still write new VBA every day. They need it.

DaiPlusPlus 9y ago
It clear Microsoft intends to replace VBA with JavaScript that will run both in desktop Office and Office Online - we have it already with "Office Apps", but Office Apps are sandboxed pretty bad and have zero access to COM and legacy Office components. Assuming Microsoft eventually brings JS-in-Office to feature-parity with VBA then they can kill off the old editor.
- cm2187 9y ago
  It will take many years before they can do that. First because they haven't provided an alternative yet (javascript is used to create addins, not for users to create scripts or make new functions available). Second because you have millions of business processes that rely on VBA. So as far as I can tell the transition hasn't even started.

etchalon 9y ago

Some days, I still miss OS 8.

cm2187 9y ago
What I miss the most is the extension system. Where installing something (driver, new feature, etc) on the OS is as simple as dropping a file in a folder. And uninstalling it deleting this file. And you know there is nothing left after you removed the extension.
- mattkevan 9y ago
  What I don't miss is when the extensions conflict, crashing the machine on boot. I also don't miss the process of removing each extension one by one, rebooting each time to find the culprit.
  - cm2187 9y ago
    That's still way better than trying to figure out which driver is causing a BSOD on windows today. Let's keep in mind this was a pre-protected memory OS.
- deleted 9y ago
  [deleted]
linux2647 9y ago
Me too.
lispm 9y ago
What I don't miss is the single address space memory without any protection or the relatively primitive multitasking.

threeseed 9y ago

It's always interesting to look back on those days at Apple when they were so innovative and took so many risks when it came to software. Technologies like OpenDoc, Cyberdog, Hypercard, AppleScript, Taligent were really quite unique.

atjamielittle 9y ago
I've really been enjoying reading Brent Simmons blog about his efforts to get Frontier running on modern macOS: http://inessential.com/frontierdiary http://inessential.com/frontierdiary I suppose that Apple Dylan was similar to Frontier in the sense that they were programming environments built around an object databases. Frontier was a shipping product though!
Volt 9y ago
Back when they actually had an R&D department.
frozenport 9y ago
Hypercard should not be on that list, it was succeful despite official neglect.
gilgoomesh 9y ago
You clearly never used Taligent and OpenDoc. They were innovation by committee and completely revolting. You can read the introductory Taligent tutorial here: https://root.cern.ch/TaligentDocs/TaligentOnline/DocumentRoot/1.0/Docs/books/PF/PF_1.html https://root.cern.ch/TaligentDocs/TaligentOnline/DocumentRoo... As for Hypercard... it wasn't Apple's innovation but Bill Atkinson's (he designed and wrote the whole thing). Once Bill left (6 months later), no one else was really able to manage the codebase and it rotted for a decade or two until it was finally cancelled.

borplk 9y ago

In case people don't know, this is often referred to as a "projectional editor" and the paradigm is also known as "Intentional Programming" in the sense that the programming environment helps capture the intent of the authors. Popularised (if we can call it popular!) by Charles Simonyi of Microsoft's fame who created the company called Intentional Software that was recently purchased by Microsoft. There was interesting editor called Isomorf that demonstrates the benefits of a non-text-based editor. (site is down https://isomorf.io/ https://isomorf.io/) (youtube demo https://www.youtube.com/watch?v=awDVuZQQWqQ https://www.youtube.com/watch?v=awDVuZQQWqQ) I would really like to see something like this take off. I firmly believe we can only unlock the next generation of software engineering by breaking free from plaintext. Think about it, how many more ASCII symbols can we mangle together to create meaning and context? A structural editor takes all of that away. Suddenly syntax becomes a choice just like the colour theme of your editor. Plaintext programming puts us into a fight with the computers because on one hand we need to keep the syntax parsable and on one hand humans need to read and write it. It's a huge conflict of interest. You want to provide information to the compiler now the syntax becomes hard and complicated (rough example: Java). You want to keep the syntax human-friendly now the program becomes weak from the compiler's point of view (rough example: Python). Our editors need to be context aware so they can hide/show relevant information and to encourage the people to provide as much information about the context/domain as possible. If you look around you see we have been doing a lot of this stuff in the past decades but for some reason we just half-ass it by baking stuff on top of plaintext. For example embedding documentation or even unit tests (python "doctests") in comment blocks in ad-hoc languages. Or we embed naming conventions and so on to relate concepts with each other. For example a "User.js" file and "User.spec.js" file for a test. If we kept information in a structured manner suddenly so many of our problems would go away. For example we will get structured version control. No need to have something like git tracking lines in files. We will get unit testing that is always correctly tied to its relevant components. We will get documentation that is structurally accurate. The editor could switch between programming and "documentation" mode. But the documentation would be a first-class object of the program not just some text that is shoved into it somewhere. We will get much smarter re-factoring. We will get much better compatibility across versions. Because there's no syntax to worry about breaking from a textual perspective. Because the program becomes a semantic tree and older programs can be "transformed" to fix them or make them compatible or something similar. Because we are text-free the environment can encourage the programmer to provide a lot more information because it can get folded/hidden/etc. The "units" will all have unique identifiers so confusion in naming and so on will be significantly reduced. Perhaps you could create and publish modules/units in some central repository then use them in your projects. Kind of like NPM for example but a lot more structured. So you could import a bunch of "units"/functions from someone else's catalogue. Because everything could have metadata attached to it you could imagine for example "security advisories" could be attached to certain units such as a function and published. The environment would know exactly in which places you are calling that exact function and it could alert you to the fact. You could do semantic find and replace ("show me all sql queries", "show me all untested functions", "show me all functions modified by John Smith since last 14 days", "show me all undocumented functions", etc...). You could do smarter CI/CD by way of defining rules and constraints on the structure of the program. Made-up Examples: - If the changeset involves objects tagged with "security" require approval before deploy - If the changeset introduces new SQL queries ping the DBA team - If the changeset introduces more than 1 function without corresponding documentation show warning - If more than 50% of the new objects introduced in the changeset lack corresponding test cases fail the build - You get the idea.. The point is, all the cool stuff we'd like to do depends on us having a lot more structured information and context about our programs and a plaintext environment is not suitable and is hostile towards that.

hydandata 9y ago

https://discuss.atom.io/t/the-deuce-editor-architecture/2218 https://discuss.atom.io/t/the-deuce-editor-architecture/2218 goes into a bit of detail regarding the editor, deuce. Note, you can download and play with the IDE, and read the source code, it is part of OpenDylan distribution, but sadly only works on windows right now https://opendylan.org/ https://opendylan.org/

BruceM 9y ago
I wrote that on the Atom forums ... that's the editor in Open Dylan, which used to be Harlequin Dylan (and was Functional Developer after Harlequin folded and before being open sourced). I had parts of Deuce up and running as a terminal-based editor at some point. Well, I didn't do input which is clearly a very important thing ... but I'd made good progress on the output side of things. :)