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

How Lisp is Going to Save the World

landoflisp.com

Post reply on HN
Print view View original

151–160 of 239 posts

Re: How Lisp is Going to Save the World

#151

Post by neeleshs »

Lapsa wrote: post #106
martinced wrote: post #85

Earlier quoted context omitted.

"The truth is, it's all state. All of it." The problem is not state. The problem is being able to recreate the state: both for testing and for business purposes. The bigger problem is that most programmers, like you, are knee-jerking before the issue of "recreating the state" and declaring that "It cannot be done, because it's all state" . And hence we have both languages who are build by considering mutability to be…

Try googling around for "cqrs". There are many ideas on how to do exactly this effectively. All it takes is to swap "write" operation with "event" entity (all is state). Combine that with intention revealing commands (customer_died instead of delete from customers where id=1) and you hit jackpot. End result is nice stream of events which is ultimate source of truth and enables crazy queries you never thought you woul…

This is quite interesting. In practice though, the lags between command/query models when the datastores are different(almost always, for large data) becomes a real concern

Re: How Lisp is Going to Save the World

#152

Post by jjwiseman »

muuh-gnu wrote: post #48
lispm wrote: post #39

Earlier quoted context omitted.

> No free implementations existed during a key period BS. CMUCL. AKCL. CLISP.

OK, let me correct myself: No competitive free implementation existed able to take a leading position and bootstrap the ecosystem, like gcc, cpython, perl and javac did for their respective language ecosystems. I did not intend to imply that nothing. existed. whatsoever. cmucl, gcl (akcl) and clisp even today are insignificant also-rans and basically unmaintained abandonware.

In 2002 I was trying to use free Lisps in production and finding it untenable due to serious bugs in fundamental areas like network sockets, and terrible support for threads. I was also surprised that implementors didn't seem to take these issues seriously.

It was very disappointing compared to my experience using commercial Lisps like Allegro Common Lisp and Macintosh Common Lisp in grad school in the mid 90s. They weren't perfect, but MCL on a machine with lots of memory was a pleasure I will always remember.

Re: How Lisp is Going to Save the World

#153

Post by tbirdz »

spacemanaki wrote: post #95
slurry wrote: post #87

Earlier quoted context omitted.

> Did you read the manual? For real? > It's not as easy as setting breakpoints in an IDE I don't use an IDE. I'm comparing against command line tools for scripting languages, Haskell and Common Lisp. Some fail more helpfully than others.

Sorry for my tone, I guess YMMV... I just never had any issue with MIT Scheme's debugger, although I admit that CL with SLIME is a bit more useful, especially compared to MIT's weird Emacs-clone (or -fork?) "Edwin".

For a slime like repl for scheme, you might want to check out geiser: http://www.nongnu.org/geiser/

It works great for guile and racket.

Re: How Lisp is Going to Save the World

#154

Post by jhuni »

nemetroid wrote: post #86

I had Haskell as the subject in my intro course at university (my first experience with functional programming). I've tinkered a bit with it since then as well, and I'm at the "somewhat intuitive grasp of monad transformers" state. I tried Clojure some week ago through the Clojure koans that were posted here. Compared to Haskell I found the syntax very obtuse and it was not obvious why Lisp would be more powerful tha…

> Compared to Haskell I found the syntax very obtuse and it was not obvious why Lisp would be more powerful than Haskell.

What do you mean by "obtuse"? If by that you mean difficult to understand, Haskell's syntax is far harder to understand because it has operator precedence tables. Even if you manage to memorize the language's built in operator precedence levels developers can define their own operators with custom associativity and precedence.

I will take the uniformity of Lisp syntax rather then the complicated, incomprehensible, and hard to parse syntax of Haskell any day. Lisp syntax is so much simpler then syntactic languages like Haskell that you can even build a simple reversible parser that converts textual code to and from list structures with whitespace metadata: http://lisp-ai.blogspot.com/2012/09/reversible-lisp-reader.h....

Re: How Lisp is Going to Save the World

#155

Post by thecombjelly »

I love lisp. I use/used it to build my web service product[1] and anything else I can.

=how do I do X?=

java: something similar to X is already done in Y. add abstract class and redo X and write Y. +200 LOC

lisp: something similar to X is already done in Y. realize you can generalize X and Y into a new pattern and use it for ABC too. -70 LOC

=there is a bug in function X=

java: open X.java. edit line. restart program. X seems to be working correctly.

lisp: two hours later, ah ha! I understand this code. fix X. write unit test. eval unit test. X works correctly.

[1] demo: https://a.keeptherecords.com/demo, source: https://github.com/ThomasHintz/keep-the-records

Re: How Lisp is Going to Save the World

#156

Post by andolanra »

king_magic wrote: post #138
jeffdavis wrote: post #129

Earlier quoted context omitted.

"The only way to reduce bugs is to test thoroughly." That is false.

No, it's not false, but I'll rephrase it to illustrate my point: "the only economically practical way to reduce bugs is to test thoroughly, unless you're NASA or you have some magnificent budget that somehow lets you hire people who can mathematically prove your code is bug free". I am aware that you can prove code is correct, from a math POV. That's about the only way you can write "bug free" code without extensive…

Type systems are, in essence, automated mathematical theorem provers designed to prevent certain classes of bugs.[1] The functional style is also a bug-reducer in that you can reason more accurately about the state of your program, because you have limited state-changing code to particular places. Certain language features like Lisp's restarts or garbage collection are bug-reducing because they give you concise ways of expressing features you might otherwise have had to implement by hand, and every line of code you write is another line for a bug to hide in.

Yes, testing is invaluable and should not be omitted. No, none of these are silver bullets that eliminate the need for testing. But it is false to say that "...the only economically practical way to reduce bugs is to test thoroughly." There are many ways to reduce bugs that can help alongside testing.

[1]: If you've only ever used C++ or Java, this sounds hilariously weak, but in languages like the ML, the type system prevents null pointer exceptions, and in Haskell, the type system goes further and separates effectful and non-effectful code to ensure you don't cause side effects where you don't expect. Even more powerful are languages like ATS, which give you compile-time type errors when you've forgotten to allocate space for a null terminator for strings.

Re: How Lisp is Going to Save the World

#157

Post by jhuni »

jeffdavis wrote: post #128
nemetroid wrote: post #86

I had Haskell as the subject in my intro course at university (my first experience with functional programming). I've tinkered a bit with it since then as well, and I'm at the "somewhat intuitive grasp of monad transformers" state. I tried Clojure some week ago through the Clojure koans that were posted here. Compared to Haskell I found the syntax very obtuse and it was not obvious why Lisp would be more powerful tha…

"Compared to Haskell I found the syntax very obtuse and it was not obvious why Lisp would be more powerful than Haskell." Language "power" is ill-defined, and basically means "good". If you think that homoiconicity is good, then you probably like lisp. If you think that referential transparency is good, then you probably like haskell. Those are mutually exclusive, so one language can't really have both. But either on…

> Those are mutually exclusive, so one language can't really have both.

There are Lisp computer algebra systems like Maxima and Axiom that can be used for advanced term rewriting operations. Referential transparency, which is replacing terms with their definition, is just a very simple term rewriting operation.

Re: How Lisp is Going to Save the World

#158

Post by klibertp »

king_magic wrote: post #138
jeffdavis wrote: post #129

Earlier quoted context omitted.

"The only way to reduce bugs is to test thoroughly." That is false.

No, it's not false, but I'll rephrase it to illustrate my point: "the only economically practical way to reduce bugs is to test thoroughly, unless you're NASA or you have some magnificent budget that somehow lets you hire people who can mathematically prove your code is bug free". I am aware that you can prove code is correct, from a math POV. That's about the only way you can write "bug free" code without extensive…

> They exist in CPUs. They exist in configuration. They exist in dependency version mishaps [...]

They exist in software assisting with formal methods usage too, but what's worse is that frequently implementation is sound and the program still works incorrectly because of erroneous assumptions or bugs in specification. So no, you cannot be sure that your program is bug free without running it... I'm not sure if it is possible to get to being 100% correct in reality - what with cosmic rays altering memory and such...

Re: How Lisp is Going to Save the World

#159

Post by king_magic »

jeffdavis wrote: post #148
king_magic wrote: post #138

Earlier quoted context omitted.

No, it's not false, but I'll rephrase it to illustrate my point: "the only economically practical way to reduce bugs is to test thoroughly, unless you're NASA or you have some magnificent budget that somehow lets you hire people who can mathematically prove your code is bug free". I am aware that you can prove code is correct, from a math POV. That's about the only way you can write "bug free" code without extensive…

I think what you mean is "any efficient engineering process will make good use of testing". But if you already have some tests in place, the most efficient way to reduce bugs is often something other than more testing, e.g. code review, design review/improvements, or static analysis (often provided by the language/compiler). All of those other methods can and will reduce bugs. So your statement that testing is the on…

I see your point. Fair enough :)

Though I'd argue those other methods really boil down to testing. Code review is a peer "test" of code. Design review is a peer test.

Re: How Lisp is Going to Save the World

#160

Post by [deleted] »

andolanra wrote: post #156
king_magic wrote: post #138

Earlier quoted context omitted.

No, it's not false, but I'll rephrase it to illustrate my point: "the only economically practical way to reduce bugs is to test thoroughly, unless you're NASA or you have some magnificent budget that somehow lets you hire people who can mathematically prove your code is bug free". I am aware that you can prove code is correct, from a math POV. That's about the only way you can write "bug free" code without extensive…

Type systems are, in essence, automated mathematical theorem provers designed to prevent certain classes of bugs.[1] The functional style is also a bug-reducer in that you can reason more accurately about the state of your program, because you have limited state-changing code to particular places. Certain language features like Lisp's restarts or garbage collection are bug-reducing because they give you concise ways…

[deleted]
Post reply on HN