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

Common Lisp homepage

lisp-lang.org

Post reply on HN
Print view View original

281–290 of 313 posts

Re: Common Lisp homepage

#281

Post by jabl »

foo101 wrote: post #261
oblio wrote: post #259

Earlier quoted context omitted.

You seem to be a bit too... enthusiastic about this conversation, for my tastes :) I won't go into everything cause it would take way too much time, but I have to point one thing out: > Optional typing dramatically increases execution speed, something that is very relevant and important in 2018. As compared to what? I'm guessing your assumption was that I was thinking about purely dynamic languages? Not really, I was…

I don't understand what point is. Do you agree that Lisp metaprogramming has benefits or do you disagree with that? If you agree, then what is your point? That we should not use a powerful language because it is not popular? Or that features in popular languages are the only features worth having? If you disagree, can you elaborate what exactly about Lisp metaprogramming do you not find powerful? That would make your…

If you're choosing a powerful but "unpopular" language, perhaps a more interesting comparison would be between lisp and, say, haskell.

Sure, you're sacrificing homoiconity and macros, but you get strong static typing and purity etc.

Re: Common Lisp homepage

#282

Post by jabl »

deepaksurti wrote: post #258
oblio wrote: post #88

Earlier quoted context omitted.

If by ASP you mean classic Visual Basic, I'll grant you that. And Pascal. But ML, Eiffel and Modula were never mainstream. And Perl, Fortran, Cobol probably still have more programmers out there than Common Lisp has :)

And the fewer CL programmers will run circles around P, F, C programmers :-)

So, why don't they? ;)

Why is viaweb and ITA trotted out decade after decade? If CL is so awesome why isn't the world filled with awesome stuff implemented in CL?

(To be clear, IMHO it's a huge shame that more powerful languages like CL or Haskell aren't more popular)

Re: Common Lisp homepage

#283

Post by arf »

drmeister wrote: post #64

This is a very nice web site describing a programming language with unparalleled expressiveness, power and permanence. I am heavily invested in Common Lisp. We are developing a programming environment for designing new materials and molecules called Cando ( https://github.com/drmeister/cando ) using Common Lisp as a scripting language. Cando is running on Clasp ( https://github.com/clasp-developers/clasp ), a new Com…

Have you tried other Lisps like Racket? If so, what's your take on them and how do you compare them with CL?

Re: Common Lisp homepage

#284

Post by arf »

Is there a way to find well-maintained non-broken preferably-actively-maintained libraries or those that the community considers to be the de facto solution? Like where would I start with doing data science or web dev (and related subjects like encryption and auth etc) or things like async or parallel programming?

Re: Common Lisp homepage

#285

Post by WindowsFon4life »

susam wrote: post #9

Often those who are curious to try Lisp are faced with a number of choices: Which dialect to choose? Which implementation to choose? Which book or tutorial should one follow? Is it necessary use Emacs? SLIME? Here are my recommendations: - Choose Common Lisp because it has been the most popular dialect of Lisp in the overall history of Lisp. It is more convenient than Scheme if one decides to develop serious software…

The only Cl implementations worth using are those with roots in the real CL. imho.

Re: Common Lisp homepage

#286

Post by WindowsFon4life »

nerpderp83 wrote: post #115

This is not good , the info density for the screen area is too low. This could have been one maybe two screens worth. Is this the credits to Friends? Am I consuming Lisp Content while chillin in my penthouse on my 20k couch using a gold plated IPad X Tablet? Millennials are Killing Common Lisp. one page, https://www.rust-lang.org/en-US/

Exactly this. "Fluff" for something that does not lack an online documentation experience.

Re: Common Lisp homepage

#287

Post by catnaroek »

hyperion2010 wrote: post #279
catnaroek wrote: post #80

Earlier quoted context omitted.

Typed Racket is more ambitious than other attempts at adding types to an underlying untyped language. Namely, Typed Racket guarantees that typed code is never to blame for certain contract violations, and, if any such contract violation happens, it will be properly traced back to an offending piece of untyped code. This is what makes gradual types gradual (as opposed to merely optional), alas, it is also what has bee…

I think this is the correct video link. https://www.youtube.com/watch?v=5DlEj6daNEo

Oops, sorry, yes.

Re: Common Lisp homepage

#288

Post by flavio81 »

jabl wrote: post #281
foo101 wrote: post #261

Earlier quoted context omitted.

I don't understand what point is. Do you agree that Lisp metaprogramming has benefits or do you disagree with that? If you agree, then what is your point? That we should not use a powerful language because it is not popular? Or that features in popular languages are the only features worth having? If you disagree, can you elaborate what exactly about Lisp metaprogramming do you not find powerful? That would make your…

If you're choosing a powerful but "unpopular" language, perhaps a more interesting comparison would be between lisp and, say, haskell. Sure, you're sacrificing homoiconity and macros, but you get strong static typing and purity etc.

True, but they support entirely different philosophies to software development: the "build a cathedral" (Haskell) versus "create a living organism" (Lisp), to paraphrase an Alan Perlis quote.

Re: Common Lisp homepage

#289

Post by e12e »

pjmlp wrote: post #128
rjsw wrote: post #68

Earlier quoted context omitted.

Lisp ran on the first UNIX workstations too, Franz Lisp ran fine on even the earliest Sun machines. Lucid pivoted from Lisp on UNIX to C++ on UNIX, they didn't have anything to do with Lisp Machines.

Correct, but it wasn't part of the platform tooling, requiring an additional expense, with a price tag which on the 80's computing world very few companies were willing to shell out. Yep, I always get that part of Lucid's history wrong.

> wasn't part of the platform tooling

I think lisp did (to a lesser extent still do) suffer from the "whole system syndrome" that also affected Smalltalk; I'm still not sure that I'd find it comfortable to marry small lisp programs with a shell pipeline, or convenient to work with sockets, files or even databases in a familiar way from within common lisp. Nor would i know how to easily share such code (although quicklisp has made strides her).

That is to say, you could probably write ansible/puppet in common lisp - but I'm not sure if you should.

Certain special programs, like unison (in ocaml)[1] combine breaking new ground, doing something a little complicated - and justify the use of a powerful language. Other examples might be pandoc (haskell) or gnu guix (scheme software/Os manager).

Perhaps it's wrong to throw scheme under the bus, for common lisp being too full of features.

But my (admittedly superficial) impression is that even "pragmatic" schemes tend to be difficult to integrate as system glue; that means both on a single platform (use for scripting, piping files, writing config files, start/stop services - Running Os commands) and as cross-platform (either distribution of artifacts for different systems, like an exe for Windows and elf binaries for Linux and bsds - or readily available run-times that work well on multiple platforms).

It may well be that many of these issues are fixed today - but the impression that sbcl is a poor fit for a system language for writing parts that are easy to integrate well remain. Both if you want a deb/msi package of a gui app, and if you want to drop some binaries in /usr/local/bin to call snippets of code that work well with the shell.

[ed: What is funny/sad is that java kept almost everything that was bad with lisp/smalltalk, and very few of the really good parts. But they introduced a more familiar api for files, streams etc - and managed to push for the jvm to be installed everywhere.]

[0] http://www.cis.upenn.edu/~bcpierce/unison/index.html

Re: Common Lisp homepage

#290

Post by lispm »

e12e wrote: post #289
pjmlp wrote: post #128

Earlier quoted context omitted.

Correct, but it wasn't part of the platform tooling, requiring an additional expense, with a price tag which on the 80's computing world very few companies were willing to shell out. Yep, I always get that part of Lucid's history wrong.

> wasn't part of the platform tooling I think lisp did (to a lesser extent still do) suffer from the "whole system syndrome" that also affected Smalltalk; I'm still not sure that I'd find it comfortable to marry small lisp programs with a shell pipeline, or convenient to work with sockets, files or even databases in a familiar way from within common lisp. Nor would i know how to easily share such code (although quick…

> I think lisp did (to a lesser extent still do) suffer from the "whole system syndrome

There are a bunch of problems of Lisp for systems/application programming:

  * dynamic typing and dealing with runtime errors
  * garbage collection vs. real-time response
  * amount of memory used is usually higher for GCed systems
  * interoperability with C code and code in other languages
  * abstraction mismatch between C code and Lisp code.
  * the need for a foreign function interface to inter-operate with C code
  * the integration with C++
  * the minimum size of a program and how many programs can be started
  * sharing much of the runtime and library
When people started to write lots of Lisp code (80s) then the question of delivery came up. The were a bunch of responses to that:

  * don't run systems and applications in Lisp,
    for example rewrite the Lisp applications into C++
    (smaller footprint, possibly faster execution, ...)
  * develop new Lisp-like programming languages,
    but which are more efficient to implement.
    Example: Apple's Dylan or see Dynace ( https://github.com/blakemcbride/Dynace )
  * develop special Lisp implementations which address
    the above issues and are specialized in application
    delivery
Let's look at the latter approach.

Germany had for example the Apply project which for example created the CLICC compiler ( https://www.informatik.uni-kiel.de/~wg/clicc.html ). CLICC is a whole-program compiler for a restricted subset of Common Lisp. mocl is based on CLICC and was/is a commercial CL compiler for macOS X, Android and iOS.

There are a bunch of similar compilers (Thinlisp is one https://www.cliki.net/ThinLisp ). Many years ago Oracle also bought an Lisp compiler (which was very expensive for users, IIRC in the range of $100k), which actually generated 'maintainable' C code.

Another interesting system is WCL: https://github.com/wadehennessey/wcl WCL allows one to use Common Lisp as a shared library (mostly). Each Lisp application starts with tiny RAM usage and tiny application size. This allows to run possibly hundreds of smallish Lisp applications at the same time.

Eclipse was a Common Lisp which has a direct integration in C and compilation to C, which made something like a Foreign Function interface unnecessary: https://github.com/blakemcbride/eclipse-lisp

Generally these tools are often 'old', not widely used and not many applications have been written with them.

Post reply on HN