Earlier quoted context omitted.
What changed?
I currently love both Go and Lisp. They are the opposites of each other. And good for different things.
They have still one thing in common - that are not oop!
Lisp at the Frontier of Computation [video]
81–90 of 143 posts
Re: Lisp at the Frontier of Computation [video]
#82Earlier quoted context omitted.
Do you like Python? Python is basically simplified Lisp. Common Lisp is Python plus first-class lexical closures (rather than second-class) plus true multithreading plus a real compiler so it runs much faster. Plus parentheses rather than indentation to delimit expressions; parentheses are much more versatile once you get used to them.
It's funny that I've been downvoted for this comment, given that I've made a living writing Common Lisp for most of my career (including working with the presenter in this video at one of the companies he describes). Of course Python is nowhere close to CL. (If anything, Javascript is closer because it has first-class closures.) But I've found that if you tell people the whole truth up front -- rather than letting th…
People probably just thought you missed the biggest differences. None of your three would come to mind if someone asked me the main differences of CL and Python (especially real multi-threading considering it's not in the standard even if bordeaux-threads works everywhere) and I'm not close to being a CL expert. I might get to 'performance' eventually if I had to list a bunch.
If you 'let people discover the truth' then you get a person who reads a couple chapters of SICP when they're 16, thinks they know Lisp, dismisses it as a cool idea language but not practical (compared to the more familiar and productive Python, Java, PHP..), and maybe just maybe ~10 years later they see an example like https://news.ycombinator.com/item?id=12222404 and say "I never knew Lisp, what have I missed out on?" But they could have been told what they were missing out on in the beginning! "Condescending Smug Lisp Weenies" may be Lisp Enemy #1, but I think Enemy #2, not far behind, is probably "People who think they know Lisp, but actually don't, write it off due to incorrect assumptions".
That said, I do think there's a certain something common to Lisp and Python that draws people to use both. e.g. Norvig. I think his page at https://norvig.com/python-lisp.html is a pretty balanced comparison.
Re: Lisp at the Frontier of Computation [video]
#83Earlier quoted context omitted.
An old epi²gram: There should be only one way to do it. — Python There's more than one way to do it. — Perl Do the right thing. — Lisp
"Do the right thing" is a brave statement for a language with no typechecking!
Plenty of typechecking primitives are available, and CL itself is strongly - but dynamically - typed. Now, the Lisp way strongly favours interactivity with programming, so by default, those typecheck helpers are not too convenient, to use, and a lot happens at runtime. But:
- CL standard defines a pretty decent type hierarchy (not Haskell-level decent, though).
- While not required by the standard, good CL implementations make use of typing for optimization and safety checks at compile-time. SBCL is particularly great in that domain, employing a solid type inference engine.
- CL allows you to override optimization/safety levels at very small granularity - even sub-function level - with (declare (optimize ...)) forms - like, you can e.g. drop (declare (optimize (speed 3) (safety 0))) inside a loop inside a function, to optimize just this particular section of code.
- Even though CL type-related primitives aren't very convenient (they generate a bit of line noise in the code), the macro system gives you all the power you need to hide it under whatever syntactic sugar you like. There's nothing stopping you from writing (or finding a library defining) e.g. a macro:
(defun* foo ((real x) ((fixnum 0 100) y) z) -> rational
... some code ...)
(declaim (ftype (function (real (fixnum 0 100) t) rational) foo)
(defun foo (x y z)
(check-type x real)
(check-type y (fixnum 0 100))
(the rational (progn ... some code ...)))
--
I see "do the right thing" in the context of that epigram as meaning that you can choose to do the right thing without having to make compromises for syntax and semantics, as Lisp will happily let you remove any and all boilerplate with its macro system.
Re: Lisp at the Frontier of Computation [video]
#84Code as data is such a big deal that - whatever you say - I will never ever understand why we don't all do Lisps.
What's the most popular Lisp in use today? Does it come with a static compile type checking?
Depends if you mean free or commercial.
For the free ones, there are already plenty of answers.
For the commercial ones, that would be Allegro Common Lisp and LispWorks, both having a complete "Lisp Machine" like experience, given that they are around for a few decades.
Re: Lisp at the Frontier of Computation [video]
#85Earlier quoted context omitted.
People don't want powerful features because they can be misapplied, making a mess. These people aren't worried that they will make a mess of their own code, they are worried that they will have to deal with someone else's mess. What happens as you add more developers to a code base, with larger variance in ability and favored abstractions is going to be important in some cases, and irrelevant in others.
To expand a bit on this: Imagine that you're joining a project. It's been worked on by a team of 100 people for a decade. Half of those people were below-average programmers. Many were newbies in the language, and some were newbies to programming. And you're going to get to try to maintain this code. Now, do you want it to be written in a restrictive language, or in one that gives developers the ultimate amount of fr…
Having worked both with big Java projects written by newbies, and on a large Common Lisp codebase that's older than I am (29), I don't really see much difference. Large projects are large, they always require time and effort to get into. That said, my current experience is that:
- A dumb language and simple code in a big project means lots and lots of code. On such codebase, my biggest issue is keeping track of how things fit together, because there's just so much of it (hint: they don't; people writing it can't keep track of all that stuff either).
- A powerful language and complex code in a big project means dense code. Like in that Lisp codebase, where I dealt with big macro-writing-macros, I would spend an hour with a macrostepper, trying to grok what a single line of code does. But once I did, that line of code (and similar lines in other places) were not a problem anymore, and they compressed what would otherwise be thousands of lines of boilerplate.
Which one I like more? I don't know. Big, old codebases suck, that's a fact of life. But I lean a bit towards "more Lispy" than "more Java-y", because it makes me feel I'm using my brain to actually think, instead of just tedious bookkeeping.
Re: Lisp at the Frontier of Computation [video]
#86Earlier quoted context omitted.
Lisp seems to take the exact opposite approach as Go. The power of languages like Lisp appeal to me, so I have a hard time understanding why people want a language that intentionally limits itself. Read Graham's book and he's talking about how macros are great for writing maintainable code because you can make it both short and very readable because it's close to the domain. But then you hear the arguments in favor o…
The complex features, lots of syntax and many ways to do things are not a problem for experienced devs in a particular language. The real trouble comes when these experienced folks leave the project for something more challenging and you start with newbie devs with no experience and they feel demotivated when they come across these tricky features and abstractions which requires months of conditioning. At that point,…
That is the theory, the practice is the factory factory pattern, design pattern books, code generation frameworks, IDE plugins,error handling libraries,... all to workaround the language limitations.
So when a new one comes into the project there is this spaghetti of workarounds in place.
Re: Lisp at the Frontier of Computation [video]
#87Earlier quoted context omitted.
People don't want powerful features because they can be misapplied, making a mess. These people aren't worried that they will make a mess of their own code, they are worried that they will have to deal with someone else's mess. What happens as you add more developers to a code base, with larger variance in ability and favored abstractions is going to be important in some cases, and irrelevant in others.
To expand a bit on this: Imagine that you're joining a project. It's been worked on by a team of 100 people for a decade. Half of those people were below-average programmers. Many were newbies in the language, and some were newbies to programming. And you're going to get to try to maintain this code. Now, do you want it to be written in a restrictive language, or in one that gives developers the ultimate amount of fr…
Surely in one that gives developers the ultimate amount of freedom.
I have seen enough C and Java code to see how creative developers and architects get to workaround the limitations of a restrictive language.
A convoluted code base full of design patterns, indirection layers, DSL and UI tooling for code generation, libraries to simulate language features.
Re: Lisp at the Frontier of Computation [video]
#88Earlier quoted context omitted.
maybe someone can help me understand. I now get homoiconisity but the example he uses doesn't seem to explain why the macro is needed. He explains a problem that can be solved by writing a function. Instead he presents what seems to be in effect an unevaluated function... so what's the point?
I agree that the macro example is not chosen well. Macros are just functions that take their arguments unevaluated and output code, so each macro call could be replaced by a function call where the arguments are wrapped in a list and the function executes the code directly instead of generating it. Then the only reason you'd have to use macros is if you want to do something at compile time. Like generating specialize…
But as the article states, compile time is (or can be) at runtime.. so it's a bit difficult for me to wrap my head around its practical effect :)
Re: Lisp at the Frontier of Computation [video]
#89Earlier quoted context omitted.
Do you like Python? Python is basically simplified Lisp. Common Lisp is Python plus first-class lexical closures (rather than second-class) plus true multithreading plus a real compiler so it runs much faster. Plus parentheses rather than indentation to delimit expressions; parentheses are much more versatile once you get used to them.
> Do you like Python? Python is basically simplified Lisp. Common Lisp is Python I am very experienced and proficient with Python. Common Lisp goes way, way beyond what Python brings to the table. Take CLOS for example and compare it with Python's OOP facilities. CLOS is light years ahead. Another differences (among many): Python is a high-level language. In CL, you can be high level and low level at the same time. F…
The sad part is that Ruby and Python could have taken some lessons from Lisp, how to have a dynamic language that has a good toolchain to generate native code.
Thankfully we have now Julia, as yet another Algol-Lisp attempt.
Re: Lisp at the Frontier of Computation [video]
#90Earlier quoted context omitted.
Do you like Python? Python is basically simplified Lisp. Common Lisp is Python plus first-class lexical closures (rather than second-class) plus true multithreading plus a real compiler so it runs much faster. Plus parentheses rather than indentation to delimit expressions; parentheses are much more versatile once you get used to them.
Python is in no way a Lisp. Python is not homoiconic, does not have first-class identifiers (symbols), and does not have full support for dynamically loading code ( https://news.ycombinator.com/item?id=14666300 ). All that makes Python much closer to BASIC than to other dynamic programming languages. I think of Python as a BASIC with an object system and a couple of incorrectly borrowed ideas from Scheme (lexical sco…
Well, the comparison by Peter Norvig makes Python and Lisp look pretty similar (https://norvig.com/python-lisp.html, also linked below in this thread).
In some cases, you can get around no-first-class-identifiers in Python by using strings and getattr(object, symbol) or locals()[symbol]. (What are other use cases of first-class identifiers, other than making some function arguments or macros look prettier?)