15 ms·

Ooh Ooh My Turn Why Lisp? (2008)

99 points by bootload 10y ago

asimuvPR 10y ago
The post linked has another interesting post in the comments: http://www.defmacro.de/?p=13 http://www.defmacro.de/?p=13 . Its about an interview McCarthy gave in the year 2000 to infoQ.
catnaroek 10y ago
> object identity for everything but numbers and characters Since when is this supposed to be a selling point? Not having compound values (not the same thing as compound objects!) is a pain.
- oconnore 10y ago
  You seem to be very confused. This is referring to #'eq (which is why #'eql exists). What lack of compound values are you lamenting? Lisp has built in classes, structs, arrays, lists, and maps. What is missing? > An implementation is permitted to make ``copies'' of characters and numbers at any time. The effect is that Common Lisp makes no guarantee that eq is true even when both its arguments are ``the same thing'' if that thing is a character or number. http://www.lispworks.com/documentation/HyperSpec/Body/f_eq.htm#eq http://www.lispworks.com/documentation/HyperSpec/Body/f_eq.h...
  - catnaroek 10y ago
    > Lisp has built in classes Objects aren't compound values. Objects are compound, well, objects. And pointers to objects are primitive, indivisible values - not compound! > lists Racket and ML have lists. Lisp has mutable linked data structures, built out of `cons` cells, whose value at any given point in time may be a list. But the value itself isn't first-class, because you can only bind the identity of the cons cell to a variable.
    - oconnore 10y ago
      Contiguous memory structs: http://www.lispworks.com/documentation/HyperSpec/Body/m_defstr.htm http://www.lispworks.com/documentation/HyperSpec/Body/m_defs... Contiguous memory vectors (multi-dimensional arrays, too!): http://www.lispworks.com/documentation/HyperSpec/Body/t_smp_ve.htm http://www.lispworks.com/documentation/HyperSpec/Body/t_smp_... Native hash tables: http://www.lispworks.com/documentation/HyperSpec/Body/f_mk_has.htm http://www.lispworks.com/documentation/HyperSpec/Body/f_mk_h...
      - catnaroek 10y ago
        > Contiguous memory I wasn't talking about the memory representation of anything. A first-class value is something that a variable may denote. In ML, if the variable `xs` denotes the list `[1,2,3]` within a given environment, it will always do so. In Lisp, I can mutate the cons cells out of which `(list 1 2 3)` is built, so what is actually bound to the variable is the object identity of the first `cons` cell. Not a list value!
        oconnore 10y ago
        Oh. You have a strange way of phrasing your critiques, but you're right, it's all in IO/IORef.
        catnaroek 10y ago
        I wanted to formulate my observation in very general terms, rather than mention specific facilities of other programming languages. I also wanted to avoid suggesting a connection with static types or effect segregation. The main benefit of values over objects is that using values leads to designs that have less moving parts, and thus are easier to understand, modify, extend and test.
einhverfr 10y ago
It's a nice perspective. Very practical and down to earth. There is another side though, and that is that learning to think of code as data is extremely empowering and translates well when working with a fairly large set of other languages (Perl, Python, Ruby, and now even Java). Learning Lisp turns you into a better programmer.
- agentgt 10y ago
  I like Scheme/Lisp but I don't know if I buy the whole "learning Lisp turns you into a better programmer". Maybe more knowledgeable but not necessarily a better a developer. In some ways learning a really flexible language like Lisp can turn you even into a really bad developer. I say "developer" instead of "programer" because I want to emphasize working with others and thus sharing code with others. Of course this is based on some past observations working with MIT grads and various other academia so take my opinion with a grain of salt. IMO the language that really changed everything for me was the ML family of languages and maybe C. I would say knowing C and ML is more worthwhile than Lisp (Lisp is not exactly hard to learn anyway... the basics that is).
  - ohyes 10y ago
    I'm biased, but there's a big difference between "learning lisp" (well enough to transliterate that python program) and really getting the code as data concept. I'd say that learning X really well is always a positive because whenever you learn something in depth you can then apply the concepts elsewhere. And there are still lisp-only concepts, so learning lisp is positive. ML is good too. Also spending time with a well designed concurrent language is beneficial.
    - agentgt 10y ago
      With Lisp I get the data thing but with ML you learn almost everything is a language. I can't really explain it but the whole variant/ADT pattern matching really forces to make you think of your problem domain as a specification or language (e.g. DSL). It is one of the reason why I think so many compilers are written in ML (that and the toolset is awesome for it).
cheez 10y ago
Did Kenny ever release his educational software?
- tsuru 10y ago
  It appears so, yes: http://tiltonsalgebra.com/# http://tiltonsalgebra.com/#
  - cheez 10y ago
    This is amazing. Kenny, please fix the fonts.
mark_l_watson 10y ago
Classic Kenny! Common Lisp used to be much of my programming world also.
platz 10y ago
> most Common Lisp implementations are native compiled. ... isn't it nice to compile down to the metal? Is just the interpreter native or does cl compile your app to native as well?
- pmalynin 10y ago
  SBCL compiles to native. In fact thats how you check if the function was tail-optimized -- it will have a JMP opcode instead of CALL
  - ohyes 10y ago
    To add to this, Most of them compile to native. I think the exception is CLISP. Certain implementations have both because compiling was costly at one point.
- snaky 10y ago
  To native with elegance [1] and even closer to the metal "because sometimes C abstracts away too much" [2]. [1] https://www.pvk.ca/Blog/2014/08/16/how-to-define-new-intrinsics-in-sbcl/ https://www.pvk.ca/Blog/2014/08/16/how-to-define-new-intrins... [2] http://www.pvk.ca/Blog/2014/03/15/sbcl-the-ultimate-assembly-code-breadboard/ http://www.pvk.ca/Blog/2014/03/15/sbcl-the-ultimate-assembly...
deleted 10y ago
[deleted]
oconnor663 10y ago
> he simply asked if Python could gracefully manipulate Python code as data Have there been any big LISP macro code injection vulnerabilities in the wild?
- kiiski 10y ago
  What do you mean with "macro code injection vulnerabilities"? Macros are expanded before the code is compiled; by the time someone is running the program there are no macros. Well, technically, someone could call `EVAL` in a production app, but that's strongly discouraged.
- Johnny_Brahms 10y ago
  As the other comment says, that doesn't really make sense. However, I have had to debug a codebase where lisps unhygienic macros led to extremely weird errors. The second time that happened in a big project I decided that schemes hygienic macros are superior. The extra cruft writing them is worth it. I have literally spent weeks debugging weird macro errors introduced years after the macro was first written.
  - wtbob 10y ago
    You're not wrong: simple macros can be written poorly. Macros which don't properly use GENSYM should be rejected in review. Also, it's entirely possible to write a hygienic macro implementation with DEFMACRO: nothing stops a team from doing that (or using one off-the-shelf). But sometimes you do need the full power of DEFMACRO, and it's not possible to write DEFMACRO with DEFINE-SYNTAX. So one tool enables you to do anything you need, and the other only some of what you need. I know what I prefer.
    - Johnny_Brahms 10y ago
      Let's agree to agree then :) I much prefer Racket's macros. Their version of syntax-case is a bit simplified compared to the one shipped with other schemes like guile and chez. If you want to see where you can go by (ab)using racket macros, watch this: https://www.youtube.com/watch?v=WQGh_NemRy4 https://www.youtube.com/watch?v=WQGh_NemRy4
krupan 10y ago
"The question is where will we be in five years, the answer is using Common Lisp, because of language features" says the author in the comments. This was 8 years ago. Kind of rude of me to take that potshot, but it's there. I've been reading these "Why Lisp?" Arguments for years and yet it still remains pretty niche. The longer this goes on the more I am unable tell Lisp advocates apart from Perl advocates. They both sound like write-only languages. They make a lone programmer feel very productive and Free, but it results in essentially unmaintainable code. I've written and attempted to maintain much more Perl than Lisp, many years ago, so please tell me if I'm wrong.
- meric 10y ago
  I'm developing a language that's a superset of Lua and Lisp. It's still in its infancy, but here's an example of a Lisp/Lua function in a module that can be imported as a (+...) macro that expands into Lua `a + b + c + ...` expression. https://github.com/meric/l2l/blob/rewrite/l2l/macro/arithmetic.lisp https://github.com/meric/l2l/blob/rewrite/l2l/macro/arithmet... The idea is programmers will write in Lua whenever readability is prioritised, and when homoiconicity is required, for example in the use of domain specific languages, lisp can be switched to. The lisp part can be used to produce macros that expand into Lua. Would be great to know your thoughts!
  - zvrba 10y ago
    You know about metalua, right? http://metalua.luaforge.net/ http://metalua.luaforge.net/
    - meric 10y ago
      Yes, I wanted a version of Lua with Macro's that reused familiar syntax (for lispers), that can run on LuaJIT, and is implemented in Lua completely.
      - groovy2shoes 10y ago
        https://github.com/baguette/lemma https://github.com/baguette/lemma I've unfortunately let it languish for the last few years, but I'm about to pick back up a bit for the 2016 Lisp Summer Game Jam. I've got a handful of big, backward-compat-breaking changes in the queue, but it should start to stabilize again within a couple of weeks.
unpop-opinion 10y ago
Okay, I've spent a lot of time writing Common Lisp and even more time reading about Common Lisp, and to be honest, I'm just a little tired of the cult around it. People who know it well gloat about how great Common Lisp is, which just so happens to make them look great too. And people who don't know Common Lisp all talk about the little Common Lisp they know, because they don't want to seem like they aren't in on it, and because they don't know better. Let's talk about this fabled exchange between Norvig and McCarthy, where McCarthy asks if Python can gracefully manipulate code as data, and Norvig said no, and supposedly a thousand words were said in the ensuing silence. Here's the thing; a thousand words weren't said. I don’t know what Tilton thinks was said there, but it certainly wasn’t a one sided silence in which only McCarthy’s side gets to smugly smirk as if it proves anything. Let’s talk about code as data, shall we? What enables that? Of course, it’s the s-expressions and prefix notation. So let’s write a macro. But we won’t want to write a macro that simply sits at the beginning of an s-expression and takes in a bunch of arguments, because then we could just write a function. No, we want to do a transformation on the code that creates a domain-specific language, because that’s the power of macros, right? So the very first thing you do with your macro powers, and pretty much the only useful thing you can do, is break s-expressions. Once the first macro is written you can no longer assume that inputs to macros will be s-expressions with the function at the beginning and arguments following. Every future macro must account for every previous macro. The more you use the capability to manipulate code as data gracefully, the less graceful it becomes. And, in my opinion, far more damningly, macros make your program harder to reason about. Before macros, a reader could assume that the first thing in the s-expression was operating on everything else in the s-expression. But no longer. We can’t even assume that sub-s-expressions in the s-expression are evaluated first. This isn’t a hypothetical problem. Common Lisp programmers spend a ton of time talking about how to write macros so that they’re not going to come back and bite you in the butt when they get used in an unexpected situation. And the reason is, nobody really knows how to do it. So, with a great deal of respect for McCarthy based on his many other achievements, I have to say I don’t care about macros, and actually think we’re better off without them. First-class functions are a much more coherent, consumable way of using code-as-data. Most of the features of Common Lisp I actually want are in other languages now. Garbage collection? REPLs? First-class functions? Higher-order functions? They’re all in other languages now. Python, for example has all those things. And to be honest, other languages have done a lot better things with the functional programming aspects of Common Lisp. McCarthy gets credit for inventing a lot of stuff, but we don’t fly Wright-brothers style planes today and we shouldn’t use Common Lisp just because it was first to have those things. More sophisticated type systems make lambdas more powerful (and incidentally, a lot of the problems with macros can be seen as type problems). People on this thread are claiming, “Learning Common Lisp turns you into a better programmer”. But I tend to think that learning functional programming is the part that people are referring to, and frankly, there are better languages in which to learn functional programming. Haskell, Standard ML, or OCaml would be a better choice. And sure, there are other features that only Common Lisp has, but nobody is talking about those. Restarts? I’d love to see more people experimenting with those. Then again, Erlang has a way better threading model than anything else and much more sophisticated pattern matching. Scheme has call/cc. Standard ML has a powerful type system. Haskell has functional purity. Prolog has unification. A great many of these are more interesting than restarts. I don’t hate Common Lisp; if nothing else, Common Lisp has a few very solid implementations out there and lots of existing libraries that make it a very useful tool. There are some programs which I wouldn’t consider writing in another language. I just don’t really think it’s the be-all and end-all of programming languages any more, and I’m kind of tired of the cult that has formed around it. EDIT: s/Lisp/Common Lisp/g because not everyone takes “Lisp” to just mean “Common Lisp”.
hahooooo 10y ago
Is there any advantage in using a functional language when programming non-mathematically related code? I see how it can help write Neural Networks, AI, financial code, etc. But if you know Python,Ruby,PHP,Java and Lisp (well), why would you choose to write a blog, webstore, webmail client or social media* app (which probably is about 90% of what people actually do) in Lisp over the four three? I'll tell you why I would chose the first four: 1. Large community. 2. Many more libraries. 3. Easier to hire. *Except for (perhaps) a small spam-block/feed ai module
- nv-vn 10y ago
  Yes. Functional programming (although it isn't necessarily a trait of Lisp) has, in fact, little relation to math (despite what many people believe). It's also very far removed from the field of AI right now (not for any particular reason, but there's no more specific reason to switch to Lisp for AI than there is for desktop or web apps). The reason you'd use Lisp is quite simple -- it saves time and makes programming easier. Macros are the biggest time saver in the world, and you don't realize how much time you waste writing repetitive code until you get to use them. As for your 3 reasons in favor of the other languages, I think the first means almost nothing at all. Lisp is much easier (once you grasp it) than many other languages, so I think the fact that you'll get less answers on StackOverflow is irrelevant. As for the second reason, as long as you have one library that works for what you want -- say some library for writing web servers -- it doesn't really matter after that. There's rarely any reason to reinvent the wheel here, and there's always someone that attempted such a common task before you. Just because you don't have 3,000 different choices like in Java, doesn't mean that you won't find high-quality code for what you need to do (in fact, I'd argue that Lisp code has a much higer quality on average than Java code). As for hiring, I think Paul Graham has already given the best comments on this. Simply put, a good programmer can be taught to write good Lisp, even if they don't know it by the time you hire them.
- GlennS 10y ago
  I'd say web's request -> response model is pretty well suited to functional programming. It seems popular amongst JavaScript programmers at the moment as well. React, which appears the current hotness, is based on making a functional interface to the DOM. Although actually, I'd say the main reason to use a Lisp for web gunk is the macros rather than the functional programming. The tree structure maps very naturally onto HTML generation. There are some really nice libraries (in particular I'm familiar with Clojure libraries) which make the server-side part of a web app really neat. You can basically skip the whole 'templating' bit.
nurettin 10y ago
For UI application programming You can do without FP language features. Hell, you can even do without smart pointers checked arrays or GC. But you cannot do without a decent desktop or web development experience. I got involved with pretty large desktop applications written in delphi. The design-time, the debugger, native compilation without having to install some msvc runtime, deriving and combining visual components, it just gives a smooth experience for desktop apps. If lisp has such well thought-out frameworks, I would jump ship just to get at the language features it offers.
- junke 10y ago
  Would you pay for it? http://www.lispworks.com/products/capi.html http://www.lispworks.com/products/capi.html
  - nurettin 10y ago
    I did buy frameworks for work, and this does look OK, but coding gui by hand is not something our developers can handle in large scales.
    - junke 10y ago
      It seems that there is an interface builder. http://www.lispworks.com/documentation/lcl50/clwug/clw-216.html http://www.lispworks.com/documentation/lcl50/clwug/clw-216.h...
      - mark_l_watson 10y ago
        CAPI is pretty nice. Years ago, LispWorks gave me free licenses in return for my doing some cleanup on their documentation. LispWorks is very good, but my licenses are for what is now a very old version, so I now use SBCL and sometimes Clozure. For industrial settings, LispWorks and also Franz are very good products. I used Franz products on a medical large data project several years ago, and their support was nothing short of amazing. That said, on the same project we had an issue with SBCL and we simply paid one of the maintainers to promptly fix the issue. Sometimes it just takes spending some money.
ww520 10y ago
I want to see people's list of reasons for why not lisp. Edit: Ok, this is not trolling. I quite liked Lisp and actually had implemented a version of common lisp from scratch based the Guy Steele's CL reference back in the undergrad time. I just found that beyond academic and a few Emacs packages, I didn't use Lisp at all, for one reason or the other. I just want to hear people's reason for not picking Lisp for their work.
- kqr 10y ago
  I dislike Lisp (and Lisp-inspired languages like Scheme and Clojure) for two reasons: 1. their weak and dynamic type system, and 2. they don't control side-effects.
  - happyslobro 10y ago
    Haskel programmers: you can spot them by that constant pained look, as if they have to step in horse poop whenever they go outside.
    - elbear 10y ago
      Why did you feel the need to deride someone for simply expressing their opinion? Do you think it helps the discussion?
      - happyslobro 10y ago
        I meant no disrespect. The horse poop outside was a metaphor for side effects. During my brief exploration of Haskell, I went to great lengths to avoid dealing with side effects, and when I couldn't avoid them, the pure functional solutions were pretty painful to learn.
        platz 10y ago
        > I meant no disrespect. I don't believe you.
hellofunk 10y ago
I'm of the opinion that there is only one lisp right now with some serious potential to dominate in the future, and that is Racket. Why? For one very simple reason: unlike all other lisps, there is serious, ongoing, and lengthy research into correctly bringing a static type-checking process to the language. Clojure's core.typed doesn't count here, as it is full of significant holes that invalidate its entire point -- though, those holes are very possibly getting filled in the coming years as they attempt to refactor core.typed following the Racket model. But the Racket team is doing something with lisp that is true to its core, not just with types, but with many other features as well. Interesting piece of trivia: this website you are reading right now is built on top of Racket.
- vertex-four 10y ago
  Isn't HN on Arc?
  - emidln 10y ago
    Arc runs on mzscheme which turned into Racket. The last official release of Arc requires an older release of mzscheme from before lists were immutable. There is a community-maintained fork called Anarki [1] that runs on modern Racket. [1] - http://arclanguage.github.io/ http://arclanguage.github.io/
- emidln 10y ago
  What makes the Racket model more correct than the system based in Sequent Calculus [1] provided by Shen? [1] - http://www.shenlanguage.org/learn-shen/types/types_sequent_calculus.html http://www.shenlanguage.org/learn-shen/types/types_sequent_c...
  - hellofunk 10y ago
    This is the first I've heard of Shen, so I can't say. However the Racket engineers, particularly Matthias Felleisen, are doing cutting-edge research into types. Typing is not a solved problem, because if it was, there wouldn't be a static vs dynamic type debate that lingers ad nauseum. Racket is in an interesting sweet spot for typing research because it is a traditional lisp with dynamic types, to which gradual typing that works both in typed and untyped land has been introduced and continues to undergo extensive attention.
tempodox 10y ago
A great read. Few words, and everything relevant mentioned.
cwmma 10y ago
The whole manipulating code as date just always seems like such a rich target for exploitation like that ruby yaml bug from a while ago [0]. It seems like a features that would be great if your code never needs data from anywhere else but as soon as you gave data coming in from other sources it would be a bit of a nightmare. 0: http://blog.codeclimate.com/blog/2013/01/10/rails-remote-code-execution-vulnerability-explained/ http://blog.codeclimate.com/blog/2013/01/10/rails-remote-cod...

99 points by bootload 10y ago

The post linked has another interesting post in the comments: http://www.defmacro.de/?p=13 http://www.defmacro.de/?p=13 . Its about an interview McCarthy gave in the year 2000 to infoQ.

catnaroek 10y ago

> object identity for everything but numbers and characters Since when is this supposed to be a selling point? Not having compound values (not the same thing as compound objects!) is a pain.

oconnore 10y ago
You seem to be very confused. This is referring to #'eq (which is why #'eql exists). What lack of compound values are you lamenting? Lisp has built in classes, structs, arrays, lists, and maps. What is missing? > An implementation is permitted to make ``copies'' of characters and numbers at any time. The effect is that Common Lisp makes no guarantee that eq is true even when both its arguments are ``the same thing'' if that thing is a character or number. http://www.lispworks.com/documentation/HyperSpec/Body/f_eq.htm#eq http://www.lispworks.com/documentation/HyperSpec/Body/f_eq.h...
- catnaroek 10y ago
  > Lisp has built in classes Objects aren't compound values. Objects are compound, well, objects. And pointers to objects are primitive, indivisible values - not compound! > lists Racket and ML have lists. Lisp has mutable linked data structures, built out of `cons` cells, whose value at any given point in time may be a list. But the value itself isn't first-class, because you can only bind the identity of the cons cell to a variable.
  - oconnore 10y ago
    Contiguous memory structs: http://www.lispworks.com/documentation/HyperSpec/Body/m_defstr.htm http://www.lispworks.com/documentation/HyperSpec/Body/m_defs... Contiguous memory vectors (multi-dimensional arrays, too!): http://www.lispworks.com/documentation/HyperSpec/Body/t_smp_ve.htm http://www.lispworks.com/documentation/HyperSpec/Body/t_smp_... Native hash tables: http://www.lispworks.com/documentation/HyperSpec/Body/f_mk_has.htm http://www.lispworks.com/documentation/HyperSpec/Body/f_mk_h...
    - catnaroek 10y ago
      > Contiguous memory I wasn't talking about the memory representation of anything. A first-class value is something that a variable may denote. In ML, if the variable `xs` denotes the list `[1,2,3]` within a given environment, it will always do so. In Lisp, I can mutate the cons cells out of which `(list 1 2 3)` is built, so what is actually bound to the variable is the object identity of the first `cons` cell. Not a list value!
      - oconnore 10y ago
        Oh. You have a strange way of phrasing your critiques, but you're right, it's all in IO/IORef.
        catnaroek 10y ago
        I wanted to formulate my observation in very general terms, rather than mention specific facilities of other programming languages. I also wanted to avoid suggesting a connection with static types or effect segregation. The main benefit of values over objects is that using values leads to designs that have less moving parts, and thus are easier to understand, modify, extend and test.

einhverfr 10y ago

It's a nice perspective. Very practical and down to earth. There is another side though, and that is that learning to think of code as data is extremely empowering and translates well when working with a fairly large set of other languages (Perl, Python, Ruby, and now even Java). Learning Lisp turns you into a better programmer.

agentgt 10y ago
I like Scheme/Lisp but I don't know if I buy the whole "learning Lisp turns you into a better programmer". Maybe more knowledgeable but not necessarily a better a developer. In some ways learning a really flexible language like Lisp can turn you even into a really bad developer. I say "developer" instead of "programer" because I want to emphasize working with others and thus sharing code with others. Of course this is based on some past observations working with MIT grads and various other academia so take my opinion with a grain of salt. IMO the language that really changed everything for me was the ML family of languages and maybe C. I would say knowing C and ML is more worthwhile than Lisp (Lisp is not exactly hard to learn anyway... the basics that is).
- ohyes 10y ago
  I'm biased, but there's a big difference between "learning lisp" (well enough to transliterate that python program) and really getting the code as data concept. I'd say that learning X really well is always a positive because whenever you learn something in depth you can then apply the concepts elsewhere. And there are still lisp-only concepts, so learning lisp is positive. ML is good too. Also spending time with a well designed concurrent language is beneficial.
  - agentgt 10y ago
    With Lisp I get the data thing but with ML you learn almost everything is a language. I can't really explain it but the whole variant/ADT pattern matching really forces to make you think of your problem domain as a specification or language (e.g. DSL). It is one of the reason why I think so many compilers are written in ML (that and the toolset is awesome for it).

cheez 10y ago

Did Kenny ever release his educational software?

tsuru 10y ago
It appears so, yes: http://tiltonsalgebra.com/# http://tiltonsalgebra.com/#
- cheez 10y ago
  This is amazing. Kenny, please fix the fonts.

mark_l_watson 10y ago

Classic Kenny! Common Lisp used to be much of my programming world also.

platz 10y ago

> most Common Lisp implementations are native compiled. ... isn't it nice to compile down to the metal? Is just the interpreter native or does cl compile your app to native as well?

pmalynin 10y ago
SBCL compiles to native. In fact thats how you check if the function was tail-optimized -- it will have a JMP opcode instead of CALL
- ohyes 10y ago
  To add to this, Most of them compile to native. I think the exception is CLISP. Certain implementations have both because compiling was costly at one point.
snaky 10y ago
To native with elegance [1] and even closer to the metal "because sometimes C abstracts away too much" [2]. [1] https://www.pvk.ca/Blog/2014/08/16/how-to-define-new-intrinsics-in-sbcl/ https://www.pvk.ca/Blog/2014/08/16/how-to-define-new-intrins... [2] http://www.pvk.ca/Blog/2014/03/15/sbcl-the-ultimate-assembly-code-breadboard/ http://www.pvk.ca/Blog/2014/03/15/sbcl-the-ultimate-assembly...

deleted 10y ago

[deleted]

oconnor663 10y ago

> he simply asked if Python could gracefully manipulate Python code as data Have there been any big LISP macro code injection vulnerabilities in the wild?

kiiski 10y ago
What do you mean with "macro code injection vulnerabilities"? Macros are expanded before the code is compiled; by the time someone is running the program there are no macros. Well, technically, someone could call `EVAL` in a production app, but that's strongly discouraged.
Johnny_Brahms 10y ago
As the other comment says, that doesn't really make sense. However, I have had to debug a codebase where lisps unhygienic macros led to extremely weird errors. The second time that happened in a big project I decided that schemes hygienic macros are superior. The extra cruft writing them is worth it. I have literally spent weeks debugging weird macro errors introduced years after the macro was first written.
- wtbob 10y ago
  You're not wrong: simple macros can be written poorly. Macros which don't properly use GENSYM should be rejected in review. Also, it's entirely possible to write a hygienic macro implementation with DEFMACRO: nothing stops a team from doing that (or using one off-the-shelf). But sometimes you do need the full power of DEFMACRO, and it's not possible to write DEFMACRO with DEFINE-SYNTAX. So one tool enables you to do anything you need, and the other only some of what you need. I know what I prefer.
  - Johnny_Brahms 10y ago
    Let's agree to agree then :) I much prefer Racket's macros. Their version of syntax-case is a bit simplified compared to the one shipped with other schemes like guile and chez. If you want to see where you can go by (ab)using racket macros, watch this: https://www.youtube.com/watch?v=WQGh_NemRy4 https://www.youtube.com/watch?v=WQGh_NemRy4

krupan 10y ago

"The question is where will we be in five years, the answer is using Common Lisp, because of language features" says the author in the comments. This was 8 years ago. Kind of rude of me to take that potshot, but it's there. I've been reading these "Why Lisp?" Arguments for years and yet it still remains pretty niche. The longer this goes on the more I am unable tell Lisp advocates apart from Perl advocates. They both sound like write-only languages. They make a lone programmer feel very productive and Free, but it results in essentially unmaintainable code. I've written and attempted to maintain much more Perl than Lisp, many years ago, so please tell me if I'm wrong.

meric 10y ago
I'm developing a language that's a superset of Lua and Lisp. It's still in its infancy, but here's an example of a Lisp/Lua function in a module that can be imported as a (+...) macro that expands into Lua `a + b + c + ...` expression. https://github.com/meric/l2l/blob/rewrite/l2l/macro/arithmetic.lisp https://github.com/meric/l2l/blob/rewrite/l2l/macro/arithmet... The idea is programmers will write in Lua whenever readability is prioritised, and when homoiconicity is required, for example in the use of domain specific languages, lisp can be switched to. The lisp part can be used to produce macros that expand into Lua. Would be great to know your thoughts!
- zvrba 10y ago
  You know about metalua, right? http://metalua.luaforge.net/ http://metalua.luaforge.net/
  - meric 10y ago
    Yes, I wanted a version of Lua with Macro's that reused familiar syntax (for lispers), that can run on LuaJIT, and is implemented in Lua completely.
    - groovy2shoes 10y ago
      https://github.com/baguette/lemma https://github.com/baguette/lemma I've unfortunately let it languish for the last few years, but I'm about to pick back up a bit for the 2016 Lisp Summer Game Jam. I've got a handful of big, backward-compat-breaking changes in the queue, but it should start to stabilize again within a couple of weeks.

unpop-opinion 10y ago

Okay, I've spent a lot of time writing Common Lisp and even more time reading about Common Lisp, and to be honest, I'm just a little tired of the cult around it. People who know it well gloat about how great Common Lisp is, which just so happens to make them look great too. And people who don't know Common Lisp all talk about the little Common Lisp they know, because they don't want to seem like they aren't in on it, and because they don't know better. Let's talk about this fabled exchange between Norvig and McCarthy, where McCarthy asks if Python can gracefully manipulate code as data, and Norvig said no, and supposedly a thousand words were said in the ensuing silence. Here's the thing; a thousand words weren't said. I don’t know what Tilton thinks was said there, but it certainly wasn’t a one sided silence in which only McCarthy’s side gets to smugly smirk as if it proves anything. Let’s talk about code as data, shall we? What enables that? Of course, it’s the s-expressions and prefix notation. So let’s write a macro. But we won’t want to write a macro that simply sits at the beginning of an s-expression and takes in a bunch of arguments, because then we could just write a function. No, we want to do a transformation on the code that creates a domain-specific language, because that’s the power of macros, right? So the very first thing you do with your macro powers, and pretty much the only useful thing you can do, is break s-expressions. Once the first macro is written you can no longer assume that inputs to macros will be s-expressions with the function at the beginning and arguments following. Every future macro must account for every previous macro. The more you use the capability to manipulate code as data gracefully, the less graceful it becomes. And, in my opinion, far more damningly, macros make your program harder to reason about. Before macros, a reader could assume that the first thing in the s-expression was operating on everything else in the s-expression. But no longer. We can’t even assume that sub-s-expressions in the s-expression are evaluated first. This isn’t a hypothetical problem. Common Lisp programmers spend a ton of time talking about how to write macros so that they’re not going to come back and bite you in the butt when they get used in an unexpected situation. And the reason is, nobody really knows how to do it. So, with a great deal of respect for McCarthy based on his many other achievements, I have to say I don’t care about macros, and actually think we’re better off without them. First-class functions are a much more coherent, consumable way of using code-as-data. Most of the features of Common Lisp I actually want are in other languages now. Garbage collection? REPLs? First-class functions? Higher-order functions? They’re all in other languages now. Python, for example has all those things. And to be honest, other languages have done a lot better things with the functional programming aspects of Common Lisp. McCarthy gets credit for inventing a lot of stuff, but we don’t fly Wright-brothers style planes today and we shouldn’t use Common Lisp just because it was first to have those things. More sophisticated type systems make lambdas more powerful (and incidentally, a lot of the problems with macros can be seen as type problems). People on this thread are claiming, “Learning Common Lisp turns you into a better programmer”. But I tend to think that learning functional programming is the part that people are referring to, and frankly, there are better languages in which to learn functional programming. Haskell, Standard ML, or OCaml would be a better choice. And sure, there are other features that only Common Lisp has, but nobody is talking about those. Restarts? I’d love to see more people experimenting with those. Then again, Erlang has a way better threading model than anything else and much more sophisticated pattern matching. Scheme has call/cc. Standard ML has a powerful type system. Haskell has functional purity. Prolog has unification. A great many of these are more interesting than restarts. I don’t hate Common Lisp; if nothing else, Common Lisp has a few very solid implementations out there and lots of existing libraries that make it a very useful tool. There are some programs which I wouldn’t consider writing in another language. I just don’t really think it’s the be-all and end-all of programming languages any more, and I’m kind of tired of the cult that has formed around it. EDIT: s/Lisp/Common Lisp/g because not everyone takes “Lisp” to just mean “Common Lisp”.

hahooooo 10y ago

Is there any advantage in using a functional language when programming non-mathematically related code? I see how it can help write Neural Networks, AI, financial code, etc. But if you know Python,Ruby,PHP,Java and Lisp (well), why would you choose to write a blog, webstore, webmail client or social media* app (which probably is about 90% of what people actually do) in Lisp over the four three? I'll tell you why I would chose the first four: 1. Large community. 2. Many more libraries. 3. Easier to hire. *Except for (perhaps) a small spam-block/feed ai module

nv-vn 10y ago
Yes. Functional programming (although it isn't necessarily a trait of Lisp) has, in fact, little relation to math (despite what many people believe). It's also very far removed from the field of AI right now (not for any particular reason, but there's no more specific reason to switch to Lisp for AI than there is for desktop or web apps). The reason you'd use Lisp is quite simple -- it saves time and makes programming easier. Macros are the biggest time saver in the world, and you don't realize how much time you waste writing repetitive code until you get to use them. As for your 3 reasons in favor of the other languages, I think the first means almost nothing at all. Lisp is much easier (once you grasp it) than many other languages, so I think the fact that you'll get less answers on StackOverflow is irrelevant. As for the second reason, as long as you have one library that works for what you want -- say some library for writing web servers -- it doesn't really matter after that. There's rarely any reason to reinvent the wheel here, and there's always someone that attempted such a common task before you. Just because you don't have 3,000 different choices like in Java, doesn't mean that you won't find high-quality code for what you need to do (in fact, I'd argue that Lisp code has a much higer quality on average than Java code). As for hiring, I think Paul Graham has already given the best comments on this. Simply put, a good programmer can be taught to write good Lisp, even if they don't know it by the time you hire them.
GlennS 10y ago
I'd say web's request -> response model is pretty well suited to functional programming. It seems popular amongst JavaScript programmers at the moment as well. React, which appears the current hotness, is based on making a functional interface to the DOM. Although actually, I'd say the main reason to use a Lisp for web gunk is the macros rather than the functional programming. The tree structure maps very naturally onto HTML generation. There are some really nice libraries (in particular I'm familiar with Clojure libraries) which make the server-side part of a web app really neat. You can basically skip the whole 'templating' bit.

nurettin 10y ago

For UI application programming You can do without FP language features. Hell, you can even do without smart pointers checked arrays or GC. But you cannot do without a decent desktop or web development experience. I got involved with pretty large desktop applications written in delphi. The design-time, the debugger, native compilation without having to install some msvc runtime, deriving and combining visual components, it just gives a smooth experience for desktop apps. If lisp has such well thought-out frameworks, I would jump ship just to get at the language features it offers.

junke 10y ago
Would you pay for it? http://www.lispworks.com/products/capi.html http://www.lispworks.com/products/capi.html
- nurettin 10y ago
  I did buy frameworks for work, and this does look OK, but coding gui by hand is not something our developers can handle in large scales.
  - junke 10y ago
    It seems that there is an interface builder. http://www.lispworks.com/documentation/lcl50/clwug/clw-216.html http://www.lispworks.com/documentation/lcl50/clwug/clw-216.h...
    - mark_l_watson 10y ago
      CAPI is pretty nice. Years ago, LispWorks gave me free licenses in return for my doing some cleanup on their documentation. LispWorks is very good, but my licenses are for what is now a very old version, so I now use SBCL and sometimes Clozure. For industrial settings, LispWorks and also Franz are very good products. I used Franz products on a medical large data project several years ago, and their support was nothing short of amazing. That said, on the same project we had an issue with SBCL and we simply paid one of the maintainers to promptly fix the issue. Sometimes it just takes spending some money.

ww520 10y ago

I want to see people's list of reasons for why not lisp. Edit: Ok, this is not trolling. I quite liked Lisp and actually had implemented a version of common lisp from scratch based the Guy Steele's CL reference back in the undergrad time. I just found that beyond academic and a few Emacs packages, I didn't use Lisp at all, for one reason or the other. I just want to hear people's reason for not picking Lisp for their work.

kqr 10y ago
I dislike Lisp (and Lisp-inspired languages like Scheme and Clojure) for two reasons: 1. their weak and dynamic type system, and 2. they don't control side-effects.
- happyslobro 10y ago
  Haskel programmers: you can spot them by that constant pained look, as if they have to step in horse poop whenever they go outside.
  - elbear 10y ago
    Why did you feel the need to deride someone for simply expressing their opinion? Do you think it helps the discussion?
    - happyslobro 10y ago
      I meant no disrespect. The horse poop outside was a metaphor for side effects. During my brief exploration of Haskell, I went to great lengths to avoid dealing with side effects, and when I couldn't avoid them, the pure functional solutions were pretty painful to learn.
      - platz 10y ago
        > I meant no disrespect. I don't believe you.

hellofunk 10y ago

I'm of the opinion that there is only one lisp right now with some serious potential to dominate in the future, and that is Racket. Why? For one very simple reason: unlike all other lisps, there is serious, ongoing, and lengthy research into correctly bringing a static type-checking process to the language. Clojure's core.typed doesn't count here, as it is full of significant holes that invalidate its entire point -- though, those holes are very possibly getting filled in the coming years as they attempt to refactor core.typed following the Racket model. But the Racket team is doing something with lisp that is true to its core, not just with types, but with many other features as well. Interesting piece of trivia: this website you are reading right now is built on top of Racket.

vertex-four 10y ago
Isn't HN on Arc?
- emidln 10y ago
  Arc runs on mzscheme which turned into Racket. The last official release of Arc requires an older release of mzscheme from before lists were immutable. There is a community-maintained fork called Anarki [1] that runs on modern Racket. [1] - http://arclanguage.github.io/ http://arclanguage.github.io/
emidln 10y ago
What makes the Racket model more correct than the system based in Sequent Calculus [1] provided by Shen? [1] - http://www.shenlanguage.org/learn-shen/types/types_sequent_calculus.html http://www.shenlanguage.org/learn-shen/types/types_sequent_c...
- hellofunk 10y ago
  This is the first I've heard of Shen, so I can't say. However the Racket engineers, particularly Matthias Felleisen, are doing cutting-edge research into types. Typing is not a solved problem, because if it was, there wouldn't be a static vs dynamic type debate that lingers ad nauseum. Racket is in an interesting sweet spot for typing research because it is a traditional lisp with dynamic types, to which gradual typing that works both in typed and untyped land has been introduced and continues to undergo extensive attention.

tempodox 10y ago

A great read. Few words, and everything relevant mentioned.

cwmma 10y ago

The whole manipulating code as date just always seems like such a rich target for exploitation like that ruby yaml bug from a while ago [0]. It seems like a features that would be great if your code never needs data from anywhere else but as soon as you gave data coming in from other sources it would be a bit of a nightmare. 0: http://blog.codeclimate.com/blog/2013/01/10/rails-remote-code-execution-vulnerability-explained/ http://blog.codeclimate.com/blog/2013/01/10/rails-remote-cod...