Lisping at JPL (2002)
flownet.com
flownet.com
I'm always curious though: what's the other side of the story? Why is lisp always rejected?
I started programming seriously (for money) in 2009, and when we needed a language we went with python because it had better math/science libraries than Java and much more libraries in general than clojure/lisp/ocaml. I confess I like the functional languages and like using some of their features in python.
Was the no-libraries dealbreaker for the "pure" functional languages also true in 1999, which led google to java? Or maybe there are complex meta-programming bugs you can generate in the functional languages (and elsewhere) that are the dealbreaker? Or what?
But if you're an engineering leader at a large company, the last thing you want is an asset in your portfolio that only extraordinarily skilled people can work on. What if they quit? What if your company's stature declines and you can't attract such people anymore? What if a more pressing problem comes along and you want to deploy them elsewhere?
So we get languages with short learning curves and low ceilings (Go!) instead.
Except in performance critical contexts, where it can’t be helped, but C++ already won that one.
Two days after starting Haskell I had essentially nothing to show for it except a feeling that I has a huge amount to learn before I could be productive. Even a year later I still have a huge amount to learn.
Of course, the same is true for the programmers. They are not extraordinarily smart, they make quirky technical decisions. Interest in functional programming solves technical problems as much as your choice of editor.
Or that mainstream languages already have the maximum expressive power and these are just lateral moves?
It isn't always. I have a consulting gig for a chip design company that uses Common Lisp internally. It's one of their principal competitive advantages.
But mainly it's a vicious cycle: no one uses it because no one uses it. Employers don't use it because they think (mostly correctly) that they can't find CL coders, and no one learns CL because no one hires CL coders.
I've always been annoyed by the "there are no X coders" argument. Coding skills are broadly transferrable. My team's code base is all python, and we've had successful team members who'd previously worked only in javascript, Java, C#, etc. When we tell recruiters that any of these languages will do, they hate that. Oof.
With lisp you can modify your development platform to suit your needs, In practice, over time you create your own programming language.
You create your DSP(Domain specific language) with your own systems. This is not standard. You are dependent on the programmer.
Companies prefer to buy "solutions"(packages,environments) from companies and depend on those solutions. They are standard and you can hire people trained on them. Replace them if needed and make people continue the work that someone else left.
That is because "solutions" have open documentation, designed by people that are able to draw beautiful diagrams, lots of books, videos on the Internet, but lisp gurus have all the info in their heads.
Bugs are way easier(orders of magnitude) to find with meta programming. In fact you can create a subsystem that finds all bugs so you don't have to.
doesn't this kind of mean they were bad abstractions though?
(am guilty of this myself of course...)
This needs some explanation.
This allows you to write utility functions that transform programs in all sorts of useful ways to find bugs.
A simple example is to just transform the program so that it traces whatever you want to a log, much like Visual Studio Intellitrace, but completely flexible.
You can do things like replace all floating point numbers with a "dual number" (a 2-number tuple) where the first number is always rounded down when operated on, and the second number is always rounded up. This then lets you robustly determine if your numerical accuracy is guaranteed to be within a certain range (due to floating point error, at any rate).
You can symbolically evaluate programs involving random variables using their distributions instead, symbolically working out the products of functions instead of scalar values. This allows things like video poker or lottery programs to be robustly evaluated for average payout even if some of the plays are rare, such as jackpots. A friend of mine did this using Mathematica back in the early 2000s.
It goes on and on...
Whichever word you put before "gurus" in that sentence, I don't want to work somewhere which values that dynamic. Programming is very occasionally a solitary and purely technical task. The rest of the time it's a collaborative and human task. Eschewing documentation and presentation in favor of "fits in one genuis's head" is not a good thing if the task at hand is collaborative/involves multiple humans.
So it now has all of Java, JavaScript and Python ;)
So for now, I use Pandas, Numpy, matplotlib, and all that from Clojure using libpython-clj. Which is the biggest issue with graal-python currently, how to leverage all the C-based libraries. That's where libpython-clj excels over Graal.
That said we do like GraalVM it has a cool ability to create native binaries out of Clojure apps, which is currently powering a resurgence in Clojure for scripting the last wave had to use Clojure's JavaScript target (cljs)
Armed Bear Common Lisp is an ANSI Common Lisp, thus can use all CL libs, runs on the JVM, and it can easily call Java libraries. In fact as easy as calling regular lisp functions.
Just one datapoint on how things were trending then.
I can actually program in it without wanting to stab myself, which has previously mostly been limited to perl and various lisps ;)
Today, parsing is one of the least interesting problems in language design (unless you're C++ or based on natural language). Most of the effort of spinning up a new language is in the backend (optimization and error checking), where lisp doesn't offer a compelling advantage (well, writing folding rules in C is a total pain, but this is a recursive problem... I can just write a code generator).
SBCL literally allows writing compiler intrinsics (and I'm talking about native machine code, not bytecode) at runtime out of the box: https://www.pvk.ca/Blog/2014/03/15/sbcl-the-ultimate-assembl...
I think learning Clojure will continue to pay off the reach you can get with it in one language is insane
Good that JVM eventually started to get nice languages like Clojure, Scala, etc - despite being the platform of choice of corporate Vorlons.
My best guess is performance.
In the 70s, computers were slow. When the decade started, the competing languages of the time were Fortran, Algol and Cobol. All were imperative languages with manual memory management that would compile directly to hardware and had semantics very close to that of the hardware. On the other hand, at that time, Lisp was this high level thing, garbage collected, dynamic types, semantics more removed from the hardware, etc. Meaning Lisp was much less performant.
Then in 1972, came C. A language inspired by Algol and Fortran, using very similar imperative semantics and constructs, but changing the syntax slightly to what is now the common syntax most programming languages use.
The whole point of C was to be crazy fast, and for compilers to be easy to write so it could be portable as well. C's biggest move was that Unix was re-written in it. Before that, operating system kernels were implemented in assembly language! Unix was implemented in assembly language! Think about that, performance was critical in the 70s for a kernel.
Once Unix was re-written in C, and C proved to be performant enough to run a Kernel, its momentum started growing. Unix won the OS war, and slowly everyone was using computers running Unix, meaning that it had a C API. What happens when the most popular OS has binding in a specific language, more people choose that language to write programs for that OS. Thus C became ever so popular. Lisp was there, but not leveraging Unix as much, and still much too slow.
And this was the beginning of the momentum for C, it only accelerated since then. Linux came around, also in C, Windows, also in C, all major OS were in C. So C like syntax, semantics and programming constructs became the norm, and was what got thought in school and uni, etc.
Fast forward to today, and Lisp is finally "fast enough" to be used. We finally reached a point where you can have useful programs in slower languages, like Python, Java, JavaScript, C# all demonstrate. But how can you beat 50 years of momentum in C like languages? That's what most everyone knows. That's why imperative, mutable, procedural statement based, with C like semantics and syntax is still the norm, and all other languages that aren't struggle to get a foothold.
In the 70s speed wasn't really the big problem, but performance. Sounds similar, but it wasn't. The performance of Lisp on a mini computer seriously degraded with the number of users on the machine and the lack of available RAM (one megabyte?). A single Lisp on the machine could be relatively fast, but Lisp had high memory demands and a simple GC could walk through all allocated (virtual) memory of a Lisp process. Thus the machine got slow when 50 users suddenly worked next to one or two Lisp users. For Lisp users this was especially a problem, since they were often meaning to use interactive Lisp systems, not batch computation.
The idea of Lisp computers was not so much about faster CPUs, but a performant machine for a single user with high memory demands.
90s memory sizes started to get bigger, but Lisp was then hit by the AI winter. Many projects at that time were either moving to C++ for applications (because that was the new efficient industrial language) or tried to develop new languages, which are simpler, cheaper and more deployment friendly (Dylan, Java, C#, Scripting languages in a C runtime, reimplementations of special languages in C/C++, ...).
Cost of development systems and the cost of deployment - we are talking about cost of both software and hardware here - was a problem for a long time.
There were always also people who tried to provide solutions, Scott Fahlman for example directed the CMUCL project and his goal was to have an optimizing CL system for free - providing CMUCL as no-cost public domain software was a major goal for him.
High level programming languages have been used to write operating systems, including the kernel: Lisp (on Lisp machines), Algol 60 (MCP on Burroughs mainframes) and PL/1 (MULTICS on General Electric and Honeywell machines). MCP and MULTICS (from which Unix gets its name) preceded Unix.
One difference between C and Lisp is that C was designed to run on the PDP-11, and is a close match for its instruction set. Lisp didn't have a native hardware architecture (the closest it had was the PDP-10) until Lisp machines were built, and there were economic reasons - largely economies of scale - why they're no longer built.
IBM also has a long history of using (non-standard and semi-secret) PL/I dialects for operating system development. Much of MVS was written in a PL/I variant optimised for systems programming PL/S (which later evolved into PL/X) – older versions were mostly assembly, with successive versions more and more written in PL/S – and that remains so with contemporary z/OS, although brand new development has largely switched to other languages, especially C.
Similarly, most of the software for the AS/400 was originally written in a pair of PL/I dialects, PL/MP (for code beneath the virtual machine layer) and PL/MI (for code above it.) (Starting with the CISC to RISC transition, PL/MP and PL/MI were progressively replaced by C++.)
Apparently, AIX 1.x and 2.x were written in a mixture of C and PL/I, but IBM got rid of all the PL/I code in AIX 3.x onwards which are pure C.
Yes I agree with that, I thought I had made that point clear.
C won over the other C-like due to Unix. But Lisp-likes lost because they weren't fast enough to run on commodity hardware. That meant that the hardware that became popular did not run Lisp, and didn't have an OS written in Lisp. Instead it did C, this has created a massive momentum that still dictates to this day what language is popular and which one isn't, in my opinion. At least it is a strong contributor I'd say.
C functions called from Python (like Numpy) are faster than Common Lisp but pure Python is much slower.
That's the crux of my argument. Not that Lisp is too slow today, it's quite fast considering today's programming language landscape. But that it was when it mattered, in the 70s and 80s.
Had Lisp been able to overcome that, we might be in a world where the most popular OS is implemented in Lisp with a Lisp API. Where the commonly thought paradigms in school would be expression based lambda calculus, functional programming, dynamic runtime object systems, meta-programming and the all mighty parenthesis syntax ;)
Lisp stopped being slow a long, long time ago.
The 80s is already 10 years later than my timeline, C had already gained massive momentum by then.
> Lisp was used to program massively parallel supercomputers
I'm curious to learn more about this, can you be more specific or provide links?
But anyhow, a massively parallel computer is a very different beast. Most computers used by people and enterprise were not massively parallel, and Lisps had poor performance on them and their architectures compared to C.
> Lisp stopped being slow a long, long time ago.
How long ago is that? I'd bet it was too little too late already. In my opinion, it would be somewhere along when Java came around, in the mid 90s. And even then, I'd say it was still too slow for most user application, but started being good enough for server work. At that point though, the momentum of C was already unstoppable, and Java became dominant, not CL.
1973.
From http://www.softwarepreservation.org/projects/LISP/maclisp_fa... , "This reports the results of a test in which a compiled MacLisp floating-point program was faster than equivalent Fortran code. The numerical portion of the code was identical and McLisp used a faster subroutine-call protocol."
Original article: https://www.deepdyve.com/lp/association-for-computing-machin...
I think this reinforces my thesis here. You can tell from the article that at the time, Lisp needed to prove itself in the mind of people as "fast enough". That seems to be the intent of the article. Given a good compiler, it may be just as fast.
I'm not trying to bash Lisp, I love lisp, I use it all the time. And when I say "fast enough", I know lisp is manageably fast, maybe custom hardware could have made it equally viable, maybe it only needed a more sophisticated compiler more widely available at an affordable price, but in practicality, it had more hurdle to overcome than other languages to meet the bar of the time.
Imagine an alternate reality where Lisp was clearly fastest. Where its semantics mapped very closely to commodity hardware of the time, and where Fortran, Algol, C, etc. semantics are all further removed from those hardware instructions, making them require more sophisticated compilers or very expensive specialty hardware to have them perform as well as Lisp. I feel it in such a reality, I can't see why C would have become the language of choice and not Lisp.
> 1973.
> From http://www.softwarepreservation.org/projects/LISP/maclisp_fa.... , "This reports the results of a test in which a compiled MacLisp floating-point program was faster than equivalent Fortran code. The numerical portion of the code was identical and McLisp used a faster subroutine-call protocol."
> Original article: https://www.deepdyve.com/lp/association-for-computing-machin....
To add some more detail, the public description MACLISP floating point code being faster than Fortran, was published about 7 months before public unveiling of UNIX and when C was just taking more solid shape in it.
In the end, the JPL isn't a software shop. The glory is in the hardware end of things. As a consequence, you want something that has a broad pool of talent, tooling, vendors, etc. to draw upon for support. It also was a more natural transition from their extant Fortran & C code.
LISP's marketshare had already declined significantly at that point, and it's primary remaining user base didn't have very similar needs to the JPL. When you're an outlier for a language with small marketshare, that means the tools, skills, vendors, etc. aren't going to be as well suited to what you're trying to achieve.
tl;dr: when you're in a domain where you aren't trying to be quite so innovative, it helps to run with the pack.
https://www.amazon.com/Little-Schemer-Daniel-P-Friedman/dp/0...
It's not about whether a programming language is simple or not. (I actually think LISP is not as simple to understand as imperative languages, unlike most nerds think) It's about what you can build with it.
For example, my first experience with programming was to build a game. If someone had tried to force-teach me LISP, it would have actually had opposite effect on me because then it would be no different from someone trying to force teach me some boring subject I have no interest in. The best way to teach something is to provide gratification. LISP is only gratifying to nerds who marvel at its "elegance", but it has no ecosystem which has tons of cool projects like fancy graphic engine or fancy game engine. It's just a "cool" language to nerds.
DON'T teach your kids LISP if you want them to love programming. Teach them JavaScript or Python, or anything they can build something tangible with which they can show off to their friends.
My go to language to refer people who want to learn is Processing though. Easy to use, and the documentation is fantastic (and Dan Shiffman is IMO the best programming educator out there for kids and adults alike, whether or not you like his high-energy style).
Lisp should be forbidden to young programmers, precisely so they'll go seek it out.
This provides a 2D and 3D NetLogo installation. The 3D version blows my mind. You can spend days going through the samples. When you look at the code after you watch a simulation, it's a bit of a shock how compact and readable it is. It's definitely a whole lot more than what they taught you and I alike in middle school.
> Lisp should be forbidden to young programmers, precisely so they'll go seek it out.
Unless it comes with a turtle, of course. Then they might end up writing the next greatest flocking algorithm.
Examples of educational languages would be Alice and Logo, and they're both pretty bad at actually doing anything.
I started by typing in listings from a book (101 Basic Games). Then I'd start modifying the games. Then I'd write my own. It's how people learn.
For a famous example, look at the Beatles. They started by copying other tunes. Then they modified the copies. Then they wrote their own.
Lisp is an imperative language. The order of execution is defined and you use side effects.
https://twitter.com/id_aa_carmack/status/569688211158511616?...
https://groups.google.com/forum/#!topic/racket-users/yjRuIxy... (Make sure to look around in this thread; he has a few comments.)
https://twitter.com/id_aa_carmack/status/635839636754038784?...
In most cases, people who are masters at something tend to be the worst teachers because by becoming the master they have forgotten how to sympathize with complete newbies.
It is possible to teach someone Lisp, or something like it, without teaching them all of it at once... if ever. There are lots of people who use CAD systems like AutoCAD, or Emacs, or the various Lisp based/inspired Expert Systems shells, etc. who wouldn't consider themselves 'Lisp programmers' who learned just what they needed to be productive. If people were exposed to it a bit at a time, rather than the fire hose with minimal direction, I suspect a lot of complaints could be addressed. For example, the reason people think all the parens are bad is because it's become a meme and it's different than what they're used to. If they had started with Lisp and never learned ALGOL-inspired syntax, semicolons would likely look very strange to them.
Of course this process could be done in an advanced language that grows with the user, but most modern languages are not that - even Python expects the user to understand at least the rudiments of structured flow and objects almost immediately. Lisp (Common or Scheme) isn't it, either - lambda calculus is already far too abstracted from the "series of instructions" model which is a critical foundation for computing in the real world. C, my next step after BASIC, has quite a good balance of available abstraction and a tractable mental model; but the amount of boilerplate (the requirement for main() always seemed baroque to me) and hand holding of the computer (total lack of even trivial type inference) is not ideal for a beginner language.
You didn't pick very good evidence to support the idea that picking a LISP is a great way to get kids to love programming. This only supports the idea that Carmack thinks that learning a LISP is good for his son's development.
If the goal is for a beginner (whether child or adult) to be able to make cool things fast, Lisp is a great choice. The interactivity and the simple syntax makes it very easy to get up and running compared to more mainstream languages.
The best motivator is recognition. Kids don't care if a language has books and whether there "exists" a game development kit. They only care about how much satisfaction they will get by learning something and building something with it.
If you want your kid to learn programming, the best approach is to teach them Swift or Java, or Javascript, so they can build a mobile app or web app and show off to their friends. And they will get the joy of building something that is actually used by others. That's how you get people to be interested.
LISP won't get you anywhere in that sense. Sure you may learn some programming concepts, but the ROI is not worth it. Kids might as well spend a bit more effort to learn languages with more exposure and actually feel the satisfaction of having real users.
That's basically child abuse.
Do you want your kid to learn actual computer science, or do you want him/her to basically be able to create a cookie cutter mobile app?
This is exactly the point I was making in the ancestor thread. If you want your kid to learn computer science, you don't force feed him/her things they will have no interest in immediately. Instead you teach how to build a "cookie cutter mobile app", and they will get interested and go from there and teach themselves racket or lisp or whatever you originally wanted to force feed them.
But that Tactix GUI took me two months of sustained effort, lasting longer than any of the actual class projects. Most of the students struggled to draw a circle. It took weeks for us to get to "implement a method that takes an argument".
If you're looking at teaching programming concepts to elementary school children, i.e. to most kids, building applications doesn't seem very likely to me. It takes a long time and small children have poor memories for long-running projects.
If the programming is supposed to support elementary math and logic for kids who are getting used to the notion of "variable" in both programming and math contexts, teaching the kids to write the sieve of Eratosthenes or Babylonian algorithm really does seem like the way to go. Not because it teaches them to be good programmers or to like programming, but because it teaches them to think, and they're mostly not going to grow up to be programmers.
If, however, you want to entertain the minority of schoolchildren who do like computers and want to learn to program, then using an easy graphics library with good deployment tooling makes sense. Those kids do want to spend two months or so making a game. But that doesn't, to me, seem to be in the spirit of 'proximitysauce's comment.
most of us!
we have made it difficult to show our games and stuff to friends. except for minecraft and game mods. that's why kids gravitate towards those.
as a side note, i was thinking last time that programming is difficult to teach nowadays because when you boot your computer or phone, it doesn't drop you into a shell or command prompt.
so few people nowadays know that you can actually give commands to your computer or phone. so the concepts is not familiar to most!
I have no doubt about what you say. I had a really broken laptop that my 3rd grader happily tookover as his laptop, a linux machine mind you, about which he knew nothing about. I showed him how to open a terminal and use some bash commands, and how to invoke the Python interpreter and import a turtle graphics module. He was hooked and had lots of fun moving the turtle around (along with the incentive to learn some math at his level). I remember the day he walked to school with this duck taped laptop on a show and tell day, which ended up with the school's IT departement making Python available on all computers in that elementary school lab. I don't think he could have pulled this off in lisp. Beautiful language Lisp,but I don't see how I could have helped with graphics programming within an hour or so -- which was all what he was interested in.
Don't fall into the trap thinking lisp is just functional.
There were some later small implementations (e.g. for the Apple II) that were written from scratch and didn't need to implement all of Lisp (e.g. lambda, plists, etc).
Logo is a bare-bones Lisp disguised as an educational language.
Really makes you think what kind of fun programming was about back then and its potential. Frankly speaking you begin to feel programming has kind of lost its way.
I also picked up that book. What are you using to work through the exercises?
? tanne.print tanne.output tanne.shift tanne.split 19 3 3
- it is completely possible to build cool things with lisp, as highlighted by some other people who answered your message.
- your pejorative use of the word "nerd" above is really annoying and doesn't bring anything to your argument.
I am doing a rearchitecture of the game's code.
https://twitter.com/id_aa_carmack/status/569688211158511616?...
Ariely said there are actually better ways to get people interested, which is to show them something meaningful.
https://www.pscp.tv/w/1yNGapZbZElKj (see minute 15 and ahead)
Also Clojure can use all of Java and JavaScript, so there's lots of tangible thing you can build. That said, here I'd mostly agree with you, the barrier to entry should be as small as possible, you just won't find the amount of tutorials and guides, and tooling that JS or Java would have on its own.
https://github.com/arcadia-unity/Arcadia
Build on top of Clojure's CLR support, obv.
I mean, this isn't true for everyone of course, but I began learning to code at around 8 or 9 years old because I was heavily interested in math and numbers, and precisely because I didn't have many friends (or brothers or sisters) to occupy my time with when I was very young.
I agree with the premise that the majority of folks learn better with a practical goal in mind, but I disagree with you that there exists only one kind of curious child.
I had a second-hand IBM XT from my fathers' shop at first, and I wanted to learn how to do things with it.
That equipment being available, in my opinion, was the biggest motivator in learning how to use it.
It was there for me to use, the limit was simply my knowledge of how to use it, and that was a very enticing proposition.
My first project as an 8 or 9 year old was a prime number generator (a naive sieve). I had read a book about patterns, and primes had been mentioned. I took a trip to the city library (another rarity statistically?) and picked up a guide to Pascal that was written towards small business owners and non-CS college students to help them with simple automation, and got to work looking up terms.
A week or two later I had a CLI program that spat out primes as fast as my computer (or my poor implementation..) could make them.
I then tried to use those primes to draw trippy pictures, which began another foray into programming topic that were new to me, necessitating more work looking up terms and generally haunting the library.
Years later, when I was a teenager, when I ran into like-minded computer folks and we'd get to talking, that same prime generator got spun into a small benchmarking suite that my friends and I toyed with before the multi-core trends.
so.. I guess that the "show it off to friends" thing still happened, but knowing myself and how I learn, I doubt that i'd have ever been interested in a hobby that was pushed towards me by authority figures as being useful.
I have a hard time conceiving how I would become a 'computer person' now-a-days, in fact. I was so anti-social and actively hostile towards teachers that the idea that one of them could have tutored me in the hobby , quite counter-intuitively, may have been the exact reason I would have avoided it as a child.
really, my grand tl;dr : "There is no one teaching method."
Python is great because of the massive ecosystem and the language is really simple. JavaScript is great because websites.
Last year Clojure made it to #1 (2019), improving from #3 (2018) in the SO salary cahrts.
(https://insights.stackoverflow.com/survey/2019#top-paying-te... vs https://insights.stackoverflow.com/survey/2018#top-paying-te...)
I certainly agree with the comment that what matters at an early age is what you can do with a language. I wanted to make GUI applications or games, and Java and Javascript hadn't been invented yet.
However if you dig deeper geometry is just the beginning eventual goal is to teach you to simulate movement of insects around light, predator-hunted scenarios etc.
My daughter took her first programming course in college and used the excellent book (HTDP), see [1], intended for beginners that used Racket as the programming language. By the end of the semester she was able to make a simple graphical game. I thought the course was very good and she liked it and still has a fondness for Racket although I believe that she has only used Java, C++, and Python since that class (she is now a CS major).
Learning Racket (which is Scheme and very closely related to LISP) worked out well for my daughter, so why would I say that LISP in elementary school isn't a good choice? Several reasons:
• Lisp isn't a popular language, ranking 28th on the TIOBE list of programming languages so there is far less opportunities to make use of programming ability in LISP than in other languages.
• Lisp isn't easy. The Common Lisp Standard is well over 1000 pages long. It lists over 1000 functions. Take a look at the basic iteration constructs, the most general is LOOP and has a whole chapter, see [2], in Peter Seibel's excellent Practical Common Lisp, but even the simpler DO construct is no cake walk[3].
• Recursion for elementary students... LOL
• Smart people have tried introducing LISP based programming to youngsters already and it didn't seem to take off. See Papert's LOGO language from the 80's. I've actually written some programs in it, but I don't remember where I got to use the language. (Perhaps it ran on the PLATO system?). I agree with a number of his insights[4].
Elementary school children don't understand functions and they really don't even understand basic math. The problem with LISP is that while it has an abstract simplicity that I find appealing and really quite beautiful, it's abstract nature is going to make it difficult for children. Less abstract systems like ALICE or SCRATCH seem a better fit if we insist on teaching kids to code.
I personally don't see the need to teach kids to code. Why not teach them math first. Why would programming come before understanding how to divide fractions or how polynomials work or what simple logical operations mean?
[1] https://en.wikipedia.org/wiki/How_to_Design_Programs
[2] http://www.gigamonkeys.com/book/loop-for-black-belts.html
[3] http://www.lispworks.com/documentation/HyperSpec/Body/m_do_d...
[4] https://docs.google.com/viewer?a=v&pid=sites&srcid=ZGVmYXVsd...
If I were to design a language matching that name, I guess it'd be basically Logo written backwards. This might be interesting for a live programming environment, because in Lisp you type a whole expression and and nothing happens till you hit enter; but on e.g. an old HP RPN calculator you see the state of the data change after every keypress. You could design an "RPL" to work that way too, though after every word instead of every key.
I can't say the documentation / tutorials that I've found are the best but it's definitely something.
With parental guidance, a 7 year old could totally do this. Figuring out how to handle the stack will be the trickiest part, and there are a few examples online of this, so if you nudge them in the direction of others' work, they should be able to get it pretty quickly. They'd finish it by the time they're 8, at least.
> Logo is a multi-paradigm adaptation and dialect of Lisp, a functional programming language.
A summary of the language: http://wla.berkeley.edu/~cs61a/fa11/61a-python/content/secti...
Or the guide for grade schoolers http://www.educa.fmf.uni-lj.si/logo/doc/Apr.96/chpt8.pdf
And yes, I remember making the snowflake back in the early 80's on an Apple ][+ in the grade school computer lab.
If you know folks learning programming for the first time and maybe struggling with Java or whatever they're using, these references may help. Sometimes you just need to see things like recursion or currying in a different way for it to click.
[1]:http://www.trollope.org/scheme.html
[2]:http://www.paulgraham.com/avg.html
[3]:https://www.worldcat.org/title/schemers-guide/oclc/24430531
[4]:https://schemers.org/Documents/ (more Scheme resources)
They used to... LOGO is a LISP.
There are only five memes to make educational curriculum decisions.
1) Most arguments for programming are from programmers who had fun learning to program and if the purpose of K12 is fun, then all kids should have mandatory enforced fun time which means learning to program. Which will not work for maybe 99% of society, although they will be subject to the curriculum. I had fun playing kickball; the purpose of school is to create an entertaining daycare like environment; therefore all kids should be forced to spend lots of time playing kickball. What about learning, or kids that don't enjoy kickball (or lisp?)
2) We have to prep our 5 year olds by teaching solely vocational skills because nothing will change in programming for the next 12-16 years. I'm old enough to remember "vocational training" that amounted to memorizing ancient versions of already obsolete Excel menus and keystrokes. Utterly useless. We like to think "Clojure K12" would be teaching Clojure, we all know its going to degenerate to drill and kill multiple choice tests about emacs keystrokes. A giant scantron test of multiple guess questions asking what C-X C-C does in emacs or what does M-f do, isn't going to help kids in the real world 30 years later. Better off teaching them welding, industry trends seem to imply TIG is a forever skill?
3) We teach critical thinking skills and frankly kids that can't conceptually understand and solve X+1=2 for X are not going to get anything out of programming that they wouldn't get better out of algebra or geometry. And what do we drop from the curriculum to add Clojure? Sorry kids you're not going to learn Trig?
4) We'll do what the cool kids do. If the cool kids district buys ipads, we need ipads. We had millions invested involving no further reasoning. Is the cool kids district using LISP? No? Well at least a third of districts won't even consider it, then.
5) The school board makes all curriculum decisions and they got and keep their job based on religion and/or politics and LISP isn't hitting the election issue hot buttons quite like a nice argument about creation science in biology class or sex ed or the new stadium for the football team.
Industry does not like LISP because is its very expressive and the programmer has the freedom to express any crazy problem solving idea they have in their head. The problem is the human condition of education for the last couple millennia shows its really kinda hard to take a hyper-customized brain dump of ... anything ... from one head into the other. So, it can do anything, any way you'd like, is too much anarchy for any shared work. How this applies to K-12 is if you think grading essays is a PITA imagine trying to grade large LISP projects.
I've good news for you: Lisp is an imperative language.
I think there are a lot of great uses of the patterns that come out of s-expressions, for example, but I would still choose Go, Python or JS / TypeScript as my daily driver.
There's no God.
// 3 brackets
float diff(vec3 v1, vec3 v2) {
float dx = v1.x - v2.x;
float dy = v1.y - v2.y;
float dz = v1.z - v2.z;
return sqrt(dx*dx + dy*dy + dz*dz);
}
;; 18 brackets
(def (diff v1 v2)
(let (dx (- (x v1) (x v2))
dy (- (y v1) (y v2))
dz (- (z v1) (z v2)))
(sqrt (+ (* dx dx) (* dy dy) (* dz dz)))))In general I think this is true, but an important caveat that your post brings up is that sometimes it also has to do with how we translate one language to another.
Consider treating a 3-tuple as a list, and assume you have the primitive functions zip, square, sum, and sub (inverse of summing a list). Then the idea of the distance between two points reduces to:
(defun dist (v1 v2)
(sqrt (sum (map sq (map sub (zip v1 v2))))))
At the same time, if you want to generalize the C function to arbitrary vectors, you'll have to do a little more work with passing arrays, checking bounds, adding a loop. The Lisp function, by contrast, requires no such effort, and once the concept is understood requires little further explanation.
Even so, the point is that line-for-line translations may not always capture idiomatic usage of the language, which may in turn make it look or feel worse than it really is.
https://fodor.org/blog/webassembly-hello-world
but for some reason the typical Lisp style looks like Python where someone vomited parentheses on it. Not sure why people choose to style it like that.
Are details of this publicly available?
The topic of storing credit card numbers is one of those for which searching returns a lot less information than one might expect. If you need to do this yourself, as opposed to using some third party vault/tokenization system, there doesn't seem to be a lot out there.
Yes and no. No, there was never anything published about the Google biller encryption system. But yes, there is now a lot of information available about encryption. The state of the art has advanced a lot in 20 years.
I shared the reaction, "wow, must've been glacially slow"
Sad it goes to such places.
It's quite good that we have a rather performant, cross-platform, GCed language.
I also didn't feel any epiphany while learning Clojure. I think Haskell is a much nicer language for some tasks, but going full-Haskell seems near impossible without a PhD in some obscure academic niche.
My perfect programming language would be a Jupyter Notebook-like thing where I can just add sections in whatever makes sense. Write some imperative Java, put a small Haskell block for a function that recurses nicely, put a Minizinc block to solve a constraint... Of course, nobody except the original author would feel comfortable with those exact choices... which explains why companies must standardise on something.
The real issu with this approach in my opinion is that a stream of bytes is just too generic, and the necessary (de)serialization is going to eat a lot of CPU for not useful task
Clojure wants to be data oriented, I recommend watching a lot of Rich Hickey talks first to "get" Clojure
document.body.style.maxWidth = '50%';
document.body.style.margin = '5% auto';
document.body.style.fontSize = '120%';
document.body.style.lineHeight = '150%';Author is @lisper around here. They've mentioned this story a few times.
Me: I'd like to talk to you about something...
Him: Let me guess - you want to use Smalltalk.
Me: Er, no...
Him: Lisp?
Me: Right.
Him: No way.
"We were not out to win over the Lisp programmers; we were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp." -- Guy Steele
Should that be read as 1/10th the effort it would take you in any other language (because of your long history with lisp), or do you suppose it would apply to arbitrary other competent people?
Like let's say we could make a few clones of you and start them all out on identical lives except that their early choice of language is different: one gets Haskell, another gets Forth, another Python, Ruby, etc.
In this scenario you're saying you'd bet on the clone who went with Lisp being most productive?
I can say this though: the ability to meta-abstract the language is a HUGE lever that no other language has. And one can also observe subsets of Common Lisp being continually re-invented in other languages. So CL must have gotten something right.
It's disingenuous to imply that every other language is simply "reinventing Lisp". The Lisp community itself spent decades figuring out elements that are now considered basic, like lexical scope. Lisp is just a ball of mud that can absorb any idea in its vicinity, and Lisp programmers like to retcon history to make every idea theirs.
It's not even slightly disingenuous to imply that every other language is simply "reinventing Lisp".
But overall, I think Lisp is an extremely productive language. In the last decades, a lot of modern languages have implemented a lot of Lisp features, so getting closer in productivity, without quite reaching it. Consequentely, the productivity factor depends on which langauge you compare Lisp with. But compared to languages like C++, the productivity gain is really large.
For me, beyond the overall language qualities, there are two especial productivity boosters in Lisp: the ability for incremental and interactive development and to create domain specific abstractions. There are many dynamic languages, but so far I haven't seen one which as easily allows you to do interactive development. That is the ability to update single functions while your application is running. That speeds up the cycle of changing the code and testing it by orders of magnitude.
Then they went to Google, as it appeared different from the corporate bureaucratic programmer = widget approach, only to be charged with implementing a massive Java project. So, irony.
But the real tragedy was that it was all for Ad Tech. Presumably tired of the same JPL work, they not only end up using a hated tool, but also working on something that seems on the opposite end of the "meaningful work" spectrum. Adding to the tragedy, they could have taken any number of development jobs that happened to use Java and yet pushed the needle forward on meaningful work.
I really regret the last 20 years of the best & brightest being drawn into the modern equivalent of Mad Men advertising firms. I do however take a fair bit of solace in the fact that these massive companies and massive systems have resulted, if only as a side effect, in excellent technology that allows corralling and orchestrating massive amounts computational power in a way I thought a bit too "utopian" when "utility computing" was being bandied about in the 90's. Just kind of wish some other monetization model had emerged. Freemium looked promising for a while, but it turned out there was still an infinity of user acquisition friction in between "free" and "extremely cheap". Oh well. I still have hope for the next decade or so.
I work in SoCal for a smaller aerospace firm. According to glassdoor, the pay is pretty decent (a little above average for a software engineer out here), but it really pales in comparison to the numbers I hear people mention when talking about "FAANG" lol.
The cost of living is not less. If you want a 30 minute commute, be prepared to pay through the arse for a 50 year old house in need of serious repairs.
The traffic is an atrocity. I grew up in the Bay Area and never in my life have I seen anything like this.
The benefits can vary from garbage to decent. Where I work, there's free lunch, free dinner, and free (really good) health insurance. OTOH, some other companies have "coffee clubs" and "water clubs" where groups of coworkers donate money to have a monthly supply of water/coffee in their office space.
Oh yeah, and no matter what, if you say you work on space stuff, everyone assumes you work at spacex or nasa. There are no exceptions. lol.
Edit: I realize I probably forgot the upshot. Yeah, this kinda work is pretty darn cool! I also really enjoy doing it, or I'd go work on something else.
Care to explain why? No big deal, but my linguistic curiosity is piqued.
In general though, outside of this one, a lot of things that somes get described as British use turn out to be things that I would also say. Sometimes there are regional differences in the US, or sonetimes it might even vary with the individual. The patterns of who says what aren't always so neat and organized as "this is always American, this is always British."
I myself have one parent who was born in England and immigrated here fairly young, and I sometimes wonder if or assume that's a factor for me.
I'm talking about positive effects to "the world" / society / the public at large. Obviously not to the people getting their pockets filled.
2. Ad Tech is trying to make advertising experience better
No, they're trying to make more money. Whether they do so by making the advertising "experience" (I loathe that freaking word) better or worse it's irrelevant.
3. AdTech (which GP kinda mentioned) pays for a lot of things that are available for free and likely wouldn’t be otherwise
Slavery pays for a lot of cheap or free things as well, so that's not a really good argument in of itself, is it?
People buying stuff from those businesses must at least think they are benefitting from the transactions in some way.
Obviously I can't block everything, but I'm having trouble coming up with some kind of improvement to my life that not ad-blocking would bring me.
The alternative would be dealing with magazine ads and the like which is a whole different profession I would have to learn. Companies have whole departments to deal with that headache. And probably the 1000+ dollar budget involved would be beyond my scale.
Regardless, the GGP's arguments are specious, circular, and delusional. The fact that the GP used slavery as an example doesn't take away from that. (And yes I get the irony of this post, advertising is that hill I chose to die on).
Oh my.
Youtube's current business model essentially breaks all ad-supported classical music content on the site. It does this by interrupting the music in the middle of a piece to insert an add. That means a long piece like a Wagner opera is littered with tens or perhaps even a hundred tiny adds that cut jarringly into the piece in the middle of acts, sections, and even phrases. It's not possible to concentrate on a piece of classical music that way. Your ad tech industry has destroyed whatever segment of content ad-supported classical music on youtube represents.[1]
But that's not my complaint.
I'm watching television the other day and I come upon some classic movie that I hadn't seen in awhile. I start to watch for about five minutes; then, in the middle of a scene, the movie switches to a loud, short commercial. In the middle of a scene! I thought maybe the channel got changed by accident. But no-- this was a youtube-sized commercial doing a youtube-sized jump-cut into a television program.
I kept watching and sure enough, every subsequent commercial used a jump cut in the very middle of dialogue, and every commercial was as short as the ones on Youtube. Now this movie was almost as unwatchable as youtube classical music is unlistenable.
So your ad tech has managed to do something I didn't think was possible-- become a big enough influence on commercial television programming so as to make it even more painful to watch. That's much worse than just "failing at the moment."
[1] Sometimes it appears that the ad-placement algo inserts ads at the next available silence. But that still destroys all kinds of music. For example, many long classical pieces are made up of short-- yet related-- variations separated by silence. Inserted loud, obnoxious sounds between every single variation is no more acceptable than blaring an air horn between each move in a chess game. Edit: on the Brahms Paganini variations I listened to the algo seemed to be every other variation. But that hardly matters.
that strikes me as a bit of a stretch, given that YouTube sells a premium subscription, which gives you a 100 percent ad-free experience.
don't like ads? (i don't!) pony up US$12.99 a month to get rid of them.
i have had a premium youtube account since the month they were announced, and boy do i ever believe i am getting my money's worth. so much stuff on there, by so many creators.
I hope that more services allow me to pay in return for removing ads.
Silence is a part of music like darkness is a part of a painting. To assume that it's "space to fill" is testament to either enormous naivety about or complete disregard for the content itself.
You know what kind of ads no one has ever ever ever liked? Web ads. Banner ads. Pop ups, pop unders, takeovers. They’re all shit, consumers hate them, and consumers love ads in general. It’s a failed business model that has never been viable for publishers.
Edit: I ask that because I use an ad blocker, as does everyone that I know. And I can’t think of a way to reconcile blocking ads with truly believing that ads are good for me.
I am strongly anti-advertising, but I always like to hear from people with an opposite point of view.
I am pretty UX-focused, but I don’t frequent any sites were I would think: god, this is unusable because of the ads. (I do find sites where UX is bad for other reasons)
My current biggest annoyance is that I was trying to hack something on iOS, opened bunch of medium articles and now I am being forced to pay for it, which I’m pretty sure would not be warranted given my usage of it. (I do pay for other services where provided value outweighs cost, like say Spotify). I’d take ad-supported Medium over pay-wall Medium any day (as a customer, maybe as a producer ads would not be a viable model).
1) An appeal to the popularity of ad tech is not a sufficient argument in this case. First, it is tautological: At issue from my original comment is the sheet volume of talent it has attracted. Implicit within that is popularity. As such, you cannot use popularity to justify the phenomena.
2) Nor is the belief of people working in the field that it is useful a compelling argument. And of course it is trying to make advertising a better experience etc. But that just says "if it has to exist, it might as well be good at its job" and doesn't provide show a prima facie argument for it to begin with.
For both 1 & 2, you could easily replace Ad Tech with military equipment and arms dealers. I'm not saying one is as bad as the other. I'm saying the flaws in the arguments become more apparent.
3) This, I think, is where we agree. But I think alternate business models, had they rose to prominence instead, might have been better for society. But counter-factuals are inherently difficult to prove, and it's certainly possible we'd be in a worse state had things worked out differently.
A truly good product sells itself. All advertising is just manipulation.
I don't understand how people can still believe this when it's so obviously false. It's a nice story, that if you make something great you'll get what you deserve. That sounds fair, but there's no reason to believe the market works this way.
A "truly great product" that no one (or not enough people) know about will go out of business and disappear.
Good advertising is just communication.
That's completely absurd. How can a product "sell itself" if nobody knows it exists, or knows how great it is? How do they find out those things? Well, in part, by advertising.
I heartily agree that some advertising is manipulative and anti-social... but I can't buy this "all advertising is just manipulation" stuff.
You also attribute to me beliefs I don't state. Lamenting the tremendous talent that has gone into ad tech instead of what I would consider more worth while endeavors doesn't mean I don't value it at all. Ad tech has facilitated robust sets of nominally "free" tools that certainly have some value.
My opinion of the field, however, is that the "hard" problems it contains are neither as hard nor as meaningful as other areas that have attracted less talent. It seems you'd like to attribute to me opinions that are "black or white", but I'm afraid my views on things are not so simple, and as such not so easy a subject for simple rebuttal.
I am sure you are right in that there areas that would deserve more talent given their impact. Care to elaborate which ones stand out in your mind? (Besides space exploration?)
Optimal auction algorithms for ad placement can be interesting technical work and there can be some interesting economics work in there for price discovery, but in the grand scheme of things it’s not very meaningful to the broader world. You won’t be getting a Nobel prize and your kids and grandkids won’t even be impressed with what you do.
Side note: don’t talk about downvotes coming for your post. It’s a sure way to ensure it and it’s boring.
What to feed humans is the other.
What does he mean by this? Is this related to the C "undefined behavior" or is the reference here to something which affects imperative languages in general?
I'm always amazed at how people have strong feelings for the tools/languages, rather than what they do and how they can help you. Even in this example, the Google person didn't even ask what they wanted to use Lisp for.
People I guess just really like rewriting software in different languages?
What I did say was there's a working piece of code out there that someone else has already spent time getting to work, but we can't use it because of the language it's written in. For example, I've had problems getting people to use Jenkins because it's written in java. Not that they were trying to write plugins or do anything internal to Jenkins, they just didn't like it because the language it was written in.
As an engineering manager, you could support every team or even every individual using whatever they like - but you then have other tradeoffs to make.
It's now not possible to run security tooling over everything or use a common artifact repository or follow common coding guidelines or linter settings and you'll get islands of language culture and endless internal reinvention and rewriting.
Java is a gigantic dependency. Any project that depends on it adds all this dependency with it. In many cases this dependency could be bad or toxic for the project.
It depends of what you do for a living. Personally I will never let anyone include java as a dependency in my company's projects, because for what we do, java is slow and linked to Oracle.
Lisp is a different story. You can create c ,Python, Lua,c++ or whatever code from Lisp easily.
I do.
But the article reads like blatant fanboy-ism, as if Lisp turned spacecraft into unicorns that magically distributed rainbows around the solar system or something. It's completely oblivious to the organizational cost (except, oddly, at Google).
What's the organizational cost of Lisp at JPL? Somebody's got to maintain these tools for decades. Over the lifetime of a spacecraft mission, people leave. People even die. If nobody understands the software (or the tools the software depends on, including the build chain), then when someone other than the original magician has to fix something, you're stuck. JPL really doesn't want to be stuck when a probe is approaching a planet and a fix is needed to make the mission work. The article has zero recognition that such issues could even exist.
Ironically, the point of this JPL Lisp project was spacecraft autonomy. When you're coming up on a flyby, light-hours from Earth, the standard fault-tolerance strategy (go into safe mode, wait for instructions) makes it physically impossible to satisfy mission goals. You need something smarter and more adaptable, and that's pretty hard to accomplish in the standard style of software in C they were used to.
(I was there and read internal docs about the Remote Agent project this post was about.)
Years later in the Pluto mission this nightmare almost happened: the probe went into safe mode ten days before the flyby, and they heroically fixed it over a few days of crunch time.
Speaking from experience, this is independent of the language chosen. I've seen several pieces of software over a variety of languages that are a nightmare to maintain.
What really ends up happening is a kind of oral lore. People learn how to use the parts of the software that is known to work, and the business processes ossify around those known behaviors. The current developers and maintainers walk around on eggshells to avoid changing that behavior because of the risk involved in changing those processes. And then nobody remembers why the processes are as convoluted as they are, and it just becomes the way things have always been done. When there's a series of successful missions backing that assertion, it's hard to argue the point.
But because this idea -- that perfectly reasonable yet "not mainstream" languages produce software thats's hard to understand and maintain -- is so pervasive, we get pressure coming back from the other side. Perfectly reasonable choices of language are blocked, and everything starts regressing to the mean. The old adage goes something like, nobody ever got fired for choosing IBM. Well, nobody ever got fired for choosing Java, either. Even Clojure or Scala, which are perfectly productive, excellent languages that also run on the JVM, are a nervous choice.
(Also, Makefiles are absolutely a dark art, and many modern languages have thankfully produced better abstractions for their purposes, but C and C++ are still seen as totally reasonable first choice languages for a program. =/ )
> JPL really doesn't want to be stuck when a probe is approaching a planet and a fix is needed to make the mission work. The article has zero recognition that such issues could even exist.
Spacecraft often receive code updates while they're in cruise to their destination -- it doesn't matter whether it's Lisp or not. See for instance Juno: http://www.deepstuff.org/nasas-juno-spacecraft-mission-overv...
>> Spacecraft activities during the Jupiter Approach phase include spacecraft subsystem calibrations and maintenance activities, as well as flight software updates and hardware checks in preparation for Jupiter Orbit Insertion.
Apropos of nothing, I found Peter Naur's "Programming as Theory Building" [1] an enjoyable read on the topic of maintaining software after the original developers depart.
Well the great news is that its Lisp, the language is simple. You have the same problem with other languages, except if you used C++, everything just got a magnitude more complicated, both because the whole thing is more complex and the ecosystem is changing and developing more rapidly.
I can't say I've ever seen a Lisp program where abstraction made it incomprehensible. That seems to be a common meme, though. I'd love to see an example.
This is a myth perpetuated by people with zero lisp experience.
I've navigated plenty of lisp libraries' codebases and haven't found not a single case of that.
>I've heard this called "the curse of Lisp
An essay written by... a graphic designer with zero Lisp experience.
I think the part about the toolchain/dependencies still stands.
You won't, since Lisp editors automatically keep parentheses balanced.
But I don't do things in hard real time, so please correct me if I'm wrong.