It also gets unwieldy when programs get complex.
It also gets unwieldy when programs get complex.
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.
Interesting. Can you mention some of the Lisp language or other features that help with that?
* 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.
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.
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.
> There's a reason GCC's internals often look like Lisp.
Dude, that notation is not original to lisp...
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...
Idris and Rust are ML descendants and C helps you to learn the basics of low-level programming. Lisp on the other hand won't teach you anything. How hard is this to understand?
> Secondly: The first paper on S-Expressions appeared in November, 1997.
That was just a draft of an RFC which never got approved. S-Expressions are MUCH older - it's "Polish Notation" invented by Jan Łukasiewicz in 1924
> McCarthy's first paper on what would become Lisp in 1982.
Lisp was specified in 1958.
> 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.
1. It's not about who used that notation but who invented it - not McCarthy; 2. that notation is practically useless for programming languages but they're good for ASTs.
Difficult when the definitive compsci course, Structure and Interpretation of Computer Programs starts, and ends, with Lisp.
> S-Expressions are MUCH older - it's "Polish Notation" invented by Jan Łukasiewicz in 1924
No. Polish notation, as described by Łukasiewicz, is:
> I came upon the idea of a parenthesis-free notation in 1924
Polish notation has a strict set of precedence rules, and no parentheses. At all.
S-Expressions contain Polish notation, but is a superset that allows you to specify arguments in a less painful precedence than Polish notation, and with variadic arguments, which is not possible in Polish notation.
> that notation is practically useless for programming languages but they're good for ASTs.
Several decades of computer science disagree with you.
[1] http://compgroups.net/comp.lang.lisp/static-type-checking-in....