On Lisp

Of course, it's feature complete!

Common Lisp is its own standard library. Here are its contents: http://www.lispworks.com/documentation/HyperSpec/Front/index.htm

It's got a whopping 980 functions for all your needs with intuitive and easy to remember names like least-negative-normalized-double-float, update-instance-for-redefined-class, load-logical-pathname-translations, simple-condition-format-arguments, internal-time-units-per-second, pprint-exit-if-list-exhausted and so on. Of course, it purposefully lacks the negligible nonsense like a graphical toolkit, image processing, nonblocking asynchronous IO, remoting, cryptography, SQL, text processing, archive tools, concurrency, parallelism, thread-safe data structures, monitoring & management, printing support, sound and processing, XML toolkits - all of that is useless, after all! The most important thing is that you get to use anaphoric lambdas and pandoric captures whilst munching on momma's tasty soup!

Seriously, you say "a core library" as if Lisp is a practical general-purpose PL. It's a lie. Lisp is no such thing, hence such a short stub in place of a core library and a trashpile of unmaintained cruftworks from fanboy-soup-eaters (a.k.a. CLiki). Look at the core libs of industrial-strength languages like Java or Python. They were forged in the fires of practical problem-solving over many years. While the Lispers have spent the whole 50 years of their totem's existence forging only one thing: their self-aggrandizement.

Although, to do Lisp justice, it should be noted that Franz and Allegro did crank out their bicycle-crutch-ersatz-"core" libraries. This is because during lisp-hype of the 80-90ies these gescheftmachers have managed to get several rich yet clueless Pinocchios addicted to the Lisp drug. Like Boeing, for example. And when the Pinocchios started trying to solve real problems lispishly, they had to hurriedly plug that gaping hole. So go ahead and spend some $4500 for a real Lisp - it's an easy sum for a Lisper, right? - and welcome to the miraculous world of Professional Lisp Pinocchios.

p.s. install gentoo

>>1

Common Lisp is a language. Systems or applications stuff wasn't standardized, because that is the stuff you build with a language, not the language itself.

To understand this approach study e.g. the character or file dictionaries, and why they are the way they are (this should illuminate many things).

Even implementation details were delibarately less specified (see environment).

There are standards for some things e.g. CLIM.

Also Lispers are not plumbers. Libraries and frameworks that would take a matter of weeks for average e.g. Python programmers to write are written by Lisp programmers in a matter of hours. Lispers consider it an insult to use someone else's programs, unless they have been vetted over 30 years and implemented as a fundamental part of a Lisp operating system running on a Lisp machine.

Lisp is not a plumbing language. For example Common Lisp pretends UNIX does not exist, because simply put, it should not. It is a travesty, and Lispers will not compromise.

So if you come to Common Lisp expecting facilities for plumbing UNIX or Windows or whatever you will be disappointed by what the language itself provides.

However, implementations provide some facilities in these ragards, which are slowly becoming canonicized over time (e.g. Bordeaux threads)

easy to remember names like least-negative-normalized-double-float
Hilarious.

What else would you call least-negative-normalized-double-float? std::numeric_limits<float>fuck_you()?

Common Lisp is the only language I have used with a sane number heirarchy/library/dictionary/whatever

Every other language gets something subtly wrong (Haskell), or is just stupidly limited (C family).

>>5
Well for one I wouldn't put subtraction/negation signs in function names because it's just silly.

>>6

Those "subtraction/negation" signs are called "hyphens".

>>1

LOL That's not the standard library. That's THE standard (i.e. a standards document) but in HTML form.

>>7
No.
The meaning of symbols shouldn't be so context sensitive.
That's just bad language design.

>>9

It's not "context sensitive" anymore than the 'f' in float and for is context sensitive in C.

You don't know what context sensitive means.

>>7
Then why are they on my number pad?
I know it's because ASCII is shit and we should all be using Space Cadet keyboards on Lisp machines.

>>10
Or anymore than j-i is different from j - i.
Yes, I am aware that Lisp uses polish notation with parenthesis for delimitation because it's hipster like that. Doesn't make it any less silly.

>>11

The space cadet was but one (early) Lisp machine keyboard.

Some Lisp machine keyboards were very different e.g. the Fujitsu FACOM Alpha keyboard had Japanese letters (I do not know Japanese)

>>12
And now that I think of it, using * to dereference pointers in C was also a stupid idea.
They should have used a completely separate symbol like $ or #.

>>12

There's nothing "hipster" about it.

Since the beginning of Lisp there have been efforts to change the textual syntax, each with its own tradeoffs.

In the 50s and 60s McCarthy and others put some effort in Lisp 2 (the successor to Lisp 1.5) which would use "M-Expressions" (very similar to what Mathematica uses today).

Apple's Dylan used s-expressions for its textual syntax at first, but then switched to an infix notation.

David Moon has recently described PLOT, which is similar to Dylan.

There is also Wheeler's "sweet expressions" or "readable s-expressions" (I don't like the latter name).

However the main Lisp line (i.e. Common Lisp, ISLisp etc.) uses "old school" S-expressions, because Lisp programmers simply find them useful for writing their programs.

You have to understand Lisp has been around for a very very very long time. Every language feature under the sun has appeared in some Lisp offshoot or another. Most languages in some way owe part of themselves to Lisp 1.5.

Lisp today(i.e. Common Lisp) is a really really good set of trade offs re: language design. But it is tradeoffs; you can't have everything (e.g. Common Lisp has no continuations cause we want (a working) unwind-protect).

This is why other languages which share a common predecessor (e.g. Scheme) are around today; they make different tradeoffs.

I almost forgot to say:

The reason Lispers like s-expressions is because they "mirror" (I can't think of a better word atm) Lisp forms (i.e. the objects (in memory) the compiler (or interperter) sees).

Different textual syntaxes either require a different and harder to work with (programatically) intermediate representation (again using that loosely) OR a more complicated reader (and a less direct mapping between what are called "forms" and the textual syntax used to represent them) (the advantages and disadvantages of each approach I hope is clear).

That what the "structure" part of the book "structure and interpertation of computer programs" refers to: the fact that you can see the structure of your program right there in front of your eyes in a very similar way to how a computer program can see it.

I also personally really like how s-expressions are indented and printed.

>>14

I'm not sure you're aware but any character can be used as part of a symbol name in Common Lisp. The reader accepts the textual syntax |like this :)| to delimit literal symbol names. Now, \ and | have to be escaped: this should explain it (note the multiple escape levels due to how the reader treates ""):

CL-USER> (symbol-name (read-from-string "|some stupid \\\| name :)|"))
"some stupid | name :)"

This probably all looks like gobbledigook.

The standard explains it best:
http://www.lispworks.com/documentation/HyperSpec/Body/02_.htm
http://www.lispworks.com/documentation/HyperSpec/Body/23_.htm

>>11

How characters are encoded is considered an implementation detail in Common Lisp. Common Lisp characters are objects, they are a distinct type from numbers. Character objects can have implementation defined attributes e.g. a face (i.e. font color etc.).

Most Common Lisp implementations today use some unicode and integers with regards to char-code and code-char

http://clhs.lisp.se/Body/13_a.htm

Specifically:
http://clhs.lisp.se/Body/13_ac.htm
http://clhs.lisp.se/Body/13_ai.htm

And for today's (okish) most used character encoding system:
http://quickdocs.org/trivial-utf-8/api

>>12

Last thought on this whole s-expression and syntax thing:

There exist two things called a "structure editor" (unfortunately two things. In the Lisp world it always meant one and one thing only, till a bunch of not very intelligent people encountering some language loosely related to Lisp (e.g. Clojure or Scheme) and hearing about the concept elsewhere decided to pollute the Lisp meaning in the context of Lisp, thus confusing newbies everywhere. Worst of all the two meanings are regularly conflated into a nonsensival meaning almost everywhere)

Anyway the first (foreign) meaning of "structure editing" or "strucucture editor" an interface to editing some representation of a program in a structured way e.g. Paredit in Emacs or Blockly.

The second (native) meaning is editing program objects (i.e Lisp forms) directly sans reader (i.e. sans text, sans files) IN MEMORY in a running Lisp image. This says nothing about the interface for doing so.

Interlisp pioneered this. Keyboard keystrokes would directly change the program objects as they were in memory; the resulting program was continuously being reprinted with a pretty printer. All clients of that program would immediately use the new updated program as it was at every keypress: This is part of the reason why Xerox D machines were known as voodoo boxes.

Many Lispers have claimed that Common Lisp's acknowledgement of the file abstraction has been a mistake. I fall into this camp.

Anyway the point is that for both meanings of "structure editor" s-expressions are very very very useful. So this is another reason why Lispers like s-expressions.

>>19
I think that idea made its way into Mac OS in a diluted form as the Resource Manager.
http://basalgangster.macgui.com/RetroMacComputing/The_Long_View/Entries/2010/5/1_Resources_and_Resource_Editors.html
http://www.folklore.org/StoryView.py?project=Macintosh&story=The_Grand_Unified_Model.txt
http://xenon.stanford.edu/~eswierk/misc/kaehler81/

Get this through your thick skulls, Lispers: No amount of proselytization, language features, whatever the fuck you want to call it, can change the simple and obvious fact that parentheses are bloody irritating to work with when nested deeply!

>>21
Seconded

>>21

You're right Cudder, it is annoying to edit Lisp programs as text with an ordinary text editor. I agree. I'd never program in Lisp if I had to do this simply cause editing would be too painful.

But that's not what Lisp programmers do. Use some of the tools a Lisp programmer uses. I use Emacs with Paredit to edit Lisp programs. There are other tools, perhaps some are better, I don't know, but Emacs with Paredit is what I use today, and its nice. Try doing the same. Just for laughs. Just for a day.

http://www.emacswiki.org/emacs/PareditCheatsheet

(pay special attention to the barf and slurp commands, and the depth changing commands)

After a while it feels like a second skin.

>>20

Neat links. Thank you :)

>>23
emacs
And give myself RSI?
barf
slurp
other horrendously verbose commands
You have to be kidding me. WTF.

it is annoying to edit Lisp programs as text with an ordinary text editor.
This is a failure already.

>>9
That's called "duality of syntax" and is actually one of the advantages of Lisp.

>>25
You don't type them in, you use the keybindings; which you can change to be more ergonomic depending on your keyboard.

>>25
It sounds like your complaining just to complain now.

>>28
"you're"

Lisp offers a lot of flexibility, at the price of macro-friendly syntax, rather than user-friendly. Besides the overrated problem of getting used to those lots of parentheses, it's all too tempting to mix macros and normal code in Lisp, in a way that doesn't visually stand out; this really doesn't encourage the writing of reusable, mutually compatible libraries. As a result of this extreme flexibility, large scale collaboration doesn't seem to happen, and Lisps lack a de facto comprehensive set of standard libs, besides those included in Common Lisp's specification. Comparisons have been drawn between getting Lispers to work together and herding cats...

There's plenty of high quality, ultra-stable Common Lisp libraries:

+ Bordeaux threads
  + Standardizes Threads.
+ CFFI
  + Standardizes C interop.
+ CL-FAD
  + Standaridzes files and directories.
+ Closer to MOP
  + Meta object protocol.
+ Trivial backtrace
  + Standardizes backtrace printing.
+ Trivial features.
  + Standardizes =*features*=.
+ Trivial Gray streams
  + Ensures CLOS streams (already defacto in most implmentations).
+ Trivial garbage
  + Standardizes weak pointers and weak hash-tables.
+ USOCKET
  + Standardizes the sockets interface.
+ Babel
  + Character encoding.
+ Chipz
  + Decompression.
+ CHUNGA
  + Chunked streams
+ CL+SSL
  + Interface to OpenSSL.
+ Flexi-streams
  + Stream interface over streams for character encoding.
+ Ironclad
  + Cryptography.
+ Nibbles
  + Reading and writing machine types.
+ Salza2
  + Compression.
+ CL-JPEG
  + JPEG input and output.
+ CL-OPENGL
  + Bindings for OpenGL.
+ CL-VECTORS
  + 2D primitive drawing library.
+ CLX
  + Bindings to X.
+ PNG-READ
  + PNG input.
+ Skippy
  + GIF input and output.
+ Vecto
  + High level interface to CL-VECTORS.
+ ZPB-TTF
  + Parses ttf files.
+ ZPNG
  + PNG output.
+ Hunchentoot
  + Web server.
+ Drakma
  + HTTP client.
+ RFC2338
  + Multi-part form data.
+ Parenscript
  + Javascript transpiler.
+ CL-WHO
  + HTML DSL.
+ Postmodern
  + Postgres interface.
+ Alexandria
  + Standard library.
+ Anaphora
  + Anaphoric macro library.
+ Cells
  + Data flow extensions.
  + GUI framework (e.g. celtk cells-gtk).
+ CL-PPCRE
  + Regular expressions library.
+ CLIM
  + GUI framework.
  + Mainly commercial.
+ Iterate
  + Alternative to LOOP.
+ optima
  + Pattern matching.
+ SERIES
  + Lazy evaluation.
  + Iteration.
+ SPLIT-SEQUENCE
  + Partitioning sequences.
+ LOCAL-TIME
  + Time and dates.
  + Based on Eric Naggum's History of Time.
+ metabang-bind
  + Combines labels, let, flet, destructuring-bind, with-slots,
    with-accessors, and multiple-value-bind into one form.
  + Extensible.
+ Stefil
  + Unit tests.
+ ASDF
  + Build system.
+ Quicklisp
  + Library package manager.

>>30

You're just a liar.

>>32
It's an excerpt from the MetaLua manual and they're not lying:
http://metalua.luaforge.net/metalua-manual.html

>>33

I listed a number of high quality, free, stable, well-maintained Common Lisp libraries. There is also a large amount of very high quality non-free Common Lisp libraries from the commercial vendors.

Metalua (nor Lua for that matter) does not have as many high quality libraries. So the Metalua people claiming Common Lisp has a library problem is stupid.

That being said let it be known that Metalua is on my list of languages I would learn if I had a few more lives. As it is though, I cannot be expert in more than 6 languages, and promising languages like REBOL, Metalua and even classics like Fortran and Simula just do not get my time.

Also, I used Python professionaly after hearing good things about it, but later discovered that the reasons I used Python at that time did not apply to Python at all (Python, next to PHP, is the worst language I have ever used), but instead applied to Lua. I rewrote 10% of the Python in Lua, but at that point it was too late and I just stuck with the Python. If I could go back to that situation now though everything would have been written in Common Lisp and that would have been that.

Once you know Common Lisp your outlook towards 99% of languages is "this is just some small variation with half of everything missing".

>>34
I'm curious about the 5 other languages you care to be expert at.

>>35
Refal, Whitespace, APL, Brainfuck, Forsythe.

>>36
LOL! those are not real programming languages
but [b]exoteric[/i] languages or turing tarballs
(ala LOLCode, u forgot this one)
you can't get a job with these!
dont put that on your resume!

also forgot Symta ;)

>>37
It's good that you got the joke, moron. Too bad you've confused exotericity with esotericity, though.

>>39
at least I had the turing tarball right, moron²