Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Idea of Lisp

dev.to

Post reply on HN
Print view View original

171–180 of 348 posts

Re: The Idea of Lisp

#171

Post by clarkd99 »

DonaldFisk wrote: post #110
clarkd99 wrote: post #98

Earlier quoted context omitted.

I can 'efficiently modify the lists you started with' with a dynamic multi-type array and I have cache locality and random access. I have a single data structure with an 8 byte overhead, 2 byte overhead per node that can be used as a tuple array with direct lookup, a single linked list, double linked list, a queue, a stack, and a balanced binary search tree. This whole structure is allocated in a single contiguous me…

I'd be interested to learn more about your language. Is there a web page about it, or a paper? Are you the D Clark who's at UCL? The way things are now can be changed. For most applications users care more about response times than CPU clock rates. Hardware has speeded up by several powers of ten (Moore's law) but software has at the same time slowed down (Wirth's law), resulting in little if any net gain, and that h…

David Clark is like John Smith and no, I am not any famous person but I have been around the micro computer world for a very long time (1975).

My website is www.rccconsulting.com where you will find an essay on the data structure I mentioned here called SLIST and some documentation and high level design for the system/language I am currently developing called MAX.

Users do care more about response times (as you say) and instantaneous and 1/2 instantaneous are considered equal by end users. Most user developed code doesn't need optimization but the data structures that under pin that user code should be as performant as possible, just in case.

Designing a language like Lisp or a special purpose language/system like I am creating have design criteria that is much different from the application programmer that is just trying to make stuff work. I have completed at least 1,000 projects big and small as an application programmer, as well as all the system programming I have done so I think I have a good incite into both points of view.

>> use of lists; most applications don't use them

You may be correct but most programs manipulate variable length character strings whether that is formatting, creating HTML documents, creating JSON data etc. Most currently used programming languages don't do variable length strings either well or efficiently. I also don't like the fact that almost all useful data must be manipulated and stored in database systems that reside somewhere other than my computer. My new system was designed to help solve that problem and more.

Re: The Idea of Lisp

#172

Post by smitherfield »

DonaldFisk wrote: post #162
smitherfield wrote: post #131

Earlier quoted context omitted.

I would argue that there's no such thing as a "functional data structure." If a data structure maps poorly to existing functional languages, that's a symptom of an insufficiently powerful and generic type system. Say you have (pseudocode) Array(4 16 5 20) What's its type? Array Array Array Array Array(Int Int Int Int) None of these lend themselves easily to paradigms other than imperative, true. But this is because t…

And if you want a new array whose first element is increased by one, you either have to allocate space for the entire array, modify the array, or use a different data structure.

No you don't, you merely need each index into an array to be a monad over all possible values it can contain. An array is itself and modifications are (take as arguments and return) its indices.

Re: The Idea of Lisp

#173

Post by pg314 »

clarkd99 wrote: post #55

This great idea of Lisp (the simple syntax of function calls in round brackets) isn't much different than a good macro assembler even back in the 1960's. The only major difference was that more than 1 function could be defined in 1 source code line. (I think that machine code is nothing but a sequence of function calls where the function is the logic encoded in the CPU itself for each opcode.) Is it fair to compare t…

> One last point about the linked list structure at the heart of Lisp. Linked lists are poorly executed in modern computers that rely heavily on locality of data, to optimize the L1 cache.

You could maybe say that linked lists are at the heart of the platonic ideal of Lisp. Naive interpreters might use linked lists in their internal representation. But real implementations of e.g. Common Lisp or Scheme provide a wide array of data structures (multi-dimensional arrays, hash tables, linked lists).

Re: The Idea of Lisp

#174

Post by pjmlp »

theseoafs wrote: post #142
crististm wrote: post #129

Earlier quoted context omitted.

Garbage collection is not necessary for lisp. Garbage collection only provides the illusion of infinite memory. Just like malloc/free.

I assure you that "malloc" and "free" don't "provide the illusion of infinite memory". Quite the opposite, in fact.

They do if always matched 1:1, it doesn't usually happen, specially in big codebases, thus leading to CVEs.

Re: The Idea of Lisp

#175

Post by pg314 »

rntz wrote: post #163
pg314 wrote: post #144

Earlier quoted context omitted.

And the implementation of garbage collection was, on at least two occasions, postponed. Once in the first implementation [1] and a second time in the early MIT Lisp Machines [2] (you just ran the machine until you ran out of memory which could take days or weeks, after which you saved the world to disk and rebooted). [1] http://www-formal.stanford.edu/jmc/history/lisp/node3.html [2] https://www.csee.umbc.edu/courses/…

"saving the world to disk and rebooting" sounds like a primitive form of garbage collection to me :)

It is. From that second link: "Such copying back and forth to disk was equivalent to a slow, manually triggered copying garbage collector."

Re: The Idea of Lisp

#176

Post by qwertyuiop924 »

pg314 wrote: post #144
crististm wrote: post #129

Earlier quoted context omitted.

Garbage collection is not necessary for lisp. Garbage collection only provides the illusion of infinite memory. Just like malloc/free.

And the implementation of garbage collection was, on at least two occasions, postponed. Once in the first implementation [1] and a second time in the early MIT Lisp Machines [2] (you just ran the machine until you ran out of memory which could take days or weeks, after which you saved the world to disk and rebooted). [1] http://www-formal.stanford.edu/jmc/history/lisp/node3.html [2] https://www.csee.umbc.edu/courses/…

McCarthy's writing style is highly entertaining. Although I still have no idea what "Pornographic Programming" is...

Re: The Idea of Lisp

#177

Post by dllthomas »

virtualwhys wrote: post #135
jimktrains2 wrote: post #76

Earlier quoted context omitted.

It's the same thing. It's a type with only a single value.

It's not the same thing, a value of type Unit can only produce a side effect (or do nothing at all).

How is that different from a value of type "empty tuple"?

Re: The Idea of Lisp

#178

Post by mamcx »

qwertyuiop924 wrote: post #167
jhbadger wrote: post #63

Earlier quoted context omitted.

Pity that it became so associated with the Tk GUI toolkit -- half the Linux GUI apps in the 1990s were in Tcl/Tk, and when Tk fell out of favor so did Tcl.

...And with TTK, you can finally have easy-to-write cross-platform UIs that actually look native. Seriously. If you want a decent cross-platform UI system with minimal effort, which has bindings in just about every language, TK is really worth your time now.

I have looked at it but don't find examples that truly look convincing,and the info in the official page look very sad.

http://wiki.tcl.tk/9485

Re: The Idea of Lisp

#179

Post by pjmlp »

qwertyuiop924 wrote: post #165
goatlover wrote: post #141

Earlier quoted context omitted.

I believe IO lets you do the same. Everything is a prototype with slots, communicating via messages. I guess Self was the same way. Self & Smalltalk also give you access to the entire runtime.

But TCL actually goes beyond that. Most languages of this sort, like Smalltalk, Lisp, and especially slower, more liberal implementations like PicoLisp, allow for compile-time and/or runtime AST transformation, and other sorts of metaprogramming. in TCL, everything is a string. Or at least, everything behaves like a string in the proper context. When you pass code blocks into a command (like if, or while, or whatever…

Smalltalk just like Lisp has very little syntax, almost everything is built on messages, including data type creation, conditionals and loops, among other things.

Also you can at any time just completely replace one object by other via the becomes: message.

There are also some cool tricks when metaclasses are used, many of each one can see in Python as well.

Re: The Idea of Lisp

#180

Post by theseoafs »

pjmlp wrote: post #174
theseoafs wrote: post #142

Earlier quoted context omitted.

I assure you that "malloc" and "free" don't "provide the illusion of infinite memory". Quite the opposite, in fact.

They do if always matched 1:1, it doesn't usually happen, specially in big codebases, thus leading to CVEs.

They surely do not. Malloc is specified in such a way such that the request for memory can fail (which leads to returning NULL).
Post reply on HN