
Apple Dylan IDE (2014) - atjamielittle
https://web.archive.org/web/20140703072127/https://opendylan.org/about/apple-dylan/screenshots/index.html
======
DaiPlusPlus
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)

~~~
jitl
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-
conce...](http://lighttable.com/2012/04/12/light-table-a-new-ide-concept/)

~~~
melloclello
> 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-
par...](http://programmingisterrible.com/post/42432568185/how-to-parse-ruby)

[2]
[https://en.wikipedia.org/wiki/The_lexer_hack](https://en.wikipedia.org/wiki/The_lexer_hack)

~~~
dom0
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)

~~~
Edmond
Are most programming languages really context-sensitive? or aren't they mostly
context-free?

My days of fiddling with writing parsers are long ago
([https://www.codeproject.com/Articles/7035/A-Java-Language-
ID...](https://www.codeproject.com/Articles/7035/A-Java-Language-IDE)) but if
I remember correctly most languages aim for at most a LL(2) grammar, meaning
they are designed so the parser doesn't have to peek more than two tokens
ahead before being able to make a correct determination.

~~~
hornetblack
C has some fun ones:

a * b;

Is either: a times b if a is a var, or declare a varible b with type a. If a
is a typedef.

Also:

some_type b = {a, b, c, d};

Is only valid if some_type is an array or a struct. Which is possibly defined
elsewhere in the source.

(I tend to see this syntax in some code bases (some_type) { a, b, c, d },
which is a bit better).

------
whyenot
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)

~~~
lispm
Note that the Apple Dylan IDE is written mostly in Macintosh Common Lisp. Only
its Interface Builder was written in Dylan, IIRC.

~~~
dreamcompiler
MCL had its own interface builder. Didn't Dylan just use MCL's?

~~~
lispm
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.

------
threeseed
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.

~~~
gilgoomesh
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/DocumentRoo...](https://root.cern.ch/TaligentDocs/TaligentOnline/DocumentRoot/1.0/Docs/books/PF/PF_1.html)

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.

------
hydandata
[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
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. :)

------
cm2187
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
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
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.

------
borplk
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.

~~~
al2o3cr
Isomorf seems like a great way to write Isomorf code in many languages, in
much the same way that you can "translate" Lisps to any language by writing a
tiny interpreter. If you can push one button and get either Haskell or
Javascript, either weird Haskell or weird Javascript is likely coming out.

Further, watching that video I was reminded of using the Equation Editor in
Word long long ago. Frightfully un-ergonomic pixel-fiddling ("no, I meant put
the insertion point INSIDE that expression!") compared to entering the same
formulas boring-ASCII-style in LaTeX.

    
    
        For example we will get structured version control. No need to have something like git tracking lines in files.
    

If there's "no syntax", what exactly is this showing diffs of? ASTs? "We will
get" is handwaving a lot of R&D here, even before you get to "how can
Programmer A communicate about a diff to Programmer B when they read the code
with different syntax?"

I don't see a huge difference between things like "tests embedded in metadata"
and "tests embedded in comments"; they're both blocks of associated bytes that
tooling is responsible for interpreting. Many of the examples you're
describing are entirely possible with things like static analysis,
annotations, etc. The difference is that in order to get them we didn't have
to throw away EVERY tool we were using and start over. Bootstrapping a new
non-text environment would be a substantial effort, and doing it without
ending up in the same spot as M-expressions (where an intended for-machines-
only representation displaced the more-complex planned notation) would be even
harder.

I'd recommend checking out some of Joe Armstrong's stuff - he's been pondering
the "global registry of functions with unique name" thing for a couple years.

~~~
borplk
With regards to the "diff" which I forgot to address earlier.

The changeset still has a textual representation.

So the diff could be like a webpage that is showing:

On 5 June 2017 John Smith authored the following changeset:

\- Added new function that calculates sum of given numbers (click to view)

\- Removed function called "old calculate sum"

The program is not the syntax the syntax is just a representation of it.

So if I have added a new function we can both look at the diff.

We will both see that I have added a function.

We could both choose to view the body of the function in the same syntax, or
you could configure your editor to show it in a different way. In the same way
that you could configure the font size or the colour scheme.

The point is to reduce the importance of things that are not inherently part
of the domain and give that importance to the problem/domain itself.

So you could view a "number node" like "5,000,000" and I could view it like
"5_000_000".

I could view a function definition like "declare function named blah" you
could view it as "def fun blah".

Because we are still looking at the exact same thing it makes no difference in
the result of the program.

------
etchalon
Some days, I still miss OS 8.

~~~
cm2187
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
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
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.

