4 ms·

In few years you'll discover classic Smalltalk workstations, modern Pharo, with a probably nicer language than Smalltalk itself. This model is essentially the o

by kkfx 3y ago

In few years you'll discover classic Smalltalk workstations, modern Pharo, with a probably nicer language than Smalltalk itself. This model is essentially the original desktop model with it's end-user programming concept.

MarceColl 3y ago
I've already tried pharo, my problem there is with the next step, making that production ready. I need tooling that allows explorative programming and that can be transitioned into production. If not it's just another source of rigidness, just later in the process
- kkfx 3y ago
  That's not much a Pharo or CL issue but a social issue: actual IT development, and for the last decades, have gone in a regressive path for commercial reasons and it's from enough from these systems and paradigms to have a nearly impossible to fill gap in between. Personally I live digitally in Emacs, so I have some tooling for the present word, mostly hidden under Emacs or *nix system, but yes, it's still limited, less then Pharo since I can read my mails, org-attach my files and so on, but not integrate much more without all the modern integration issues of a an IT built to be isolated not integrated to sell programs before, services thereafter. However I see a very slow and long trend: the more current IT evolve the more it tend back to the IT pioneer era, in the "modern past" all was widget-based GUIs, not even Microsoft recommend CLIs for certain works, most apps have WebUIs witch are limited DocUIs but with the same doc concept, NotebookUI are more and more widespread, here and there someone recommend LaTeX instead of WYSIWYG word processor, someone else recommend R instead of spreadsheets and so on. Perhaps in 50 years we will have Smalltalk, Lisp and so on again, at least at concept/paradigm level.
- ElevenLathe 3y ago
  Smalltalk and Excel are both good to draw on. Another programming tradition that is actually very popular but seems to have limited influence on "professional" programming languages is Wolfram/Mathematica. The Wolfram Cloud product has some very interesting features in terms of exposing your Mathematica code as a service on the internet. Here's an interesting demo: https://www.youtube.com/watch?v=3VqlCm_T2CA https://www.youtube.com/watch?v=3VqlCm_T2CA. Mathematica also popularized the "notebook" style of dev which is also very nice for exploration.
lispm 3y ago
See the timeline of Interlisp https://interlisp.org/history/timeline/ https://interlisp.org/history/timeline/
- MarceColl 3y ago
  Someone yesterday commented exactly about interlisp in mastodon regarding this article and they already hit a lot of these goals 40 years ago. It was super interesting to read about it and very humbling abiut all the ideas early programmers tried and managed to make work. It was commented by ine of the people currently working in the interlisp medley project. I will be testing interlisp today actually after reading about it last night.
  - lispm 3y ago
    There is a lot to learn from it, but you would have difficulty right now to apply it to Common Lisp development. People are working on improvements, but for the most part we are beamed to the state of the art of 30+ years ago, which is impressive enough. If we stay on the Lisp side for a moment. Slighty different from Interlisp, then is Symbolics Genera. It's the OS and development environment of networked workstations for groups of Lisp programmers. The manual(s) has a chapter on the philosophy. I've put it online (the text is not by me, but from the manual): http://lispm.de/genera-concepts http://lispm.de/genera-concepts Then there is the idea to keep the developer "in the flow" while programming: http://lispm.de/symbolics-lisp-machine-ergonomics http://lispm.de/symbolics-lisp-machine-ergonomics Then there are the commercial environments, which have a similar development environment. Allegro CL and LispWorks. One marketing slogan there was: the cost of change to the software most only depends on the size of the change, not on the size of the software under development. Both have the advantage that they support application "delivery" on normal computers: Windows, Macs, UNIX, Linux, ... Nowadays I think the combination of SBCL, SLIME + GNU Emacs (for the IDE), version controlled source code sites (Gitlab: https://common-lisp.net/project-intro https://common-lisp.net/project-intro ) , test suites, etc. makes for a very powerful development environment for groups. For example the SBCL implementation is a sizable and complex Lisp project itself, which is managed very well by the maintainers. There is a good build process and people have been porting SBCL, which is an optimizing native code compiler, to new platforms without much problems. In the Lisp history there was always also the idea to apply exploratory development environments to other languages, improving on what various Lisp systems did. Example from the past, improving on Lucid CL: Energize, foundation for a C++ environment. https://dreamsongs.com/Files/Energize.pdf https://dreamsongs.com/Files/Energize.pdf The development UI was Lucid Emacs, Objectstore was the code database, they had an incremental linker/compiler for C++.

by kkfx 3y ago

MarceColl 3y ago

I've already tried pharo, my problem there is with the next step, making that production ready. I need tooling that allows explorative programming and that can be transitioned into production. If not it's just another source of rigidness, just later in the process

kkfx 3y ago
That's not much a Pharo or CL issue but a social issue: actual IT development, and for the last decades, have gone in a regressive path for commercial reasons and it's from enough from these systems and paradigms to have a nearly impossible to fill gap in between. Personally I live digitally in Emacs, so I have some tooling for the present word, mostly hidden under Emacs or *nix system, but yes, it's still limited, less then Pharo since I can read my mails, org-attach my files and so on, but not integrate much more without all the modern integration issues of a an IT built to be isolated not integrated to sell programs before, services thereafter. However I see a very slow and long trend: the more current IT evolve the more it tend back to the IT pioneer era, in the "modern past" all was widget-based GUIs, not even Microsoft recommend CLIs for certain works, most apps have WebUIs witch are limited DocUIs but with the same doc concept, NotebookUI are more and more widespread, here and there someone recommend LaTeX instead of WYSIWYG word processor, someone else recommend R instead of spreadsheets and so on. Perhaps in 50 years we will have Smalltalk, Lisp and so on again, at least at concept/paradigm level.
ElevenLathe 3y ago
Smalltalk and Excel are both good to draw on. Another programming tradition that is actually very popular but seems to have limited influence on "professional" programming languages is Wolfram/Mathematica. The Wolfram Cloud product has some very interesting features in terms of exposing your Mathematica code as a service on the internet. Here's an interesting demo: https://www.youtube.com/watch?v=3VqlCm_T2CA https://www.youtube.com/watch?v=3VqlCm_T2CA. Mathematica also popularized the "notebook" style of dev which is also very nice for exploration.

lispm 3y ago

See the timeline of Interlisp https://interlisp.org/history/timeline/ https://interlisp.org/history/timeline/

MarceColl 3y ago
Someone yesterday commented exactly about interlisp in mastodon regarding this article and they already hit a lot of these goals 40 years ago. It was super interesting to read about it and very humbling abiut all the ideas early programmers tried and managed to make work. It was commented by ine of the people currently working in the interlisp medley project. I will be testing interlisp today actually after reading about it last night.
- lispm 3y ago
  There is a lot to learn from it, but you would have difficulty right now to apply it to Common Lisp development. People are working on improvements, but for the most part we are beamed to the state of the art of 30+ years ago, which is impressive enough. If we stay on the Lisp side for a moment. Slighty different from Interlisp, then is Symbolics Genera. It's the OS and development environment of networked workstations for groups of Lisp programmers. The manual(s) has a chapter on the philosophy. I've put it online (the text is not by me, but from the manual): http://lispm.de/genera-concepts http://lispm.de/genera-concepts Then there is the idea to keep the developer "in the flow" while programming: http://lispm.de/symbolics-lisp-machine-ergonomics http://lispm.de/symbolics-lisp-machine-ergonomics Then there are the commercial environments, which have a similar development environment. Allegro CL and LispWorks. One marketing slogan there was: the cost of change to the software most only depends on the size of the change, not on the size of the software under development. Both have the advantage that they support application "delivery" on normal computers: Windows, Macs, UNIX, Linux, ... Nowadays I think the combination of SBCL, SLIME + GNU Emacs (for the IDE), version controlled source code sites (Gitlab: https://common-lisp.net/project-intro https://common-lisp.net/project-intro ) , test suites, etc. makes for a very powerful development environment for groups. For example the SBCL implementation is a sizable and complex Lisp project itself, which is managed very well by the maintainers. There is a good build process and people have been porting SBCL, which is an optimizing native code compiler, to new platforms without much problems. In the Lisp history there was always also the idea to apply exploratory development environments to other languages, improving on what various Lisp systems did. Example from the past, improving on Lucid CL: Energize, foundation for a C++ environment. https://dreamsongs.com/Files/Energize.pdf https://dreamsongs.com/Files/Energize.pdf The development UI was Lucid Emacs, Objectstore was the code database, they had an incremental linker/compiler for C++.