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.

>>36
>>38

My first imposter :)

>>35
C++, Smalltalk, (ANS) Forth, J, Oberon

C++ (and C for that matter) was the second language I learned (first was Java), and the one I have the most experience in. C++ is also a good way to get interesting jobs.

The value of (Pharo or Squeak) Smalltalk depends where you're coming from:

1. If you're already very well versed in Lisp and Lisp history, you are visiting Lisp's "West coast" relative: Alan Kay's take on John McCarthy's "Maxwell's equations of software", and the product of Dan Ingals implementing the one page compiler writing compiler called "Meta". Even more interesting for a Lisp programmer is that you're seeing a language with a lot of cross polination with Interlisp; the sister evolution of the Lisp machine; You are seeing the cutting edge of a whole divergent and just as rigorous branch of operating system and user interface programming.

2. If you're not a Lisp programmer then you are seeing what computers could (have) be(en): Ever wondered what it would be like to be able to modify your operating system's scheduler at run time? What about clicking on anything ("object" in Smalltalk parlance) you see and calling functions on it ("sending messages" in Smalltalk parlance), seeing the program text (or compiled program!) object corresponding that object, modifying that, and having those changes reflected immediately? What about opening up something like top or task manager ("process browser" in Pharo) showing you every process running in the system, halting a process, looking at its stack, modifying the programs in that process and resuming it? What about an operating system where there is no such thing as files? Where program text is just an object like any other? Where the hard-drive is just another transparent level of cache? Just as there were Lisp machines, there were Smalltalk machines (in fact they were sometimes the same machine with different microcode loaded). It is imperative at every point to realize that Smalltalk was never meant to be a program running on UNIX or some other anachronistic crapware, it was meant to be the entire system. (Now, a Lisp programmer has already seen a Lisp machine, so many of these things aren't novel)

3. For all programmers, if you learn Smalltalk along with some Smalltalk literature (or from an old Smalltalker), you learn for the first time how to build large systems. You learn for the first time that the reason you rolled your eyes at all those "patterns", "designs", "methodologies" etc. are just because the people telling you about them were maniacs (the California computer ponzi scheme people) trying to fit square pegs into round holes (ideas from Smalltalk into C++/Java/C#/VB.NET/PHP/Python/Ruby etc.). You learn for the first time just what "reusable code" is (actually if you've used Genera you already know). A Smalltalk system as a whole is a paragon of programming. Individual parts are pretty hard to beat in a language with Smalltalk's design (i.e. single dispatch and inheritance) e.g. the "Collections" package, while other parts are just hard to beat e.g. Morphic (which comes to Smalltalk by way of Self).

4. Pragmatically, I use Smalltalk for the web (you can use the "Seaside" class library as a "whole stack", or you can mix Amber Smalltalk (a Javascript transpiler transruntime thingo) with your backend of choice (e.g. a Common Lisp)) and for protyping GUIs.

Oberon (and its offspring) is the language of the Oberon family of operating systems (ETH-Oberon (i.e. System 3) Linz-Oberon (i.e. System 4), AOS/Bluebottle (and others?)). The Ceres series of workstation were the "Oberon machines" (so to speak), but are no longer produced. However, you can run the Oberon operating systems on x86 PCs, or hosted on your operating system. Also, thanks to Niklaus Wirth's many freely available books, and the fact that all relevant code is GNU free or public domain, you can implement or port the Oberon language or operating system to your platform of choice.

http://www.inf.ethz.ch/personal/wirth/

Now, Oberon the language (07 rev 2013) descends from Pascal via Modula. Oberon is very conservative (think Dijkstra and Knuth); It is strictly procedural, structured and statically typed (traditional meaning i.e. type erasure). It is also one person understandable from the compiler up in a reasonable amount of time (one month of study) (as is Oberon the operating system!).

As an example of "conservative" Oberon doesn't have anything like "break" or "return" in a loop, instead it uses Dijkstra's "while" form e.g.


WHILE m > n DO m := m – n
ELSIF n > m DO n := n – m
END

Similar to C, it is easy to analyze the performance characteristics of Oberon programs on a Von Neumann machine (one of the design goals was "No hidden costs").

Pragmatically, when you write an application in Common Lisp, it is already extensible in Common Lisp. However, not everyone feels comfortable using Common Lisp, or having others use Common Lisp. Oberon is a good extension language because it is very easy for novices to understand, and it is very hard for inexperienced programmers to write bad programs in it.

Forth is Chuck Moore's (a student of McCarthy's) take on the Maxwell's equations of software (i.e. another sibling of Lisp).

I am not yet an expert in Forth; The extent of my experience with Forth is that I put Forth (amforth) on an AVR (Atmel 2560) microcontroller and defined some words related controlling step motors. On an ARM computer (an Odroid XU) running Debian Linux I used Clozure Common Lisp to generate small Forth programs (based on various inputs from elsewhere), and send them to the Atmel via USB.

I also read part of a postscript tutorial once (which as I understand is similar or related to Forth).

I also emulated a PC booting to colorForth and ran some demo programs.

I plan on learning more about and gaining expertise in Forth over time.

Finally, I lied. I have no experience with J at all.

However, I have reasons for believing it to be worth mastering (It is sufficiently different from the other languages I do know (I do not know any array languages (although I have written some MATLAB programs)), and I can think of a few niche uses for it, or at the very least I will gain from being intimate with its implementation).

If Steele's Fortress was ever "completed" I would probably be thinking of concentrating my next efforts there instead of J.

Anyway this brings me to the fact that I have wasted a lot of time half learning languages that I will probably never use again unless someone pays me to, and even then I will be quite upset and think it is a further wate of time. I learned most of these because of University, but also because of some bumbling about on my own part afterwards, and employers. These languages are:
+ VB.NET
+ Java
+ Perl
+ PHP
+ Haskell
+ Python
+ Clojure
+ Lua
+ JavaScript

I am especially bitter about my time wasted with Python and Haskell, which I have concluded are massive troll languages or CIA disinformation campaigns no different from ADA.

Even for an expert programmer, it takes a while to become truly expert in some language i.e. know its libraries, community, tools, "dialects", impelmentations, how to write common algorithms most succintly in them etc. intimately. And for the vast majority of languages there's no point especially when you know something like Common Lisp. What the heck is the point of Scala or Ruby or some other nonsense if I know Common Lisp? I'd put C++ on that above list of mispent youth languages if it weren't for the "real world" and my need of employment in it (my strategy so far has been to infiltrate employers touting my C expertise, spend a month or two proving myself, then just getting permission to use whatever I want. For some reason most ppl are of the belief that C and C++ is the only way to do systems or embedded programming, so if you want a systems programming job with only light application level work this is the way to go (these jobs tend to give you the most freedom later)).

I already feel like I have a lot on my plate just keeping up with C++, Common Lisp, Forth, Oberon and Smalltalk.

To put it more succinctly:

The marginal benefit of learning a new language (given the ones I already know) is smaller (in almost all cases) than the marginal cost of obtaining and maintaining a life time of true expertise in that language.

This is why languages such as Metalua, REBOL, Factor, Julia, Self, IO, Dylan or any other mix and match or evolution of Lisp, Smalltalk, Forth and a Wirth family language (Modula, Pascal, Oberon) simply don't get my attention even though there's some potential these could be interesting (of course they could be quite unpleasant too). I have the mental capacity for maintaining expertise in maybe 3 more languages, but only the patience and desire to do so for 1 more. idk if it will be J (or some other language in the APL family) (another strong contendor is Unicon or Icon, and as mentioned Fortress).

Also these are just high level general purpose languages. I also have to maintain expertise with DSLs (Mathematica, ACL2 and Maxima) and assemblers (AVR, x86, ARM).

>>44
+ JavaScript
Shalom!

One trend I've noticed in the languages I have chosen to maintain expertise in is that they are all languages which were once used or are intended to be used as languages for an understandable computer from the bottom up (all obviously taking different approaches). They are "no-compromise" languages. Obviously UNIX and C won, but just as easily any of the others could have been the foundation of computers today (ideally it would have been Lisp :D)

None of those languages are pure functional. You should become an expert Haskell or Agda to feel what it's like to break away from the imperative miasma.

>>47
Not fucktional

>>48
Back to /g/, please.

>>47

I mentioned Haskell. I mispent much time with Haskell (it was the 3rd language I learned) before concluding it is a troll language. I recommend only learning Haskell for a similar reason someone might learn INTERCAL (good, fun mental exercise).

I see only a very very very small amount of utility in Agda. Not enough to warrant expertise in it.

I especially liked how Haskell programmers name functions typeclasses etc. after Mathematical concepts they resemble only so slightly to greatly confuse someone who previously only encountered the mathematical concept.

I guess the same can be said of the use of the word "function" instead of the more appropriate "procedure".

>>49
Back to /g/, please.

fuck you niggers

learn to F#

>>51
Haskell doesn't have functions? Oh, I see that I've been trolled. Alrighty then.

>>54

A function in most programming languages including Haskell has very little in common with a mathematical function.

>>54

However I agree with you; you have been trolled. By Haskell.

>>55
Do any programming languages have functions in the sense that you're talking about?

Not that I know of. Not even in e.g. Mathematica.

What's called a function in most programming languages does not enforce the required properties of a function. Even if it did, it's very debatable whether an abstract concept like a function can ever be reified (general sense) like that. It's far more acceptable for it to be the other way around. You can analyze part of some program as a function (but it is not a function!)

In fact, out of all the words used to refer to the same thing (procedure, subroutine, callable unit etc. etc.) function is the worst.

Especially annoying is that in e.g. VB.NET you have "subroutines" and "functions" and the difference between them is that a "function" might return a value (i.e. if it exits locally). What a load of baloney!

However, I have long since accepted that function in programming languages means something entirely different than it does in mathematics. However this one uibqutious historical precedence is no excuse for Haskell programmers to keep making the same mistake over and over again; misusing words with clear meanings from mathematics to describe things they slightly but not fully resemble to the detriment of anyone who knows the slightest bit of mathematics.

On Lisp. In Lisp. Above Lisp. Below Lisp. Within Lisp. Without Lisp. Around Lisp. Atop Lisp. Beneath Lisp. Beside Lisp.

>>58
They were called "functions" in BASIC/FORTRAN because they could be used in expressions. "Subroutine" calls are on a statement of their own and return no values. I think some BASIC variants restricted functions to being a single formula while subroutines could be multiple statements e.g. you couldn't PRINT from a function, but you could do math. I agree that "function" is a bad name for them, especially in languages like C that call every procedure a function.

>>55
A function is a well-defined static mapping of input to output. Haskell functions are functions because they always evaluate to exactly the same output if provided with exactly the same input.
It's sad I have to spell out these truths for you.

And of course you can have a language with pure mathematical concepts reified, except that this language will have to be something like Agda or Coq. Which is why I mentioned Agda, but you can't learn Agda because you're too wired into ancient imperative relicts to even admit the possibility of having mathematical purity in a programming language. You probably haven't even heard of the Haskell Curry and William Howard's isomorphism.
But guess what, according to the new Homotopy Type Theory all mathematics is fundamentally calculational. So you can go back to your Lisp or Forth or whatnot and keep wanking your imperative actions which are impossible to reason about.

>>62
Haskell Curry
Wait... that's a real person? I thought it was some kind of in-joke.


Is it possible to have a language that reads like math?
Most math papers I've touched spend most of their time describing stuff in words rather than notation.

>>63
That's the person the language Haskell is named after, genius.

Haskell Brooks Curry (September 12, 1900 – September 1, 1982) was an American mathematician and logician
There are three programming languages named after him, Haskell, Brooks and Curry
LEL.

>>65
Who names their kid after a programming language?
Terrible!

>>61

Look,

What you say is not true. For example your "function" can cause a stack overflow exception (or other exceptions).


ghci> divBy 100 [1..]
*** Exception: stack overflow

A "function" in Haskell represents a computer program not a function.

A computer program is something that is executed on a computer. It has nothing to do with a mathematical function. You can model computer programs as functions to analyze them, but they are not functions.

>>67
Isn't that the reason why lifted types contain _|_ (bottom)?

>>67
LOL!

>>67
In order to have termination, just choose a total language like Agda.
A function in Haskell is a program that calculates a mathematical function. Since the vast majority of practically important functional values are calculated by computer programs nowadays, the depth of this terminological distinction is dubious. The difference between a computer function and a mathematical function is usually obvious from context. It is especially negligible since lazy pure functional languages support equational reasoning: substituting a computer function into a code term is analogous to substituting a mathematical function into an algebraic expression modulo the limitations of computer memory.
Lisp, on the other hand, does not have functions even in the computer sense.

>>70
λame!

So if mathematical languages are possible, then which language allows me constant time oracle machines?

>>62

Imperative languages are not difficult to reason about.

A (very) good resource is "Introduction to algorithms" if you are experiencing difficulty.

People have been reasoning about imperative programs for a very long time, and, empirically speaking, quite successfuly. For example, all convex hull algorithms I know are "imperative", but many properties are known about them (e.g. for which set of inputs they terminate, for which set of inputs they give a "correct" answer, all the asymptotic properties (time, space, big and little omega and theta)).

In comparison, not much analysis of "purely functional" (I strongly disagree with this term, but I think I know what it means to you so I use it) programs has been done. One resource I know of is the book "Purely functional datastructures", but this does not analyze too many programs. Also notable is that most programs are very awkward, and have terrible characteristics compared to programs written without the restrictions this book places on programs.

Now, I haven't tried to learn Agda. Perhaps you are correct and I cannot learn it. I have some limited experience with Coq.

I mentioned earlier that I use ACL2. ACL2 can analyze Lisp forms as mathematical functions (Note: the Lisp forms aren't mathematical functions, however the subset of Lisp forms which ACL2 recognizes are (in this case) representations of mathematical functions). Here is a small example I took from and executed on the website "Try ACL2":


(defun factorial (n)
    (if (zp n)
      1
      (* n (factorial (- n 1)))))

Succeeded. (click for details)
The admission of FACTORIAL is trivial, using the relation O< (which is known to be well-founded on the domain recognized by O-P) and the measure (ACL2-COUNT N). We observe that the type of FACTORIAL is described by the theorem (AND (INTEGERP (FACTORIAL N)) (< 0 (FACTORIAL N))). We used the :compound-recognizer rule ZP-COMPOUND-RECOGNIZER and primitive type reasoning.

Summary
Form: ( DEFUN FACTORIAL ...)
Rules: ((:COMPOUND-RECOGNIZER ZP-COMPOUND-RECOGNIZER)
        (:FAKE-RUNE-FOR-TYPE-SET NIL))
Time: 0.01 seconds (prove: 0.00, print: 0.00, other: 0.00) FACTORIAL

(thm (> (factorial n) 0))
Succeeded. (click for details)
But we reduce the conjecture to T, by primitive type reasoning and the :type-prescription rule FACTORIAL.

Q.E.D.

Summary Form: ( THM ...)

Rules: ((:FAKE-RUNE-FOR-TYPE-SET NIL)
        (:TYPE-PRESCRIPTION FACTORIAL))

Time: 0.00 seconds (prove: 0.00, print: 0.00, other: 0.00) Proof succeeded.

Note that you can run factorial as a Lisp program. This is because apart from being a representation of a function which ACL2 understands and can reason about, it is also a valid Lisp program.


(factorial 10)
3628800

>>70

I mentioned the language Fortress earlier. Fortress comes with an Emacs program called "fortify" which will format (for lack of a better word) a Fortress program using LaTeX.

However, I personally really really dislike classical (for lack of a better word) mathematical notation. It is confusing and often amibguous. I especially dislike TeX and LaTeX syntax (can you imagine if e.g. your favorite CAS used such syntax?)

Simply put: mathematical notaiton lacks a grammar.

I meant to refer to
>>63
apologies. My reply to Mr. 70 is coming soon :)

>>70

I'm having a lot of trouble following what you're trying to say.

For example I am not sure what you mean when you say "practically important functional values are calculated by computers nowadays".

Also I'm not sure if you're refering to term rewriting or plain denotational semantics in your sentence about "equational reasoning". I assume you are refering to Haskell when you say "lazy purely functional language", and AFAIK Haskell does not use term rewriting.

In any case I don't understand what you are trying to communicate. I know that any programming language which features expressions which evaluate to values can be analyzed or described at least partially using denotational semantics. I just don't understand why you would state this fact.

I also don't understand what you could mean by "function in the computer sense" if Lisp doesn't have them. As discussed earlier, a better word for "function in the computer sense" (at least for all the things "function" means in each of the hundreds of programming languages that use the word "function" to name some feature) is "procedure" or "callable unit". Common Lisp has these.

A d-bus is here!