The True Cost of Rewrites - <AUTHOR> https://8thlight.com/blog/doug-bradbury/2018/11/27/true-cost-rewrites.html <comment><USER2> I see a lot of fear of rewrites in the comments. Naturally, someone has posted that daft Spolsky article about how Netscape staying with the disastrous Navigator 4 codebase would somehow have been a good idea. Rewrites are one of the classic bogeymen in software.

So i just want to tell you that i've done successful rewrites!

The biggest was rewriting the e-commerce site of a well-known toy company. They had a homegrown site written in .NET, and we rewrote it on top of a commercial e-commerce framework in Java. It took a couple of years, the rewrite team was 2-5 times the size of the team that built the old site, and the client ended up with all the features of the old site, plus internationalisation, plus thorough automated tests and deployment. They seemed to be really happy with it.

The smallest was a data-aggregation server my team uses. It was written in Node, and kept crashing under load. I rewrote it in Java. It was just me, and it took a week or two. It hasn't crashed since, and we've been able to add loads more features.

Success factors in both: putting effort into thoroughly understanding the old thing; resisting any temptation to add new features unless you are exceptionally confident in how much more work it will take; thoroughly testing what you build as you go.

<comment><USER3> Everyone has done "successful" rewrites. But a rewrite that takes 2 years and requires a team much larger than the original team isn't successful in the eyes of most stakeholders and is almost NEVER what the dev team proposes as the timeline. Just because something got done eventually at great cost doesn't make it successful.

<comment><USER4> Our team is doing a slow replacement of code written in Java to node. At almost every turn we find that the replaced code is 50 to 80 percent smaller and much easier to read. We're doing it slow because we are phasing in new features at the same time to make sure stakeholders get value while we do it. It's been tremendously successful and cost effective keeping the old and the new running simultaneously.

<comment><USER5> Awesome results! Is the new code smaller due to the different programming language (JS) or a better understanding of the program's requirements?

<comment><USER4> Sadly just converting poorly written code that doesn't use re-use mostly. Other than that, we're using multiple typescript frameworks for data wrangling and transport and validation without having to re-define objects as DTOs, Models, etc... And taking advantage of graphql has been, massively helpful.

</comment></comment></comment></comment></comment><comment><USER6> There is a trick to rewrites: start by writing a full suite of end to end tests. Once done you'll discover that you can easily stabilize your old code and make changes with this security harness. You may discover that you don't really need to rewrite anything.

If you have to maintain untested code I recommend you get yourself a copy of "working effectively with legacy code" as it is mostly a list of recipes on how to add tests to a codebase. I also recommend it to anyone starting to write something new so they can learn what is useful to test.

Forget about unit testing and start working on end-to-end tests. Selenium, Sikuli, Codeception, Wiremock, siege are the kind of tools you want more than whateverUnit. Test your applications at the UI level. Test its performances. Your client does not care about your design pattern usage: they want something which respect their specifications.

<comment><USER7> Tests fossilize a design. This is generally a good thing and allow you to focus on refactoring and bug fixes with some confidence that you won't break anything. It's also especially good for products that must adhere to specific interface or API.

But when you want to re-write the last thing you want is to fossilize your design. You explicitly don't want the same system you started with otherwise it wouldn't be a rewrite, It would be a refactoring.

<comment><USER8> This isn't necessarily the case. In my experience, the teams that want rewrites have built big monoliths with no design, lots of coupling, and lots of copy-and-paste code (basically a 'big ball of mud'). So, what the rewrite does is introduce an architecture that decouples (often valuable) functionality into small, targeted functions and libraries. This enables easier maintenance and modification. It also fixes the brittleness and fragility.

So, the goal isn't to keep the monolith as is. Instead, it's to break up its functionality into small parts. Then, the parts may be joined so that the old interfaces work as they did before. But, they may also be used to build entirely new interfaces.

</comment></comment></comment><comment><USER9> A good rewrite is done bit-by-bit releasing the rewritten work immediately. This forces you to focus on deliverable chunks rather than code-for- code's-sake and to test your assumptions instantly. If you do not release your work there is a very large chance that it will all be for nothing.

A good rewrite happens so subtly that end-users and operators will never really realize that a rewrite is underway.

There are only very rare cases where a rewrite in big-bang fashion is indicated and even then the bulk of those will be incompetence on the part of the tech crew because they see no way to turn the job into an incremental one (or do not want to see a way).

<comment><USER10> Incremental rewrite isn't a rewrite at all. It is the better choice though. It is worth noting that refactoring and improving an area of the code without a need to change it or build new features on it is also wasteful.

<comment><USER11> Your comment is great except for the first sentence. Maybe you could elaborate on what you mean, but of course an incremental rewrite is a rewrite. All rewrites are incremental, the proposal is to choose the order of increments of a system rewrite such that it is fully working both before and after each increment, rather than start from scratch and wait to find out if the full system will work until and have feature parity after all increments are complete. I'd guess you already knew that, and just have a notion that the word "rewrite" means it needs to be from scratch and all at once for some reason?

<comment><USER10> I'm just trying to be absolute on the fact that incremental change of a single running system is more efficient and shouldn't be confused with 'rewrite' projects where a second system, that is not used by the business yet, is developed while the business continue to use the 'old' one.

Calling incremental improvement a form of rewrite gives it a bad name :)

I'd argue that rewrites that are a second system that (hopefully) eventually get deployed once the features exceed current system is not incremental at all, but is instead Big Bang.

Even if the features of second system are built incrementally, if the business aren't using it until it is finished then it is Big Bang.

</comment></comment></comment></comment><comment><USER12> I've seen 2 non-trivial rewrites of the mainline software at 2 companies. Non- trivial = 10-100M in yearly revenue.

In both cases:

\- it was promised to take 6-9 months, and ended up taking 3-4 years

\- it never really finished, the old software had to remain in production (along with the new "rewrite")

\- in some form or the other, while the rewrite was happening, the company lost its customer focus and/or its ability to innovate

\- good people left

Instead of rewrites, make incremental changes. The eng. team should never be off doing its own thing.

Also, a good lesson from Facebook: instead of rewriting their PHP codebase, they extended the language by creating the "PHP++" language Hack (along with the HHVM runtime), and incrementally changed their codebase to take advantage of Hack:

[http://bytepawn.com/hack-hhvm-second-system- effect.html](http://bytepawn.com/hack-hhvm-second-system-effect.html)

<comment><USER13> > Also, a good lesson from Facebook: instead of rewriting their PHP codebase, > they extended the language by creating the "PHP++" language Hack (along with > the HHVM runtime), and incrementally changed their codebase to take > advantage of Hack

I agree with most of your comment, but I don't think this part generalizes. This isn't feasible for most companies unless you're operating at Facebook scale.

<comment><USER12> I agree it doesn't generalize, but I don't agree that it's because of "scale". It doesn't generalize because not every company should write its own language (and can't hire good enough engineers for this). And, fortunately, most "legacy" codebases aren't in "bad" languages, so there's no need for this.

Afaik, the team that did Hack/HHVM at Facebook is ~5 people. I don't think you need scale for this (the rewrite of the code itself is not a scale thing, the codebase is usually linear-ish in the number of engineers).

My point is: instead of doing a rewrite, be inventive and avoid it, and this is a great example.

<comment><USER14> What Facebook did amounts to rewriting PHP itself though.

</comment></comment></comment></comment><comment><USER15> I specialize in fixing bad software projects typically taking a role of principal developer/architect. Over nearly 20 years of my experience every rewrite I took part in failed by either not delivering the improvements, by causing a lot of unplanned headaches for the business or by wildly missing all planned deadlines and cost estimates.

On the other hand couple of years back I started purposefully taking up projects in bad shape and fixing them by cutting discussions about rewrites and instead focusing on putting work where it matters -- diagnosing the problems and finding solutions to them.

I found that most of the teams I met stopped or indeed never really had any practice of constantly diagnosing and improving their process and application. This is usually the cause why the application is in bad shape but more frequently than not the team will blame the organization, predecessors or constraints like old technology they are working with. They channel their frustration by focusing on the idea of the rewrite which seems like a relief from the frustration of current codebase. Unfortunately, the rewrite is performed using the same process that failed the previous version with predictable results.

Think of a person that has messy house. This person does not have practice to keep things clean and in order. The person decides he/she will fix the issue by building another house and burning the old one with all belongings. The result is predictable.

The solution is to learn to keep things clean and in order instead of burning the old house and re-building it at great cost and effort.

<comment><USER16> I agree that in most cases it is the fault of an organization that problems were swept under the rug for far too long. There are cases were requirements changed so much over the years that architecture of system would no longer support the business without massive cost or overhead.

We have plenty of ideas on how to build new software: agile, TDD, DDD. It seems that there is no proven process for doing rewrites.

<comment><USER15> I would not say in most cases organization is to blame, I would say in most cases the blame is shared.

</comment></comment></comment><comment><USER17> There is a lot of advice here to do incremental rewrites, refactoring, unittesting, functional/system testing etc.

Undoubtfuly it is all mature and correct advise. However, I feel it is all one-sided and I ought to provide some counter points:

1\. The codebase in question may be well beyond the line where any sane person would touch it, seriously.

2\. Individuals experienced with the codebase, its structure, implementation, technology stack might be not available (think cobol).

3\. Refactoring or incremental rewrite is a process that has to be planned and managed s.t. current product/codebase structure. Oftencase it is this very structure, which demands the full rewrite -- because of it being too convoluted to allow refactoring to take place.

4\. You might want to do a rewrite to refresh the tech. stack -- language, design, frameworks -- it is ok to do so.

5\. You do not necessarily need to come with the same feature set. Both you and your customers might want to cut down unnecessary cruft. Technical debt usually starts to show its signs with losing flexibility w.r.t user request to change features.

6\. Occasionaly you might come up with a separate, different product, with a different name and brand -- which might turn out to be even better!

7\. You learn a lot in the process.

<comment><USER18> I think this is a pretty reasonable set of counter points, even if I don't agree with them.

Being part of team incremental rewrite, myself, I'd say that you're overestimating the cost of the incremental rewrite and underestimating the cost of the rewrite.

For your first 2 points especially, I'd argue if you can't even begin to incrementally rewrite a system, you're in no position to begin to plan a full rewrite.

<comment><USER17> It is mainly a matter of decision making. In my case, no refactoring was ever sanctioned by itself. Devs were having been allowed to refactor anything on a small scale and always backed up by a feature request. So when the desire to somehow "heal" the codebase is met, it is usually because it is already too "dead" to work with in the first place.

<comment><USER18> I'm not sure what you mean by your last sentence.

I'd say that if code is being used in production it's not yet "dead", and it should be a much higher priority for team members to work with it.

Can you not add additional tests? Refactor out even a single feature at a time into more modern tech?

</comment></comment></comment></comment><comment><USER19> Relevant, from 2000: [https://www.joelonsoftware.com/2000/04/06/things-you- should-...](https://www.joelonsoftware.com/2000/04/06/things-you-should-never- do-part-i/)

An interesting point: code is ( _probably_ ) not as ugly as it seems -- it just looks that way because you didn't write it. What looks like cruft is actually the accumulation of years of bug fixes and edge case handling.

<comment><USER20> ... or accumulation of hacky extra features not in orginal scope and architecture? In the beginning it might have been fine code, but not enough time have been allocated to do new features right.

Rewrites might be the wrong term. "Refactoring" is a better. If you already have functioning code you don't need to rewrite it, but fix the mess.

If you have undocumented legacy code that's a mess, and it doesn't work with new quite different requirements, it might be faster to just rewrite most parts and cherry pick code that seems to do edge catching stuff and opaque interfacing with other black box systems.

I aim at spending half my time refactoring and documenting, so I'll in reality end up with at-least some time. Random Company average I have been at is probably around 0.1%.

<comment><USER21> There's a very big difference between refactoring and rewriting, IMHO. As you say, with rewriting you're throwing away functional code whereas with refactoring you're shifting it around.

Both have their place but refactoring happens regularly whereas rewriting is a more drastic option that should be used only when absolutely necessary. Having a robust test suite is very important with rewrites to prevent regressions.

</comment></comment></comment><comment><USER22> To me the biggest issue with re-writes is it tends to be Engineering working in a vacuum without business input. What that tends leads to is "blind" 1-to-1 reimplementation of features without reflection on which features are _still_ bringing business value e.g. if most of your user base transitioned to mobile, is it really worth reimplementing all things that were built with users IE on Windows in mind?

Or put another way, the place where you can save a ton of effort in a rewrite and increase your chances of success is in throwing stuff away, but you usually need more than just the engineering team to achieve that.

<comment><USER23> Oddly enough, my experience is that when IT asks Business "can we finally drop support for feature X? We are pretty sure that Roman Numerals are not used anymore for budget reports..." the answer is "I am not sure, maybe it will become useful again in a year or two. Let it alone".

<comment><USER24> You haven't communicated the cost. To the business manager it's essentially free to leave it in - so why not keep the optionality.

If you could estimate "keeping feature X costs $200,000 per year in added development time" it would be an easy decision. Through this process of cost estimating you may find that while annoying it only costs $10,000. Any ill will generated from removing it would cost more than that so it should be left alone.

<comment><USER23> This has never worked. The project has a maintenance budget that covers everything (bug fixing, new features, migration to new versions of OS, DB etc.). Business requires a certain number of enhancements, the development team is already understaffed and therefore they are often missing the required number of enhancements in a specific release cycle.

So the full discussion goes something like this: _" Can we remove support for Roman Numerals? We are pretty sure nobody uses these anymore, and we estimate that this would cost 20 man/days in this release but result in a saving of 800 man days over the fiscal year..."_

 _" Not sure, it could be useful again, use these 20 days to add support for Aztec calendar to the Insurance reports - you have already postponed this twice!"_

(I.e. they get the impression that somehow there are 20 "extra" days available and those have to be diverted to implements something that may have become already obsolete).

<comment><USER24> Never lead a sales pitch with the price tag, always with the benefit.

The conversation shouldn't be about it costing 20 days to remove something. It should be about the net savings from doing so.

"Removing rarely used feature XYZ will open up 780 man-days of schedule time this year for new features by improving our efficiency"

<comment><USER23> I am working on a legacy application which brings in 90% of the revenue of the company (imagine something managing bookings for an hotel chain: of course we get also revenue for what guests pay during the stay, and maybe for cups, pens, and bathrobes with our logo, but the vast majority comes from the bookings, of course).

As such, every different part of the business may request changes/enhancements - our team provides these to lots of different "business departments" across the whole company.

Again, imagine a hotel chain with hotels all over the world, each national branch may require specific changes due to local laws and regulations, or because they need to start a new incentive campaign or participate in a joint venture with a flight company or whatever.

There is one application, and N different (competing) "customers" each one considering only their own specific plans and priorities. (In case of conflicts, the pecking order will be used to solve who gets more attention: biggest hotels, or hotels in regions that bring more revenue have more "clout").

Now, when I say "we have to postpone your request for X in order to recoup 780 more days later" the guy in front of me will immediately conclude that he will not necessarily get a bigger share of these 780 days - he will have to fight for his piece just as strenuously as before, and in any case this will happen maybe in three months, and he needs his stuff _yesterday_ \- so he better insist to have his own specific request included in the release, no matter if it costs 21 days, 20 days, 5 days: he wants this to be done because the rest of his business needs it for a specific date, and everything else is just a way for IT to postpone his request once again.

In other words: everybody wants their own specific request implemented as soon as possible, and anything else has absolutely zero interest for them. Especially if it is some promise of future "gains" from guys who are constantly late.

In my experience, this is not so uncommon when you work on an app that has been developed internally (and so there is no unified marketing department which represents a single stakeholder) - note also that precisely because we have to work for a myriad different "internal customers" we tend to accumulate "technical debt" at a faster rate: there is only one codebase, and has to accommodate all these pesky requirements from all over the world...

<comment><USER24> If you have multiple teams competing for features, it shouldn't be too hard to sell it that way.

"If we could open up 780 days on the schedule - what new features would you like?" At this point you want the client dreaming of all the extras they never thought they'd get to have.

Then at the end you mention the 20 day delay. At this point they will feel the "loss" of the new features they just imagined. It's an extremely powerful sales technique that works almost everywhere.

Given your earlier comments about the extra 20 days they seem particularly susceptible to this technique.

<comment><USER25> If you announce that you have 4 man years free for new tasks, in a team that may not even have 4 developers, after abandoning a feature that already existed and worked, you're delusional and so is the stakeholder if he believes it.

I agree on the principles nonetheless. You want clients to write a formal request for new features, then development has a backlog of requests and can prioritize them.

Clients might not like the prioritization but that's life, limited bandwidth, it's simple to show there is too much to do and not enough resources.

<comment><USER24> I'm using the numbers I was given as I'm not in a place to judge if they are realistic. Certainly if you make false promises no amount of sales techniques will save you in the long run.

<comment><USER23> The 200000 vs 10000 (and therefore the 20 vs. 780 man days) come straight from your example. Which is part of the problem: while I know for sure that are a lot of things that should be refactored/changed/improved/cut off it would be very difficult for me to give an estimate of "how much resources we save over the next year" \- as a simple example, I could revamp significantly the GUI (God knows how much it needs it)... and in the next six months I get 85% of the requests for changes having to do with business logic, financial batches running at the end of the month and stuff like that, maybe because there are new regulatory hurdles to clear like GDPR or The EU Travel Directive. Then the promised extra resources that would have become "available" fail to materialize, and the whole initiative is considered a failure. Good luck trying this again on the next year.

<comment><USER24> If you can't quantify the benefits then how do you know if it's worth doing?

Everyone else has to justify their programs with a cost/benefit analysis. I don't think software should be immune.

<comment><USER23> The benefit depends on what part of the system I decide to optimize. If I guess right (and enhance something impacted by many/big requirements _in the future_ ) I will reap good results. If I enhance something which stays basically untouched for the rest of the FY I will be considered a fraud or misguided.

Applications developed internally don't necessarily have a roadmap (or might have it and abandon it 2 weeks into the new year because). Problem is, nobody will consider you a hero for sticking to the (now obsolete) plan.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER26> I hate to criticize, but people need to know that this is a bad article. If I had to summarize the errors into three sentences, they'd be "You don't know how to write software so your software sucks. That means you won't know how to do a rewrite either. Here's some math I made up."

The simplest way I can show the error? If making a new piece of software is so expensive that it's far, far too expensive to do, how come folks enter the market everyday with new software which keeps replacing all of that stuff you think is irreplaceable? And they not only replace your stuff with better stuff, they do it at a fraction of the cost you take just keeping the lights on in your shop.

Math is not going to save you now. Looking at how fast features can be deployed is sticking your head in your ass. It's counting things for the purpose of counting them. It doesn't work like that. You may enjoy counting, sgraphing, and tracking points-per-sprint or feature-speed-per-team, but nobody buys or uses software based on feature count or team speed. It's not that these things aren't important. It's that you're confusing managing things with value creation.

I wrote an essay earlier this week about code budgets which I think can help a little by at least helping force conversations around the real issues involved. [http://tiny-giant- books.com/1.html?EntryId=rec39SaDeZCZjauRo](http://tiny-giant- books.com/1.html?EntryId=rec39SaDeZCZjauRo)

But the larger issue here is that organizations don't know how to create and harness value. They're really good at hiring, managing, and a few other things. But those other things don't come directly into play here. It'd be great if they did, but they don't.

You don't know how to create value. Step 1 is admitting that. Without that admission, no amount of charting or graphing is going to help. And yes, you can't rebuild your software. Probably lucky you've got it up enough to provide value right now. I'd hang on to it.

<comment><USER27> I second this rebuttal.

Incremental changes by domain, decomposition, and careful management of the work is not only effective, but also necessary.

<comment><USER26> I was leading an effort a while back to look at replacing a group of 40-odd systems, tied together by batches, to run a large worldwide retail operation.

After scoping out the work, my recommendation? Build a small app to handle receiving. You do receiving at all of your locations, it's being done by several different separate systems, and it's an opportunity to write a small, cross-platform app that can be used by anybody with zero training right away.

It was shot down! Why? _Because large projects aren 't done that way around here_

That has nothing to do with anything, yet it prevented getting started immediately.

As a hired-gun, I moved on to bigger and better things. The org dropped 100M+ on just the kind of rewrite this author is talking about before giving up in failure. (Actually they changed the goalposts so that they won, then had a big party. But there was very little done compared to the money they spent)

It's the wrong mental model. It's painful to watch, like a kid with a big hammer trying to make a large circular block fit inside a small square hole. It's not going to be good even if somehow you make it happen. It's going to be ugly as crap. You end up destroying the thing you're trying to help.

<comment><USER28> > The org dropped 100M+ on just the kind of rewrite this author is talking > about before giving up in failure.

That is evidence that the author has a point. He also said, at the very end, that this is a two-part article, and part 2 will deal with how to address these problems. I would not be surprised if he advocates something like the approach you suggested in this case.

</comment></comment></comment></comment><comment><USER29> "Don't pave cowpaths" is relevant here.

If the old software is convoluted, it may be because the old business processes are convoluted.

A software rewrite should be done in the context of a business process redesign. Consider how information flows through the organization. Do you really need to do all the things you're doing now? Should different people or departments get different information? Should the product you're selling or the service you're providing change? Should parts of the process be outsourced or insourced?

If an IT department is considering a big rewrite, but doesn't have the authority to look at the business as a whole, then the project is being managed at too low a level. Rewrites make the most sense in the context of a change in the underlying business.

</comment><comment><USER30> "We'll do a rewrite, simplify everything, get rid of all the edge-cases."

Guess what? It turns out that all those edge-cases were there for a reason. You needed them. And by the time you've added them back, or equivalents, two things have happened. First, you've burned an order of magnitude more time than you budgeted for the rewrite. And second, you have a codebase every bit as gnarly as the one you started with.

First rule of rewrites: don't do it. Second rule of rewrites (for experts only): don't do it yet.

<comment><USER31> Sometimes the reason has not been relevant for ten years, though, like when a codebase is filled with horrible hacks to account for the fact that you only have 64MB of RAM, while running in a vm with 4GB.

<comment><USER32> That is right, but you should be able to point at (preferable several) such assumptions that went into the original system, and verify that they are no longer necessary.

Maybe you used to have much less RAM in the past, but also much less data, or not as many users etc.

</comment></comment></comment><comment><USER33> A rewrite can also mean a gradual change. A great example of this is the rewrite of 0install in OCaml from Python [0]. With such an approach you change module by module with old code and new code working side by side. It is of course not so easy, but it makes it possible to do on-line. A bit like with bits of Rust code that go in Firefox with each version.

I would like to know if anyone participated in a similar gradual rewrite and how it went.

It may be very hard for some architectures and also sometimes wrong architecture (prototype became production, some features were dropped along the way, a new feature is dog slow) may require big rewrite, even breaking APIs, then it would be impossible. But if one keeps API one can at least do comparison tests as more features are implemented.

[0] [http://roscidus.com/blog/blog/2014/06/06/python-to-ocaml- ret...](http://roscidus.com/blog/blog/2014/06/06/python-to-ocaml- retrospective/)

</comment><comment><USER34> Rewrite from scratch is a very risky business, especially if it is conducted under the technical view only. The only exception is when the rewrite-team is the same as the original development team, which is almost never the case, except in the continuous delivery model. For me, the consequence is clear: \- The rewrite cost is so high, it never justifies to do architectural and software engineering sloppily, even in an agile approach. \- Rewrite only critical pieces of software is always a better approach to prefer. In most cases, rewrite just a few pieces of software can satisfy the requirement at least to 80%, be it better performance or higher stability or interfacing with other software. \- Therefore, for any big piece of software, modularisation is always helpful.

</comment><comment><USER35> Sounds about right, but:

> As people move off of the team, features are forgotten and misunderstood; > but as long as those features continue to work, there will be customers > continuing to depend on them.

You have this in the non-rewrite scenario, too, it's just part of the technical debt, so it's less obvious to see. And it will bite you just as hard if you need to update the feature.

So because rewrites are good at uncovering unknown unknowns, and it might be better to say that the technical debt was underestimated.

</comment><comment><USER36> I'm approaching the rewrite of one old system in the next year (not really large, I'm estimating that this rewrite will take 2 years for few developers, probably 100-300 KLoC in the end). It's really hard to extend that system. It uses Oracle 9. It's written with Delphi 7 with half of the code being autogenerated PL/SQL procedures (those visual tools for users, too bad that users don't use them anyway). It's distributed, because in 1998 there was no network access everywhere, so there's hierarchical export-import over CD all over the country (of course now everything is connected, so those export- imports are just mailed). Build process is another nightmare. It consists of several DLLs. Every DLL is a separate project which uses its own set of components. You need separate VM to develop and build every component. Sources for some components are lost. DB schema is insane.

Customer wants to migrate from Oracle (because it costs quite a fortune) to free PostgreSQL and he wants to use browser. Also a lot of things changed in those 20 years and many functions are just not used anymore. I think that rewrite is quite justified in this case (will rewrite in Java).

</comment><comment><USER37> My team recently completed a rewrite of a major system. It was approached with the following goals.

\- Port from Java to C#. The Java teams no longer maintained it beyond critical fixes. Many original experts were gone. My team had more vested interest and expertise. We _wanted_ to be in charge of this system, and we work in C#.

\- Switch from horizontal processing to vertical processing. The original system would query one record, query one associated record, query yet another associated record, etc. to form the complete picture of one entity. The new system reads and writes batches of homogeneous data. (Kind of a leap from OOP to DOD in terms of database accesses.) This optimization was largely necessary as the old system could not keep up with load spikes.

\- Along with the previous change, we completely separated the data processing into two giant phases: one read-only step and one write-only step. This allows the read-only step to target replication databases. This reduces the stress on the primary database, which is a huge win.

\- Detach the system so that it can be run, tested, and released in isolation. The original system was part of a much larger whole, so any fixes or enhancements had to wait for weekly or biweekly monolithic releases.

Everything you expect from a rewrite happened but not to a devastating degree. It went overbudget, missed key bug fixes, etc. but we worked through them and came out the other side with all the wins we hoped for. Being able to deploy multiple times within a single day is amazing. Our iteration time on new bugs or features is very small. The overall architecture is simpler and easier to navigate. I have confidence that a member of my team could enter the code base cold and fix a bug within a day.

So I dunno. AMA?

<comment><USER38> > We wanted to be in charge of this system, and we work in C#.

What was the estimated cost of developers being literate in more than one language? How significant was this in the decision?

<comment><USER37> I don't think it had a visible cost in our case. For starters, my team understood the system adequately to not need to reference the original source code so closely. (Much of the work happened before even beginning to read the original source code.) Secondly, we all had enough Java exposure to be comfortable porting behavior over when it was needed.

</comment></comment></comment><comment><USER39> Huge, ugly, broken legacy systems are a bear to work with and I've mostly spent time working on them when not at startups. The most successful project of my career was a facade-and-rewrite in which I played a significant role and has billions of $ of annual revenue behind it now, so I think I understand this issue fairly well. I also played a significant role in another similar project that, after I left, spiraled completely out of control and became a disaster that, 8 years later, is still not finished.

The "this is dumb, we should rewrite it" reaction people tend to have when exposed to very large, complex legacy software systems is totally understandable, but really comes from a fundamental misunderstanding of the forces that drive software development at organizations which have legacy code bases. Yes, the re-write, if it gets "done", is basically guaranteed to be "simpler and cleaner" when it arrives; of course it is! It is being compared to a code base that's 20 years old, not just from an era where the technological compromises were completely different, but also from essentially a different world of what was acceptable at the time. In addition to that, all software that lives long enough tends to become a mess. Let's see how the rewrite is in 20 years.

Oh, but wait, this time will be different. This time we won't make quick fixes and little hacks, we'll be diligent about requirements, we'll refactor and clean up when change is needed ...

Everyone who has not should read "The Big Ball of Mud" ( [http://www.laputan.org/mud/](http://www.laputan.org/mud/) ) which is about the clearest description I have seen of the reality of legacy systems.

</comment><comment><USER40> I think it's important to distinguish full rewrites and incremental rewrites. The latter is possible if you have some tests in place.

</comment><comment><USER41> Coming from data warehousing. Rewrites are normally instigated to get rid of data silos. Put everything in one place and model it the say way. Very few of these projects are ever finished and the irony is that each project ends up being a data silo. It is not unusual to have three so data warehouses within an organisation. Each just slightly different from the next but with 80% the same information. Turns out that last 20% in the 80/20 principle is very hard.

</comment><comment><USER28> The author's formulae leave an interaction out: as the project is delayed, the catch-up costs increase as a consequence. Furthermore, if the delay leads to an unanticipated shifting of resources back to the old system to keep it running, that can add to the delay. Catch-up cost has a dependency on undiscovered scope.

It is also possible that some of the unknown scope becomes obsolete, but if that is happening, then you are already in a long-drawn-out process.

</comment><comment><USER42> If a rewrite introduced a stable, performant, secure, extensible architecture, than it's worth it. Else just improve it incrementally instead.

<comment><USER9> The two are not mutually exclusive. A rewrite can be done incrementally. In fact, that's the best way to do it.

<comment><USER42> Ah, what i mean is, for the latter part, do not rewrite from scratch, instead change the old architecture incrementally.

</comment></comment></comment><comment><USER43> As a general rule in my experience, a re-write will take at least as long as writing the current software. There's a reason that much of our modern banking infrastructure still lives in COBOL. But that's not a bad thing. It makes a ton of sense. The cost/benefit of a rewrite should be done beforehand and this should be taken into consideration. You'd be surprised at how rarely that happens. It's a false and incorrect assumption that re-writes are cheaper or faster (you are basically re-learning the entire specification of an application). But re-writes also offer a ton of opportunity and benefits and if those are important to your business, then proceed with a re-write.

</comment><comment><USER44> If code reached the point where it can't evolve anymore - it should be rewritten. Otherwise it will be dead code and there's not so many fields where dead code can be used without killing everything around.

</comment><comment><USER45> Rewrites mostly fail because business logic is assumed but never fully understood at a detailed level. Multiply by the size of the rewrite and things get out of hand quickly.

The best way to go through a rewrite or upgrade is to get the business involved at the start and throughout the process. If you fail to do this when something is missed, overlooked or done differently and you will be at fault. If you include them it becomes a not feature not necessary.

</comment><comment><USER46> This is a fascinating thread on HN because of how divisive the issue of software rewrites is. I wonder, what do people think of rewrites that are driven by emergent scale and business requirements (rather than technical bitrot or code smells)?

I've been on a project where we had a working system, but it had some severe technical platform & product value limitations, and we knew those limitations were costing us real $$$, both in support burden and market share vs legacy incumbents and competitors.

Plus, we had a "ticking time bomb" because it was a large-scale data system, but the prototype (which became prod) was not designed up-front to handle horizontal sharding, and we were at the limits of vertical scaling, and were projected to hit the "max limit" of that vertical scaling within 12 months, given current growth rate.

Thus, we began a rewrite, with full knowledge of how dangerous it was -- we even circulated Brooks's essay on "the second system effect" and had several team discussions about it during the specification stage of the rewrite.

In the end, the project was a success, and powered 3+ years of scaled growth (the current live data storage of the system is 100x what it was when the rewrite began, and our "hard limit" was around 2x). The rewrite also helped us make the system more scalable, competitive, and mature, not by throwing away edge cases, but by choosing an architecture that didn't cut corners on areas that, we discovered during user feedback from the v1, were non-negotiable core areas of value for our customer use cases. We had relaxed many requirements in the "prototype stage" of the v1, merely in the interest of getting _something_ working out the door in front of customers.

The last piece of de-risking we did is to run _both systems in parallel with our users for several months_. This allowed us to e.g. let 10% of our users into the new system at first, ensure we weren't breaking any of their use cases, then let 20% in, 50% in, and so on. We could also do user interviews throughout. Since the new system involved not just a better data backend, but also faster response times, a modernized UI, and many new features, lots of people wanted in. We even had a waitlist, at one point.

Then, we cut the stragglers over, and cut the old system loose -- which felt great, BTW! Running two production systems in parallel isn't easy, but was absolutely the right thing to do.

With hindsight being 20/20, we feel firmly that our first system was a "prototype that went to prod", and that we followed Brooks's advice to "plan to throw one away, because you will anyway". And that we executed a "successful rewrite". But it certainly wasn't easy.

I'm really proud of that project, but I also feel it was a bit of a harrowing experience, especially near the end, when we were concerned some "showstopping bugs" were going to keep the progress bar at 99% for a couple extra months. But we made it through.

Perhaps the reason my outcome is better is because the _need_ to rewrite wasn't driven by a framework or architecture du jour, but by real business requirements and real scaling requirements. Even then, I think sometimes those requirements can be overstated and the ability for an existing architecture to cope can be understated. I feel confident we made the right call, but I think it takes real expertise -- and healthy dose of skepticism -- to take on the full rewrite risk with eyes wide open.

(p.s. now, 3 years later, the same team is being _forced_ to rewrite a significant portion of the backend, not for any business requirement or scale reason, but because of bitrot of a stable open source database engine version which needs to be upgraded to avoid EOL, and wherein the new version introduces backwards-incompatible breaking changes to the API and schemas. At least in this case, it's "only" a backend migration, and not a total rewrite. But, I'll tell you that it sucks to realize this is _just_ required maintenance, thus a pure development cost with little customer benefit, rather than a project to introduce a step-level change to the product and business. C'est la vie!)

</comment><comment><USER47> My team has been rewriting a winforms application in JS. We just reached feature parity after ~4 years. In order to continue delivering new features without having to catch up with the old application, we released both the new and old applications together. This strategy worked well for us, as it allowed customers the ability to fall-back to the old application and create requests for missing features in the new application.

</comment><comment><USER48> Odd that increasing the Pace of the rebuild team from 1.5 to 2.0 has no impact on the catch-up factor.

The faster they work, the more over-engineered the results? :-)

</comment><comment><USER49> IME, the chief roadblock to a successful rewrite is the organization: an organization that produced poorly-factored, unmaintainable code that NEEDS a rewrite is not well-equipped to do something different the second time.

</comment><comment><USER50> i think the point to start rewriting is when nobody still on the team can maintain the product. i recently got pretty close. i had been researching something for months (speeding up a login), but to no avail. so to avoid looking even more incompetent i said, you know what, an SSO app should be relatively simple to create. just slap some strings together and youre done. it would be quicker than banging my head against the wall for another three months. but somebody on another team still had knowledge and this ultimately gave us the idea to fix it.

</comment><comment><USER51> > What's a better way? I'll propose an alternative to you in my next blog > post!

After a clifhanger like that, it better be good. :)

<comment><USER52> It's pretty obvious what part II will be, considering Part I is basically arguing that a full, ground-up, greenfield, throw-away-everything-and-start- from-a-blinking-cursor rewrite is an expensive mistake.

Half the comments on this thread have already alluded to it: A careful, piece- by-piece replacement, delivering the new system incrementally (running in parallel with the old system if need be.) Or even a gradual refactoring of the original code base if the base technology wasn't the problem. Read the success stories in this thread - you'll see they tend to follow this pattern.

</comment></comment><comment><USER53> cost of rewrite is 1x, unless you have to maintain the old ones and replace them in parallel.

</comment><comment><USER54> I think the "undiscovered scope" part is where most people trip.

You can think of software and how it fits with its users purposes as having multiple layers of features, interactions and details.

The top few features usually each have a few sub features that you have to tailor correctly to your users work flows, each of these sub feature often have sub details, interactions with other features, corner cases, data formats or cross compatibility considerations.

It's a fundamentally mathematical issue. Adding a layer of detail is an exponential proposition and the exponential function is explosive in nature. If your software only has 3 major features and each have 3 sub features, that is 9 things to consider. If each sub feature has 3 corner cases you need to get right, that is 27 things. And if each of these 27 things have 3 details that gets you to 81 considerations. The next level is 243. Each of the 243 points tend to take a similar ammount of time to plan out and build weather it's at the top or the bottom of the pyramid.

As a piece of software evolves over the years, the intricate details at the bottom get sculpted out. The software's fit to its purposes can become very fine.

The thing is, people tend to think of software in terms of its top 2-3 layers of details, its 27 most important features. The finer complexity is often not as visible and it's just difficult for humans to keep so many items in mind.

This is true of any complex technologies. People tend to think of cars as machines that have properties concerning speed and direction and suspensions and breaking but rarely think of the complex chemistry of the fuel aeration and combustion process, the complex internal forces and velocities of parts in the transmission, the carefully tweaked metallurgic alloy work that has gone in each of the thousands of metal parts, the carefully chosen properties of the plastics and the rubbers, the thermal properties of everything, the hundreds of electronic systems, the analog circuits, the thousands of specification lines of many dozens of communication protocols for controlling all these parts, the entertainment system, acoustic properties etc, etc, etc. All these things took decades to evolve and refine.

It's easy when planning a rewrite, to plan out the few dozen items visible at the top of the iceberg and underestimate the amount of important details hiding bellow.

Sometimes, some of the details might not be important, but often times they are the essence of your business case and at the core of the favourable economics of your product. It's the years of knowledge accumulated in the subtle details that provide you with a moat and makes it difficult for your product to be copied.

If you rebuild with mostly the top few dozens of features in mind, and only vague ideas about everything else, you are likely to be creating a commodity solution, one that your competitors will have a much easier time to copy than your older finely tailored solution.

</comment><comment><USER55> anyone know of an articles with references or real data?

</comment><comment><USER56> There are very few axioms of software development that are applicable everywhere. "Never rewrite" is one of the few that is valid in all situations.

<comment><USER57> "except when the original version used MongoDB as a relational store and a home-grown web framework that was a poor mans' Django/Rails (except slower, undocumented and incredibly resource hungry) where moving bit by bit to PostgreSQL wasn't an option, then totally rewrite it properly"

<comment><USER58> Better yet: Stick with Mongo, create regression tests, switch out or simplify the framework and add integration testing.

It is often viable to take the meat of a system and place it in a new framework with some alterations.

And for the performance issue, just identify what causes it by timing parts of your code. I'm guessing home grown database wrapper.</comment></comment></comment>


Why Hypercard Had to Die - <AUTHOR> http://www.loper-os.org/?p=568 <comment><USER3> This doesn't seem to be anything special about Hypercard.

Hypercard was the BASIC of the Macintosh in that it served the same niche. It certainly was not BASIC, but the idea was the same, a little language and environment that fit into the machine's environment that allowed novices (and then highly practiced novices :-)) to create stuff on the machine for other people to use.

It was killed for the same reason BASIC, in the sense of built-in 8bit micro BASIC, kind of fell to the wayside except as a way to stitch existing apps together. No one is really impressed by a calculator program anymore. Matching the capabilities of modern software is hard nowadays. It's demotivating to create a calculator program... that's it? Hypercard really can't match even JS, et al. in functionality.

I remember when it started to happen in the 16bit era. Software was already starting to get too good and too complex for a simple tool. I got an Amiga. The Amiga had a built-in BASIC -- but no one used it. Why? Because there was no fucking way you were going to recreate even the bouncing ball demo in BASIC. It wasn't going to happen. Essentially, anything you created was going to be a huge disappointment with that tool. This was not necessarily true in the 8bit days -- but from 16bit on, you either learned assembly/C or gave up. People can learn in that environment (and did), but the barrier was much higher.

Lowering that barrier while coming close to the capability of "real" software is a hard problem. Fortunately, it's coming full circle. Now that machines are powerful enough that "real" software is being written in interpreters, JS seems like it actually _is_ the new BASIC.

I'm not totally sold on that -- because the stack is too too baroque (although, again, people do learn in that environment). Processing is perilously close but not quite there because it's so domain specific. Python comes with a lot, but doesn't fit into native environments very well. If I had to chose, I'd say it's going to be something else over the JS/CSS/HTML stack in the same way 8bit BASIC sat over the primitive OS at the time.

<comment><USER4> _> This doesn't seem to be anything special about Hypercard._

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

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

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

<comment><USER5> That rant is was quite nice... had me going for a minute.

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

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

<comment><USER6> Because 'right' is in the eye of the beholder? It's subjective.

<comment> loup-vaillant We agree much more on what's "right" than you suggest.

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

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

</comment></comment></comment></comment></comment></comment><comment><USER7> Sigh. Maybe instead of ranting at your "typical software engineer", the author should spend a moment to consider that maybe it "could be built again" - <USER2> it never has.

So the question then turns to, why has it never been built? Is it maybe because Hypercard (and other visual systems) become entirely unmaintainable once we get to large-scale systems? And maybe it is because most people don't _want_ a trivialized programming environment? They either want a full system, or just a product?

<comment><USER8> > They either want a full system, or just a product.

While I think this is true at the moment, it seems that there is an interesting question behind that, as well. Why don't more people want to create their own software? I do think the author has an implicit point: because, frankly, creating software stinks. Jon Skeet's talk [1] demonstrates this admirably. I spend a shockingly large part of my time working around bugs and leaky abstractions in other software rather than implementing my own ideas.

I don't know if it is possible to design a system with a solid enough abstraction that these problems don't exist. I do know that HyperCard came unusually close, as I know several folks who made HyperCard stacks who wouldn't imagine creating software in any typical fashion.

I hold out hope that such a useful system could be created again, one that gives people enough flexibility to create software solutions of their own (perhaps within a genre of software) and that is able to combat the currently- accurate stigma of programming being "hard".

[1] [http://msmvps.com/blogs/jon_skeet/archive/2009/11/02/omg- pon...](http://msmvps.com/blogs/jon_skeet/archive/2009/11/02/omg-ponies-aka- humanity-epic-fail.aspx)

<comment><USER7> Hm. I've never seen a HyperCard project that was both maintainable and of a large-ish size. I think _that_ is where the HyperCard idea broke down - navigating through a bunch of cards is significantly more difficult than through a bunch of text files.

Granted, that _may_ be a question of the tools. But I do find it telling that in the long time since the "death" of HyperCard nobody could come up with compelling tools.

And creating software is hard because ultimately, it requires analytical thinking. Which, by itself, is hard. Yes, the choice of tool modulates the hardness of the problem - but the underlying issues are still hard. (Note: I do not claim non-programmers _can't_ reason analytically. I claim the effort/result ratio is not right for them)

It's the same reason most people buy furniture instead of building it. Acquiring the necessary skill set is simply too much effort for the result.

<comment><USER8> I definitely agree that software desire requires analytical thinking. (It certainly put a halt in my thoughts about a mass-appeal software builder: if they don't "get" [or want to get, or whatever] Excel, they don't have a chance for much else.)

I do think, though, that not being able to make projects of large-ish size isn't necessarily important for a wide variety of use cases. Most of the best apps I know of do only a very small thing—but do it very well. I think HyperCard allow people to do small things exactly the way they wanted. Which maybe wasn't very well, but was good enough for their needs and better than the alternatives.

As I mentioned in my other comment [1], I wonder if the parallel is somewhat like the UNIX command line. You probably aren't going to write a MySQL competitor in bash. But there are a whole class of small custom tools that you will write.

To perhaps restate my original point (and this is where perhaps we agree), the abstractions of HyperCard eventually didn't (couldn't?) adapt. Perhaps, as you said, because of cards. As someone else commented, also partially because of the codebase, but also, I think, because things like color and networking and a greater number of standard UI widgets all had to be added.

[1] <http://news.ycombinator.com/item?id=3294915>

</comment></comment></comment></comment><comment><USER9> I recently discovered Quartz Composer, which is included on any Mac w/ Xcode, and I was pretty impressed by its capability. IMHO it is one of the best kept secrets of the apple-verse.

While it is very different from Hypercard, it certainly provides a level of artistic expression and creative freedom that the article alludes is present in Hypercard.

When I booted up QC for the first time a few months ago, I was blown away by its awesomeness.

And then when I further explored the vibrant community out there AND the fact that it can be readily integrated into objective-c / cocoa, it's clear that Apple is very much in tune with what normal people and creative people need to express themselves on a computer. To get started, here are some links: <http://en.wikipedia.org/wiki/Quartz_Composer> and [http://developer.apple.com/technologies/mac/graphics-and- ani...](http://developer.apple.com/technologies/mac/graphics-and- animation.html) Hint: If you have Xcode installed, simply type "quartz composer" into spotlight and begin your journey.

A final note: I seem to recall but not certain that a) QC was an acquisition by Apple of a french company; and b) the original developer has moved on from Apple

</comment><comment><USER10> I was sad to see Hypercard abandoned - I learned how to program with it myself (along with Perl & CGI apps - syntax didn't matter so much as what you could accomplish with it). But part of the reason I think is that Steve Jobs abandoned going primarily after the education market when he returned to Apple - he had already been burned by it (or become disillusioned by it) at Next, but also really Apple had already saturated the education market. He and Apple focused on the consumer market (imacs, ipods, etc.) - the business market had already been won by Microsoft. Microsoft also already had a more successful end-user friendly programming/scripting environment: Visual Basic and VBA. In case some don't know, Visual Basic was the most popular programming language in the world until overtaken by Java. VB didn't really start to significantly decline until more people developing business apps switched to C# and other languages.

Microsoft also won with a more popular tool for creating visual 'stacks' or presentations: Powerpoint. Most educators were basically using hypercard/supercard/hyperstudio to create presentations - and Powerpoint made it easier to do so.

Hypercard (and hypertalk) isn't dead though. Applescript is still around (despite Apple also trying to kill it). LiveCode and other options are still around and being updated for HTML5 & mobile platforms, as is Visual Basic, too (nsbasic). A java port of the hypertalk language is here: <http://code.google.com/p/openxion/>

Natural language-like interfaces aren't dead, either. Look at testing tools like Cucumber, the google search engine, Siri, and so forth. Look at all the DSLs out there that try to make Ruby/Javascript/etc. more like natural languages, at least in certain contexts.

</comment><comment><USER11> HyperCard is very near and dear to my heart. When I was a kid I taught myself how to program with Hypercard. I'm a software developer today, and despite the crazy verbose syntax of HyperTalk, I still acquired an intuition for programming that remains helpful, 15 years later.

I actually approached Steve Jobs about the demise of Hypercard in 1998, when I was 15, at the Seybold SF conference. IIRC he gave a pretty dismissive response about it, basically saying that there wouldn't be a market for it anymore. It was pretty obvious that he didn't care about HyperCard or HyperCard-like products anymore. That, or he didn't want punk teenagers questioning his business strategy.

As a side note, I got my photo taken with him. When the photo was developed I saw that I was wearing a megawatt smile (shit, I met with Steve Jobs!), and Steve was looking distractedly at something in the corner.

</comment><comment><USER12> I think much more likely explanations than the nefarious anti-creative one given for HyperCard's death are that, to varying degrees: Steve found all HyperCard stacks he saw to be messy and confusing, not at all the functional simplicity he was looking for; HyperCard was taking engineering resources and/or money that could be better spent saving the Mac, and therefore Apple.

Apple has not, in recent years, on the Mac, been against trying to provide simpler programming environments - look at Automator, (the now also defunct?) AppleScript Studio, or Dashcode.

<comment><USER13> Simple programming environments have a fundamental flaw: they fool you.

Let's say we have a type of perforated balsa wood that you can just snap into pieces and glue in place. Making a dog house just went from hours to minutes! Hurrah! So you start telling everyone that this is the new way to construct buildings, but then as you get bigger structures, it starts to fall apart.

Simple programming environments fool you into thinking you into thinking your projects can scale, and the result is a mess. Hypercard was fun, but it wasn't a deep paradigm, it wasn't good syntax, and in the end, I have to say that it was good that it died.

<comment><USER14> And why does it need to be "deep"?

It's good that it died because it doesn't "scale" to the elephantine size of software you're accustomed to?

<comment><USER15> > It's good that it died because it doesn't "scale" to the elephantine size of > software you're accustomed to?

Does nobody else find this hilarious? I mean, the whole persecuted-Mac-fan vibe here; it's so 1990s it's almost a time warp in itself, except this time it's a persecuted-Classic-Mac-fan, and the main entity doing the persecution is Apple itself.

<comment><USER4> Steve Jobs demolished Apple and replaced it with Next.

</comment></comment></comment></comment></comment><comment><USER16> Umm, SuperCard still exists and is under active development. Even back in the day it was superior to HyperCard in every way.

My guess was that HyperCard was killed because the WWW was coming. I used SuperCard pretty heavily back in '92ish at the second college in Minnesota to get the internet (MCAD - U of M was first). I remember the rows of NeXT boxes they had, the only machines connected and I remember fumbling around with building Gopher sites as well as some basic HTML hacking, as basic as it was back then. I lost interest in HyperCard/SuperCard shortly thereafter.

But it's spirit certainly lived on in Visual Basic, Borland Delphi, Macromedia Director and a bunch of other things. I don't know that this guy had exposure to any of this hence the short sightedness and, in my opinion, miscalculation of Job's motives.

<comment><USER4> _> the WWW was coming._

In 1998?

 _> it's spirit certainly lived on in Visual Basic, Borland Delphi, Macromedia Director and a bunch of other things._

I have used all of these, and beg to differ. The spirit of HyperCard was that of _radical simplicity_ , and it does _not_ live in these systems.

<comment><USER16> > > the WWW was coming.

> In 1998?

I built my first HTML page in '93. NCSA Mosaic was the rage in the lab.

> > it's spirit certainly lived on in Visual Basic, Borland Delphi,

> > Macromedia Director and a bunch of other things.

>

> I have used all of these, and beg to differ. The spirit of

> HyperCard was that of radical simplicity, and it does not

> live in these systems.

???

Drag and drop, double click to add script, how is that not the spirit of HyperCard? HyperCard was the preeminent RAD development tool. Easier than Visual Basic? Sure, but not by much. The gap between BASIC and HyperTalk is not that great a leap. If you can't see the parallels between Macromedia Director and HyperCard, you're being blinded by your own weird sense of what's what - considering they both used the same basic language back then.

<comment><USER16> > Hypercard is different from systems like Director > in what isn't there: the > cancerous complexity.

No offense, but you're reaching for straws now. Any stack of any complexity was just as complex as the equivalent in Director. I'm not sure what you were doing in 96 or so, but I was making a living with Director after cutting my teeth with some serious SuperCard action. I wrote a precursor to AIM/ICQ for our feeble AppleTalk network with SuperCard and that was not simple at all.

I guess if you were writing simple back and forth stacks, then yes I see your argument. But anything truly useful beyond that was just as complex as anything else. I appreciate your romantic notions to the contrary however.

<comment><USER17> I never used Director, so I can't speak to that. And, by '96, I had graduated from HyperCard into C and Pascal.

But: I spent a _lot_ of time in HyperCard, and I can assure you that the field of HyperCard complexity was not limited to just "simple back and forth stacks" or "anything truly useful beyond that". HyperCard afforded a really nice way of gradually ramping up complexity and approaching complex-on-the-outside problems with simple-on-the-inside code.

I doubt I could remember any of my own HyperCard projects at this point if my life depended on it. But, I can tell you about a HyperCard project a good friend of mine did: he called it "MusicMaker", and it came with a piano keyboard, multiple synthesizers, and its own unique musical notation system which allowed you to easily translate any sheet music into text which the HyperCard stack could synthesize and play on the piano keys. It could teach people music better than just about any other piece of software at the time. This was not, as I recall, remarkably challenging for him, and we both had a lot of fun with it.

I think any network-related programming is going to suck. Tricks of the Mac Game Programming Gurus had an entire chapter devoted to it, as I recall, in which most of the chapter could be summed up as, "OpenTransport sucks". So, I don't think it's fair to use a networking-related program as an example of a challenging HyperCard (or SuperCard) project.

> _I appreciate your romantic notions to the contrary however._

(edited for snark)

Please try to keep the snark to a minimum. Thanks.

<comment><USER16> Yes, and I wrote a MIDI sequencer in Borland Delphi in about 1997 and that wasn't particularly challenging either, in fact simpler than attempting similar in SuperCard: [http://www.sonicspot.com/aliendiskosystems/aliendiskosystems...](http://www.sonicspot.com/aliendiskosystems/aliendiskosystems.jpg)

The point is, people tend to gloss and shine and wax poetic about HyperCard and it's ilk, but if it was so profoundly simple and awesome, why aren't SuperCard and related (MetaCard or Toolbook anyone?) prominent development platforms? Because that simplicity becomes complexity once you cross a certain threshold.

> _Please try to keep the snark to a minimum. Thanks._

Please keep attempts at editing people's personalities at a minimum. It's how I talk, it's how I write, I make no apologies for it.

Cheers!

<comment><USER18> The technical qualities of a technology are not the sole determinant of its success or failure.

</comment></comment></comment></comment></comment></comment></comment><comment><USER19> HyperCard like systems are not dead. I make my living from LiveCode ( <http://www.runrev.com> ) which is a xTalk system that is able to build applications for Mac OS X, Windows, Linux, iOS and Android. From a single HyperCard-like environment, I can build apps for all these platforms and reuse the code.

LiveCode is very verbose and it may take a while for those that are already familiar with C-like languages but it is worth it. Software is easy to maintain and there is little space for confusion, even with few comments.

RunRev company also release a PHP-like engine, so I can create web applications that communicate with native clients on mobile and desktop all from a single language and environment, this is very powerful.

You should always use the best tool for your job. For my job, LiveCode fits perfectly. I also think that xTalk languages are a wonderful introduction to programming and people from non-technical backgrounds can learn it easily and start creating little tools to help their specific domains. Yes, anyone can learn programming in any language, it is just a matter of effort, I believe LiveCode makes this effort fun and productive.

You may read this as advertisement but this is my personal opinion. I am 31 and have been using LiveCode since I was 25 or something like that. In the meantime I got married, got my own place and am living a good life. All my work is LiveCode related. Just telling you that so you guys don't take me for "someone that toys with this cute language every once in a while but is not serious".

Even if you already have your favorite language, it is worth to check out LiveCode, just to learn what else is out there. There are beginner webinars starting next month I think...

<comment><USER19> oh... I forgot to tell, LiveCode can import HyperCard stacks... =)

</comment></comment><comment><USER20> A bit of trivia: MYST, the CD-ROM game, was first shipped for the Mac and written entirely in HyperCard (with a few custom extensions to load the color graphics as quickly as possible).

</comment><comment><USER21> I think what killed Hypercard, in some sense, was what it made popular: like the Amiga, it was too closely tied to its hardware.

HyperCard ran black and white windows of 512*342 pixels because that is what the original Mac had (there was a version that did some color things, but that was and felt like a serious bolt-on job). Moreover, all graphics where bitmaps.

Bringing that into the 'real world' as it existed at the end of the eighties would have taken a lot of resources, and it was not guaranteed that the end result would still be HyperCard. For example, if one allowed resizable windows, laymen would have to learn about layout algorithms ('is this button 50 pixels wide, or a quarter screen wide? Is it 20 pixels from the bottom, 10% of screen height, or should its bottom border match that of that text field over there?').

Also, at the time, there were attempts to include some Hypercard/Director-like features to QuickTime. HyperCard was considered for that functionality, but did not make the cut.

<comment><USER22> I think that versions of Hypercard past v1.0 allowed for stacks of arbitrary window size; I know for a fact that I made up at least a few 1024x768 ones in v2.2.

You are correct in that I don't think it supported _resizable_ windows without the use of some XCMD though.

<comment><USER21> You are correct. Surprisingly, I even found evidence for that: <http://support.apple.com/kb/TA31048>:

* All the cards in a given stack must be the same size, even if there are several different backgrounds in the stack.

* Smallest card size: 64 x 64 pixels

* Largest card size: 1280 x 1280 pixels.

</comment></comment></comment><comment><USER23> FTA: "And if you think that XCode, Python, Processing, or the shit soup of HTML/Javascript/CSS are any kind of substitute for HyperCard, then read this post again."

I always hope in the back of my mind that someday there will be a way to create a web interface as easily as you could in Hypercard.

I miss it so much.

<comment><USER4> No such luck. The Web architecture _inherently sucks:_

<http://philip.greenspun.com/research/internet-haters>

<comment><USER7> Take that article with a _large_ grain of salt. Much of it has been proven wrong by now. ("HTML is where the Web starts and probably where it will end.")

<comment><USER24> Take anything from loper-os with a massive grain of salt, he is a long-term troll who has been writing these sorts of wistful but ultimately empty posts for several years now. Calling everything and everyone stupid and bloated and yearning for the good old days is his thing. I only mention this because some HN readers might not be fully aware of his history.

<comment><USER4> The distinction between a "troll" and an actual human with unpopular opinions is lost on you?

You aren't the only one: <http://www.loper-os.org/?p=91>

</comment></comment></comment></comment></comment><comment><USER25> Actually has a really good example (a calculator) to show how HyperCard could be used.

HyperCard was a big part of my junior high years. It could even be extended, e.g. there was one add-on that allowed color graphics to be displayed and I learned to make some simple games that way.

<comment><USER6> But its not a good example.

You're sitting at a device with a numeric keypad, and a 9" screen; Replicating the calculator interface in clickable buttons, with a textbox as simulated LCD is a horrible misuse of the potential of a computing environment.

A screen, a keyboard and a hardware ALU. Being used to run an OS which draws some keys and a screen, interprets mouse movements, parses and interprets Applescript and parses text arithmetic operations, so it can pretend to be some keys and a screen connected to a hardware ALU.

And this is hailed by our "anti-bloat" author as a great example of simplicity which normal people love, and its limits are fine, compared to any other system - e.g. Visual Basic 3 - which is needlessly complex.

It's almost funny, until you read his seven tenets of computing and find that any program which encounters any error should enter a debugger, so you can fix it and carry on. I think that would drive anyone insane.

<comment><USER26> Have you never watched a video on your PC depute owning a perfectly serviceable TV?

<comment><USER6> Yes.

I have also loaded up an OS and browser built on a cross-platform GUI framework and a TCP-IP stack, and used it to do a DNS lookup and send a HTTP compliant request across a tangle of hundreds of miles of interconnected systems to Google's servers to statistically analyse my query, run it through around 700 servers, through an index of several billion web pages, and thousands of years of Youtube videos, millions of pictures, hundreds of thousands of news articles and twitter streams, ranking the results, and at the top putting the results of my calculation "2+1" or whatever.

But then, I'm not the author with the weirdo view of 'simple'. What's your point?

</comment></comment></comment></comment><comment><USER8> I had a sudden hypothesis after reading this thread last night. (No proof, mind you, just an idea.) I wonder if HyperCard's success was for the same reason as UNIX's success: a well-chosen, small set of interoperable tools that allowed the user to do far more than the sum of their parts. And, as computing and interfaces have become more complex, we've just tacked on complexity to them rather than reinventing them to adapt.

For instance, UNIX's treatment of everything as a file is a great tool, but I think there was a time where that simplified a much greater percentage of computing than it would today. Similarly, I suspect HyperCard died because the abstractions it was using had to be reimagined to stay competitive.

Spreadsheets (as mentioned elsewhere) are an example of a product that has managed to stay focused on the simple set of tools, and, when features were tacked on, they often stay out of the way instead of adding complexity to day- to-day operations. However, I'm not sure they've aged well, but I guess they are the best we have at the moment.

<comment><USER27> IMHO, the Linux programming environment is a mess precisely because not everything is a file handler - not even sockets, as even though sockets can behave like files, there are differences. Plan9 was supposed to be the reinvention of Unix and a lot of useful stuff was ported from Plan9 to modern- day Linux, including the /proc filesystem which is really, really useful.

Unfortunately the UNIX philosophy is so powerful that you don't understand it until you live and breathe UNIX. And it also doesn't scale for some use-cases, but this philosophy is the reason why UNIX is not only alive, but the dominant platform.

Also, HyperCard is NOT a " _small set of interoperable tools_ ". And neither is Excel.

<comment><USER8> Though I haven't done any Linux programming, I can definitely see your point. A abstraction seems only as useful as it is consistent.

You're right: HyperCard and Excel aren't a small set of interoperable tools like UNIX is. I would argue, though, that they are close: a walled garden of interoperable tools. Rather than guide you through steps to a specific end (the extreme example is a wizard for, say, a mail merge), they present you with tools you can use to get to that end. Obviously, they don't work particularly well outside their garden, and the great advantage of adding tools to your toolset is cumbersome at best.

I do wish I understood the UNIX philosophy better. Perhaps I'll learn more over time.

</comment></comment></comment><comment><USER28> I loved Hypercard and BASIC too, but this post strikes me as being a little affected by nostalgia.

With Hypercard you could make something for someone who 1) has an Apple, 2) Has Hypercard installed, and 3) Has the right version of Hypercard installed.

With HTML/CSS/Javascript you can make something to run almost anywhere. It's not 'easy' but it is useful.

<comment><USER4> _> With HTML/CSS/Javascript you can make something to run almost anywhere._

With gargantuan effort.

And your creation will still appear distorted in unpredictable ways to many users.

</comment></comment><comment><USER28> Don't forget, there's Hackety Hack <http://hackety-hack.com/> and Scratch <http://scratch.mit.edu/>, two great tools for new programmers to get their feet wet and make something fun in the process!

</comment><comment><USER29> There's no mystery, here. No great conspiracy -- the article has a screenshot of the smoking gun.

<http://www.loper-os.org/wp-content/hypercard-calc/hc12.jpg>

The scripting language had a verbosity and ambiguity that only a lawyer could love. The documentation for that language was similarly impenetrable to anyone with a background in CS, requiring a serious commitment to trial and error to perform operations that were trivial in BASIC.

<comment><USER21> It looks that way, but it is not that verbose. Compare:

        get name of me
        put the value of the last word of it after card field "lcd"

with

        it = event.target.name
        currentCard.fields["lcd"].append(it.text.asWords().last())

It looks verbose, and in some sense it is, but having lots of implicit state made it a nice environment for what it was.

</comment></comment><comment><USER30> Visual Basic played a similar role for me many years ago. I've moved on since, but at the time it was exactly what I needed. The value of a WYSIWYG GUI editor and a simple event system to a budding developer can't be overstated.

</comment><comment><USER31> I think it'd be interesting to re-write HyperCard in javascript and HTML5, as a way to get kids interested in coding (and maybe use javascript instead of apple script as the card language?). Not sure how difficult this would be as I've never actually used it, only heard of it's majesty and wonder. Cool that you can still run it on an emulator. I'll have to try it out.

</comment><comment><USER32> If the author loves HyperCard so much why doesn't he re-create it? Honestly, it would not take that long.

The answer is because he'd rather write some link bait trashing Apple and Steve Jobs.

And because he knows perfectly well that making HyperCard is not worth his time.

IMHO his calculator example makes it perfectly obvious why HyperCard not only was killed but deserved to die. Like all of Apple's languages of the time, HyperTalk is awful. Additionally HyperCard is not particularly flexible or elegant, nor does it produce particularly fantastic end results. It's crap.

And in a day like today where we have the web enabling people who have never even heard of a pointer (let alone had to deal with pointer math) to write full fledged, performant, distributed, multi-user applications, why does anyone in their right mind spend 5 minute bemoaning the loss of HyperCard? It's absurdity.

</comment><comment><USER33> The code for this could have simpler/less verbose. It's been a while, but I believe in the number buttons this would have worked:

        put the short name of me after fld "lcd"

and in the equals sign button:

        put the value of fld "lcd" into fld "lcd"

(edited to fix a missing quote)

<comment><USER4> Thanks!

Also there is an extra eval (the first one is unnecessary, I think.) But I am too lazy to revise the screenshots.

</comment></comment><comment><USER34> I remember making a game with hyper card when I was at school and loved that I could visually script the buttons.

We hand drew pictures of 3D rooms and then scanned them in and put big invisible buttons over the doors etc.

I personally think the www killed hyper card, suddenly you could do very similar things but have them instantly shared globally.

In my mind hypercards real innovation was creating your own links which would take you to any other card you desired, I think plain old simple HTML came along and killed the poor thing. HyperCard lived in a time of share it on a disc and I imagine Jobs seeing it's days as numbered.

<comment><USER8> Bill Atkinson, the creator of Hypercard, is on record [1] wishing he'd had the foresight to extend the links to the network. Hypercard was inches away from being the first "web browser".

[1] [http://www.wired.com/gadgets/mac/commentary/cultofmac/2002/0...](http://www.wired.com/gadgets/mac/commentary/cultofmac/2002/08/54370)

</comment></comment><comment><USER35> Hypercard was very interesting to me, enough so that I bought my first programming book, Danny Goodman's The Complete Hypercard Handbook. I loved tinkering about with Hypercard on my very first computer, a Powerbook 100 that I bought new in 1992.

I was sad when Apple decided to only include Hypercard Player with new Macs, which I also think ultimately helped contribute to its death. People liked Hypercard but not enough to pay money for it. By the time Steve killed it, it was a lumbering zombie of its former self.

</comment><comment><USER36> The thing I've always felt held back these paradigms is something that is inherent in them, they are too visual.

That sounds crazy, but just look at this article and how he described what he did. He had to take a million screenshots to show it. The same is true for say, the Android app builder, or the Lego logic thing.. the way you sure code is via a screenshot.

And that just doesn't scale very well I don't think. It makes copy/pasting, the most basic way that people learn, really difficult.

HTML5 is pretty awesome, or rather WOULD be pretty awesome if we could erase the last 15 years and all start with CSS3 compliant browsers. But it is such a mess now that I feel bad for anybody starting from scratch.

But the combination of HTML for layout and Javascript for layout is pretty darn powerful, and I think pretty accessible as well. You could certainly build something on the order of the simplicity of Hypercard on that stack.

But I do like the author's comments about the shame that there are far fewer 'programmers' than back in the old days. BASIC on the AppleII is of course the other example (among others).. where it was just so easy and almost natural for ANY user to start getting a feel for things and hacking around. Losing that really IS a shame.

</comment><comment><USER37> I remember using hyper studio (later version) in 5th grade in ~96. That was one of my earlier "programming" experiences and I spent a lot of time making a shooter called teddy bear doom for our class. However, the next year I found vb and found it a lot more flexible (I also decided I was a pc about that time)

The author makes an interesting point re: computers as bicycle vs train, that nothing like HyperCard exists today and apple now has a clear and hard separation between laying track and riding on it. I agree, but I wonder if HyperCard (or a modern version) makes the same mistake many wysiwyg solutions make: if you do something enough, you'll want more capable tools, and if you're a casual hobbyist, the wysiwyg solution will be too complicated anyway, with a disjointed interaction metaphor to boot. If I were a 5th grader today, I think I'd be better served by starting with python than something like hypercard.

</comment><comment><USER38> The author makes a very valid point: the modern Way of personal computing is about the controlled user experience; allowing people to get their mess all over with their own work would disrupt that Way.

Don't appreciate the crack about the 'aspie software engineer' though. Definitely not needed.

</comment><comment><USER39> Has this guy played with Interfave Builder lately? I fail to see his point. Apple has poured tons of resources into making development for its devices simpler, and that's part of the reason you have so many amateur apps on the App Store.

Jobs understood the division of responsibility between Apple, with its extremely limited resources, and its developer community. What wasn't core to selling computers was cut. We are talking about a company that was 90 days from bankruptcy when he took over. I think he made a good decision.

If somebody has wanted to do a proper visual programming environment in the vein of HyperCard for the Mac, what in the last 13 years has stopped them? It wasn't Jobs.

<comment><USER40> _Has this guy played with Interfave Builder lately?_

This guy writes a lot of well executed but fundamentally vacuous articles; I wrote about a previous one here: [http://jseliger.com/2010/09/30/computers- and-network-effects...](http://jseliger.com/2010/09/30/computers-and-network- effects-why-your-computer-is-slow/) last year. At this point, PG's essay: <http://www.paulgraham.com/trolls.html> applies to him. But you wouldn't notice as much from any _individual_ article or submission; it's only through the collection that his tactics become apparent.

<comment><USER41> I think he's more of a crackpot than a troll (and I think the difference matters).

</comment></comment></comment><comment><USER42> He's kind of pissed off. I see nothing special with it except for the "natural" language.

<comment><USER17> Y'know, I can see where he's coming from. I'll get to that in a moment, but first: I'm starting to get a little sick of HN's tone lately. I'll readily admit that I've contributed to that in the past, but some of the comments in this thread ("person is a troll", "writes vacuous posts", "is a crackpot") are really over the top asinine.

He's a better person than I am, because if it were me, I'd already have a script in place that checked the referrer and would post a blank page with "Eat a dick" for anybody coming from HN. If nothing else, it would ensure that the submission wouldn't get as many upvotes (or would get flagged) and I wouldn't feel compelled to put up with the abuse.

Anyway:

So, IIRC, my progression as a young programmer went something like: BASIC on a Commodore 64 / Vic-20, to Logo on I-don't-remember, to HyperCard (and then on to QBasic and Pascal and C and C++ and OOP and on and on).

HyperCard was amazing because its barrier-to-entry was so, so low, and I agree with the author's comments that there still isn't anything quite like it. For one thing, it was on most Macs by default at the time, so you didn't have to find a copy of the software and install it first.

As he shows, it was a piece of cake to get started with. A budding HyperCard programmer could easily learn new tricks by downloading anybody's stack and reading the code. Since it wasn't compiled, you could learn from it. Anything that anybody else did, you could take apart, and learn how to do.

And it grew with you. You could make something as simple or as complex as you wanted. My very first, very naive foray into AI was in HyperTalk; I discovered I could write self-modifying stacks, and decided to see if I could teach a HyperTalk stack to talk to me like a person.

HyperCard also introduced me to online forums for the first time. I still remember, fondly, downloading J5iverson's XFCNs from eWorld. From there, I discovered the world of the early internet -- the alternative to BBSs. Whereas BBSs at the time let me easily chat with someone else in my town (or, more often, play TradeWars or something), eWorld let me chat with people "across the pond" for the first time. For a young kid, this was a life-changing, world-shrinking event.

I disagree with the comments that SuperCard is a reasonable alternative. I don't remember the details now, but while I appreciated the addition of color in SuperCard, it brought with it other complexities that I disliked. I played around with SuperCard but ultimately went back to HyperCard.

So, what I'm getting at is, if it weren't for HyperCard, I don't think I'd be a programmer right now. HyperCard was simple enough for a beginner, and rich enough to keep my interest. It was a _huge_ influence on me. I really can't overstate that.

Almost two decades later, I was approached by an employer who wanted me to teach computer programming to his son. His son was young, not yet in high school, pretty sharp, and, y'know, geeky. Liked video games, liked taking things apart. Not exactly a challenging pupil in terms of motivation.

I spent a ton of time trying to figure out just what in the hell environment to use to teach him. JavaScript? You have to know a _lot_ of other stuff before you can really begin to do anything of value in JavaScript. Before we could do the calculator example in the author's blog post in JavaScript, I'd have to teach basics of HTML, the DOM, and eventually we'd either end up using JQuery or going over the whole "browsers are different in how they handle the same code" discussion, which, honestly, is one of the most stupid problems in the history of computing when you think about it.

Anyway, I went through a bunch of options and finally settled on something called Kids Programming Language (or Phrogram). What a damned mess that was. It wasn't very long before I had to teach the concept of objects to the kid. And scope. And then half the time the entire environment would just up and crash with no helpful explanation. There's a fun problem for a newbie programmer: write some code, your environment crashes, no explanation.

If the field has improved much since then, I'm unaware of it. Not having something like HyperCard available to young programmers really is a tragedy, because it means that future programmers are going to be introduced to programming in college (which, often, is a joke, and IMO also too late in an individual's mental development), or they're going to have to tough it out through JavaScript or Ruby or Python or whatever the inscrutable popular language-of-the-month is, and that's going to really narrow down the field of people interested in getting into programming.

Some free market adherents might respond with, "Well, if there was demand, someone would build it, so obviously there's no demand". Honestly, I find that entire argument completely boring. It's clear that there _was_ a lot of demand for it; did nobody want it before it was invented, and has nobody wanted it since it became no longer supported? I don't think so. I think there is a market for such a thing, and it just hasn't been built yet.

I really hope it will be. It's already on my list of near-future projects if nobody else does it first.

<comment><USER4> Finally, a breath of sanity on HN.

</comment></comment></comment><comment><USER43> Alan Kay's STEPS project drew some inspiration from Hypercard. I haven't gotten to try it, alas. <http://www.vpri.org/pdf/tr2011004_steps11.pdf>

</comment><comment><USER44> Who remembers the HyperCard Smut Stack? [http://finance.groups.yahoo.com/group/HyperCard/message/2809...](http://finance.groups.yahoo.com/group/HyperCard/message/28096)

</comment><comment><USER45> Hypercard was a wonder. I used to teach street people how to make simple, useful applications that they thought of themselves.

Sure it was limited in what it did, and that was part of its beauty. It was a tool for quickly hacking together a simple application. A tool that nearly anyone could learn to use quickly. And it was fun and spontaneous.

And the Hypertalk language was very interesting to work in. It was like a limited dialect of a spoken language; a pidgin for computers.

</comment><comment><USER46> Still surprised that nobody's made the connection to FileMaker.

FileMaker actually _predates_ Hypercard (depending how you define it), and is similar to the point where you can still find Hypercard->FileMaker conversion tools.

Filemaker is also screens + controls + simple scripting language (albeit not quite as easy to grasp as HyperTalk/Applescript), and is wildly popular for an audience similar to that of Hypercard users.

</comment><comment><USER44> Does anyone remember publishing HyperCard stacks on the web with the WebStar mac web server? That was pretty cool! It even translated the controls and fields on the stack to html forms that worked in the web browser. <http://220.127.116.11/HyperCGI.html>

</comment><comment><USER11> I think HyperCard was special in that other people's stacks were easy to come by, and easy to disassemble. There was no compiled distributable form, all stacks could be cracked open if you wanted to see how they ticked, and just modified just as easily if you wanted to see how the program's behavior would change.

</comment><comment><USER47> Filemaker is similar to Hypercard.. <http://www.filemaker.com/>

<comment><USER48> You know what's actually the product I've met with the most similarity to HyperCard? _Microsoft PowerPoint_. You have cards, buttons that can navigate between them in arbitrary ways, effects that can trigger on loading or unloading a card, etc. And for everything else, you have VBA, which, like AppleScript, allows buttons and fields to do arbitrary things (with generic COM objects, even!) I once wrote a full-scale Dragon-Quest-style CRPG in PowerPoint, using the cards as a scene graph; it was actually quite friendly.

<comment><USER49> There's some truth to this (as appalling as the notion is). While I'm teaching Python to my 7th grade nephew his school is having him 'program' in Powerpoint. As dismissive as I am of the notion, it does allow students to quickly get some stuff up on the screen and start being interactive.

Fortunately my nephew has taken to Python and is even starting to become a language snob "That looks like a stupid way to program".

<comment><USER48> Hmm... putting PowerPoint and Python side-by-side reminds me a little of Shoes (<http://shoesrb.com/>), which is also something that "allow[s] students to quickly get some stuff up on the screen and start being interactive", but is purely code-based, rather than having any sort of GUI interface construction tool.

</comment></comment></comment></comment><comment><USER50> Wow, that brings back some happy memories. Writing Eliza style chat bots on my Mac SE in Hypercard was a lot of fun :)

Fun fact: the best selling game Myst was developed in Hypercard!</comment>