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

Lisp at the Frontier of Computation [video]

youtube.com

Post reply on HN
Print view View original

41–50 of 143 posts

Re: Lisp at the Frontier of Computation [video]

#41

Post by sillysaurus3 »

xstartup wrote: post #30
patkai wrote: post #23

Code 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?

Rather than most popular, I propose using the most useful.

That'd be Lumen.

http://github.com/sctb/lumen

It's the only lisp that can interface seamlessly with any JS library you want. Just `npm i leftpad && LUMEN_HOST=node lumen` and type `(require 'leftpad)`.

  $ npm i leftpad
  $ LUMEN_HOST=node lumen
  > (require 'leftpad)
  function
  > ((require 'leftpad) "foo" 5) 
  "00foo"
Other lisps are nice, but they all try to build their own ecosystems instead of use existing infrastructure. So if you want to do webdev and run into a problem with the library, your only option is to fix it yourself or write your own, since most people don't use lisp for webdev.

That brings us to Clojure: the prima facie "lisp for webdev". It's a good lisp, but it forces you into non-optional immutability. That's a feature for some and a burden for others. And it's very difficult to transpile into JS. In an era where size and speed matter due to bandwidth concerns, this is a severe limitation.

That said, all of the lisps are a delight to use in their own way. Racket is fun to wrestle with, mostly to coerce it into doing what you want. SBCL is neat for doing archeology in -- you can run all kinds of interesting old programs. Elisp is fun because you can extend your editor to do anything you can imagine. Arc powers the website you're reading this on, and its underlying ideas are worth internalizing.

Re: Lisp at the Frontier of Computation [video]

#42

Post by willismichael »

tunesmith wrote: post #29
flavio81 wrote: post #16

Earlier quoted context omitted.

It is one of the very few languages where the source code is made of a data structure that the language is very good at manipulating. Thus, writing code that generates code, be it at runtime or at compile-time, is downright easy in Lisp. This opens up enormous possibilities not found in other languages. Also, on regular programming languages, your code executes only at run time. In Lisp, or at least in Common Lisp (a…

The problem for me is that I've learned to avoid macros in other languages. It seems to me that when you've got a fairly complex program, you need a fairly complex mental model of what the program "is" to understand it. But if you introduce macros, or code writing code, then you have a much more complex mental model since now even what the code "is" can change. What is it about lisp that makes this an easier sell?

It is true that even in a Lisp, unfettered use of macros can result in write-only code, so you do have to be careful about what kind of cognitive burden you are imposing upon people who will have to read your code.

With that said, I tried to learn about metaprogramming in a number of other languages, and Lisp is the first one with a metaprogramming model that I could actually grok, because the meta-language is equivilant to the language itself. Lisp macros are more or less just plain old code that manipulates data structures.

When I'm working on a lisp project, I give myself a budget of a very small number (often just 1 or 2) of magic macros that I can build for it. Other than that, I only use macros in the core library, or well-known third party libraries that other people are likely to be familiar with.

Re: Lisp at the Frontier of Computation [video]

#43

Post by gnufx »

flavio81 wrote: post #19
defenestration wrote: post #12

Earlier quoted context omitted.

I enjoyed learning Clojure by doing the exercises at http://www.4clojure.com/ . I documented my progress and learned a lot from solutions of others.

Note that Clojure is not really a Lisp dialect, so you will need a different tutorial if you want to try a Lisp like Scheme, Common Lisp, Racket, TXR Lisp, etc.

How is Hickey wrong about that?

Re: Lisp at the Frontier of Computation [video]

#44

Post by flavio81 »

tunesmith wrote: post #29
flavio81 wrote: post #16

Earlier quoted context omitted.

It is one of the very few languages where the source code is made of a data structure that the language is very good at manipulating. Thus, writing code that generates code, be it at runtime or at compile-time, is downright easy in Lisp. This opens up enormous possibilities not found in other languages. Also, on regular programming languages, your code executes only at run time. In Lisp, or at least in Common Lisp (a…

The problem for me is that I've learned to avoid macros in other languages. It seems to me that when you've got a fairly complex program, you need a fairly complex mental model of what the program "is" to understand it. But if you introduce macros, or code writing code, then you have a much more complex mental model since now even what the code "is" can change. What is it about lisp that makes this an easier sell?

>The problem for me is that I've learned to avoid macros in other languages.

Macros in other languages are significntly unlike Lisp macros. You should take a look at the Practical Common Lisp book (available for free online) to have an idea on how you can easily leverage Lisp macros for more readable, succint, easy to understand code.

>But if you introduce macros, or code writing code, then you have a much more complex mental model

In Lisp, you use the different tools available (macros, CLOS, readtables, etc) to achieve a simpler translation between the problem domain and your actual source code.

If you are using them to create more convoluted, harder-to-understand code, then "you're doing it wrong", just as you can, for example, write rather clean C code versus code that would win the IOCCC (International Obfuscated C Code Competition).

Re: Lisp at the Frontier of Computation [video]

#45

Post by nerpderp83 »

agumonkey wrote: post #13
taeric wrote: post #10

This was a much more enjoyable video than I was expecting. The audio quality really had me tempted to skip, so I encourage others to not let that turn them away. The quote which I will paraphrase that "lisp is not freed from having to justify why you would use it." This is huge and the section before it going off about how condescension is a terrible enemy of the language is one that I would hope more people contempl…

I unplug my headphones jack halfway to turn failing stereo into good enough bi-mono.

Some please make an ML/Dsp powered magical audio fixer for system sound.

Re: Lisp at the Frontier of Computation [video]

#46

Post by jimbokun »

icholy wrote: post #36
patkai wrote: post #23

Code as data is such a big deal that - whatever you say - I will never ever understand why we don't all do Lisps.

5 years ago I was in the same boat. Now I'm in love with Go .. funny how things turn out ¯\_(ツ)_/¯

What changed?

Re: Lisp at the Frontier of Computation [video]

#47

Post by flavio81 »

dreamcompiler wrote: post #34
nafizh wrote: post #7

Every time, I see one of these links or videos, I feel the urge to learn Lisp. But after some time, I lose the motivation. I think that is because I don't know what benefit learning lisp will provide me concretely. Anyone has any suggestion?

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. For example, in CL you can disassemble your code to machine language and apply optimization directives and declarations to produce the shortest code, which can approach C speeds if done right.

That said, I still like Python a lot.

>Python is basically simplified Lisp.

... and I thank you for this phrase, perhaps I can use it whenever I need to justify my usage of Common Lisp at my workplace.

Re: Lisp at the Frontier of Computation [video]

#48

Post by flavio81 »

gnufx wrote: post #43
flavio81 wrote: post #19

Earlier quoted context omitted.

Note that Clojure is not really a Lisp dialect, so you will need a different tutorial if you want to try a Lisp like Scheme, Common Lisp, Racket, TXR Lisp, etc.

How is Hickey wrong about that?

I am not saying that Hickey is "wrong".

Clojure simply differs too much from the Lisp languages. For example take into account the "atom" keyword and its meaning in Lisp versus Clojure. And also the way lists are used in Clojure, see "cons" for example.

These are not frivolous differences -- atoms and conses are the key building blocks of the Lisp language!

Re: Lisp at the Frontier of Computation [video]

#49

Post by AnimalMuppet »

zardo wrote: post #22
flavio81 wrote: post #18

Earlier 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. Me too. I don't understand how people in HN vouch for restrictive languages.

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 freedom?

Post reply on HN