Live data from Hacker News

Apple Dylan IDE (2014)

web.archive.org

41–50 of 58 posts

Re: Apple Dylan IDE (2014)

#41
post #18

Earlier quoted context omitted.

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

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…

Previously:

http://graydon2.dreamwidth.org/193447.html

https://news.ycombinator.com/item?id=8451271

Re: Apple Dylan IDE (2014)

#42
post #39

Earlier quoted context omitted.

> 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 g…

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)

Context free grammars are perfectly capable of expressing matched curly braces, even with unbounded nesting. Am I missing something?

Re: Apple Dylan IDE (2014)

#43
post #36

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…

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

Old-school VB actually shows you all your code (sorry, best video I could find quickly: 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 code editor.

Re: Apple Dylan IDE (2014)

#44
post #32

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…

(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 d…

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

Re: Apple Dylan IDE (2014)

#45
post #39

Earlier quoted context omitted.

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)

Context free grammars are perfectly capable of expressing matched curly braces, even with unbounded nesting. Am I missing something?

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.

Re: Apple Dylan IDE (2014)

#46
post #12

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 interesti…

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.

Re: Apple Dylan IDE (2014)

#47
post #39

Earlier quoted context omitted.

> 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 g…

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)

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

Re: Apple Dylan IDE (2014)

#48

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…

This has all been available in Visual Studio for as long as I can remember.

Re: Apple Dylan IDE (2014)

#49

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/

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

Re: Apple Dylan IDE (2014)

#50
post #46
post #12

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 interesti…

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…

It will be something close to an AST.

"syntax" is the textual representation of an underlying structure.

When all of our tooling revolves our modifying text/syntax not the underlying structure we make our lives very difficult and create new "artificial" problems with regards to parsing/extracting and so on.

A sufficiently good editor could make the experience even better than a normal text editor.

The crucial difference is that there's no such concept as "lines" or "files". But it could visually almost represent it to you in that way.

So you would type "let x = 1;" instead of it saving those characters in some file it would modify the program/tree and add a node that represents the fact that "assign 1 to name x".

As I also stated I know many of the things I have mentioned are already kind-of possible with the tooling that we have but they are bolted on in such a way that is disconnected from other components so we lack a more global view into a system as a whole.

This creates little isolated/disconnected worlds within a system and significantly reduces the potential and benefits of things we could do.

It also reduces accuracy to a level that you always have to have your guards up and can't fully trust the system. It turns into a helpful heuristic but not a first-class part of the system.

It is one thing to be able to "parse all of this crap and extract these blocks of characters that we think are the documentation" vs having strong accurate links established so that the entire system is capable of querying navigating metadata associated to objects.

Tests and benchmarks and documentation and all sorts of stuff can become first-class citizen objects in a programming language and the compiler and tooling gets exposed to that information it can suddenly start helping you a lot more than it is otherwise able to when it has no view into that stuff (i.e. compiler ignoring the comments).

Lots of things that are today very cumbersome and require sophisticated parsing and so on become very easy because you don't have to parse/compute stuff, information about the structure is readily available and queryable.

For example all your "logging" stuff could simply be tagged as "log".

Then when you are compiling you could say "take out all function calls tagged as log as if they didn't exist".

Again there's a huge but yet subtle difference between that and what we are capable of doing today.

We today we have ways of kind-of achieving the same thing by #ifdef compile constants and so on but one is inherently semantic and logically sound the other one is just arranging a sequence of side-effects to achieve a desired effect without exposing that insight to the compiler/environment itself.

That difference is the essence of intentional programming.

The system allows you to express and preserve your intent in its original semantic form that is the blueprint for the software that is produced from it.

If you are interested to learn more about this topic you can watch some of Charles Simonyi's presentations on YouTube on this topic, they are long but worth a listen.

https://www.youtube.com/results?search_query=charles+simonyi

Post reply on HN