The Toyota Way - <AUTHOR> https://en.wikipedia.org/wiki/The_Toyota_Way <comment><USER4> In the 1960s, my father was a manufacturing engineer for BigTechFirm (this was back when BigTechFirms built actual stuff, rather than trafficking in webshit). On the shop floor, there were A, B, and C workers on a line in descending order of skill level required and roughly ascending order of available workers. It was a true assembly line model. I believe the A and B workers had more variety to their work but the C workers had precisely one job, like putting two parts together along a joint or tightening a specific set of screws. This introduced problems in the line when a C worker got sick: the line would be held up entirely while a substitute was trained and then the substitute would perform much more poorly than the sick worker.

My father's bright idea was to give each C worker a workbench and train them in several jobs, then have them perform all those jobs in one phase of the assembly. That way, if a C worker got sick, because all of their colleagues knew all the jobs that worker had to do, the line would be held up much less.

Upper management passed on my dad's idea back then -- but it became all the rage in the 1980s when it was rediscovered in the Toyota model, part of the massive fad for "Japanese management techniques" that prevailed back then.

I keep this story in mind when I have to deal with agileshit at a company whose management had apparently never heard of _The Mythical Man-Month_.

<comment><USER5> What is webshit? It seems like you are trying to say that you don't think web developers build anything worthwhile, but I'm hoping there's a less insulting interpretation of your comment?

<comment><USER4> Television was developed with the intent of bringing culture, like Shakespeare to the masses -- but it was more profitable to present cheap-to-make, lowest- common-denominator entertainment and an increasing number of ads. Similarly, the Web was supposed to be a global information resource for scientific papers and other human knowledge, but the companies that dominate the Web today have turned it into television that watches back.

Somewhere there are Web developers adding real value. Sometimes I like to think I'm one of them. But that's not the LOB of the big players.

</comment></comment></comment><comment><USER6> "The Machine That Changed the World" is a wonderful title on this. Kiichiro Toyoda invented the lean production model after coming to the states and studying the inefficiencies of the assembly lines of Ford. This was a process dependent on modularizing every manufacturing component due to a demand for the Toyota company to serve a market with a need for an immense variety of vehicles, and giving teams ownership of the entire production process rather than one error check at the end a lá Ford. Introducing a vehicle with a steering wheel on the opposite side might take a year to implement in lean production, while handling that kind of variation in the assembly line model could take years (generally double the amount of time); The net result of this being that Toyota could offer 2x the vehicles of GM at half GM's size. Toyota was able to make extremely reliable vehicles and modify them as consumer demands shifted. By 1990, the Japanese were making cars with 4 year product lives and 500k total units (125k per year) while the Western companies were building 2M over 10 year product lives.

<comment><USER7> Ironically Toyota now has longer product lives than many other mainstream manufacturers. The Camry and Corolla are on roughly 6 year product lifecycles. The 4Runner has barely changed in 10 years.

<comment><USER8> > The 4Runner has barely changed in 10 years.

To be fair, that may be a purposeful design decision.

I consider the fact that the 4Runner can trace its way back to a 1980s Hilux that Top Gear dropped off a building (and still survived) to be nothing but good for its likely reliability.

Similarly, its primarily dial-based dashboard (as opposed to the touch-screen everywhere fad right now), truck-based suspension, and off-road performance (all things that could point to it being a rather much for a city car) to be its primary selling points.

Additionally, why change what sells so well? They sell ~140,000 4Runners a year, vs all of the Lexus models combined being ~40,000.

I can't comment on the Camry/Corolla as I've never owned one.

<comment><USER9> That's incorrect by an order of magnitude. Lexus sells in excess of half a million cars per year.

<comment><USER8> I stand corrected.

Having performed some cursory 'research' I found that in the USA in 2018, according to [https://www.best-selling-cars.com/brands/2018-full-year- usa-...](https://www.best-selling-cars.com/brands/2018-full-year-usa-toyota- north-america-and-lexus-sales/)

All Lexus vehicles combined sold 92,660 units versus the 4Runner model which sold 139,694 units.

A difference of 47,000 units, or roughly, the 2018 US sales for the Lexus ES

<comment><USER10> At a guess the USA is not the primary market for Lexus.

<comment><USER11> America is 100% the primary market for Lexus.

The first Lexus car ever was unveiled in the 1989 Detroit Auto Show, Toyota's first non-Japanese Lexus plant was in North America. In fact, Toyota stopped selling top-of-the-line cars after Lexus launched, they discontinued the Cressida and stretched the Camry into the Avalon just to have a full-sized Toyota in America.

Toyota didn't even sell Lexus cars in Japan until ~2006, the American Lexus vehicles were badged as Toyotas (e.g The LS400/LS430 was the 'Celsior'). Additionally, Japanese luxury tastes are different than American tastes - <USER2> Japanese Toyota Celsiors were available with a premium cloth interior and without sunroofs (which came standard on many American Lexus cars).

Now, Lexus may sell more in the Middle East than North America (by revenue if not units) but America was 100% the target market.

</comment></comment></comment></comment></comment></comment></comment><comment><USER12> Whenever I see articles like this, I like to remind people that a great production system doesn't make a company more honest or accountable.

Unintended acceleration flaw in Toyota models around 2005 to 2011, due to firmware bugs: [http://www.safetyresearch.net/blog/articles/toyota- unintende...](http://www.safetyresearch.net/blog/articles/toyota-unintended- acceleration-and-big-bowl-%E2%80%9Cspaghetti%E2%80%9D-code)

Great for USA customers. They were made whole.

I personally was driving a 2011 Toyota minivan in Thailand in 2013 when I suffered this firmware bug. Toyota refused to consider it was anything other than driver fault. I was only going 5kph when it happened so no damage, but damn scary as hell. No recall in that country, and unless dealers did a covert firmware upgrade during maintenance, the flaw still exists in similar model years.

<comment><USER13> Weirdest thing, a colleague had unintended acceleration in a Toyota 4WD of much older vintage, 80s or early 90s. Must have been something different entirely, those things were much more mechanical in nature.

<comment><USER14> Most cases of unintended acceleration, in all brands of cars, are due to the foot coming down on the wrong pedal. And then in a panic, your brain refuses to acknowledge the error and doubles down. Your memory gets based on what your brain thought, and not what actually happened.

US government estimates are that this happens an average of around 16k times per year in the USA. The press release that Wikipedia cites for that has disappeared but you can find it on the wayback machine: [https://web.archive.org/web/20180423205652/https://www.nhtsa...](https://web.archive.org/web/20180423205652/https://www.nhtsa.gov/press- releases/nhtsa-safety-advisory-reducing-crashes-caused-pedal-error)

Toyota's acknowledged problem was a floor mat that could get jammed and cause the accelerator to stick. However most of their cases of unintended acceleration were still likely to be human error.

<comment><USER12> I'm sorry but you are wrong regarding the Toyota problem.

There was (is?) a firmware issue that caused the vehicle to attempt to speed up, regardless of if the accelerator was pressed, or even if the brake was pressed.

In my case, I had the brake fully depressed with around 100kg of force, and the engine was revving to attempt to overcome the brake (VERY scary situation, believe me!). The system only recovered when I bumped a taxi in front of me.

Now you may say I was pushing the accelerator. If I did that I would have hit the car in front of me a lot faster than 5kph. If I was somehow pushing both the accelerator and the brake, the computer system should ignore the acceleration anyway (due to brake taking precedence).

But you don't have to take my word for it. Go read up on the Toyota firmware issue, starting with link I put in the prior post.

EDIT: here's another article, summarizing the faults as determined by court: [https://www.edn.com/design/automotive/4423428/Toyota-s- kille...](https://www.edn.com/design/automotive/4423428/Toyota-s-killer- firmware--Bad-design-and-its-consequences)

\- Toyota's electronic throttle control system (ETCS) source code is of unreasonable quality.

\- Toyota's source code is defective and contains bugs, including bugs that can cause unintended acceleration (UA).

\- Code-quality metrics predict presence of additional bugs.

\- Toyota's fail safes are defective and inadequate (referring to them as a "house of cards" safety architecture).

\- Misbehaviors of Toyota's ETCS are a cause of UA.

<comment><USER15> >I had the brake fully depressed with around 100kg of force, and the engine was revving to attempt to overcome the brake

No, it wasn't. An engine's speed (RPM / "revs") is directly proportional to the drivetrain speed -- the RPMs literally _cannot_ increase unless you are 1) accelerating (actual drivetrain speed going up), 2) shift to a lower gear then slip torque converter to rev match (I assume you're driving automatic), or 3) disengaged from the drivetrain (in neutral gear) and hitting the gas.

There's no way for an engine to be "revving" to overcome braking. Hop in a manual car, get up to a normal speed in any gear, then try hitting both the brake and gas.

<comment><USER16> This is just plain wrong. The poster didn't say they were at a standstill but that they had the brake pedal pressed. That means the engine could have downshifted into 1st gear and started to rev noticeably. The engine would also produce more power (and sound very different) when taking up load, even under the same RPM. Finally, as the other reply pointed out, the engine can spin a clutch or CVT.

<comment><USER17> The poster said that the brake was fully depressed with around 100kg of force. It won't take long for that to be in a standstill. And there's no way acceleration can overpower that kind of brake power. The sound might be scary but it won't change much about brake performance.

<comment><USER13> Bad clutch plus bad brakes (but not so bad as to be unserviceable in light, normal use). Story is not implausible.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER18> They should call this "The Deming Way" since most of it sounds identical to Deming's management philosophy and he taught Toyota back in the 1960s[1]. His system also had 14 points, which probably isn't a coincidence[2].

[1] [https://blog.deming.org/2016/10/toyotas-management- history/](https://blog.deming.org/2016/10/toyotas-management-history/)

[2] [https://en.wikipedia.org/wiki/W._Edwards_Deming](https://en.wikipedia.org/wiki/W._Edwards_Deming)

<comment><USER19> Thanks for sharing! Good read

<comment><USER18> Thanks for reading! I think Deming is extremely under-appreciated.

It seems like Six Sigma is all anyone talks about in terms of management philosophy these days...

<comment><USER20> Deming's work has been highly influential within the DevOps community:

[https://itrevolution.com/deming-to-devops- part-1/](https://itrevolution.com/deming-to-devops-part-1/)

</comment></comment></comment></comment><comment><USER21> I love the Toyota books, read almost any book that is somehow connected to TPS, Toyota, Lean and such.

There is a really fun to read a trilogy by Michael Ballé, the first book is called "The Gold Mine".

And from Goldratt, all of his books and videos and related material is also a favorite. Specifically, about Toyota, Eli Goldratt wrote an article that provides the historical context and what problems Toyota solved, and then continue to improve upon that solution to invent a new solution that is even more amazing. Highly recommended 10m read for free here [https://www.goldrattconsulting.com/webfiles/fck/files/Standi...](https://www.goldrattconsulting.com/webfiles/fck/files/Standing- on-the-Shoulders-of-Giants.pdf)

</comment><comment><USER22> >Principle 5 Build a culture of stopping to fix problems, to get quality right the first time. Quality takes precedence (Jidoka). Any employee in the Toyota Production System has the authority to stop the process to signal a quality issue.

I heard culturally Japan and to an extent other Asian manufacturing nations would never actually press the button. Can anyone confirm this?

<comment><USER23> If you can get your hands on the HBS case study of TPS it's a great read. Details how much emphasis is put on blaming any/all issues on process, rather than people. To the extent that if a clumsy worker drops a wrench, it is assumed to be a problem with process, not that worker, and addressed immediately. The case study also describes a couple of examples of assembly line workers pulling the stop levers and how management runs over asap (every minute of stoppage is much money lost) to ask the question "why" five times in order to understand the root issue of the process breakdown.

<comment><USER24> > The case study also describes a couple of examples of assembly line workers > pulling the stop levers and how management runs over asap (every minute of > stoppage is much money lost) to ask the question "why" five times in order > to understand the root issue of the process breakdown.

More than that, when the manager approaches the employee who stopped the line, she is not supposed to ask, "why did you stop the line?" She instead asks, "how can I help?"

</comment></comment></comment><comment><USER25> My favorite book in this topic is "The High-Velocity Edge: How Market Leaders Leverage Operational Excellence to Beat the Competition: Second Edition" by Steven J. Spear (Formerly "Chasing The Rabbit")

Also really good: Deming wrote his perspective in "Out of Crisis" and Toyota's Taiichi Ohno wrote about his experience in "Toyota Production System: Beyond Large-Scale Production". As others have mentioned, Deming laid the ground work for this type of thinking in post-war Japan. Taiichi Ohno led the initial development of the Toyota Production System.

</comment><comment><USER26> How do you maintain "Principle 1" while being a publicly traded company?

The way the stock market is designed (and the fact that stockholders often get to appoint the board who gets to appoint the CEO) means they're going to put short term profits over long term viability. Many companies have been ruined and continue to be ruined by this short-term-ism chase for quarterly and yearly profits.

For example look at the field of Customer Retentions. It used to be focused on satisfaction & delight which are both long term success strategies (both to grow and to retain), but in the last twenty years Customer Switching (i.e. making it harder/more costly/more time consuming/more stressful/etc to switch) has become the norm, this is a short term strategy since it improves short term retention metrics at the cost of long term returning customers and poor word of mouth (i.e. nobody returns or joins after they leave, if you made the switching process hellish). It is a great way to keep your quarterly and yearly churn low, but a poor way to run a business.

It used to only be businesses with artificial monopolies that would do this (e.g. Verizon, Comcast, etc). But recently we've seen companies in fairly competitive spaces adopted a similar short term "suicide strategy" like LogMeIn (Remote Support Software), The New York Times (News Publication), SiriusXM (streaming audio), etc. All of which are likely chasing quarterly performance metrics tied to executive compensation.

<comment><USER27> While that is a common statement, it isn't really true. Most stock holders have figured out that long term profits are important as well. Companies that only focus short term go out of business quickly and so are worth less than companies who will be around longer.

Most shareholders (37%) are retirement accounts which have long term goals.

<comment><USER28> > _Most stock holders have figured out that long term profits are important as > well. Companies that only focus short term go out of business quickly and so > are worth less than companies who will be around longer._

Doesn't matter if the stock holders who pushed for the decisions managed to flip their stocks when they were still rising in value. Aren't most stock holders playing this game to flip stocks, without caring much about the particular company they're making money off?

<comment><USER29> Aren't most stocks are held in index funds and ETFs?

<comment><USER28> I don't know. Could someone who knows this for sure chime in here?

<comment><USER7> Yahoo Finance will show you the top holders for any publicly traded company.

[https://finance.yahoo.com/quote/TM/holders?p=TM](https://finance.yahoo.com/quote/TM/holders?p=TM)

</comment></comment></comment></comment></comment></comment><comment><USER30> FYI, practice of Kanban also comes from Toyota: [https://en.wikipedia.org/wiki/Kanban](https://en.wikipedia.org/wiki/Kanban)

</comment><comment><USER31> A lot of this was covered in "The Phoenix Project". A good read but a bit idealistic in the expected outcome. The fake company was essentially able to right the sinking ship after the band had already stopped playing, in 2 quarters no less.

However, the core tenets were valid from a general approach. My fear when reading was the potential to go overboard. We have all met over-zealous scrum masters. Same could be applied to a lot of the stuff they were essentially transferring from manufacturing to development and more specifically devops.

<comment><USER32> It's worth reading _The Goal_ as _The Phoenix Project_ is somewhat based on it. _The Goal_ introduces the idea of Theory of Constraints in a similar novelized form, and _The Phoenix Project_ takes ToC and applies it to information systems/software work. There's overlap between ToC and the Toyota Way (Toyota Production System, Lean, etc.) as all are based on taking a systems view of things, and place a great deal of emphasis on identifying problems with the process, not the people (that is, no individual blame).

<comment><USER33> I had a CTO loan me "The Goal" after I came back from USENIX in Boston (2011) talking about devops and shite... Its a good read and gave context to the Phoenix project without being a spoiler...

</comment></comment></comment><comment><USER34> And what I have seen (working in a similarly famous Japanese company) is that while these management models are quite powerful, they lack interpretation in the modern age - that is to say, how they apply to systems, data, software, etc. For example, if data quality is not respected holistically (an extension of the focus on "quality"), the organization and its constituents (customers, employees, stakeholders) suffer.

</comment><comment><USER35> Why don't software professionals defer more to the likes of Nintendo, Konami, and other Japanese software companies rather than this manufacturing process?

<comment><USER32> Are those companies known for their speed and quality of code delivery? Have they published studies and popularised their approaches? Have they, or anyone else, generalized their approaches to things other than specific software categories?

The thing about the manufacturing processes that have come out of Toyota (and others), or the ideas from Deming, Goldratt, and others, is that they're more about general systems theory. What is the flow through the system? How do we know when is an appropriate time to do X? How do we know the focus should be on improving the sales team and not the development team or vice versa?

It may seem like a focus on a manufacturing is misplaced, but many of the ideas transfers over to services as well. Within your business, you have processes which are repeated regularly, information flows with bottlenecks. Which of those should you focus on improving? How do you determine that? How do you measure the improvement efforts? How do you choose how to improve something (top-down directive, or bottom-up participatory effort)? Study Lean, Theory of Constraints, and systems theory and you'll get some answers and ideas.

<comment><USER35> Nintendo releases more software than Toyota

<comment><USER32> Maybe don't edit your post next time? Especially after people have replied. That's a very dishonest mode of discussion.

<comment><USER36> What was edited? The discussion still appears to make sense.

<comment><USER35> The point is dear friends and colleagues, that none of us signed up to be computer professionals only to have our craft usurped by a bunch of management types trying to make a name for themselves by spouting eastern philosophies and wearing ragged golf shirts

I am tired of having a textbook thrown at me every time I ask a human question and treated like a factory floor worker by human automata and recent grads suffering from impostor syndrome

I know there is more to software than bottlenecks and efficiencies and all that tripe it seems quality and quantity are the only measures may as well go back to East Germany where all this bullshit emanates from in the first place

Even the damned ranking system on hacker news is an echo to the system used in North Korea. Software has become a breeding ground of groupthink and it's this kind of crap that fuels it

Are you seriously telling me Toyota is a better software company than Nintendo?

</comment></comment></comment></comment></comment></comment><comment><USER37> Those interested might also find these worth reading:

Deming and Software Development

      https://management.curiouscatblog.net/2014/03/17/deming-and-software-development/

What's Deming Got to Do With Agile Software Development and Kanban

      https://blog.deming.org/2013/07/whats-deming-got-to-do-with-agile-software-development-and-kanban/

<comment><USER38> Please just put links on a normal line of text — code formatting prevents them from being rendered as clickable links. It also makes them harder to read on mobile.

</comment></comment><comment><USER39> This Toyota stuff gets a little bit of a bad rap in some circles, because of the infamous "TPS report" thing - some people believe it's a reference to "Toyota Production System." My understanding is that the Office Space reference was actually meant to be to Testing Procedure Specification documents, but it's hard to be sure.

In any case, Toyota / Lean / etc. is a mindset that has a lot of really good ideas embedded in it. I'm sure you can take it and distort it and come up with a monstrosity (like people do with "Agile") but the core stuff is really good.

As noted by lemax, _The Machine That Changed The World_ is a really good book on this topic.

It's also interesting to note that a lot of the "Toyota" system was inspired by the teachings of an American, W. Edwards Deming. If I recall the story correctly, Deming was pushing these ideas on statistical process control, and nobody in America would listen to him, so he want to Japan and they embraced his stuff, ran with it, and it helped them become a manufacturing juggernaut.

<comment><USER40> I'm pretty sure the writers of Office Space have gone on record saying "TPS report" is a meaningless term used simply to evoke a sense of wasteful bureaucratic nonsense.

<comment><USER39> Hmm... this article[1] cites an interview with Mike Judge where he says it mean "Test Program Set" when he was an engineer.

Anyway, I've seen more than a few people jump to the conclusion that it stands for something to do with the "Toyota Production System" which is unfortunate.

[1]: [http://mentalfloss.com/article/57338/what-tps- report](http://mentalfloss.com/article/57338/what-tps-report)

<comment><USER41> That's too bad. It's quite funny thinking Toyota Production System is where TPS reports come from because it's so believable. Even though Toyota switched to Agile-ish methodologies, they still produce 20x the documentation and paperwork that the Waterfall method produces!

</comment></comment></comment></comment><comment><USER42> A resonably good read: [https://www.thedrive.com/tech/26955/inside-toyotas- takaoka-2...](https://www.thedrive.com/tech/26955/inside-toyotas- takaoka-2-line-the-most-flexible-line-in-the-world)

 _How do you double output to 500,000 cars a year? "Easy," you say, "just make that line run faster."_

</comment><comment><USER43> "Work like the tortoise, not the hare."

I knew I was onto something.

<comment><USER44> Completely unrelated but...

I was listening to the "The Rocky Road to Dublin" when reading your comment during the "hunt the hare" part.

Funny coincidence.

<comment><USER45> Which version? The Dubliners recording (with Luke Kelly singing) is one of my favorite songs of all time.

<comment><USER44> This one: [https://www.youtube.com/watch?v=jxBKgOyMzSc](https://www.youtube.com/watch?v=jxBKgOyMzSc)

Edit:

Although this one is pretty good too!

[https://www.youtube.com/watch?v=0QdbeM2JWYE](https://www.youtube.com/watch?v=0QdbeM2JWYE)

</comment></comment></comment></comment><comment><USER46> This American Life had an interesting episode.

A car plant in Fremont California that might have saved the U.S. car industry. In 1984, General Motors and Toyota opened NUMMI as a joint venture. Toyota showed GM the secrets of its production system: How it made cars of much higher quality and much lower cost than GM achieved. Frank Langfitt explains why GM didn't learn the lessons—until it was too late.

[https://www.thisamericanlife.org/561/nummi-2015](https://www.thisamericanlife.org/561/nummi-2015)

</comment><comment><USER47> Curious would anyone like to learn about Toyota production system (lean manufacturing) implementation at Zenbooth factory in Berkeley, CA? We've thought about doing tours.

<comment><USER48> If I was in the USA, in a heartbeat. I have got so much buy-in in the past by taking senior people on tours and showing them the things I am trying to get them to buy. Seeing things in action is much more powerful for many people than dry documents.

</comment></comment><comment><USER49> I enjoyed this fiction book that covers a story of a business professional learning the Toyota business system from a mentor. It's a quick worthwhile read. Non-affiliate Amazon link here: [https://www.amazon.com/Andy-Me-Crisis- Transformation-Journey...](https://www.amazon.com/Andy-Me-Crisis- Transformation-Journey/dp/1439825386)

</comment><comment><USER50> This is no longer the case. Toyota quality is been slipping lately. I got a brand new Toyota the dealer had to replace transmission after 3k.

<comment><USER51> Where was it made? Anything outside of Japan won't benefit from the culturally pervasive perfectionism.

</comment></comment><comment><USER52> Isn't this based on a "philosophy" published by Bell Labs a couple of decades prior?

<comment><USER32> Can you point to a source or resource on that?

<comment><USER52> I've read it mentioned a number of places - as it's somewhat mythical - <USER3> the source that comes to mind at the moment - but perhaps I'm getting it wrong? - was the book "Creativity Inc."

[https://en.wikipedia.org/wiki/Creativity%2C_Inc](https://en.wikipedia.org/wiki/Creativity%2C_Inc).

</comment></comment></comment><comment><USER53> When US and Japan car makers join forces:

[https://www.youtube.com/watch?v=7trB7i2xpfc](https://www.youtube.com/watch?v=7trB7i2xpfc)

</comment><comment><USER54> They list "motion" as a form of waste. What does this mean?

<comment><USER32> In manufacturing its unneeded movement. If I have to get a part that's at the other side of the facility or even 30' away, that's a lot of effort in roundtrips. The component or part should be brought to me. Or my work should be brought to the component or part.

Or the movement could be made useful by having me (or the movement mechanism) carry something both ways.

</comment></comment><comment><USER55> I initially misread that as "The Toyota War". Which was a real thing, named that because Chad used Toyota Land Cruisers to defeat Libya.

[https://en.wikipedia.org/wiki/Toyota_War](https://en.wikipedia.org/wiki/Toyota_War)

<comment><USER56> The entire decades-long overseas diversion saga surrounding American Toyota pickups has always fascinated me.

Top Gear did an episode [0] trying to destroy a Toyota Hilux (similar to the Land Cruiser) and literally couldn't, which explains why it's so popular with terrorists. It's a worthwhile watch if you want to see truck survive after being drowned in water, fire, and the rubble of a demolished skyscraper. Say what you want about Toyotas, but that's quite the engineering feat in my opinion!

[0] [https://www.youtube.com/watch?v=xnWKz7Cthkk](https://www.youtube.com/watch?v=xnWKz7Cthkk)

<comment><USER57> It's not really limited to terrorists, is it? I mean in the popular imagination but essentially technicals are actually great for a lot of rough terrain variable condition combat. But yeah I understand it's a big deal in the popular imagination.

<comment><USER56> Not quite sure what you mean by imagination... Of course Toyotas aren't limited to terrorist groups, but it's definitely been a long-standing trend – so much so that the US Treasury Department asked Toyota to open an inquiry internally regarding ISIS and the dozens of Tacomas and Land Cruisers their propaganda videos:

[https://abcnews.go.com/International/us-officials-isis- toyot...](https://abcnews.go.com/International/us-officials-isis-toyota- trucks/story?id=34266539)

<comment><USER57> Hahah I did not know that. What I meant was lots of third world military and militia types use technicals, that's all.

</comment></comment></comment></comment></comment><comment><USER58> Ah, I see the HN has discovered the OG lean, the true innovation, commonly misinterpreted, that inspired Lean Startups.

</comment><comment><USER59> That shit works only if you are Japanese.... Have Japanese mentality and work culture... Also your product is a car.. Or something tangable made on a production line....

Agile IS the Toyota way... Or at least tries to be

<comment><USER60> A sibling post mentioned Deming, the American who's WWII work on bomber production formed the basis for "The Toyota Way," and not in some indirect way, either. Deming went to Japan at the behest of the US to help them rebuild their economy after WWII.

<comment><USER21> I read somewhere that the context for this was all the men returning from WW II. While it was mostly women worked in the factories during the war and had to find ways to improve production, Deming ideas were solid. But as soon as the egoistic men came back from the frontlines after the war, he was kinda "pushed away" because no one in the US wanted to listen to him anymore. Which naturally was a big mistake as it turned out in the 70s when Japanese car manufacturing made American cars look like garbage.</comment></comment></comment>


Former Apple SVP Scott Forstall Has Been Traveling and Advising Startups - <AUTHOR> http://www.ihash.eu/2013/12/former-apple-svp-scott-forstall-traveling-advising-startups-philanthropical-work/

<comment><USER2> Interesting that some who didnt get job done at Apple is now teaching startups</comment>


Exploring the Web Speech API - <AUTHOR> https://www.voorhoede.nl/en/blog/exploring-the-web-speech-api/ <comment><USER2> I've tried to use the web speech API in a browser-based educational game, yet the tech isn't well mature yet, except on mobile maybe. \- The mic on laptop & PC are noisy and mobile ones are better in suppressing noise \- Apple, Google and Microsoft have huge cloud-based API yet other browsers don't yet.

But i hope in few years speech API (both synthesis and recognition) will be a solved problem with strong open source alternatives

</comment><comment><USER3> SpeechRecognition worked great for me on Chrome for years until Google probably banned me for sending so many request. It would be cool with a completely offline SpeechRecognition... The trick with SpeechRecognition is to use grammars; if there are only a few words to choose from, it will more likely get it correct vs a random sentence.

<comment><USER4> >It would be cool with a completely offline SpeechRecognition...

Nuance still makes Dragon and Windscribe branded speech recognition software. Dragon was great +20 years ago. Not sure how it is now, but investigating offline speech recognition is on my agenda because Microsoft nerved theirs to push people to their online service.

<comment><USER5> Oh, gotcha, "Microsoft nerfed theirs"

<comment><USER4> It worked fine in Windows 7, and barely gets "Yes" or "No" in its current iteration.

</comment></comment></comment></comment><comment><USER6> It seems Chromium and Firefox don't come with any voices installed by default. In production I would probably just use custom server-side synthesis instead.

<comment><USER7> I guess that the downside of that is that you'd be streaming audio instead of text?</comment></comment>


Show HN: The reverse package manager - <AUTHOR> https://github.com/spiceapps/cupboard

<comment><USER2> I would expect a reverse package manager to be something that somehow screws up, disorganizes, or otherwise injects entropy into my packages.

</comment><comment><USER3> I would like to see the "why" expanded on a bit more. Lay out the use case clearly and sell me on the benefits. Especially if I have to install two other pieces of software to get this to work.

<comment><AUTHOR> Thanks for the feedback. The "why" section is definitely on my radar. Also, I'll eventually port this over to either ruby, or c++. I know it's kind of a pain to have to install node.js, and NPM.

</comment></comment><comment><USER4> I think this does the same as mr (<http://kitenet.net/~joey/code/mr/>), though mr supports repository formats than just git at the moment.

</comment><comment><USER5> You seem to have checked in a '.DS_Store' there. A good example of why you should explicitly add files, not use wildcards. ;)

<comment><AUTHOR> eh, I'm lazy. Removed it - thanks for noticing that.</comment></comment>


How does Facebook and WhatsApp picks up an image when any url is inserted? - <AUTHOR> <comment><USER2> og</comment>


Xamarin 2.0 reviewed: iOS development finally comes to Visual Studio - <AUTHOR> http://arstechnica.com/information-technology/2013/02/xamarin-2-0-reviewed-ios-development-finally-comes-to-visual-studio/ <comment><USER2> I still don't think that Xamarin 2.0 has the ability to compete with the native applications produced in Objective C</comment>


Ask HN: First startup. What do I ask so I don't get screwed? - <AUTHOR>

I'm about to join my first startup in SF as the 9th employee at a company that has sucessfully closed a small Series A round ~2M. CEO has a track record of exiting companies ... 5 so far anywhere from 10M-50M.
They have not made their offer yet, but what kinds of things should I be looking out for in the hiring terms? What kind of questions should I as them about options, stock, etc?
I hear so many horror stories about companies screwing early employees I was hoping you could give me an idea of things to look out for. <comment><USER2> As an "old guy" founder with multiple exits, may I suggest you consider reframing the question in your own mind, perhaps to something like "If I join an 8-person startup, what are the daily qualities I need to exhibit to become indispensible to the team, and maximize the chances of not only riding this pony across the finish line but becoming well-positioned to leverage that success into even bigger and better things going forward?"

A couple of quick observations:

1) It seems unlikely that the CEO you decribe (5 decent exits, and another $2M series A) got that far by screwing people by any objective measure.

2) I've never met a rockstar who (as far as I know) worried a lot about getting screwed... they knew they could walk into a better gig any day if they weren't getting a fair shake.

3) They probably won't have too much wiggle room on their first offer, anyway. Sounds like they have enough experience to know what it takes to attract and retain a good team. So if you feel you can do "a lot" better elsewhere (or where you are) then that would be the right choice for you.

4) It's worth considering that it's one possible stepping stone on your path. When I joined Xilinx very early, I was pretty darned sure I was worth a lot more than the stock I got. That said, it was an awesome education on thriving in a frenetic startup environment with exquisitely talented peers, and fwiw that seemingly-meager stock offering bankrolled my next deal, which bankrolled the next one, etc.

<comment><USER3> Totally disagree on #2. Walking into a better gig is easy, but it means you lose years of investment in the previous company (due to dilution, preferences, loss of retention bonus on acquisition, etc). Many of us on the engineering side consider that "getting screwed" even if folks on the executive side think of it as business as usual.

To the OP, I would suggest that the only sure-fire way to avoid getting screwed is to remain indispensable all the way through to a liquidity event. Even then, employee #9 may not see much from their equity.

<comment><USER4> I agree, if you're not standing to get a good share of equity then just look at it as another job. Of course, every CEO-type, like the guy above wants you to do what he's suggesting and slave away but you should evaluate your options and maybe a 9 person startup is too small to not have to work hellish hours, etc but also too big to where you're not getting enough from out of it since you're not a founder. All I can say is be careful of what you're getting into and if you don't stand to gain much from equity or are not sure how long you would stay with them consider working as a contractor then you get paid for all the time you work, etc

</comment></comment></comment><comment><USER5> Here some advice from Ryan Freitas

[http://secondverse.tumblr.com/post/5840343627/so-you-want- to...](http://secondverse.tumblr.com/post/5840343627/so-you-want-to-join-a- startup)

Here a couple of red flags to look out for. They are looking to be a billion dollar company. This is another way of saying that they have giant egos and unrealistic exit plans. Find the people that know the topography of the exit landscape and how they fit into it.

Business Development personel without a product: For most startups, its just too early to have a BizDev person around, unless partnerships are critical to the success of product

The CEO can't code

They have 1 Jr level designer to feed 6 engineers

Everyone uses Windows, including dev-ops. (run away)

<comment><USER4> I agree with the "CEO can't code" part, I've worked for two very small companies (one startup, the other basically a startup but was a few years old) and both had worthless CEO's who hardly understood anything about technology which made things rather unsavory at points. In small companies the CEO is very involved in things and they can really muck things up if they don't know anything about software development.

And, of course, the windows point, if a developer uses windows I immediately take off credibility points.

</comment></comment><comment><USER6> The 9th employee of a company sold @ $50 million is very unlikely to cash out with fuck you money, regardless of anyone else's level of integrity - it would probably take close to a double digit undiluted stake to put you there...at least.

In other words, the biggest way to avoid feeling screwed is to have realistic expectations and to place a realistic value on any stock options. Remember that the bigger the target number for exiting is, the more likely that all the options and stocks will be worth exactly zero.

Good luck.

</comment><comment><USER7> I'm on my first start up right now so I don't have a whole lot of advice, but all I can say is personalities count. In a small environment like that you need to make sure that you can get along well with everyone there. Get to know the team a little bit and try to spot any red flags. If the team includes a few friends or relatives of the founders, that could be a red flag for nepotism over execution.</comment>


Calling All Thieves: Twitter Account Retweets Debit Card Pics - <AUTHOR> http://mashable.com/2012/07/02/debit-card-photos-online/ <comment><USER2> Thanks, but I usually wait until Wednesday to have my faith in humanity crushed.

Still, that's a nice bit of social engineering to auto-filter for people that are either naive or have too much time on their hands.

As an example of too much time on their hands, it's funny watching some of the spam girl accounts post cards with a totally different person's name and sex on them.</comment>


How Class-based Programming Sucks (2011) - <AUTHOR> http://loup-vaillant.fr/articles/classes-suck <comment><USER2> Class-based programming works great for GUI toolkits. In most other contexts, the suitability is variable. OO is a horrible match for compilers, for example.

The article is chasing down the wrong tree when he tries to build an Option type in C++, though. The normal OO way to handle the same class of functionality as ADT sum types is to use separate subclasses. What he's not acknowledging is that OO and functional+ADTs both only handle half the expression problem[1], in different ways. There's no absolute superiority for either model. It depends on the domain.

Less mutability is good almost everywhere though. The lack of persistent data types is a blight on almost all non-functional container libraries.

[http://en.wikipedia.org/wiki/Expression_problem](http://en.wikipedia.org/wiki/Expression_problem)

<comment><USER3> PL designer here with extensive experience writing compilers in C#, Java, and Scala. Pattern matching is nice but OO will get you most of the way and filling the matching gap is simple.

The expression problem is much safer solved using virtual classes (using traits and type members) in scala than with case matching. There are so many OO solutions to this problem it's not funny; I think I had a small argument with Wadler over this back in 2001 or 2.

As for persistent collection types, observable collections with undoable operations are just as good, if not better because they can still support mutability while persistent collections cannot.

<comment><USER2> I've written compilers in C, C++, C#, Delphi, Java, ML and Lisp; targeting x86, x64, JVM and MSIL. I was maintainer of the Delphi front end at Borland / Embarcadero. Pattern matching isn't just nice; you end up with substantially better typechecking, and doesn't need ugly patterns like visitors with their inverted callback control flow, if you want to decouple e.g. type checking or code generation from your AST classes. Visitors are implicitly closed to extension unless you create very abstract visitors (and I've gone down that path, it's not pleasant) - you lose a big chunk of the extensibility objects give you over ADTs. (I'd prefer to use multimethods, but they are rarely available.)

I think persistent collections, along with nice syntax for updating immutable objects (i.e. cloning with a subset of changed attributes) are more practical than having undo available. Immutable data types remove the burden of worrying about who's going to modify the data type from under you, so it lets you share subgraphs more freely. You don't need to worry as much about coupling, because the things you give your state to can't modify it. A possible alternative is mutable collections with snapshots or freezing, but I think persistent collections are a better approach.

<comment><USER4> Wow. Don't mind us mere mortals please continue your discussion, it seems really fascinating even though i hardly understand a word of it.

<comment><USER5> I consider myself a mere mortal too but I can understand most of the discussion.

</comment></comment></comment></comment></comment><comment><USER6> The thing about "Class based Programming" \- or Object Orientated Programming - is that it allows you to model a problem domain in real-world terms. No one approach is ever going to be perfect; OO being mutable makes it perhaps less founded (on the face of things) on formal principles, but for a lot of large codebases it can have a great beneficial effect on readability and maintainability - cognitive overhead is, perhaps, reduced when you can "ground" your understanding in real-life terms.

At the end of the day, pick what language and coding paradigms best suit your problem domain and you as a coder. Pick right, and there's no mistake there.

<comment><USER7> OOP actually doesn't model the real world well at all. It seems to on the surface, but it completely ignores time.

In the real world, everything is a process. Nothing ever stays the same or stands still. No object is the same object from one millisecond to the next.

Immutable state isn't just a formal exercise--it's a more authentic model of the world.

<comment><USER8> I'm sorry, are you arguing that immutability models the world more well than OO because _no object in the real world ever stays the same_?

<comment><USER9> Yes. Due to Special Relativity, different observers perceive events (changes to object state) at different moments, the state of the whole universe is not consistent. Therefore, we model the universe using a sequence of immutable universe snapshots, with different computational agents independently moving through the (branching) timeline of snapshots, so that each and every one of them views the universe consistently.

<comment><USER10> Most events humans care about happen in plain old classical physics, and no computer is moving at some large fraction of light-speed relative to any other computer. If you maintain synchronized clocks, everyone can agree on the exact same order of events (which would not be true in a relativistic situation).

Now it turns out to be difficult to maintain synchronized clocks, and Lamport timestamps and vector clocks are alternatives. The end result looks similar to a relativistic situation, but (and I'm not a physicist), it seems wrong to claim this situation is because of Special Relativity.

Thoughts?

<comment><USER9> Yes. I was half joking, half explaining why immutability actually is better to model the universe.

In practice, replace Special Relativity with Network Problems.

</comment></comment></comment></comment></comment></comment><comment><USER11> Okay, for one:

1\. Dynamically Typed Languages (LISP, Erlang, Smalltalk, Python, Ruby, and Javascript) are all easier than Haskell, JAVA, C++ or any other typed language for working with ADTs. Whether the language is OO or not isn't really relevant. On the other hand, you loose type-safety/efficient representations. But life is filled with choices, different tools are good for different things at different times.

2\. You can have closures in a class based language. Here's some rather exotic Python code that uses both for measuring the performance of iterators: [https://github.com/wearpants/measure_it/blob/master/measure_...](https://github.com/wearpants/measure_it/blob/master/measure_it/__init__.py)

Smalltalk and Scala also have closures. It's not an either/or for classes vs. closures in programming language land.

3\. There's more to concurrency than shared memory, so immutability is again a weapon that is good for some battles. If you have an app which you've factored into workers, unless they are on the same machine they'll need to communicate. Having your data be serializable is more important than having things be immutable in this context. What a worker does with data while it is handling it can involve lots of mutation.

So everyone should take a big breath, and remember that there's no one way to think about software and there's no universal rules, other than probably P != NP and stuff like that.

<comment><USER12> At this point, it's probably easier to name the languages that don't have closures as opposed to those that do

</comment></comment><comment><USER13> Best (and most humorous) argument against Java's object oriented obession that I've ever read is: [http://steve-yegge.blogspot.com/2006/03/execution-in- kingdom...](http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of- nouns.html)

<comment><USER14> The funny thing is that many like to bash Java's OO model, and in the process forget that Smalltalk, Eiffel, C# and many others offer a similar model.

<comment><USER15> What's really funny is to claim that the Java/C++ model is similar to the Smalltalk model.

<comment><USER14> Kind of, yes.

You can map instance methods to normal methods in Smalltalk. And static methods to class methods in Smalltalk.

Of course, you don't have the dynamism of sending messages, instead of invoking method calls.

However given that Smalltalk is the originator of OO and everything is an object, OO critics would feel in prison most likely. :)

<comment><USER16> I thought Simula was the originator of OO?

</comment></comment></comment></comment></comment><comment><USER17> I find a mix between Object-Orientation to model the problem, and a lot of functional thinking in the 'solving' department to be the most comfortable. The modernisation (as in taking features from the old languages into the newer ones) of C++, C#, Java, Obj-C etc. are all liberal with this direction.

<comment><USER18> I agree - in my experience object-orientation is at it's best at structuring a representation of the problem domain and functional thinking fits well with solutions. I've written a lot of code over the last few years that models large scale industrial systems and the general style is very much functional processes over immutable objects and this has worked pretty well.

</comment></comment><comment><USER19> This is a very good article. The point about mutable state is key. Class based programming encourages you to treat objects as little bags of mutable state, instead of as values, and everything goes downhill from there. Its one thing to not go all the way to disallowing mutation. Its another to encourage it to be used pervasively.

<comment><USER20> Prorgramming without mutating state is honestly just bizarre to me. Mutating state is all a program does, literally.

</comment></comment><comment><USER21> > You may even have to inherit a base class or implement an interface. Subtype > polymorphism is a very poor substitute for closures. This is why C++ > algorithm library is unusable.

Does anybody understand what the author means by this? STL's algorithm library does not use class hierarchies for anything. And they often take functions (be they free functions, lambdas, or functors) as arguments.

<comment><USER22> The author probably had (this was written 3 years ago) a bitter and rather narrow view of OOP capable languages.

In C++ a class is just a facility of the language with many different features. If you want immutable, value-semantic objects, then _do it_. If you want a closure... well objects can be closures too. C++ calls them functors, they can be immutable. In fact, C++11 lambdas are immutable by default.

His criticism of the STL is probably that they expose their mutation, rather than hiding it in the architecture like pure functional languages. In C++ you just have to hide the infrastructure yourself.

<comment><USER23> The overhead that is assumed unimportant by most functional languages (copying is cheap, GC is fine, etc.) is intolerable in key situations and problem domains. In C++ _all_ overhead must be optional.

That being said, nearly all C++ applications can benefit from immutable classes, algorithms that take closures, and so on. But C++, like C before it, is really just an abstraction of the hardware and OS below it. That hardware mutates. That pool of memory changes size and locality. The closer your problem domain is to the metal (especially drivers and highly-optimized code), the more you appreciate mutable state, at least given the current state of computing.

<comment><USER24> Dealing with complex immutable data structures without GC is either extremely hard or inefficient (and usually both). C++ standard library does not offer any helping hand here either. Additionally C++ logical memory model (flat, uniform memory) does not describe the hardware memory model well - it is already an abstraction. An memory access isn't uniform and mutations can cost you really very much. In some cases immutable structures + little copying is often the way to go, especially when we aim at parallelization.

</comment></comment></comment></comment><comment><USER25> In case you don't know ML, you should. Also note that though OCaml is the most popular ML dialect right now, Standard ML is where it all started (PolyML is a good Standard ML implementation: [http://www.polyml.org/](http://www.polyml.org/))

<comment><USER26> Or even F#, which is basically OCaml on the CLR. Very fast, fully supported IDE, great if you're stuck in SLAs for CLR code, complete interop with C# or VB.NET, it's the current hidden treasure of the .NET world.

<comment><USER14> Pity that Microsoft pushes it more for library code and not so much for full applications.

But if it gets more use in the mainstream that way, then so be it.

<comment><USER27> The only difference between a "library" and a "full application" is that the "full application" has an entry point where execution begins, whereas a "library" does not.

Many large applications are implemented as a thin user interface (GUI, web, services/APIs) which glues together a bunch of libraries (which is where all of the real functionality is implemented). This doesn't only apply to F#, but C#, Java, Python, etc.

The reason F# gets used for implementing libraries is because that makes it easier to introduce into organizations with existing code in C# or VB.NET; a new component or plugin can be written in F# and easily utilized by the existing code, so the other developers in the organization don't need to anything differently than if they were consuming another C# or VB.NET component.

<comment><USER14> I do understand the reasoning behind it, just as a ML fan would like to see the possibility of proper support for GUI/Web for pure F# applications.

But I fully understand it, on my enterprise world JVM == Java and .NET == C#, except when doing small prototypes. It is very hard to use alternative languages, as managers always look for coding drones.

</comment></comment></comment></comment></comment><comment><USER28> Also see: _The problem with OOL is not the OO_ by Carl Sassenrath (from 2009) - [http://www.rebol.com/article/0425.html](http://www.rebol.com/article/0425.html)

PS. Just submitted to HN - [https://news.ycombinator.com/item?id=6900426](https://news.ycombinator.com/item?id=6900426)

</comment><comment><USER29> Relevant recent tweet by the creator of the Io Language, Steve Dekorte: [https://twitter.com/stevedekorte/status/411045428361056256](https://twitter.com/stevedekorte/status/411045428361056256)

I suppose most folks here disagree?

<comment><USER30> Of course I agree with Dekorte. Having written compilers written in perl, C and LISP - the ones in perl in pure OO, and the ones in C and LISP without, I conclude that I rather add classes and methods to my compilers than trying to improve it without. In the one written in C, classes are supported by the intermediate VM though (dynamically typed, very similar to Io), which is still better than having to write it in horrible C++.

</comment></comment><comment><USER31> I agree, mostly, with the conclusions. "Classes" as a method of code re-use is dead. However, his conclusion that ML would dominate C# and Java as a language, I highly contest.

The most important thing in my opinion is tools and platform support. Show me a fast, good looking IDE with good autocomplete/intellisense/integrated debugger and UI tools for ML. See?

Is there an abundance of libraries and api wrappers available (that doesn't require you to do straight C-interop)? See?

Also: the design of a language should be done with the tools in mind. While there is not much difference between norm(vec) and vec.norm() the latter is the form that supports autocomplete. So even for functional languages, being able to use member properties and member functions is an absolute reqirement to support the tooling that we expect.

You _could_ say that F# dominates C#. It has almost the same tool and library support, while having the features you expect from an ML type language.

<comment><USER32> I'm noticing that whenever there is talk about any language that isn't Java or a CLR language several someones pop up to go on about the tooling "we" expect.

The difference between norm vec and vec.norm() is that the function can be used in a higher order function while the method would require wrapping it in a lambda to achieve the same thing and would probably still break your tool's ability to autocomplete if you used it that way.

You're basically insisting that an FP language needs to include an embedded OO language to be usable.

</comment></comment><comment><USER33> "The obvious conclusion is that ML simply dominates Java (and C#) as a language. Time to switch."

The obvious conclusion is that any statement that contains the phrase "the obvious conclusion is" is 100% BS, including this one.

</comment><comment><USER34> mutable state is not a problem per se. _Shared_ mutable state however, is a recipe for disaster.

There are other problems with Object-Orientation. For example, it tends to scatter allocation which has performance impact. ( see this nice presentation: [http://harmful.cat-v.org/software/OO_programming/_pdf/Pitfal...](http://harmful.cat-v.org/software/OO_programming/_pdf/Pitfalls_of_Object_Oriented_Programming_GCAP_09.pdf) )

If performance is not an issue, I'd guess the price you pay for OO is that you eschew parallelism and concurrency.

<comment><USER35> Any code that operates upon your object with "private" state still has to account for the fact that its methods are not referentially transparent. E.g. I have to open a connection to the database before I can send commands through it, and so now I have to check if its already open everywhere I use it. So that is definitely shared state, but I guarantee you that a lot of people think a private variable means it is not shared.

</comment></comment><comment><USER36> A language can't suck just because it isn't Haskell or ML.

<comment><USER37> It's funny how people blame the language when they are the ones who made a mess. :)

On the other hand, there are languages that make it easier for you to screw it up and the ones that try to prevent that.

But there's no bullet proof language.

<comment><USER36> A bug-proof language is like an uncrashable car.</comment></comment></comment>


Adobe Flash's Gaming Legacy and My Efforts To Save It - <AUTHOR> https://blog.usejournal.com/adobe-flashs-gaming-legacy-thousands-upon-thousands-of-titles-and-my-efforts-to-save-it-58c14811558a <comment><USER2> Perhaps worse than the death of Flash was the death of Shockwave. I feel like so many Shockwave games I played back in the day are completely gone with no reference to them on the modern internet. Today, you can install some version of Flash on most operating systems, but I don't think there's any modern standalone Shockwave player and I could only get the plugin to work in Safari on macOS. Chrome and Firefox don't even run those types of plugins anymore.

There's one particular Shockwave game that I was recently able to recover from the depths of the Wayback Machine, which was a game from Disney for the Inspector Gadget movie; terrible film, but their website had this nifty little game that wasn't necessarily difficult but was addicting in that I wanted to see just how far I could go with it. For years I thought it was gone for good, and was glad to finally see it again after I lost it 15+ years ago.

Here it is in all its 1999 glory: [https://web.archive.org/web/20031017000018/http://www.disney...](https://web.archive.org/web/20031017000018/http://www.disney.co.uk:80/gadget/repair.html)

I always liked it in part because I don't think I've seen a similar game. It's kind of like if you took the random shapes part of Tetris and added a "jigsaw puzzle" element.

<comment><USER3> What was the difference between Flash, Shockwave, and Shockwave Flash (I think the last one was a thing!)?

<comment><USER4> When asking the difference between Shockwave and Flash, you'll often get the answer that they're two products that have nothing to do with each other. That is almost true, but not entirely true.

Director was originally meant for creating CD-ROM games. However, in the early 90's, it began finding a new home on the web. "Shockwave" was Macromedia's term which meant "compressed for the web." The first entry in the Shockwave line of products was Shockwave Director Player - so called because it could play Director Movies which had been compressed for the web. Because it was, at the time, the first and only product in the Shockwave line of products, Shockwave Director Player was often shortened to just "Shockwave."

Enter Flash. Again, Macromedia wanted Flash Movies to be able to be compressed so they could be downloaded quickly over the web - so they made the Shockwave Flash Player plugin, so called because it could play Flash Movies which had been compressed for the web. So there was Shockwave Director Player, to play compressed Director Movies, and Shockwave Flash Player, to play compressed Flash Movies.

The problem is, by this point, everyone already knew Shockwave Director Player as just "Shockwave." To those uninformed, it seemed that there was now both a Shockwave AND a Shockwave Flash. Shockwave Flash Player was more often referred to as just Flash, to avoid confusion with what was already being referred to as Shockwave.

So when we say Shockwave, we're referring to the first word in Shockwave Director Player, but when we say Flash, we're referring to the second word in Shockwave Flash Player...

Or at least, this was the case until Adobe acquired these names from Macromedia, at which point they just decided to rename the plugins to what they were being popularly referred to as. Now what was Shockwave Director Player is officially just called Shockwave, and what was Shockwave Flash Player is officially just called Flash. In order to further undo the confusion, SWF was changed to stand for Small Web Files instead of ShockWave Flash.

<comment><USER5> Great summary!

As for useless trivia, Director actually even predates it's main use of producing multimedia CD-ROMs. When it was still a MacroMind product, it was used for stuff like the "getting started" floppy disk for early Macs (the tutorial where you learned how to use a mouse by feeding fish and stuff)

[http://www.action- packed.net/q-design/examples/Instructional...](http://www.action- packed.net/q-design/examples/Instructional/MacBasics.html)

<comment><USER4> Right, I suppose it's not fair to say it was originally meant for "creating CD-ROM games," that's an oversimplification. It's more like it was meant as a way to make applications without needing to learn a more advanced language like C++.

</comment></comment></comment></comment></comment><comment><USER6> It's a damn shame that HTML5 implementations of Flash, like Shumway ([https://en.wikipedia.org/wiki/Shumway_(software)](https://en.wikipedia.org/wiki/Shumway_\(software\))) and Swiffy ([https://en.wikipedia.org/wiki/Google_Swiffy](https://en.wikipedia.org/wiki/Google_Swiffy)) are no longer being actively developed. I would have thought running SWFs in the JS sandbox would be a good way to get the compatibility of Flash, without the insane security bugs that it comes with.

And in case anyone is still in doubt about Flash's security woes - take a gander at the Flash CVE page at [https://www.cvedetails.com/vulnerability- list/vendor_id-53/p...](https://www.cvedetails.com/vulnerability- list/vendor_id-53/product_id-6761/Adobe-Flash-Player.html). There were FIVE CVSS 10 bugs (total and complete remote code execution with minimal user interaction, i.e. visit a malicious page and your computer is owned) published just _two months ago_. The author of Flashpoint is absolutely correct in his assessment that Flash will be overrun with security bugs as soon as it hits EOL in 2020.

<comment><USER7> > _I would have thought running SWFs in the JS sandbox would be a good way to > get the compatibility of Flash_

And these days a WebAssembly build of Flash player would be an even better way, but it would depend on Adobe being willing to spend the time and the money to do it.

<comment><USER8> I've spent a ridiculous amount of time reverse engineering SWF files. There was even a time when Adobe published the SWF file bytecode format. It's not a terribly complicated format like photoshop psd.

WebAssembly is probably a good target. However flash added a ton of apis in their latest versions. They were so ahead of the game before html5 before even became a thing.

I'm sure Adobe has patents/trademark on some of the things. Also Adobe Flex, that was a god send for rich internet applications. Their components were really well done and I still can't fine equivalent things in this day and age.

I do strongly believe if Adobe had open sourced big chunks of things, Flash and a number of technologies would still be relevant today. Their big money makers were the IDE's like Flash Studio, dreamweaver, photoshop etc. The formats and the runtimes should have been open from the get go.

Although it was the Ballmer era when most corporate CEOs truly believed OS was cancer.

<comment><USER9> Flash was mixed with licensed non-opensource-able stuff and it wasn't a trivial code base in the first place. Given that Adobe hasn't actually made much money off Flash, such an effort would have been likely unfeasible and prohibitively expensive. Someone from the Flash team could chime in here to give more details.

<comment><USER10> Another option was for Google to buy Macromedia, instead of Adobe. I believe web would have looked completely different today.

</comment></comment></comment></comment></comment><comment><USER11> I do understand some of the reasons behind the web community's rejection of flash over the past decade and a half — security and accessibility issues, closed standards, etc. However Flash and Shockwawe technology enabled smooth interactive graphics on 90's and 00's desktop hardware, in packages that are friendly for 56kbps dialup connections. Nothing compares to it, still to this day — web platform tech still horribly underperforms and is only now capable of what flash could do a decade ago. We could also blame Apple and Smartphones and Yourube for its demise, but I feel like we haven't moved forward in terms of quality shareable interactive media since Flash.

<comment><USER12> I hope by smooth you're referring to the graphics being vector vs bitmap, because Flash performed really badly once you added any kind of complexity to a scene. (edit: simple things worked brilliantly though, and often that was enough.) The key innovation of Flash was and still is the creation side of things in Flash Pro rather than the runtime.

My main experience was with Line Rider. I didn't create it, but I became involved in the community and started making tweaked versions with tools that made it easier to create tracks (as opposed to versions that let you do things like change the physics or the rider).

Every line you added to a track caused a new MovieClip to be added to the scene that had a line drawn in it. By the time you had around 3,000 lines or so you'd start to get reduced framerates. 3,000 lines sounds like a lot, but is tiny when you consider tracks that have accompanying artwork.

A few years ago, we released a JS + WebGL rewrite of Line Rider that has a physics engine that's bug-for-bug compatible with the original (you can play it at [https://www.linerider.com/](https://www.linerider.com/) if you're interested - sorry if that's too self promotional). With access to WebGL and a _massively_ faster ECMAScript runtime, the JS version runs multiple orders of magnitude faster than the original Flash version.

It's now possible to work with tracks that have hundreds of thousands of lines without experiencing frame rate drops as opposed to just a few thousand lines. So as for web platform tech underperforming from a runtime point of view, I disagree.

The problem is that all the ingredients are there to make something great, but the developer effort required is monumental in comparison to how fast it was to make something work with Flash Pro.

<comment><USER13> To be fair, it became possible to do deeper graphical optimizations in Flash later in its lifespan(particularly after the BitmapData API, and towards the very end, Stage3D) but I would agree that it wasn't in the spirit of the tool to work on Flash games with an eye towards high framerates, that just happened as a byproduct of the web-game space professionalizing around the close of the last decade.

It really was an odd, "software is brutal" history in that in a very short timeframe Flash progressed from being the domain of hobbyist game makers, animators and web site designers into the core client technology of _every_ web site using audio and video. And then a few years after that, it was cut off from expanding to mobile and was strangled on the web through expansion of HTML.

</comment></comment></comment><comment><USER14> For those of you involved in saving flash projects, consider Haxe and OpenFL :

[https://haxe.org/](https://haxe.org/)

[http://www.openfl.org/](http://www.openfl.org/)

Case Studies:

[https://haxe.org/blog/tivo-using-haxe-to-improve-user- experi...](https://haxe.org/blog/tivo-using-haxe-to-improve-user-experience- for-millions-of-customers/)

[https://venturebeat.com/2017/12/12/flowplay-overhauls- vegas-...](https://venturebeat.com/2017/12/12/flowplay-overhauls-vegas-world- ditches-adobe-flash-for-haxe/)

</comment><comment><AUTHOR> Here is the latest dump with almost 4000 titles [https://archive.org/details/Flashpoint3.3.zip](https://archive.org/details/Flashpoint3.3.zip)

</comment><comment><USER15> Imo this is an incredible project. I wasted thousands of hours playing flash games as a kid, glad to see someone is interested in preserving them

<comment><USER16> I also grew up spending a lot of time playing those games. I say good ridance to the flash video players, but seeing the screenshots of those games, it makes me pretty sad to think that so many of them might be going away.

</comment></comment><comment><USER17> Let this be a warning to young developers tying into proprietary platforms.

(Not one mention in TFA of [http://homestarrunner.com](http://homestarrunner.com), for shame)

<comment><USER18> That's not fair. There was a point in time that if you don't use flash for web games, you just weren't doing web games. HTML was not up to the task.

You could avoid being tied to proprietary platforms now but there is a good chance you're just leaving the market to someone else.

<comment><USER19> Running another program in a rectangle in your web browser can hardly be called "web".

<comment><USER5> Does WebAssembly running in a <canvas> tag count as "web"?

<comment><USER20> Maybe. However, wasm will eventually tightly integrate with the DOM.

<comment><USER21> Yeah it seems like people don't understand this. We've had an era of JavaScript dominating web standards. I also don't think people realize this is only the start of wasm...

</comment></comment></comment></comment></comment></comment><comment><USER22> Thank you to everyone preserving these games. I made over 40 flash games in my career and I'd like to see at least 3 of them preserved indefinitely

</comment><comment><USER23> To capture more than just the SWF:

\- Load the game into a real web browser and let it run for a bit

\- Intercept all network requests with a caching proxy

\- Save the external resources loaded to disk

Would that help? The process could be automated, though only for games which load all their resources without human interaction. But then, clicking through a few screens to get a game to start is a much less time- and knowledge- intensive task per game than reverse-engineering the source code of each, at least to get as much data backed up in some state as possible before it disappears.

<comment><USER4> There's an excellent command line application called Auto Saving Sniffer which can be found here (ignoring the rather crude abbreviated name.)

[https://www.cockos.com/assniffer/](https://www.cockos.com/assniffer/)

While you need to play through the entire game to be sure you have all of it, this is a big time save, though with the downside it doesn't work over HTTPS. It's also possible to use a Fiddler script to accomplish something similar, which defeats the HTTPS problem.

</comment></comment><comment><USER24> From the article:

 _There's eventually going to be one question on the lips of everyone involved, though: is this legal? And the only real answer is nobody knows and really, nobody should care._

I can understand having an urge to preserve something that is in danger of decaying past recovery — I feel the same way when I see an interesting building or a classic airplane rotting away somewhere — but the usual course of action is to choose what you find most worth saving, _purchase it from the owner_ , and restore your new possession. Any other course isn't legal, in most cases, and it isn't here either, in most cases. I care about that, and some of the game creators will care about it too.

<comment><USER25> If we care about legality when it comes to media preservation, more often than not works will end up lost or destroyed one day.

Today's pirates are tomorrow's historians.

<comment><USER24> That is true. Other people's rights are often an inconvenience.

<comment><USER26> Copyright isn't really a right in the sense of the public freedoms/choice.

It's there to limit publishing and distribution to only those with the legal document saying they can. It's more of a anti-right. In fact historically it was created for the purpose of censorship.

<comment><USER24> People have a right to the fruits of their labors. I don't care a tinker's mother about the history of copyright — the principle is simple, and copyright is a flawed protection of that right.

<comment><USER26> Though it may be used by industry on some occasion to protect someone's ability to profit. Copyright and the right to the fruits of your labor are not the same thing.

In cases like this disregarding one isn't equivalent to infringing on the other.

<comment><USER24> I expressed the contrast between copyright and the right it attempts to protect above. Notice that I didn't say anything about _profiting_ from the fruit of their labors, but the right to them, no matter whether they choose to profit or let it rot. It's just as much an infringement to preserve it without their permission as it is to sell it.

<comment><USER26> Yep that's the definition of copyright. Seems like more of a anti-right as it's about limiting others rights.

<comment><USER24> I see the problem here: you don't know what a right is.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER27> Some years from today it will be proper chunk of retro scene, but I for one am happy we've moved on. Flash was horrible and a burden.

Edit: missing word

<comment><USER28> In hindsight, sure. But it was perfect (or as close as you could get) for the time it was created.

</comment></comment><comment><USER29> Mozilla tried with Shumway project, but it got abandoned.

</comment><comment><USER30> And this is the problem I have with tying anything to a remote server. Every digital movie, song, book, or video game that requires a remote server for patches, activation, or anything else will eventually end up like this.

What happens in 5 years when Sony turns off their PS3 servers? And what happens in 10 years when most of the hard drives in those PS3s need replacing?

</comment><comment><USER31> Not only this, but I've had a very difficult time even finding original SWFs of animutations. Albinoblacksheep only seems to host video renders these days. While that works, many authors hid extra content in their videos, and that's now lost to time.

</comment><comment><USER32> One could ask is the attempt to save lost games, or lost innocence?

<comment><USER33> It's about saving cultural goods. The worst thing about the modern age is how transient and impermanent data is. In 100 years, the past 30 years will be effectively a big black hole for anybody interested in studying our culture and civilization.</comment></comment>


Why you'd be stupid to bet against HTML5 - <AUTHOR> http://www.techrepublic.com/blog/european-technology/why-youd-be-stupid-to-bet-against-html5/1254

<comment><USER3> HTML5 apps are good for the company making them, not for the user using the app. Almost all the best apps (i.e. the apps you want to use not the apps you have to use) are native. That doesn't mean they're worthless, they're great for getting an app out quickly (e.g. Wunderlist, who released non-native then made a native app).

LinkedIn put a lot of time and effort into their app, it is pretty good, though a little laggy even on a Galaxy S2 which should be powerful enough. The Financial Times doesn't really care too much about user experience I'd imagine, as long as the users get the content.

But er, I resent being called stupid for betting against HTML5 for mobile app development. No need for such a confrontational title :-)

<comment><USER4> I think thats very much personal preference.

As a user, I almost always prefer the browser version. The main reason for this is that the browser controls are always there. For example, forward and back are always there, save for offline reading, and bookmarking is always there. Always in the same place.

I've tried a few native apps for news and social sites, but I've removed almost all of them because I found them harder to use than the browser. Some other people seem to love native apps though.

<comment><USER3> Browser is different to a HTML5 mobile app. A HTML5 mobile app is one you download from the app store. I'm a big fan of the browser and I'm a big fan of native apps - I just don't like it when I download an app (especially if I have to pay) expecting a native app, and then I get a HTML5 app.

<comment><USER4> Gotcha, I thought you were arguing against HTML5 in general. I agree that HTML5 mobile apps are not currently as good as native, and I'd prefer native as a user.

I think in the future HTML5 mobile apps will be good, especially if Winmo8 and/or Firefox OS gain traction, but if I were a developer in that space I would stick with native for the moment.

</comment></comment></comment></comment><comment><USER5> I think the HTML5 vs Native debate is less about the software as it is about hardware support on a corporate or communal level. As a software developer, i've been hoping HTML5 would take off since I first learned about it. However, in mobile, there seems to be a trend for hardware and software synergy.. a preference to really own the vertical stack and have full control over the experience and in order to build a great phone. On the native side, the titans of Google, Microsoft, and Apple all have their weight behind their own respective platforms.

While the community in software for HTML5 is strong, the reason i'm starting to bet against is because of the lack of love from the hardware side of things. I'm not sure I can imagine a large existing company in hardware pushing HTML5 as far as its own native platform. Without a phone or mobile device built and designed with HTML5 in mind, is it really possible for the fortress to crumble inside out?

<comment><USER6> >>>Without a phone or mobile device built and designed with HTML5 in mind, is it really possible for the fortress to crumble inside out?

What do you think of these two Intel demos that show River Trail speeding up HTML5:

[http://www.youtube.com/watch?v=7hhksxH1Wco&feature=share...](http://www.youtube.com/watch?v=7hhksxH1Wco&feature=share&list=PL27DC1B760EA680E9)

... and giving JavaScript multiples cores:

[http://www.youtube.com/watch?v=XRGfMllFyuM&feature=share...](http://www.youtube.com/watch?v=XRGfMllFyuM&feature=share&list=PL27DC1B760EA680E9)

If that happens on the desktop, won't people also demand it on mobile devices too?

</comment></comment><comment><USER7> I don't think "betting against it" is accurate terminology - the general consensus is more that the mobile device infrastructure isn't ready for HTML5 yet (in terms of performance etc). I think it will catch up... probably within the next couple of years, but until then we need to think about our current users and the experience they receive.

On a side note I see the article mentioned using a hybrid app - I think that is an acceptable "in-between" at the moment. Personally though I have found maintaining hybrid applications cost a lot in extra development time - <USER2> really hope it pays off in the long term.

<comment><USER8> I don't think it has to be binary: [ ] ready [x] not ready. It's ready for a certain set of use cases and platforms, but not everything, much as Hypercard was ready for calculator clones, but not 3D flight simulators.

The internet itself is a prime example of the value of a common platform accessible by nearly any device. That doesn't mean such a platform needs to be all things to all people.

</comment></comment><comment><USER9> A couple of things:

1\. Facebook's app isn't pure native today. They simply shifted more of the development to native than was before. LinkedIn does the same thing. _"For areas within the app where we anticipate making changes more often, we will continue to utilize HTML5 code, as we can push updates server side without requiring people to download a new version of the app."_ [1]

2\. "Now nobody says Java is slow" - Seriously?

3\. "This is like what we saw 30 years ago with the PC, with hundreds of standards and everyone wanting to produce their own PC." - No, it's not. This is a different set of fragmentations. Mainly having to do with OS fragmentation (which didn't exist with Win dominance) and displaying information on a limited canvas.

4\. Curious...what motivation does Apple, Samsung, HTC, Nokia, etc have to advance their browser engines? When we talk about "HTML5 maturing" isn't this what we are waiting for?

[1] - [https://www.facebook.com/notes/facebook-engineering/under- th...](https://www.facebook.com/notes/facebook-engineering/under-the-hood- rebuilding-facebook-for-ios/10151036091753920)

</comment><comment><USER10> My problem with HTML5 is that you have to use JavaScript on the client. Until browser vendors implement other languages I'll stick with native.

<comment><USER11> If you dislike JS so much, why don't you use some cross-compiler?

<comment><USER12> JS is (unfortunately) the only choice when you target browsers. I don't see any intrinsic advantage that can make it the go-to language.

It's the lack of choice that I find problematic.

</comment></comment></comment><comment><USER13> I hope people continue to bet against it so those of us seeing productivity gains from utilizing it can continue to outmaneuver the competition.</comment>