6 ms·

Lisp is a beautiful language (or, to be more precise, set of languages). It is absolutely essential to a computer science education. It also gets unwieldy when

by Fej 9y ago

Lisp is a beautiful language (or, to be more precise, set of languages). It is absolutely essential to a computer science education. It also gets unwieldy when programs get complex.

webkike 9y ago
Lisp is the best language for any task that does not require types.
- progman 9y ago
  You can add static type checking in Lisp anytime if you want. Consider the discussion at [1]. [1] http://compgroups.net/comp.lang.lisp/static-type-checking-in-lisp/695744 http://compgroups.net/comp.lang.lisp/static-type-checking-in....
- threatofrain 9y ago
  There's Typed Racket: https://docs.racket-lang.org/ts-guide/quick.html https://docs.racket-lang.org/ts-guide/quick.html
- deleted 9y ago
  [deleted]
sds2 9y ago
No, it shouldn't be. Lisp is not practical(try to prove it otherwise, there's no evidence) and it's only a thing now because some ppl likes its esoteric syntax. It's way too overhyped.
- progman 9y ago
  You find many practical examples at planet.lisp.org.
- Risord 9y ago
  Real apps has been built with lisp so therefore it's at least some what practical. On the other hand I just cannot see anything fundamental which makes lisp lot less practical from many commonly used business languages. Well ecosystem size may not same but on day one most languages haven't Hugo ecosystem. There are lot of schools and if you are "be a cool web app developer"-school where you learning direct skills reauired most common web dev jobs today... Yeah lisp is not essential. But if you are "computer SCIENCE"-school and you targeting variety of fundamental cocepts of field I say that lisp is quite essential.
  - sds2 9y ago
    > But if you are "computer SCIENCE"-school and you targeting variety of fundamental cocepts of field I say that lisp is quite essential. I'm sure you've nothing to do with compsci because lisp is a useless language family. If anything is recommended than it's rust, c and idris.
    - shakna 9y ago
      > I'm sure you've nothing to do with compsci because lisp is a useless language family. If anything is recommended than it's rust, c and idris. Scheme is particularly suited to parsing, interpreting and compiling.[0][1] There's a reason GCC's internals often look like Lisp. If you exclude language design from computer science, then maybe Lisp becomes a "useless language family", but there's a reason MIT Scheme was created. [0] https://mitpress.mit.edu/sicp/ https://mitpress.mit.edu/sicp/ [1] https://en.wikipedia.org/wiki/Lisp_in_Small_Pieces https://en.wikipedia.org/wiki/Lisp_in_Small_Pieces
      - sds2 9y ago
        You can do that more efficiently with any ML language. > There's a reason GCC's internals often look like Lisp. Dude, that notation is not original to lisp...
        shakna 9y ago
        > You can do that more efficiently with any ML language. So first you say Lisp is useless in compsci because of the existence of "rust, c and idris", and now its pointless to use it because of ML? > Dude, that notation is not original to lisp... Firstly: Have you actually looked at an MD file? [0] RTL is a Lisp dialect. Secondly: The first paper on S-Expressions appeared in November, 1997. McCarthy's first paper on what would become Lisp in 1982. I'm aware of no language, and can find reference to no language, that used that notation before Lisp did, so yes it is original to Lisp. [0] https://gcc.gnu.org/git/?p=gcc.git;a=blob_plain;f=gcc/config/aarch64/aarch64.md;hb=172881b016150e383411bfbbe8bf757bff62f22b https://gcc.gnu.org/git/?p=gcc.git;a=blob_plain;f=gcc/config...
- deleted 9y ago
  [deleted]
lispm 9y ago
That depends. Several mildly large programs have been written in Lisp. There should be code bases for applications reaching or surpassing ten million lines of Lisp code. There also should be code bases with relatively complex code, which have been maintained for more than a decade. For example the Cyc system is under continuous development since the mid 80s. A dialect like Common Lisp was designed such that applications in the large are possible. As any large program it needs a bit thought how to make a scalable architecture and how to best use and extend the facilities provided by rhe development environment and the language.
- vram22 9y ago
  >A dialect like Common Lisp was designed such that applications in the large are possible. Interesting. Can you mention some of the Lisp language or other features that help with that?
  - lispm 9y ago
    Note that in a large Lisp system you need certain features at compile time, but some will help at runtime (like the error handling system) to make large software debuggeable, more robust, or both. * namespaces for symbols, in earlier days Lisp had a flat namespace * compilation of files, means in a large system you can use 'ahead of time' compilation, where the compiler might give a lot of diagnostic messages. There is very little penalty to that, basically one can compile always and interactively. * type declarations/hints which can be used for optimization, type checks -> see SBCL and CMUCL, and documentation * lots of declaration forms which can be checked at compile time or runtime * macros which can be expanded at compile-time. This can create early warnings/errors. * function arglists, where the usage can be checked at compile-time (missing arguments, added arguments, ...) * keyword arguments, which makes code more readable * a very elaborate error handling system, which can not only catch errors, but which can be used to interactively or automatically repair some errors. Thus you don't get 'program crashed', but a handler gets called in the error context, which than can use provided explicit restarts. Errors types can be organized in an ontology with inheritance. * runtime assertions and type checks work with the error system * documentation features included: many declarations allow documentation strings * robust runtimes which by default prevent corrupting the running Lisp as much as possible. Some earlier Lisps created unsafe compiled code. By default I would expect a Common Lisp system to detect all kinds of wrong access to data structures at runtime. * optimizations, which can be restricted to certain code blocks Plus * an object system which can be used to provide extensible software, typically used to structure larger software. Also provides multi-methods which prevent being called with arguments of wrong types at runtime. Multiple inheritance. This allows a lot explicit structure in larger applications, which also can explored by reflection and which can be tailored for specific needs. * features like macros and reader macros can increase the code density in larger software -> fewer lines of code and domain level code. By default Common Lisp favors larger identifies, but in larger codebases macros can significantly reduce code size and make external tools like preprocessors obsolete. A different development methodology: In static languages you tend to statically compile a program, build it, start it, test it. May be in some debug mode or with some kind of extension language interface. In Common Lisp one may develop with a build while it is running and then make sure that these builds can be reproduced by compiling/loading the whole thing. This can reduce the typical development cycle time drastically. But different development models are possible: fully batch, pre-compiled + interactive, fully interactive.

by Fej 9y ago

Lisp is a beautiful language (or, to be more precise, set of languages). It is absolutely essential to a computer science education. It also gets unwieldy when programs get complex.

webkike 9y ago

Lisp is the best language for any task that does not require types.

progman 9y ago
You can add static type checking in Lisp anytime if you want. Consider the discussion at [1]. [1] http://compgroups.net/comp.lang.lisp/static-type-checking-in-lisp/695744 http://compgroups.net/comp.lang.lisp/static-type-checking-in....
threatofrain 9y ago
There's Typed Racket: https://docs.racket-lang.org/ts-guide/quick.html https://docs.racket-lang.org/ts-guide/quick.html
deleted 9y ago
[deleted]

sds2 9y ago

No, it shouldn't be. Lisp is not practical(try to prove it otherwise, there's no evidence) and it's only a thing now because some ppl likes its esoteric syntax. It's way too overhyped.

progman 9y ago
You find many practical examples at planet.lisp.org.
Risord 9y ago
Real apps has been built with lisp so therefore it's at least some what practical. On the other hand I just cannot see anything fundamental which makes lisp lot less practical from many commonly used business languages. Well ecosystem size may not same but on day one most languages haven't Hugo ecosystem. There are lot of schools and if you are "be a cool web app developer"-school where you learning direct skills reauired most common web dev jobs today... Yeah lisp is not essential. But if you are "computer SCIENCE"-school and you targeting variety of fundamental cocepts of field I say that lisp is quite essential.
- sds2 9y ago
  > But if you are "computer SCIENCE"-school and you targeting variety of fundamental cocepts of field I say that lisp is quite essential. I'm sure you've nothing to do with compsci because lisp is a useless language family. If anything is recommended than it's rust, c and idris.
  - shakna 9y ago
    > I'm sure you've nothing to do with compsci because lisp is a useless language family. If anything is recommended than it's rust, c and idris. Scheme is particularly suited to parsing, interpreting and compiling.[0][1] There's a reason GCC's internals often look like Lisp. If you exclude language design from computer science, then maybe Lisp becomes a "useless language family", but there's a reason MIT Scheme was created. [0] https://mitpress.mit.edu/sicp/ https://mitpress.mit.edu/sicp/ [1] https://en.wikipedia.org/wiki/Lisp_in_Small_Pieces https://en.wikipedia.org/wiki/Lisp_in_Small_Pieces
    - sds2 9y ago
      You can do that more efficiently with any ML language. > There's a reason GCC's internals often look like Lisp. Dude, that notation is not original to lisp...
      - shakna 9y ago
        > You can do that more efficiently with any ML language. So first you say Lisp is useless in compsci because of the existence of "rust, c and idris", and now its pointless to use it because of ML? > Dude, that notation is not original to lisp... Firstly: Have you actually looked at an MD file? [0] RTL is a Lisp dialect. Secondly: The first paper on S-Expressions appeared in November, 1997. McCarthy's first paper on what would become Lisp in 1982. I'm aware of no language, and can find reference to no language, that used that notation before Lisp did, so yes it is original to Lisp. [0] https://gcc.gnu.org/git/?p=gcc.git;a=blob_plain;f=gcc/config/aarch64/aarch64.md;hb=172881b016150e383411bfbbe8bf757bff62f22b https://gcc.gnu.org/git/?p=gcc.git;a=blob_plain;f=gcc/config...
deleted 9y ago
[deleted]

lispm 9y ago

That depends. Several mildly large programs have been written in Lisp. There should be code bases for applications reaching or surpassing ten million lines of Lisp code. There also should be code bases with relatively complex code, which have been maintained for more than a decade. For example the Cyc system is under continuous development since the mid 80s. A dialect like Common Lisp was designed such that applications in the large are possible. As any large program it needs a bit thought how to make a scalable architecture and how to best use and extend the facilities provided by rhe development environment and the language.

vram22 9y ago
>A dialect like Common Lisp was designed such that applications in the large are possible. Interesting. Can you mention some of the Lisp language or other features that help with that?
- lispm 9y ago
  Note that in a large Lisp system you need certain features at compile time, but some will help at runtime (like the error handling system) to make large software debuggeable, more robust, or both. * namespaces for symbols, in earlier days Lisp had a flat namespace * compilation of files, means in a large system you can use 'ahead of time' compilation, where the compiler might give a lot of diagnostic messages. There is very little penalty to that, basically one can compile always and interactively. * type declarations/hints which can be used for optimization, type checks -> see SBCL and CMUCL, and documentation * lots of declaration forms which can be checked at compile time or runtime * macros which can be expanded at compile-time. This can create early warnings/errors. * function arglists, where the usage can be checked at compile-time (missing arguments, added arguments, ...) * keyword arguments, which makes code more readable * a very elaborate error handling system, which can not only catch errors, but which can be used to interactively or automatically repair some errors. Thus you don't get 'program crashed', but a handler gets called in the error context, which than can use provided explicit restarts. Errors types can be organized in an ontology with inheritance. * runtime assertions and type checks work with the error system * documentation features included: many declarations allow documentation strings * robust runtimes which by default prevent corrupting the running Lisp as much as possible. Some earlier Lisps created unsafe compiled code. By default I would expect a Common Lisp system to detect all kinds of wrong access to data structures at runtime. * optimizations, which can be restricted to certain code blocks Plus * an object system which can be used to provide extensible software, typically used to structure larger software. Also provides multi-methods which prevent being called with arguments of wrong types at runtime. Multiple inheritance. This allows a lot explicit structure in larger applications, which also can explored by reflection and which can be tailored for specific needs. * features like macros and reader macros can increase the code density in larger software -> fewer lines of code and domain level code. By default Common Lisp favors larger identifies, but in larger codebases macros can significantly reduce code size and make external tools like preprocessors obsolete. A different development methodology: In static languages you tend to statically compile a program, build it, start it, test it. May be in some debug mode or with some kind of extension language interface. In Common Lisp one may develop with a build while it is running and then make sure that these builds can be reproduced by compiling/loading the whole thing. This can reduce the typical development cycle time drastically. But different development models are possible: fully batch, pre-compiled + interactive, fully interactive.