The Idea of Lisp • Hacker News Board

Re: The Idea of Lisp

#311

Post by roganp » Sat, Dec 17, 2016, 2:37 PM UTC

amag wrote: post #263

rntz wrote: post #188

Earlier quoted context omitted.

The specification allows for this, yes. However, on some platforms (including linux glibc by default, I believe), malloc() never fails, but allocates virtual memory optimistically; the first you hear of an out of memory condition is when the system slows down due to paging, and the next thing you notice is when the OOM killer nixes a process. Of course, other platforms, especially embedded ones, behave differently.

Actually there is one reason for malloc to return NULL even with virtual memory, your process can run out of address space.

Or run out of room in the paging file. Your addressable memory cannot be larger than physical memory without a backing store.

Re: The Idea of Lisp

#312

Post by markc » Sat, Dec 17, 2016, 3:00 PM UTC

Blackthorn wrote: post #36

erik14th wrote: post #18

I wonder why lisp isn't as popular as say python for AI, ML, and stuff. I see these fields as having a strong academic tone, and it feels like racket or clojure could be bigger when it comes to that.

Well, it was. Specifically, Common Lisp was. But that language's standard was etched in stone in 1994 whereas languages like Python (where most deep learning user-facing code is done) continue to evolve. I think Python really took off for that because it already had quality and widely-used libraries for writing the code in Python and doing the work in a more efficient place (numpy, scipy). Clojure has one of those fo…

Clojure matrix libs:

    https://github.com/mikera/core.matrix
    https://data-sorcery.org/
    https://github.com/mikera/vectorz-clj
    http://neanderthal.uncomplicate.org/
    https://github.com/tel/clatrix

Re: The Idea of Lisp

#313

Post by Ericson2314 » Sat, Dec 17, 2016, 3:11 PM UTC

stcredzero wrote: post #156

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.

Challenge: Write a Turing complete machine using a finite number of registers and a state machine. One or all of the registers can contain a rational number of unlimited precision. (This has already been done, so if you are aware of the existing machines, you have to create a new one.)

This...is not possible?

Re: The Idea of Lisp

#314

Post by Ericson2314 » Sat, Dec 17, 2016, 3:18 PM UTC

theseoafs wrote: post #147

jimktrains2 wrote: post #76

Earlier quoted context omitted.

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

`void` in C does not have a value. You can't make a variable and put a void in it because there is no such object as "void".

That is an artificial restriction if C. Also see how ! In Rust is also loosing it's artificial restrictions.

Re: The Idea of Lisp

#315

Post by junke » Sat, Dec 17, 2016, 3:26 PM UTC

DonaldFisk wrote: post #310

smitherfield wrote: post #225

Earlier quoted context omitted.

Same as in a higher-level statically typed imperative language: mutable arrays contained within larger dynamic buffers for amoritized constant-time append and prepend.

So it isn't really functional at all. It just hides the side effects behind a lot of complexity.

This is precisely what functional programming does. Purely functional abstractions are just that, abstractions.

Re: The Idea of Lisp

#316

Post by rwallace » Sat, Dec 17, 2016, 3:33 PM UTC

ChicagoBoy11 wrote: post #99

tyleraldrich wrote: post #65

Earlier quoted context omitted.

You may be interested in checking this out for inspiration: http://www.ccs.neu.edu/home/matthias/HtDP2e/ (It's the Intro to CS book used at my alma mater, teaching programming in Racket)

Tried doing some of that with High School kids -- I have to admit, at the beginning it was very difficult for them to wrap their head around the basic concepts in functional programming. The other issue was that the few syntactical rules and prefix notation, while great in the long term, required the kids to do a bit more of mental gymnastics for even basic things at the beginning, so that didn't help either. But man…

I have met people who were already earning a paycheck as professional C programmers, who didn't fully grasp what it meant to return a value from a function. If I were teaching beginners these days, I would do what SICP does and tackle the substitution model of evaluation head-on at an early stage.

Re: The Idea of Lisp

#317

Post by kazinator » Sat, Dec 17, 2016, 4:16 PM UTC

anoctopus wrote: post #294

qwertyuiop924 wrote: post #258

Earlier quoted context omitted.

Clojure's an odd, unlispish language, at least for us Lispers and Schemers. CL is still very good at what it does: all current implementations have solved many of the problems you mentioned, and there are a lot of libraries that will run across implementations. CL is a beast, but clojure is a mess. Scheme is elegant, but has a radically different, more ALGOL mentality than CL, at least in some respects. Some of it is…

Could you explain what you think is wrong with Clojure? Maybe it's because I've spent far more time using it than CL, but I see Clojure as having a very consistent, well designed core. It's very opinionated in it's design, but it's a practical and pragmatic one. I don't see what's unlispish about it.

All that immutability humbug, for starters. Traditional Lisps are "everything you can access is mutable".

Lisp trusts the programmer to be responsible with mutability and not to abuse it. The trust is not misplaced; the sky doesn't fall.

Re: The Idea of Lisp

#318

Post by kazinator » Sat, Dec 17, 2016, 4:50 PM UTC

Retra wrote: post #295

kazinator wrote: post #279

Earlier quoted context omitted.

That might not meet some expectations behind the word "properly".

Such expectations would have little to do with Lisp. Even one with a garbage collector can run out of memory. How quickly that happens and how it handles it is just a matter of how good of a garbage collector you have.

Nobody in this thread has claimed that program's reachability graph always magically fit into available RAM, if only a garbage collector is present.

> How quickly that happens and how it handles it is just a matter of how good of a garbage collector you have.

It depends on the object size, how well objects are packed, and how much memory you have. Waste cannot be better than zero, so we have an upper bound on hitting OOM.

The lower bound (under non-compacting allocation) depends on the size ratio between the smallest and largest object. This is explored in paper by J.M. Robson (JACM 18, 416-423, [1971]) where Robson shows (IIRC, using only power of two block sizes, but arguing that the result is general) that an allocator client can be so contrived as to bring about the worst case whereby the heap consists only of the smallest objects, spaced apart just close enough that a request for the largest object can then be made, which fails. The memory utilization at that OOM moment is then the ratio between the size of the smallest and largest object. Robson's important argument is that an allocator has no way to defend against this problem. Regardless of its strategy for placing requests, the client can be contrived to tickle the worst case.

Fragmentation is not necessarily GC's fault; some objects just can't be moved. Objects which are opaque memory managed by a foreign library API pose an intractable problem in this area. There are good rationales for a non-compacting GC; non-compacting doesn't make it "bad".

Without GC, there is no lower bound on the amount of reachable data which exists under OOM. A tight loop which repeatedly calls cons will hit OOM.

Re: The Idea of Lisp

#319

Post by dTal » Sat, Dec 17, 2016, 6:30 PM UTC

qwertyuiop924 wrote: post #259

cicero wrote: post #199

Earlier quoted context omitted.

Even Schemes can take a practical turn, e.g. Racket.

Racket isn't Scheme. It is its own dialect. That's why it's no longer called Scheme. At present, there are only a few Schemes that are practical: Chicken, Guile, Chez, and Gambit seem to be the big players, with Cyclone, Chibi, and Bigloo bringing up the rear.

Wow, pedantic much? It started out as a pure Scheme, then "took a practical turn" as the parent said. You can still make it act like a pure Scheme with a #lang directive.

It's also kind of funny that a handful of major, practical implementations is considered a low amount. Number of Python implementations? Between one and three, depending on definition. Number of Javas? 2 or 3 again. Number of Clojure implementations? One. Javascript? Half a dozen at most.

Seems to me like the problem is standardization between these implementations, not overall number.

Re: The Idea of Lisp

#320

Post by prodigal_erik » Sat, Dec 17, 2016, 6:33 PM UTC

roganp wrote: post #311

amag wrote: post #263

Earlier quoted context omitted.

Actually there is one reason for malloc to return NULL even with virtual memory, your process can run out of address space.

Or run out of room in the paging file. Your addressable memory cannot be larger than physical memory without a backing store.

Depending on VM_OVERCOMMIT_MEMORY, Linux might give out address space well beyond the size of the pagefile, hoping many of those pages are never written to (e.g., most threads never get anywhere near the bottom of their default stacks).