amno

That was an ambitious error recovery in Interlisp indeed. It took like 30 ~ 40 years to get similar thing in Emacs, and we still don't have the "trusted" mode, just cautious with flycheck & co.

> For display it removes the com and the hyphens.

In Emacs, packages are supposed to define a group node and a prefix for symbol names for Customize. Not all packages do, but most of quality ones do. We could actually use that prefix and implement similar strategy to display labels for menus and commands. Menus in Emacs are also implemented as keymaps, but they do require a programmer to specify a label for display in "easy menu" as they call their menu implementation. This strategy could thus remove the need for that extra label.

DWIM from Interlisp could be implemented in forms too. All forms have to use known symbols unless in some well-defined places: literals (strings, quoted symbols), the symbol name which is the word after the certain operator (defun, defmacro, defalias, etc), in argument lists, or as a first symbol of locally defining symbols (let, let*, flet, labels and similar). But there are some questions I am not sure how to answer: I think I will have to tell the system somehow that certain part of an expression is a "defining" part so it understands which symbols are to be introduced into the system and not checked or mistaken for misspelled.

It would be actually useful to have such feature, bound to space and return, so when we type it just replaces misspelled symbols. I am a master of misspellings, I often replace two characters place for some reason, like in Siebel as seen :).

Yeah, if you have $500M (half a billion of USD) to spend on marketing, like Sun Microsystems poured into Java, you must have some engineering merit behind you. Not necessarily in the thing you market.

> One doesn't need to use the menus, one can use the keyboard commands. The UI provides several ways to interact: key commands, interactive command line and menus. > Genera comes with a Scribe-based markup language and formatter.

You mean, the humanity has not gone too far away when it comes to computer-human interaction back from those days? :-). Just kidding; that sounds like they were quite modern back in 80's. I saw the other video on YT about their graphics software and hardware. While it looks relatively simple compared to modern image editors, modellers, fx and animation packages, it still feels like they had all the right ideas. What do you think put them out of the business? Just the economy or some other more technical reason?

> The new emulator for the Mac & Linux is many times faster and runs silent on something like a MacBook.

Yeah I saw another video, and saw "machdd" or something similar on the modeline somewhere, so I assumed you made it on a mac.

> lacks emulation of the console hardware (graphics hardware)

That explains why all the demos are black and white.

I don't have so much time to install and configure virtual machines and programs, but one beautiful day I'll try it, just for the curiosity; I have seen the repo on GH.

>> but I don't see much gain

> It looks better. Much better.

I think it is just preference.

I don't think it would be difficult to implement in Emacs, by just transforming the symbol name and presenting that to user instead. I think the read-extended-command-1 is the place where they actually do the work. They could also store a display string for each command in symbols plist as they do with interactive form, but it would be more surgery and as you say harder to use in the code. If display string is decoupled from the function name than the programmer has to remember as well the name for the command, but if they just do a transformation than the programmer can remember the rule. We are used to this in menus and gui stuff like that indeed, labels are often different strings than actual symbol names used for function callbacks, but I am not sure if we would prefer that on the command line.

In my opinion there is still discrepancy between the spoken language and the function names. I guess that is why people have come up with llamas and what not they call those AI llms and chatgpt and so on. I personally am not so fun of using spoken languages as a programming language or a way to control the computer, but who knows, perhaps one day M-x will run some llm search instead of precise lisp function names.

Yes, well that is basically what I meant. I guess in practice, those examples I made are contrived, so I suppose what they do is not a problem for the most people in practice, so I don't think it is a big argument against.

Well if you could sure; but you would still want to see what the app does I guess.

Without the source, you can't trust binary blobs. That was just a reflection why people want the source.

Cool video, interesting. Looks though like a very complicated way of creating and entering the content, compared to just typing in a buffer with some markup language. When I saw the video first I thought it was just textual hyperlinks, sort of what we with clickable text in Emacs. Info and help-mode are Emacs apps that uses it quite heavy. But then I looked up Concordia on Wikipedia, and I see it has same ancestor as texinfo :).

But very interesting to see, I'll watch your other videos when I have more time, it is a bit of history. Thanks for recording them and uploading videos. Is that machine still alive and running, or did you record it on your Linux port?

Because they used web technologies to put together the program?

> I don't see how that would help.

Perhaps with the source you could setup an offline server on your own computer so you don't have to upload your data anywhere?

> CL-USER> foo 1 > > CL-USER> foo 1 2 > > CL-USER> foo 1 (+ 1 2) (+ 3 4)

But then they do have the problem I mentions: they can't distinguish between calling (foo 1 (+ 1 2) (+ 3 4)) and calling (foo 1) (+ 1 2) (+ 3 4).

I don't think it is important ether, I certainly wouldn't type code like that in a repl either. I don't even know if sly/slime repl even support typing several expressions on the same line in repl. I am not at home to test it.

> Basically instead of hyphens it uses spaces. > > In LispWorks & Zmacs one enters the command M-x Replace String <return> and then the editor prompts for the arguments.

I understand, thanks.

I thought they were a bit more finicky about it. I think that could be relatively easily done in Emacs as well, but I don't see much gain to implement a M-x replacement like that. Especially with modern completion systems like Helm and fuzzy completing which basically don't care how we type.

Thank you for your time and answers.

Indeed; that is my objection to the loop and format in CL.

But on the pragmatic side, if you want to interop with shell, or some other language/runtime, isn't it sometimes easier and less typing and noise if a program can be expressed in DSL or as a mix of Lisp and a DSL than if everything is written in pure s-expressions?

Hah! Why am I not surprised to see that nick on HN too :-)

I have no experience with LispWorks whatsoever, but I am curious, how did they implemented it if you know? I mean, how do they differ between calling first as a value or first as a function? In your example first could be a defvared to have some value, and then I might have called a function to produce some unrelated output. I mean it is a contrived example, and probably nobody types in a repl like that, but the language does not forbid it since white spaces are insignificant.

If they just treat the first token as operator always, than they could call any function with any arguments:

    CL-USER> op arg1 arg2 ... argN

but then they would have to eval all values at the start of repl by calling (symbol-function arg), instead of just type arg to examine a value. I don't think it would be a bad think in itself tbh; but I am not sure the win is big enough to introduce a new concept.

By the way, I think I have stumbled on some mailing list comment somewhere once, where they said, that Hemlock can use commands named more "english like", i.e. they can have names with spaces in it, not just the hyphenated function name as in Emacs. Do you know more about it, or how they have implemented it? I am just curious; seen your comments on Reddit, and if you are the same person, I understand you are well experienced and familiar with various Lisps and implementations; hope you don't mind asking. :)

Eshell?

https://www.gnu.org/software/emacs/manual/html_mono/eshell.h...

It is not as trivial as you think, but it is possible. M-x in Emacs does it. But it is certainly not as simple as "just remove start and end parenthesis" :-). In a Lisp-2 if you type a symbol "foo" without parens, you are asking for symbol foos value as a variable, but it you type (foo) you are asking for symbol foos value as a function. Since every symbol in a Lisp-2 language (Common Lisp, Emacs Lisp some other possibly) can have both variable value and function object assign to it, how would system know which one you ask for?

Anyway, it is possible to do, for example M-x in Emacs does it. They do it by means of restricting repl to execute only functions, and they limit that to special function with so-called "interactive" form, whose job is to provide function arguments.

Indeed. However you can achieve things like that in an ordinary Lisp via unevaled (special) forms, with other words, macros. In Emacs Lisp eshell does it too, though they have extra advantage since Emacs has built-in text editor and text processing extensions. Eshell implements both Bash and Lisp syntax. I am not sure if "sharp lisp" does anything special for scripting than any other Lisp, but it is possible to do.

Elisp is actually exceptional for scripting :). You can also compile Emacs without graphics for even faster startup, check emacs-nox, and you can run it as a script: https://www.emacswiki.org/emacs/EmacsScripts.

What you get extra is a really good debugger (edebug), and text processing library extensions so you don't need to start extra processes (grep, awk, tr & co) just to extract some text from one output and send it to another.

They also have really, really good integration with system, almost on par with Bash. So despite Lisp being more verbose than a DSL like Bash script, you win tons by just having a debugger. Completion and Emacs auto-typing features (snippets, abbrevs, autoinsert etc) compensate for the verbosty.

As an Emacs addict, Emacs can do it all that babashak & ciel do, plus much more than so, like having a great stepper (edebug) and possibility to view the output while stepping through the code in a separate file buffer, as well as a server for long term processes, that can watch files and directories etc.

https://ftp.sunet.se/ for another oldie one.

OOP itself is not a misstake, but the way it is (usually) implemented probably is.

I thought Nix used as Guix Guile under the hoos, but looked up now, and they seem to use custom language, in which case is it even worse. I should have looked up that before the hand, my bad there, I appologize.

Op complained about that make requires a bunch of extra tools to get running, and suggests another bunch of extra tools, as well as of make DSL which is more or less shell on steroids, but suggests a mix of two different languages instead, and does not even seem to be aware he can use Guile Scheme to extend Make.

> That is not the argument though.

But it was; one of his arguments. Yes, he opens with the argument that he was unhappy with the Make for years, but he later clarifies why:

> I am still stuck with a tool that (according to Wikipedia) has been written 47 years ago.

You probably haven't read his article to the end? Those were his words I copy-pasted from the blog. So one of the reasons he is unhappy is because Make is 47 years old. For some reason, it stopped to be good enough 20 years ago, according to his opinion.

I can give him that we can always have a better tool, but it is a tautology. Unfortunately, his offered alternative is not better IMO.

Even in other medicine fields and academia.

For me it was new :)

I guess you have never programmed in Lisp?

> Should we force people to disable proximity sensors? After all you can drive without them but they make driving safer and easier for everyone.

I think your analogy is quite bad here. You ain't giving people proximity sensors or parking cameras or automatic parking. You are exchanging a good, comfortable vehicle we all know how to drive for a new type of vehicle with clearly worse ergonomics and forcing everyone to re-learn how to drive.

Once part of designing cars is that we can sit down in any car and just drive it. Perhaps we need to look up some minor and less important details, but we are guaranteed some very basic operation: how the blinking lights work, how to operate gas, brakes, steering wheel and manual transmission. I do think that they have messed up with short/long lights and back gears. That should have also been the same on all cars. But the basics are the same.

Makefile uses shell scripts for the recipes and shell variables, which makes Make an extension to the shell. There are differences, of course, but basics are very, very simple to get to learn. I learned 30+ years ago by just looking at other makefile and basically copying the details for my projects. I am still not even a very advanced makefile writer, I still lookup what automatic variables do, which one do I want and which functions I can use when I need them.

How is it different to learn Make from any other building tool like Gradle, Scons, Cmake, you name it?

Actually, basic is very simple, since the syntax is pretty much like the shell, or I mean, it is more or less shell scripts on steroids.

> But it still falls over if you put in a space versus a tab

It fails only in a certain part of the script where tab is part of the syntax. It is like saying Python language fails if I add a wrong number of spaces, or replace a space with a tab, since white spaces are part of the Python syntax.

> Even the fact makefiles have no extension is confusing

How is that confusing, the entire filename (makefile) is "the extension" :-)

Put .mk at the end of the file name if that makes you happy and less "outdated" and "idiosyncratic". C/C++ does not require extension either, it is just a convention. Ever seen <vector>, <algorithm>, <iostream> etc?

> we would just keep our browser windows at a smaller size

I wouldn't keep a browser at all, I would just read them in Emacs all the time or from the command line. I would also be able to use my preferred visual theme with the entire web, and not have to look at some really nasty web designs from time to time, albeit I do agree that as a game dev (long time ago) I do like when I see pretty graphic design.

However, I am not sure how my bank will do and all the other web services in just plain text. Perhaps it is possible, perhaps not?

Never heard of it before, but I am a bit curious about it being homoiconic. I wonder how it comes into play in Red/Rebol world, a little more thorough. This page shows some examples of lisp-like 'apply: https://www.red-lang.org/. I wonder if the use of '[] is inspired by pre-modern lisp M-expressions (Mathematica is also using them), or is it for some other reason, like let's pretend we are not a lisp-like language so to not scare of folks? :) Square brackets and curly brackets are unfortunately harder to type on some layouts. On Swedish layout I have to press alt-gr to type those, while ordinary parenthesis are a bit simpler: I can use shift, which is found on both sides of the keyboard.

Perhaps such things sounds trivial, but in a language where they claim that programming should be fun, hard to type things are a bit of fun-killers. I also disslike both visually and if I would to type all those operators #,%,$,?,:,! etc. We humans are used to raede txet adn cna prase text even when mistyped without barely stopping, but the punctuation is a bit harder to read and type, and that for a reason. That becomes especially annoying if those signs are overloaded or combined, as in Perl or C++, which is probably one of the reasons that gives those languages "write-only" epithet.

I have seen the video: https://www.youtube.com/watch?v=-KqNO_sDqm4 by Nenad, but it is from 2015. If they are still 4x slower than C for the compiled code, than I am very hard to believe they are a serious contender to become a systems programming language as they claim to be. Compare to sbcl (Common Lisp) where speed is almost approaching C in some cases. Having built-in toolchains and DSLs is nice, but it can also be a curse and made things harder to evolve and modernize.

While I sound like a very negative person, I do like some of the ideas in Red definitely. Built-in tasks, concurrency and homoiconicity sounds like a very nice features to start with.

Why do you think they haven't evolved? Latest versions give you access to Guile scheme as an extension language, not to mention that they extended over time for quite a bit. But it is all backwards compatible so old makefiles still run.