Slashdot Mirror
LispM Source Released Under 'BSD Like' License
mschaef writes "Announced on Bill Clementson's Blog, Brad Parker has stated that he has
'permission from MIT to release all the LISPM source code with a "BSD like" source license.'" Zach Beane has also set up a torrent for easy download.
Is that anything like a death certificate?
Does that mean we have to pronounce it as
Bee - Ethh - Dee?
"Imagination is more important than knowledge..."
All "What is LISPM?" comments over on the right.
"This proves BSD is dying" comments on the left.
Wordplay that desperately wants to be clever, like "I guess that makes it a 'Bee Eth Dee Licenth'" comments go there by the door.
If you have read the article, know the history of Brad Parker, LISPM and their involvement in the Church of the Flying Spaghetti Monster, and have something intelligent to say, then we don't want your kind around here. Slashdot has standards to maintain, you know.
The permissioned release of 25 year old code is /. news now? This code is worthless IMO
Just like your opinion. Now get back to work, those burgers won't flip themselves!
I don't know, does anyone still program in LISP (I'm sure some people do (personally I could never get used to its syntax (although I never really tried that hard (I did use it with Autocad (one of the really old DOS versions) for a while))))?
Reality test... am I dreaming?
Let me be the first to say...Great News!!
This has long been the dream of those yearning for the revival of Lisp machines and their allegedly superior programming environment.
Please correct me if I got my facts wrong.
...this is obviously stolen SCO intellectual property.
I mean if SCO can claim all your ELF are belong to SCO, why stop there?
SCO needs to start up a Lisp licensing program, it can be as wildly successful as their Linux licensing program.
This software was written in the 80s. Back then, all the programmers were supposed to have supernatural abilities and could, like, fit an entire operating system in 640K! What is this??!!! A modern JVM download is only 15MB.
I read
Does that make this the oldest software to be released under an "open-sourceish" license?
-Rob
Biblical fiscal responsibility
(This(truly(is(great news))))
Yeah! This clearly shows that C is superior! At least in C you have superfluous parentheses, semicolons, commas, ...
Please correct me if I got my facts wrong.
There are the original TPC tape images included, and then those same images in SIMH format. Then there's an archive of the extracted files, and the archive is also extracted.
Cyric Zndovzny at your service.
This was in the body of the story, but maybe it's more appropriate elsewhere. One of the more interesting links in the blog posts about this source code release was a transcript of a speech by RMS on how the Lisp Machine influenced his decision to start the free software movement. Interesting reading.
In Thoviet Rutha, LITHP lithenthes you!
Sorry, it needed to be done. That and a co-worker suggested I post it.
mind explaining why the "th" jokes? For us uneducated masses.
Thanks.
I think it's good that this is getting released. The LispM software contained a lot of low-level ideas that are being rediscovered now 25 years later. This will be useful for the history of computing, as well as a potential source of prior art in patent claims.
Still, personally, I think Smalltalk 80, developed around the same time, was more innovative and interesting than the LispM software. You can get a complete Smalltalk 80 environment in its original form as part of the Squeak project.
Looking at the actual license used, it is the MIT license. I guess they referred to it as a "BSD-like" license as it is somewhat more familiar to the average techie.
Like when you have one of those wicked amps that goes up not to 10 but to 11?
Maybe you think you're funny but d00d, Skynard never sounded so good!
Dedicated Cthulhu Cultist since 4523 BC.
I probably used it at about the same time that tape was created, since I graduated high school in 1980 and had a summer job dabbling with one of them.
They did some very cool things, yes, but at least the ones I used were dog-slow because of all the overhead associated with the windowing system and the like.
I hate to say it, but I remember actually preferring the PDP-10. Primitive compared to the Lispm but it was less overwhelmingly complex and actually had an easier time keeping up with my typing.
D
That's not it, you insensitive clod! It's Lethargic, Impractical Soiree Prognosticator Malfeasance. Duh!
Here here! I find it incredible to see that C/Java people bitch about "superflous" punctuation. Compare this:
// 5 punctuation marks
// 7 punctuation marks
// 7 punctuation marks
// 10 punctuation marks (11 if you count the 'else')
// 4 punctuation marks
(defun square (x) (* x x)) ; 6 punctuation marks
To C:
double square(double x) {return x * x;}
To C++:
template <typename T>
T square(T x) {return x * x;}
To Java:
public class Square
{
public double operate(double x) {return x * x;}
};
Compare this:
(if (something) ; 8 punctuation marks
(do-this)
(do-that))
To C/C++/Java:
if(something())
do_this();
else
do_that();
Compare this:
(do-something to-this with-that in-there) ; 2 punctuation marks
To C/C++/Java:
do_something(to-this, with-that, in-there)
The only reason it seems like there are so many parentheses in Lisp is because of LET and because Lisp uses just a single type of punctuation while C/C++/Java use all sorts of different punctuation. With a good editor, the parentheses don't even matter, all you see is the indented structure!
A deep unwavering belief is a sure sign you're missing something...
Now I can fix that annoying bug that Symbolics introduced when they changed Zwei to say "is not a defined key" instead of "undefined", so when I press Meta-Symbol-B it will say "Meta-Beta Undefined (doo-dah, doo-dah)" again.
What is a Lisp machine? I see tons of posts, but no explanations of what they are! Help!
Parent screwed up link, try Squeak.org
What about everyone who wants to bash LISP syntax?
(a ()(((b))(c)())q ((m ()() x))(w))(l)(((z)))) cdr bddr) oh crap it's just too confusing.
---GEC
I'm but the humble pupil, seeking to snatch the scratchbuilt pebble from the master's fully articulated hand
Hmm. The Macsyma code dates from around the same period (and was also developed at MIT), and it (well, Maxima, the continuation of the codebase), is still one of the best free computer algebra systems out there. I use it every day, and I don't miss Mathematica at all.
A deep unwavering belief is a sure sign you're missing something...
They're using a p2p fileswapping program to distribute it - doesn't that make it defacto music piracy?
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
And thats worse than perl regular expressions? Me thinks not.
Open Source Drum Kit, LPLC deve board - mjhdesigns.com
Somebody needs to design a modern Lisp Machine. It would be a nice "open hardware" project. Maybe could run on an FPGA PCI board or something.
I was originally going to title this "Symbolics is Dying", but it turns out Symbolics is still around, selling things like Macsyma, just not making Lisp Machines any more.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
Only if you confuse 'reputation' with 'loudmouth /. trolling'.
you had me at #!
Yes! Now I just need someone to find and publish the source to PLANNER and CONIVER.
--MarkusQ
LISP, itself, is a language developed for parsing describable information - usually text. It was developed by an AI professor at MIT, IIRC, in one of the early attempts to develop a machine capable of learning.
Because LISP was run in a virtual machine, it was 100% portable. Any machine that had a LISP machine could run a LISP program. It was the real start of "run-anywhere" programming. Although LISP is not the most popular of languages, it has always been a surprise that it has never taken off amongst web developers for purely text-based processing. Java is way too heavy for that and Javascript is very cumbersome for text operations, yet LISP would be ideal for such work.
I'm not 100% sure of this, but I believe Tcl/Tk is derived from LISP, and the syntax used by the LambdaMOO virtual world is very similar and was probably influenced by it.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Every modern language is LISP re-invented poorly. Including LISP.
Socialism: a lie told by totalitarians and believed by fools.
That's all well and fine, but let's look at a more common example:
// crap!
Common Lisp: 12 punctuation marks
(tagbody
10 (print "hello")
20 (print "world")
30 (go 10))
BASIC: 4 punctuation marks
10 PRINT "hello"
20 PRINT "world"
30 GOTO 10
C: 24 punctuation marks, but you don't even have real line numbers
#include
main() {
ten: printf("hello\n");
twenty: printf("world\n");
thirty: goto ten;
}
Java: 22 punctuation marks, but you don't even have GOTO!
public class HelloWorld {
public static void main(String args[]) {
System.out.println("hello");
System.out.println("world");
}
}
With a good editor, the parentheses don't even matter, all you see is the indented structure!
Which, of course, is why Python dispensed with the parentheses and kept just the indented structure. IMO, that was one of the very few genuinely new ideas in computer languages in the past 30 years - the realization that the punctuation that was only there for the computer, not for the human, could be dispensed with entirely.
Socialism: a lie told by totalitarians and believed by fools.
The issue is not the raw number per-se. The crux of the problem is the way in which you have many of the same punctuations bunched up in one place. Lisp is exceptionally bad with everything being a parend. C/C++/Java has its problems when you do lots of embedded control statements and {}. C/C++/Java mixes it up a bit which makes things easier on the eye.
--Kevin
The problem with the Python mechanism is that it makes macros quite a bit trickier to implement.
A deep unwavering belief is a sure sign you're missing something...
According to the Unix Haters Handbook, the Lisp Machines were much better than the early Sun workstations that replaced them (except for cost, which is why people bought the first Suns instead of LispM.) Didn't they used to cost more than $50,000 each? I've been wating 20 years to get my own Lisp Machine, now I can run one on a cheap PC. Emacs is like eating crumbs from the table, its time to cook some real meals!
Software freedom...I love it!
LISP Machine Wikipedia Page
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
1. Memory bounds checking in hardware.
2. Hardware typed memory.
3. Hardware designed for specific language implementation.
The current problems that plague the software industry are unreliable code, vulnerabilities to malicious software and poor programmer productivity. It's embarrassing that architectures that were abandoned 20 years ago had features that address these issues.
Memory bound checking is a complete no-brainer. When you declare a data structure you know the size. If you try to go outside that size, then something is wrong. It might be a run time bug, it might be a malicious attack. Who cares? If an exception occurs, you're going to be safer.
Hardware typing in memory is more of the same. If you add a floating point value to an address you are in trouble, and an exception should be the result. In the Lisp world, type bits support arithmetic between various numerical representations, so there is added value beyond error checking.
Hardware/software co-design is not quite as obvious, but it can have big payoffs. Both the Lisp machines and the Burroughs machines were incredibly reliable. They also ran very fast, as least on the tasks that fit the architecture. (Although Symbolics had a great graphics setup, they were not the fastest rendering engines.) Some of this was due to memory bounds checking and some because of typed memory, but much was because the software was designed to match the hardware and hardware was targeted as software. There are currently many examples of hardware designers building computers that are no good for software and software systems that have to make up for gaps in the hardware. Can you say Itanium?
I know I'm really going to get flamed for this, but I think it's true: RISC is to blame for a lot of these problems. RISC attempts to optimize one thing, the instruction execution pipeline. This was fine when speed was the bottleneck, but we are now at a point where the problems are not if we can run fast enough, but can we run reliably enough?
So you're saying that the problem isn't too many parentheses, but that the parentheses are hard to distinguish? First, that's an awfully subjective argument. I find { and } and ; to be much harder on the eyes than ( and ). They stand out too much compared the actual code. Which leads to my second point: the parentheses aren't supposed to be easy to distinguish. You're not supposed to pay attention to them. It's a skill, but no more so, for example, than learning to not voice the words in your head when reading. The editor is supposed to take care of the parentheses. For example, say I have:
(defun wumpus (x)
(let ((foo 1)
(bar 2)
(baz 3))
(when (+ foo bar baz)
(let ((temp (do-something foo bar baz)))
(when (> temp 0)
(do-something-else temp...
What's the proper termination for that fragment? It's '))))))'. How many parentheses is that? What closes what? Who cares! No Lisp programmer actually looks and counts to see if they have 6 parentheses. A Lisp programmer simply tapes SHIFT-0 until the paren to the left of the 'defun' lights up. What happens when he needs to insert something after the "when" clause? Does he look through the '))))))' at the end and try to figure out where to insert the cursor? No! He uses an editor hotkey to place the cursor for him. It takes a bit of practice to get the hang of it, but there is a benefit. Since the parens demark the bounderies of each fragment, the editor is fully capable of moving the cursor around the AST. One of the benefits is that Lisp programmers don't have to use the arrow keys to move between expressions. They simply use the hotkeys for "next sibling expression" or "parent expression". Say I'm deep in a nested IF statement, and want to edit the predicate. In C, I'd arrow up and over until I get to the predicate clause. in Lisp, I'd tap the "parent expression" a couple of times, then "next child" once. Since the editor highlights what is currently selected, this process can be extremely efficient, since it basically becomes a hand-eye exercise.
A deep unwavering belief is a sure sign you're missing something...
Shift-0? What kind of stone age are you living in, man?
.
Remap your keyboard so the parentheses replace the (mostly useless?) square brackets.
Kind of like http://www.asl.dsl.pipex.com/symbolics/photos/IO/
LOL. I'm too dumb to remap keys in X :-/ Also, I need a keyboard with #' and ,@ keys :)
A deep unwavering belief is a sure sign you're missing something...
the x87 is so broken but luckily, we are no longer shackled to it.
part of the x86-64 spec is full support for SSE and in fact, the SSE instructions are meant to completly replace the use of the x87, which is only there for legacy support.
I think a lot of the gain of x86-64 will be from being able to _count_ on sse support and use it when compiling in addition to just its 64bit nature.
although, a lot of distros are dropping support (at least optionally) for pre-SSE cpus to always compile with it enabled so we are already starting to see some of the benefits.
http://notanumber.net/
How ironic that they released the LispM sources under a BSD-like license instead of GPL.
Here is an essay written a while ago (1986 or so) by Richard M Stallman (RMS), telling his side of the story about the MIT AI Lab, and the Lisp Machine Wars.
Many other sides of the story, less extreme than from RMS's viewpoint, are covered here and here and here and here and of course here.
Machine Room Folk Dance, Thursday at 8pm. Come Celebrate the Joy of Programming, with the World's Most Unbureaucratic Computers. (There were only five of us dancing, but we had a good time.)
[...] The Lab Betrayed
There is still an institution named the MIT Artificial Intelligence Lab, and I still work there, but its old virtues are gone. It was dealt a murderous blow by a spin-off company, and this has changed its nature fundamentally and (I believe) permanently.
For years only we at the AI lab, and a few other labs, appreciated the best in software. When we spoke of the virtues of Lisp, other programmers laughed at us, though with little knowledge of what they were talking about. We ignored them and went on with our work. They said we were in an ivory tower.
Then parts of the "real world" realized that we had been right all along about Lisp. Great commercial interest in Lisp appeared. This was the beginning of the end.
The AI lab had just developed a computer called the Lisp machine, a personal computer with a large virtual address space so that it could run very large Lisp programs. Now people wanted the machine to be produced commercially so that everyone else could have them. The inventor of the Lisp machine, arch-hacker Richard Greenblatt, made plans for an unconventional "hacker company" which would grow slowly but steadily, not use hype, and be less gluttonous and ruthless than your standard American corporation. His goal was to provide an alternative way of supporting hackers and hacking, and to provide the world with Lisp machines and good software, rather than simply to maximize profits. This meant doing without most outside investment, since investors would insist on conventional methods. This company is Lisp Machines, Incorporated, generally called LMI.
Other people on the Lisp machine project believed this would not work, and criticized Greenblatt's lack of business experience. In response, Greenblatt brought in his friend Noftsker, who had left the lab for industry some years before. Noftsker was considered experienced in business. He quickly demonstrated the correctness of this impression with a most businesslike stab in the back: he and the other hackers dropped Greenblatt to form another company. Their plan was to seek large amounts of investment, grow as rapidly as possible, make a big splash, and the devil take anybody or anything drowned in it. Though the hackers would only get a small fraction of the fortunes the company planned to make, even that much would make them rich! They didn't even have to work any harder. They just had to stop cooperating with others as they had used to.
This resulted in two competing Lisp machine companies, Greenblatt's LMI and Noftsker's Symbolics (generally called "Slime" or "Bolix" around the AI lab). All the hackers of the AI lab were associated with one or the other, except me, because even LMI involved moral compromises I didn't want to make. For example, Greenblatt is against proprietary operating system software but approves of proprietary applications software; I don't want to refuse to share either kind of program.
I strongly suspect that the destruct
Take a look and feel free: http://www.PieMenu.com
Does that make this the oldest software to be released under an "open-sourceish" license?
... the "Free Software Movement" was already in high gear years before Stallman decided *he* was going to invent it.
Hell no. Not even close.
There was a thriving free software community back in the '70s, with operating systems, compilers for C, Forth, Basic, Pascal, and other languages, editors, graphics systems... all released to the public domain or under BSD-style licences. Heck, there were already Berkeley Software Distribution tapes circulating when most of this code was being written, and those contained software under all kinds of licenses.
Let's see... just off the top of my head, thinking back a quarter of a century, I used Small C (1980), Fig-Forth (1978), Software Tools (1976),
As in Philip Greenspun's 10th Rule of Programming you mean?
"The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
Why design a new language to solve the problem? We have Python...
The main feature you get from Lisp macros that allow new features to solve specific problems, is a performance enhancement. The vast majority of features that use macros in Lisp, can be implemented via passing around functions in Python (very similar to unevaluated arguments). Sure, performance-wise it sucks, but in Python, that doesn't matter.
There are very very few cases where an actual new syntax or language is useful for a specific domain, and in those cases you can use an ugly String for parsing.
The real tradeoff in most cases is between a readable syntax (Python) and performance (Lisp macros).
I'd take the former any day.
You may be interested to know that Python was not the first to do this. The language OCCAM did the same thing and it too may not have been the first.
Lisp macros are somewhat like a function that receives its arguments unevaluated. Sure, the function executes at read-time, but it could, in principle, do all the logic in run-time - as long as its arguments are unevaluated.
Now, suppose we provide the reverse feature, of saying "dont-eval-this" (much like Lisp's quote), and use normal functions instead of macros.
We may lose some performance (moving work from read-time to run-time), but we gain simplicity and readability.
In most dynamic languages, there is no "quote" operator, but instead there are first-class function objects which are, for most purposes, practically equivalent (as any piece of unevaluated code can be enclosed in a closure definition). So that in practice, aside for trivial syntax issues, (almost) every macro can be converted to a function call with a closure argument.
For example, the "loop" macro can be converted to a set of functions (for/while/etc) that receive the conditional as a closure, and the loop body as a closure. This approach is used by Smalltalk.
Advantages of this macro alternative:
A. Simpler to enhance language, much easier than to write a macro
B. More predictability and explicitness about the evaluation of code
C. Does not require code to be representable as data
Disadvantages:
A. Some macros may provide more syntatic sugar
B. Performance, read-time work is moved to run-time.
I would say that Disadvantage A is moot because a nice readable syntax is something Lispers must give up in order to support macros in the first place. And that advantage B is not relevant for the vast majority of software development.
Thus, contrary to popular oppinion, macros don't really empower the developer, they just make it possible to create really powerful performance hacks at read-time. Their disadvantages far outweigh their advantages, and that is why they haven't won out.
You want to learn about xmodmap
.xmodmap) which has lines like
.xinitrc) you want to put a command
First, do xmodmap -pke
That will print out the current keymap you have.
Then, you want to find lines like
keycode 45 = 9 parenleft
keycode 46 = 0 parenright
keycode 71 = bracketleft braceleft
keycode 72 = bracketright braceright
(the lines show unshifted shifted)
Then, you want to create a file (call it
keycode 45 = 9 braceleft
keycode 46 = 0 braceright
keycode 71 = parenleft bracketleft
keycode 72 = parenright bracketright
Then, in a suitable init file (such as
xmodmap $HOME/.xmodmap
to load it when you start up or just type it from the command line to try it out: You can do it one line at a time by using the syntax
xmodmap -e "keycode 72 = parenright bracketright"
Note: the alternative keysym syntax is a briar patch: it allows you to make all the keys which emit left brackets to now emit left parentheses, but then it doesn't offer you a way to change only the ORIGINAL left parenthesis key to emit a left bracket. Perhaps your xmodmap has a swap syntax, but my clunky Solaris environment does not. The keycodes are unfortunately not guaranteed to be portable, but hey, how many machines will you need to customize?
"Since the demise of LISP machines, the concept of a stack-based machine has surfaced repeatedly in virtual machines."
I guess I'm the only one who remembers the commercially available Harris RTX-2000
Peter Norvig has a nice comparison of Python and Lisp.
Thufferin' thuccotasth!
The moral of this post? We should all be programming in BASIC!
A deep unwavering belief is a sure sign you're missing something...
Not when you use it inside Texmacs, it doesn't. Powerful math capabilities, great TeX output, what more could you want?
A deep unwavering belief is a sure sign you're missing something...
Comment removed based on user account deletion
Comparing Python to Scheme, no matter what Paul Graham may say, is a really bad comparison. Python supposedly aims to be a really clean imperative OOP language. Guido not only refuses to implement crucial features for functional programming like proper closures and anonymous functions; he's actually seeking to remove some such features, because he thinks they're "confusing." The general culture around Python strongly discourages use of techniques like higher-order functions; Python programmers write a loop in every other function. Python uses flexible arrays as its list datatype, and its list processing operations are built around that sort of datatype. It's never been intended to be self-hosting (i.e. Python has never been seriously implemented in Python, IIRC.)
Scheme, on the other hand, is an impure functional language that mandates anonymous lexical closures, tail call optimization, first-class continuations and a macro system. Its design is guided by absolute minimalism in terms of features, in favor of extremely general constructs. Most of the syntax called for in R5RS can actually be implemented in Scheme itself, using the macro system, as the language definition itself demonstrates. It uses singly linked lists as its list datatype (though it also provides fixed-size arrays). There is a heavy emphasis on higher-order functions of very general applicability; highly fluent Scheme programmers only need to write loops infrequently, because most of the time there's a higher-order function that does the job for you, like map, fold, or many others from the SRFI-1 list library.
The popular scripting language that's the most Lisp-like, really, is Ruby, whose pervasive use of code blocks echoes functional programming techniques.
Are you adequate?
;;; ... expression-n)
;;; delay, force, promise?
;;;
;;; (delay expression-1
;;; => <a promise object>
;;;
;;; Returns a promise to evaluate the block of code contained within
;;; the delay expression.
;;;
;;; (force p)
;;; => <a value>
;;;
;;; Forces evaluation of the code delayed by the promise, caching the
;;; result. Forcing a promise a second or more time returns the
;;; cached value. Forcing a non-promise returns the value itself.
;;;
;;; (promise? p)
;;; => <boolean>
;;;
;;; True if and only if p is a promise.
;;;
(define-syntax delay
(syntax-rules ()
((delay expression . expressions)
(cons '*PROMISE-SIGIL*
(lambda () expression . expressions)))))
(define (force p)
(cond ((not (promise? p)) p)
((procedure? (cdr p))
(set-cdr! p ((cdr p)))
(cdr p))
(else (cdr p))))
(define (promise? p)
(and (pair? p)
(eq? '*PROMISE-SIGIL*
(car p))))
;;
;; Though actually, the Scheme standard already includes these...
;;
Are you adequate?
Macros in Lisp and Scheme are way more general than that. They don't just get you performance enhancements (and actually, I'd say that's a minor use for macros); they get you arbitrary evaluation rules, which allow you to do things like define new binding forms, that is, syntax for assigning values to variables within a scope.
For example, it's pretty simple to define a macro to do ML and Haskell-style pattern matching in Lisp; that is, a binding construct that tests whether arbitrarily complex data matches an arbitrarily complex pattern, and if it does, binds the variables in the pattern to the values that they match in the input.
I don't think you're going to find any remotely simple way of adding a new binding construct to Python within Python itself.
Are you adequate?
That's all well and fine, but let's look at a more common example:
Common Lisp: 12 punctuation marks
(tagbody
10 (print "hello")
20 (print "world")
30 (go 10))
This is a "common" example only in the sense of "lowest common denominator" - congratulations, you've succeeded in reducing the power of lisp to the lameness of BASIC. In real life, lisp programmers do not write code with numbered tags a-la numbered source lines in BASIC.
Your infinite loop would be rendered in common lisp as:
(loop (print "hello") (print "world"))
or even
(loop (print "hello
world"))
since newlines are allowed in literal strings.
But really, one probably doesn't want the quotes in the output, so you'd really see:
(loop (format t "hello~%world~%"))
But this is still more punctuation marks than BASIC, thus proving that when trying to accomplish something so simple even a severely retarded chimpanzee would not be challenged by the task, BASIC requires fewer punctuation marks than lisp, c, or java. Unfortunately, when the task is quite complex BASIC isn't up to the job at all, no matter how many (or few) punctuation marks you use.
;;;c ed.el
;;; Use automatically balanced parens, and indent automatically on
;;; newline. Has other tricks up its sleeve, too; for example, if you
;;; want to put a parens around the next <number> s-exps after the
;;; point, just do C-u <number> (.
;;;
;;; balanced.el is available at:
;;;
;;; http://www.cs.indiana.edu/chezscheme/emacs/balan
;;;
;;; Only tried this in real Emacs, dunno if it works in XEmacs.
;;;
(require 'balanced)
(add-hook* '(scheme-mode-hook lisp-interaction-mode-hook emacs-lisp-mode-hook)
(list 'balanced-on
(lambda () (local-set-key [13] 'newline-and-indent))
))
(defun add-hook* (mode-hooks procs &optional append)
"add each listed procedure to each listed mode hook.
If append is true, we append the hooks to the end of the list instead
of consing them on to the beginning."
(for-each (lambda (mode-hook)
(for-each (lambda (proc)
(if append
(nconc (eval mode-hook) (list proc))
(add-hook mode-hook proc)))
procs))
mode-hooks))
Are you adequate?
To Java:
// 7 punctuation marks
public class Square
{
public double operate(double x) {return x * x;}
};
Minor nitpick - the final semicolon, while allowed, is surpurfluous and against the Java Programming Style guidelines.
Being bitter is drinking poison and hoping someone else will die
The guy was obviosly joking.
Look at what he says about the Java there.
Besides he wrote EVERYTHING in a way that slashdotters wouldn't do.
Emacs is good operating system, but it has one flaw: Its text editor could be better.
It's the commas. If the language designers had chosen to make the space significant (e.g. as an argument or statement separator, just like LISP), then C would have won. Fortunately, Kernighan and Richie had the decency to add some syntactic sugar to their hieroglyphic language. Otherwise, the result would have been Python, but with less keyword. Plus, the IOCCC would never have started, since nobody would have been able to read even
main(int a char* b[]) { int c for c = 1 c a c++ puts b[c] }
Yes, that is a cut down version of echo...
damn, the less than symbol fell out: read "c a" where you see "c a"
Oops it fell out again, how did that happen??? *snicker*
The LISP song http://www.prometheus-music.com/audio/eternalflame .mp3
OCCAM isn't that much older than Python (which borrowed the idea from ABC). Pythoneers like to point to a Knuth quotation from 1974:
"We will perhaps eventually be writing only small modules which are identified by name as they are used to build larger ones, so that devices like indentation, rather than delimiters, might become feasible for expressing local structure in the source language."
(but they sometimes miss the "only small parts" and "expressing local structure" parts when they do that...)
Holy cow, I ain't never going to get them darn ampserpersands right.
But I'm posting in "plain old text". I suppose the TCP/IP stack eats the mathematical operators...
Just recently me and a friend of mine wrote a LazyExpression object in Python.
It indeed takes a few more lines (About a factor of 3), but it supports more functionality (and is simpler!). I can use the "promise" (my lazy object) in any context, and automagically, new "promises" are created.
What happens if you use (car my-promise)? Will it create a promise to run car on the result of the promise when it is evaluated, as you would want it to, or will it return an arbitrary piece of data that you did not mean for it to return?
These promises are a lot less useful than the Python Lazy object because everyone using them must be aware of the fact that they are not actual results.
You're obviously a troll, but the claim that C++ programmers "get the code out" faster than Lisp programmers is a huge laugh.
How long do you wait for a re-compile when you've modified a header in your program? Most Lisp implementations compile as fast as you can type control-x control-e into your Emacs.
Linear thinking, by the way, reads from the beginning (where things like "defun" and "let" and "loop" let you know what is going on, and the automatic indentation shows you the organization), and by the time you've read the last non-parenthesis item, you understand it all, and the final group of parenthesis is not needed any more.
You seem to read your code from the bottom of the screen going up. That could explain why you have trouble understanding Lisp programs. Try turning your monitor right-side up, and see if that helps.
"*" doesn't count as punctuation: it's a freaking function!
And you should at least count the carriage return at the end of the Python example as punctuation. Isn't the white-space significant?
Plus, you have to use the redundant word "return". Think about why it is not simply
def square(x) x*x
Which is the Lisp example where white-space punctuation replaces explicit parenthesis punctuation.
In any case, the original poster was comparing to C++. Python and Lisp are pretty much on the same side of this debate: use a single consistent punctuation scheme instead of trying to use lots of punctuation to distinguish shades of meaning.
1) The parens aren't clear because its the editor that handles the parens, not the programmer.
2) Linear thinking is mildly retarded when all lexically-scoped languages are tree-structured.
3) I'd really like to see you try.
4) What?
A deep unwavering belief is a sure sign you're missing something...
I think I have to (provisionally) disagree with your statement that the out-of-order stuff is there because of C/C++. It is my belief that the OOO stuff, which as been in the x86 since the P6 core, is there to get around the finite #of CPU registers in the x86 design, and the gulf between CPU speed and main memory latency. Unlike risc/IA64 systems, with lots of registers for the compilers to allocate, you only have a limited number of general purpose registers. The CPU gets around this with its internal register set, scheduling operations out of order but only pulling them back in to the public register set (and raising faults) in the original order.
Now, you could argue that IA64 is a more C/C++ compiler-centric box, as it assumes plenty of time up-front to compile down code, and a compiler written by competent people. Its a lot harder to do dynamic stuff on there.
I do agree with your MMU comments, though note that i286 up had a segmented memory model which did offer better memory protection, and a strong model of executable code versus plain data. And you could program it in C and later C++, as I recall from my windows 3.x programming days. But believe me, it was not a nice paradigm to code against, partly because segments were too small (64K), and partly because some things (pointer comparision) get so very, very hard. C/C++ code does normally assume that if you have two pointers char *p,*p1; then if p1!=p2 a write to p (*p=X) does not mean that *p2==X. That is, different pointers point to different places. In Win31, there was no such guarantee.
Ruby's a better descendant than Python!
I18N == Intergalacticization
Some of us are still around. :) I'll say hey to biggles for ya....
Not a Python programmer myself (learning ruby, scheme and know ISO-C, Handel-C and Perl), but saying that you're trying to make "macros" in a language where there's no up-front strong typing like with Python indicates you don't understand the language...
Macros are incredibly useful in a strongly-typed language like C, but have pretty much no place at all in weakly typed languages like Perl and Scheme. Python is still "strongly-typed" (or so I understand it), it just defers the actual checking until the latest possible time at run-time. Or something. Like I said, I'm no expert...
If you are really missing macros, perhaps it's because you want to "abuse" it to write code that writes code.
Which is exactly what Scheme (and functional programming in general) is all about. Ruby, Scheme, and AFAIK Python all support "higher order functions", where you plug in functions or even anonymous code to other functions, and the result is a program that does something completely different expressed with almost mathematical precision and conciseness.
C's preprocessor "macro" language is totally barbaric, by comparison, and one of the fascinating things about Handel-C is its support for "macros written with C syntax" - having used Handel-C a lot, I really think the world would be a better place if ISO-C had the same macro language Handel does instead of the poor excuse for sanity we have now.
In short... "Python? Macros? What the...?"
The thing which makes lisp different is not that it has feature parity with other languages, or that it has hordes of religious followers with a black-and-white view... or even that it's the Right Tool For The Job. What makes lisp different is that you can use it to build whatever tools you need. You're not limited to just what the language provides, like in most languages. You don't have to wait until the next upstream release to get new syntax or features. Instead, you can modify the language itself, and do so in a standard, compatible way.
For example, lisp doesn't have list comprehensions, a very useful syntactic feature which increases expressive capacity and reduces code size. But it's not terribly difficult to just do it yourself.
The point is that, unlike most languages, lisp does not limit you to only the predefined set of hammers which come with the language. If you need a power drill or a chalk line or some widget nobody ever thought of before, you can make one and use it as if it were there all along.
This doesn't make it the right tool for every job, or even most jobs. If your project needs Wonder Widget #32, it's much easier to use a language which already has one. You could build one in lisp, but that wouldn't be a very efficient use of time. Why reinvent the wheel? Most of those wonder widgets are already available in other languages. Where lisp shines is when you need tools nobody has ever thought of before.
One other interesting thing to note about lisp... it's often excluded from language comparisons. See quicksort implementations for an example. The reason it's not there is not because it's outdated or unpopular, but because there's simply no point. It's just taken for granted that lisp can match the expressive power of every language in the comparison, so there's no reason to bother including it.