Oh no, I am quaking in my hip boots, and up to my chin in deep doo doo.
A big corporation is trying to claim the rights to BSML, the name of my invention: Bull Shit
Markup Language.
The wheels of government and commerce would grind to a halt were they not well lubricated with Bull Shit.
So I created the Bull Shit Markup Language and published the BSML web page
years ago, putting it on the public domain for the good of mankind.
Now somebody has finally taken it seriously, and is trying to monopolise BSML!
He who controls BSML controls the Bull Shit... and he who controls the Bull
Shit controls the Universe!
Does anyone know of any prior art pertaining to Bull Shit and Markup
Languages?
What about VRML -- Maybe I could get Mark Pesche to testify on my behalf?
c(-;
Here's a list of the huge faceless multinational corporations I'm up against: http://www.labbook.com "IBM, NetGenics, Apocom, Bristol-Myers Squibb, Wiley and other leaders of
the life sciences industry support LabBook's BSML as the standard for
biological information".
To paraphrase Pastor Martin Niemöller:
First they patented the Anthrax Vaccine
and I did not speak out
because I did not have Anthrax.
Then they patented the AIDS Drugs
and I did not speak out
because I did not have AIDS.
Then they patented Viagra
and I did not speak out
because I already had an erection.
Then they came for the Bull Shitters
and there was no one left
to speak out for me.
Appearently, they would prefer that people searching for "BSML" did not turn up my web page. I wonder if they've tried to get the Boston School for Modern Languages to change their name, too?
Now isn't the whole point of properly using XML and namespaces to disambiguate coincidental name clashes like this? If LabBook thinks there's a problem with more than one language named BSML, then they obviously have no understanding of XML, and aren't qualified to be using it to define any kind of a standard.
Maybe LabBook should put some meta-tags on their web pages to decrease their relevence when people are searching for "Bull Shit" or "Modern Language".
-Don
========
From: "Gene Van Slyke" <gene.vanslyke@labbook.com>
To: <don@toad.com>; <dhopkins@maxis.com>
Sent: Monday, November 12, 2001 10:36 AM
Subject: BSML Trademark
Don,
While reviewing the internet for uses of BSML, we noted your use of BSML
on http://catalog.com/hopkins/text/bsml.html.
While we find your use
humorous, we have registed the BSML name with the United States Patent
and Trademark Office and would appreciate you removing the reference to
BSML from your website.
Bull Shit Markup Language is designed to meet the needs of commerce,
advertising, and blatant self promotion on the World Wide Web.
New BSML Markup Tags
CRONKITE Extension
This tag marks authoritative text that the reader
should believe without question.
SALE Extension
This tag marks advertisements for products that are on sale.
The browser will do everything it can to bring this to the
attention of the user.
COLORMAP Extension
This tag allows the html writer complete control over the user's
colormap. It supports writing RGB values into the system colormap,
plus all the usual crowd pleasers like rotating, flashing, fading
and degaussing, as well as changing screen depth and resolution.
BLINK Extension
The blinking text tag has been extended to apply to client side
image maps, so image regions as well as individual pixels can now
be blinked arbitrarily.
The RAINBOW parameter allow you to specify a sequence of
up to 48 colors or image texture maps to apply to the blinking
text in sequence.
The FREQ and PHASE parameters allow you to precisely control the frequence
and phase of blinking text.
Browsers using Apple's QuickBlink technology or MicroSoft's TrueFlicker
can support up to 65536 independently blinking items per page.
Java applets can be downloaded into the individual blinkers,
to blink text and graphics in arbitrarily programmable patterns.
See the Las Vegas and Times Square home pages for
some excellent examples.
I registered a domain with Network Solutions, but made a typo in the email field and entered my email address as "mindsprinc.com" instead of "mindspring.com".
Of couse Network Solutions would not answer any of my email or phone calls, for which they are infamous.
So I had to register the domain name "mindsprinc.com" (with ANOTHER registrar, of course -- I never used Network Solutions after that), and then I simply sent them email from that domain name asking their automated system to fix it.
We were taught only TWO levels of precedence in elementary school. I remember it well: at the time I thought it was a stupid and pointless gimick, and I still do. I already knew about parenthesis, and they made perfect sense. What makes no sense is leaving parenthesis out in some cases, and requiring extra parenthesis in other cases.
What they didn't teach you in elementary school was that there might be any more than TWO levels of precedence. Nothing from elementary school prepared you for the FIFTEEN or so levels of precedence on C. Two levels was bad enough, but FIFTEEN is RIDICULOUS.
The fact is that the rules DO change from language to language. Each language with precedence rules has ITS OWN SET OF OPERATORS. Some blindly copy the precedence rules of C, but none of them are exactly the same.
And the rules of C++ have been changing for many years, so much that it's a running joke. If you think mathematical notation is so wonderful, then why can't you multiply a and b by writing "ab"?
Now do you still really want to blindly copy mathematical notation? Read Bjarne Stroustrup's paper, "Generalizing Overloading for C++2000"
to see where that will lead. If you still think it's a good idea after reading that, let me remind you he wrote it as an April Fools joke. (The paper, not C++.)
Relying on precedence most certainly DOES make code hard to maintain, and easy to break ("brittle").
It's a fact that code changes over time, and many different people make those modifications. If any of those people did rely on precedence instead of using extra parenthesis, the chances are much higher that the code will break whenever you or somebody else modifies it. Much worse than simply breaking with a syntax error: its meaning will change, but it will still compile without error, so you probably won't even notice you made a mistake.
By "brittle", I mean that code should be ROBUST in the face of CHANGE, and precedence flies in the face of that.
For example, if you foolishly write a big "if" statement that spans several lines, has many sub-expressions with addition, multiplication, shifting, ?: conditionals, ands, ors, or any other operators at different precedences, it is extremely difficult and time consuming for anyone else to come along and modify that code, without reindenting it and wrapping it all in parenthesis, simply to understand what it does.
Second of all, you are probably responsible for many bugs youself, because you reply on precedence! How is the poor sucker who has to debug your code supposed to figure out if you really MEANT to depend on the subtle order of evaluation, or if you were simply too foolish to put in enough parenthesis so there was no visual ambiguity, therefore no bug?
If you're DESIGNING a language for expressions, you've got to design GOOD, SIMPLE, CONSISTENT, EASY TO REMEMBER RULES, or else the poor victims who have to use your language will waste a huge amount of time and energy trying to make up for your stupid mistake as a language designer, and fixing bugs they never would have encountered were it not for your short sightedness.
This is a discussion about the DESIGN of programming languages. It's acceptable to QUESTION the rules, instead of blindly following them, and blaming the victims for the mistakes they couldn't help but make, because their language was badly designed.
Don't act like such a pedantic school teacher with a ruler always ready to smack the hand of anyone who makes a mistake. Rules should not be designed as opportunities to PUNISH people for breaking them. They should help people get their work done more easily and efficiently, instead. And precedence rules cause much more harm than they do any good.
How does not having to type parenthesis really improve your life? If you were a good programmer, you'd type them anyway, because it's your duty to write robust maintainable easy to read code. Precedence rules only open up the door to hard-to-spot mistakes, they don't prevent any.
Precedence rules come from written mathematical expressions, which is a two dimensional visual language. Conventional programming languages are written in ASCII, which is a one dimensional string of characters. It's not possible to directly express the two dimensional branching and grouping in ASCII that you can in written mathematical expressions, therefore you have to use parenthesis and other explicit grouping and associative techniques. Precedence rules are subtle, invisible, and a totally arbitrary convention copied from mathematics and then taken to a ridiculous extreme. There's absolutely nothing "natural" or "essential" about it, like the rest of math. It's like arguing that racial prejudice is good and natural, just because you learned it from your parents.
Mathematical notation was arbitrarily made up over history by many different people. As you should know, there's no rhyme or reason to most of it, and a bad notation can certainly get in the way of understanding the problem.
That's why Alan Turing and others had to invent their own ways of writing expressions like differential equations, that make the problem easier to understand and work with. There is certainly room for evolution and improvement -- mathematical notation was not carved on stone and handed down to us from God.
It's ridiculous to say that precedence rules are easy to learn, because they're based on mathematical notation. People aren't born with it. They have to learn it over time, just like any other syntax in any programming language.
Most people in this world have very little understanding (and a lot of misunderstanding) about math, and couldn't give a flying fuck about traditional mathematical notation.
I don't believe knowing grammar is optional, but I do believe the grammar should be simple and well defined enough that you can quickly learn ALL of it. This is certainly NOT the case with C++. Off the top of your head, what's the syntax for declaring and using a pointer to a member function? How did your knowledge of mathematical notation help you with answering that question? And what's the relative precedence of that syntax, compared to pointer indirection? How do you use an array of pointers to member functions?
Whatever it is, you'd better put in a lot of extra parenthesis, and use temporary intermediate typedefs and variables, if you want your code to be readable, maintainable and robust.
If you protest that it slows down your code, you don't know the first thing about compilers. If you protest that it slows you down, then that's good, because you should realize that writing robust code prevents bugs and saves a whole lot more time and energy in the long run.
Some time during the roaring 80's, Bill Joy made the following two predictions at a Sun Users Group talk:
a) Computers would increase in speed, to the tune of 2^(year-1984) MIPS. [That would put us at 131,072 MIPS today, and 262,144 MIPS in a few months.]
b) He predicted the rise of a safe system programming language he called C+++=-- (pronounced "see plus plus, plus equals, minus minus), which is a safe subset of a C++ superset.
Java hadn't been invented yet, but Gosling (who was busy inventing NeWS at the time) wrote Oak aka Java several years later, and it fit the description to a tee, but just had a different name or two.
[I'll never forgive Bill Joy for writing VI and CSH. Ewwww icky yucko!]
Check out SWIG,
the Simplified Wrapper and Interface Generator.
"SWIG is a software development tool that connects programs written in C, C++, and Objective-C with a variety of high-level programming languages. SWIG is primarily used with common scripting languages such as Perl, Python, Tcl/Tk, Ruby, Guile and MzScheme."
You can write your code as portable C++ classes, and then use SWIG to automatically read in the header file, and write out all the glue code to plug your C++ classes (or C libraries) into the scripting language of your choice.
A tool like C that requires a program like cdecl to figure it out is foolishly designed, and you're wasting a lot of your time and energy limping along with crutches, when there's no reason to have broken your legs in the first place. I think of C as a "moronic" leg, no a "bionic" one.
I can't remember, but I sure could use some more peanut butter cups.
Did you get fired over a misplaced operator in the past, or something, and still hold a grudge against C? Because operator precedence is not the major obstacle to readability in any language. Let's talk about block structure.
Your guess was close, but it was even more traumatic than that. A stupid TA took off points because I left a superfluous BEGIN/END in my Pascal program, around a single statement terminated by a semicolon underneath an IF statement. I insisted that the reason the null statement was defined in Pascal was exactly for that purpose. And that the code was more maintainable because it was easier to insert and delete debugging writeln statements in the if statement, without having to move to the previous line and add a semicolon. But he marked me off anyway.
What's that? You say Emacs has built-in support for helping you find out which s-expression the star is in? Dude. If you need a computer to help you read code, the code isn't readable.
Yeah, I admit it. I have written functions that go on for pages and pages, and I need Emacs to help me understand and edit them. Out of necessity and haste, I've written lots of horrible code that isn't readable, and I've been stuck working with and maintaining a whole lot more unreadable code than I could ever write myself. That is life. Thank McCarthy for Lisp and RMS for Emacs. Now where do we go from here?
Wouldn't the world be a better place if more programs were written in languages that were essentially easy to maintain and more robust against mistakes, misunderstanding, code rot and entropy?
I view parenthesis like the tie-downs and steel bars that reinforce a building against hurricanes and earthquakes, such as email corruption, global search-and-replace damage, tab changes and misleading reindentation.
Python: None (it was developed by one of those annoying usability gurus)
Please don't pigeonhole Guido van Rossum as a usability guru -- GUI is only 60% of his first name!
He's really a completely general purpose Guru!
Python is just the latest thing that Guido is well know for. Just as Java is for Gosling, who's also implemented several programming languages that most headhunters have never heard of.
Maybe the reason Yahoo can't hire anyone to translate their working Lisp system to C, is that what it's doing is much to complex and dynamic to implement and maintain in C.
Yahoo is a lot better off with a working production quality Lisp solution, rather than no solution at all. If they had implemented it in Perl, I'm sure it would have collapsed under its own weight by now.
As much of a productivity drain learning a new languages is, it's a fact of life that there are millions of special purpose little languages out there, built into most of the large projects you will probably encounter in your career as a programmer.
Take LambdaMoo's Moo scripting language, Quake's attempt at C, RMS Emacs's Teco, Gosling Emacs's infamous Mocklisp, Gnu Emacs's ELisp, AutoCad's AutoLisp, 3D Studio Max's MaxScript, Maya's GEL, or Alice's Python, as a few examples.
You should thank the gods when somebody was thoughtful enough to use a decent, well documented and supported, off-the-shelf extension language like Lisp, Scheme or Python.
But most of the time, large programs that pass a certain point of complexity inevitably develop their own cheezy special purpose totally bizarre weird assed scripting languages with silly names, that you simply have no other choice but to learn to love and live with.
This was certainly the case with The Sims. It has a built-in special purpose visual programming language called "SimAntics", that Maxis developed over a long period of time to support the needs of Will Wright, to dynamically design and prototype simulated human behavior, which was used in SimCopter, then in The Sims.
Designing, implementing and debugging the visual programming language, porting it from the Mac to Windows, supporting it with debuggers, browsers, editors, writing documentation, training new hires and summer interns to use it, all was an enormous drain of time and resources: it was no easy solution or magic bullet. But the result was well worth it.
Having been given a choice between passing up a job because I wanted to stick to tools and programming languages I already knew and loved, or else having to use horrible tools like Visual C++, STL, and DirectX, and learn "yet another silly special purpose programming language" in order to work with Will Wright on The Sims, I have no regrets that I chose to use horrible tools and learn yet another silly programming language.
My point is that you're cheating yourself out of some of the most interesting jobs in the industry, if you refuse to use shitty tools or learn weird new languages that no headhunter has ever heard of.
In the mathematical sense described by Alan Turing, all programming languages are equivalent.
But in the usability sense explored by the
Psychology of Programming
field, there are important differences between programming languages, in terms of ease of use, learnability, maintainability, readability, syntactic surface area, cognitive load, etc.
The trivial fact that a language is Turing complete, does not mean that it's well designed or easy to use. It's not all just a function of the programmer's skill. Certainly there are objective qualitative differences between programming languages that make some substantially better than others.
Did you know that Scott Kim designed the cover of the Dylan manual!
We shipped the final version of ScriptX, and Kaleida closed in January of 1996.
Apple said they were going to support it at first, then swept it under the rug.
Now you can't find anything about ScriptX on Apple's or IBM's web sites.
Python
and
Zope
are clearly the coolest dynamic cross platform open source programming environments happening today.
The poor dude's got macrophobia, the fear of thinking in the large.
There is only one hell worse than debugging Lisp macros, and that's not having any Lisp macros to debug.
Debugging macros in any language is hard. Instead of Lisp macros, would you rather be debugging C++ templates like STL?
Seriously, have you ever tried to port any large code bases using STL from one platform to another? It totally sucks! The fountain of error messages that the compiler vomits gives no clue to the cause to the problem. Debugging STL is much more difficult than debugging Lisp macros, because of the nonsensical jibberish it expands into that the compiler won't even show, instead of simple Lisp s-expressions.
That's a hell of lot worse than writing clean, simple, reliable, portable macros in Lisp, that you don't have to spend ages debugging, because they often work the first time. Lisp macros are well defined and easy to understand compared to C++ templates mish-mashed with C preprocessor macros.
Forget all the prejudices against macros you ever learned from other languages like the C preprocessor and C++ templates. They're fundamentally flawed, and qualitatively inferior to Lisp macros.
The ScriptX programming language from Kaleida was like what you describe: essentially a multimedia object oriented cross platform lexically scoped Lisp, Scheme or more specifically Dylan, but with a simple, more traditional surface syntax.
The ScriptX parser allowed you to type in a straightforward javascript-like syntax, with traditional infix notation, precedence rules and other additional syntactic sugar.
The parser transformed text into a parse tree, that was like Lisp s-expressions. ScriptX macros operated in terms of those parse trees, not the surface syntax. So internally it even had "downward passing" continuations (that you couldn't pass outside of the scope they were created), but the parse trees were compiled into a byte code, not unlike the Java virtual machine (which explains why it didn't support fully general continuations).
So you could implement any number of different surface syntaxes for ScriptX, by writing different parsers.
My trusty Kaleida colleague DanFuzz wrote a traditional Scheme parser for ScriptX.
ScriptX was a lot like Dylan with a cross platform multimedia class library. It was essentially a Lisp-like language, designed around an object system and class library, more dynamic like CLOS than static like Java.
Unlike Java, all data types including integers and arrays are first class objects.
ScriptX had a rich set of polymorphic container classes, much more dynamic than STL, that made heavy use of multiple inheritance.
The container classes (like arrays and maps) were supported by the language sytax, and mixed into many system classes, so you could easily treat windows as arrays, looping over their subwindows, filtering collections of objects through functions and type conversions with "pipes", mix collections into your own classes so they're easy to use through well supported interfaces, etc.
ScriptX had built-in high level time synchronization and graphics classes, including QuickTime movies, sprite graphics like Director, and vector graphics similar to Flash.
One of the great things about ScriptX, which also applies to CLOS and Dylan which inspired it, is its wonderful dynamic objects system. Programming in C++ and STL is totally miserable after having been exposed to ScriptX and CLOS.
For example, I subclassed ScriptX container classes like Array to implement ScriptX Classes for automatically generating HTML, that macros can plug together like legos and dynamically expand into complex web pages.
The ScriptX Tracking Service is a good example of using multiple inheritance with the container and presentation classes.
There's an abstract class called Tracker (that inherits only from RootObject): "This mixin class gives an object the ability to track the mouse, by participating in the tracking service protocol. You can mix Tracker in with presentation and model objects to implement all kinds of direct manipulation interfaces.".
The abstract Tracker class is subclassed by the concrete leaf class TrackerCachedPresenter, and also by another abstract class, TrackerMulti, which implement the recursive tracking protocol.
TrackerMulti is then mixed down into concrete with the various container presentation classes TrackerMultiPresenter, TrackerGroupPresenter and TrackerTwoDSpace.
At the time (1995), Java was no nowhere near capable of doing anything like that on the Mac, Windows and OS/2. With regard to more modern languages, Python is most exciting dynamic and practical programming language around.
The best thing about Python, is that it's completely open source.
It's not tightly controled by a short sighted company that only intends to use it in their religious Jihad against Microsoft, like Java.
And it's not proprietary, jointly developed by strange bedfellows Apple and IBM, and swept under the rug, like Kaleida's ScriptX was.
So Python will be around forever, while quickly and naturally evolving, because it has earnestly learned so many lessons from Lisp and other languages.
If you're just talking about readability, Lisp is much more readable than most other languages. Especially "popular" ones like C++ and Perl.
And readability has a whole lot to do with maintainability. Programs should not just be written for the computer to understand. Much more importantly, other people should be able to clearly read and unambiguously understand the code.
I've read and written quite a lot of Lisp and other Lisp-like languages, not only in school, but also in the real world. I've spent much time reading, understanding and modifying huge complex Lisp systems written by other people, and I don't think it's unreadable at all. Well written Lisp code is extremely elegant, and a joy to read.
Complaining about parenthesis is trivial, misguided nit picking, and totally misses many much more important points.
Don't like parenthesis? Then let's talk about how all the subtle levels of operator precedence and associativity rules effect the readability and writability of C, C++, Java and Perl code!
Can't remember the difference in precedence between "==" and "<="? Then you have to either look it up (and require the poor bastards reading your code to either remember it or look it up themselves), or use an extra level of parenthesis!
Now whose code has lots of unnecessary parenthesis? Not the Lisp code. Every paren is in there for a reason. But most C, C++, Java and Perl code is eather riddled with unnecessary parenthesis, or totally unreadable, brittle and unmaintainable, because it subtly depends on operator precedence and associativity.
Most competent programmers put in lots of extra parenthesis just to be sure, because code is changed over time by other people. Relying on operator precidence causes many subtle, hard to find bugs, because it's extremely easy to make and miss practically invisible mistakes. And text editors like Emacs can't give you any help with operator precedence and associativity, like they can with parenthesis.
The arguments for operator precedence that claim people expect it are ridiculous. It's an utterly arbitrary and capricious linguistic artifact foolishly copied from mathematics (which most people don't understand), and taken to a ridiculous extreme (with many additional subtle levels of precedence for operators that simply don't exist in standard mathematical notation).
http://www.howstuffworks.com/c14.htm
C contains many operators, and because of the way in which operator precedence works, the interactions between multiple operators can become confusing.
x=5+3*6;
X receives the value 23, not 48, because in C multiplication and division have higher precedence than addition and subtraction.
char *a[10];
Is a a single pointer to an array of 10 characters, or is it an array of 10 pointers to character? Unless you know the precedence conventions in C, there is no way to find out. Similarly, in E.11 we saw that because of precedence statements such as *p.i = 10; do not work. Instead, the form (*p).i = 10; must be used to force correct precedence.
The following table from Kernigan and Richie shows the precedence hierarchy in C. The top line has the highest precedence.
[I am forced to spell out the operators in order to get past slashdot's lameness filter -- and I totally agree that languages with lots of ridiculous noisy punctuation are lame. Save it for cursing in comic strips.]
Operators : Associativity
"open paren" "open bracket" "minus" "dot": Left to right
"exclamation mark", "plus", "minus", "plus-plus", "minus-minus", "star", "ampersand", "(type-cast)", "sizeof": Right to left
(in the above line, "plus", "minus" and "star" are the unary forms)
"star", "slash", "percent": Left to right
"plus", "minus": Left to right
"less-less", "greater-greater": Left to right
"less", "less-equal", "greater", "greater-equal": Left to right
"equal-equal", "exclaimation-equal": Left to right
"ampersand": Left to right
"caret": Left to right
"pipe" : Left to right
"ampersand-ampersand": Left to right
"pipe-pipe": Left to right
"question-colon": Left to right
"equal", "plus-equal", "minus-equal", "slash-equal", "percent-equal", "ampersand-equal", "caret-equal", "pipe-equal", "less-less-equal", "greater-greater-equal": Right to left
"comma": Left to right
Using this table, you can see that char *a[10]; is an array of 10 pointers to character. You can also see why the parentheses are required if (*p).i is to be handled correctly. After some practice, you will memorize most of this table, but every now and again something will not work because you have been caught by a subtle precedence problem.
Some games are high creative art (like Seaman), and most others are low trashy art (like Quake). But they're all art.
Why do the eggheads bother asking such easy questions as "are video games art"? Mega-duh. How about asking more interesting questions like "how can we apply art to other computer applications like spreadsheets, word processors, web browsers and programming languages?"
What happens when art meets a programming language? Check out the most amazing stuff I've ever seen done with Flash 5 -- and it's all open source:
And here's the most elegant approach to a visual programming language I've ever seen. Click the right button and select "Zoom" a few times, then pan around with the left button to manipulate the icons close-up:
What Python lacks that's extremely important to Lisp, is a macro facility.
String based macros like the C and C++ preprocessors are woefully inadequate.
Representing code as data and transforming code with macros is essential to Lisp.
Take macros and s-expressions away from Lisp, and you have Python.
Take macros and gratuitous syntax away from C++, and you have Java.
Because of the syntax of languages like C, C++ and Java, there's no good way to design a macro language as powerful and easy to use as Lisp macros.
The pointlessly ridiculous syntax of Perl make it impossible to implement Lisp-like macros for Perl in a meaningful way.
The Byzantine parse-tree data structures required to represent the syntax of a Perl program are much too complex for macros to easily understand and transform.
Before he designed Java, James Gosling took a crack at the problem by designing and implementing a C macro language called "Ace".
Ace was a high level C parse tree macro transformation language, used to generate the low level raster-op code for the X11/NeWS server.
The previous version of NeWS totally abused the C preprocessor in ways it wasn't designed to be used, in order to implement the low level high performance graphics code (a dark, unpleasant practice known as "macrology").
Gosling designed Ace in response to the problems and limitations of the C preprocessor, as he later designed Java in response to C++.
You could give Ace several ways to implement loops like two dimensional raster operations, and it could different plug code into the middle of loops with different performance characteristics.
Commonly used rasterops could be expanded to different degrees, with many different cases separately coded (pulling the if statements to the outside and generating big fast code).
Seldom used rasterops could be collapsed so the code was correct but compact (pushing the if statements inside of the loop and generating small slow code).
Ace operated on the level of C parse trees, not text like C preprocessor macros.
Ace would actually estimate the space/time tradeoffs, and decide how to expand macros according to the hints you gave it.
But Ace transformations were quite complex, special purpose and difficult to program.
So James Gosling decided not to put macros into Java at all.
The success of Java proves that C and C++ preprocessor macros are not essential to those kinds of languages. But Lisp macros are vastly more powerful, and absolutely essential to Lisp.
Ace was an ambitious tour de force for a C macro language, but it was much too complex and unwieldy for Gosling to design into Java.
But that kind of macro programming is actually quite commonplace and straightforward with Lisp.
I think Lem has every right to publish the letter Dick wrote to the FBI, simply because it's so interesting, if not just to clear his own name.
Lem can certainly be harsh when he wants, but has a lot of great things to say about Dick, in his essays entitled "Science Fiction: A Hopeless Case---with Exceptions" and "Philip K Dick is a Visionary Among the Charlatans".
Dick deserves the "blame" for that letter as much as he deserves the "credit" for everything else he wrote during the time that he was insane.
If you don't hold him responsible for that letter, you can't hold him responsible for the other stories he wrote, either. I think he deserves credit for everything he wrote.
Here are some refreshingly harsh quotes from Lem about science fiction. I have to agree with him that most science fiction is trash. But I love trash, and reading his essays helps me better appreciate the trash I read.
"American science fiction, exploiting its exceptional status, lays claim to occupy the pinnacles of art and thought. One is annoyed by the pretentiousness of a genre that fends off accusations of primitivism by pleading its entertainment character and then, once such accusations have been silenced, renews its overweening claims." (from his essay "Philip K. Dick: A Visionary Among the Charlatans" - Lem was once a member of the Science Fiction Writers of America, but was expelled in 1976)
"Science fiction became a vulgar mythology of technological civilization. I wrote its monograph without the intention of creating a crushing critique....I think that this monograph is an expression of my personal utopia: a longing for a better science fiction - one that should exist." (writing about his Fantastyka i futurologia)
"Some time ago crime was modest - take Al Capone and his mere two dozens of victims. Now we have the Independence Day movie, where alien spaceships murder almost the entire mankind. Some American producer claims now that his next picture will be even stronger. But what can be stronger? To murder an entire biosphere? This is so disgusting for me, that I decided to leave the street-car of science fiction on a stop of essay writing." (from 1996 Orlinski interview)
Nanotech nothing. Just crush the rock, mix in some shit, water it, plant a seed, and wait. Sheez. Lots of trees growing on this rock we call Earth, without any help from nanotech.
What a small world! I'm glad I didn't get beat up for suspiciously driving around that neighborhood all afternoon, looking for my van. I found a lot of vans, but not mine.
Slashdot Mirror
The wheels of government and commerce would grind to a halt were they not well lubricated with Bull Shit. So I created the Bull Shit Markup Language and published the BSML web page years ago, putting it on the public domain for the good of mankind. Now somebody has finally taken it seriously, and is trying to monopolise BSML!
He who controls BSML controls the Bull Shit... and he who controls the Bull Shit controls the Universe!
http://catalog.com/hopkins/text/bsml.html
Does anyone know of any prior art pertaining to Bull Shit and Markup Languages? What about VRML -- Maybe I could get Mark Pesche to testify on my behalf? c(-;
Here's a list of the huge faceless multinational corporations I'm up against:
http://www.labbook.com
"IBM, NetGenics, Apocom, Bristol-Myers Squibb, Wiley and other leaders of the life sciences industry support LabBook's BSML as the standard for biological information".
To paraphrase Pastor Martin Niemöller:
First they patented the Anthrax Vaccine
and I did not speak out
because I did not have Anthrax.
Then they patented the AIDS Drugs
and I did not speak out
because I did not have AIDS.
Then they patented Viagra
and I did not speak out
because I already had an erection.
Then they came for the Bull Shitters
and there was no one left
to speak out for me.
-Don
Appearently, they would prefer that people searching for "BSML" did not turn up my web page. I wonder if they've tried to get the Boston School for Modern Languages to change their name, too?
Now isn't the whole point of properly using XML and namespaces to disambiguate coincidental name clashes like this? If LabBook thinks there's a problem with more than one language named BSML, then they obviously have no understanding of XML, and aren't qualified to be using it to define any kind of a standard.
Maybe LabBook should put some meta-tags on their web pages to decrease their relevence when people are searching for "Bull Shit" or "Modern Language".
-Don
========
From: "Gene Van Slyke" <gene.vanslyke@labbook.com>
To: <don@toad.com>; <dhopkins@maxis.com>
Sent: Monday, November 12, 2001 10:36 AM
Subject: BSML Trademark
Don,
While reviewing the internet for uses of BSML, we noted your use of BSML on http://catalog.com/hopkins/text/bsml.html.
While we find your use humorous, we have registed the BSML name with the United States Patent and Trademark Office and would appreciate you removing the reference to BSML from your website.
Thanks for your cooperation,
Gene Van Slyke
CFO LabBook
========
Here's the page I published years ago at http://catalog.com/hopkins/text/bsml.html:
========
BSML: Bull Shit Markup Language
Bull Shit Markup Language is designed to meet the needs of commerce, advertising, and blatant self promotion on the World Wide Web.
New BSML Markup Tags
CRONKITE Extension
This tag marks authoritative text that the reader should believe without question.
SALE Extension
This tag marks advertisements for products that are on sale. The browser will do everything it can to bring this to the attention of the user.
COLORMAP Extension
This tag allows the html writer complete control over the user's colormap. It supports writing RGB values into the system colormap, plus all the usual crowd pleasers like rotating, flashing, fading and degaussing, as well as changing screen depth and resolution.
BLINK Extension
The blinking text tag has been extended to apply to client side image maps, so image regions as well as individual pixels can now be blinked arbitrarily.
The RAINBOW parameter allow you to specify a sequence of up to 48 colors or image texture maps to apply to the blinking text in sequence.
The FREQ and PHASE parameters allow you to precisely control the frequence and phase of blinking text. Browsers using Apple's QuickBlink technology or MicroSoft's TrueFlicker can support up to 65536 independently blinking items per page.
Java applets can be downloaded into the individual blinkers, to blink text and graphics in arbitrarily programmable patterns.
See the Las Vegas and Times Square home pages for some excellent examples.
Of couse Network Solutions would not answer any of my email or phone calls, for which they are infamous.
So I had to register the domain name "mindsprinc.com" (with ANOTHER registrar, of course -- I never used Network Solutions after that), and then I simply sent them email from that domain name asking their automated system to fix it.
-Don
What they didn't teach you in elementary school was that there might be any more than TWO levels of precedence. Nothing from elementary school prepared you for the FIFTEEN or so levels of precedence on C. Two levels was bad enough, but FIFTEEN is RIDICULOUS.
The fact is that the rules DO change from language to language. Each language with precedence rules has ITS OWN SET OF OPERATORS. Some blindly copy the precedence rules of C, but none of them are exactly the same.
And the rules of C++ have been changing for many years, so much that it's a running joke. If you think mathematical notation is so wonderful, then why can't you multiply a and b by writing "ab"?
Now do you still really want to blindly copy mathematical notation? Read Bjarne Stroustrup's paper, "Generalizing Overloading for C++2000" to see where that will lead. If you still think it's a good idea after reading that, let me remind you he wrote it as an April Fools joke. (The paper, not C++.)
Relying on precedence most certainly DOES make code hard to maintain, and easy to break ("brittle").
It's a fact that code changes over time, and many different people make those modifications. If any of those people did rely on precedence instead of using extra parenthesis, the chances are much higher that the code will break whenever you or somebody else modifies it. Much worse than simply breaking with a syntax error: its meaning will change, but it will still compile without error, so you probably won't even notice you made a mistake.
By "brittle", I mean that code should be ROBUST in the face of CHANGE, and precedence flies in the face of that.
For example, if you foolishly write a big "if" statement that spans several lines, has many sub-expressions with addition, multiplication, shifting, ?: conditionals, ands, ors, or any other operators at different precedences, it is extremely difficult and time consuming for anyone else to come along and modify that code, without reindenting it and wrapping it all in parenthesis, simply to understand what it does.
Second of all, you are probably responsible for many bugs youself, because you reply on precedence! How is the poor sucker who has to debug your code supposed to figure out if you really MEANT to depend on the subtle order of evaluation, or if you were simply too foolish to put in enough parenthesis so there was no visual ambiguity, therefore no bug?
If you're DESIGNING a language for expressions, you've got to design GOOD, SIMPLE, CONSISTENT, EASY TO REMEMBER RULES, or else the poor victims who have to use your language will waste a huge amount of time and energy trying to make up for your stupid mistake as a language designer, and fixing bugs they never would have encountered were it not for your short sightedness.
This is a discussion about the DESIGN of programming languages. It's acceptable to QUESTION the rules, instead of blindly following them, and blaming the victims for the mistakes they couldn't help but make, because their language was badly designed.
Don't act like such a pedantic school teacher with a ruler always ready to smack the hand of anyone who makes a mistake. Rules should not be designed as opportunities to PUNISH people for breaking them. They should help people get their work done more easily and efficiently, instead. And precedence rules cause much more harm than they do any good.
How does not having to type parenthesis really improve your life? If you were a good programmer, you'd type them anyway, because it's your duty to write robust maintainable easy to read code. Precedence rules only open up the door to hard-to-spot mistakes, they don't prevent any.
Precedence rules come from written mathematical expressions, which is a two dimensional visual language. Conventional programming languages are written in ASCII, which is a one dimensional string of characters. It's not possible to directly express the two dimensional branching and grouping in ASCII that you can in written mathematical expressions, therefore you have to use parenthesis and other explicit grouping and associative techniques. Precedence rules are subtle, invisible, and a totally arbitrary convention copied from mathematics and then taken to a ridiculous extreme. There's absolutely nothing "natural" or "essential" about it, like the rest of math. It's like arguing that racial prejudice is good and natural, just because you learned it from your parents.
Mathematical notation was arbitrarily made up over history by many different people. As you should know, there's no rhyme or reason to most of it, and a bad notation can certainly get in the way of understanding the problem.
That's why Alan Turing and others had to invent their own ways of writing expressions like differential equations, that make the problem easier to understand and work with. There is certainly room for evolution and improvement -- mathematical notation was not carved on stone and handed down to us from God.
It's ridiculous to say that precedence rules are easy to learn, because they're based on mathematical notation. People aren't born with it. They have to learn it over time, just like any other syntax in any programming language. Most people in this world have very little understanding (and a lot of misunderstanding) about math, and couldn't give a flying fuck about traditional mathematical notation.
I don't believe knowing grammar is optional, but I do believe the grammar should be simple and well defined enough that you can quickly learn ALL of it. This is certainly NOT the case with C++. Off the top of your head, what's the syntax for declaring and using a pointer to a member function? How did your knowledge of mathematical notation help you with answering that question? And what's the relative precedence of that syntax, compared to pointer indirection? How do you use an array of pointers to member functions?
Whatever it is, you'd better put in a lot of extra parenthesis, and use temporary intermediate typedefs and variables, if you want your code to be readable, maintainable and robust.
If you protest that it slows down your code, you don't know the first thing about compilers. If you protest that it slows you down, then that's good, because you should realize that writing robust code prevents bugs and saves a whole lot more time and energy in the long run.
-Don
I guess that means csh is just cat and echo with syntactic syrup of ipicac.
And vi is just insert and delete with semantic anthrax.
-Don
a) Computers would increase in speed, to the tune of 2^(year-1984) MIPS. [That would put us at 131,072 MIPS today, and 262,144 MIPS in a few months.]
b) He predicted the rise of a safe system programming language he called C+++=-- (pronounced "see plus plus, plus equals, minus minus), which is a safe subset of a C++ superset.
Java hadn't been invented yet, but Gosling (who was busy inventing NeWS at the time) wrote Oak aka Java several years later, and it fit the description to a tee, but just had a different name or two.
[I'll never forgive Bill Joy for writing VI and CSH. Ewwww icky yucko!]
-Don
"SWIG is a software development tool that connects programs written in C, C++, and Objective-C with a variety of high-level programming languages. SWIG is primarily used with common scripting languages such as Perl, Python, Tcl/Tk, Ruby, Guile and MzScheme."
You can write your code as portable C++ classes, and then use SWIG to automatically read in the header file, and write out all the glue code to plug your C++ classes (or C libraries) into the scripting language of your choice.
-Don
-Don
I can't remember, but I sure could use some more peanut butter cups.
Your guess was close, but it was even more traumatic than that. A stupid TA took off points because I left a superfluous BEGIN/END in my Pascal program, around a single statement terminated by a semicolon underneath an IF statement. I insisted that the reason the null statement was defined in Pascal was exactly for that purpose. And that the code was more maintainable because it was easier to insert and delete debugging writeln statements in the if statement, without having to move to the previous line and add a semicolon. But he marked me off anyway.
Yeah, I admit it. I have written functions that go on for pages and pages, and I need Emacs to help me understand and edit them. Out of necessity and haste, I've written lots of horrible code that isn't readable, and I've been stuck working with and maintaining a whole lot more unreadable code than I could ever write myself. That is life. Thank McCarthy for Lisp and RMS for Emacs. Now where do we go from here?
Wouldn't the world be a better place if more programs were written in languages that were essentially easy to maintain and more robust against mistakes, misunderstanding, code rot and entropy?
I view parenthesis like the tie-downs and steel bars that reinforce a building against hurricanes and earthquakes, such as email corruption, global search-and-replace damage, tab changes and misleading reindentation.
Please don't pigeonhole Guido van Rossum as a usability guru -- GUI is only 60% of his first name! He's really a completely general purpose Guru! Python is just the latest thing that Guido is well know for. Just as Java is for Gosling, who's also implemented several programming languages that most headhunters have never heard of.
-Don
Yahoo is a lot better off with a working production quality Lisp solution, rather than no solution at all. If they had implemented it in Perl, I'm sure it would have collapsed under its own weight by now.
As much of a productivity drain learning a new languages is, it's a fact of life that there are millions of special purpose little languages out there, built into most of the large projects you will probably encounter in your career as a programmer.
Take LambdaMoo's Moo scripting language, Quake's attempt at C, RMS Emacs's Teco, Gosling Emacs's infamous Mocklisp, Gnu Emacs's ELisp, AutoCad's AutoLisp, 3D Studio Max's MaxScript, Maya's GEL, or Alice's Python, as a few examples.
You should thank the gods when somebody was thoughtful enough to use a decent, well documented and supported, off-the-shelf extension language like Lisp, Scheme or Python.
But most of the time, large programs that pass a certain point of complexity inevitably develop their own cheezy special purpose totally bizarre weird assed scripting languages with silly names, that you simply have no other choice but to learn to love and live with.
This was certainly the case with The Sims. It has a built-in special purpose visual programming language called "SimAntics", that Maxis developed over a long period of time to support the needs of Will Wright, to dynamically design and prototype simulated human behavior, which was used in SimCopter, then in The Sims.
Designing, implementing and debugging the visual programming language, porting it from the Mac to Windows, supporting it with debuggers, browsers, editors, writing documentation, training new hires and summer interns to use it, all was an enormous drain of time and resources: it was no easy solution or magic bullet. But the result was well worth it.
Having been given a choice between passing up a job because I wanted to stick to tools and programming languages I already knew and loved, or else having to use horrible tools like Visual C++, STL, and DirectX, and learn "yet another silly special purpose programming language" in order to work with Will Wright on The Sims, I have no regrets that I chose to use horrible tools and learn yet another silly programming language.
My point is that you're cheating yourself out of some of the most interesting jobs in the industry, if you refuse to use shitty tools or learn weird new languages that no headhunter has ever heard of.
-Don
-Don
But in the usability sense explored by the Psychology of Programming field, there are important differences between programming languages, in terms of ease of use, learnability, maintainability, readability, syntactic surface area, cognitive load, etc.
The trivial fact that a language is Turing complete, does not mean that it's well designed or easy to use. It's not all just a function of the programmer's skill. Certainly there are objective qualitative differences between programming languages that make some substantially better than others.
-Don
We shipped the final version of ScriptX, and Kaleida closed in January of 1996. Apple said they were going to support it at first, then swept it under the rug. Now you can't find anything about ScriptX on Apple's or IBM's web sites.
Python and Zope are clearly the coolest dynamic cross platform open source programming environments happening today.
-Don
There is only one hell worse than debugging Lisp macros, and that's not having any Lisp macros to debug.
Debugging macros in any language is hard. Instead of Lisp macros, would you rather be debugging C++ templates like STL?
Seriously, have you ever tried to port any large code bases using STL from one platform to another? It totally sucks! The fountain of error messages that the compiler vomits gives no clue to the cause to the problem. Debugging STL is much more difficult than debugging Lisp macros, because of the nonsensical jibberish it expands into that the compiler won't even show, instead of simple Lisp s-expressions.
That's a hell of lot worse than writing clean, simple, reliable, portable macros in Lisp, that you don't have to spend ages debugging, because they often work the first time. Lisp macros are well defined and easy to understand compared to C++ templates mish-mashed with C preprocessor macros.
Forget all the prejudices against macros you ever learned from other languages like the C preprocessor and C++ templates. They're fundamentally flawed, and qualitatively inferior to Lisp macros.
-Don
The ScriptX parser allowed you to type in a straightforward javascript-like syntax, with traditional infix notation, precedence rules and other additional syntactic sugar.
The parser transformed text into a parse tree, that was like Lisp s-expressions. ScriptX macros operated in terms of those parse trees, not the surface syntax. So internally it even had "downward passing" continuations (that you couldn't pass outside of the scope they were created), but the parse trees were compiled into a byte code, not unlike the Java virtual machine (which explains why it didn't support fully general continuations).
So you could implement any number of different surface syntaxes for ScriptX, by writing different parsers. My trusty Kaleida colleague DanFuzz wrote a traditional Scheme parser for ScriptX.
ScriptX was a lot like Dylan with a cross platform multimedia class library. It was essentially a Lisp-like language, designed around an object system and class library, more dynamic like CLOS than static like Java. Unlike Java, all data types including integers and arrays are first class objects.
ScriptX had a rich set of polymorphic container classes, much more dynamic than STL, that made heavy use of multiple inheritance.
The container classes (like arrays and maps) were supported by the language sytax, and mixed into many system classes, so you could easily treat windows as arrays, looping over their subwindows, filtering collections of objects through functions and type conversions with "pipes", mix collections into your own classes so they're easy to use through well supported interfaces, etc.
ScriptX had built-in high level time synchronization and graphics classes, including QuickTime movies, sprite graphics like Director, and vector graphics similar to Flash.
One of the great things about ScriptX, which also applies to CLOS and Dylan which inspired it, is its wonderful dynamic objects system. Programming in C++ and STL is totally miserable after having been exposed to ScriptX and CLOS.
For example, I subclassed ScriptX container classes like Array to implement ScriptX Classes for automatically generating HTML, that macros can plug together like legos and dynamically expand into complex web pages.
The ScriptX Tracking Service is a good example of using multiple inheritance with the container and presentation classes.
There's an abstract class called Tracker (that inherits only from RootObject): "This mixin class gives an object the ability to track the mouse, by participating in the tracking service protocol. You can mix Tracker in with presentation and model objects to implement all kinds of direct manipulation interfaces.".
The abstract Tracker class is subclassed by the concrete leaf class TrackerCachedPresenter, and also by another abstract class, TrackerMulti, which implement the recursive tracking protocol. TrackerMulti is then mixed down into concrete with the various container presentation classes TrackerMultiPresenter, TrackerGroupPresenter and TrackerTwoDSpace.
ScriptX was great fun to think and program in. It was an ideal language for developing an open ended platform for plugging together dynamically loaded interactive multimedia objects like Legos.
At the time (1995), Java was no nowhere near capable of doing anything like that on the Mac, Windows and OS/2. With regard to more modern languages, Python is most exciting dynamic and practical programming language around.
The best thing about Python, is that it's completely open source.
It's not tightly controled by a short sighted company that only intends to use it in their religious Jihad against Microsoft, like Java.
And it's not proprietary, jointly developed by strange bedfellows Apple and IBM, and swept under the rug, like Kaleida's ScriptX was.
So Python will be around forever, while quickly and naturally evolving, because it has earnestly learned so many lessons from Lisp and other languages.
Q: What do you get when you cross Apple and IBM?
A: IBM.
-Don
Search for: "linear algebra NOT!"
(Postfix "NOT!": Low precedence, right to left associativity.)
-Don
And readability has a whole lot to do with maintainability. Programs should not just be written for the computer to understand. Much more importantly, other people should be able to clearly read and unambiguously understand the code.
I've read and written quite a lot of Lisp and other Lisp-like languages, not only in school, but also in the real world. I've spent much time reading, understanding and modifying huge complex Lisp systems written by other people, and I don't think it's unreadable at all. Well written Lisp code is extremely elegant, and a joy to read.
Complaining about parenthesis is trivial, misguided nit picking, and totally misses many much more important points.
Don't like parenthesis? Then let's talk about how all the subtle levels of operator precedence and associativity rules effect the readability and writability of C, C++, Java and Perl code!
Can't remember the difference in precedence between "==" and "<="? Then you have to either look it up (and require the poor bastards reading your code to either remember it or look it up themselves), or use an extra level of parenthesis!
Now whose code has lots of unnecessary parenthesis? Not the Lisp code. Every paren is in there for a reason. But most C, C++, Java and Perl code is eather riddled with unnecessary parenthesis, or totally unreadable, brittle and unmaintainable, because it subtly depends on operator precedence and associativity.
Most competent programmers put in lots of extra parenthesis just to be sure, because code is changed over time by other people. Relying on operator precidence causes many subtle, hard to find bugs, because it's extremely easy to make and miss practically invisible mistakes. And text editors like Emacs can't give you any help with operator precedence and associativity, like they can with parenthesis.
The arguments for operator precedence that claim people expect it are ridiculous. It's an utterly arbitrary and capricious linguistic artifact foolishly copied from mathematics (which most people don't understand), and taken to a ridiculous extreme (with many additional subtle levels of precedence for operators that simply don't exist in standard mathematical notation).
http://www.howstuffworks.com/c14.htm
C contains many operators, and because of the way in which operator precedence works, the interactions between multiple operators can become confusing.
x=5+3*6;
X receives the value 23, not 48, because in C multiplication and division have higher precedence than addition and subtraction.
char *a[10];
Is a a single pointer to an array of 10 characters, or is it an array of 10 pointers to character? Unless you know the precedence conventions in C, there is no way to find out. Similarly, in E.11 we saw that because of precedence statements such as *p.i = 10; do not work. Instead, the form (*p).i = 10; must be used to force correct precedence.
The following table from Kernigan and Richie shows the precedence hierarchy in C. The top line has the highest precedence.
[I am forced to spell out the operators in order to get past slashdot's lameness filter -- and I totally agree that languages with lots of ridiculous noisy punctuation are lame. Save it for cursing in comic strips.]
Operators : Associativity
"open paren" "open bracket" "minus" "dot": Left to right
"exclamation mark", "plus", "minus", "plus-plus", "minus-minus", "star", "ampersand", "(type-cast)", "sizeof": Right to left
(in the above line, "plus", "minus" and "star" are the unary forms)
"star", "slash", "percent": Left to right
"plus", "minus": Left to right
"less-less", "greater-greater": Left to right
"less", "less-equal", "greater", "greater-equal": Left to right
"equal-equal", "exclaimation-equal": Left to right
"ampersand": Left to right
"caret": Left to right
"pipe" : Left to right
"ampersand-ampersand": Left to right
"pipe-pipe": Left to right
"question-colon": Left to right
"equal", "plus-equal", "minus-equal", "slash-equal", "percent-equal", "ampersand-equal", "caret-equal", "pipe-equal", "less-less-equal", "greater-greater-equal": Right to left
"comma": Left to right
Using this table, you can see that char *a[10]; is an array of 10 pointers to character. You can also see why the parentheses are required if (*p).i is to be handled correctly. After some practice, you will memorize most of this table, but every now and again something will not work because you have been caught by a subtle precedence problem.
-Don
With Java, C and most other neanderthal programming languages, it's only code, and you have no other choice.
The fact that an expression may be interpreted as data or code is an extremely important ADVANTAGE.
Go back to school and learn about Alan Turing.
-Don
Especially after playing Seaman.
http://www.gamenationtv.com/reviews/seaman.shtml
Some games are high creative art (like Seaman), and most others are low trashy art (like Quake). But they're all art.
Why do the eggheads bother asking such easy questions as "are video games art"? Mega-duh. How about asking more interesting questions like "how can we apply art to other computer applications like spreadsheets, word processors, web browsers and programming languages?"
What happens when art meets a programming language? Check out the most amazing stuff I've ever seen done with Flash 5 -- and it's all open source:
http://www.levitated.net/daily/index.html
Don't miss these elegant XML browsers for mapping web pages and reading poetry:
http://www.levitated.net/daily/pondcoderotdaily.ht ml
http://www.levitated.net/daily/pcFinite.html
http://www.levitated.net/daily/may2.html
And here's the most elegant approach to a visual programming language I've ever seen. Click the right button and select "Zoom" a few times, then pan around with the left button to manipulate the icons close-up:
http://www.levitated.net/daily/isoconstruct.html
-Don
What letter's a joke?
Dick and Lem are my favorite writers, and I'm fascinated to learn what they've written about each other.
It just goes to show: never write anything to the FBI that you don't want published.
-Don
String based macros like the C and C++ preprocessors are woefully inadequate. Representing code as data and transforming code with macros is essential to Lisp. Take macros and s-expressions away from Lisp, and you have Python. Take macros and gratuitous syntax away from C++, and you have Java.
Because of the syntax of languages like C, C++ and Java, there's no good way to design a macro language as powerful and easy to use as Lisp macros. The pointlessly ridiculous syntax of Perl make it impossible to implement Lisp-like macros for Perl in a meaningful way. The Byzantine parse-tree data structures required to represent the syntax of a Perl program are much too complex for macros to easily understand and transform.
Before he designed Java, James Gosling took a crack at the problem by designing and implementing a C macro language called "Ace".
Ace was a high level C parse tree macro transformation language, used to generate the low level raster-op code for the X11/NeWS server. The previous version of NeWS totally abused the C preprocessor in ways it wasn't designed to be used, in order to implement the low level high performance graphics code (a dark, unpleasant practice known as "macrology").
Gosling designed Ace in response to the problems and limitations of the C preprocessor, as he later designed Java in response to C++. You could give Ace several ways to implement loops like two dimensional raster operations, and it could different plug code into the middle of loops with different performance characteristics.
Commonly used rasterops could be expanded to different degrees, with many different cases separately coded (pulling the if statements to the outside and generating big fast code). Seldom used rasterops could be collapsed so the code was correct but compact (pushing the if statements inside of the loop and generating small slow code). Ace operated on the level of C parse trees, not text like C preprocessor macros. Ace would actually estimate the space/time tradeoffs, and decide how to expand macros according to the hints you gave it.
But Ace transformations were quite complex, special purpose and difficult to program. So James Gosling decided not to put macros into Java at all.
The success of Java proves that C and C++ preprocessor macros are not essential to those kinds of languages. But Lisp macros are vastly more powerful, and absolutely essential to Lisp.
Ace was an ambitious tour de force for a C macro language, but it was much too complex and unwieldy for Gosling to design into Java. But that kind of macro programming is actually quite commonplace and straightforward with Lisp.
-Don
Dick deserves the "blame" for that letter as much as he deserves the "credit" for everything else he wrote during the time that he was insane. If you don't hold him responsible for that letter, you can't hold him responsible for the other stories he wrote, either. I think he deserves credit for everything he wrote.
Here are some refreshingly harsh quotes from Lem about science fiction. I have to agree with him that most science fiction is trash. But I love trash, and reading his essays helps me better appreciate the trash I read.
From http://www.geocities.com/bill_testerman/LemQuotesP art1.html:
"American science fiction, exploiting its exceptional status, lays claim to occupy the pinnacles of art and thought. One is annoyed by the pretentiousness of a genre that fends off accusations of primitivism by pleading its entertainment character and then, once such accusations have been silenced, renews its overweening claims." (from his essay "Philip K. Dick: A Visionary Among the Charlatans" - Lem was once a member of the Science Fiction Writers of America, but was expelled in 1976)
"Science fiction became a vulgar mythology of technological civilization. I wrote its monograph without the intention of creating a crushing critique....I think that this monograph is an expression of my personal utopia: a longing for a better science fiction - one that should exist." (writing about his Fantastyka i futurologia)
"Some time ago crime was modest - take Al Capone and his mere two dozens of victims. Now we have the Independence Day movie, where alien spaceships murder almost the entire mankind. Some American producer claims now that his next picture will be even stronger. But what can be stronger? To murder an entire biosphere? This is so disgusting for me, that I decided to leave the street-car of science fiction on a stop of essay writing." (from 1996 Orlinski interview)
-Don
-Don
-Don