4 ms·
Can someone direct me to some code where I can see the full potential of Lisp? I have programmed in Scheme before while taking a course using SICP. Final proje
by hackingthenews 6y ago
Can someone direct me to some code where I can see the full potential of Lisp?
I have programmed in Scheme before while taking a course using SICP. Final project was a Scheme interpreter. But I didn't have any epiphany/awakening like many others seems to have.
- capableweb 6y agoI think you will have to program with it to get it. It's not so much about a final, static copy of code that you can look at and be amazed, but more about how fluid and well oiled the journey there was. Try to build something with Clojure (bit easier to get started with than LFE, Common Lisp or others, except maybe Racket) and try to focus on a REPL heavy flow (with integration with your favorite editor) to see the full potential of Lisp.
- phoe-krk 6y ago> Can someone direct me to some code where I can see the full potential of Lisp? There's exists no code that shows the full potential of Lisp because its potential lies not in the code itself, but in the way of working with it. The language is interactive and image-based, meaning that you do not program in it by passing code through a compiler into executables, but instead you modify the running Lisp image until it contains the program you want. This is usually done by connecting the editor to the running Lisp image and sending commands to it: usually that is to compile-and-load (or compile-and-replace) individual forms/functions/variables, or whole files, or whole systems, or to work with the read-eval-print loop, or to interactively inspect objects, or to interactively resolve signaled errors via the debugger. This provides a lot of introspection into how the Lisp image and the program contained within works, and drastically reduces the feedback loop since the overhead of compiling-and-loading individual functions or even whole files is unnoticeable. Disclosure: I am a Common Lisp programmer.
- smabie 6y agoYeah but none of what you said applies to Scheme.
- phoe-krk 6y agoThe question was about Lisp in general, or at least I read it that way. If I misread, then I'll nonetheless leave describing Scheme paradigms to someone who knows something substantial about Scheme programming; I'm not that person.
- smabie 6y agoLisp has two big ideas. The first big idea is that a regular syntax allows the trivial implementation of macros. Just have a separate compilation where the AST is passed in as a list to different macros and then compile the result. The second idea (not shared by the some Lisps like Scheme) is that of a system image which is modified in real time. This allows on the fly debugging, adding of new features, etc with no downtime. Macros have worked there way into languages like Julia or Nim, while the system image idea is mostly constrained to Smalltalk and Common Lisp. The best example of the power of macros is Racket, which has world class meta programming facilities and is probably the best language in existence for creating new languages, DSLs, and doing experimental PL research. I've used both CL and Racket professionally, and they both shine in certain situations. That being said, I've grown tired of the relative verbosity of both languages (minimal syntax has a high cost) and the performance and productivity cost of dynamic typing. For most new engineering projects, I'd much rather use something like OCaml or Scala than CL or Racket. For scientific computing, I usually go with Julia or kdb+/q. That being said, I think Racket especially shines in the development of internal business or research tools. The large number of high quality libraries (especially for GUIs) makes it a great choice for desktop apps.
- hackingthenews 6y agoThanks! I haven't really experienced the image feature, as I used Scheme. It doesn't sound like it would be consequential to how I program, but that might just be my ignorance of it. My experience with the macro stuff is that they enable in-house implementation of language features like lazy evaluation (not possible in other languages without a lot of extra code), which we implemented during the course. But implementing features like that is not really something I need to do for my everyday programming.
- smabie 6y agoThe power of macros goes beyond just core language features. For example, Racket has a prolog implementation, an OOP implementation, contracts, and much more, all developed with macros. You can generate HTML, do templating, or write documentation, all with macros. There's a certain magical feeling as a library designer when you can decide upon whatever syntax you want, with absolutely no constraints. Leads to the development of some very cool and clean stuff. For example, I used Racket macros at my old job as a bio informatics researcher at a hospital to design a DSL to specify bio informatics processing pipelines. You could either write it yourself, or you could use a GUI to manipulate a visual graph of operations and write out the pipeline using the DSL to a file. These sort of DSL use cases are a lot more common than people think, mostly because they don't think of an API as a new language, merely as some code written in an existing one. When you realize that macros can be used to eliminate all repetition and all patterns, you start to think in a different way. Designing proper interfaces with macros can be challenging though: you want to provide a nice syntax that is both composable with other macros, and clean. Also macros allow the core language to be paired down and very simple. Stuff like Scheme, in which all desired features (OOP, actors, async, generators, etc) can be implemented by external packages. But like I said, I don't use Lisp much anymore. Functional programming with higher kindred types goes a long way in matching the power of macros, albeit in a more structured way. Of course, type systems will always fall short of the unlimited power of macros, but for a lot of problems it's more than sufficient. Think of Lisp as the prototypical programming language, the essence of transforming symbols into other symbols. Lisp forms the base, on top of which all other features can be implemented.
- brudgers 6y agoPeter Norvig’s Paradigms of Artificial Intelligence: case studies in Common Lisp shows how Common Lisp can be used “in anger” to create the compact powerful code people always say Common Lisp is good for.
- gitgud 6y agoPretty sure you're writing on a good example now! Hacker news is written in Arc, which is a dialect of Lisp. There's an old copy of code base here: https://github.com/wting/hackernews https://github.com/wting/hackernews
- dig1 6y ago* Hiccup (https://github.com/weavejester/hiccup https://github.com/weavejester/hiccup) - DSL for generating html. You can easily mix it with other language constructs. There are similar libraries for Common Lisp and Scheme. * Compojure-api (https://github.com/metosin/compojure-api https://github.com/metosin/compojure-api) - for building web applications. Mix json-like, hiccup and clojure constructs for web applications and autogenerate Swagger documentation. * LOL book (https://letoverlambda.com/ https://letoverlambda.com/). Extreme examples what you can do with macros and code modifications during compile time. * Seesaw (https://gist.github.com/daveray/1441520 https://gist.github.com/daveray/1441520) - library for building GUI apps with Clojure and Swing. Express GUI elements through declarative syntax. Qt and other libraries has similar feature, but is usually preprocessed with external tools. * Scheme - MiniKanren (https://docs.racket-lang.org/minikanren/index.html https://docs.racket-lang.org/minikanren/index.html) Most of these things in regular languages would require modifying language parser or compiler, or adding external tool that will parse that code and generate new one; e.g. like React is doing with html chunks. Also, many Scheme/CL/Clojure implementations provide functions to modify syntax table in runtime, allowing you to alter how things are parsed. That is extremely hard in regular languages due unregular syntax constructs.