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

121–130 of 143 posts

Re: Lisp at the Frontier of Computation [video]

#121

Post by rcarmo »

sillysaurus3 wrote: post #96
rcarmo wrote: post #93

Earlier quoted context omitted.

Lumen seems interesting, but at a quick glance the GitHub repo has zero information as to how to install it and getting it to run. Is it an npm package/lua rock as well? (edit: it's all in the repo.) Follow-up: I don't see much in the way of interop documentation... Pointers?

The cool thing is, there's no interop. It's literally JS or Lua. Think of it like CoffeeScript -- there's no "interop" between CoffeeScript and JS. It's just JS. You can see what each expression compiles to by passing it through (print (compile (expand ...))) For example: > ((require 'leftpad) "foo" 5) "00foo" > (print (compile (expand '((require 'leftpad) "foo" 5)))) require("leftpad")("foo", 5) And of course, you c…

By interop I mean how to interact with existing functions (fine, most of the above covers that) and syntax for accessing data structures (arrays, tables, etc.).

Re: Lisp at the Frontier of Computation [video]

#123

Post by kgwgk »

pjmlp wrote: post #89
flavio81 wrote: post #47

Earlier quoted context omitted.

> 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.

The “lispy” aspect of Julia is somewhat disappointing, macros do not fit naturally with the non-lisp syntax of the language.

Re: Lisp at the Frontier of Computation [video]

#124

Post by Chattered »

yorwba wrote: post #79
geokon wrote: post #62

Earlier 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…

Macro examples are often poor, and my advice is to always favour functions, since then you are working with actual values. For instance, with-open-file should be a higher order function, not a macro as it is in CL.

That leaves a few other uses: macros as compiler extensions for generating fast code (see "Paradigms in Common LISP" for a lovely example of a parser generator). But heed warnings about premature optimisation.

It leaves macros for novel binding strategies. List comprehensions, do-notation, destructuring-bind, pattern matching, CL's LOOP and macros that anonymously bind a pronoun like "it".

I have no shame in using macros for really succinct control structures where delaying evaluation with a lambda would just look gross (see "or" and "and" macros), but maybe that's just a cry for lazy evaluation :P

Re: Lisp at the Frontier of Computation [video]

#125

Post by taeric »

pjmlp wrote: post #116
taeric wrote: post #106

Earlier quoted context omitted.

60 or so years ago, many of the main tricks of functional programming today were far too expensive in terms of memory to actually be used. So, I find this claim somewhat hard to take at face value. More, early lisps were far more up front about their imperative abstractions. Something that we try our damnedest to hide from folks nowadays. In ways that are actually hard to fully explain. Used to, you were given an arr…

Not really, the way Lisp abstracts the hardware is what made projects like Thinking Machines in 1985, with StarLisp possible. So it might not be 60 years ago, but 40 is already quite some years.

What are you saying "not really" to? I wasn't claiming that lisp didn't allow you to use hardware.

Rather, I was claiming that most of the hallmarks of functional code in today's programs wasn't possible in older hardware. Specifically, many of the "functional data structures" that people are growing to love nowadays were decidedly not possible on so little memory.

Re: Lisp at the Frontier of Computation [video]

#126

Post by agumonkey »

kbp wrote: post #111
agumonkey wrote: post #109

Earlier quoted context omitted.

In non lisp languages, the mutable array often came without map / filter, weren't generic, didn't have lambdas so you end up writing imperative loops and potentially mutating elements in place because it's tempting; changing the paradigm right away

> In non lisp languages, the mutable array often came without map / filter What languages do you know that have map and filter for lists, but not for arrays? Lisp has them for both, C++ has them for both, Java has them for both; Java didn't used to have lambdas or map, but it had standard lists long before it got either of them. Several decades before Java existed, Lisp had mutable arrays with map and filter. Support…

I'm not criticizing lisp at all here. And Java had lists but no functional API on top of it. Processing ArrayLists is extremely different from (mapcar #'f '(....)), in idiom, paradigm. You can, but you'll have to do anonymous inner classes gymnastics and you'll end up writing loops before you know it. And my point is: it sucks.

Re: Lisp at the Frontier of Computation [video]

#127

Post by throwaway7645 »

baldfat wrote: post #64
xstartup wrote: post #30

Earlier quoted context omitted.

What's the most popular Lisp in use today? Does it come with a static compile type checking?

Racket is the best Lisp to learn for a few reasons: 1. It was designed to be a teaching language 2. Everything included. You get a great simple IDE and a ton of packages 3. Great teaching materials (I learned the most from HTDP than any other programming book and I have read a ton) a) How to Design Programs http://www.ccs.neu.edu/home/matthias/HtDP2e/ b) http://realmofracket.com/ . Great book I learned a ton and espe…

Racket isn't near as fast as SBCL though. However, now that Chez Scheme is open source, Racket is in the process of leveraging that run time. Also I don't know, but would guess deployment is easier with SBCL as it can build a standalone executable (albeit it is very large due to saving the running image).

Re: Lisp at the Frontier of Computation [video]

#128

Post by throwaway7645 »

cube2222 wrote: post #92
flavio81 wrote: post #52

Earlier quoted context omitted.

> What's the most popular Lisp in use today? At least if based in 2016 GitHub popularity: http://sogrady-media.redmonk.com/sogrady/files/2016/07/lang.... #1 Emacs Lisp #2 Common Lisp #3 Scheme #4 Racket Unless you consider Clojure a Lisp (yes it is, and no, it isn't...), in which case #1 would be Clojure, and then the others listed above.

Why would clojure not be considered a lisp? (I'm curious)

There's a website article called "Clojure Sucks" that is written by a Common Lisp user who uses a symbolics lisp machine and has some interesting insight although it is very aggressive.

Re: Lisp at the Frontier of Computation [video]

#129

Post by aag »

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…

Videographer here. Amateur videographer, that is.

I apologize for the sound quality. I'm still learning how to do this stuff, and one thing I forgot to check is whether the final audio sounded good in headphones. On my laptop's speakers, I couldn't hear that there was only one channel. Checking that is now in my post-production checklist.

Unfortunately, while the lapel microphone I use normally produces good sound, I needed to do some level setting first. That's also in my checklist now. And I didn't expect the amplifier's sound to be picked up so strongly by the lapel mic. That may be something I'll have to solve using equipment.

I promise that I'm working on getting better at this.

Many thanks to Philip Greenspun, of Greenspun's Tenth Rule [1], for giving me the video camera that I've been using.

By the way, this talk was co-hosted the Bay Area Lisp & Scheme Users Group, [2], of which I'm co-organizer. You can see videos of prior BALISP talks at [3]. If you're in the area, please join us. We encourage you to give a five-minute lightning talk on anything interesting you've been working on that is related to Lisp.

Thank you so much to Robert Smith and Rigetti for giving and hosting such a terrific talk.

[1] https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule

[2] http://balisp.org/

[3] http://balisp.org/videos

Re: Lisp at the Frontier of Computation [video]

#130

Post by reikonomusha »

throwaway7645 wrote: post #127
baldfat wrote: post #64

Earlier quoted context omitted.

Racket is the best Lisp to learn for a few reasons: 1. It was designed to be a teaching language 2. Everything included. You get a great simple IDE and a ton of packages 3. Great teaching materials (I learned the most from HTDP than any other programming book and I have read a ton) a) How to Design Programs http://www.ccs.neu.edu/home/matthias/HtDP2e/ b) http://realmofracket.com/ . Great book I learned a ton and espe…

Racket isn't near as fast as SBCL though. However, now that Chez Scheme is open source, Racket is in the process of leveraging that run time. Also I don't know, but would guess deployment is easier with SBCL as it can build a standalone executable (albeit it is very large due to saving the running image).

10-20 MB isn't large these days, especially when every iPhone app update is on the order of 60-200 MB.
Post reply on HN