4 ms·

Yeah, I am pretty excited about the idea of IDEs just presenting ASTs instead of text (of course can always save as text). There's a haskell structured mode tha

by rtpg 10y ago

Yeah, I am pretty excited about the idea of IDEs just presenting ASTs instead of text (of course can always save as text). There's a haskell structured mode that tries to do a similar thing. It might seem silly, but the biggest impediment I can think of is copy-pasting code from elsewhere. If your variable names are different, the IDE should reject the code (since you shouldn't be able to commit variables that don't exist), but then what do you do? Open it in Notepad and "fix" it? EDIT: structured haskell mode, complete with GIFs showing how it works https://github.com/chrisdone/structured-haskell-mode#features https://github.com/chrisdone/structured-haskell-mode#feature...

merijnv 10y ago
Are you familiar with Lamdu? http://www.lamdu.org/ http://www.lamdu.org/
e12e 10y ago
Brings to mind Smalltalk's concept of images (which comes from lisp, I believe) and Forth. Of course in Smalltalk, you do work with code-as-text, but then it becomes code-as-program (technically byte-code, with among other things a text representation). Does seem more reasonable than the anachronistic insistence on text->parse-to-AST->(whatever magic, and however many transforms the actual compile-part is). Then again, we all know what a rich editor is. It's MS Word. And MS Word eats documents and depricates file formats. On the other hand, I think Emacs Org-mode, Gimp images and the literate editor in Python, Leo[l] are examples of more pleasant "rich format" editors. It is a bit odd that what we take for granted for image files (edit history, binary format++) we fear in our IDEs. [l] http://leoeditor.com/ http://leoeditor.com/
- lispm 10y ago
  Core images in Lisp have been used since the early 60s. See for example the Lisp 1.5 manual. Appendix E describes the handling of images: http://www.softwarepreservation.org/projects/LISP/book/LISP%201.5%20Programmers%20Manual.pdf http://www.softwarepreservation.org/projects/LISP/book/LISP%... > Overlord is the monitor of the LISP System. It controls the handling of tapes, the reading and writing of entire core images, the historical memory of the system, and the taking of dumps.

by rtpg 10y ago

merijnv 10y ago

Are you familiar with Lamdu? http://www.lamdu.org/ http://www.lamdu.org/

e12e 10y ago

Brings to mind Smalltalk's concept of images (which comes from lisp, I believe) and Forth. Of course in Smalltalk, you do work with code-as-text, but then it becomes code-as-program (technically byte-code, with among other things a text representation). Does seem more reasonable than the anachronistic insistence on text->parse-to-AST->(whatever magic, and however many transforms the actual compile-part is). Then again, we all know what a rich editor is. It's MS Word. And MS Word eats documents and depricates file formats. On the other hand, I think Emacs Org-mode, Gimp images and the literate editor in Python, Leo[l] are examples of more pleasant "rich format" editors. It is a bit odd that what we take for granted for image files (edit history, binary format++) we fear in our IDEs. [l] http://leoeditor.com/ http://leoeditor.com/

lispm 10y ago
Core images in Lisp have been used since the early 60s. See for example the Lisp 1.5 manual. Appendix E describes the handling of images: http://www.softwarepreservation.org/projects/LISP/book/LISP%201.5%20Programmers%20Manual.pdf http://www.softwarepreservation.org/projects/LISP/book/LISP%... > Overlord is the monitor of the LISP System. It controls the handling of tapes, the reading and writing of entire core images, the historical memory of the system, and the taking of dumps.