Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Apple Dylan IDE (2014)

web.archive.org

Post reply on HN
Print view View original

51–58 of 58 posts

Re: Apple Dylan IDE (2014)

#51

Post by paulddraper »

borplk wrote: 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…

Sounds great in theory.

The dirty reality is that text is the lowest common denominator, and as such, most reusable.

Speaking of Microsoft, I would rather manage flat config files than structured registry editors.

Re: Apple Dylan IDE (2014)

#52

Post by borplk »

paulddraper wrote: post #51
borplk wrote: 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…

Sounds great in theory. The dirty reality is that text is the lowest common denominator, and as such, most reusable. Speaking of Microsoft, I would rather manage flat config files than structured registry editors.

I know. That's why I think it's a very difficult but worthwhile problem to tackle.

We have stopped questioning certain things and take them for granted and those come with certain constraints and limit our progress.

(Such as the idea that any programming must involve editing text that is stored in a collection of files and folders)

I also think we under-estimate how pleasant a structured editor can be.

Most programmers associate those things with "toys" or think of them as not hardcore enough for their skills, some clunky drag-and-drop GUI editor that insults the mad skills of the precious programmer who has embedded vim/emacs bindings in his/her muscle memory.

It doesn't have to be that way. If it's flexible enough it can look almost like a plain text editor. But it would be one on steroids. It could do holy-grail stuff in terms of suggestions/intellisense/auto-complete and so on because of its rich understanding of the underlying structure.

Re: Apple Dylan IDE (2014)

#53

Post by borplk »

al2o3cr wrote: post #46
borplk wrote: 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…

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.

Re: Apple Dylan IDE (2014)

#54

Post by hornetblack »

Edmond wrote: post #47
dom0 wrote: 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)

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

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

Re: Apple Dylan IDE (2014)

#55

Post by tjoff »

coldtea wrote: post #44
tjoff wrote: post #32

Earlier quoted context omitted.

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

True, but this truly is a non-issue.

Re: Apple Dylan IDE (2014)

#56

Post by dTal »

tjoff wrote: post #32
DaiPlusPlus wrote: post #4

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…

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.

Re: Apple Dylan IDE (2014)

#57

Post by aaron_kent »

borplk wrote: 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…

Hello! I’m Aaron one of the co-founders of isomorƒ. Sorry our site was down when you visited. We’ve actually just pushed a new demo (https://isomorf.io/#!/demos) and we would love feedback on it (feedback@isomorf.com)! We are planning a public beta soon and we’re looking for participants (https://isomorf.io/#!/sign-up).

Your descriptions of projectional editing and intentional programming very much resonate with the vision we are pursuing. We agree that structured editing can create much more efficient paradigms for refactoring, reuse, and stability. Why do we search for code based on text rather than real function signatures and even input/output examples? Why do we need to change languages just to use new control structures? Why do we accept the coarse granularity of file level commits? Why are things like parallelization/caching part of code rather than ex-post runtime configuration? Why does deployment need to involve endless command line idiosyncrasies

This is definitely a complex problem, but we feel a paradigm shift is necessary to make a step change in software development efficiency. We’d love to discuss further.

Re: Apple Dylan IDE (2014)

#58

Post by tjoff »

dTal wrote: post #56
tjoff wrote: post #32

Earlier quoted context omitted.

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

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

no one would suggest adding it

Disagree.

Post reply on HN