101–110 of 110 posts
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.
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.
Earlier quoted context omitted.
>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?
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…
Earlier quoted context omitted.
> Maintenance timesink might easily outweigh the gain in development time. That is correct. However, in Haskell you need a lot of discipline to guide a big project in the right direction. Maintenance can quickly became a nightmare due to very dense code. If maintenance is the main issue I would choose Ada than Haskell. I have no problem to understand my own Ada code written 10 years ago, even without documentation. I…
> That is correct. However, in Haskell you need a lot of discipline to guide a big project in the right direction. Maintenance can quickly became a nightmare due to very dense code. Have you worked with Haskell professionally? Your observations do not match my experience of approx. 3 years of professional Haskell development across 3 different companies. Guiding the growth of Haskell codebases is trivial compared to…
Not yet. I was seriously interested in Haskell. The cabal hell however put me back. Stack is interesting but installation from source is still troublesome.
I always want to be able to install my developer tools from scratch (by source only) since I want to make sure that I can port my software to new systems. Haskell's and Rust's way of installation (curl | sh) is convenient but inacceptable for porting. Nim's bootstrap from source (no dependencies except a C compiler) is the right way how it should be.
Earlier quoted context omitted.
> That is correct. However, in Haskell you need a lot of discipline to guide a big project in the right direction. Maintenance can quickly became a nightmare due to very dense code. Have you worked with Haskell professionally? Your observations do not match my experience of approx. 3 years of professional Haskell development across 3 different companies. Guiding the growth of Haskell codebases is trivial compared to…
> Have you worked with Haskell professionally? Not yet. I was seriously interested in Haskell. The cabal hell however put me back. Stack is interesting but installation from source is still troublesome. I always want to be able to install my developer tools from scratch (by source only) since I want to make sure that I can port my software to new systems. Haskell's and Rust's way of installation (curl | sh) is conven…
Earlier quoted context omitted.
> JavaScript has fixed S-expressions Replacing them with a semicolon and curly brace riddled abomination; see CoffeScript and various syntax extensions that come with latest JS standards. Also note how many years it took for JS to get even very basic features, like `() => {}` lambda notationor multiline strings. In a language with a macro system you can implement both easily. > Macros are harmful to programming in th…
> Linked lists are a very convenient and surprisingly universal data structure, but they really shine wherever you have a recursive algorithm. Which is, in the languages mentioned, almost all the time. Linked lists were way ahead of their time. Nowadays everything is so fast that we can probably use them without guilt, but there is still a sense of disgust associated them.
However, linked lists offer many advantages that arrays do not. The length of a list need not be known at compile time, for one. It's trivial and very fast to insert a new element in the middle of the list. They are not optimized for random access, but they pose no performance penalty (over arrays) if you need to traverse them from start to end.
But the most important advantage of linked lists is that they are their own iterators (in C++ parlance). You don't need an additional state for iterating over a list - you don't need to store and update the index, for example. Each element of a list is the beginning of the rest of the list, so if you hold a reference to one, you can stop and restart iteration without problems. Moreover, you can add elements to the list and still be able to use the previously captured element as a start of new iteration: no need to invalidate the iterator.
In other words, Linked List has some very desirable properties and it makes sense to use it for almost anything other than a fixed-length, random-access collection. All Lisps provide vectors and hashes for the latter use-case.
I think the problem with Linked Lists is that they are not hard to implement and taught on the entry-level courses, with C as an implementation language. This makes it very hard to see their usefulness. With a bit of tooling (library functions) and language support, they really shine.
Earlier quoted context omitted.
> Linked lists are a very convenient and surprisingly universal data structure, but they really shine wherever you have a recursive algorithm. Which is, in the languages mentioned, almost all the time. Linked lists were way ahead of their time. Nowadays everything is so fast that we can probably use them without guilt, but there is still a sense of disgust associated them.
Linked lists are indeed wasteful in terms of memory usage, compared to simple arrays. There are ways of optimizing this, but you won't get away from having an additional pointer to the next element. However, linked lists offer many advantages that arrays do not. The length of a list need not be known at compile time, for one. It's trivial and very fast to insert a new element in the middle of the list. They are not o…
It was done on some Lisp Machines with CDR-coding. newly allocated lists did not have any CDR pointers. Optimizing lists that way could also be done by the garbage collector, when it needed to copy lists or in optimization runs before saving an image.
Most other implementations did not implement it.
What are some examples of open source Lisp projects and codebases whose features and elegance could have only been executed as well as they are in the language, or are just great codebases in general to study?
Earlier quoted context omitted.
> 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? 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…
> Lisp on the other hand won't teach you anything. How hard is this to understand? 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 Poli…
Poor choice.
> Several decades of computer science disagree with you.
compsci hates lisp along with the industry, what are you talking about?
Earlier quoted context omitted.
GNU Guix. It uses code staging a lot, which works best in a language in which you can trivially pass around code as data. It also demonstrates that Scheme is flexible enough to easily implement features that the language designers did not, such as monads and laziness. While both can be done in almost any language, I think that Scheme's macros allow for exceptionally seamless implementations.
> code staging I'm trying to look up what this means. Do you have a link?
That's not the only instance of "staged" execution. Guix introduces G-expressions, a quoted expression in a build context where unquoted package values are replaced with absolute directory names that are not known until execution time.
Quoting and unquoting code and dealing with different strata of evaluation come natural in Scheme.
Another simpler example of staged execution might be the remote code execution feature of Guile-SSH.
You may also like to read about multitier programming in Hop: http://queue.acm.org/detail.cfm?id=2330089