11–20 of 131 posts
Shouldn't [2012] be appended to the title? I've seen the article discussed on HN before. [1] [1] https://news.ycombinator.com/item?id=3830867
I thought HN wont allow to re-post the exact same url, so to bypass people add noise to the url. is date of post also considered?
Earlier quoted context omitted.
Things change. LISP was popular in the 1980s before caches, branch prediction, and complex memory hierarchies. The car/cdr list is just about the worst way to represent lists in terms of performance on modern CPUS. Conceptually it is really clean, but about the only application it makes sense for is first order theorem proving, or in languages that support pattern matching. If you actually want to use lists as lists…
That's... basically not even wrong. Lisp implementations that run well on, and take advantage of, architectures with caches, branch prediction and complex memory hierarchies are well-known, and have been well-known for, literally, decades. http://pt.withy.org/publications/VLM.html is an example from 1994. More importantly though, even the earlier Lisp machines (at least since 1983!) implemented a form of instruction…
Earlier quoted context omitted.
Things change. LISP was popular in the 1980s before caches, branch prediction, and complex memory hierarchies. The car/cdr list is just about the worst way to represent lists in terms of performance on modern CPUS. Conceptually it is really clean, but about the only application it makes sense for is first order theorem proving, or in languages that support pattern matching. If you actually want to use lists as lists…
>LISP was popular in the 1980s before caches, branch prediction, and complex memory hierarchies. Yeah, let's just forget about decades of Lisp development since. >something like the Java ArrayList makes more sense. Except you lose the most important detail of Lisp pairs: persistence.
Earlier quoted context omitted.
Things change. LISP was popular in the 1980s before caches, branch prediction, and complex memory hierarchies. The car/cdr list is just about the worst way to represent lists in terms of performance on modern CPUS. Conceptually it is really clean, but about the only application it makes sense for is first order theorem proving, or in languages that support pattern matching. If you actually want to use lists as lists…
>LISP was popular in the 1980s before caches, branch prediction, and complex memory hierarchies. Yeah, let's just forget about decades of Lisp development since. >something like the Java ArrayList makes more sense. Except you lose the most important detail of Lisp pairs: persistence.
Just about every language that promises an advance in parallelism (other than solidly "worse is better" approaches such as Hadoop and Pig) is selling some kind of snake oil, and immutability is one of the worst of them.
Immutability has benefits in terms of correctness, but not in terms of scalability to more processors or total throughput. With modern memory hierarchies a lot revolves around never letting two threads touch the same cache line and this happens at all you lose at least an order of magnitude in performance. Garbage collection involves global properties of the system, so there will always be some "stop the world" element of GC, so GC itself becomes a scaling bottleneck when you allocate lots of memory and throw it all behind your rear.
I admit that I don't completely understand Lisp's claim to fame. Yes, programs in the language are represented by a built-in data type, and you can write a self-interpreter quite easily. But the same is true for a simple assembly language, if you know the instruction encoding! You can represent a program as a code pointer, and it's easy to write an analog of "eval" by hand, using just a handful of arithmetic instruct…
It took years to develop approaches to garbage collection (the earliest prototypes used bump allocators and crashed when they exhausted a heap), years to finalize the syntax of the language (you'll notice that the "maxwell's equations" are written using M-Expressions, a syntax for the language which was discarded for ease of implementation and later rationalized because homoiconicity can be handy), decades to realize how important lexical scope (versus dynamic) is to maintaining encapsulation. Modern Lisps are substantially different in syntax and semantics from these earliest ideas; we're just still calling them Lisp.
It's very easy to make Lisp look elegant when you brush all the implementation details under the rug.
I admit that I don't completely understand Lisp's claim to fame. Yes, programs in the language are represented by a built-in data type, and you can write a self-interpreter quite easily. But the same is true for a simple assembly language, if you know the instruction encoding! You can represent a program as a code pointer, and it's easy to write an analog of "eval" by hand, using just a handful of arithmetic instruct…
I admit that I don't completely understand Lisp's claim to fame. Yes, programs in the language are represented by a built-in data type, and you can write a self-interpreter quite easily. But the same is true for a simple assembly language, if you know the instruction encoding! You can represent a program as a code pointer, and it's easy to write an analog of "eval" by hand, using just a handful of arithmetic instruct…
Languages involve a lot of apparent mystification, in part because the syntax tree and the semantics of the syntax tree are not the program you are writing. Who knows what "class X {}" actually does to the (virtual) machine?
By essentially providing a 1:1 correspondence between the "real" semantics and the "apparent" semantics, programming this way can seem magical compared to other languages.
With assembly you arent taking objects of the language and making them objects of a metalanguage, ie. you arent preserving semantics when you abstract. All you're doing is creating hacks on top of the basic semantics, so in effect, introducing a new language (of specialized jumps, etc.).
Earlier quoted context omitted.
Things change. LISP was popular in the 1980s before caches, branch prediction, and complex memory hierarchies. The car/cdr list is just about the worst way to represent lists in terms of performance on modern CPUS. Conceptually it is really clean, but about the only application it makes sense for is first order theorem proving, or in languages that support pattern matching. If you actually want to use lists as lists…
Although it is called List Processing, it does support other types of data structures, including arrays. https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node158.html#... Don't blame the language for lack of programmer knowledge.
If you learn anything about binary search you should learn to avoid it. Even computer science books have a wrong implementation of it more than 50% of the time and, that, together with all the algorithms based on total ordering, tends to blind people to the fascinating world of algorithms that are based on partial orderings. 99% of the time you are better off using the hashtables that come with your language than you are to look into a "data structures and algorithms" book we're you'll probably pick something that performs worse and you'll screw up the implementation of.
(I recently wasted a few days coding up something that was "kinda like" binary search, but the analogy with binary search led me to think about it the wrong way.)
Today people still read the stuff on Random Number generators from Knuth, which was obsolete by 1985. It's very likely that the rand() function in your language comes out of Knuth, even though his stuff was completely superceded but what was in Numerical Recipes (Knuth never did scientiic computing) and the stuff in NR was obsolete by 1990.
They're removing rand() from the C++ standard library because they can't burn all the copies of Knuth fast enough to stop standard library implementers from reimplementing all the bad algorithms.