[HN Gopher] Why we need Lisp machines
___________________________________________________________________
Why we need Lisp machines
Author : otacust
Score : 166 points
Date : 2022-03-26 13:24 UTC (9 hours ago)
(HTM) web link (fultonsramblings.substack.com)
(TXT) w3m dump (fultonsramblings.substack.com)
| DonHopkins wrote:
| Reposting this from the 2014 HN discussion of "Ergonomics of the
| Symbolics Lisp Machine":
|
| https://news.ycombinator.com/item?id=7878679
|
| http://lispm.de/symbolics-lisp-machine-ergonomics
|
| https://news.ycombinator.com/item?id=7879364
|
| eudox on June 11, 2014
|
| Related: A huge collections of images showing Symbolics UI and
| the software written for it: http://lispm.de/symbolics-ui-
| examples/symbolics-ui-examples....
|
| agumonkey on June 11, 2014
|
| Nice, but I wouldn't confuse static images with the underlying
| semantic graph of live objects that's not visible in pictures.
|
| DonHopkins on June 14, 2014
|
| Precisely! When Lisp Machine programmer look at a screen dump,
| they see a lot more going on behind the scenes than meets the
| eye.
|
| I'll attempt to explain the deep implications of what the article
| said about "Everything on the screen is an object, mouse-
| sensitive and reusable":
|
| There's a legendary story about Gyro hacking away on a Lisp
| Machine, when he accidentally trashed the function cell of an
| important primitive like AREF (or something like that -- I can't
| remember the details -- do you, Scott? Or does Devon just make
| this stuff up? ;), and that totally crashed the operating system.
|
| It dumped him into a "cold load stream" where he could poke
| around at the memory image, so he clamored around the display
| list, a graph of live objects (currently in suspended animation)
| behind the windows on the screen, and found an instance where the
| original value of the function pointer had been printed out in
| hex (which of course was a numeric object that let you click up a
| menu to change its presentation, etc).
|
| He grabbed the value of the function pointer out of that numeric
| object, poked it back into the function cell where it belonged,
| pressed the "Please proceed, Governor" button, and was
| immediately back up and running where he left off before the
| crash, like nothing had ever happened!
|
| Here's another example of someone pulling themselves back up by
| their bootstraps without actually cold rebooting, thanks to the
| real time help of the networked Lisp Machine user community:
|
| ftp://ftp.ai.sri.com/pub/mailing-lists/slug/900531/msg00339.html
|
| Also eudox posted this link:
|
| Related: A huge collections of images showing Symbolics UI and
| the software written for it:
|
| http://lispm.de/symbolics-ui-examples/symbolics-ui-examples....
| ogogmad wrote:
| I've started using Mathematica recently. I quite like it: I've
| used Sympy before, which was good, but nowhere near as "good" as
| Mathematica. How does it compare to the Lisp Machine operating
| systems? There's some vague resemblance to Lisp in treating
| symbols as a basic type of object. In the Mathematica use-case,
| these symbolic values are used to stand for algebraic variables
| or unknowns. Undeclared variables by default have symbolic type,
| with their own names being their values. (I know that other CASes
| do similar things here). Also, algebraic manipulations produce
| expressions which double as Mathematica code, which resembles the
| meta-programming features of Lisp. There's even glimpses of
| reactive programming in the way you construct interactive plots.
|
| I know this is "uncouth" because it's commercial software, but
| Mathematica is one of the most interesting programs I've ever
| used. [edit] Might something like this be the future?
| PaulHoule wrote:
| What ramblings.
|
| Optane is the best performing SSD but the worst performing RAM
| you ever had. It is too expensive at any speed, even if Intel is
| losing money on it. HP memristors are vaporware.
|
| LISP machines, Java machines, and similar architectures
| specialized for complex language runtimes are a notorious dead
| end. They just can't keep up with performance-optimized RISC,
| pipelined, superscalar, SIMD, etc. architectures paired with
| compilers and runtimes that implement efficient abstractions
| (e.g. garbage collection, hotspot compilers) on top of those very
| fast primitives.
| zozbot234 wrote:
| The RISC-V folks are working on additions for special support
| of "complex language runtimes". Pipelined, SIMD and superscalar
| are all well and good, but what kills pure software-side
| support is always heavy branching and dispatching. These
| operations are genuinely much faster and more power-efficient
| when implemented in hardware.
| lispm wrote:
| Before Lisp Machines were killed in the market it was clear
| that new architectures were needed and a few were under
| development, even RISC like CPUs. They weren't released.
|
| But Lisp at that time was already fast enough on standard RISC
| chips (MIPS, SPARC, ALPHA, POWER, ...). Later the 64bit RISC
| chips also provided enough memory space. SPARC also had some
| tricks for Lisp implementors.
|
| Currently the assembler coded Ivory emulator is 80 times faster
| on Apple's M1 than the last Ivory hardware (the Ivory
| Microprocessor from Symbolics was released end 80s).
| DonHopkins wrote:
| How is the ARM not a "JavaScript Machine"?
|
| https://stackoverflow.com/questions/50966676/why-do-arm-chip...
|
| >Why do ARM chips have an instruction with Javascript in the
| name (FJCVTZS)?
|
| https://community.arm.com/arm-community-blogs/b/architecture...
| PaulHoule wrote:
| That instruction is a very small hack that uses just a few
| transistors to speed up a bit of data conversion that JS
| runtimes do frequently. That's a far cry from a specialized
| chip.
| imglorp wrote:
| Speed is relevant for some use cases, sure, but not at all for
| a ton of others. Memory, disk and CPU are almost free in this
| new world, so why are we computing like it's 1990 still? It's
| time for some different abstractions than file -> process ->
| file.
|
| The vast productivity gains of Smalltalk and Lisp were because
| they discarded those abstractions and programmers were free for
| others.
|
| Presumably OP posted this after noticing Phantom came up a few
| days ago. https://news.ycombinator.com/item?id=30807668
| bigbillheck wrote:
| > Memory, disk and CPU are almost free in this new world, so
| why are we computing like it's 1990 still?
|
| Elsewhere on this very site you'll find no ends of complaints
| about, say, Electron apps.
| [deleted]
| VLM wrote:
| The problem with language wars is the people whom cannot be
| trusted with pointers, also cannot be trusted with lambdas or
| recursion.
|
| The name of the game has always been to avoid directly insulting
| the bad programmers by making fun of the languages they use. Bad
| programmers have clustered in several languages over the course
| of my long career. Mostly they are the easiest most expressive
| languages, which would superficially seem to be an advantage,
| however they make it easy to express amazingly bad ideas. The
| harder to express languages require more work to express a bad
| idea thus somewhat filtering them out of that language's pool.
|
| People whom don't understand the game think the game will be won
| if the bad programmers would have access to better languages for
| the first time in history. Despite the idea being decades old its
| always presented as a new idea.
|
| There's an authoritarian streak where if only we could remove
| access to the inferior languages then they'd have to use the
| better languages and we'd have better code. However you can't
| force people to not use inferior tools and you can't force them
| to learn to use better tools.
|
| The graph of easy to write and code goodness is interesting and
| nonlinear. You can express very complicated ideas in lisp easier
| than in vb6 or perl or interpreted basic or spaghetti fortran.
| However, you can express very bad ideas easier in a "bad"
| language, so it accumulates interesting authors. There is always
| a crossover point where an intermediate complexity idea is
| equally hard to express in a simple language or a complex
| language. Frankly most of IT needs are and always will be below
| that point. So its counterproductive to demand difficult language
| for simple tasks, everyone laughs at "Enterprise Java Hello
| World" that is 100K lines of enterprise patterns.
|
| Expressing ideas in computer languages is much like expressing
| ideas in everyday language. Some esoteric philosophy texts
| require a VERY large precise complicated hard to use and hard to
| learn vocabulary. Road signs do not. For in between jobs, trying
| to use a minimum number of language vocabulary words and lexical
| complexity would be wise. It would be a fools errand to try to
| cut half the vocab words from street signs to "make driving
| safer", or an equally bad idea to force all road signs to be
| expressed as Shakespearean sonnets. The real world counterpart of
| "Enterprise Java Hello World" would be forcing the "No U Turn"
| street sign to be in the form of a Shakespearean sonnet.
|
| The difficulty of tasks is usually under a power law, so its nice
| that we have lisp, but usually a bad idea to use lisp.
| snek_case wrote:
| You could do some powerful things with LISP machines but I think
| the underlying assumption is that everything is written in LISP,
| or compiles to LISP (or its underlying bytecode). That places
| restrictions on what you can do. For example, does it do high-
| performance multithreading and SIMD right?
|
| Also not sure LISP machines solved security as well as modern-day
| Linux does. I think it was just less of a concern back then,
| because you knew most of the people who were on the network.
| pjmlp wrote:
| The answer for that question lies with Connection Machine and
| Star-Lisp.
|
| https://en.m.wikipedia.org/wiki/Connection_Machine
| mark_l_watson wrote:
| I used to start writing Star-Lisp code for my company's
| Connection Machine (version 1, the SIMD one) by using Coral
| Common Lisp on my little Macintosh. Then I would get on an
| airplane and fly to the city where out CM was installed.
| h2odragon wrote:
| Part of the hype and hope of the "OLPC" laptops was that it would
| generate a "Python machine" userland, if not entire OS.
| mumblemumble wrote:
| > With lisp machines, we can cut out the complicated multi-
| language, multi library mess from the stack
|
| This seems like the kind of goal that's only palatable to a very
| few people nowadays. Specifically, the people who want to use
| that language, toolchain, and libraries, _and nothing else._
|
| These days, I don't think that that's ever going to allow for
| enough of a community to support more than a relatively self-
| contained hobbyist scene. Which there's absolutely nothing wrong
| with that; personally I wish there were more compelling
| tinkering-oriented platforms; I'm a little meh on Unix too. But
| the article seems to be advocating rather loftier ambitions.
| peter303 wrote:
| Hardware LISP machines didnt survive the 1980s because you could
| emulate LISP on a general purpose CPU faster than a special
| machine. That is because faster new general purpose CPUs cane out
| every year or so, while it took 3-5 years for the next special
| purpose CPU.
| throw10920 wrote:
| I think that, while the idea is solid (Unix is poorly-designed
| and we should have better) some of the specific ideas mentioned
| are lacking:
|
| > Everything worked in a single address space, programs could
| talk to each other in ways operating systems of today couldn't
| dream of.
|
| No! Bad! We have enough problems securing software on _separate
| VMs running on the same metal_ , single address spaces are
| completely out of the question until someone manages to build a
| feasible trusted compiler system.
|
| > Then we add a gazillion programming languages, VMs, Containers,
| and a million other things, UNIX is a bloated mess of workaround
| for its own problems.
|
| A lot of these problems could happen with a Lisp machine - you
| could have a billion different Lisps, for instance (although, to
| be fair, with better (i.e. non-Unix) OS design you wouldn't need
| containers).
|
| > With lisp machines, we can cut out the complicated multi-
| language, multi library mess from the stack, eliminate memory
| leaks and questions of type safety, binary exploits, and millions
| of lines of sheer complexity that clog up modern computers.
|
| This is partially true, but a _lot_ of the complexity in modern
| software doesn 't come from Unix, but just...bad design
| decisions. Webtech doesn't really care whether it's running on
| Windows or Unix, after all.
|
| Also, high-level CPUs are a bad idea: http://yosefk.com/blog/the-
| high-level-cpu-challenge.html
|
| I think the good in this post is along the lines of: text bad,
| typed IPC good, runtime-aware OS good, standardized VMs good,
| interactive systems (Lispy stuff, Jupyter) > batch-processing
| systems (Unix, C).
| mark_l_watson wrote:
| I don't really agree. I had a Xerox 1108 Lisp Machine in the
| 1980s and loved it, but special purpose Lisp hardware seems like
| a waste of effort. I set up an emulator for the 1108 last
| weekend, and yes, I really did enjoy the memories, and things ran
| an order of magnitude faster than on the 1108 in the 1980s.
|
| Then, I appreciated my M1 MacBook Pro running SBCL, LispWorks,
| Haskell, Clojure, and various Scheme languages - all with nice
| Emacs based dev setups. Life is really good on modern hardware.
| mst wrote:
| I feel like a lot of posts like this are pining for the
| complete lisp machine -user environment- and overestimating how
| necessary/important the hardware architecture would be to
| getting back to that today.
|
| I can manage to context switch between different lisps fine but
| I do sometimes wonder in e.g. a slime+SBCL setup how much that
| context switching is costing me.
| lispm wrote:
| The 1108 wasn't really special purpose Lisp hardware. One could
| run other operating systems on it. What made it special purpose
| was the loaded microcode for the CPU.
|
| > Life is really good on modern hardware.
|
| Agreed: On modern CPUs.
|
| More support for the additional hardware features like GPUs,
| media processing engines and the neural network engines (see
| the M1 Pro/Max/Ultra) would be welcome.
| mark_l_watson wrote:
| The best bet for getting GPU deep learning support, I use
| Anaconda/conda, using the Apple M1 channel. That said, I
| usually use my Linux GPU rig or Colab for deep learning.
| maydup-nem wrote:
| > genera
|
| eh, if it's gui is anything like clim which was based off of it,
| no thank you big time
| amelius wrote:
| The main problem with Unix right now is security / permission
| control. Unix was built from the perspective that users
| potentially don't trust each other, but users all magically trust
| the applications that are run. In the age of the internet, this
| doesn't hold anymore, and we need strong permission control.
| shaunxcode wrote:
| The JVM is my lisp machine.
| rst wrote:
| Some of this needs checking -- you could not run Unix on
| Symbolics hardware. LMI did have machines that ran both OSes --
| but Unix was running on a separate 68000 processor; see, e.g.
| http://www.bitsavers.org/pdf/lmi/LMI_lambdaOverview_1982.pdf
|
| (3600-series Symbolics machines also had a 68k "front end
| processor", but no Unix port was provided for it; they also
| ultimately had a C compiler that could generate code for the
| "Lisp processor", but the code it generated was intended to run
| in the Lisp environment.)
|
| It's also worth noting that systems-level code for Symbolics
| machines (and, I presume, LMI as well) made frequent use of
| "unsafe subprimitives", misuse of which could easily crash the
| machine. And, unfortunately, if you needed to, say, get anything
| close to hardware bandwidth out of the disk drives, some of this
| became well-nigh unavoidable, due to poor performance of the OS-
| level file system (LMFS).
| lispm wrote:
| What one could do was running hardware Lisp Machines from
| Symbolics on VME boards inside a SUN: the UX400 and UX1200.
|
| Later Open Genera was sold as a Virtual Lisp Machine running on
| a DEC Alpha / UNIX system.
| pbohun wrote:
| If were talking about wild dreams, I would like to see a modern
| Plan9-like operating system written in lisp.
|
| While the Plan9 mouse chording is cool (and could be kept), I
| would have everything also accessible via keyboard commands. 3
| button mouse chording on a laptop trackpad is not fun.
| pjmlp wrote:
| It used Limbo and was called Inferno.
| mananaysiempre wrote:
| Executable-images-and-bytestreams (Research Unix, Plan 9) and
| everything-is-in-$LANGUAGE (Lisp machines, Emacs, Smalltalk,
| Oberon, Forth) environments seem largely contradictory to me,
| because much of the flexibility in Unix seems to come from the
| freedom to ignore as much structure in the data as you want to,
| while programming-language environments seem to derive their
| advantages from expressing the structure in as detailed a way
| as possible. (In particular, they really want to invent their
| own storage formats for everything.) I don't have much of an
| idea about Inferno, but my superficial impression is it also
| mostly ends up as a single-language island.
|
| Which is annoying, because both of these approaches produce
| some really attractive results, so I'd very much like to learn
| about any attempts to reconcile them.
| zozbot234 wrote:
| "Expressing structure" is just a higher layer on simple
| bytestreams. Some historical operating systems only supported
| special-cased "file types" with hard-coded structure, but the
| *IX folks found out that the simple bytestream is enough.
| mportela wrote:
| For a somewhat complete history of LISP machines, I recommend
| reading "Hackers: Heroes of the Computer Revolution" [1].
|
| [1] https://www.goodreads.com/book/show/8260364-hackers
| scruple wrote:
| Thanks for the recommendation.
|
| I've been learning/using CL, on the side, for about a year, in
| fits and starts, and I'm also picking up a lot of it's history
| and evolution along the way.
|
| I find the history of the thing is as fascinating as the
| language/tools.
|
| There's so much written on this but it's hard to aggregate and
| put together. Links lead to other links that lead to other
| links and oftentimes a lot of them are dead.
|
| So I'm glad that there are books like this that can preserve
| some pieces of the story.
| mikewarot wrote:
| The key thing about those type of systems was the ability to
| reach down into the system and edit the code of the system
| currently in operation.
|
| Here's a demonstration of Symbolics Open Genera (TM) 2.0,
| demonstrated running in a virtual machine. It is noted by the
| author of the video in the first minute or so that even in
| emulation, it is much faster than the original machines. -
| https://www.youtube.com/watch?v=o4-YnLpLgtk
|
| Oberon also had a similar attribute, in that they kept the names
| of functions to operate on objects visible.
|
| The same was true of the Canon Cat, Hypercard, Ted Nelson's
| Xanadu project, Smalltalk, and a number of other early computing
| systems.
|
| The main feature common to all of these systems is that they all
| _preserve context_. In Genera, Oberon, Canon Cat, Hypercard, and
| SmallTalk the source was always available. (as far as I know). In
| Xanadu, the main functionality of the web was present, but it
| wouldn 't allow the broken links (and lost context) that now
| plague the web.
|
| I think a future platform could take code in a number of
| languages, compile it to an abstract syntax tree, but preserve
| the context required to recreate the source. In fact, it's
| reasonable that you could import a routine in a language you
| aren't familiar with, and reverse the compilation to get it
| expressed in an equivalent (but less elegant) form in your
| language of choice, along with the original comments.
|
| There's nothing stopping an open source project from taking
| elements of these existing systems and moving forward from that
| basis. It might be profitable to include ideas such as Coloring
| of the Source text to label intent, such as in ColorForth.
|
| Also, consider "Literate Programming" - Literate programs are
| written as an uninterrupted exposition of logic in an ordinary
| human language, much like the text of an essay, in which macros
| are included to hide abstractions and traditional source code.
|
| You could also add the ability to store graphics and other data
| along with the source code.
|
| Of course, if you are required to run code you didn't write and
| don't trust, your operating system _must provide_ means to run it
| only against the files or folders you wish to let it operate on.
| The principle of least privilege needs to be supported at a
| fundamental level. This is one of the big shortcomings of the
| Unix model.
|
| Sorry it was a bit of a ramble, but this seemed to be a call for
| ideas, so I ran with it.
|
| PS: In the past, getting your vision of Computing required
| building a machine, and then getting it manufactured. Now it just
| requires that you make it work in a VM, Raspberry Pi, or web
| browser window.
|
| It is MUCH easier to try out and/or create alterative systems now
| that it has ever been in the past.
| jodrellblank wrote:
| Why would you reach down into the system and edit the code of
| the system currently in operation? Because it doesn't already
| do what you want. Isn't it a bit pathalogical to start by
| building a system which _doesn 't do what you want_, then
| building in the tools to let you fix it, so you can use those
| make it do what you want? Why not skip all the middlemen and
| make what you want in the first place?
|
| If you arrive at "we can't do that because everyone wants
| different things", you're in this weird place where you can't
| build one system to suit everybody so as a fix for that you
| will ... make one dev system to suit everybody? Why is that
| going to work out any better? If people are going to have to
| build the system they want anyway, why not skip all the
| middlemen and leave people to build the system they want from
| scratch their own way?
|
| "Well we can't do that, having to build everything from scratch
| is hard, people don't want that. And we don't know what people
| want (and can't be bothered to ask) and won't try to build it
| for them, but we can give everyone Our Blessed System and Our
| Blessed Tooling which we presume they will want to use, while
| we abandon them to have to build what they actually want using
| it". It's patriarchal and preachy and still unhelpful. The kind
| of person willing to put up with your system and language and
| its edge-cases and limitations instead of making their own, is
| quite likely the same person who would have put up with your
| spreadsheet and its edge-cases and limitations if only you'd
| built it.
|
| It's the "all progress depends on the unreasonable person"
| meme; you need the person who can't tolerate a system which
| isn't perfect and demands to be able to tune it to their
| perfection, but is simultaneously fine with a customizable-
| system built by someone else for someone else's ideas. Then you
| say "ah but they can rebuild as much of the system as they
| want!" they're now having to build it themselves from scratch
| but based on what you built, which is even more work for them,
| not less.
|
| And the whole thing says little about working with other
| people/organizations; everyone building their own thing isn't
| great for that. One could argue that Microsoft did a lot of
| good for the world by strongarming companies into .doc and .xls
| formats for interchange, in a similar way that HTTP/HTML did
| (but more tyrannically). Microsoft-Word-documents-over-email
| should probably go down in history as one of the big enablers
| of distributed human organization, like the telephone. Moreso
| than SMTP alone or TCP/IP alone which enabled computers to
| connect, not people. More than HTTP/HTML which ordinary people
| can't use without setting up a webserver and publishing first.
|
| > " _I think a future platform could take code in a number of
| languages, compile it to an abstract syntax tree, but preserve
| the context required to recreate the source. In fact, it 's
| reasonable that you could import a routine in a language you
| aren't familiar with, and reverse the compilation to get it
| expressed in an equivalent (but less elegant) form in your
| language of choice, along with the original comments._"
|
| Would that even work? What about "code is primarily for people
| to read"; loss of indentation, of alignment, of variable names
| if you're changing language with different variable naming
| rules, loss of separate files/folder/module-context of how it
| was built in the first place, and loss of idiomatic patterns
| from changing one language to another, or to languages with
| different scoping behaviour. Look at the image in The Article
| for the square root code[1], can you decompile the syntax tree
| for a language which doesn't have a complex number type? What
| about one which doesn't have a short-float for the result, or
| has different floating point precision assumptions? What does
| "F and I2 need to be regular-heap-consed to avoid the extra-pdl
| lossage" mean for JavaScript or Python or Clojure? What's the
| magic 0.4826004 for, without any comments next to it?
|
| And that square root function alone is a screenful of code, the
| very idea of being able to rebuild the system to your desires
| falls out the window if it's going to take you a lifetime to do
| that, and if not then we're back to my original paragraph where
| you're building a massive programmable system so someone can
| tweak one or two tiny things occasionally, which seems hella
| overkill.
|
| > " _Of course, if you are required to run code you didn 't
| write and don't trust, your operating system must provide means
| to run it only against the files or folders you wish to let it
| operate on. The principle of least privilege needs to be
| supported at a fundamental level. This is one of the big
| shortcomings of the Unix model._"
|
| The XKCD comment that malicious code can ransomware all my
| documents and upload them to the cloud, but at least it can't
| add a new printer. One of the big shortcomings of the principle
| of least privilege is the effort of carefully and precisely
| describing the privileges needed - see the complexity and
| quantity of SELinux rules for a whole system. Even then you get
| immediately to the point where "my editor can edit all my text
| files" and that's now a large blast radius.
|
| [1]
| https://cdn.substack.com/image/fetch/w_1456,c_limit,f_auto,q...
| mikewarot wrote:
| >One of the big shortcomings of the principle of least
| privilege is the effort of carefully and precisely describing
| the privileges needed - see the complexity and quantity of
| SELinux rules for a whole system.
|
| SELinux was a terrible thing to inflict upon the world.
| Capabilities are more like cash in your wallet.... you pick
| what you want to use in a transaction, and hand it over...
| never worrying that the rest of your money would somehow get
| siphoned off later.
|
| Static rules aren't what capabilities are about. Run this
| program, oh.. it wants a file? Here... it can have this. The
| default access would be nothing (or in a more modern context,
| it's config file) The program wouldn't directly access files,
| but would use dialog boxes to do I/O, or you could drop them
| in via batch, etc.
| pjmlp wrote:
| You can get a bit of that Oberon experience on Windows via
| PowerShell, .NET and COM.
|
| Now if Windows team would get over their COM worship, it would
| be even better.
| abecedarius wrote:
| If I'd like to try the emulated Lisp Machine linked to
| (https://tumbleweed.nu/lm-3/), is there a straightforward
| getting-started doc? The page lists multiple links for each of
| the simulator, the bootstrap, the documentation, and umbrella
| projects ("to make it easier setting up", though for this one
| it's only a binary choice). This is not counting the multiple
| system sources, since only one is recommended right now.
|
| This suggests it's too much work for now if you're just curious,
| but it'd be great to be wrong.
| fferen wrote:
| I have had the same thoughts before and come to a similar
| conclusion. I believe it's not about the language. It's about the
| features: runtime code editing, single address space, program
| interoperability. Lisp could be replaced with C or anything else.
| Unfortunately this is the hard part. No one is about to design
| completely new hardware or architecture for this, as it makes no
| economic sense. So we just get a shiny new language every few
| years, and nothing really changes.
| klodolph wrote:
| I agree that we need more operating systems, but...
|
| > These machines used specialized hardware and microcode to
| optimize for the lisp environments (Because of microcode you
| could run UNIX and the Lisp OS at the same time).
|
| This is a dead end in the history of CPU design.
|
| Processors are all vaguely similar these days. Your CPU is built
| around ALUs which typically take one or two inputs, produce one
| output. Around that, you build some logic for shuttling these
| inputs and outputs to and from registers, or in some cases, to
| and from memory.
|
| The core here, the ALUs, have gotten more and more sophisticated
| over the years, but the wiring on the outside has remained fairly
| modest relative to its excesses back in the day. I'd say that the
| lesson here is simple: rather than add complicated operations to
| make your high-level language faster, do the complicated stuff in
| software... which gives you a lot more flexibility, and the
| combined hardware-software stack ends up being faster and cheaper
| anyway.
|
| > With lisp machines, we can cut out the complicated multi-
| language, multi library mess from the stack, eliminate memory
| leaks and questions of type safety, binary exploits, and millions
| of lines of sheer complexity that clog up modern computers.
|
| I can understand where this notion is coming from... but
| practically speaking, switching to Lisp doesn't eliminate memory
| leaks or questions of type safety or binary exploits. Even with
| an idealized version of Lisp, I don't think these problems could
| possibly go away. Neither garbage collection nor systems like
| Rust really "solve" memory leaks, they just provide strategies to
| make memory leaks less common.
|
| The same thing applies to type safety. You'd have to define "type
| safety" very narrowly to say that Lisp solves all type safety
| problems. Again, I can understand where the author comes from--
| it's kind of an intuitive notion of type safety, that you don't
| end up operating on an incorrectly typed pointer, or something
| like that. But the notion of type safety is much more broad than
| that these days.
|
| And the C/Unix strategy is actually pretty good, too, when it
| works--contain memory leaks within a process, then terminate the
| process.
| mportela wrote:
| This post would benefit from further expanding some of these
| statements.
|
| > UNIX isn't good enough anymore and it's getting worse
|
| Why exactly?
|
| > A new operating system means we can explore new ideas in new
| ways.
|
| LISP machines were not only OSes but also hardware. Is the author
| also proposing running this OS on optimized hardware or simply
| using our x86-64/AMD/M1 CPUs?
|
| > With lisp machines, we can cut out the complicated multi-
| language, multi library mess from the stack, eliminate memory
| leaks and questions of type safety, binary exploits, and millions
| of lines of sheer complexity that clog up modern computers.
|
| Sure, but it also requires rewriting a lot of these things,
| introducing and fixing new bugs... It feels like the good ol'
| "let's rewrite this program" that quite frequently doesn't live
| up to the expectations [1].
|
| [1] https://vibratingmelon.com/2011/06/10/why-you-should-
| almost-...
| traverseda wrote:
| >> UNIX isn't good enough anymore and it's getting worse
|
| >Why exactly?
|
| Personally? We're in a bit of a transition point, and a lot of
| the technologies aren't working together like they used to.
|
| An example, on my laptop I want to run android apps. The way to
| do this that actually works well (waydroid) only supports
| wayland. Unfortunately I use x2x to control another display
| remotely, and x2x doesn't work properly under wayland, and
| never will due to wayland's security choices.
|
| So like, what am I supposed to do here? Not run android apps?
| Not use tools like barrier/synergy/x2x?
|
| This is one of many many frustrations I've had from this new
| generation of wayland/systemd/etc. Hopefully it gets better
| eventually but it does feel a lot like the rug is constantly
| being pulled out from under me for no good reason...
|
| Now I don't think a lisp machine is going to fix that mind you,
| but it is a concern.
| sseagull wrote:
| I am finding that everything is just becoming more and more
| fragmented. Programming languages, ecosystems, frameworks,
| blah.
|
| I have had ideas for some applications, but can't do them
| because the libraries I need are written in different
| languages, which don't interoperate well (and one I am not
| familiar in).
|
| Every post here looking for recommendations has many
| responses with different packages/ecosystems doing the same
| thing.
|
| Sometimes I feel like there are too many developers and not
| enough of them really interested in the actual hard problems.
| So they just make another python package manager or webapp
| framework.
| pjmlp wrote:
| It isn't nice? Back to the 8 and 16 bit home computers,
| when we had plenty of choice and real fights on the school
| playground about which were better.
| eternityforest wrote:
| I think they are too invested im hard problems, but not
| invested enough in tedious problems.
|
| I don't want a new language, or a new preprocesser, or a
| new way of thinking about programs... I just want a one
| click way to take a folder of HTML that looks like a static
| site, and package it up into cross platform apps with all
| the proper API access.
|
| I don't care about cryptocurrency and global decentralized
| databases, I just want to be able to run a site by buying a
| NAS appliances, putting files on it, and sharing the QR
| code on it without any signups and cloud accounts.
|
| The hard problems are mostly solved. There's probably some
| long dead random github repo that does anything you want.
| They're just not packaged for all platforms and maintained
| professionally.
|
| I don't need a phone without any binary blobs at all... I
| just want a mesh network feature and a fair trade stamp.
|
| Because... it sucks to maintain something novel even if
| it's all just pieced together from npm. It sucks to be the
| one responding to issues. It sucks to actually run a
| project and keep track of devops stuff.
|
| All the tech has been invented dozens of times over, but
| never polished, and always ruined with some unnecessary
| immutable log feature or performance destroying random
| access low latency routing thing like IPFS has.
| TheOtherHobbes wrote:
| There's a gap between developer culture and the giant
| corporate bureaucracies.
|
| The former is focussed on tinkering, nostalgia, tool-
| building, wheel reinventions, and half-finished build-
| and-forget spare time projects.
|
| The latter has successfully applied high-friction
| chokeholds around startup culture which makes the cost of
| entry for new business ideas far higher than it really
| needs to be.
|
| There is almost no blue sky development equivalent to the
| original Internet, the Mother of All Demos, and the
| desktop computing model - and associated projects -
| created at PARC in the 70s and early 80s.
|
| It's all very "mature", incremental, slow, and me-too.
|
| And so expensive, both financially and in terms of
| developer time.
|
| I'd love to see a renewed interest in attacking this from
| both ends - a movement to really push the imaginative
| limits of what's possible, while also being implacably
| humane and user-oriented and indifferent to ad tech,
| tinker tech, and pre-commercialised cloud tech.
| eternityforest wrote:
| The giant bureaucracies are doing some pretty amazing
| innovation. Look at Google's web platform features,
| Bluetooth LE, etc.
|
| There's just certain things they can't do because their
| incentive is stuff you constantly pay for all the time.
|
| I'd love to be part of something like old 90s
| revolutionary software.
|
| But I've noticed close to zero interest from the dev
| community in anything like that.
|
| Everyone mostly just wants to play with sorting
| algorithms or write their own small language, unless
| they're getting paid a whole lot. It's become a sport
| more than an engineering discipline.
|
| It's hard to imagine Excel or BitTorrent being written
| now.
|
| Heck, it's hard to even imagine web browsers with
| JavaScript being written now.
|
| What kind of projects would you like to see/work on?
| pnathan wrote:
| a revolutionary project moving forward would be a quality
| gopher browser with a gopher extension for forms, along
| with a gopherd.
|
| the basic problem is fragmentation and assembling a
| community of interest.
| eternityforest wrote:
| Wouldn't gopher just be more fragmentation? What can it
| do that can't already be done on top of web? It's still
| pretty much just client/server.
| zozbot234 wrote:
| "New business ideas" are really easy. VC-style
| hypergrowth towards unicorn status is what's hard, but
| make no mistake it's _always_ been very hard. Unicorns
| are rare, by definition.
| tacitusarc wrote:
| This is why I like Golang. I think it's the first time in
| my professional experience where if I see a package that
| hasn't been updated in 3 years, that doesn't mean it's
| abandoned, it means it's stable.
| christophilus wrote:
| Clojure is like that. I love it.
| pnathan wrote:
| common lisp is like that.
| PaulDavisThe1st wrote:
| So a perfect use-case for the obligatory XKCD post about
| "too many standards, invent one more to try to solve the
| issue => too many standards plus one".
| onlyrealcuzzo wrote:
| I don't think standards are the problem.
|
| I think a wave of new standards causes issues like the
| above, and eventually this gets worked out.
|
| Not all "standards" in practice become standard. We learn
| a lot of "standards" were bad ideas, and they eventually
| get tossed out and most people forget anyone was ever
| trying to make that a thing.
| PaulDavisThe1st wrote:
| "Standards" in this case just means "things that I/we
| developed that we think should be adopted by lots of
| other people because it's awesome-sauce"
| tacitusarc wrote:
| I'm curious what you would classify as a hard problem.
| Personally, I think writing a good, easy to use Python
| package manager that both gains adoption and addresses the
| myriad of corner cases is a hard problem.
| sseagull wrote:
| I work in scientific software. I tend to view really hard
| problems as problems where you don't know the solution,
| and don't even have a blueprint for how could be solved.
|
| Writing a package manager is hard in some sense, but you
| have an idea of what it needs to do, what features it
| should have, and what success ultimately looks like.
|
| But there are problems, large and small, which require
| new thinking and leaps of faith. There are people working
| on these, of course, but sometimes I feel they are being
| neglected.
|
| (and people working on those problems probably make
| 10-25% of what many FANG developers make...)
| zozbot234 wrote:
| You can actually start a Wayland compositor/session in a X
| window. That plus existing solutions for Wayland network
| transparency should be enough.
| traverseda wrote:
| That's what I'm doing now, but it's a pretty bad user
| experience and definitely isn't seamless. Also completely
| breaks any integration with my app menu meaning I have to
| rewrite all the desktop files to launch the app in cage. I
| imagine someone will eventually make a seamless wayland
| compositor for x though.
|
| >That plus existing solutions for Wayland network
| transparency should be enough.
|
| If you're saying it will fix my x2x use case, well it
| won't. Wayland's security model fundamentally prevents this
| use case. Maybe someone will add extensions to it
| eventually but right now the way compositors handle mouse
| capture seriously prevents this use case, and I'm skeptical
| that all the different compositors will agree on a solution
| any time in the next 10 years...
|
| So I'm stuck using X on both displays for the foreseeable
| future if I want to use x2x/synergy like functionality, and
| I'm certain that it's going to become harder and harder to
| keep using X over time...
| 20after4 wrote:
| Wow and here I was hopeful that Wayland would actually
| make this kind of thing easier. I'm a big fan of synergy
| and all it's descendant. Apple just released a similar
| feature for iOS and OSX. Really surprised this is getting
| more difficult on Linux instead of easier.
| DonHopkins wrote:
| There's a old book all about just that, which included and
| popularized Richard P. Gabriel's paper, "The Rise of Worse Is
| Better":
|
| https://en.wikipedia.org/wiki/The_UNIX-HATERS_Handbook
|
| https://web.mit.edu/~simsong/www/ugh.pdf
|
| >The year was 1987, and Michael Travers, a graduate student at
| the MIT Media Laboratory, was taking his first steps into the
| future. For years Travers had written large and beautiful
| programs at the console of his Symbolics Lisp Machine
| (affectionately known as a LispM), one of two stateof-the-art
| AI workstations at the Lab. But it was all coming to an end. In
| the interest of cost and efficiency, the Media Lab had decided
| to purge its LispMs. If Travers wanted to continue doing
| research at MIT, he discovered, he would have to use the Lab's
| VAX mainframe.
|
| >The VAX ran Unix.
|
| >MIT has a long tradition of mailing lists devoted to
| particular operating systems. These are lists for systems
| hackers, such as ITS-LOVERS, which was organized for
| programmers and users of the MIT Artificial Intelligence
| Laboratory's Incompatible Timesharing System. These lists are
| for experts, for people who can--and have--written their own
| operating systems. Michael Travers decided to create a new
| list. He called it UNIXHATERS: Date: Thu, 1
| Oct 87 13:13:41 EDT From: Michael Travers <mt>
| To: UNIX-HATERS Subject: Welcome to UNIX-HATERS
| In the tradition of TWENEX-HATERS, a mailing list for surly
| folk who have difficulty accepting the latest in
| operating system technology. If you are not in fact a
| Unix hater, let me know and I'll remove you. Please add
| other people you think need emotional outlets for their
| frustration.
|
| https://www.amazon.com/UNIX-Haters-Handbook-UNIX-Haters-line...
|
| https://www.goodreads.com/en/book/show/174904.The_UNIX_Hater...
|
| https://wiki.c2.com/?TheUnixHatersHandbook
|
| >I'm a UnixLover, but I love this book because I thought it was
| hysterically funny. Many of the war stories are similar to
| experiences I've had myself, even if they're often flawed as a
| critique of Unix itself for one reason or another. But other
| UnixLovers I've loaned the book to found it annoying rather
| than funny, so YMMV.
|
| >BTW the core group of contributors to this book were more
| Symbolics Lisp Machine fans than ITS or Windows fans. ITS had
| certain technical features superior to Unix, such as PCLSRing
| as mentioned in WorseIsBetter, but having used it a bit myself,
| I can't see that ITS was superior to Unix across the board. The
| Lisp Machine on the other hand, although I never used it, was
| by all accounts a very sophisticated environment for
| programmers. -- DougMerritt
|
| https://news.ycombinator.com/item?id=13781815
|
| https://news.ycombinator.com/item?id=19416485
|
| >mtraven on March 18, 2019 | next [-]
|
| >I founded the mailing list the book was based on. These days I
| say, Unix went from being the worst operating system available,
| to being the best operating system available, without getting
| appreciably better. (which may not be entirely accurate, but
| don't flame me).
|
| >And still miss my Lisp Machine. It's not that Unix is really
| that bad, it's that it has a certain model of computer use
| which has crowded out the more ambitious visions which were
| still alive in the 70s and 80s.
|
| >Much as the web (the Unix of hypertext) crowded out the more
| ambitious visions of what computational media for intellectual
| work could be (see the work of Doug Engelbart and Ted Nelson).
| That's a bigger tragedy IMO. Unix, eh, it's good enough, but
| the shittiness of the web makes humanity stupider than we
| should be, at a time when we can ill afford it.
|
| https://medium.com/@donhopkins/the-x-windows-disaster-128d39...
| kkfx wrote:
| >> UNIX isn't good enough anymore and it's getting worse
|
| > Why exactly?
|
| Beside the defects well stated in the Unix Hater's Handbook,
| unix violate it's own principles since many years. Original
| unix idea was: desktops like Xerox SmallTalk workstations are
| too expensive and complex for most needs, so instead of a real
| revolution of an extraordinary outcome we decide to limit
| ourselves to most common needs in exchange of far less costs.
| No GUIs, no touchscreen, no videoconferencing and screen
| sharing [1] just a good enough CLI with a "user language"
| (shell scripts) for small potatoes automation and a bit of IPCs
| for more... Well... For more there is a "system language" (C)
| that's easy enough for most really complex task.
|
| That was a success because no one really like revolutions and
| long terms goals especially if they demand big money while many
| like quick & done improvements at little price.
|
| However in few years unix start to feel the need of something
| more than a CLI and some GUIs start to appear, unfortunately
| differently than original Xerox&co desktops those UIs were not
| "part of the system, fully integrated in it" but just hackish
| additions with so interoperability, just single apps who have
| at maximum cut&paste ability.
|
| > Sure, but it also requires rewriting a lot of these things,
| introducing and fixing new bugs... It feels like the good ol'
| "let's rewrite this program" that quite frequently doesn't live
| up to the expectations
|
| We need desktops again, witch means not just "endpoints" or
| "modern dumb terminals of modern mainframes named cloud", but
| desktop computing, since desktop development is essentially
| abandoned since many years and even back then was in a bad
| shape we need to restart from the classic desktops. LispM was
| ancient, hackish, but are still the best desktop we have had in
| human history so a good starting point. We have some kind of
| LispM OS/OE here: Emacs, still alive and kicking so there is
| something to work with, that's is. Emacs is already a WM (EXWM)
| have countless features and it's already "plugged" in modern
| bootloader OSes to have hw, driver and services. It just need
| to evolve.
|
| [1] yes, you are reading correctly and no, I'm not wrong, I'm
| talking about the famous NLS "Mother of all the Demos" from
| 1968 https://youtu.be/yJDv-zdhzMY
| tytrdev wrote:
| I agree, especially with the statement that Unix isn't good
| enough and getting worse.
|
| I feel like that was one of the core assumptions and point of
| the article, but it didn't have any explanation beyond
| "multiple programming languages." Feels a bit flat to me.
| pmoriarty wrote:
| > > UNIX isn't good enough anymore and it's getting worse
|
| > Why exactly?
|
| Two reasons:
|
| 1 - systemd (which is moving linux towards becoming a systemd
| OS)
|
| 2 - developers and companies moving ever more towards web apps
| (which will eventually make the underlying OS irrelevant, as
| the browser becomes the OS) (incidentally, web assembly seems
| to herald the end of the open/transparent web too, as we're
| eventually all be running opaque binary blobs on our web
| browsers)
| amelius wrote:
| > 1 - systemd (which is moving linux towards becoming a
| systemd OS)
|
| Or, a microservices OS.
| pjmlp wrote:
| Xerox PARC workstations could run Interlisp-D, Smalltalk,
| Mesa/XDE, Mesa/Cedar, thanks to this little thing RISC failed
| to kill, microcoded CPUs.
| ogogmad wrote:
| When the author talks about too many languages and libraries, I
| personally think he means the proliferation of Unix DSLs (some of
| which are Posix and some are not) like Make, Awk, Sed, BC, DC,
| shell-script dialects, Gnuplot (I know it's not Posix but it was
| widely used once), xargs, Vimscript, ELisp. Each of these has its
| own quirks and random limitations. Each of these makes Unix
| unnecessarily complicated and difficult to learn, and they don't
| even accomplish much that's impressive. I also think they make
| the editing experience worse, because they prevent the use of
| IDEs or highly featured REPLs like the ones general-purpose
| languages have.
|
| I imagine that a lot of this can be replaced with libraries for a
| general-purpose language like Python. In the case of Awk, BC and
| DC, Python's standard library does everything these do without
| their strange quirks. Gnuplot can be replaced with umpteen
| plotting libraries like Matplotlib. Shell-scripting can be done
| in a Python dialect like Xonsh. I don't know of a Python
| alternative to Make, but Make is a fairly perverse and ad-hoc
| language that looks ripe for being replaced by a library.
|
| I don't think a new operating system (however you define that) is
| necessary. I think you just swap out a lot of the crazy DSLs with
| one consistent general-purpose language. People will switch over
| when they want to accomplish things more easily (like me!). This
| is especially likely if you're not a SWE but you want to do file
| system automation anyway. The DSL-heavy approach is too Byzantine
| for such people (like me!). And it's mostly possible today.
| eternityforest wrote:
| I wouldn't even say any of those make UNIX difficult to learn.
| 99% of people can be users and developers just fine without
| learning awk or sed or even make, if they don't do low level
| work.
|
| It can all be incrementally replaced over time, without
| starting over, just like how systemd and pipewire didn't need
| to totally start over.
|
| Make will probably need something more than just a library
| though, because it's gotta stay declarative. But the fact that
| make exists at all is kind of an issue. I think build and
| package management should be done in the language itself like
| non-C languages do.
|
| The other use of make is almost as a pseudo UI, just a standard
| place to put a list of actions you can do.
|
| Something like Ansible could replace that, in theory, or we
| could have some new "project control center" file with menus
| and inputs and settings.
| [deleted]
| eternityforest wrote:
| UNIX is fine. UNIX philosophy is an issue, along with C, and the
| fact that everything now is mobile and web based and the tools
| aren't well suited to offline/nonSaaS stuff yet.
|
| Linux is slowly becoming a standardized, integrated platform. I
| don't see why it can't be evolved to have all the main advantages
| of a LISP machine.
|
| I also don't see how that solves dependency management. No matter
| what, if you build against something and it changes, stuff
| breaks. That's the main issue with Linux.
|
| It also doesn't solve microservices being kinda hard and needing
| manual configuration specifically for the setup, rather than the
| one size fits all style of monolithic desktop software. That's an
| application architecture challenge.
|
| Nor does it solve cross-platform.
|
| Linux does have problems and could learn from LISP
| machines(Although I'd rather we have TypeScript machines or
| Python or something, LISP is pretty far from what I want a
| language to be, and is meant for creativity and expressiveness
| rather than Ada-like safety and boring hacker-repelling Java-like
| standardization).
|
| But a lot of issues go away if you pretend everything other than
| Debian and Red Hat don't exist.
| agumonkey wrote:
| From a semi shallow position, what annoys me with linux is the
| lack of genericity above the "file" abstraction (which is not
| even real enough).
|
| I remember seeing GNU ls code, 30% argparse, 30% formatting..,
| all of this seems brittle and redundant.
|
| Bazaar is fine to allow freeform innovative evolution but it's
| also too messy.
| eternityforest wrote:
| Linux has a lot going on above the file level, it's just not
| in the kernel.
|
| Most people using Linux also have DBus and Pulse/Pipewire
| going, and a ton of other stuff.
|
| Network devices are technically files, but in practice they
| are names. I have no idea what them being a file even means
| at the byte level. They're just names that you deal with
| through NetworkManager's DBus API, if you're not targeting
| any of the minimal or embedded distros.
| taeric wrote:
| This feels like an odd critique. I would expect that more
| programs should devote more code to the parts that interact
| with a user. That is, the size alone isn't much of a signal.
| Is it?
| agumonkey wrote:
| The formatting is redundant and should be able
| externalized. The argparse also deals with the output
| formatting, hence redundant. Only file spec selection is
| core to LS.
| taeric wrote:
| Redundancy isn't, by itself, a problem. In the case of
| core utilities, it affords them a level of stability that
| is just not even attempted in many areas.
| jodrellblank wrote:
| In the sense of the PowerShell engine doing the argument
| parsing and display formatting for all cmdlets, which is
| something I think the designers took from VMS shell. That
| makes for "Don't Repeat Yourself" (one place for all the
| argument parsing code) and from the user experience side
| all commands which subscribe to this take parameters in the
| same way, arguments handled in the same way, with the same
| common parameters, and support parameter introspection and
| tab completion, etc. so it can be a more uniform
| experience.
|
| (Not always great though; I don't know VMS shell but
| PowerShell cmdlets can still have similar tools taking
| different parameter names for the same concept, or not
| working implementing what to do with common parameters, or
| taking DSLs in strings like WMI Query Language, or taking
| rather opaque and unique hashtable blobs).
| agumonkey wrote:
| I didn't mention it but powershell was in my mind.
| powershell format-table in particular. Also there's some
| guys who are patching linux user space to embed json as
| output (and the jc wrapper to be able to leverage jq
| later down the pipe)
| pjmlp wrote:
| UNIX and UNIX philosophy are one and the same, there is no way
| around it with some kind of word games.
|
| C was created to make UNIX, originally written in straight
| Assembly, portable. A process finalized by UNIX V6 release.
|
| UNIX philosophy grew out of Bell Labs into all universities and
| business that took those source tapes, and took it from there.
|
| Hardly possible to be selective of what UNIX is all about.
| eternityforest wrote:
| Modern Linux is so far from old school UNIX though. They are
| even talking about using Rust!
|
| It's evolved so much, and the remaining unixy bits get more
| and more supressed and hidden.
|
| BSD still has more of it, but Linux seems to be moving on and
| is very far from the days of everyone piecing together
| software from small parts.
| pjmlp wrote:
| Linux became a kernel for the GNU project, whose founders
| were raised in ITS and MIT AI Laboratory, and the original
| planned kernel for the project doesn't have anything
| related to UNIX.
|
| Most projects using the Linux kernel nowadays care more
| about having a free beer kernel than anything UNIX related.
|
| BSD has always been a proper UNIX, hence AT&T lawsuit when
| they were finally allowed to monetize on UNIX.
| reikonomusha wrote:
| I'm as big of a Lisp fan as can be. I'm a proud owner of
| Symbolics and TI hardware: a MicroExplorer, a MacIvory, two 3650,
| and two 3620. Not to mention an AlphaServer running OpenGenera.
|
| Today, we have computers that run Lisp orders of magnitude faster
| than any of those Lisp machines. And we have about 3-4 orders of
| magnitude more memory with 64-bits of integer and floating point
| goodness. And Lisp is touted to have remained one of the most
| powerful programming languages (I think it's true, but don't read
| into it too much).
|
| Yet, it appears the median and mean Lisp programmer is producing
| Yet Another (TM) test framework, anaphoric macro library, utility
| library, syntactic quirk, or half-baked binding library to
| scratch an itch. Our Lisp programming environments are less than
| what they were in the 80s because everybody feels the current
| situation with SLIME and Emacs is good enough.
|
| We don't "need" Lisp machines. We "need" Lisp software. What made
| a Lisp machines extraordinary wasn't the hardware, it was the
| software. Nothing today is impeding one from writing such
| software, except time, energy, interest, willpower, and/or money.
|
| Don't get me wrong, there are some Lisp programmers today
| developing superlative libraries and applications [1], but the
| Lisp population is thin on them. I'd guess that the number of
| publicly known, interesting (by some metric), and _maintained_
| applications or libraries that have sprung up in the past decade
| probably fits on one side of a 3 "x5" index card. [2]
|
| Though I won't accuse the article's author of such, sometimes, I
| find, in a strange way, that pining for the Lisp machines of yore
| is actually a sort of mental gymnastic to absolve one for not
| having written anything interesting in Lisp, and to excuse one
| from ever being able to do so.
|
| [1] Just to cherry-pick a recent example, _Kandria_ is a neat
| platformer developed entirely in Common Lisp by an indie game
| studio, with a demo shipping on Steam:
| https://store.steampowered.com/app/1261430/Kandria/
|
| [2] This doesn't mean there aren't enough foundational libraries,
| or "batteries", in Lisp. Though imperfect, this is by and large
| not an issue in 2022.
| zozbot234 wrote:
| > We don't "need" Lisp machines. We "need" Lisp software. What
| made a Lisp machines extraordinary wasn't the hardware, it was
| the software. Nothing today is impeding one from writing such
| software, except time, energy, willpower, and/or money.
|
| Discussed here https://news.ycombinator.com/item?id=30800520
| The main issue is that Lisp, for all its inherent "power", has
| very limited tools for enforcing modularity boundaries in code
| and "programming in the large". So everything ends up being a
| bespoke solo-programmer project, there is no real shared
| development. You can see the modern GC-based/"managed"
| languages, perhaps most notably with Java, as Lisps that
| avoided this significant pitfall. This might explain much of
| their ongoing success.
| throw10920 wrote:
| > The main issue is that Lisp, for all its inherent "power",
| has very limited tools for enforcing modularity boundaries in
| code and "programming in the large"
|
| I don't see any mention of "modular" or "boundaries" in the
| post you linked, so I'm assuming that it doesn't add extra
| context to your point.
|
| You say "very limited tools for _enforcing_ modularity
| boundaries ", which I'm going to assume means that you
| believe that Lisps have constructs for _creating_ modularity
| boundaries (e.g. unexported symbols in Common Lisp), and just
| don 't enforce them (e.g. I can still use an unexported
| symbol in CL by writing foo::bar), in which case - I don't
| think that this is actually an issue.
|
| Programmers are capable of doing all _kinds_ of bad things
| with their code, and shooting themselves in the foot, yet I
| 've never seen an indication that the ability to shoot
| yourself in the foot with a language noticeably contributes
| to its popularity (see: C, C++, Perl, Ruby).
|
| Moreover, specializing to Common Lisp, it's not like CL
| allows you to _accidentally_ access an unexported symbol in a
| package - you have to either deliberately use :: (which is
| bad style, and takes more effort than typing :) or you get a
| hard crash. This is opposed to the above listed languages,
| which allow you to shoot yourself in the foot in a large
| number of extremely diverse and interesting manners, often
| without giving you advance warning - and yet are still far
| more successful.
|
| ------------
|
| I don't believe that the lack of success of Lisps are due to
| technical deficiencies.
| johnny22 wrote:
| What do you think it is?
| syngrog66 wrote:
| agreed, and well said
|
| in broadstrokes, imo, Lisp's endless plasticity of infinitely
| nested parentheses is both its greatest strength and... its
| greatest weakness
|
| I love it at Write time. hate it at Read/Maintain time. why
| I've avoided it for serious work. Python, Java, Go Rust etc
| are all easier for my brain & eyes to quickly parse on the
| screen
|
| which is unfortunate. because I still drool at Lisp's
| linguistic power
| reikonomusha wrote:
| Lisp at "read/maintain" time in a good environment is
| probably the most enjoyable time for me working with Lisp,
| assuming it's on a code base that followed some sort of
| coding standards. Introspection, debugging, and navigation
| in a Lisp environment are incredible.
| lanstin wrote:
| Still the average function written by a smart lisp
| programmer is going to make me sigh, take three deep
| breathes, and set aside some time to focus, while the
| average function by a smart Go programmer, I can just
| read.
|
| This readability loss does counteract the ability to
| reload forms into a running core. Especially now when i
| am trying so hard to make everything running be immutable
| and derived from various git repos.
| lispm wrote:
| Already in the 80s the Lisp Machine OS had > 1 MLOC code
| lines with support for programming in the large. The
| development environment was networked from the start. A
| server keeps the definition of things on the network:
| machines, users, file systems, networks, gateways, printers,
| databases, mailers, ... The source code and documentation is
| usually shared in the team and versioned via a common file
| server.
|
| Nowadays, there are large applications written by
| groups/teams, which are worked on for three or more decades.
| For example the ACL2 theorem prover has its roots in the 70s
| and is used/maintained until today for users in the chip
| industry.
|
| Common Lisp was especially designed for the development and
| production use of complex programs. The military at that time
| wanted to have a single Lisp dialect for those - often
| applications came with their own Lisp, which made deployment
| difficult. A standard language for projects was then
| required.
|
| These were usually developed by teams in the range of 5 - 100
| people. Larger teams are rare.
| zozbot234 wrote:
| "Designed for complex programs in the 1980s" is not really
| up to current standards. Moore's law means that complexity
| of overall systems can grow by multiple orders of magnitude
| in the 01980 -to- 02022 timeframe.
| lispm wrote:
| That was not the point. Lisp applications were already a
| team sport back then. That all or even most Lisp software
| is written by single person teams is just wrong.
| zozbot234 wrote:
| Modern agile development is far more complex than even
| that: you need entire loosely-coupled _teams_ of
| developers to be able to seamlessly cooperate with one
| another, so there are multiple scales of cooperation.
| Tightening the semantics of interface boundaries is a
| necessary support for that kind of development and is
| what 's largely meant today by programming "in the
| large". Highly dynamic "scripting" languages get in the
| way of this, and that's essentially what Lisp is too.
| lispm wrote:
| Lisp isn't essentially a scripting language. Common Lisp
| was designed as an application language, in rare case
| it's also a systems language. On a Lisp Machine, for
| example the whole networking stack was written in it.
| reikonomusha wrote:
| I think many people have conjectures, such as this one, but I
| don't think it's a tech problem, or a "Lisp is too powerful
| for its own good" problem. It's a "people aren't writing
| software" problem. History has demonstrated umpteen times
| that developing large, sophisticated, maintained, and
| maintainable projects in Lisp is entirely and demonstrably
| possible. Modern Common Lisp coding practices gravitate
| toward modular, reusable libraries through proper modules via
| ASDF packages ("systems") and Common Lisp namespaces
| ("packages").
| SulphurCrested wrote:
| The obvious answer as to why people aren't writing software
| is that almost all of the people able to write good
| software don't like the language and are writing software
| in some other language or for some other platform.
|
| I know Lisp enough to have written programs of a few
| thousand lines in it. I'm not even slightly fazed by
| functional programming and (tail-)recursion instead of
| loops. I've read Steele's Common Lisp book from cover to
| cover. Someone even tried to get me to interview for a job
| writing Lisp (I politely told them I thought their system
| could not practically be implemented in Lisp and was,
| several years and tens of millions of dollars later,
| eventually proven right).
|
| And I don't think the language has any redeeming features
| other than garbage collection and documentation, neither of
| which is notable in 2022. I'm someone familiar with the
| language who could quickly become productive in any decent
| Lisp, and that's what I think of Lisp. Can you imagine what
| a person new to the forest of parentheses, weird
| identifiers and rejection of 500 years of operator
| precedence notation thinks?
| drekipus wrote:
| > I politely told them I thought their system could not
| practically be implemented in Lisp.
|
| I'm curious to what that was, it sounds like a challenge
| more than anything.
|
| I'm off a younger generation of programmers, and I've
| recently found lisp after coming from python. I still
| adore python and I can understand python's success, but I
| also adore lisp and its syntax, and I feel like I get the
| "powerful" argument for it.
|
| For me, for what it's worth, I think the difficulties for
| lisp to join mainstream is really the thousands of little
| differences and gotchas that there's no single standard
| body looking after the users of the language. Princ
| instead of print, mapcars everywhere, etc. Trivial
| examples sure, but there's a lot that prevented me from
| making a few programs without doing through a book.
|
| I'm not saying it's wrong, or it should be such and such
| a way. I am just simply comparing it to python and
| pointing to the first big elephant I come across.
|
| Fwiw I also think that clojure is a lang that is capable
| of capturing more love because it's capable of tying in
| with Java ecosystem.. but it java is old and slow*; jobs
| in Java are slowing down, and clojure isn't filling in
| the gap, kotlin might be.
|
| I take common lisp with me to holidays, because I like to
| learn it and all the funny words for things, but by far
| the lisp I use the most in day to day stuff is fennel,
| which is a lisp that compiles to Lua, and allows me to
| write plugins for neovim as well as a few other things
| that uses Lua.
|
| TLDR: yes lisp needs software to be popular but it's not
| just a case of "make more applications" nor is the
| problem parents or operator precedence. People like
| sensibly named keywords.
|
| I personally think things would be a little better if
| there was a CL to JavaScript transpilier, then you'd
| start to get some of the js crowd, same with python.
| coryrc wrote:
| > people aren't writing software
|
| Maybe not OSS, but somebody is keeping Lispworks and Franz
| in business.
| copperx wrote:
| I'd love to know who. The example apps in Lispworks site
| aren't commercial successes, as far as I know.
| [deleted]
| metroholografix wrote:
| The greatness of Lisp -at least when it comes to end-user
| empowerment- and (I think) the only differentiating factor that
| most other languages have still not caught up to, is the
| cybernetic philosophy with its roots in Licklider (man-computer
| symbiosis) and Engelbart.
|
| Building an environment that strongly and uncompromisingly
| expresses this philosophy at its core is a serious undertaking
| in terms of time investment. Emacs has been in continuous
| development for 37 years and while it is still not as good as
| Genera, it's certainly "good enough" for lots of people and
| definitely captures the spark of this philosophy.
|
| In the Common Lisp world, we've had plenty of tries (MCL,
| Hemlock, McCLIM) but they've all failed to get people to
| coalesce and generate progresss.
|
| Maybe the fact that Emacs exists is a curse in that people
| realize the barrier they'll have to clear to make something
| substantially better and decide to devote their energies into
| more easily realizable efforts.
| lonjil wrote:
| > Yet, it appears the median and mean Lisp programmer is
| producing Yet Another (TM) test framework, anaphoric macro
| library, utility library, syntactic quirk, or half-baked
| binding library to scratch an itch. Our Lisp programming
| environments are less than what they were in the 80s because
| everybody feels the current situation with SLIME and Emacs is
| good enough.
|
| I don't think this is true. Not anywhere close. Most such
| examples are small, and probably only took a small number of
| hours to produce. While "superlative" stuff takes very many man
| hours to create. So just by seeing that there are many
| throwaway testing frameworks or whatever, you cannot tell where
| most of the work hours actually go. A half baked binding
| library takes 20 minutes to make, while a proper high quality
| rendering engine takes hundreds if not thousands of hours.
|
| The Lisp population is thin on people making cool shit because
| the Lisp population in general is thin.
| 13415 wrote:
| Personally, I think the problem is that CommonLisp is just
| another programming language, whereas Lisp really shines when
| it provides a full-fledged programming environment. Nowadays,
| it would seem best to create such an environment on top of
| commodity hardware as a "virtual machine" that abstracts away
| from the hardware in a general, portable way. However, a good
| environment (1) needs a purpose, and (2) somebody needs to
| write it. Lisp currently fails on both points. The purpose used
| to be symbolic AI and NLP among other things. Nowadays it could
| be the same, or a web framework with integrated distributed
| computing and database, or scientific computing, or a server
| for certain business services, etc. There are many application
| domains for which a virtual "Lisp machine" would be beneficial
| but it needs to be developed for one of those real world
| applications, not just as a toy like existing attempts of
| building Lisp machines. And in my opinion the problem really is
| (2), developer power / size of the community. If you exclude
| super-expensive legacy Lisps, the current Lisp community
| doesn't even have a fully supported Lisp-native editor
| (portable Hemlock is not good enough) and also doesn't have
| good enough object persistence / native Lisp-based databases.
| Both are the foundations of any integrated Lisp machine.
|
| People sometimes claim CL+Emacs+Slime provides the full
| interactive experience. I just can't agree with that at all. I
| have tried, and the experience was not substantially different
| from Go development and development in any other fast-compiling
| language with Emacs. In some respects, it's even worse than
| with various modern languages, even though most of those
| languages are strictly inferior to CL from a pure language
| perspective. If editing files in Emacs is all there is to the
| allegedly great Lisp experience, and developers at the same
| time have to deal with all those idiosyncrasies of CL such as
| CL's filesystem path handling, ASDF, and tons of poorly
| documented libraries, then I can't really see the advantages of
| CL. The language is powerful, don't get me wrong, but a truly
| interactive experience is totally different. Smalltalk managed
| to keep this experience but for some reason the Lisp community
| seems too have lost this vision. I guess the developer
| community is just not large enough.
|
| Anyway, before someone tries to build another "close to metal"
| Lisp machine or tries to revive any old Lisp machine, I'd
| rather wish the community would focus on creating truly
| integrated development environments that abstract away from the
| host system and are fully hackable and editable from the ground
| up while maintaining security and multi-user access. A "virtual
| Lisp" machine with virtual OS, so to say. If that's developed
| for a certain purpose like building and deploying extremely
| portable web applications, I believe it can have a great
| future.
|
| Sorry for the long rant. This is just my impression after
| having programmed in various Lisp dialects for the past three
| decades.
| thorondor83 wrote:
| To me development with SLIME is much better than with a fast-
| compiling language.
|
| - Debugger is always ON.
|
| - I can inspect the data I'm working with.
|
| - I can redefine things without starting everything all over,
| avoid losing current context. Fast restart is not the same.
|
| - I can evaluate pieces of code without the need of a REPL.
| Point to an s-expression and evaluate that piece of code,
| inspect the result.
|
| I don't see how Smalltalk is much more interactive. It is
| more powerful at graphics and tools integration, but SLIME
| provides an interactive enough experience IMO, and it is
| significantly better to any fast compiling + restart
| language.
| coryrc wrote:
| > the experience was not substantially different from Go
|
| I think the (a?) reason for that is a (otherwise good) shift
| to production being immutable. When you aren't allowed to
| interact and change code in a running system, you lose a
| massive advantage of CL over simpler languages. When the
| answer to every error is "send a 4xx or 5xx to the client"
| then having a powerful error-handling system is similarly
| pointless. When you only write CRUD programs like everyone
| else, you're just plugging together other's libraries and not
| creating novel techniques or fancy math. In this world all
| CL's advantages are negated.
| metroholografix wrote:
| Common Lisp on Emacs via SLIME is not competitive with
| Smalltalk, re: "interactive experience" since Emacs is not
| the native substrate of CL, but essentially an out-of-process
| experience. If you want to experience CL at its best, you
| need to run Symbolics Genera.
|
| Emacs with Emacs Lisp on the other hand offers a great
| interactive experience that also manages to easily surpass
| every modern Smalltalk incarnation in practicality and size
| of development community. So if running Genera isn't easily
| doable, this will give you a taste of what Lisp interactivity
| is all about.
| jodrellblank wrote:
| > " _We don 't "need" Lisp machines. We "need" Lisp software._"
|
| Nobody goes into Java because their self identity is "a Java
| programmer" to gather a team of people to create a Java machine
| running Java software to unleash the power of Java for the
| masses by enabling them to do everything in Java for the sake
| of doing everything in Java, By Java, With Java, For Java. And
| if they do talk like that they would be a Sun Microsystems
| marketing pamphlet from 1999, or a joking reference to
| Zombo.com, or suspected of having zero interesting ideas and
| defaulting to Ouroboros-naval-gazing.
|
| Adobe Photoshop Lightroom is C++ and Lua. Blender is C++ and
| Python. Excel is C++ and Visual Basic for Applications.
| LibreOffice Calc is C++ and Python. These are large, popular,
| programmable systems which exist today and are good enough;
| good enough for people to spend lots of money on them, good
| enough for people to spend years skilling up in them, good
| enough that once they existed people wanted them to keep
| existing and they haven't faded into the past.
|
| The added allure of an imaginary rebuild of them like "if you
| took the lid off Excel you'd see VBA inside so you could rework
| the way it handles multiple sheets using only a skill you have
| and software design skills and Excel-internals knowledge you
| don't have" would get a hearty side-eye and slowly backing away
| from most Excel users. "Everything inside looks the same" is as
| attractive as "if you open your car trunk you'll see leather
| seats and plastic dashboard components making it move" or "if
| you sit in this car you're sitting on engine parts because the
| top priority is that a welder in a scrapyard can build the
| entire car without leaving their comfort zone". There are
| certainly people who want that, but the way the world hasn't
| developed that way suggests it isn't particularly desirable.
| Even when such things have been built, people can today use a
| Smalltalk, an APL, save their running work in a memory-dump and
| reload it and rewrite parts of it in itself, people flocked to
| Jupyter notebooks instead.
|
| > " _[1] Kandria is a neat platformer developed entirely in
| Common Lisp_ "
|
| https://cdn.akamai.steamstatic.com/steam/apps/1261430/ss_a3f...
|
| Without mocking a team who has built, developed, polished and
| planned to release a project, because that is respectable, it
| also looks like computer gaming of the early to mid 1990s Intel
| 386/486 era; remeniscent of Prince of Persia, Gods, Lemmings,
| Monkey Island. But it needs an Intel i5, 4GB RAM and 1GB
| storage. It's not even released yet and has no reviews, but you
| describe it as 'superlative' ("Of the highest order, quality,
| or degree; surpassing or superior to all others") - are you
| rating it so highly based on it being written in Lisp or what?
| p_l wrote:
| Regarding Kandria:
|
| You might have heard of this thing called "Art", and that it
| has styles, and that not only one of them is called "pixel
| art" for celebrating that kind of limitations, Art as a whole
| is often talked in terms of self-imposed limits used in
| creation of a work.
|
| That said, a game can deliberately target such style, and yet
| hide considerable richness of implementation (consider:
| Noita, Dwarf Fortress).
|
| Another thing with Shinmera and his team is that they produce
| both interesting stories, interesting games, but also code
| I'd argue is art too.
| reikonomusha wrote:
| I don't know how to respond to the whole "Lisp programmer
| identity" stuff; it doesn't seem relevant to anything I said.
| I also didn't suggest anybody rewrite anything in it. The
| success of Lisp doesn't depend on the existence of fancy
| machines, it depends on people choosing to write software in
| it. That's basically all I meant to say.
|
| As for Kandria, did you play the demo, or did you just look
| at screenshots and system requirements and make your brazen
| judgment? I don't think Kandria is at all amateur or sloppy,
| regardless of to which aesthetic era you think it belongs.
| Many have claimed that it's not even possible to write a game
| that doesn't blow because Lisp is dynamically typed and
| garbage collected. Now the goalposts have moved to, "well, it
| takes 1GB of memory and doesn't even look like it's from
| 2022."
|
| I commend anybody who ships.
| agumonkey wrote:
| I'd say it's both. It seems most lisping is done high on the
| stack. Some are doing assembler level lisp (or scheme) but less
| bare metal / OS / system oriented lisp.
|
| I wonder what the lisp os guy are thinking about OS / UI these
| days.
| GregorMendel wrote:
| Anyone interested in the computing holes that can be filled by
| lisp machines should check out Urbit. There is an vibrant and
| growing community of people building a network of personal
| servers running a lisp-like functional OS. It uses an identity
| system secured by the Ethereum blockchain and it has created a
| bottom up economic incentive for developers to participate.
| They are starting to solve unique problems that couldn't be
| addressed on currently prevalent platforms. Urbit is an
| affirmation; we can ditch the nihilism.
| Gollapalli wrote:
| And it's 4x more expensive than it was supposed to be to buy
| a planet.
|
| Ethereum was a mistake.
| TacoT wrote:
| It's $3. www.azimuth.shop
| olah_1 wrote:
| Since they moved to Layer 2 it has been amazing. No eth
| fees anymore.
|
| They should just move to their own chain entirely. Maybe
| this is a baby step towards that. Each Galaxy/Star is
| already basically a staker in a Proof of Stake network.
| convolvatron wrote:
| i associate lisp machines with power, simplicity, and a
| delightfully shallow learning curve.
|
| urbit to me is exactly the opposite
| scroot wrote:
| Leaving the specific idea of the Lisp Machine aside, today there
| we have a tremendous advantage over the past when it comes to
| creating the kind of full, self-consistent systems Lisp Machines
| -- and systems like Smalltalk or Oberon, etc -- represent. Today
| we have widely accepted communications and data format standards.
| This is something that really isolated system diversity in the
| past, where you were "stuck" in some given computing system and
| had little ways of interacting with other types of computing
| systems. We have figured all of that out.
|
| We should hope to see a flourishing of new and diverse systems
| again, since now all one need to do to interact with everyone
| else is merely (and I know it's a slog) implement tried and true
| standards.
| lispm wrote:
| One can implement these standards. Problem: it's work.
|
| They supported things like TCP/IP, UDP, SMTP, X11, RPC, NFS,
| DNS, HTTP, ... The machines had C compilers, too.
| scroot wrote:
| Some of these new systems should definitely be lisp machines
| of a kind, though not direct clones of Genera. We need
| something more "of the times." In reality, there are only a
| few things people expect of their computing systems, but
| those things are huge: decent graphics and components for the
| UI, and a web browser.
|
| So, yeah, standards and protocols are there. And it would
| take a s*t-ton of work to implement them in a bespoke
| environment. But they are not "difficult" in the classic
| sense. If we had a completely different type of economy it
| might even be possible!
| karmakaze wrote:
| The trend seems to be toward statically-typed languages, with the
| exception of the adoption of Python being used for data. I also
| prefer having more problems being found before deploying and
| running on production data.
|
| Dynamic typing is great for prototyping, early development, and
| for small teams. If your definition of success is greater than
| that I would choose differently, or port at a good time early on.
|
| And if someone were to ask me to join a company using lisp, I
| would hope that it's Clojure, though arguably not a Lisp, is
| better it that it will vary less between usages. This gives it a
| better chance of a growing ecosystem.
| zozbot234 wrote:
| Just run Emacs as your Lisp Virtual Machine. All it really needs
| is a good editor, but evil-mode is kinda serviceable.
| FPGAhacker wrote:
| I have had this thought. Jokes about needing a good editor
| aside, I wondered about making a unikernal that bootstraps
| enough to start emacs.
|
| The issue I see with the idea of lisp-all-the-way-down is that
| most people don't want to write filesystems and device drivers.
| I know I don't. I mean I find them fascinating, but I usually
| have a specific app I want to write. I don't want to write
| device drivers on my way there.
| convolvatron wrote:
| you could do this with nanos...but i dont know how that would
| benefit you
| codr7 wrote:
| The future is already here, but unfortunately it's programmed in
| elisp and still lacks a decent editor.
| codr7 wrote:
| Oh, come on; I love Emacs, and I admire RMS a lot.
|
| And I mean it, Emacs is as close to a Lisp Machine as you get
| in today's world.
| ByteJockey wrote:
| Emacs has a great editor...
|
| The evil package.
| nanochad wrote:
| > You could open up system functions in the editor, modify and
| compile them while the machine was running.
|
| Why would you want to do that other than hot patching a system
| that can't go down? Testing new changes requires more time than
| rebooting. If you just want to test simple changes, most
| debuggers can do that.
|
| > Everything worked in a single address space, programs could
| talk to each other in ways operating systems of today couldn't
| dream of.
|
| And with a single address space you have win9x security.
|
| > A modern UNIX system isn't self-contained. I have 4 UNIX
| systems on my desk (Desktop, laptop, iPhone, iPad) I'm
| contentiously using the cloud (iCloud for photos, GitHub for text
| files, Dropbox for everything else) to sync files between these
| machines. The cloud is just a workaround for UNIX's self-
| contained nature
|
| This is just your use habbits. Nothing is stopping you from using
| NFS or SSHS. Someone who feels the need to use iCloud for
| whatever trivial convenience it provides is unlikely to benefit
| from a Lisp machine's ability to edit code on the live system.
|
| > Then we add a gazillion programming languages, VMs, Containers,
| and a million other things, UNIX is a bloated mess of workaround
| for its own problems. We need a replacement, something that can
| be built for the modern world using technologies that are clean,
| secure, and extendable
|
| The same thing will happen with any OS given enough time. Lisp is
| also not secure. It's prone to side channel and eval bugs.
|
| > eliminate memory leaks and questions of type safety,
|
| Lisp is not type safe.
| reikonomusha wrote:
| > Lisp is not type safe.
|
| It is type safe. While Lisp is not statically typed, its typing
| discipline is strong: operations performed on incompatible
| types signal recoverable errors.
| [deleted]
| zozbot234 wrote:
| > And with a single address space you have win9x security.
|
| Address space != protection boundaries. These are nearly
| orthogonal concerns. Where single address spaces _might_ become
| less useful today is in dealing with Spectre vulnerabilities,
| though formalizing more explicit requirements about information
| domains (as in multilevel security, which is a well-established
| field of OS research) might help address those.
| maydup-nem wrote:
| > Testing new changes requires more time than rebooting.
|
| no it doesnt
|
| > Lisp is not type safe.
|
| yes it is
| xedrac wrote:
| > They were programmed in lisp the whole way down and could be
| run code interpreted for convenience or compiled to microcode for
| efficiency. You could open up system functions in the editor,
| modify and compile them while the machine was running. Everything
| worked in a single address space, programs could talk to each
| other in ways operating systems of today couldn't dream of.
|
| So this is basically expanding Emacs to _actually_ be the
| operating system. There 's definitely some allure to it. Awhile
| back, I was hacking on the Lem editor for Common Lisp, using the
| Lem editor itself. It was great until I made a mistake in some
| code that restricted my ability to edit the code, sort of like
| performing brain surgery on my self and snipping a nerve that
| controlled my arms. It was amazing to have that immediate
| feedback loop, but in a world that is striving to find new ways
| to minimize human error, I'm just not sure it'd hold up.
| mst wrote:
| Pervasive rollback in a sufficiently compartmentalised bit of
| the UI that it's really hard to break would seem like the ideal
| theoretical solution but practically really quite tricky to
| introduce to an environment retroactively.
|
| (I've been pondering this problem recently for something I'm
| working on an introducing it from the ground up is bending my
| brain hard enough, others may be better at it though ;)
| chubot wrote:
| Meh the problem is "Which Lisp?" There are dozens of incompatible
| Lisps. Even this site is written in a Lisp dialect written by its
| author (Arc).
|
| In fact I conjecture that this is the reason Unix is more popular
| than Lisp -- because Lisps don't interoperate well. They haven't
| built up a big ecosystem of reusable code.
|
| Whereas Python, JavaScript, R, C, C++, and Rust programmers can
| reuse each others' code via Unix-style coarse-grained
| composition. (Not just pipes -- think about a web server running
| behind nginx, or git reusing SSH and HTTP as transports.)
|
| You can also use link time composition. It takes some work but
| it's better than rewriting your Common Lisp code from scratch in
| Clojure.
|
| -----
|
| Honest question: how do you communicate between two Lisp
| processes on two different machines? I know Clojure has EDN
| (which is sort of like JSON : JavaScript), but I haven't heard of
| the solutions for other Lisps.
|
| I wrote about this problem here: _A Sketch of the Biggest Idea in
| Software Architecture_
| http://www.oilshell.org/blog/2022/03/backlog-arch.html
|
| _> The lowest common denominator between a Common Lisp, Clojure,
| and Racket program is a Bourne shell script (and eventually an
| Oil script)._
|
| I'll definitely update it if there's something I'm missing.
|
| I would say the design of Unix is "rotting", but the answer is to
| IMPROVE Unix. Not dream of clean slate designs that will never be
| deployed. Plus this post doesn't actually propose anything. If
| you actually start trying to build your Lisp machine, I believe
| you will run into dozens of reasons why it's not a good idea.
| zozbot234 wrote:
| An unappreciated means of code reuse under *nix is the static
| and dynamic library. This seems to be the go-to whenever you
| need something more involved than simply reusing a full binary
| via pipes.
| scj wrote:
| C's greatest feature is that it trivially maps onto .so
| files. Linking to and creating .so files isn't just cheap,
| it's effectively free.
|
| Most higher level languages I've worked with seem to focus on
| using .so files rather than producing them.
|
| This means the lowest common denominator for the unix
| ecosystem is what C can provide. Otherwise stated, unix is
| marching forward at the pace of C.
| pjmlp wrote:
| No wonder, given that C was created to turn UNIX from an
| originally Assembly written OS into a portable one, UNIX is
| effectively a C Machine.
| armitron wrote:
| The canonical Lisps still widely used today are Common Lisp,
| Scheme and Emacs Lisp. They all belong in the same family, and
| syntax / semantics are close. Porting code from Scheme to
| Common Lisp can be a lot easier than going from Python 2 to
| Python 3.
|
| Clojure is something else entirely which is why a lot of people
| don't consider it a Lisp.
|
| > Honest question: how do you communicate between two Lisp
| processes on two different machines?
|
| If you want to use built-in object serialization, there is
| print and read.
| throw10920 wrote:
| > Meh the problem is "Which Lisp?"
|
| Not a problem - you don't need (or _want_ ) a single Lisp. A
| hypothetical Lisp OS would support a standard runtime and typed
| IPC system that host programs can use (a la Windows and COM, or
| dbus), and nothing prevents you from using your own custom
| communication protocol over pipes/sockets instead.
|
| I don't agree with your implicit assertion that there is a
| _single_ reason why Unix is more popular than Lisp (machines) -
| I think that there are a multitude of reasons. Certainly, the
| most impactful one isn 't a lack of interoperability between
| Lisps - it would be something like the bandwagon effect, or the
| fact that Bell Labs gave away Unix to universities, or the
| inefficient implementations of early Lisps.
|
| I'm also fairly confident that the lack of a Lisp ecosystem is
| not because of a particular lack of interoperability (after
| all, Python has a massive ecosystem that is built almost
| exclusively on (a) C FFI and (b) other Python code), but for
| cultural reasons - Lispers just don't like collaborating
| together, and enjoy reinventing the wheel. These tendencies
| have been documented in [1] and many other places, and are
| highly consistent with my own experience in the Common Lisp
| community.
|
| > Honest question: how do you communicate between two Lisp
| processes on two different machines?
|
| Use PRINT to serialize an object on one machine, ferry it over
| to another one through whatever means you wish, and then READ
| it on the other. Or: "in the same way that two processes in
| most other languages on two different machines communicate".
| Serialize, transport, deserialize. Yes, the ecosystem is far
| less mature, and you'll have to do more legwork, but
| fundamentally the process is the same as in, say, Python.
| (Erlang might be an exception and have language-lever support
| for this, I'm not sure)
|
| This method works for different implementations of the same
| Lisp, and even for different Lisps, under some constraints
| (e.g. while a list with the integers 1, 2, and 3 is represented
| as the s-expression (1 2 3) in almost every Lisp you can find,
| CL represents "true" as T, while Scheme represents it as #true,
| so you'll have to work around that). If you will, you can just
| use JSON or XML as a serialization format instead - every non-
| trivial Lisp has libraries for those formats, and some have
| libraries for ASN.1, too.
|
| >> The lowest common denominator between a Common Lisp,
| Clojure, and Racket program is a Bourne shell script (and
| eventually an Oil script).
|
| All of those languages share basic s-expression syntax
| described above, which is rather higher-level than a Bourne
| shell script. Why do you say that the latter is the "lowest
| common denominator"?
|
| For that matter, why do you exclude the idea that JSON or XML
| aren't "common denominators" between Lisp programs, or even
| between Lisps, Python, and C++?
|
| ----------------
|
| Your article says "Text Is The Only Thing You Can Agree On",
| but "text" isn't even a single thing. The set of bytes allowed
| by ASCII vs UTF-8 vs UTF-16 aren't the same. Even if it was,
| plain text is _purely sequential and flat_. Program
| interoperability requires structure. If the structure isn 't
| directly encoded in a given "substrate" (such as text), and you
| need another layer on top, then that substrate isn't actually
| the one providing the interoperability. You say "Text is the
| most structured format they all agree on" but text isn't even
| structured at all, and nobody completely agrees on it - "bytes"
| is the only thing that fits into place here (which is
| equivalent to saying that there's no structured communication
| method that all programs agree on, which is true).
|
| Put another way - programs do _not_ communicate using plain
| text. They communicate with either an ad-hoc protocol built on
| _top_ of text (that still has a set of constraints that make it
| incompatible with other protocols built on top of text), or
| they use a standardized format like JSON or XML, or even
| something like ASN.1 that isn 't a subset of text.
|
| Communication using text does _not_ make programs
| interoperable. Bytes might be a "narrow waist", but _text_ is
| factually not - if it was, you wouldn 't need to use
| sed/awk/perl one-liners to connect various Unix utilities to
| each other, because the very fact that they were all using text
| input/output would make them interoperable.
|
| You say "Tables and documents are essential structures in
| software, and expressing them in JSON is awkward." but you
| _can_ express them in JSON. You _cannot_ express those
| structures in "plain text", because "plain text" is not
| capable of expressing structure at all, and the best you can do
| is build a protocol that is a subset of plain text that _can_
| express structure (JSON, XML, CSV, etc.)
|
| ------------
|
| If anything, Lisps are _more_ interoperable than Unix, because
| the "lowest common denominator" of Unix utilities is "plain
| text" (which by definition cannot encode structure), while the
| lowest common denominator of Lisps is some common subset of
| their s-expression formats, which can encode structure.
|
| ------------
|
| > I would say the design of Unix is "rotting", but the answer
| is to IMPROVE Unix.
|
| You say this, but you haven't given a reason for why that's the
| answer.
|
| Here's a reason why improving Unix is not the answer: because
| "everything is text" is a fundamentally flawed paradigm that
| introduces needless complexity and fragility into the whole
| system design.
|
| > Not dream of clean slate designs that will never be deployed.
|
| You're mixing the normative and the positive - "Unix _should_
| be improved " with "clean-slate designs _won 't_ be deployed".
| Are you making an argument about what _should_ happen, or what
| _will_ happen? (there 's no guarantee that any improvements to
| Unix will be deployed, either)
|
| > Plus this post doesn't actually propose anything. If you
| actually start trying to build your Lisp machine, I believe you
| will run into dozens of reasons why it's not a good idea.
|
| Oh, yes, and I can start with a few: first, there's good reason
| to believe that high-level CPUs are a bad idea (as suggested by
| the fact that nobody has been able to make an effective
| one[2]); second, the security-less design of older Lisp
| machines is a _terrible_ idea (in a vacuum); third, that a
| machine that _only_ runs Lisp is going to be unpopular _and_
| there 's no single Lisp _and_ Lisps are not the final stage of
| PL evolution.
|
| ...but the arguments made by the article as to why Unix is
| _inadequate_ are still solid, even if the author is suggesting
| a suboptimal solution due to nostalgia.
|
| [1] https://www.lambdassociates.org/blog/bipolar.htm [2]
| http://yosefk.com/blog/the-high-level-cpu-challenge.html
| chubot wrote:
| This feels like a whole bunch of misunderstandings about what
| I'm saying ... Almost everything here was directly addressed
| in the article.
|
| _For that matter, why do you exclude the idea that JSON or
| XML aren 't "common denominators" between Lisp programs, or
| even between Lisps, Python, and C++?_
|
| JSON is mentioned in the post as A narrow waist, not THE
| narrow waist (of an operating system or of the Internet). I
| also mention CSV and HTML as "on the same level".
|
| Likewise, bytes and text have a similar hierarchical
| relationship. I mention that in the post and also show some
| diagrams in the previous post.
|
| _If anything, Lisps are more interoperable than Unix,
| because the "lowest common denominator" of Unix utilities is
| "plain text" (which by definition cannot encode structure),
| while the lowest common denominator of Lisps is some common
| subset of their s-expression formats, which can encode
| structure._
|
| JSON, CSV, and HTML are all built on top of plain text.
|
| What I'm contrasting this with is people who say that we
| should build s-expressions into the kernel -- i.e. passing
| linked data structures directly, rather than bytes/text.
|
| See the threads linked in the posts -- a variant of this same
| arguument came up. This is very related to the idea of
| building Lisp into hardware, which I view as a bad idea.
|
| _You say this, but you haven 't given a reason for why
| that's the answer._
|
| The article is analyzing why empirically Unix, the web, and
| the Internet have worked in multiple respects --
| interoperability, generality, scalability in multiple
| dimensions and multiple orders of magnitude, extensibility
| over decades, the polyglot nature, etc.
|
| These are obviously successful systems, and I think it is
| pretty crazy to have the opinion that because it makes you
| parse things that a design that tries to eliminate parsing
| much be better along many/all dimensions!
|
| These kinds of (IMO naive) arguments are exactly why I wrote
| the last 2 posts. They were popular and highly commented
| upon, and most people got it, or at least appreciated the
| tradeoffs I highlighted.
|
| So I don't need to convince everybody -- as I said in the
| intro to the post, the more important task is to build
| something that embodies these ideas. I look forward to your
| code and blog posts; I do think there is something to the top
| criticism in the thread:
| https://news.ycombinator.com/item?id=30812626
| openfuture wrote:
| It's all going to be datalisp, mark my word :)
|
| Although you have no idea what I am talking about yet just wait
| a bit more :))
| foobarian wrote:
| > In fact I conjecture that this is the reason Unix is more
| popular than Lisp -- because Lisps don't interoperate well.
| They haven't built up a big ecosystem of reusable code.
|
| And why are there so many? IMO the language is too flexible for
| its own good. It promotes this curious intellectual solo-
| competition where you try to prove you are worth of the elite
| who get all the fancy FP stuff and make all this bespoke
| functionality.
|
| It's almost impossible for Lisp to be popular. To be popular
| means a lot of people use it, but that means it can't be
| complicated much above the median. But because it lets
| individual programmers push intellectual boundaries it self-
| selects itself out of this pool. Any big collaborative project
| will attract this type of developer and soon the lesser
| developers (who don't dare object for fear of appearing dumb)
| are not able to contribute.
|
| Just my opinion, if a little dramatic.
| bitwize wrote:
| You are aware that Lisp machines understood several different
| flavors of Lisp? The Symbolics ones understood Zetalisp and
| Common Lisp at least. Were they on the market today they could
| be convinced to run Clojure and Scheme as well. There are a few
| old-timers developing Common Lisp applications to run on modern
| hardware, using Symbolics hardware.
|
| In fact, Symbolics shipped compilers for other non-Lisp
| programming languages, including C and Ada. These interoperated
| smoothly with Lisp code, much more so than they do under Unix.
| In this demo, Kalman Reti compiles a JPEG decoder written in C,
| and replaces the Lisp JPEG decoder that came with the system
| with it, yielding a performance boost:
|
| https://www.youtube.com/watch?v=o4-YnLpLgtk
| chubot wrote:
| OK interesting, I will check out the link.
|
| I still think various Lisps don't interoperate enough today,
| but I'm not very familiar with the Lisp machines of the past.
| If it can interoperate with C and Ada that's interesting. But
| I also wonder about interop with JavaScript :) i.e. not just
| existing languages but FUTURE languages.
|
| These are the M x N problems and extensibility problems I'm
| talking about on the blog.
| fiddlerwoaroof wrote:
| If you're fine with ES3, there's
| https://marijnhaverbeke.nl/cl-javascript/ (I've been
| intending to use Babel to compile modern JS to ES3 and then
| load it into CL, but no time)
|
| Or parenscript: https://parenscript.common-lisp.dev/
|
| Or CLOG: https://github.com/rabbibotton/clog
|
| And, there's always the option of writing an HTTP or
| websocket server and serving JSON.
|
| I personally use the SLIME repl in emacs for a ton of
| things I used to use bash one-liners for and you can push
| it pretty far (this is an experiment, I've wrapped it up
| more nicely into my .sbclrc since):
|
| https://twitter.com/fwoaroof/status/1502881957012668417?s=2
| 1...
| convolvatron wrote:
| > Honest question: how do you communicate between two Lisp
| processes on two different machines?
|
| using continuations with sexps is insanely powerful
|
| send (+ 1 3 (lambda (x) `(handle-response, x)))
| syrrim wrote:
| pretty sure hn was ported away from arc at some point.
| fiddlerwoaroof wrote:
| > Honest question: how do you communicate between two Lisp
| processes on two different machines?
|
| Depends what level of integration you want: custom tcp/udp
| protocols, HTTP and websockets are all pretty easy. But, you
| can also use something like this over a trusted network/vpn:
| https://github.com/brown/swank-client
| Jtsummers wrote:
| > Honest question: how do you communicate between two Lisp
| processes on two different machines? I know Clojure has EDN
| (which is sort of like JSON : JavaScript), but I haven't heard
| of the solutions for other Lisps.
|
| Probably TCP or UDP based protocols like essentially every
| cross-network communication in every language today.
|
| EDIT: Also, it should be noted that JSON does not, itself,
| allow you to communicate across a network. It's just a
| serialization format. You still have to select some protocol
| for actually doing the communication. If your answer to the
| question "How do you communicate between two JavaScript
| processes on two different machines?" is "JSON", you've failed
| at actually answering the question.
| chubot wrote:
| Right, so that is what I'm getting at. If you have two Lisp
| programs on different machines, or two programs written in
| different Lisp dialects, the way you compose them is
| basically "Unix" -- serialize to some common format and send
| over a pipe / socket.
| daniel-cussen wrote:
| So it's interesting to note modern hardware is only 60x faster
| than Lisp machines when it should be 1000x. Weirdness of Lisp,
| turns out hardware isn't some random thing. And harder to
| compromise than modern stuff, by a huge amount, real actual
| security improvement.
| glmdev wrote:
| Not saying you're wrong, but do you have a source for the
| 60/1000x number? Curious to read more.
| daniel-cussen wrote:
| Yeah, where did I read it, I think John McCarthy checked it
| out along with...who could it have been...definitely him.
| lispm wrote:
| Today one Lisp Machine CPU emulator written in assembler is
| 80 times faster than the original Lisp hardware. This could
| be made faster by a JIT compiler. Native code Lisp
| compilers for x86-64 or Apple's M1 are roughly 800 times
| faster than the original Lisp hardware (the third
| generation Ivory processor).
| daniel-cussen wrote:
| Wow! Really?! So the M1 really is faster in a non-
| gimmicky way? I could cut out this X86-64 assembly
| bullshit, at 800x I could be happy just with Lisp.
| Assembly all based on C by this point anyway...
___________________________________________________________________
(page generated 2022-03-26 23:00 UTC)