HyperCard Smut Stack
on
fvwm Turns Ten
·
· Score: 2, Interesting
I accidentally met the author of the HyperCard Smut Stack, several years ago at a dot-com trade show. I was ranting and raving with a group of people about pioneering forms of interactive multimedia, and of course I described the HyperCard Smut Stack with the nipples that go "ping" when you click on them.
Then this guy I didn't know said "I wrote that". I stopped dead in my tracks, my jaw dropped on the floor, I rewound my mental tape of what I had been saying, played it back to myself, and asked incredulously "You wrote the HyperCard Smut Stack??!" He said yes, and proceeded to tell me all about it with pride. It really made his day for somebody to bring up his baby out of the blue like that.
The guy who wrote the HyperCard Smut Stack is none other than
Chuck Farnham, who is notorious in the San Francisco Bay area as a demented radio personality on Alex Bennett's "Live 105" morning radio show. "Yes this is the guy who puts food all over himself and lets people eat off of him."
References were added to Perl 5, which was released on October 18 1994, 7 years after the first release of Perl 1.0 on October 18 1987. They were clearly an afterthought.
Ignorance is forgivable, but Perl advocates and apologists aren't just ignorant, they're maliciously spreading a Contagious Linguistically Acquired Mental Illness (called CLAMI syndrome), that eats up your brain. CLAMI is also known as Mad Webmaster's Disease.
Here's a typical example of how PHP screwed up by mindlessly aping a feature of Perl that was horribly designed in the first place: references.
This demonstrates my point that PHP is merely an anemic, mediocre, unenlightened knee-jerk reaction to Perl, which is an extremely foolish choice of a language to imitate without understanding.
One of the
most underused features of PHP is the ability to use references. The problem is that using references are rather troublesome in PHP. References was not part of the original syntax but has been added later on, thus leading to a somewhat confusing syntax. There's also little support for references in the native function set.
References in PHP are simpler than the related mechanism found in C and C++, C and C++ uses pointers which allows for pointing to memory areas. C++ also has references which are less troublesome than pointers but not as versatile. By using references you can refer or point to the same data using different variables. This is useful when you want to avoid costly memory operations or want functions to access your data directly rather than copying it.
References are created by assigning a variable with the reference operator &.
$a = "data";
$b =& $a;// Now $b refers to data in $a
As I mentioned above the behavior is not as advanced as in C/C++, this means that you cannot create a reference to a reference. For instance let's extend the above example by create a new reference. [...]
Here are some typical comments about Perl references from Google, to get you on the right track (the right track being not programming in Perl because it's a foolishly designed language, since much better languages are freely available):
ma[i][j][k] is different from $ma->[i][j][k], you need to remember - the
shortform only separates uses of [ ] but the -> CANNOT be left out when it
follows an ordinary lvalue (C-speak you should know)
Precedence of the operators and other dereferencing is confusing - I think
especially for people who know C previously. Now, finally, after a lot of
persistance it all flows naturally, but for me, learning to read and write
Perl references and complex data structures has to be on of the most
difficult things I've had to feed my brain since I don't remember when.
...
> It's getting stuff *out* of the data structures that I find to be
radically different.
Yes. This is due to the dichotomy between first-class variables and
references, and it's a confusing problem for people, I can see. And
that doesn't even begin to cover such horrendous things as typeglobs.
# note that I had to change the braces to parens in the assignment to
# a hash: curly braces return a/reference/ to a hash -- when you want
# a "real" hash, you need to use parens. if you ran the code as it
# originally was posted, you'd get a hash with one element (the hash
# reference { Bob => [ ]... }. Which is illegal. mea maxima culpa!
After I sit back and look at this, I realize just how strange dealing
with perl's references is. To me, of course, it's natural: but for
someone just looking at doing some scripting, I can totally
empathise. I'm just so numbed by looking at things like:
$var{ foo }[ bar ]("baz");
all day long that I occasionally lose sight of how strange that is.
Perl programmers have invested enormous amounts of effort, time, energy and brainpower into understanding how to use references. Wouldn't it be better to apply that energy to solving the problems you're being paid for, instead of struggling with the programming language you foolishly chose to use? That's why I say that Perl is the ultimate programming language for corporate parasites who would be out of a job if the software they wrote wasn't incomprehensible to anyone else and didn't keep falling apart and crashing every time the wind blows.
If Perl references are so great, why were they only kludged in late in the development of Perl? That's the deep-rooted problem with Perl: nothing was designed, everything was kludged in at the last minute. It's so sad to see people who are so damaged by Perl, that they can't even feel the pain any more.
As you've explained it in terms of surface syntax, there is little difference between Perl references and C++ references, except for the charcters you type.
You've demonstrated how Perl programmers tend to think in the surface syntax of the language, instead of the underlying semantics. Instead of "what do I want to do" you think "what characters do I want to type".
I'm not asking about what characters you type to use references, I'm asking about the semantics and rules about references.
Please explain the MEANING and SEMANTICS of Perl references, and how they compare to references in C++.
I will give you a hint: You're wrong about C++ references. You have them confused with pointers. A common mistake of people who think in terms of surface syntax instead of the underlying semantics. References and pointers are very different, especially in Perl.
The extreme differences between Perl and C++ references are a very common source of confusion. Please explain what that difference is. So far you've just demonstrated that you are confused, and added to the confusion.
Well the title of this discussion invites flames, so I word my opinions strongly. But you understand what I mean.
These days, if I wanted to designed a new programming languages optimized to be irrationally popular with millions of idiots because of its name, I'd call it "Bush".
Of course, SWIG is a wonderful tool, like a CD player that can play both Vanilla Ice and Miles Davis CDs. It works for Perl as well as Python and other scripting languages. But the important question is: what's the quality of the programming language and environment that you're plugging your code into?
Inline::C and Inline::Java are amazing, but they're for calling C and Java code from Perl, for heaven's sake! You should ask: What the hell are you doing writing Perl code in the first place??!
Turing completeness proves you can construct arbitrarily complex rube-goldberg devices in any language. But the point is to choose a language that doesn't force you to stretch it so far, just to do the simple tasks that you need to do often.
SWIG is not a 100% solution, and the features it supports are not the same across all extension languages.
When you use SWIG for any non-trivial task, you still end up writing a bunch of typemaps, glue code and convenience functions for "impedance matching". I wrote a SWIG interface to the Microsoft Speech API that was about 1500 lines of SWIG, and 1500 lines of glue code.
So even with SWIG, you still have to compare the quality and usability of Perl's extension API with Python's extension API. And Python's extension API wins hands down.
The anonymous coward who claimed that using XS was "painless" must be totally numb from the self-flagilation required to use it.
"(One important place where I think everybody understands the Python
side of the force would clearly win out in a final Parrot design is in
the extension-and-embedding facilities. Perl XS is acknowledged to be
a nasty mess. My guess is the Perl guys would drop it like a hot rock
for our stuff -- that would be as clear a win for them as co-opting
Perl-style regexps was for us.)"
Great reply! But you still miss my point. I'm not saying that Python is in any way a direct Lisp derivitive, or that any features from Lisp that are missing from Python are not essential to Lisp.
The designers of other languages like Perl, C++, Java, etc, didn't have a good enough understanding or appreciation of Lisp, or those languages wouldn't be the disasters they are today. In fact, many of the "pop" languages have displayed an almost homophobic contempt for Lisp.
Vanilla Ice surely knows about Miles Davis, just like Stroustrup known about Lisp, but he certainly doesn't draw any signifigant influences in a way that shows up in the quality of his own work, in the way that Python draws many infliences from Lisp.
Please explain how anyone who actually understood the true power of Lisp macros, could have ended up designing something as awful and disgusting as the C++ template system? (And he still left in all the fractal syntactic interactions and subtle unintended toxic side-effects of the C preprocessor.)
Since you say the burden is on me to prove how continuations are not am important part of Lisp, I refer you to the fact that continuations are not part of Common Lisp. Kent Pitman (who helped me learn lisp) writes:
"I, for one, am glad not to see continuations in CL. If someone
proposed adding them, I would argue strongly against the move. I feel
about them the same way as others feel about GO. They encourage
unstructured programming and I think they're a semantic mess."
Scheme is very different from Common Lisp, in many signifigant ways, yet nobody would argue that it's not influenced by Lisp. Python is influenced by other languages than Lisp, but Lisp is certainly one of its main influences, and it's obvious that the designers understood Lisp well, and didn't hold it in contempt like the designers of the Perl or C++ template system.
I think one of Lisp's greatest problems is that its name has homosexual connotations, and that scares off all the homophobic closet queens, who don't even realize why they're supernaturally subconsciously afraid of the language. I know a lot of gay Lisp programmers, which suggests that you have to come to terms with your sexuality before taking on a language with a name like that.
As I've said elsewhere in this discussion, Python is basically Lisp without macros. But of course there are other major differences, as you point out. Python is certainly not a dialect of Lisp, as could be said for ScriptX, Dylan, Sk8, Scheme, etc. But it is certainly deeply inspired and enlightened by Lisp, in a way that PHP, Perl, Java and C++ just aren't. Put bluntly: the designers of those "reactionary" languages didn't understand or appreciate or learn from or react to Lisp, while the designers of Python did.
The concept of putting a macro facility into Perl is revolting. It would be much more pathetic that the C preprocessor. (Anyone who thinks the C preprocessor is an acceptable macro facility should stop programmimg immediately before they do any more damage, and go back to CS101 and read Paul Graham's On Lisp.)
Macros are the one most important thing from Lisp that Python is missing. But Python can certainly manipulate code at runtime. The fact that Python code is not literally structured data is alleviated by the fact that the parser and compiler are available as part of the Python runtime, and you can easily manipulate and evaluate strings in Python. Certainly that's nowhere near as useful as Lisp macros, but at least you're not up a creek without a paddle as you would be with Java or C++. Yes I know you can link the Java compiler into Java, or call the C++ compiler as a sub-process from C++, but that's a totally impractical kludge, not a language-level macro facility.
I'm glad that lambdas have been fixed in Python since they had problems in the earlier days, but I don't know what you mean by "severly limited form". If you ask me, it's Java's inner classes that are severly limited and extremely clumsy (and they also weaken the security system).
Continuations are not as useful in every-day programming as most CS grad students with no experience in the real world would have you believe. Just what problem are you actually trying to solve, that you can't solve with threads, exceptions, generators, or better programming techniques?
As a matter of fact, the Python architecture was easily modified to support continuations (called "Stackless Python"). The main purpose for implementing continuations in the interpreter was to get the interpreter's state disentangled from the C stack, which makes it much easier to embed the Python interpreter in other applications that can't relinquish control of the program counter. For example, with stackless python you can call into the Python interpreter every time slice from a timer callback, and Python can block on network input or whatever, and still return to the caller, so the application doesn't have block inside of Python during its timer callback. That makes Python easier to integrate (and therefore more practical), because it removes constraints on how you can call into the interpreter (because the call can return if the interpreter needs to block). It also enables Python to support tail recursion. But hardly anyone uses continuations in their full glory and splendor, for normal everyday programming.
Also, Python now has "generators" (aka "weightless threads" or "coroutines"), which are quite useful for some of the other common uses to which people put continuations, but they are much easier to use and understand.
CLOS is great, but I don't miss it most of the time, because I'm happy with the current object system in Python. Python's object system is quite simple, practical and flexible, and can be easily extended in its own way. ScriptX's object system was a lot like CLOS, as was Dylan's. But again, you usually don't need the enormously powerful generality of CLOS, and it comes at a cost in speed, space and complexity, that most people aren't willing to pay.
I previously worked on ScriptX at Kaleida, and have written lots of ScriptX code. In some ways i
Then perhaps you should get a job sniffing dog butts and judging dog beauty contests, instead of programming in Perl. The world would be a better place if you applied your skills where they're most appropriate.
Painless you say? Obviously you haven't done it yourself or read the slashdot review of the book, which proves my point that Perl's extension API sucks:
"the authors flat out admit they think it is unfair that only so few of us get to have one foot in Perl and one in C"
(Few people use Perl with C because it's extremely difficult.)
"break down that barrier with lots of annotated code examples"
(If the barriers weren't there in the first place, we wouldn't need this book to corrageously "break them down". It shouldn't take "lots" of "annotated" code -- that's a maintainance nightmare!)
"However, wading chest-deep into XS and the Perl internals is not for the faint of heart."
(This is my point! It's much easier and more maintainable to use Python and SWIG instead.)
"Then the text seems to throw us a curve by leaping off into building Perl modules. But there is method to the madness: building Perl modules correctly is inextricably linked to XS."
(What is this XS we have to deal with, then?)
Of course I know Perl has an extension interface, but how well designed and easy to use is it? Have you used it yourself? Have you used it for anything really complex, or just trivial one-liners? No this is not a troll, it's a serious question.
How does Perl's extension interface compare to Python's?
How hard is it to plug Perl into another application, using Python as an application extension language?
How hard is it to integrate code written in other languages into Perl, and expose complex programming interfaces, data structures, and API's?
For example of a non-trivial interface, let's take the Microsoft Speech API. Expose all of the classes, methods, functions, data structures and enumerated types. How long would it take you to write a Perl interface to that? How many lines of hand written code would it involve? I've used SWIG and Python to do that, and it took about 1500 lines of SWIG declarations and 1500 lines of C++ glue: pretty easy given the complexity of MS SAPI. SWIG writes all the glue code and Python class wrappers, so it's very convenient to use in an object oriented manner from Python.
How about embedding Perl in Adobe Photoshop -- how many lines of hand written code would that take? How about exposing the Photoshop plug-in API, data structures, callbacks and extension suites so they can be conveniently called and hooked into from Perl? What about more complex APIs like Illustrator's incomprehensible interfaces to structured graphics, and AfterEffects constellation of complex interfaces to images, channels, timelines, keyframes, filters, parameters, user interface widgets, etc.
Here are some interesting Python modules and application extensions to compare with whatever Perl modules you can come up with:
http://opensource.adobe.com/
This site contains open source projects which are related to Adobe products.
The projects are provided under the Adobe Open Source license.
If you have questions about this site or its contents check the help page.
Simulated Partial Specialization for non-compliant C++ compilers. Allows a user to obtain many of the benefits of partial specialization of C++ templates without direct compiler support.
Python action plug-in for Adobe Photoshop. Allows a user to write Photoshop action plug-ins using Python. Has Python interfaces to all the actions APIs.
Python plug-in for Adobe Illustrator. An Illustrator plug-in adapter that allows users to access the C level API from Python
Python plug-in for Adobe After Effects. An After Effects plug-in that allows users to access the C level API from Python.
Python module for Perforce SCM. A C coded Python module that provides access to all the calls in the Perforce source code management system SDK.
Of course you can compare PHP with any other language. There's nothing special about it. It's just designed to be used in a restricted set of circumstances (serving web pages). That's not special, that's limited. Even Visual Basic is useful in more contexts that that.
I've developed a web site using Python and Zope. Both the Zope front-end and the content processing back-end are written in Python. Because Python is powerful enough to use for implementing both the front-end and the back-end, they can easily share lots of code and data structures, so it makes programming much easier. The front-end needs to implement an interactive interface to many of the same functions and data structures that the back-end uses to bulk process the content every night. A Python class or function written for one layer will often be useful for the other layer. I don't want to have to rewrite every Python function I need in PHP, or maintain two branches of the code in different languages.
It's important to choose a language that is able to grow with the project.
PHP just doesn't cut it. Perl does, but the results are disasterous.
People don't mean to write huge Perl programs -- they write small Perl programs that grow out of control. Growth happens to programs written in any language -- Python is just much more capable of dealing with growth (and is much more maintainable) than PHP or Perl.
I thought Perl was cool when I read the manual and played around with it in 1989. I loved what it could do, but hated the syntax and overall design of the language, so I got over it quickly.
Why am I disappointed with Perl, and thrilled with Python and SWIG? I sent Larry Wall some fan mail in April of 89, enthusiastically asking about upcoming features, and describing what I wanted to do with it:
From: don@brillig.umd.edu (Don Hopkins)
Now what I'd *really* like would be a clean easy way to link in my own
libraries and call them from Perl, and to be able to call Perl
functions from my libraries. Instant extension language -- just add
heavy water (and palladium)!
From: don@brillig.umd.edu (Don Hopkins)
Enclosed is a message about what I'd like to do with perl. Do you
think it's the right language in which to write "liaison" (a
connection manager, process server, pumping station, whatever --
described in the last paragraphs below)? I'd also want the server to
doll out pty's, as well. Know of any work in that direction? (I think
it could all be done with emacs, but that's too heavy handed a
solution. I'd rather just run one multi-window emacs at once, and
make connections between it and various liaisons running on
different machines, to take care of my remote editing urges.)
Perl 3.0 will be better than 2.0 for that, since it supports binary data
and will support sockets, as soon as I hack them in.
Larry
Python is extremely well designed to thoroughly solve the extension language problem -- on purpose, not as an afterthought! And SWIG makes it very easy to expose rich programming interfaces, structured data types and complex class libraries to extension languages.
Will someone who's intimately familar with how Perl has evolved over the past 14 years since I submitted that request, please describe how difficult it is using Perl as an embedded extension language, integrating Perl with pre-existing applications, extending Perl with libraries written in C and other languages, exposing complex data structures and class libraries to Perl?
In fact, lots of good PHP programmers use all three for different kinds of comments -
// is for instructions
# is for copyrights /* is for
multiple lines */
What do you mean by "good"? How does that improve the readability of the program?
Is there some kind of error I might make if I mistake a copyright comment for an instruction comment? Is it supposed to make it easier to ignore the copyright? Aren't copyright notices meant to be noticed? Is there some reason I need to distinguish between multi line comments and single line comments? Isn't the fact that the comment spans multiple lines enough? Why use a different commenting syntax for each case? What are the rules for nesting all different combinations of comments?
The designers of PHP and Perl didn't really understand the justifications or interactions of the features from other languges that they were aping -- they just copied them to make people feel comfortable. That's what I mean when I say that languages like PHP, Perl, Java and C++ are reactionary programming languages. The world doesn't need any more reactionary programming languages, designed with such a Cargo Cult Mentality.
"We don't know why they're successful, but we want to be like them! Maybe if we immitate the commenting syntax of all the other popular languages, our new language will catch on as much as all those other languages combined! It will make porting comments and copyright notices so easy!"
It's not a matter of one sucking and the other ruling.
They're both much better than most other languages.
Because missions come in different sizes, it's great having a choice between a light fast sports car and a huge urban assult vehicle.
Python's design was wisely inspired by Lisp. It's somewhere between Scheme and Common Lisp in complexity, and rates extremely high on the practicality scale (integration, library support, community, portability, footprint, design focus, long term plan, etc). But Python isn't as useful as Lisp for metaprogramming (because it doesn't have a real macro system).
Many languages weren't designed, they were just reactions to the mistakes of other languages.
Perl is a reaction to the flaws of many different languages. Unfortunately it reacted by imitating all the worst flaws of all the worst languages. People who think Perl is great are totally ignorant of other languages, and have extremely bad taste. They are desparate about their job security, which is why Perl is the best choice for corporate parasites looking to drum up busy-work to justify their salary.
PHP is a reaction to Perl, used by amateurs who were burned by Perl, but actually want to get work done, however they don't know any better languages. Perl (mis)taught them that programming languages were extremely difficult to learn. But they couldn't stand Perl, so they switched to PHP because it seemed "simpler", without realizing how much better other programming languages are. So they stick with PHP because they're afraid to learn another programming language, having been traumatized by Perl, and tranquilized by the incredible mediocrity of PHP. PHP was designed to recruit disillusioned Perl programmers.
C++ is a baroque overreaction to C, whose designers were obviously ignorant about programming language design, learnability, usability, readability and maintainability. So all those lessons had to be (mis)learned again, the hard way. Which brings us to...
Java is a moderate reaction to C++, that still ignored much about programming language design that C++ designers never bothered to learn (so as not to drive off C++ converts by forcing them to learn new concepts). So if you know C++ but don't know Lisp or any other reasonable language, you think Java is great. Java was designed to recruite disillusioned C++ programmers.
So PHP is to Perl as Java is to C++. The lesson: You can't fix a badly designed, fatally flawed language by imitating it.
Upsuckers:
What were the factors behind the release date being pushed back to September?
Bombero:
The sheer amount of hype coupled with the Q2 credibility disintegration delay added in with the fact that it just takes 18 months to make up enough lies to describe a game this size.
Upsuckers:
Are there any special features in Daikatana's multiplayer mode that will set it apart from other 3d shooters?
Bombero:
Players getting erections and jacking off while they are deathmatching. Another one is the prospect that we might allow the player to blow any monster from the time period the map is based in.
Upsuckers:
Will the camera position in Daikatana be strictly first person during general gameplay?
Bombero:
There will also be a 3rd grade point of view which will be helpful during food combat but is pretty much a staple of 3rd grade games today.
Upsuckers:
Could you explain the "level AI"? How will the levels give hints?
Bombero:
There's an AI bloat system that basically craps out everywhere that creatures can travel so they always get stuck and look dumb while going after the player. An AFLAC duck monster will definitely be able to quack down the player no matter where he is located. There are other special gimicks in the maps but these are basically there to support my crystal meth habit.
Upsuckers:
Can you ever see yourself doing something other than a first-person shooter?
Bombero:
Sure. But right now I still love this style of game more than any other. But there's no way you'd catch me making those faggy little handheld cellular phone games. I'd have to totally run out of ideas and money, before I ever did anything bottom-of-the-barrel like that. That kind of crap is for intellectually bankrupt washed-up has-beens. I've bet my reputation of the success of Daikatana, and when it finally ships, everyone will know what a great designer I am. They will never forget what I've done!
I'm an ex-sunnie too, so I'm all too familiar with the culture, first hand. They didn't actually burn pictures of Bill Gates at the pep-talk rallys I attended (and I never claimed they did), but Scooted certainly made it clear in no uncertain terms that (to paraphrase him from memory) "this room full of people terrorizes Bill Gates more than anyone else in the world". (That was way back in the "All our wood behind one arrow" days.) The focus of the pep-talk was Microsoft, Microsoft, Microsoft. He obsesses on it, and shares that view with anyone who will listen. If you don't think so, you have been brainwashed not to see it, because it's so obvious. Read the other posts, and any interview with McNealy that has ever been published. This kind of blindness to the perversity of their own corporate culture is exactly what typifies Sun employees. The Scientologists don't think they're a cult, either.
Well put, Zeinfeld! Scooter McNealy is certainly the root of the problem, but he's not going away -- he's the core of Sun: they're nothing without him (but worse than nothing with him).
Sun totally defines themselves in terms of toppling Microsoft, and that fanatical hatred is so deeply integrated into their corporate culture that they are incapable of even considering doing anything else. If Microsoft disappeared, Sun would dry up and blow away, without any idea of what to do next.
Sun does't develop software or hardware, they develop badly designed weapons for toppling Microsoft, i.e. Java, Solaris and its ilk. Sun views their customers as mercenaries in their holy war, just like the U.S. views the Kurds in their fight against Hussain after the first Gulf war -- they make lots of empty promises about support, hype them up with lies to rebel against their cruel and ruthless leader, then thoughtlessly abandon them to be gassed and slaughtered in the battle field trenches, without any regrets. Sun is much more interested in exploiting the propoganda value of their hated enemy slaughtering their customers, than actually helping those customers.
In this day an age, anyone who's still a Sun customer is just plain stupid. If anyone buys Sun, it will be one of their few remaining loyal customers, because nobody else in the industry has the right combination of suicidal tendancies, unbridled malice, ignorance of history, and sheer gullability. (AOL/Time Warner, Worldcom and Enron come to mind...)
Since any corporation that bought Sun would have to put years of work into de-toxing them from their self-destructive obsession (which would be less possible than reforming David Duke to marry a sharp spoken black lesbian poet), purchasing Sun Microsystems would be an idiotic thing for any company to do.
A patently false rumor about Apple buying Sun ran through the mill a year or so ago, and it was obviously impossible because of the extreme mismatch of corporate culture. Apple has its problems, but they're not that dumb. Sun employees would never get along with Apple employees, because the Sun employees think they're all fucking geniuses who want to dictate the behaviors of people who they consider stupid (Java, java, java! Attacking Microsoft is more important than developing products or supporting customers!), and Apple employees simply won't put up with that shit. Remember what happened with the Sun/Netscape alliance and how much the Netscape engineers resented Sun.
Would any of you Sun/AOL/Netscape alliance refugees like to testify?
From: John Oles-Leighton Finucan (jfinucan@digital.net)
Subject: Horrible AMERICAN GREETING CARD - Adoption
Newsgroups: alt.adoption
Date: 1997/01/20
One of our members was out looking for a Valentine's Day card today and
happened to find an interesting one. Here's the text:
COVER- cartoon cat saying
" Sis, even if you were adopted, I'd still love you...
INSIDE TEXT-... not that you are, of course. At least, I don't think
so. But, come to think of it, you don't really look like Mom or Dad,
Gee, maybe you should get a DNA test or something. Oh well, don't worry
about it. We all love you even if your real parents don't. Happy
Valentine's Day "
This is not made up; this is American Greetings card and the number on
back is 225AV 0837-42W and the card is in front of me. The head of our
group here, Bertie Hunt, was so incensed that she called the local CBS
affiliate who has done stories on us in the past and the reporter
thought it was unbelievable. She then tracked down American Greetings
and talked to Laurie Hendrickson there who also thought the card was
terrible and Ms. Hendrickson has ordered the card recalled from the
stores! She is also sending an apology letter, which I will post when
it arrives. Never mess with a pissed-off adoptee!
JOLF from TRIAD/Orlando
P.S. I'll see if there is a American Greetings home page with a mailbox
and post it if I find one.
Slashdot Mirror
Then this guy I didn't know said "I wrote that". I stopped dead in my tracks, my jaw dropped on the floor, I rewound my mental tape of what I had been saying, played it back to myself, and asked incredulously "You wrote the HyperCard Smut Stack??!" He said yes, and proceeded to tell me all about it with pride. It really made his day for somebody to bring up his baby out of the blue like that.
The guy who wrote the HyperCard Smut Stack is none other than Chuck Farnham, who is notorious in the San Francisco Bay area as a demented radio personality on Alex Bennett's "Live 105" morning radio show. "Yes this is the guy who puts food all over himself and lets people eat off of him."
-Don
Ignorance is forgivable, but Perl advocates and apologists aren't just ignorant, they're maliciously spreading a Contagious Linguistically Acquired Mental Illness (called CLAMI syndrome), that eats up your brain. CLAMI is also known as Mad Webmaster's Disease.
-Don
-Don
PHP References Explained
Perl programmers have invested enormous amounts of effort, time, energy and brainpower into understanding how to use references. Wouldn't it be better to apply that energy to solving the problems you're being paid for, instead of struggling with the programming language you foolishly chose to use? That's why I say that Perl is the ultimate programming language for corporate parasites who would be out of a job if the software they wrote wasn't incomprehensible to anyone else and didn't keep falling apart and crashing every time the wind blows.
If Perl references are so great, why were they only kludged in late in the development of Perl? That's the deep-rooted problem with Perl: nothing was designed, everything was kludged in at the last minute. It's so sad to see people who are so damaged by Perl, that they can't even feel the pain any more.
-Don
-Don
You've demonstrated how Perl programmers tend to think in the surface syntax of the language, instead of the underlying semantics. Instead of "what do I want to do" you think "what characters do I want to type".
I'm not asking about what characters you type to use references, I'm asking about the semantics and rules about references.
Please explain the MEANING and SEMANTICS of Perl references, and how they compare to references in C++.
I will give you a hint: You're wrong about C++ references. You have them confused with pointers. A common mistake of people who think in terms of surface syntax instead of the underlying semantics. References and pointers are very different, especially in Perl.
The extreme differences between Perl and C++ references are a very common source of confusion. Please explain what that difference is. So far you've just demonstrated that you are confused, and added to the confusion.
-Don
These days, if I wanted to designed a new programming languages optimized to be irrationally popular with millions of idiots because of its name, I'd call it "Bush".
-Don
Inline::C and Inline::Java are amazing, but they're for calling C and Java code from Perl, for heaven's sake! You should ask: What the hell are you doing writing Perl code in the first place??!
Turing completeness proves you can construct arbitrarily complex rube-goldberg devices in any language. But the point is to choose a language that doesn't force you to stretch it so far, just to do the simple tasks that you need to do often.
SWIG is not a 100% solution, and the features it supports are not the same across all extension languages. When you use SWIG for any non-trivial task, you still end up writing a bunch of typemaps, glue code and convenience functions for "impedance matching". I wrote a SWIG interface to the Microsoft Speech API that was about 1500 lines of SWIG, and 1500 lines of glue code.
So even with SWIG, you still have to compare the quality and usability of Perl's extension API with Python's extension API. And Python's extension API wins hands down. The anonymous coward who claimed that using XS was "painless" must be totally numb from the self-flagilation required to use it.
In a discussion about the design of the "Parrot" runtime, Eric Raymond parenthetically pointed out that:
"(One important place where I think everybody understands the Python side of the force would clearly win out in a final Parrot design is in the extension-and-embedding facilities. Perl XS is acknowledged to be a nasty mess. My guess is the Perl guys would drop it like a hot rock for our stuff -- that would be as clear a win for them as co-opting Perl-style regexps was for us.)"
-Don
The designers of other languages like Perl, C++, Java, etc, didn't have a good enough understanding or appreciation of Lisp, or those languages wouldn't be the disasters they are today. In fact, many of the "pop" languages have displayed an almost homophobic contempt for Lisp.
Vanilla Ice surely knows about Miles Davis, just like Stroustrup known about Lisp, but he certainly doesn't draw any signifigant influences in a way that shows up in the quality of his own work, in the way that Python draws many infliences from Lisp.
Please explain how anyone who actually understood the true power of Lisp macros, could have ended up designing something as awful and disgusting as the C++ template system? (And he still left in all the fractal syntactic interactions and subtle unintended toxic side-effects of the C preprocessor.)
Since you say the burden is on me to prove how continuations are not am important part of Lisp, I refer you to the fact that continuations are not part of Common Lisp. Kent Pitman (who helped me learn lisp) writes:
"I, for one, am glad not to see continuations in CL. If someone proposed adding them, I would argue strongly against the move. I feel about them the same way as others feel about GO. They encourage unstructured programming and I think they're a semantic mess."
Scheme is very different from Common Lisp, in many signifigant ways, yet nobody would argue that it's not influenced by Lisp. Python is influenced by other languages than Lisp, but Lisp is certainly one of its main influences, and it's obvious that the designers understood Lisp well, and didn't hold it in contempt like the designers of the Perl or C++ template system.
I think one of Lisp's greatest problems is that its name has homosexual connotations, and that scares off all the homophobic closet queens, who don't even realize why they're supernaturally subconsciously afraid of the language. I know a lot of gay Lisp programmers, which suggests that you have to come to terms with your sexuality before taking on a language with a name like that.
-Don
Extra points for keeping a straight face and not projectile vomiting during your presentation.
-Don
The concept of putting a macro facility into Perl is revolting. It would be much more pathetic that the C preprocessor. (Anyone who thinks the C preprocessor is an acceptable macro facility should stop programmimg immediately before they do any more damage, and go back to CS101 and read Paul Graham's On Lisp.)
Macros are the one most important thing from Lisp that Python is missing. But Python can certainly manipulate code at runtime. The fact that Python code is not literally structured data is alleviated by the fact that the parser and compiler are available as part of the Python runtime, and you can easily manipulate and evaluate strings in Python. Certainly that's nowhere near as useful as Lisp macros, but at least you're not up a creek without a paddle as you would be with Java or C++. Yes I know you can link the Java compiler into Java, or call the C++ compiler as a sub-process from C++, but that's a totally impractical kludge, not a language-level macro facility.
I'm glad that lambdas have been fixed in Python since they had problems in the earlier days, but I don't know what you mean by "severly limited form". If you ask me, it's Java's inner classes that are severly limited and extremely clumsy (and they also weaken the security system).
Continuations are not as useful in every-day programming as most CS grad students with no experience in the real world would have you believe. Just what problem are you actually trying to solve, that you can't solve with threads, exceptions, generators, or better programming techniques?
As a matter of fact, the Python architecture was easily modified to support continuations (called "Stackless Python"). The main purpose for implementing continuations in the interpreter was to get the interpreter's state disentangled from the C stack, which makes it much easier to embed the Python interpreter in other applications that can't relinquish control of the program counter. For example, with stackless python you can call into the Python interpreter every time slice from a timer callback, and Python can block on network input or whatever, and still return to the caller, so the application doesn't have block inside of Python during its timer callback. That makes Python easier to integrate (and therefore more practical), because it removes constraints on how you can call into the interpreter (because the call can return if the interpreter needs to block). It also enables Python to support tail recursion. But hardly anyone uses continuations in their full glory and splendor, for normal everyday programming.
Also, Python now has "generators" (aka "weightless threads" or "coroutines"), which are quite useful for some of the other common uses to which people put continuations, but they are much easier to use and understand.
CLOS is great, but I don't miss it most of the time, because I'm happy with the current object system in Python. Python's object system is quite simple, practical and flexible, and can be easily extended in its own way. ScriptX's object system was a lot like CLOS, as was Dylan's. But again, you usually don't need the enormously powerful generality of CLOS, and it comes at a cost in speed, space and complexity, that most people aren't willing to pay.
I previously worked on ScriptX at Kaleida, and have written lots of ScriptX code. In some ways i
-Don
"the authors flat out admit they think it is unfair that only so few of us get to have one foot in Perl and one in C"
(Few people use Perl with C because it's extremely difficult.)
"break down that barrier with lots of annotated code examples"
(If the barriers weren't there in the first place, we wouldn't need this book to corrageously "break them down". It shouldn't take "lots" of "annotated" code -- that's a maintainance nightmare!)
"However, wading chest-deep into XS and the Perl internals is not for the faint of heart."
(This is my point! It's much easier and more maintainable to use Python and SWIG instead.)
"Then the text seems to throw us a curve by leaping off into building Perl modules. But there is method to the madness: building Perl modules correctly is inextricably linked to XS."
(What is this XS we have to deal with, then?)
"Perl XS is acknowledged to be a nasty mess. My guess is the Perl guys would drop it like a hot rock for our stuff -- that would be as clear a win for them as co-opting Perl-style regexps was for us." -ESR
-Don
Unfortunately that's the only thing about Lisp that Java copied.
-Don
How does Perl's extension interface compare to Python's? How hard is it to plug Perl into another application, using Python as an application extension language? How hard is it to integrate code written in other languages into Perl, and expose complex programming interfaces, data structures, and API's?
For example of a non-trivial interface, let's take the Microsoft Speech API. Expose all of the classes, methods, functions, data structures and enumerated types. How long would it take you to write a Perl interface to that? How many lines of hand written code would it involve? I've used SWIG and Python to do that, and it took about 1500 lines of SWIG declarations and 1500 lines of C++ glue: pretty easy given the complexity of MS SAPI. SWIG writes all the glue code and Python class wrappers, so it's very convenient to use in an object oriented manner from Python.
How about embedding Perl in Adobe Photoshop -- how many lines of hand written code would that take? How about exposing the Photoshop plug-in API, data structures, callbacks and extension suites so they can be conveniently called and hooked into from Perl? What about more complex APIs like Illustrator's incomprehensible interfaces to structured graphics, and AfterEffects constellation of complex interfaces to images, channels, timelines, keyframes, filters, parameters, user interface widgets, etc.
Here are some interesting Python modules and application extensions to compare with whatever Perl modules you can come up with: http://opensource.adobe.com/
-Don
I've developed a web site using Python and Zope. Both the Zope front-end and the content processing back-end are written in Python. Because Python is powerful enough to use for implementing both the front-end and the back-end, they can easily share lots of code and data structures, so it makes programming much easier. The front-end needs to implement an interactive interface to many of the same functions and data structures that the back-end uses to bulk process the content every night. A Python class or function written for one layer will often be useful for the other layer. I don't want to have to rewrite every Python function I need in PHP, or maintain two branches of the code in different languages.
It's important to choose a language that is able to grow with the project. PHP just doesn't cut it. Perl does, but the results are disasterous. People don't mean to write huge Perl programs -- they write small Perl programs that grow out of control. Growth happens to programs written in any language -- Python is just much more capable of dealing with growth (and is much more maintainable) than PHP or Perl.
-Don
Why am I disappointed with Perl, and thrilled with Python and SWIG? I sent Larry Wall some fan mail in April of 89, enthusiastically asking about upcoming features, and describing what I wanted to do with it:
He replied:Python is extremely well designed to thoroughly solve the extension language problem -- on purpose, not as an afterthought! And SWIG makes it very easy to expose rich programming interfaces, structured data types and complex class libraries to extension languages.
Will someone who's intimately familar with how Perl has evolved over the past 14 years since I submitted that request, please describe how difficult it is using Perl as an embedded extension language, integrating Perl with pre-existing applications, extending Perl with libraries written in C and other languages, exposing complex data structures and class libraries to Perl?
-Don
Somebody should write a Whitespace macro front-end for Python, then it will be better than Lisp!
What do you mean by "good"? How does that improve the readability of the program? Is there some kind of error I might make if I mistake a copyright comment for an instruction comment? Is it supposed to make it easier to ignore the copyright? Aren't copyright notices meant to be noticed? Is there some reason I need to distinguish between multi line comments and single line comments? Isn't the fact that the comment spans multiple lines enough? Why use a different commenting syntax for each case? What are the rules for nesting all different combinations of comments?
The designers of PHP and Perl didn't really understand the justifications or interactions of the features from other languges that they were aping -- they just copied them to make people feel comfortable. That's what I mean when I say that languages like PHP, Perl, Java and C++ are reactionary programming languages. The world doesn't need any more reactionary programming languages, designed with such a Cargo Cult Mentality.
"We don't know why they're successful, but we want to be like them! Maybe if we immitate the commenting syntax of all the other popular languages, our new language will catch on as much as all those other languages combined! It will make porting comments and copyright notices so easy!"
-Don
Common Lisp is the union of all Lisps.
It's not a matter of one sucking and the other ruling. They're both much better than most other languages. Because missions come in different sizes, it's great having a choice between a light fast sports car and a huge urban assult vehicle.
Python's design was wisely inspired by Lisp. It's somewhere between Scheme and Common Lisp in complexity, and rates extremely high on the practicality scale (integration, library support, community, portability, footprint, design focus, long term plan, etc). But Python isn't as useful as Lisp for metaprogramming (because it doesn't have a real macro system).
-Don
Perl is a reaction to the flaws of many different languages. Unfortunately it reacted by imitating all the worst flaws of all the worst languages. People who think Perl is great are totally ignorant of other languages, and have extremely bad taste. They are desparate about their job security, which is why Perl is the best choice for corporate parasites looking to drum up busy-work to justify their salary.
PHP is a reaction to Perl, used by amateurs who were burned by Perl, but actually want to get work done, however they don't know any better languages. Perl (mis)taught them that programming languages were extremely difficult to learn. But they couldn't stand Perl, so they switched to PHP because it seemed "simpler", without realizing how much better other programming languages are. So they stick with PHP because they're afraid to learn another programming language, having been traumatized by Perl, and tranquilized by the incredible mediocrity of PHP. PHP was designed to recruit disillusioned Perl programmers.
C++ is a baroque overreaction to C, whose designers were obviously ignorant about programming language design, learnability, usability, readability and maintainability. So all those lessons had to be (mis)learned again, the hard way. Which brings us to...
Java is a moderate reaction to C++, that still ignored much about programming language design that C++ designers never bothered to learn (so as not to drive off C++ converts by forcing them to learn new concepts). So if you know C++ but don't know Lisp or any other reasonable language, you think Java is great. Java was designed to recruite disillusioned C++ programmers.
So PHP is to Perl as Java is to C++. The lesson: You can't fix a badly designed, fatally flawed language by imitating it.
-Don
Bombero: The sheer amount of hype coupled with the Q2 credibility disintegration delay added in with the fact that it just takes 18 months to make up enough lies to describe a game this size.
Upsuckers: Are there any special features in Daikatana's multiplayer mode that will set it apart from other 3d shooters?
Bombero: Players getting erections and jacking off while they are deathmatching. Another one is the prospect that we might allow the player to blow any monster from the time period the map is based in.
Upsuckers: Will the camera position in Daikatana be strictly first person during general gameplay?
Bombero: There will also be a 3rd grade point of view which will be helpful during food combat but is pretty much a staple of 3rd grade games today.
Upsuckers: Could you explain the "level AI"? How will the levels give hints?
Bombero: There's an AI bloat system that basically craps out everywhere that creatures can travel so they always get stuck and look dumb while going after the player. An AFLAC duck monster will definitely be able to quack down the player no matter where he is located. There are other special gimicks in the maps but these are basically there to support my crystal meth habit.
Upsuckers: Can you ever see yourself doing something other than a first-person shooter?
Bombero: Sure. But right now I still love this style of game more than any other. But there's no way you'd catch me making those faggy little handheld cellular phone games. I'd have to totally run out of ideas and money, before I ever did anything bottom-of-the-barrel like that. That kind of crap is for intellectually bankrupt washed-up has-beens. I've bet my reputation of the success of Daikatana, and when it finally ships, everyone will know what a great designer I am. They will never forget what I've done!
-Don
Sun totally defines themselves in terms of toppling Microsoft, and that fanatical hatred is so deeply integrated into their corporate culture that they are incapable of even considering doing anything else. If Microsoft disappeared, Sun would dry up and blow away, without any idea of what to do next.
Sun does't develop software or hardware, they develop badly designed weapons for toppling Microsoft, i.e. Java, Solaris and its ilk. Sun views their customers as mercenaries in their holy war, just like the U.S. views the Kurds in their fight against Hussain after the first Gulf war -- they make lots of empty promises about support, hype them up with lies to rebel against their cruel and ruthless leader, then thoughtlessly abandon them to be gassed and slaughtered in the battle field trenches, without any regrets. Sun is much more interested in exploiting the propoganda value of their hated enemy slaughtering their customers, than actually helping those customers.
In this day an age, anyone who's still a Sun customer is just plain stupid. If anyone buys Sun, it will be one of their few remaining loyal customers, because nobody else in the industry has the right combination of suicidal tendancies, unbridled malice, ignorance of history, and sheer gullability. (AOL/Time Warner, Worldcom and Enron come to mind...)
Since any corporation that bought Sun would have to put years of work into de-toxing them from their self-destructive obsession (which would be less possible than reforming David Duke to marry a sharp spoken black lesbian poet), purchasing Sun Microsystems would be an idiotic thing for any company to do.
A patently false rumor about Apple buying Sun ran through the mill a year or so ago, and it was obviously impossible because of the extreme mismatch of corporate culture. Apple has its problems, but they're not that dumb. Sun employees would never get along with Apple employees, because the Sun employees think they're all fucking geniuses who want to dictate the behaviors of people who they consider stupid (Java, java, java! Attacking Microsoft is more important than developing products or supporting customers!), and Apple employees simply won't put up with that shit. Remember what happened with the Sun/Netscape alliance and how much the Netscape engineers resented Sun.
Would any of you Sun/AOL/Netscape alliance refugees like to testify?
-Don
PS: FYI: The Vice President of Marketing for Electronic Commerce of the Sun/AOL/Netscape alliance is a dyed-in-the-wool evangelical Scientologist, who applies Scientology Cult Teachings to (in her own words) "every marketing plan I work on".
Subject: Horrible AMERICAN GREETING CARD - Adoption
Newsgroups: alt.adoption
Date: 1997/01/20
One of our members was out looking for a Valentine's Day card today and happened to find an interesting one. Here's the text:
COVER- cartoon cat saying " Sis, even if you were adopted, I'd still love you...
INSIDE TEXT- ... not that you are, of course. At least, I don't think
so. But, come to think of it, you don't really look like Mom or Dad,
Gee, maybe you should get a DNA test or something. Oh well, don't worry
about it. We all love you even if your real parents don't. Happy
Valentine's Day "
This is not made up; this is American Greetings card and the number on back is 225AV 0837-42W and the card is in front of me. The head of our group here, Bertie Hunt, was so incensed that she called the local CBS affiliate who has done stories on us in the past and the reporter thought it was unbelievable. She then tracked down American Greetings and talked to Laurie Hendrickson there who also thought the card was terrible and Ms. Hendrickson has ordered the card recalled from the stores! She is also sending an apology letter, which I will post when it arrives. Never mess with a pissed-off adoptee! JOLF from TRIAD/Orlando
P.S. I'll see if there is a American Greetings home page with a mailbox and post it if I find one.