Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Roots of Lisp (2001)

paulgraham.com

Post reply on HN
Print view View original

71–80 of 92 posts

Re: The Roots of Lisp (2001)

#71

Post by lispm »

iLemming wrote: post #69
lispm wrote: post #68

Earlier quoted context omitted.

You should stop oversellling things. Spec is not a type system.

Just because you can't do a rigorous static analysis (which to certain degree is possible, check out Spectrum) it doesn't mean that Spec is not a type system.

That's misleading. Spec is a contract system. Read the page on the spec rationale: https://clojure.org/about/spec . It even mentions that spec is not a type system and that spec is similar to contracts in Racket, etc.

If we look at programming languages like Java, Typescript, C++, Haskell, etc., then we see that their type systems are completely different and have an entirely different purpose. Claiming to those users that spec is a type system, is just misleading them.

Re: The Roots of Lisp (2001)

#72

Post by blackrock »

I get that Lisp is popular because of its meta-programming abilities, ie its macro system. And the reasoning was that you didn’t have to wait for the language writers to implement the feature you wanted, since you could implement it yourself as a macro.

But this presented other problems, namely that you might end up coding your libraries on an island, and no one else could understand your code. This is probably why Lisp is mostly more powerful when there is only one or a few programmers working on the code base.

But with the increase in other programming languages, and the massive amounts of other libraries out there, then is this macro system really all that necessary anymore?

Re: The Roots of Lisp (2001)

#73

Post by lispm »

tabtab wrote: post #57
lispm wrote: post #53

Earlier quoted context omitted.

> Lisp won't do this because it's then harder to blur/merge/change the distinction between code and data, which is the very power of Lisp. Though it has tried a bunch of times. > Some people have a certain kind of eye and/or brain that allows them to read Lisp quickly Could be that or that one just needs a bit of practice - as it is the case with many thing: riding a bike, driving a car, learning a foreign language,…

Re: Though [separating in Lisp] has tried a bunch of times. I haven't seen it done well. The attempts kind of end up with the worse of both worlds. Re: Could be that or that one just needs a bit of practice But the key is how much, and how long does it vary per individual. There is no solid research that I know of, so it's just opinion and anecdotes either way. I tried to get used to it and read it fast, but it just…

> Most Algol-derived languages use punctuation and symbols that seem to make them stand out better than words alone.

If we read a long novel, then we read mostly words without much visual structure. The only thing that guides us are occasional marks of sentences, paragraphs and chapters. Still many can read Lord of the Rings without much problem.

Lisp is slightly unusual, since the code is written as nested lists (trees). To make Lisp code readable there are a few things follow: speaking symbols, standardized code layout and familiar code structures. After a while the reader/writer of Lisp code will recognize the symbolic hints and the usual visual patterns of the layouted code.

> The top COBOLer can probably out-code an average Lisper I'd bet.

In terms of lines of code I would think that's true.

> It should be a curiosity why after 60 years it never caught on mainstream

Why should it be in the mainstream? Why should a programming language originally designed for certain types of meta-programming (remember: the symbolic computation and code as data ideas, which are central to Lisp) be especially popular among programmers and their customers?

> easier-to-read

Now you are shifting the goal. You originally claimed that functional code is hard to debug, because there are no variables you can inspect. But that's what we do in Lisp too: we use variables for that purpose.

Re: The Roots of Lisp (2001)

#74

Post by slifin »

blackrock wrote: post #72

I get that Lisp is popular because of its meta-programming abilities, ie its macro system. And the reasoning was that you didn’t have to wait for the language writers to implement the feature you wanted, since you could implement it yourself as a macro. But this presented other problems, namely that you might end up coding your libraries on an island, and no one else could understand your code. This is probably why L…

Clojure is a lisp that runs on top of Java, JavaScript and a couple of others and has access to all of those libraries via npm and maven

Having more libraries than most languages doesn't nullify the use of macros, macros are usually discouraged in application code because they don't compose well, don't make a macro if a function will do

However having macros meant that when go popularised CSP concurrency at the language level it meant we didn't need to change the language (for all variants of Clojure) it just meant we could make a library with macros to do CSP concurrency and it works on the browser on the server etc

Completely opt in, well documented as a library and we didn't weigh down the language with this feature, if or when the next big concurrency thing comes along we won't be looking to deprecate go channels from the language

Macros are incredibly powerful and you probably won't need them often but for those small cases of scratching a particular itch they're a get out of jail free card

Re: The Roots of Lisp (2001)

#75

Post by iLemming »

lispm wrote: post #71
iLemming wrote: post #69

Earlier quoted context omitted.

Just because you can't do a rigorous static analysis (which to certain degree is possible, check out Spectrum) it doesn't mean that Spec is not a type system.

That's misleading. Spec is a contract system. Read the page on the spec rationale: https://clojure.org/about/spec . It even mentions that spec is not a type system and that spec is similar to contracts in Racket, etc. If we look at programming languages like Java, Typescript, C++, Haskell, etc., then we see that their type systems are completely different and have an entirely different purpose. Claiming to those user…

Semantics. Spec is very close to dependent types. "Entirely different purpose" is kinda vague. If the end result is the correctness of the program, the purpose is the same. If someone can perform Vivaldi's Four Seasons on Ukelele, it's cool. It doesn't make Ukelele less of an instrument.

Re: The Roots of Lisp (2001)

#76

Post by lispm »

iLemming wrote: post #75
lispm wrote: post #71

Earlier quoted context omitted.

That's misleading. Spec is a contract system. Read the page on the spec rationale: https://clojure.org/about/spec . It even mentions that spec is not a type system and that spec is similar to contracts in Racket, etc. If we look at programming languages like Java, Typescript, C++, Haskell, etc., then we see that their type systems are completely different and have an entirely different purpose. Claiming to those user…

Semantics. Spec is very close to dependent types. "Entirely different purpose" is kinda vague. If the end result is the correctness of the program, the purpose is the same. If someone can perform Vivaldi's Four Seasons on Ukelele, it's cool. It doesn't make Ukelele less of an instrument.

So, spec is the ukulele in the vast domain of Type Systems?

Re: The Roots of Lisp (2001)

#77

Post by tabtab »

iLemming wrote: post #66
tabtab wrote: post #60

Earlier quoted context omitted.

Re: It takes time, for some it's hours, for others - weeks, but eventually you will stop seeing parentheses, and instead, you will see structure, consistency, and meaning. And Lisp becomes more readable than any other language you've used before. I'd like to see a university test this theory. I suspect it's subjective and varies greatly per individual, but testing on say 100 random subjects could better resolve the G…

Of course, it's subjective. Do you think everyone is born with an innate ability to read Javascript? I don't know anything about music, but I feel this debate is like guitar tabs vs. standard music notation. I've heard, for example, that Paul McCartney doesn't know how to read music notation. "Yesterday" is still a masterpiece, though. Now imagine if Paul all his life advocated young musicians against musical notatio…

I didn't say get rid of Lisp. It's indeed a great teaching tool. What I'm against is the implication that if one doesn't like it or use for production systems, they're doing something wrong or bad.

Re: The Roots of Lisp (2001)

#78

Post by tabtab »

iLemming wrote: post #65
tabtab wrote: post #59

Earlier quoted context omitted.

I personally admire Lisp conceptually . It's a work of art. It's the practical use as tool in a team environment that you cannot carefully control hiring is where I have skepticism.

I've started using Clojure a few years ago as my primary language of choice. I switched multiple jobs since then. I never had a problem with finding one. I worked once for a big fin-tech company. We never said that knowing Clojure was a requirement, but we admitted that the preference would be given to people at least interested in Clojure. And you know what? It helped us to build an incredibly strong team. Even thou…

Re: If I were given a choice to either hire five Javascript/Python/Go programmers and pay them each 100K/Y or hire only three Lispers and pay them each 200K/Y, I would go for the latter. ROI, in that case, would be much, much higher.

If that were universally true, one could out-compete the entrenched software companies and be the next Bill Gates. The common "production" languages are successful I believe because they offer a semi-consistent way to doing things, and for large or fungible staff, that turns out more important than less lines-of-code or powerful abstractions.

In business, communicating between humans is more important than parsimony. This is based on direct and indirect experience. My own "grand abstractions" have been rejected also at times. The "best" programmers are often those who have a decent understanding of the domain, UI design, and various "team" skills. Somebody good in all those may not necessary be the best abstractionist or parsimonist. The best programmers get B's on lots of topics rather than an A+ in just one, such as abstraction. I'm just the messenger. Scott Adams made a similar observation:

https://www.forbes.com/sites/carminegallo/2013/10/23/dilbert...

Re: The Roots of Lisp (2001)

#79

Post by tabtab »

mquander wrote: post #44
tabtab wrote: post #34

Earlier quoted context omitted.

Early Microsoft tended to clone or buy successful products. They were not really into core R&D, only improvement R&D. They let others be the guinea pigs. Gates was a skilled poker player, which probably helped him be a shrewd business-person. When all was said and done, you would realize he walked away with all your best cards.

Gates was a skilled poker player, which probably helped him be a shrewd business-person. When all was said and done, you would realize he walked away with all your best cards. That doesn't happen in poker.

Insert better card-game metaphor here.

Re: The Roots of Lisp (2001)

#80

Post by iLemming »

tabtab wrote: post #78
iLemming wrote: post #65

Earlier quoted context omitted.

I've started using Clojure a few years ago as my primary language of choice. I switched multiple jobs since then. I never had a problem with finding one. I worked once for a big fin-tech company. We never said that knowing Clojure was a requirement, but we admitted that the preference would be given to people at least interested in Clojure. And you know what? It helped us to build an incredibly strong team. Even thou…

Re: If I were given a choice to either hire five Javascript/Python/Go programmers and pay them each 100K/Y or hire only three Lispers and pay them each 200K/Y, I would go for the latter. ROI, in that case, would be much, much higher. If that were universally true, one could out-compete the entrenched software companies and be the next Bill Gates. The common "production" languages are successful I believe because they…

> if that were universally true, one could out-compete the entrenched software companies

What makes a software product a successful product? Would you agree that popularity and sold copies do not necessarily make it the right product? There's a lot of marketing goes into success, and I admit - sound engineering often lacks good marketing.

What you can't see behind your clouded judgment that despite being non-mainstream tech, Clojure (I can only speak for Clojure since that's my primary language, I've been using for the past few years) has been quite successful.

- It is consistently being rated as the top paid language (alongside with F#) in numerous surveys (e.g., Stackoverflow and StateOfJS)

- The community has fewer active members than the number of programmers working for Google, but they are continually innovating. They are figuring out interop with Python and R, writing machine learning libraries and books about it, they are running Clojure-like Lisp dialect on BEAM, Clojure-like Lisp that compiles to Lua, researching type-systems, running Clojure on embedded devices, etc.

- Clojure teams at companies like Walmart and Apple processing massive amounts of data. Can you imagine the amount of data Walmart has to deal with on Black Fridays? Do you know how many people they have in the team that has built the pipeline for processing receipts? Seven. For comparison, React team at Facebook has more developers, and they also get massive help from it being open-source. I don't want to belittle the work they do; managing a massively popular UI library is not a simple task either. I just brought it here for the lack of better examples.

- Jira, incredibly popular and sometimes vehemently hated by programmers. Please take a look at its less popular competitive Clubhouse.io. It's beautiful, clean, and nothing but a fantastic product. I believe they've built it with a team of fewer than ten developers. And there are many examples like that: CircleCI, Grammarly, Pandora and many, many more.

I agree with what you say:

> The "best" programmers are often those who have a decent understanding of the domain, UI design, and various "team" skills.

That's why (after many years programming in other languages) I chose Clojure. It allows me to stay laser-focused on solving real problems. Like creator of Clojure once said: "solve real-world problems, not puzzles."

Post reply on HN