[asciilifeform]

> This doesn't seem to be anything special about Hypercard.

Tell that to the thousands of otherwise non-programming people who developed real, useful applications (some of them best-selling) in Hypercard.

> it's going to be something else over the JS/CSS/HTML stack

Like building a castle on a swamp. Foundations matter: http://www.loper-os.org/?p=55

[neilk]

I agree. The web stack is a castle on a swamp, except that swamp is itself built above a hyperspace junction linking everything in the world together.

The web surpassed HyperCard from day one, simply by locating its resources on the network. And that's why people put up with it, even if we have to dive into a fetid quagmire every time we use it.

HyperCard versus the web is a classic example of Worse is Better.

[roel_v]

Is it not programming because the syntax is verbose? I don't know anything about hypercard, but from the example in the OP it just looks like a limited and clunky IDE with a toy programming language. Just enough to build things that are just about good enough for people with limited goals, but then again there are thousands of products like that out there.

The whole paranoid 'everybody conspires against it because it's so great' is bullshit. If it's so great, why hasn't anyone make a clone and got rich of it? It's quite obvious why: because everybody who uses it runs into its limitations very quickly, so clones add extensions, and after a few iterations it becomes too difficult for beginners. And then the next clone stands up, lather rinse repeat.

[joe_the_user]

That rant is was quite nice... had me going for a minute.

But I'm sure it is one of many in a line of "reasons the software crisis didn't have to happen" - riiight. The "mythical man month"? It's 'cause they didn't do it right in 1960/1970/1980/1990/2001/... If only "they" would learn...

[asciilifeform]

So doing "it" right is a physical impossibility, then? Care to say why?

[jodrellblank]

Because 'right' is in the eye of the beholder? It's subjective.

[loup-vaillant]

We agree much more on what's "right" than you suggest.

Take two systems which do the same things. One does it as expected, the other surprises you in subtle ways. One does it as specified, the other sometimes does not. One does it quickly, the other makes you wait a bit. One fits in a few pages of code, the other takes a whole book.

I agree that you can't tell what's right in advance. But it's not a matter of preference, it's a matter of ignorance. In hindsight, when you see the results, you can most of the time point out what could have produced better results, if only you knew. You can even go meta, wondering why you didn't knew, then try and change that in the future.

[joe_the_user]

I upvoted you because I think this is a conversation that should be as civil as possible. My original tone was probably a bit too sarcastic.

On the subject of "doing it right" - every software engineer or maybe most passionate software engineers, have an ability to look at a spec or a piece of code and see how it is "done right". I certainly have my conception, my agenda, of what the right way to code and good software engineering is.

The thing is that this comes after fifty years of efforts to "do it right" failing in the sense that we don't have a single language we're satisfied with, we don't have a single operating system people unambiguously call good etc. The edifice of modern computing seems to lack a sound foundation.

The grizzled software engineer often knows this as a fact without caring about why and indeed the why is obscure.

Oddly enough, I think can illustrate my explanation for "why" by noting the common complain that programmers are "constantly reinventing the wheel". Now, if we look at the automotive engineers who build cars, we will note they too are "constantly reinventing the wheel" (literally now). Yet no one complains that the automotive engineer must create a new wheel for a new car with different mechanical properties than the old car which had the old wheel. Here we can see problem and the solution ("reinventing the wheel") does not seem intuitively to we-humans as a problematic state of affairs.

Looked at this way, initial criticism of a software engineer "reinventing the wheel" is a bit ridiculous. It seem logic that an engineer needs to change the components whenever they are putting together a different system for a different purpose. Moreover, the variety of distinct circumstances a software system needs to be engineered for is vast - it faces far more meaningful-context-changes than a car. In this perspective, it is absurd to expect the

Yet, this intuitively, with our human intuition, just doesn't seem right. I would claim that the intuition we have involve a natural conflating of something like "the idea of a wheel" with "the software implement of a wheel". A software implementation of a wheel or anything is more nebulous than a physical wheel but it is still not "the idea of a wheel". But as we "naturally" conflate these two item is easy for us to believe that we only need to think up the concept of an entity and we will have captured the thing. And this natural conflation of the ideas is perhaps where things go wrong... Where we get off expecting "general purpose operating system" to satisfy the gazillion purposes assigned to it, etc.

[ezy]

You're completely missing my point. I'm actually sort of agreeing with you -- but I'm also saying you don't really need (want?) to duplicate Hypercard.

Let's just say that considerably more than "thousands" have written BASIC programs that were real useful applications in their day. I would not argue that people have not done the same in Hypercard.

There's nothing special about hypercard. What's special is having an easy-to-use beginner programming environment that you could create fairly good small programs in -- in comparison to the commercial offerings of the day. BASIC was that, Hypercard was that, but that only partially exists today as the web stack because of it's baroque nature.

"Foundations matter" is really a tautology. I don't think the problem is the foundations. We build on sand all the time. Certainly without a foundation, you're fucked, but you place too much importance on it. Saying something like "Foundations matter" is pretending to be profound without substance. I might just as well say that "Input devices matter" -- and they do -- but how much do they matter? Is everything fucked because we all use mice & keyboards?

[asciilifeform]

> "Foundations matter" is pretending to be profound without substance

Please take the time to read my article. The kind of pieces you get when something breaks or needs reworking does matter.

> Is everything fucked because we all use mice & keyboards?

I do not myself believe this, but there are those who do, and their arguments are worth paying attention to.

[ezy]

Yes, I read your article. I think I understand where you're coming from, but it's completely circular. All you need to do is create another mostly impermeable strata. People do this all the time, and it has been wildly successful so far.

In that sense, original foundations don't matter. But, of course, they do, 'cause you had to build a new strata, right? Round and round...

And, in the passing of time, you can simply replace the underlying foundations with something more unified. This, again, happens all the time. CPUs gain SIMD instructions and new addressing modes, VM support, etc. I fully expect, while nothing like DESCRIPTOR, more hardware support for higher level GC to come if its worth is proven.

The input device remark was probably a poor analogy, but it is somewhat similar. "Input devices matter". Well, duh, yeah. But it certainly is not a good summary of an argument to replace the mouse and keyboard with an generalized gesture recognition device. :-) The mouse was an addition to the keyboard, not a reconstruction of it. If we find that, say, speech is better at some things, we don't propose to take away everything else. We build on top, because, while it may offend the sensibilities of some -- you can fix the warts later.

You're right to say that we're all working on huge 8bit micros to an extent -- but beyond the historical implications, it's circular to think that really matters. It's why Alan Kay now sounds like a grumpy old man, as Raskin does, as most people who moan about lisp machines and the DESCRIPTOR architecture. Today, I can run emulations of these things far, far faster than the originals and the software on my box is far more capable than the software people were using then. The real world favors cutting away/polishing a turd into a smooth stone, not piling up someone's perfect diamonds -- because restarting from scratch every time you discover something new is wasted work.

[ebbv]

You are lauding HyperCard and calling JS/CSS/HTML a swamp? Seriously?

JS/CSS/HTML all have flaws -- some more vexing than others -- but they (and the browsers that put them to use) are infinitely superior to HyperCard.