Score code on line count and runtime golf. Shorter, faster, and fastest time to completion is best.
Code that’s 4K and took slightly less time to write but runs slightly faster than code that’s 400 bytes that took another 30m to write still doesn’t get the best score.
I kind think metrics are not the answer and instead one needs taste. Obviously performance is multidimensional both in what one measures (latency vs throughput) and as a function of the input. The solution you imagine that is slightly faster in the test could avoid (or introduce) different worst-case or asymptotic behaviour, for example.
I argue we shouldn’t be doing this at all; but, if we have to do to whatever insanely arbitrary metric a project/product/eng leader wants, this is probably a better metric than code length.
Atkinson is a legendary UX pioneer. Great technical skill and a deep understanding of the principles of interaction. His work, from the double click to HyperCard, continues to inspire my own work. You will be missed.
Some of his old demos of graphics capabilities on the Mac or hypercard are around on YouTube, and I watched some maybe 10 years ago. He displayed not just the tech chops but he was a good communicator. RIP.
In an alternate timeline, HyperCard was not allowed to wither and die, but instead continued to mature, embraced the web, and inspired an entire genre of software-creating software. In this timeline, people shape their computing experiences as easily as one might sculpt a piece of clay, creating personal apps that make perfect sense to them and fit like a glove; computing devices actually become (for everyone, not just programmers) the "bicycle for the mind" that Steve Jobs spoke of. I think this is the timeline that Atkinson envisioned, and I wish I lived in it. We've lost a true visionary. Memory eternal!
Maybe there's some sense of longing for a tool that's similar today, but there's no way of knowing how much hypercard did have the impact you are talking about. For example many of us reading here experienced HyperCard. It planted seeds in our future endeavors.
I remember in elementary school, I had some computer lab classes where the whole class worked in hypercard on some task. Multiply that by however many classrooms did something like that in the 80s and 90s. That's a lot of brains that can be influenced and have been.
We can judge it as a success in its own right, even if it never entered the next paradigm or never had quite an equivalent later on.
I miss the days of For Dummies, Bibles, and all the rest. If you'd read that thing carefully a few times, you usually knew your stuff. There was a finish line.
Modern continual versioning and constant updates means there is no finish line. No Bible could ever be printed. Ah, nostalgia.
Word. This is the Papert philosophy of constructionism, learning to think by making that so many of us still carry. I’m still trying to build software-building software. We do live in that timeline; it’s just unevenly distributed.
HyperCard was undoubtedly the inspiration for Visual Basic, which for quite some time dominated the bespoke UI industry in the same way web frameworks do today.
HyperCard was great, but it wasn't the inspiration for Visual Basic.
I was on the team that built Ruby (no relation to the programming language), which became the "Visual" side of Visual Basic.
Alan Cooper did the initial design of the product, via a prototype he called Tripod.
Alan had an unusual design philosophy at the time. He preferred to not look at any existing products that may have similar goals, so he could "design in a vacuum" from first principles.
I will ask him about it, but I'm almost certain that he never looked at HyperCard.
Cooper's solution to this problem didn't click until late 1987, when a friend at Microsoft brought him along on a sales call with an IT manager at Bank of America. The manager explained that he needed Windows to be usable by all of the bank's employees: highly technical systems administrators, semi-technical analysts, and even users entirely unfamiliar with computers, like tellers. Cooper recalls the moment of inspiration:
In an instant, I perceived the solution to the shell design problem: it would be a shell construction set—a tool where each user would be able to construct exactly the shell that they needed for their unique mix of applications and training. Instead of me telling the users what the ideal shell was, they could design their own, personalized ideal shell.
Thus was born Tripod, Cooper's shell construction kit.
I think that would be Decker (https://internet-janitor.itch.io/decker). Not my project but I found it some time ago when I searched for Hypercard successors. The neat thing is that it works in the browser.
HyperNext doesn't appear to be actively developed; the most recent updates I see are from last year, and it can't be used on modern computers. Decker's most recent release was yesterday morning.
There's a fair amount of usage of it on Itch.io, if you are into that indie crowd. I was skeptical of it at first -- the whole 1-bit dithering aesthetic seems a bit too retro-twee, but I find it it is the best Hypercard-alike in terms of functionality -- it "just works" as compared to most Hyperclones that seem more like a proof of concept than a functional program.
Flash completely missed the most important point of HyperCard, which was that end users could put it into edit mode, explore the source code, learn from it, extend it, copy parts of it out, and build their own user interfaces with it.
It's not just "View Source", but "Edit Source" with a built-in, easy to use, scriptable, graphical, interactive WYSIWYG editor that anyone can use.
HyperCard did all that and more long before the web existed, was fully scriptable years before JavaScript existed, was extensible with plug-in XCMDs long before COM/OLE/ActiveX or even OpenDoc/CyberDog or Java/HotJava/Applets, and was widely available and embraced by millions of end-users, was used for games, storytelling, art, business, personal productivity, app development, education, publishing, porn, and so much more, way before merely static web page WYSIWYG editors (let alone live interactive scriptable extensible web application editors) ever existed.
LiveCard (HyperCard as a live HTTP web app server back-end via WebStar/MacHTTP) was probably the first tool that made it possible to create live web pages with graphics and forms with an interactive WYSIWYG editor that even kids could use to publish live HyperCard apps, databases, and clickable graphics on the web.
HyperCard deeply inspired HyperLook for NeWS, which was scripted, drawn, and modeled with PostScript, that I used to port SimCity to Unix:
Alan Kay on “Should web browsers have stuck to being document viewers?” and a discussion of Smalltalk, HyperCard, NeWS, and HyperLook
>"Apple’s Hypercard was a terrific and highly successful end-user authoring system whose media was scripted, WYSIWYG, and “symmetric” (in the sense that the “reader” could turn around and “author” in the same high-level terms and forms). It should be the start of — and the guide for — the “User Experience” of encountering and dealing with web content.
>"The underlying system for a browser should not be that of an “app” but of an Operating System whose job would be to protectively and safely run encapsulated systems (i.e. “real objects”) gotten from the web. It should be the way that web content could be open-ended, and not tied to functional subsets in the browser." -Alan Kay
>[...] This work is so good — for any time — and especially for its time — that I don’t want to sully it with any criticisms in the same reply that contains this praise.
>I will confess to not knowing about most of this work until your comments here — and this lack of knowledge was a minus in a number of ways wrt some of the work that we did at Viewpoints since ca 2000.
>(Separate reply) My only real regret about this terrific work is that your group missed the significance for personal computing of the design of Hypertalk in Hypercard.
>It’s not even that Hypertalk is the very best possible way to solve the problems and goals it took on — hard to say one way or another — but I think it is the best example ever actually done and given to millions of end users. And by quite a distance.
>Dan Winkler and Bill Atkinson violated a lot of important principles of “good programming language design”, but they achieved the first overall system in which end-users “could see their own faces”, and could do many projects, and learn as they went.
>For many reasons, a second pass at the end-user programming problem — that takes advantage of what was learned from Hypercard and Hypertalk — has never been done (AFAIK). The Etoys system in Squeak Smalltalk in the early 2000s was very successful, but the design was purposely limited to 8–11 year olds (in part because of constraints from working at Disney).
You're right. Flash and its legacy would have been better if it had built in "Edit Source".
The earliest Flash projects were these artful assemblages of scripts dangling from nested timelines, like an Alexander Calder mobile. They were at times labyrinthine, like they are in many similar tools, but there were ways to mitigate that. Later on, AS3 code was sometimes written like Java, because we wanted to be taken seriously.
Many Flash community members wanted to share their source, wanted a space where interested people could make changes. We did the best we could, uploading FLA files and zipped project directories. None of it turned out to be especially resilient.
It's one of the things I admire about Scratch. If you want, you can peek inside, and it's all there, for you to learn from and build off of, with virtually no arbitrary barriers in place.
Pretty sure the next after Hypercard was Macromind (later Macromedia) Director. I recall running an early version of a Director animation on a black and white Mac not long after I started playing with Hypercard. Later I was a Director developer. I recall when Future Splash released -- the fast scaling vector graphics were a new and impressive thing. The web browser plugin helped a lot and it really brought multimedia to the browser. It was only later that Macromedia acquired Future Splash and renamed it Flash.
- Minecraft
- Roblox
- LittleBigPlanet
- Mario Maker
This is what kids do to be creative.
Slightly more serious (and therefore less succesful):
- Logo/Turtle Graphics
- Scratch
- HyperStudio
HyperCard was both graphic design and hypertext (links). These two modalities got separated, and I think there are practical reasons for that. Because html/css design actually sucks and never became an amateur art form.
For writing and publishing we got Wiki, Obsidian et al, Blogs (RIP), forums, social media. Not meant to be interactive or programmable, but these fulfill people's needs for publishing.
(see the subsubsection "Arcs for toolpaths and DXFs")
Jupyter Notebooks come close to allowing a seamless blending of text and algorithm, but they are sorely missing on the graphic design and vector graphics front --- which now that I write that, makes me realize that that is the big thing which I miss when trying to use them. Makes me wish for JuMP, a Jupyter Notebook which incorporates METAPOST --- if it also had an interactive drawing mode, it would be perfect.... (for my needs).
inspired an entire genre of software-creating software. In this timeline, people shape their computing experiences as easily as one might sculpt a piece of clay, creating personal apps that make perfect sense to them and fit like a glove
Mr. Atkinson's passing was sad enough without thinking about this.
(More seriously: I can still recall using ResEdit to hack a custom FONT resource into a HyperCard stack, then using string manipulation in a text field to create tiled graphics. This performed much better than button icons or any other approach I could find. And then it stopped working in System 7.)
Not sure that sculpting clay is the best analogy. Lots of sculpting is hard, as is turning clay, especially if you want to successfully fire the result. Maybe it is an accurate analogy, but people may understand the difficulty differently.
Hypercard is more like Lego - you can simply buy completed sets (use other's hypercard programs) - or you can put together things according to instructions - but you can always take them apart and change them, and eventually build your own.
The Web was significantly influenced by HyperCard. Tim Berners-Lee's original prototypes envisioned it as bidirectional, with a hypertext editor shipping alongside the browser. In that sense it does live on, and serves as the basis for much of the modern Internet.
IIRC, the mouse pointer turning into a hand when you mouse over something clickable was original to HyperCard. And I think Brendan Eich was under a heavy influence of HyperTalk when created JavaScript.
JavaScript felt like it took the best parts of C (concise expressiveness) and the ease of use of HyperTalk (event handlers, easy hierarchical access to objects, etc). It was pretty sweet.
I honestly don't think the modern web is a legitimate hypertext system at this point. It was already bad enough 20 years ago with flash and serverside CGI but now most of the major websites are just serving JavaScript programs that then fetch data using a dedicated API. And then there's all the paywalls and constant CAPTCHA checks to make sure you aren't training an LLM off their content without a license.
Look up hyperland, it's a early 90s documentary by Douglas Adams and the guy from doctor who about the then-future hypermedia revolution. I can remember the web resembling that a long time ago but the modern web is very far removed from anything remotely resembling hypertext.
That look like my kind of book, I'll definitely be checking it out. Overall I'm still pretty pessimistic about hypertext making a true return, there's too much money in the web as an app-delivery mechanism, plus we have an entire generation of adults who are younger than Facebook, and now companies are trying to gatekeep the content itself because they want to be able to charge for LLM training on their text (I've noticed a significant increase in how many CAPTCHA challenges I get and I'm pretty sure it has nothing to do with DDOS).
But I'm glad to see I'm not the only one who misses the old web when it really was all about exchanging ideas and information over open protocols. I will never get over this massive sense of nostalgia whenever I remember browsing through weird groceries fan sites and seeing people just documenting their love for whatever hobbies they had and the platforms weren't always pushing political BS to "drive engagement" by making me angry.
DonHopkins on Feb 10, 2020 | parent | context | favorite | on: HyperCard: What Could Have Been (2002)
Do you have the first commercial HyperCard stack ever released: the HyperCard SmutStack? Or SmutStack II, the Carnal Knowledge Navigator, both by Chuck Farnham?
SmutStack was the first commercial HyperCard product available at rollout, released two weeks before HyperCard went public at a MacWorld Expo, cost $15, and made a lot of money (according to Chuck). SmutStack 2, the Carnal Knowledge Navigator, had every type of sexual adventure you could imagine in it, including information about gays, lesbians, transgendered, HIV, safer sex, etc. Chuck was also the marketing guy for Mac Playmate, which got him on Geraldo, and sued by Playboy.
>Smut Stack. One of the first commercial stacks available at the launch of HyperCard was Smut Stack, a hilarious collection (if you were in sixth grade) of somewhat naughty images that would make joke, present a popup image, or a fart sound when the viewer clicked on them. The author was Chuck Farnham of Chuck's Weird World fame.
>How did he do it? After all, HyperCard was a major secret down at Cupertino, even at that time before the wall of silence went up around Apple.
>It seems that Farnham was walking around the San Jose flea market in the spring of 1987 and spotted a couple of used Macs for sale. He was told that they were broken. Carting them home, he got them running and discovered several early builds of HyperCard as well as its programming environment. Fooling around with the program, he was able to build the Smut Stack, which sold out at the Boston Macworld Expo, being one of the only commercial stacks available at the show.
>This staunch defender was none other than Chuck Farnham, whom readers of this column will remember as the self-appointed gadfly known for rooting around in Apple’s trash cans. One of Farnham ’s myriad enterprises is Digital Deviations, whose products include the infamous SmutStack, the Carnal Knowledge Navigator, and the multiple-disk set Sounds of Susan. The last comes in two versions: a $15 disk of generic sex noises and, for $10 more, a personalized version in which the talented Susan moans and groans using your name. I am not making this up.
>Farnham is frank about his participation in the Macintosh smut trade. “The problem with porno is generic,” he says, sounding for the briefest moment like Oliver Wendell Holmes. “When you do it, you have to make a commitment ... say you did it and say it’s yours. Most people would not stand up in front of God and country and say, ‘It’s mine.’ I don’t mind being called Mr. Scum Bag.”
>On the other hand, he admits cheerily, “There’s a huge market for sex stuff.” This despite the lack of true eroticism. “It’s a novelty,” says Farnham. Sort of the software equivalent of those ballpoint pens with the picture of a woman with a disappearing bikini.
I actually had an experience like this yesterday. After reading Gruber talk about how Markdown was never meant for notes, I started to rethink things. I wanted plain text, to be future proof, then stumbled across CotEditor as a means to edit. Inside I was able to use the code highlighting and outline config to define my own regex and effectively create my own markup language with just a dash of regex and nothing more. I then jumped over to Shortcuts and dragged and dropped some stuff together to open/create yearly and daily notes (on either my computer or phone), or append to a log with a quick action.
It is a custom system that didn’t require any code (if you don’t count the very minor bits of regex (just a lot of stuff like… ^\s- .).
Is it a good system, probably not, but we’ll see where it goes.
"In an alternate timeline, HyperCard was not allowed to wither and die, but instead continued to mature, embraced the web..."
In yet another alternate timeline, someone thought to add something like URLs with something like GET, PUT, etc. to HyperCard, and Tim Berners-Lee's invention of the Web browser never happened because Hypercard already did it all.
On one hand this would be simply amazing, on the other hand it would have been a total security nightmare that makes early Javascript look like a TPM Secure Enclave.
Looking at the HyperTalk syntax [0] it's interesting how we take left hand variable assignment as a given while math typically teaches the exact opposite since you can't really write the answer before you have the question.
Makes you think if lambda expressions would be more consistent with the rest if they were reversed.
We kind of had that for a time with FileMaker and MS Access. People could build pretty amazing stuff with those apps, even without being a programmer.
I think the reason those apps never became mainstream is that they didn't have a good solution for sharing data. There were some ways you could use them to access database servers, but setting them up was so difficult that they were for all intents and purposes limited to local, single user programs.
HTML, CSS, PHP and MySQL had a learning curve, but you could easily make multi-user programs with them. That's why the web won.
Yes! I used FileMaker a lot, and built my first journaling system with it. Like a cross between hypercard and a wiki. It really changed my life and this lead to programming.
His legacy still exists and continues today. Even updated to modern sensibilities, cross-platform, and compatible with all your legacy Hypercard stacks!
As far as I remember, progression was Hypercard -> Metacard -> Runtime Revolution -> Livecode.
I was a kid when this progression first happened, my older brother Tuviah Snyder (now at Apple), was responsible for much of these updates and changes first at Metacard and then at its acquirer Runtime Revolution.
I even wrote some of my first programs as Hypercard compatible stacks. Was quite fun to see my apps on download.com, back in the day when that meant something :).
I always joked it required please and thank you due to its verbosity, but was super simple, accessible, and worked!
How nice, that even today one can take their legacy Hypercard Stacks and run them in the web, mobile, etc. Or create something new in what was more structured vibecoding before vibecoding :).
This seems like something completely different? Livecode looks like just another toolkit or SDK for developing standalone apps, which might be great for the handful of developers using it but certainly doesn't do anything to re-shape how users interact with their computers
Nope, is completely the same base. Scroll the homepage, and you'll see an example of Livecode (updated HyperTalk).
You can open your HyperCard stacks, or MetaCard stacks, or Runtime/Livecode Stacks in their IDE, code, edit, etc, similar to what you would have back in Hypercard days, but with modern features, updates, and additions.
It's backwards compatible with HyperTalk, its current language is an updated HyperTalk (i.e. an updated MetaTalk), that incorporates all that was, but adds new features for today.
Your Livecode apps can be deployed and run as cross-platform desktop applications (Mac, Win, *nix) , mobile applications, and as far as I remember, web applications with HTML5 deployment (so they say).
Not affiliated with them in any way, just sharing my understanding and memories.
Oh. I came here to pass the time as I built a TinyMac with a Pi and was compiling BasiliskII in SDL mode. I'm quite saddened by the news, as Bill was one of the people who had the most influence in the technical design of early Macs (and a brilliant engineer for all accounts).
This post is only an hour old as I’m writing this, so give it time. It’s a weekend, and as far as I’m aware there are only 2 mods, unless there are others empowered to turn on the black bar in their absence.
Resources only help you reach your genetic potential, but if you’re just not built for longevity you still may not live long.
And some people with no resources, no reason to live, but have incredible genetics will linger for many years beyond what people think is possible, like a weed.
Like a weed, in the sense of living in spite of ones circumstances. For example, a person with limited resources living for a long time, which is like a weed with little sunlight still growing from a crack in concrete.
Bill pushed himself to his limits. I saw this first hand at General Magic, and heard the stories about the development of the Macintosh. People can wear themselves out.
> RIP. It still suprises me that people with resources die so early (he died at 74).
You don't know for how long he did have that disease, if anything, resources might have afforded him many more years of life at first place.So your comment strikes me as odd, given the fact that you can't judge how long did he live with such disease.
One of my friend's dad died from the same kind of cancer. Between the diagnosis and their death, 2 months passed, and that person had plenty of "resources"...
Life is not guaranteed. Once you've seen it happen a few times, you realize how stochastic death really is (or really, how stochastic living is). 74 is at least not the territory where people generally gasp at how young he was.
Unless you're getting preventative screenings frequently, pancreatic cancer can be one of those ones that don't show any symptoms til you're already in stage 4. And most normal doctors will tell you to not do large amounts of preventative screenings.
There isn't an amount of resources in the world that will protect you from cancer, despite what some claim. Like my grandma said, "it is your reward for surviving absolutely everything else that could have got you" (she beat 3 different kinds of cancer before losing to a 4th, with 'resources')
> One of Bill Atkinson’s amazing feats (which we are so accustomed to nowadays that we rarely marvel at it) was to allow the windows on a screen to overlap so that the “top” one clipped into the ones “below” it. Atkinson made it possible to move these windows around, just like shuffling papers on a desk, with those below becoming visible or hidden as you moved the top ones. Of course, on a computer screen there are no layers of pixels underneath the pixels that you see, so there are no windows actually lurking underneath the ones that appear to be on top. To create the illusion of overlapping windows requires complex coding that involves what are called “regions.” Atkinson pushed himself to make this trick work because he thought he had seen this capability during his visit to Xerox PARC. In fact the folks at PARC had never accomplished it, and they later told him they were amazed that he had done so. “I got a feeling for the empowering aspect of naïveté”, Atkinson said. “Because I didn’t know it couldn’t be done, I was enabled to do it.” He was working so hard that one morning, in a daze, he drove his Corvette into a parked truck and nearly killed himself. Jobs immediately drove to the hospital to see him. “We were pretty worried about you”, he said when Atkinson regained consciousness. Atkinson gave him a pained smile and replied, “Don’t worry, I still remember regions.”
I think the difference between the Apple and Xerox approach may be more complicated than the people at PARC not knowing how to do this. The Alto doesn't have a framebuffer, each window has its own buffer and the microcode walks the windows to work out what to put on each scanline.
Not doubting that, but what is the substantive difference here? Does the fact that there is a screen buffer on the Mac facilitate clipping that is otherwise not possible on the Alto?
It allows the Mac to use far less RAM to display overlapping windows, and doesn't require any extra hardware. Individual regions are refreshed independently of the rest of the screen, with occlusion, updates, and clipping managed automatically,
Yeah, it seems like the hard part of this problem isn't merely coming up with a solution that technically is correct, but one that also is efficient enough to be actually useful. Throwing specialized or more expensive hardware at something is a valid approach for problems like this, but all else being equal, having a lower hardware requirement is better.
I was just watching an interview with Andy Hertzfeld earlier today and he said this was the main challenge of the Macintosh project. How to take a $10k system (Lisa) and run it on a $3k system (Macintosh).
He said they drew a lot of inspiration from Woz on the hardware side. Woz was well known for employing lots of little hacks to make things more efficient, and the Macintosh team had to apply the same approach to software.
So when the OS needs to refresh a portion of the screen (e.g. everything behind a top window that was closed), what happens?
My guess is it asks each application that overlapped those areas to redraw only those areas (in case the app is able to be smart about redrawing incrementally), and also clips the following redraw so that any draw operations issued by the app can be "culled". If an app isn't smart and just redraws everything, the clipping can still eliminate a lot of the draw calls.
Displaying graphics (of any kind) without a framebuffer is called "racing the beam" and is technically quite difficult and involves managing the real world speed of the electron beam with the cpu clock speed ... as in, if you tax the cpu too much the beam goes by and you missed it ...
The very characteristic horizontally stretched graphics of the Atari 2600 are due to this - the CPU was actually too slow, in a sense, for the electron beam which means your horizontal graphic elements had a fairly large minimum width - you couldn't change the output fast enough.
It definitely makes it simpler. You can do a per-screen window sort, rather than per-pixel :).
Per-pixel sorting while racing the beam is tricky, game consoles usually did it by limiting the number of objects (sprites) per-line, and fetching+caching them before the line is reached.
I remember coding games for the C64 with an 8 sprite limit, and having to swap sprites in and out for the top and bottom half of the screen to get more than 8.
Reminds me of a GPU's general workflow. (like the sibling comment, 'isn't that the obvious way this is done'? Different drawing areas being hit by 'firmware' / 'software' renderers?)
Frame buffer memory was still incredibly expensive in 1980. Our labs 512 x 512 x 8bit table lookup color buffer cost $30,000 in 1980. Mac's 512 x 384 x 8bit buffer in 1984 had to fit the Macs $2500 price. The Xerox Alto was earlier than these two devices and would have cost even more if it had a full frame buffer.
The Alto created the image from a display list, like the Atari 800 or the Amiga. So you could have a wider rectangle on most of the screen for pictures and a narrower rectangle at the bottom for displaying status. It was not up to showing overlapping windows. Nearly all applications just set things to one rectangle, having a frame buffer in practice. This was the case for Smalltalk, which is where Bill saw the overlapping windows. One problem is that filling up the whole screen (606x808) used up half of the memory and slowed down user code, so Smalltalk-72 reduced this to 512x684 to get back some memory and performance.
The Smalltalk-76 MVC user interface that the Apple people saw only ever updated the topmost window which, by definition, was not clipped by any other window. If you brought some other window to the front it would only then be updated. But since nothing ran in the background it was easy to get the wrong impression that the partially visible windows were being handled.
Bill's solution had two parts: one was regions, as several other people have explained. It allowed drawing to a background window even while clipping to any overlapping windows that are closer. But the second was PICTs, where applications did not directly draw to their windows but instead created a structure (could be a file) with a list of drawing commands which was then passed to the operating system for the actual drawing. You could do something like "open PICT, fill background with grey pattern, draw white oval, draw black rectangle, close PICT".
Now if the window was moved the OS could recalculate all the regions of the new configuration and re-execute all the PICTs to update any newly exposed areas. If the application chose to instead draw its own pixels (a game, for example) then the OS would insert a warning into the app's event queue that it should fix its window contents.
In parallel with Bill's work (perhaps a little before it) we had Rob Pike's Blit terminal (commercially released in 1982) which added windows to Unix machines. It had the equivalent of regions (less compact, however) but used a per window buffer so the terminal would have where to copy newly exposed pixels from.
Pretty awesome story, but also with a bit of dark lining. Of course any owner, and triple that for Jobs, loves over-competent guys who work themselves to the death, here almost literally.
But that's not a recipe for personal happiness for most people, and most of us would not end up contributing revolutionary improvements even if done so. World needs awesome workers, and we also need ie awesome parents or just happy balanced content people (or at least some part of those).
Pretty much. Most of us have creative itches to scratch that make us a bit miserable if we never get to pursue them, even if given a comfortable life. It’s circumstantial whether we get to pursue them as entrepreneurs or employees. The users or enjoyers of our work benefit either way.
Just to add on, some of us have creative itches that are not directly monetizable, and for which there may be no users or enjoyers of our work at all (if there are, all the better!).
Naturally I don’t expect to do such things for a living.
Survivorship bias. The guys going home at 5 went home at 5 and their companies are not written about. It’s dark but we’ve been competing for a while as life forms and this is “dark-lite” compared to what our previous generations had to do.
Some people are competing, and need to make things happen that can’t be done when you check out at 5. Or more generally: the behaviour that achieves the best outcome for a given time and place, is what succeeds and forms the legends of those companies.
If you choose one path, know your competitors are testing the other paths. You succeed or fail partly based on what your most extreme competitors are willing to do, sometimes with some filters for legality and morality. (I.e. not universally true for all countries or times.)
Edit: I currently go home at 5, but have also been the person who actually won the has-no-life award. It’s a continuum, and is context specific. Both are right and sometimes one is necessary.
With overlapping rectangular windows (slightly simpler case than ones with rounded corners) you can expect visible regions of windows that are not foremost to be, for example, perhaps "L" shaped, perhaps "T" shaped (if there are many windows and they overlap left and right edges). Bill's region structure was, as I understand it, more or less a RLE (run-length encoded) representation of the visible rows of a window's bounds. The region for the topmost window (not occluded in any way) would indicate the top row as running from 0 to width-of-window (or right edge of the display if clipped by the display). I believe too there was a shortcut to indicate "oh, and the following rows are identical" so that an un-occluded rectangular window would have a pretty compact region representation.
Windows partly obscured would have rows that may not begin at 0, may not continue to width-of-window. Window regions could even have holes if a skinnier window was on top and within the width of the larger background window.
The cleverness, I think, was then to write fast routines to add, subtract, intersect, and union regions, and rectangles of this structure. Never mind quickly traversing them, clipping to them, etc.
The QuickDraw source code refers to the contents of the Region structure as an "unpacked array of sorted inversion points". It's a little short on details, but you can sort of get a sense of how it works by looking at the implementation of PtInRgn(Point, RegionHandle):
As far as I can tell, it's a bounding box (in typical L/T/R/B format), followed by a sequence of the X/Y coordinates of every "corner" inside the region. It's fairly compact for most region shapes which arise from overlapping rectangular windows, and very fast to perform hit tests on.
The key seems to have been recognizing the utility of the region concept and making it fundamental to the QuickDraw API (and the clever representation that made finding the main rectangular portions easy). This insulated QuickDraw from the complexity of windowing system operations. Once you go implementing region operations you probably find that it's fairly efficient to work out the major rectangular regions so you can use normal graphics operations on them, leaving small areas that can just be done inefficiently as a bunch of tiny rectangles. All this work for clipped graphics was applicable to far more than just redrawing obscured window content, so it could justify more engineering time to polishing it. Given how easy they were to use, more things could leverage the optimization (e.g. using them to redraw only the dirty region when a window was uncovered).
> In fact the folks at PARC had never accomplished it, and they later told him they were amazed that he had done so.
Reminds me of the story where some company was making a new VGA card, and it was rumored a rival company had implemented a buffer of some sort in their card. When both cards came out the rival had either not actually implemented it or implemented a far simpler solution
An infamous Starcraft example also contains notes of a similar story where they were so humbled by a competitor's demo (and criticism that their own game was simply "Warcraft in space") that they went back and significantly overhauled their game.
Former Ion Storm employees later revealed that Dominion’s E3 1996 demo was pre-rendered, with actors pretending to play, not live gameplay.
I got a look at an early version of StarCraft source code as a reference for the sound library for Diablo 2 and curiosity made me do a quick analysis of the other stuff - they used a very naive approach to C++ and object inheritance to which first time C++ programmers often fall victim. It might have been their first C++ project so they probably needed to start over again anyways. We had an edict on Diablo 2 to make the C++ look like recognizable C for Dave Brevik's benefit which turned out pretty well I think (it was a year late but we shipped).
Michael Abrash's black book of graphics programming. They heard about a "buffer", so implemented the only non-stupid thing - a write FIFO. Turns out the competition had done the most stupid thing and built a read buffer.
I teach this lesson to my mentees. Knowing that something is possible gives you significant information. Also, don't brag - It gives away significant information.
Just knowing something is possible makes it much, much easier to achieve.
> Turns out the competition had done the most stupid thing and built a read buffer
This isn't really stupid though as explained in the pdf
> Paradise had stuck a read FIFO
between display memory and the video output stage of the VGA, allowing the video output to
read ahead, so that when the CPU wanted to access display memory, pixels could come from
the FIFO while the CPU was serviced immediately. That did indeed help performance--but not
as much as Tom’s write FIFO.
VRAM accesses are contended, so during the visual display period the VGA circuitry has priority.
CPU accesses result in wait states - a FIFO between the VRAM and the VGA means less contention and more cycles for CPU accesses
Why improve read performance though? Games accessing VRAM I presume would be 99% write.
Perhaps it was to improve performance in GUIs like Windows?
Would someone mind explaining the technical aspect here? I feel with modern compute and OS paradigms I can’t appreciate this. But even now I know that feeling when you crack it and the thrill of getting the imposible to work.
It’s on all of us to keep the history of this field alive and honor the people who made it all possible. So if anyone would nerd out on this, I’d love to be able to remember him that way.
There were far fewer abstraction layers than today. Today when your desktop application draws something, it gets drawn into a context (a "buffer") which holds the picture of the whole window. Then the window manager / compositor simply paints all the windows on the screen, one on top of the other, in the correct priority (I'm simplifying a lot, but just to get the idea). So when you are programing your application, you don't care about other applications on the screen; you just draw the contents of your window and that's done.
Back at the time, there wouldn't be enough memory to hold a copy of the full contents all possible windows. In fact, there were actually zero abstraction layers: each application was responsible to draw itself directly into the framebuffer (array of pixels), into its correct position. So how to handle overlapping windows? How could each application draw itself on the screen, but only on the pixels not covered by other windows?
QuickDraw (the graphics API written by Atkinson) contained this data structure called "region" which basically represent a "set of pixels", like a mask. And QuickDraw drawing primitives (eg: text) supported clipping to a region. So each application had a region instance representing all visible pixels of the window at any given time; the application would then clip all its drawing to the region, so that only the visibile pixels would get updated.
But how was the region implemented? Obviously it could have not been a mask of pixels (as in, a bitmask) as it would use too much RAM and would be slow to update. In fact, think that the region datastructure had to be quick at doing also operations like intersections, unions, etc. as the operating system had to update the regions for each window as windows got dragged around by the mouse.
So the region was implemented as a bounding box plus a list of visible horizontal spans (I think, I don't know exactly the details). When you represent a list of spans, a common hack is to use simply a list of coordinates that represent the coordinates at which the "state" switches between "inside the span" to "outside the span". This approach makes it for some nice tricks when doing operations like intersections.
Hope this answers the question. I'm fuzzy on many details so there might be several mistakes in this comment (and I apologize in advance) but the overall answer should be good enough to highlight the differences compared to what computers to today.
It's a good description, but I'm going to add a couple of details since details that are obvious to someone who lived through that era may not be obvious to those who came after.
> Obviously it could have not been a mask of pixels
To be more specific about your explanation of too much memory: many early GUIs were 1 bit-per-pixel, so the bitmask would use the same amount of memory as the window contents.
There was another advantage to the complexity of only drawing regions: the OS could tell the application when a region was exposed, so you only had to redraw a region if it was exposed and needed an update or it was just exposed. Unless you were doing something complex and could justify buffering the results, you were probably re-rendering it. (At least that is my recollections from making a Mandelbrot fractal program for a compact Mac, several decades back.)
And even ignoring memory requirements, an uncompressed bitmap mask would have taken a lot of time to process (especially considering when combining regions where one was not a multiple of 8 pixels shifted with respect to the other. With just the horizontal coordinates of inversions, it takes the same amount of time for a region 8 pixels wide and 800 pixels wide, given the same shape complexity.
Yeah those are the horizontal spans I was referring to.
It’s a sorted list of X coordinates (left to right). If you group them in couples, they are begin/end intervals of pixels within region (visibles), but it’s actually more useful to manipulate them as a flat array, as I described.
I studied a bit the code and each scanline is prefixed by the Y coordinates, and uses an out of bounds terminator (32767).
It's a bit more than that. The list of X coordinates is cumulative - once an X coordinate has been marked as an inversion, it continues to be treated as an inversion on all Y coordinates below that, not just until the next Y coordinate shows up. (This manifests in the code as D3 never being reset within the NOTRECT loop.) This makes it easier to perform operations like taking the union of two disjoint regions - the sets of points are simply sorted and combined.
Uhm can you better explain that? I don’t get it. D3 doesn’t get reset because it’s guaranteed to be 0 at the beginning of each scanline, and the code needs to go through all “scanline blocks” until it finds the one whose Y contains the one specified as argument. It seems to me that each scanline is still self contained and begins logically at X=0 in the “outside” state?
> D3 doesn’t get reset because it’s guaranteed to be 0 at the beginning of each scanline
There's no such guarantee. The NEXTHOR loop only inverts for points which are to the absolute left of the point being tested ("IS HORIZ <= PT.H ? \\ NO, IGNORE THIS POINT").
Imagine that, for every point, there's a line of inversion that goes all the way down to the bottom of the bounding box. For a typical rectangular region, there's going to be four inversion points - one for each corner of the rectangle. The ones on the bottom cancel out the ones on the top. To add a second disjoint rectangle to the region, you'd simply include its four points as well; so long as the regions don't actually overlap, there's no need to keep track of whether they share any scan lines.
One of my favourite Atkinson stories -- I can't remember if this is on folklore.org or somewhere else -- is that he actually implemented editable text in MacPaint, by scanning the bitmap for character shapes, but chose not to ship that feature because it could never be perfect. Amazing technical skill and great taste and judgement.
If you haven't, check out the documentary[0] on General Magic which Bill co-founded in 1990. Among the more remarkable scenes in there is when a member of the public seems perplexed by the thought that they would even want to "check email from Times Square."
An unthinkable future, but they thought it. And yet, most folks have never heard of General Magic.
Also, it's here in the documentary that someone expresses the excitement anticipating the smart phone. It's hard to watch for me now and not shake my head, "Oh, it's not quite as wonderful as you imagined."
No, just someone who isn't steeped in surveillance culture. My obtuseness is just a direct response to the obtuseness of the surveillance industry demanding "consent" when I'm trying to read about someone's death. I have also entered throwaway nyms for the online streams of family funerals that have tried to bundle abusive legal terms. What's socially gauche here is letting a moment of mourning turn into leverage for the surveillance industry.
Thank you for that, actually. Archive.md is my go to for trashwalled news articles, somehow I didn't think to do that for a Faceboot URL. Probably because I don't respect Faceboot enough to imagine they operate with real URIs.
I'm yet another child of HyperCard. It opened my mind to what computers could be for, and even though the last two decades have been full primarily of disappointment, I still hold onto that other path as a possibility, or even as a slice of reality---a few weeds growing in the cracks of our dystopian concrete.
I fondly remember creating simple narrative stories and games with HyperCard at 6 years old on my dad's Macintosh SE. It was my first contact with programming and a fundamental seed to using the computer as a creative tool. It has shaped my life in a substantial way. RIP Bill - HN bar should be blacked out.
When I was on the ColorSync team at Apple we, the engineers, got an invite to his place-in-the-woods one day.
I knew who he was at the time, but for some reason I felt I was more or less beholden to conversing only about color-related issues and how they applied to a computer workflow. Having retired, I have been kicking myself for some time not just chatting with him about ... whatever.
He was at the time I met him very in to a kind of digital photography. My recollection was that he had a high-end drum scanner and was in fact scanning film negatives (medium format camera?) and then going with a digital workflow from that point on. I remember he was excited about the way that "darks" could be captured (with the scanner?). A straight analog workflow would, according to him, cause the darks to roll off (guessing the film was not the culprit then, perhaps the analog printing process).
He excitedly showed us on his computer photos he took along the Pacific ocean of large rock outcroppings against the ocean — pointing out the detail that you could see in the shadow of the rocks. He was putting together a coffee table book of his photos at the time.
I have to say that I mused at the time about a wealthy, retired, engineer who throws money at high end photo gear and suddenly thinks they're a photographer. I think I was weighing his "technical" approach to photography vs. a strictly artistic one. Although, having learned more about Ansel Adams technical chops, perhaps for the best photographers there is overlap.
> I have to say that I mused at the time about a wealthy, retired, engineer who throws money at high end photo gear and suddenly thinks they're a photographer
I think this says more about you than it does about him
This is absolutely true and I don't understand why you're being downvoted. Especially in the context of this man just recently dying, there's someone throwing in their elitist opinion about photographers and how photography SHOULD be done, and apparently Bill was doing it wrong.
Well, I certainly didn't mean for it to come across that way. I wasn't saying this was the case with Bill. To be clear, I saw nothing bad about Bill's photos. (Also I'm not really versed enough in professional photography to have a valid opinion even if I didn't like them and so would not have publicly weighed in on them anyway.)
I was though being honest about how I felt at that time — debated whether to keep it to myself or not today (but I always foolishly error on the side of being forthcoming).
Perhaps it's a strange thing to imagine that someone would pursue in their spare time, especially after retired, what they did professionally.
There probably still isn't a good way to get that kind of dynamic range entirely in the digital domain. Oh, I'm sure the shortfall today is smaller, say maybe four or five stops versus probably eight or twelve back then. Nonetheless, I've done enough work in monochrome to recognize an occasional need to work around the same limitations he was, even though very few of my subjects are as demanding.
I wish a good monochrome digital camera didn't cost a small fortune. And I'm too scared to try to remove the Bayer grid from a "color" CCD.
Seems that, without the color/Bayer thing, you could get an extra stop or two for low-light.
I had a crazy notion to make a camera around an astronomical CCD (often monochrome) but they're not cheap either — at least one with a good pixel count.
I've replaced my D5300's viewfinder focusing screen a couple of times, back before I outgrew the need for focusing aids. I also wouldn't try debayering its sensor! But that sort of thing is what cheap beater bodies off your friendly local camera store's used counter, or eBay, were made for. Pixel count isn't everything, and how better to find out whether the depth of your interest would reward serious investment, than to see whether and how soon it outgrows unserious? Indeed, my own entire interest in photography has developed just so, out of a simple annoyance at having begun to discover what a 2016 phone camera couldn't do.
For black and white photography, the best high-end camera seemed to be the Leica M Monochrom (https://en.wikipedia.org/wiki/Leica_M_Monochrom), but to my mind, it's trounced by the Foveon:
You always lose something when doing optical printing - you can often gain things too, but its not 1:1.
I adore this hybrid workflow, because I can pick how the photo will look, color palate, grain, whatever by picking my film, then I can use digital to fix (most if not all of) the inherent limitations in analog film.
Sadly, film is too much of a pain today, photography has long been about composition for me, not cameras or process - I liked film because I got a consistent result, but I can use digital too, and I do today.
"When art critics get together they talk about form and structure and meaning. When artists get together they talk about where you can buy cheap turpentine."
> I have been kicking myself for some time not just chatting with him about ... whatever.
Maybe I should show some initiative! See, for a little while now I've wanted to just chat with you about whatever.
At this moment I'm working on a little research project about the advent of color on the Macintosh, specifically the color picker. Would you be interested in a casual convo that touches on that? If so, I can create a BlueSky account and reach out to you over there. :)
John is cool, but I don't think he was around when the Macintosh II software and hardware was being designed for color support. I did work with Eric Ringewald at Be and he was one of the Color Quickdraw engineers. He would be fun to talk to. Michael Dhuey worked on the hardware of the Mac II platform. I guess we can give some credit to Jean-Louis Gassée as well. Try to talk to those people! I got to work with a lot of these Apple legends at General Magic, Be, Eazel and then back at Apple again. I never got to work on a project with JKCalhoun directly, but I did walk by his office quite frequently.
True. I showed up at Apple in '95 after Color Quickdraw was already a thing.
Hilariously though, I did get handed the color pickers to "port" to PowerPC. In fact one of the first times I thought I was in over my head being at Apple was when I was staring at 68030 assembly and thinking, "Fuck, I have to rewrite this in C perhaps."
From your username, I feel like we've chatted before (but I don't know your real name).
> I have to say that I mused at the time about a wealthy, retired, engineer who throws money at high end photo gear and suddenly thinks they're a photographer.
Duchamp would like a word.
Seriously though, as someone this describes to a T (though “suddenly” in this case is about 19 years), I was afraid to call myself any sort of artist for well over a decade, thinking I was just acquiring signal with high end gear. I didn’t want to try to present myself as something I’m not. After all, I just push the button, the camera does all the work.
I now have come to realize that this attitude is toxic and unnecessary. Art (even bad art!) doesn’t need more gatekeeping or gatekeepers.
I am a visual artist. A visual artist with perhaps better equipment than my skill level or talent justifies, but a visual artist nonetheless.
Bill showed up at one of the WWDCs (2011?). I sat next to him during a lunch, not knowing who he was! He told me his name, and then showed me some photos he had taken. He seemed to me to be a gentle and kind soul. So sad to read this news.
Atkinson's work is so influential. From his contributions to the Macintosh team, to HyperCard, Bill was an inspiration to me and showed the power of merging art & technology.
294 comments
[ 3.1 ms ] story [ 259 ms ] threadrip
https://www.folklore.org/Joining_Apple_Computer.html
https://www.folklore.org/Negative_2000_Lines_Of_Code.html --- something to bring up whenever lines of code as a metric is put forward
https://www.folklore.org/Rosings_Rascals.html --- story of how the Macintosh Finder came to be
https://www.folklore.org/I_Still_Remember_Regions.html --- surviving a car accident
This lesson stuck with me for years. Final results alone are measurable, not productivity.
> Final results alone are measurable
Not even those, for individuals
Mostly we work in teams. I myself like to work in "plumbing" that is arbitrarily far from "final results"
Code that’s 4K and took slightly less time to write but runs slightly faster than code that’s 400 bytes that took another 30m to write still doesn’t get the best score.
What about correctness, robustness, readability, clarity, maintainability?
I remember in elementary school, I had some computer lab classes where the whole class worked in hypercard on some task. Multiply that by however many classrooms did something like that in the 80s and 90s. That's a lot of brains that can be influenced and have been.
We can judge it as a success in its own right, even if it never entered the next paradigm or never had quite an equivalent later on.
Modern continual versioning and constant updates means there is no finish line. No Bible could ever be printed. Ah, nostalgia.
I was on the team that built Ruby (no relation to the programming language), which became the "Visual" side of Visual Basic.
Alan Cooper did the initial design of the product, via a prototype he called Tripod.
Alan had an unusual design philosophy at the time. He preferred to not look at any existing products that may have similar goals, so he could "design in a vacuum" from first principles.
I will ask him about it, but I'm almost certain that he never looked at HyperCard.
https://vibes.diy/
We had a lot of fun last night with Vibecode Karaoke, where you code an app at the same time as you sing a song.
What actually are the best successors now, at least for authoring generic apps for the open web? (Other than vibe coding things)
Why use it rather than Livecode (aside from the licensing of the latter) or Hypernext Studio?
Unlike LiveCode (or so far as I am aware HyperNext), Decker is free and open-source: https://github.com/JohnEarnest/Decker
HyperNext doesn't appear to be actively developed; the most recent updates I see are from last year, and it can't be used on modern computers. Decker's most recent release was yesterday morning.
I'd be happy to go into more detail if you like.
I guess I want a Flash replacement....
It's not just "View Source", but "Edit Source" with a built-in, easy to use, scriptable, graphical, interactive WYSIWYG editor that anyone can use.
HyperCard did all that and more long before the web existed, was fully scriptable years before JavaScript existed, was extensible with plug-in XCMDs long before COM/OLE/ActiveX or even OpenDoc/CyberDog or Java/HotJava/Applets, and was widely available and embraced by millions of end-users, was used for games, storytelling, art, business, personal productivity, app development, education, publishing, porn, and so much more, way before merely static web page WYSIWYG editors (let alone live interactive scriptable extensible web application editors) ever existed.
LiveCard (HyperCard as a live HTTP web app server back-end via WebStar/MacHTTP) was probably the first tool that made it possible to create live web pages with graphics and forms with an interactive WYSIWYG editor that even kids could use to publish live HyperCard apps, databases, and clickable graphics on the web.
HyperCard deeply inspired HyperLook for NeWS, which was scripted, drawn, and modeled with PostScript, that I used to port SimCity to Unix:
Alan Kay on “Should web browsers have stuck to being document viewers?” and a discussion of Smalltalk, HyperCard, NeWS, and HyperLook
https://donhopkins.medium.com/alan-kay-on-should-web-browser...
>"Apple’s Hypercard was a terrific and highly successful end-user authoring system whose media was scripted, WYSIWYG, and “symmetric” (in the sense that the “reader” could turn around and “author” in the same high-level terms and forms). It should be the start of — and the guide for — the “User Experience” of encountering and dealing with web content.
>"The underlying system for a browser should not be that of an “app” but of an Operating System whose job would be to protectively and safely run encapsulated systems (i.e. “real objects”) gotten from the web. It should be the way that web content could be open-ended, and not tied to functional subsets in the browser." -Alan Kay
>[...] This work is so good — for any time — and especially for its time — that I don’t want to sully it with any criticisms in the same reply that contains this praise.
>I will confess to not knowing about most of this work until your comments here — and this lack of knowledge was a minus in a number of ways wrt some of the work that we did at Viewpoints since ca 2000.
>(Separate reply) My only real regret about this terrific work is that your group missed the significance for personal computing of the design of Hypertalk in Hypercard.
>It’s not even that Hypertalk is the very best possible way to solve the problems and goals it took on — hard to say one way or another — but I think it is the best example ever actually done and given to millions of end users. And by quite a distance.
>Dan Winkler and Bill Atkinson violated a lot of important principles of “good programming language design”, but they achieved the first overall system in which end-users “could see their own faces”, and could do many projects, and learn as they went.
>For many reasons, a second pass at the end-user programming problem — that takes advantage of what was learned from Hypercard and Hypertalk — has never been done (AFAIK). The Etoys system in Squeak Smalltalk in the early 2000s was very successful, but the design was purposely limited to 8–11 year olds (in part because of constraints from working at Disney).
>It’s i...
The earliest Flash projects were these artful assemblages of scripts dangling from nested timelines, like an Alexander Calder mobile. They were at times labyrinthine, like they are in many similar tools, but there were ways to mitigate that. Later on, AS3 code was sometimes written like Java, because we wanted to be taken seriously.
Many Flash community members wanted to share their source, wanted a space where interested people could make changes. We did the best we could, uploading FLA files and zipped project directories. None of it turned out to be especially resilient.
It's one of the things I admire about Scratch. If you want, you can peek inside, and it's all there, for you to learn from and build off of, with virtually no arbitrary barriers in place.
This is what kids do to be creative.
Slightly more serious (and therefore less succesful): - Logo/Turtle Graphics - Scratch - HyperStudio
HyperCard was both graphic design and hypertext (links). These two modalities got separated, and I think there are practical reasons for that. Because html/css design actually sucks and never became an amateur art form.
For writing and publishing we got Wiki, Obsidian et al, Blogs (RIP), forums, social media. Not meant to be interactive or programmable, but these fulfill people's needs for publishing.
I had to drop into BlockSCAD to rough out an arc algorithm for my current project:
https://github.com/WillAdams/gcodepreview
(see the subsubsection "Arcs for toolpaths and DXFs")
Jupyter Notebooks come close to allowing a seamless blending of text and algorithm, but they are sorely missing on the graphic design and vector graphics front --- which now that I write that, makes me realize that that is the big thing which I miss when trying to use them. Makes me wish for JuMP, a Jupyter Notebook which incorporates METAPOST --- if it also had an interactive drawing mode, it would be perfect.... (for my needs).
https://pontus.granstrom.me/scrappy/
LLMs inspired vibe coding - that’s our timeline.
(More seriously: I can still recall using ResEdit to hack a custom FONT resource into a HyperCard stack, then using string manipulation in a text field to create tiled graphics. This performed much better than button icons or any other approach I could find. And then it stopped working in System 7.)
- watch
- busy
- hand
- arrow
- iBeam
- cross
- plus
> auto | crosshair | default | pointer | move | e-resize | ne-resize | nw-resize | n-resize | se-resize | sw-resize | s-resize | w-resize| text | wait | help | <url>
https://www.w3.org/TR/WD-CSS2-971104/ui.html
Look up hyperland, it's a early 90s documentary by Douglas Adams and the guy from doctor who about the then-future hypermedia revolution. I can remember the web resembling that a long time ago but the modern web is very far removed from anything remotely resembling hypertext.
https://www.goodreads.com/book/show/192405005-hypermedia-sys...
which maybe argues for a return to early ideas of the web as a successor to Hypercard...
But I'm glad to see I'm not the only one who misses the old web when it really was all about exchanging ideas and information over open protocols. I will never get over this massive sense of nostalgia whenever I remember browsing through weird groceries fan sites and seeing people just documenting their love for whatever hobbies they had and the platforms weren't always pushing political BS to "drive engagement" by making me angry.
DonHopkins on Feb 10, 2020 | parent | context | favorite | on: HyperCard: What Could Have Been (2002)
Do you have the first commercial HyperCard stack ever released: the HyperCard SmutStack? Or SmutStack II, the Carnal Knowledge Navigator, both by Chuck Farnham? SmutStack was the first commercial HyperCard product available at rollout, released two weeks before HyperCard went public at a MacWorld Expo, cost $15, and made a lot of money (according to Chuck). SmutStack 2, the Carnal Knowledge Navigator, had every type of sexual adventure you could imagine in it, including information about gays, lesbians, transgendered, HIV, safer sex, etc. Chuck was also the marketing guy for Mac Playmate, which got him on Geraldo, and sued by Playboy.
https://www.zdnet.com/article/could-the-ios-app-be-the-21st-...
>Smut Stack. One of the first commercial stacks available at the launch of HyperCard was Smut Stack, a hilarious collection (if you were in sixth grade) of somewhat naughty images that would make joke, present a popup image, or a fart sound when the viewer clicked on them. The author was Chuck Farnham of Chuck's Weird World fame.
>How did he do it? After all, HyperCard was a major secret down at Cupertino, even at that time before the wall of silence went up around Apple.
>It seems that Farnham was walking around the San Jose flea market in the spring of 1987 and spotted a couple of used Macs for sale. He was told that they were broken. Carting them home, he got them running and discovered several early builds of HyperCard as well as its programming environment. Fooling around with the program, he was able to build the Smut Stack, which sold out at the Boston Macworld Expo, being one of the only commercial stacks available at the show.
https://archive.org/stream/MacWorld_9008_August_1990/MacWorl...
Page 69 of https://archive.org/stream/MacWorld_9008_August_1990
>Famham's Choice
>This staunch defender was none other than Chuck Farnham, whom readers of this column will remember as the self-appointed gadfly known for rooting around in Apple’s trash cans. One of Farnham ’s myriad enterprises is Digital Deviations, whose products include the infamous SmutStack, the Carnal Knowledge Navigator, and the multiple-disk set Sounds of Susan. The last comes in two versions: a $15 disk of generic sex noises and, for $10 more, a personalized version in which the talented Susan moans and groans using your name. I am not making this up.
>Farnham is frank about his participation in the Macintosh smut trade. “The problem with porno is generic,” he says, sounding for the briefest moment like Oliver Wendell Holmes. “When you do it, you have to make a commitment ... say you did it and say it’s yours. Most people would not stand up in front of God and country and say, ‘It’s mine.’ I don’t mind being called Mr. Scum Bag.”
>On the other hand, he admits cheerily, “There’s a huge market for sex stuff.” This despite the lack of true eroticism. “It’s a novelty,” says Farnham. Sort of the software equivalent of those ballpoint pens with the picture of a woman with a disappearing bikini.
https://archive.org/stream/NewComputerExpress110/NewComputer...
Page 18 of al_borland ↗ I actually had an experience like this yesterday. After reading Gruber talk about how Markdown was never meant for notes, I started to rethink things. I wanted plain text, to be future proof, then stumbled across CotEditor as a means to edit. Inside I was able to use the code highlighting and outline config to define my own regex and effectively create my own markup language with just a dash of regex and nothing more. I then jumped over to Shortcuts and dragged and dropped some stuff together to open/create yearly and daily notes (on either my computer or phone), or append to a log with a quick action. garyrob ↗ "In an alternate timeline, HyperCard was not allowed to wither and die, but instead continued to mature, embraced the web..." jandrese ↗ On one hand this would be simply amazing, on the other hand it would have been a total security nightmare that makes early Javascript look like a TPM Secure Enclave. duskwuff ↗ Those who were there will remember:
(And now I'm curious if this post will trip anyone's antivirus software...) moffkalast ↗ Looking at the HyperTalk syntax [0] it's interesting how we take left hand variable assignment as a given while math typically teaches the exact opposite since you can't really write the answer before you have the question. jjcob ↗ We kind of had that for a time with FileMaker and MS Access. People could build pretty amazing stuff with those apps, even without being a programmer. crucialfelix ↗ Yes! I used FileMaker a lot, and built my first journaling system with it. Like a cross between hypercard and a wiki. It really changed my life and this lead to programming. specialist ↗ Yes. They didn't survive the transition from workgroup (shared files on a LAN) to client/server. skeeter2020 ↗ the stuff I made in Access (and later Excel) looks a lot like the stuff I generate with AI these days! asnyder ↗ His legacy still exists and continues today. Even updated to modern sensibilities, cross-platform, and compatible with all your legacy Hypercard stacks! mort96 ↗ This seems like something completely different? Livecode looks like just another toolkit or SDK for developing standalone apps, which might be great for the handful of developers using it but certainly doesn't do anything to re-shape how users interact with their computers asnyder ↗ Nope, is completely the same base. Scroll the homepage, and you'll see an example of Livecode (updated HyperTalk). mort96 ↗ And how exactly does this re-shape the user's (not developer's) relationship with their computer? pazimzadeh ↗ it says "GUI coding built in" mort96 ↗ Can you elaborate on how that answers my question? jostylr ↗ There is hypersrcipt: https://hyperscript.org which claims a descent from hypercard and certainly embraces the web.
It is a custom system that didn’t require any code (if you don’t count the very minor bits of regex (just a lot of stuff like… ^\s- .).
Is it a good system, probably not, but we’ll see where it goes.
In yet another alternate timeline, someone thought to add something like URLs with something like GET, PUT, etc. to HyperCard, and Tim Berners-Lee's invention of the Web browser never happened because Hypercard already did it all.
Makes you think if lambda expressions would be more consistent with the rest if they were reversed.
[0] https://en.wikipedia.org/wiki/HyperTalk#Fundamental_operatio...
I think the reason those apps never became mainstream is that they didn't have a good solution for sharing data. There were some ways you could use them to access database servers, but setting them up was so difficult that they were for all intents and purposes limited to local, single user programs.
HTML, CSS, PHP and MySQL had a learning curve, but you could easily make multi-user programs with them. That's why the web won.
As far as I remember, progression was Hypercard -> Metacard -> Runtime Revolution -> Livecode.
https://livecode.com
I was a kid when this progression first happened, my older brother Tuviah Snyder (now at Apple), was responsible for much of these updates and changes first at Metacard and then at its acquirer Runtime Revolution.
I even wrote some of my first programs as Hypercard compatible stacks. Was quite fun to see my apps on download.com, back in the day when that meant something :).
I always joked it required please and thank you due to its verbosity, but was super simple, accessible, and worked!
How nice, that even today one can take their legacy Hypercard Stacks and run them in the web, mobile, etc. Or create something new in what was more structured vibecoding before vibecoding :).
You can open your HyperCard stacks, or MetaCard stacks, or Runtime/Livecode Stacks in their IDE, code, edit, etc, similar to what you would have back in Hypercard days, but with modern features, updates, and additions.
It's backwards compatible with HyperTalk, its current language is an updated HyperTalk (i.e. an updated MetaTalk), that incorporates all that was, but adds new features for today.
Your Livecode apps can be deployed and run as cross-platform desktop applications (Mac, Win, *nix) , mobile applications, and as far as I remember, web applications with HTML5 deployment (so they say).
Not affiliated with them in any way, just sharing my understanding and memories.
Also, this might happen in a few years if AI improves enough to be trusted to make things by novices. Hard to imagine, but just maybe.
Why isn't the black bar up atop the site?
This post is only an hour old as I’m writing this, so give it time. It’s a weekend, and as far as I’m aware there are only 2 mods, unless there are others empowered to turn on the black bar in their absence.
And some people with no resources, no reason to live, but have incredible genetics will linger for many years beyond what people think is possible, like a weed.
“A 60-year-old male in the US can expect to live until about age 82”
Pancreatic cancer usually is hard to detect until it’s reached an advanced stage. We really should invest more into research
You don't know for how long he did have that disease, if anything, resources might have afforded him many more years of life at first place.So your comment strikes me as odd, given the fact that you can't judge how long did he live with such disease.
One of my friend's dad died from the same kind of cancer. Between the diagnosis and their death, 2 months passed, and that person had plenty of "resources"...
It happened during a family reunion for Christmas, so at least everyone was present.
https://youtu.be/ji5_MqicxSo?si=TlgWzgQ7bD3Usvu3
https://www.nytimes.com/2018/03/26/lens/the-superfund-sites-...
> One of Bill Atkinson’s amazing feats (which we are so accustomed to nowadays that we rarely marvel at it) was to allow the windows on a screen to overlap so that the “top” one clipped into the ones “below” it. Atkinson made it possible to move these windows around, just like shuffling papers on a desk, with those below becoming visible or hidden as you moved the top ones. Of course, on a computer screen there are no layers of pixels underneath the pixels that you see, so there are no windows actually lurking underneath the ones that appear to be on top. To create the illusion of overlapping windows requires complex coding that involves what are called “regions.” Atkinson pushed himself to make this trick work because he thought he had seen this capability during his visit to Xerox PARC. In fact the folks at PARC had never accomplished it, and they later told him they were amazed that he had done so. “I got a feeling for the empowering aspect of naïveté”, Atkinson said. “Because I didn’t know it couldn’t be done, I was enabled to do it.” He was working so hard that one morning, in a daze, he drove his Corvette into a parked truck and nearly killed himself. Jobs immediately drove to the hospital to see him. “We were pretty worried about you”, he said when Atkinson regained consciousness. Atkinson gave him a pained smile and replied, “Don’t worry, I still remember regions.”
He said they drew a lot of inspiration from Woz on the hardware side. Woz was well known for employing lots of little hacks to make things more efficient, and the Macintosh team had to apply the same approach to software.
My guess is it asks each application that overlapped those areas to redraw only those areas (in case the app is able to be smart about redrawing incrementally), and also clips the following redraw so that any draw operations issued by the app can be "culled". If an app isn't smart and just redraws everything, the clipping can still eliminate a lot of the draw calls.
The very characteristic horizontally stretched graphics of the Atari 2600 are due to this - the CPU was actually too slow, in a sense, for the electron beam which means your horizontal graphic elements had a fairly large minimum width - you couldn't change the output fast enough.
I strongly recommend:
https://en.wikipedia.org/wiki/Racing_the_Beam
... which goes into great detail on this topic and is one of my favorite books.
Per-pixel sorting while racing the beam is tricky, game consoles usually did it by limiting the number of objects (sprites) per-line, and fetching+caching them before the line is reached.
There was a discussion here a couple of weeks ago (with a typo in the title): https://news.ycombinator.com/item?id=44110219
The Smalltalk-76 MVC user interface that the Apple people saw only ever updated the topmost window which, by definition, was not clipped by any other window. If you brought some other window to the front it would only then be updated. But since nothing ran in the background it was easy to get the wrong impression that the partially visible windows were being handled.
Bill's solution had two parts: one was regions, as several other people have explained. It allowed drawing to a background window even while clipping to any overlapping windows that are closer. But the second was PICTs, where applications did not directly draw to their windows but instead created a structure (could be a file) with a list of drawing commands which was then passed to the operating system for the actual drawing. You could do something like "open PICT, fill background with grey pattern, draw white oval, draw black rectangle, close PICT". Now if the window was moved the OS could recalculate all the regions of the new configuration and re-execute all the PICTs to update any newly exposed areas. If the application chose to instead draw its own pixels (a game, for example) then the OS would insert a warning into the app's event queue that it should fix its window contents.
In parallel with Bill's work (perhaps a little before it) we had Rob Pike's Blit terminal (commercially released in 1982) which added windows to Unix machines. It had the equivalent of regions (less compact, however) but used a per window buffer so the terminal would have where to copy newly exposed pixels from.
But that's not a recipe for personal happiness for most people, and most of us would not end up contributing revolutionary improvements even if done so. World needs awesome workers, and we also need ie awesome parents or just happy balanced content people (or at least some part of those).
Naturally I don’t expect to do such things for a living.
And I don't think anyone said that that's the only way to be
Some people are competing, and need to make things happen that can’t be done when you check out at 5. Or more generally: the behaviour that achieves the best outcome for a given time and place, is what succeeds and forms the legends of those companies.
If you choose one path, know your competitors are testing the other paths. You succeed or fail partly based on what your most extreme competitors are willing to do, sometimes with some filters for legality and morality. (I.e. not universally true for all countries or times.)
Edit: I currently go home at 5, but have also been the person who actually won the has-no-life award. It’s a continuum, and is context specific. Both are right and sometimes one is necessary.
Windows partly obscured would have rows that may not begin at 0, may not continue to width-of-window. Window regions could even have holes if a skinnier window was on top and within the width of the larger background window.
The cleverness, I think, was then to write fast routines to add, subtract, intersect, and union regions, and rectangles of this structure. Never mind quickly traversing them, clipping to them, etc.
https://github.com/historicalsource/supermario/blob/9dd3c4be...
As far as I can tell, it's a bounding box (in typical L/T/R/B format), followed by a sequence of the X/Y coordinates of every "corner" inside the region. It's fairly compact for most region shapes which arise from overlapping rectangular windows, and very fast to perform hit tests on.
Reminds me of the story where some company was making a new VGA card, and it was rumored a rival company had implemented a buffer of some sort in their card. When both cards came out the rival had either not actually implemented it or implemented a far simpler solution
Former Ion Storm employees later revealed that Dominion’s E3 1996 demo was pre-rendered, with actors pretending to play, not live gameplay.
(for ref, diablo III is also in my top 3 :)
I teach this lesson to my mentees. Knowing that something is possible gives you significant information. Also, don't brag - It gives away significant information.
Just knowing something is possible makes it much, much easier to achieve.
https://valvedev.info/archives/abrash/abrash.pdf
This isn't really stupid though as explained in the pdf
> Paradise had stuck a read FIFO between display memory and the video output stage of the VGA, allowing the video output to read ahead, so that when the CPU wanted to access display memory, pixels could come from the FIFO while the CPU was serviced immediately. That did indeed help performance--but not as much as Tom’s write FIFO.
VRAM accesses are contended, so during the visual display period the VGA circuitry has priority. CPU accesses result in wait states - a FIFO between the VRAM and the VGA means less contention and more cycles for CPU accesses
Why improve read performance though? Games accessing VRAM I presume would be 99% write. Perhaps it was to improve performance in GUIs like Windows?
It’s on all of us to keep the history of this field alive and honor the people who made it all possible. So if anyone would nerd out on this, I’d love to be able to remember him that way.
(I did read this https://www.folklore.org/I_Still_Remember_Regions.html but might be not understanding it fully)
Back at the time, there wouldn't be enough memory to hold a copy of the full contents all possible windows. In fact, there were actually zero abstraction layers: each application was responsible to draw itself directly into the framebuffer (array of pixels), into its correct position. So how to handle overlapping windows? How could each application draw itself on the screen, but only on the pixels not covered by other windows?
QuickDraw (the graphics API written by Atkinson) contained this data structure called "region" which basically represent a "set of pixels", like a mask. And QuickDraw drawing primitives (eg: text) supported clipping to a region. So each application had a region instance representing all visible pixels of the window at any given time; the application would then clip all its drawing to the region, so that only the visibile pixels would get updated.
But how was the region implemented? Obviously it could have not been a mask of pixels (as in, a bitmask) as it would use too much RAM and would be slow to update. In fact, think that the region datastructure had to be quick at doing also operations like intersections, unions, etc. as the operating system had to update the regions for each window as windows got dragged around by the mouse.
So the region was implemented as a bounding box plus a list of visible horizontal spans (I think, I don't know exactly the details). When you represent a list of spans, a common hack is to use simply a list of coordinates that represent the coordinates at which the "state" switches between "inside the span" to "outside the span". This approach makes it for some nice tricks when doing operations like intersections.
Hope this answers the question. I'm fuzzy on many details so there might be several mistakes in this comment (and I apologize in advance) but the overall answer should be good enough to highlight the differences compared to what computers to today.
> Obviously it could have not been a mask of pixels
To be more specific about your explanation of too much memory: many early GUIs were 1 bit-per-pixel, so the bitmask would use the same amount of memory as the window contents.
There was another advantage to the complexity of only drawing regions: the OS could tell the application when a region was exposed, so you only had to redraw a region if it was exposed and needed an update or it was just exposed. Unless you were doing something complex and could justify buffering the results, you were probably re-rendering it. (At least that is my recollections from making a Mandelbrot fractal program for a compact Mac, several decades back.)
The source code describes it as "an unpacked array of sorted inversion points". If you can read 68k assembly, here's the implementation of PtInRgn:
https://github.com/historicalsource/supermario/blob/9dd3c4be...
It’s a sorted list of X coordinates (left to right). If you group them in couples, they are begin/end intervals of pixels within region (visibles), but it’s actually more useful to manipulate them as a flat array, as I described.
I studied a bit the code and each scanline is prefixed by the Y coordinates, and uses an out of bounds terminator (32767).
There's no such guarantee. The NEXTHOR loop only inverts for points which are to the absolute left of the point being tested ("IS HORIZ <= PT.H ? \\ NO, IGNORE THIS POINT").
Imagine that, for every point, there's a line of inversion that goes all the way down to the bottom of the bounding box. For a typical rectangular region, there's going to be four inversion points - one for each corner of the rectangle. The ones on the bottom cancel out the ones on the top. To add a second disjoint rectangle to the region, you'd simply include its four points as well; so long as the regions don't actually overlap, there's no need to keep track of whether they share any scan lines.
Also, perhaps the General Magic documentary is a fun watch too: https://youtu.be/JQymn5flcek
An unthinkable future, but they thought it. And yet, most folks have never heard of General Magic.
0. https://www.youtube.com/watch?v=JQymn5flcek
Also, it's here in the documentary that someone expresses the excitement anticipating the smart phone. It's hard to watch for me now and not shake my head, "Oh, it's not quite as wonderful as you imagined."
Bill on Steve Jobs and HyperCard:
https://youtu.be/kzKCZN3UsRQ?si=eNIsysWdrjp2tHwd
Black bar, please.
RIP Mr Bill Atkinson
I'm yet another child of HyperCard. It opened my mind to what computers could be for, and even though the last two decades have been full primarily of disappointment, I still hold onto that other path as a possibility, or even as a slice of reality---a few weeds growing in the cracks of our dystopian concrete.
I knew who he was at the time, but for some reason I felt I was more or less beholden to conversing only about color-related issues and how they applied to a computer workflow. Having retired, I have been kicking myself for some time not just chatting with him about ... whatever.
He was at the time I met him very in to a kind of digital photography. My recollection was that he had a high-end drum scanner and was in fact scanning film negatives (medium format camera?) and then going with a digital workflow from that point on. I remember he was excited about the way that "darks" could be captured (with the scanner?). A straight analog workflow would, according to him, cause the darks to roll off (guessing the film was not the culprit then, perhaps the analog printing process).
He excitedly showed us on his computer photos he took along the Pacific ocean of large rock outcroppings against the ocean — pointing out the detail that you could see in the shadow of the rocks. He was putting together a coffee table book of his photos at the time.
I have to say that I mused at the time about a wealthy, retired, engineer who throws money at high end photo gear and suddenly thinks they're a photographer. I think I was weighing his "technical" approach to photography vs. a strictly artistic one. Although, having learned more about Ansel Adams technical chops, perhaps for the best photographers there is overlap.
I think this says more about you than it does about him
Power tools definitely have it!
https://news.ycombinator.com/newsguidelines.html
I was about to argue but then I saw this part
> The cost outweighs any benefit.
And this is absolutely true - there is a benefit but it doesn’t mean it’s worth it
Either way my bad, I should have elaborated and been more gentle instead of just that quip
I was though being honest about how I felt at that time — debated whether to keep it to myself or not today (but I always foolishly error on the side of being forthcoming).
Perhaps it's a strange thing to imagine that someone would pursue in their spare time, especially after retired, what they did professionally.
But the irony isn’t lost on me that I myself shouldn’t have been so mean about it
Seems that, without the color/Bayer thing, you could get an extra stop or two for low-light.
I had a crazy notion to make a camera around an astronomical CCD (often monochrome) but they're not cheap either — at least one with a good pixel count.
Comparisons and advantages: https://www.photigy.com/school/sigma-foveon-sensor-review-dp...
For black and white photography, the best high-end camera seemed to be the Leica M Monochrom (https://en.wikipedia.org/wiki/Leica_M_Monochrom), but to my mind, it's trounced by the Foveon:
https://youtu.be/OODMWXX_N7A
https://www.stevehuffphoto.com/2013/01/14/quick-comparison-l...
THIS is the photo that really sold it for me:
https://www.fredmiranda.com/forum/topic/1806915/0&year=2023#...
That's from a modified DP1m, but the SD Quattro H has an easily-removable IR filter and a huge sensor.
Sometimes it’s just nice to talk about the progress of humanity. Nothing better than being a part of it, the gears that make the world turn.
I adore this hybrid workflow, because I can pick how the photo will look, color palate, grain, whatever by picking my film, then I can use digital to fix (most if not all of) the inherent limitations in analog film.
Sadly, film is too much of a pain today, photography has long been about composition for me, not cameras or process - I liked film because I got a consistent result, but I can use digital too, and I do today.
Maybe I should show some initiative! See, for a little while now I've wanted to just chat with you about whatever.
At this moment I'm working on a little research project about the advent of color on the Macintosh, specifically the color picker. Would you be interested in a casual convo that touches on that? If so, I can create a BlueSky account and reach out to you over there. :)
https://merveilles.town/deck/@rezmason/114586460712518867
Did you ever get hit with a paper airplane as you did? ;)
Thanks for this reply, and if you're who I think you are, thank you for all the good work you did alongside these other folks :D
Hilariously though, I did get handed the color pickers to "port" to PowerPC. In fact one of the first times I thought I was in over my head being at Apple was when I was staring at 68030 assembly and thinking, "Fuck, I have to rewrite this in C perhaps."
From your username, I feel like we've chatted before (but I don't know your real name).
Duchamp would like a word.
Seriously though, as someone this describes to a T (though “suddenly” in this case is about 19 years), I was afraid to call myself any sort of artist for well over a decade, thinking I was just acquiring signal with high end gear. I didn’t want to try to present myself as something I’m not. After all, I just push the button, the camera does all the work.
I now have come to realize that this attitude is toxic and unnecessary. Art (even bad art!) doesn’t need more gatekeeping or gatekeepers.
I am a visual artist. A visual artist with perhaps better equipment than my skill level or talent justifies, but a visual artist nonetheless.
Thanks for everything, Bill — Rest in Peace.