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

The Land of Lisp

landoflisp.com

Post reply on HN
Print view View original

131–140 of 146 posts

Re: The Land of Lisp

#131

Post by throwaway7645 »

TeMPOraL wrote: post #117
Vekz wrote: post #50

Earlier quoted context omitted.

Unfortunately, this web-based version is just printing text to the browser instead of a repl in the other examples.

Using a local web browser as your user interface is a valid method for making user interfaces; in fact, it's a very cool and cheap one - all it takes is to embed a HTTP server in your application and have it output HTML/CSS/JS (+ SVG for extra pretty graphics).

This is the standard way to do user interfaces in Picolisp. If you've never toyed with Picolisp, check it out. It is a very opinionated lisp.

https://picolisp.com/wiki/?home

Re: The Land of Lisp

#132

Post by throwaway7645 »

baldfat wrote: post #17
throwaway7645 wrote: post #6

I've read most of it too, but not sure it shows a lot of lisp's strengths. A lot of the programs I read them over and thought that I could do the same thing in significantly less Python code. I'm not sure what should be fixed if anything though.

> A lot of the programs I read them over and thought that I could do the same thing in significantly less Python code. My racket code is usually many time smaller then my Python code. The nice thing about Racket/Lisp is you can just make your own tools when in Python you copy thousands of lines of code into a one line code. The real fix that Lisp/Racket gives over Python is deployment.

Agreed on deployment.

Re: The Land of Lisp

#133

Post by flavio81 »

TeMPOraL wrote: post #114
flavio81 wrote: post #75

Earlier quoted context omitted.

> The main issue people have with the book is that it uses CLISP-specific code in a few places. This makes sense for a tutorial book, since CLISP is easy to install, very small to download (compared to SBCL), and is a fully featured (ANSI compliant) implementation. So i don't think it was a mistake to choose CLISP. The recommendation in #lisp for SBCL over CLISP might be because SBCL is nicer to the programmer, offer…

I'd add one more very popular implementation: CCL - Clozure CL Produces fast native code; compiles faster than SBCL. Also has some MacOS-specific goodies. People sometimes use both CCL and SBCL at the same time, to have faster compiling during development via CCL and then better runtime performance of the released version via SBCL. I used to use CCL for hobby gamedev back when SBCL had some troubles on Windows (they'…

Thanks TeMPOraL! I'll try CCL then!

Re: The Land of Lisp

#134

Post by flavio81 »

doktrin wrote: post #121
flavio81 wrote: post #37

Earlier quoted context omitted.

Hi doctor! The comic at the bottom of the web page got me laughing and in tears at the same time, in particular the line: "Back in the 80s we showed you how to program without ANY bugs ". Also, Java as a little tank, C# as a plane, Python as an helicopter... just brilliant. I almost rolled in the floor laughing by looking at that part of the strip. Certainly it is prophetic, it seems we're almost reaching the point o…

> Java as a little tank, C# as a plane, Python as an helicopter... just brilliant. I almost rolled in the floor laughing by looking at that part of the strip. Is there a special significance to the Java / Python / Ruby / C# representations? I feel like I missed the joke here, even though I enjoyed the strip as a whole.

Java as a tank - that is, slow (in development time) although resilient and all-terrain

Python as a helicopter - far more manuverable but slower than a plane and easier to take down

C# as a plane, fast and carries more cargo than an helicopter.

Ruby like some sort of convoluted laser beam weapon

Lisp dialects (on the strip) are all spaceships done using "secret alien technology". Even then, the insectoids are harder to kill than back in the 80s! What will the human+lispers alliance do? Read the strip for knowning what happens next!

Re: The Land of Lisp

#135

Post by flavio81 »

endgame wrote: post #111
drcode wrote: post #32

Earlier quoted context omitted.

Thanks for the kind words! Glad you enjoyed my book!

As an avid haskeller with a lot of respect for lisp, I've gotta say I really love the depiction of the Republic of Haskell as a police state, where side effects receive no mercy.

"Follow the simple rules..."

"I hereby pronounce you guilty... of having SIDE EFFECTS!"

Re: The Land of Lisp

#136

Post by flavio81 »

TeMPOraL wrote: post #115
Koshkin wrote: post #29

Earlier quoted context omitted.

From what I have seen, code that "goes straight to the point" is usually poorly thought out, is unmaintanable, has bugs, is difficult to extend to new use-cases, and the developer who wrote it is long gone.

No, it's the opposite - it doesn't have to drag around pointless layers of unused abstractions, and all the bugs that are there are bugs of subject matter, not of surrounding boilerplate. Such code minimizes the surface area and degrees of freedom, hence not leaving space for bugs. The more I program, the more I'm convinced that - unless you've coded identical software many times before - code needs to grow organical…

You should expand this into an article or blog post!

Re: The Land of Lisp

#138

Post by didibus »

klipt wrote: post #104
didibus wrote: post #97

Earlier quoted context omitted.

I question the downsides you suggest. There was a study done where they had two groups of people implement the same thing, one with a dynamic language, the other with its equivalent static variant. What they found was that the people who used the dynamic language took 33% less time to complete the task. But what's interesting is students who were given the static typed variant all said they felt the type system helpe…

> two groups of people implement the same thing The obvious problem with that is that dynamically typed languages are great for prototyping things ... and implementing something quickly for a study sounds like prototyping. But statically typed languages really shine for maintenance and refactoring.

> But statically typed languages really shine for maintenance and refactoring.

Possibly, I've not been able to find any research related to the impact of the typing discipline on maintenance.

All there is out there are studies on defect count of large code base projects. And those showed only marginal differences, certain dynamic languages like Clojure even beat out all others.

So at least in terms of maintening quality over time, dynamic languages seem to hold up to static languages.

What I've been trying to get data on is productivity over time. I know dynamic languages are more productive at the beginning, but do static languages get more productive over time is a good question. I still feel probably not, I think it's still just all a big feeling, but I've got no data on it.

Re: The Land of Lisp

#139

Post by TeMPOraL »

flavio81 wrote: post #136
TeMPOraL wrote: post #115

Earlier quoted context omitted.

No, it's the opposite - it doesn't have to drag around pointless layers of unused abstractions, and all the bugs that are there are bugs of subject matter, not of surrounding boilerplate. Such code minimizes the surface area and degrees of freedom, hence not leaving space for bugs. The more I program, the more I'm convinced that - unless you've coded identical software many times before - code needs to grow organical…

You should expand this into an article or blog post!

You know what? I might actually do just that; I just need to collect my thoughts and outline some examples.

Re: The Land of Lisp

#140

Post by nextos »

flavio81 wrote: post #75
stevelosh wrote: post #59

This book comes up in #lisp on freenode every so often, and the channel is generally split on whether or not to recommend it. I generally do. It's fun and lighthearted. Using games as a medium to teach the language is something some people enjoy, and is a lot less dry than most programming books. It avoids taking sides on the editor war, by just ignoring it altogether and teaching Lisp . This is refreshing compared t…

> The main issue people have with the book is that it uses CLISP-specific code in a few places. This makes sense for a tutorial book, since CLISP is easy to install, very small to download (compared to SBCL), and is a fully featured (ANSI compliant) implementation. So i don't think it was a mistake to choose CLISP. The recommendation in #lisp for SBCL over CLISP might be because SBCL is nicer to the programmer, offer…

CLASP is for me the most exciting CL implementation right now. Compilation to the LLVM is a huge advantage.

Sadly, it's a one-man thing. And CL seems quite stagnant.

I wish one implementation triumphed over the others, and CL progressed beyond its ANSI standard.

Clojure has many interesting things. So does Racket. The Lisp landscape is too fragmented. And thus libraries are a huge problem.

Post reply on HN