You Really Don't Need All That JavaScript [video] - <AUTHOR> https://youtube.com/watch?v=e1L2WgXu2JY <comment><USER2> More than anything this reminds me of the fact that HTML has failed on a basic level, to keep up with the ways that users want to experience content, and that designers want to present content. The browser has no real concept of "page navigation" or "site navigation" with any kind of state, or the "current" navigation item, or of hierarchy, breadcrumbs, menus, or other core navigational concepts involving site and page structure.

With a few built-in "site structure" features in the html standard, the browser could do a large part of what developers end up reimplementing over and over again - both with and without JS. A large part of "knowing about usability" is just knowing how to execute these basic navigation features without goofing up on the many pitfalls available to you.

For example, imagine if there was some kind of Site Structure standard, or Page Structure standard. The browser could then generate standardized navigation elements with perfect UX on every platform, and sure, you can style them, but the basic functionality just works everywhere without having to make advanced javascript/html/css menus that take into account concepts like responsiveness, touch interface, or accessibility.

<comment><USER3> No thanks. Good languages start small and stay small. HTML is already bloated with tons of elements of questionable usefulness. It's a document presentation format, and that's all it should ever be. Does Markdown need knowledge of state and navigation and breadcrumbs and menus?

<comment><USER4> At this point, the choice is not whether the web should have apps, but whether they should use multiple frameworks that invent the missing pieces on top, or whether some of that should be standardized. For me personally, knowing HTML is small will be cold comfort if we are all using react-router or whatever in the future.

<comment><USER5> > For me personally, knowing HTML is small will be cold comfort if we are all > using react-router or whatever in the future.

Serious question, what's the issue with react-router?

<comment><USER6> I can't speak for OP, but my issue with react-router is that for just a single project I had to significantly change things as they kept doing things in completely new ways. Once I gave up and used page.js (or some other non-react- specific solution), not only was the resulting code shorter and cleaner, it needed much less upkeep.

I'm sure there are situations where using react-router makes sense, but for me it was one of the few packages 'blessed' by the react ecosystem that gave me more trouble than it was worth.

</comment></comment></comment></comment></comment><comment><USER7> I saw this earlier today (Edit: instead of the first 10 minutes, I ended up watching the whole thing.) After going into the problems of client side rendering, he does get into the benefits (9:00), but then argues that these are after-the-fact rationalizations. He then argues that the real problem designers and devs are trying to solve is the loss of control - that the browser controls loading, and the blank screen is "bad."

He then says that the solution is using an iframe (called a portal.) which looks to be a proposed API. [https://web.dev/hands-on- portals/](https://web.dev/hands-on-portals/) \- this is available as an origin trial in Chrome 85.

So, he's saying that SPAs are bad and we should invest in a Chrome-only feature or future feature that might make it through standards? This makes no sense to me.

There are multiple uses for SPAs. One is building a genuine web application, such as Gmail or a SAAS. SPAs are also used in places they shouldn't, such as news sites, because of the page load problem as mentioned above. Portals would be useful here.

But it gets to the real problem: client side rendering in the past decade has had a lot more thought and effort in tooling, tutorials, and patterns on the client side than server side, especially with mixed mode. (Mixed mode: adding javascript on top of server-side rendering.) The problem is that server-side rendering and mixed mode is not a good development experience. The back button was never a fully solved problem and POST-redirect-GET is essentially an insufficient hack.

If someone wants to talk about making server side rendering for web applications a viable experience, we are likely going to need changes to the standards and we will need to build up a great set of tooling to solve the problem. (Oh, and since it's server-side rather than javascript, each framework or language will have to replicate it just like React, Angular, Vue, and others have done.)

<comment><USER8> > So, he's saying that SPAs are bad and we should invest in a Chrome-only > feature or future feature that might make it through standards? This makes > no sense to me.

That was my own conclusion, at first I thought "whoa, <portal>? never heard about it but looks cool", I proceeded to search for `HTMLPortalElement` and then I got to a W3C page saying "Draft" and I was like "what? a yet to be standardized feature? thanks, but no thanks, I'll might check it back in 2 years".

<comment><USER9> This presentation is essentially Dev Advocacy, he's describing where we want to go, not necessarily where we are now.

I hear you though; I thought this was gonna be another "you don't need React, here's the Vanilla JS that does the same thing" kinda presentation, but was actually intrigued to learn about this <portal> tag. I does seem to address the (main?!) bugbear we have with interactive webpages and the fight between the server and client.

Although I am surprised there's little to no support for it _right now_ \- thought at least Chrome would.

[https://caniuse.com/?search=portal](https://caniuse.com/?search=portal)

Edit: Ofc it _can_ be tried out w/ Chrome if Dev Enabled, but it's not user supported at this time.

</comment></comment></comment><comment><USER10> His example of using portals to solve "a real problem" is really interesting to me, because it seems to point to a much more fundamental problem with UI development via HTML and browsers.

The example involves a common page design: left hand table of contents, right hand (typically most of the width) with current contents (chosen via ToC). Jump to a new section, and the scroll position in the ToC is lost.

He describes how to use a portal to fix this.

Compare with desktop GUI toolkits. The ToC would be its own element (GtkListView or QtWhateverList or NSThisNThat). The contents would be their own element (GtkTextView or QtCanvas or whatever). Both are drawn independently of the other. You can call for an invalidation of part of the window. You do not need to consider them part of a single window rectangle that will always be redrawn in-toto for a page load.

Now, my (weak) understanding of why we've ended up with things like React is that in part they are an attempt to solve this by effectively creating the equivalent of a widget heirarchy inside the browser. When a React implementation of his example gets new content, it doesn't invalidate or even necessarily "redraw" the ToC, and it tells the browser what to do by invalidating certain DOM elements (or even just one DOM element).

I think he misses this as a key reason for the movement towards frameworks.

But ... notice that the browser will probably (I'm not 100% sure about this, would appreciate comment from someone who knows), re-render the entire rectangle the contains the page.

Desktop applications don't work this way. If you turn on Quartz debugging on macOS you can actually see the rects on screen that are re-rendered to reflect invalidation by the application (e.g. after new content needs to be displayed).

Maybe I have this wrong, and React and similar frameworks have leveraged a subtle capability in the browser to invalidate a DOM element as a way to only re-render part of the on-screen rect.

But assuming that I've have this roughly correct, this model in which the "atomic, indivisible rendering unit" for browser apps is the page rect seems fundamentally disadvantaged and mis-designed compared to desktop apps.

<comment><USER11> I don't have technical references to point to atm, but as far as I know, browsers _do_ go to great lengths to only actually repaint portions of the page that have changed. There's lots of layer compositing on GPUs, checks to see what DOM nodes were mutated, etc. Nothing framework-specific here at all - this is how all modern browsers are implemented.

React in turn does work to let you, the developer, divide your UI code into discrete components that control the layout of some subset of the page, and lets you declare what the UI should look like at any given point in time based on our data. React then tries to minimize the number of DOM updates that have to be modified to make the previous DOM structure look like the structure you said you want now.

<comment><USER10> Assuming that you're right about the browser avoiding invalidating windows rects unnecessarily, that still leaves the fundamental problem that DOM elements are not widgets in the way that (say) GtkListView and GtkTextView are. In a desktop GUI toolkit, you can alter one of those entirely independently of the other (and because of the typically non-overlapping assumption of most widget-centric toolkits, only resizing will ever create a dependency between them for the parent window).

More technically: if you change the content of a desktop text view widget, then there is more or less a straightforward and simple code path from the widget invalidating its own rect to the native window/graphics system causing a re-render of just that rect. The toolkit really has almost no work to do to make this happen, and neither does the native window/graphics system.

But in the browser model, the DOM is an abstract model that may or may not map easily onto window rects. So to decide what will be invalidated in the (native) window, the browser has to essentially recompute the entire window and then decide what to invalidate at the native window/graphics level.

Are you sure about layer compositing on GPUs within the browser? My guess is that this is done mostly by the (desktop/native) toolkit used by the browser and is an optional optimization, since the browsers will function normally without a GPU.

At some level though, I think you're right and that the video is wrong in some deep way: the way I was first told about React made it sound precisely like "it is designed to work more like a desktop toolkit", and given this, the video misses one of the more fundamental reasons for contemporary web frameworks.

<comment><USER11> A few seconds of googling turns up these relevant articles on how browsers paint via GPU (which date back many years):

\- [https://www.chromium.org/developers/design-documents/gpu- acc...](https://www.chromium.org/developers/design-documents/gpu-accelerated- compositing-in-chrome)

\- [https://www.urbaninsight.com/article/improving-html5-app- per...](https://www.urbaninsight.com/article/improving-html5-app-performance- gpu-accelerated-css-transitions)

\- [https://hacks.mozilla.org/2017/10/the-whole-web-at- maximum-f...](https://hacks.mozilla.org/2017/10/the-whole-web-at-maximum-fps- how-webrender-gets-rid-of-jank/)

and also how they handle painting and redrawing in general:

\- [https://www.phpied.com/rendering-repaint-reflowrelayout- rest...](https://www.phpied.com/rendering-repaint-reflowrelayout-restyle/)

\- [https://www.html5rocks.com/en/tutorials/internals/howbrowser...](https://www.html5rocks.com/en/tutorials/internals/howbrowserswork/)

\- [https://james-priest.github.io/udacity-nanodegree- mws/course...](https://james-priest.github.io/udacity-nanodegree-mws/course- notes/browser-rendering-optimization.html)

So no, browsers don't "recompute the entire window". They know what DOM nodes have been mutated, and are able to fairly efficiently redraw just those pieces of the UI that have changed.

I haven't watched the video yet, but React's approach to defining UI structure and updates is considerably different than your typical desktop UI toolkit (ie, Swing, Windows Forms, MFC, Qt, etc). With those classical frameworks, you generally have a bunch of object-oriented class inheritance hierarchies and manually instantiated child widgets with specific parameters (`button.setWidth(80)`, `button.setPosition(20, 40)`, etc), then add a lot of event listeners to manually modify both the data and the UI.

As I previously mentioned, React expects to work with a "retained mode" environment, such as the DOM, where previously-set UI layouts persist until such time as they are modified. React is explicitly based on determining what the current UI _ought_ too look like based on your current state. The problem that frequently plagued jQuery-type UIs is figuring out how to transition the UI contents from where it was previously to where it needs to be now, taking into account all the possible permutations of what could be shown on screen. With React, you tell it what UI output you want at any point in time based on your current state, and it takes care of figuring out what relatively minimal set of changes actually need to be applied.

<comment><USER10> Thanks for the links.

I'll have to hunt around a bit harder, because it seems that in general, the people who talk in the most detail about browser rendering don't seem to understand the rendering processes in non-browser apps, and vice versa.

For example, all of the discussions of GPU usage that you linked to all seem to skip over the fact that (most) native desktop apps do the same thing implicitly c/o the toolkit they're using. If your ListView widget is ultimately drawn using Vulkan or Metal etc., then the exact same set of abstraction processes and delivery to the GPU are going in a a native toolkit app as the browser (which is not suprising, really).

AFAICT, React has no access to the browser render tree, and it can only control the DOM. As such, it is really positioned at a very different level in the "drawing stack" than, say, Qt. At the same time, as you point out, it also isn't particularly close to the widget layout models of "classical frameworks" (even constraint-based versions as have become more common in recent years), because it deliberately tries to prevent you from having too much direct control over the current DOM - that's supposed to be driven by the state.

I wish there was a more fruitful meeting place where the experiences of 30+ years of "classical frameworks" could shape and in turn be shaped by the decade plus of "web frameworks". I think that the former has a lot offer the latter and the latter has many ideas and insights that could probably improve the former.

</comment></comment></comment></comment></comment><comment><USER12> I am definitely one that loves a good "get off my lawn" moment, but it seems like we rehash this point every few weeks (and I don't even read frontend twitter). There is a reason we are where we are in the front end world -- most every useful tool/wave of engineering came to be for a reason. A (very spotty) timeline[0] was even submitted in the not too distant past to HN, and I won't go into it here, but from jquery to mootools to snowpack/vite, people built tools to solve problems (some of which don't exist anymore or won't in the near future) -- a strong grasp of fundamentals and knowledge of _why_ a thing exists and you will feel a lot less like you're being thrown around by the waves of frontend development zeitgeist.

All that said -- SSR is the best of both worlds. To the untrained eye, it looks like a step backwards, but there's more to it than that -- it gives separation (if you want it) for your frontend code that usually moves at a different pace than the backend code, server-side rendering for performance (obviously), and complex client side functionality for building rich experiences. If you can withstand the increase in complexity, you can mostly have your cake and eat it too -- server-side rendered robust client applications.

Even for the most stalwart monolith enthusiast, isn't it nice to make it relatively difficult for your View code to call some Model/Controller/util method/function that it shouldn't be calling? If you go through the trouble of committing to separating your "API" and your "frontend server" (there's a trendy name for this which I have forgotten -- "companion" server? BFF?[1]), you get better focused and hopefully more manageable domains.

All _that_ said, portals are a pretty cool new feature, but I'm not going to hold my breath for them to be ready to use any time soon.

[0]: [https://bestofjs.org/timeline](https://bestofjs.org/timeline)

[1]: [https://docs.microsoft.com/en- us/azure/architecture/patterns...](https://docs.microsoft.com/en- us/azure/architecture/patterns/backends-for-frontends)

<comment><USER13> > There is a reason we are where we are in the front end world

Insecurity resulting from a lack of proper training.

<comment><USER12> Well yeah, but that's everywhere. More realistically I think it's because browsers are the biggest software delivery platform every created (and likely that ever will be created until we get some sort of neural/in-body interface), and they change faster than regular desktop software ever could.

The browser is so popular as a software distribution method, it now competes with GTK/QT/Cocoa/etc for (large amounts of) "RAMshare" on your neighborhood desktop.

<comment><USER10> Yes to everything here except ... browsers do not change faster than the equivalent part of desktop software: the toolkits (GTK/Qt/Cocoa/etc). The latter change at least as fast and often much faster than browsers ever had.

</comment></comment></comment></comment><comment><USER14> Let's say you're updating your UI through Ajax requests, something like Laravel Livewire. For example filtering a list. If you do a web request, although is going to be fast that request and the re-rendering could take up to 300ms.

That's very noticeable when you're browsing. It makes the website feel slow. It's very hard to beat that latency if you're going to update everything from the server.

So you really do need JavaScript to create that snappiness. If you're filtering in the browser with the data that you already received, it's going to feel instant.

I purposefully chose the filtering example because it's something that you can do server-side or client-side. But the server side is always going to feel slower if you're sending all the data in each request and simply changing the rendering.

So where do you draw the line? I think you should only let the server re- render the UI if there's new data being queried and sent. I'm of the opinion that JavaScript should only manage the interactivity of what receives and should be fetching very few data.

Of course this only makes sense if you're using something like Laravel or Rails. But even if you are building a SPA and working against a series of endpoints I think you should make an effort to write those endpoints in such way that you're sending as much data as you can in each request and let the client handle it without requesting again just to re-paint the UI.

<comment><USER15> I've yet to encounter client-side filtering. Usually there are many pages of items. Server returns selected page according to filter criteria. Client just does not have all the items, so he'll be able to filter only already visible items which is not useful.

</comment></comment><comment><USER16> "Blank page" problem is usually only a problem if your site is really slow, but if it is fast (because of server side rendering) it is less of a problem.

As the presenter in the video said, browsers can render HTML documents really fast, this leads to some interesting conclusions.

Assume that you need to render a modal as popup for each item in a grid.

Frontend solution would be to reuse the same modal for every item and just swap in the on-the-fly rendered content for that item. Or maybe even on-the- fly create & render the entire modal when needed.

Backend solution would be to render one modal per item. This is actually easier, just loop & have unique ids (you can even reuse the same loop that you build the grid with) & no need for dynamic loading, rendering, etc. So even if you send more HTML down the line, the page acts smother.

<comment><USER7> Let's say you have a query that takes 3 seconds, and about half second to manipulate that into something that makes sense and start sending the data over. With the single page solution, you can have a spinner that is allowing the user to know that something is happening. What does it look like if you click that link?

<comment><USER17> You know browsers have built-in loading spinners?

[https://media.giphy.com/media/anjRJ4nv9WJzO/source.gif](https://media.giphy.com/media/anjRJ4nv9WJzO/source.gif)

In my experience, any time a web site reimplements basic browser functionality in JavaScript (e.g. loading spinners, scrolling, navigation) it is slow, buggy, and annoying.

</comment></comment></comment><comment><USER18> A proper fully clientside rendered website gives a much better user experience. Yes you need a strong clientside framework able to render components, maintain state, history etc. Once the application is loaded, the only data communication between server and client is JSON or some other format. Much more efficient in bandwidth and speed. Another plus is that you can actually have multi platform versions of the application with the look and feel of the target platform. Good luck to get that feeling with a 800ms delay serverside rendered page.

The main reason why you shouldn't do it, is because of SEO. Dynamic sites are considered weak in SEO. Very challenging to get them properly indexed by Google etc. You also got still a lot of engineers who somehow favour the serverside rendering. For inhouse internal apps or b2b apps I would always prefer a clientside app.

<comment><USER19> I agree in theory but in practice SPAs chug on initial loading and they chug on loading new content (and they often even chug when scrolling this content!). the experience of using many websites increased drastically with javascript disabled. Something is clearly wrong with current SPA practice if this is the consistent result that users see.

</comment></comment><comment><USER20> Until convinced otherwise, I'll continue using Vue and if necessary server- side rendering of it. This post didn't change my opinion.</comment>


"My team will be able to program circles around everyone else" (2002) - <AUTHOR> http://tech.groups.yahoo.com/group/feyerabend-project/message/252 <comment><USER2> Yahoo's download limit reached, here's Google's cache: [http://webcache.googleusercontent.com/search?q=cache:07l8NZL...](http://webcache.googleusercontent.com/search?q=cache:07l8NZL4S44J:tech.groups.yahoo.com/group/feyerabend- project/message/252)

<comment><USER3> "The message you requested is temporarily unavailable because this group has exceeded its download limit. Please try again later." kind of blows my mind. This is yahoo, not some weird server running on a 4.77MHz processor in Turkmenistan.

<comment><USER4> <http://ascii.textfiles.com/archives/2848> # YAHOO!LOCAUST

</comment></comment></comment><comment><USER5> For some context, <http://www.dreamsongs.com/Feyerabend/Feyerabend.html>

There is a tone of defeatism here. As Alan Kay said, Smalltalk and Lisp tend to eat their young. Common Lisp is a testament to how great Lisp is but it's no end game. Alan Kay always said he expected people to make something way, way, way better. And yet no one did for such a long time.

Luckily there are some Lisps today that are no longer sitting around twiddling their thumbs.

</comment><comment><USER6> I fail to buy this argument -- _Because Lisp is dead, I'll get better programmers for less money._

<comment><USER7> Because it makes no sense ... Programmers for dead/dying ususally languages cost more

<comment><USER8> It's hard to motivate people to work in terrible old languages that won't contribute to their market value in the future. But I can believe that people make exceptions for languages that they love and wish weren't dead.

</comment></comment></comment><comment><USER9> > The message you requested is temporarily unavailable because this group has > exceeded its download limit. Please try again later.

Text anyone?

<comment><USER10>
      Subject: Re: [feyerabend-project] An introduction to Lisp
      From: "Richard P. Gabriel"
      Date: Tue Aug 27, 2002 1:03 pm

At 22:23 +0200 8/25/02, Dirk Riehle wrote:

      >Choosing CLOS or the like:
      >
      >- you don't get enough people
      >- those people you get cost too much
      >- you are incompatible with the rest of the world
      >- adapters and bug-fixes will always be last for you

Though it's not relevant, I would argue like this:

My team will be able to program circles around everyone else. They will be able to construct rapidly a language specific to the problem we are solving rather than using a language designed by computer scientists worrying about their place in history and a herd of library writers working in cubicles a thousand miles from our business. My team will be able to use a language without training wheels. Strong typing is for weak minds, and it's exactly like they say at MIT: Our current popular languages are designed to help losers lose less.

I will be able to point to various examples where Lisp programmers have written not only 3-5 times faster, but they wrote things other programmers thought were impossible. In this regard, I'd tell the CEO, our competitors will be spending all their time trying to figure out that it's really possible we're doing what we're doing, because they will be thinking in terms of customization at compile time or link time, not at runtime.

Moreover, we will be operating where the CEO is focusing on his or her specialty and not imposing his or her knuckleheaded view on technology.

Because Lisp is dead, I'll get better programmers for less money. I'll be able to guarantee 50 more IQ points for the same pay. And my guys will be able to spend their time typing in value not book keeping overhead and typing in type descriptions because their guys are too stupid to know when they type + numbers are involved.

Because no one uses Lisp, I'll have my pick of thousands of great, experienced programmers looking to work for someone with a non-zero IQ, not the ones fresh out of college with 10 programs under their belts.

I'll be compatible with everything because it is right now. And if someone throws me a bug, I can code around it in a few minutes. Being a niche market means we're more proprietary. People will not use Lisp to compete with us because they are lamebrains listening to the latest fashion statement from Sun or Microsoft.The open source crowd isn't even smart enough to notice C++, so they are especially nowhere in the picture.

Of course, no CEO will belive this because every one of them is stupid.

-rpg-

<comment><USER11> Oh gosh it reads brilliantly - it is meant to be ironic, yes?

<comment><USER12> Richard Gabriel is the master of writing things that leave that exact question unanswered. For eg - <http://www.dreamsongs.com/WorseIsBetter.html>

</comment></comment></comment></comment><comment><USER13> That post is hilariously arrogant and off-the-mark. "Strong typing is for weak minds?" Really? I suppose this guy compiles his code by hand too. I would go out of my way _not_ to work with someone so cocky.

<comment><USER14> _That post is hilariously arrogant and off-the-mark. "Strong typing is for weak minds?" Really?_

While I grant that that's a harsh statement, would you disagree with what he says next?

"Our current popular languages are designed to help losers lose less."

<comment><USER15> I consider myself a fairly strong programmer. I have worked with literally hundreds of programmers over my career. None have been better than me. Now I'm not the smartest person on the planet, I'm not even smarter than say Sheldon Cooper, but despite the article author's assertion, you _cannot_ hire someone who has an IQ 50 points higher than mine.

All that said, I've recently done a couple of months of programming (in a very restrictive environment) in Javascript, and I _yearn_ for a compiler.

Perhaps these tools do help "losers lose less"... but a tool is a force multiplier (bad tools are multipliers with a value less than one, and truly bad tools have negative multipliers :D _Not all tools are bad_.)

In the hands of an expert, the right tool can become a powerful weapon.

<comment><USER16> "I have worked with literally hundreds of programmers over my career. None have been better than me."

Really? In every aspect of programming? In every language? This is the typical prima donna bullshit that pervades this industry. I pity anyone who has to deal with you on a daily basis.

</comment></comment></comment></comment><comment><USER17> This was ages ago. Does anyone know what happened? Was the confidence justified? Can we learn anything from their experience?

</comment><comment> daniel-cussen Hey both states the advantages and implies the disadvantages of working with Lisp. Advantages: dynamic typing, macros ("customization at compile time or link time, not at runtime.") dealing with bugs, etc. He really knows his shit, too, especially with regards to how Lisp compiles. So the good news is, he's right.

But that's the bad news, too. He's right, but not tactful.

This that holds Lisp back in a business setting: the tech is awesome, the people skills aren't. Entrepreneurs considering doing a Lisp startup would be wise to address this as part of your strategy.

<comment><USER13> That dynamic typing and Lisp-style macros are advantages is highly debatable. Most programmers I've worked with (some of whom are probably in the top 1% of coders in the world, these include the guys who developed PLT Scheme) would in fact consider both those features to be _dis_ advantages.

Example counterarguments:

Static typing is far better than dynamic typing. There is nothing you can express in a dynamically typed language which you cannot express in a statically typed language, and most of those things can be expressed just as succinctly thanks to type inference. Further, to use your own words, static typing provides _debugging_ "at compile time or link time, not at runtime."

Hygienic macros (i.e., macros which gracefully handle identifier collisions) provide all the same "language-building" features of Lisp-style macros without mysterious bugs caused by namespace clashes. Furthermore, the "customization" use case you point out is far better served by either higher-order modules (a.k.a. functors), which enforce provides-requires relationships at compile time; and by compile-time inlining of static code (also known as partial compilation), thus allowing the same language to be used for compile-time and run-time code.

<comment><USER18> I'm going to agree with you about dynamic typing. I spend most of my time programming in dynamic languages, but I spend a lot of that time pretending I have static types. I waste a lot of CPU cycles making up for the safety difference between static and dynamic typing. Then I waste even more to be able to store "hello world" and 42 in the same variable, even though I never need to do this.

Fortunately, if I care about CPU time, I just use Haskell, which gives me the syntactic sugar and expressiveness of Lisp with the type safety of ... well ... Haskell.

<comment><USER19> The question isn't whether you want static types while running or debugging (or testing). The question is whether you want static types while developing.

</comment></comment></comment></comment><comment><USER20> I think i've read this before, maybe from Paul Graham?

<comment><USER21> Well most of the arguments are the same, Richard Gabriel is just less tactful than pg.

What I want to know is whether Richard P. Gabriel ever had business success with LISP rather than just academic success. A quick scan of wikipedia doesn't mention any modern businesses.

<comment><USER15> He raised by my count over 4 million dollars back in the 80s (back when that was real money), and the company lasted 10 years. If that isn't getting a business "off the ground", I think your criteria is far too harsh!

But (if I understand the timeline) by the time he wrote that, the prior business had been dead and buried for 7 or 8 years. Reading between the lines, I think they attached themselves to a platform that looked good (symbolics) at the time, but which failed to capitalise on it's potential. Essentially they were in the accessories aftermarket... and if that market disappears you'll go down with it.

<comment><USER22> Lucid was the disruptive competitor to Symbolics: rather than building expensive hardware to run Lisp fast, they built expensive software to make mainstream hardware (e.g. SPARCs) run Lisp fast. AFAIK they never had a product that ran on LispMs.

</comment></comment></comment></comment><comment><USER23> beware, that man is an artist and might not see the world as it is, but as it should be.

</comment><comment><USER24> they believe lisp is secure because its rare. thats kinda strange like driving a trabant.

(and its still hackable).</comment>


Relational lattices: From databases to universal algebra (2015) [pdf] - <AUTHOR> http://www.dcs.bbk.ac.uk/~szabolcs/rellat-jlamp-second-submission-2.pdf <comment><USER2> Can anyone express why this is important before I dive into this paper?

<comment><USER3> I just skimmed, pulling on whatever related math I know and it looks to be relevant if your into database query optimisers and such.

It turns out that join constraints that may be costly to compute can sometimes be simplified to something equivalent or even s completely elided in some circumstances simply by doing some algebra on the join operators.

Good luck!

</comment></comment><comment><USER4> Well, my ego has been sufficiently deflated enough for one night....</comment>


Relay FAQ: Facebook's Data-fetching Framework for React - <AUTHOR> https://gist.github.com/wincent/598fa75e22bdfa44cf47? <comment><USER2> I wrote the gist; happy to answer questions (although out and on my phone right now so I won't be super fast).

<comment><USER3> A common problem in a service oriented architecture is needed to minimize the amount of round trips to a particular service.

Example: To render a UI view, I need to fetch a list of friends, a list of posts, and a list of notifications. All 3 of these data types (friends, posts, notifications) have users associated with them. Instead of fetching users for the 3 data types 3 separate times, I need to flatten that into a single call. I end up with something like this:

      var [posts, friends, notifs] = yield [
        getPosts(),
        getFriends(),
        getNotifs()
      ]; // executes in parallel

      var userIDs = new Set();
      userIDs.addAll(posts.map(p => p.userID));
      userIDs.addAll(friends.map(f => f.userID));
      userIDs.addAll(notifs.map(n => n.userID));

      var users = yield getUsers(userIDs.toArray());

      return {posts, friends, notifs, users};

You can see where this gets cumbersome. I have to compose one of these for every kind UI view at the root level. On the one hand it's very explicit and the flow of data is very clear, but it also means relationships between data are dupicated in more than one place (often many places).

Could GraphQL help with that scenario?

<comment><USER4> What language is that?

<comment><USER3> That's ES6 JavaScript (running on Node 0.11.15). We've already migrated most of our production code to this and we're loving it!

If you like that kind of control flow, check out the library we wrote to do it: [https://github.com/storehouse/engen](https://github.com/storehouse/engen)

<comment><USER5> Why not use let instead of var?

<comment><USER3> Only habit. We're so used to var. But yea, need to transition to let for most things.

<comment><USER6> I think migrating to const makes more sense. In practice only a few things require to be mutated.

<comment><USER5> Didn't realize const was in. Will definitely be using it.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> Much of this FAQ reminds me of a little-known library called Breeze.

BreezeJS is a stand-alone data library for SPAs which takes care of managing the lifecycle of data objects; querying, fetching, caching is all taken care of. Queries use OData by default, but implements a specific subset of the query language that can rendered down and used against REST apis. Breeze also provides server libraries for different stacks to easily integrate and get up and running.

Granted the usecase of embedding declarative queries as part of a component which gets composed along with other components+queries is unique to React, but I speculate it wouldn't be too difficult to implement within Breeze.

All that said, it will be nice to see another rich-data management library to compare and contrast. The days of painstakingly writing business objects in 34 places will end.

</comment><comment><USER8> Would it be accurate to say that Relay's approach works best for component- based apps (not React components, "component" in the more general sense) - that is, the app is made up of a bunch of mostly separate components that encapsulate their own state, like {Feed, Ads, Groups, Messaging, Photos, Events, Minifeed}, which don't really share much state and don't require central coordination?

<comment><USER2> Not really. It's true that those kinds of "components" will usually live on their own routes, but there's nothing intrinsic to the framework that favors that particular kind of app structure.

<comment><USER9> I'd like to phrase dustingetz' question slightly differently: if you're building an app that does _not_ have multiple relatively independent parts as dustin describes, does Relay still have a major advantage over what's currently common? (i.e. if one page is only ever one "thing", how is it better than just calling the right APIs from the router be done with it?)

</comment></comment></comment><comment><USER10> "Simplified server implementation: Rather than having a proliferation of end- points (per action, per route), a single GraphQL endpoint can serve as a facade for any number of underlying resources."

GraphQL sounds tremendously exciting.

</comment><comment><USER11> This looks incredible.

Especially excited at the idea of a single store. I've always had a little bit of a beef with Flux when it came to interdependencies within stores.

I feel like one of the problems with react that is currently not well solved is the integration of a client and server side router for a truly isomorphic application. There have been quite a few implementations that rely on a single om-like state that they serialize and deserialize to the client. Relay feels like it would fit extremely well into this paradigm.

<comment><USER12> Check out [http://entrendipity.github.io/astarisx/](http://entrendipity.github.io/astarisx/) . It uses a Single Source of Truth to accomplish what you're after.

</comment></comment><comment><USER13> This looks very similar to a library I've been working on (live demo here for webkit browsers: [http://city41.github.io/bookends/demo.html](http://city41.github.io/bookends/demo.html)), and it was inspired by a similar framework that is used at my former employer.

</comment><comment><USER14> Also, this is as interesting as React Native. And React Native is pretty interesting.

</comment><comment><USER14> This is the biggest thing for JSON payload control since...JSON APIs became a thing?

<comment><USER15> What's "JSON payload control" exactly?

<comment><USER14> Confidence in returning the minimum to render a view. By default, without having to worry about over / under fetching data. Not having to worry about cleaning up endpoints when the needs of the consumer changes. A client that requests exactly what it needs, rather than hitting an endpoint with 'something', is extremely efficient.

<comment><USER15> Great answer; thanks for the clarification!

</comment></comment></comment></comment><comment><USER16> Here's the video introducing it at React.js conf: [https://www.youtube.com/watch?v=9sc8Pyc51uU](https://www.youtube.com/watch?v=9sc8Pyc51uU)

</comment><comment><USER17> If you're interested in building GraphQL with Node+Mongo, checkout this github project: [https://github.com/lutherism/GraphNoQL](https://github.com/lutherism/GraphNoQL)

<comment><USER18> Wow! That was fast!

</comment></comment><comment><USER19> I am confused: why is data made available as props and not as state?

<comment><USER20> This [https://github.com/uberVU/react-guide/blob/master/props- vs-s...](https://github.com/uberVU/react-guide/blob/master/props-vs-state.md) is a good explanation of the difference. But in short, it essentially comes down to who can manipulate the data. If the component will manipulate it, then it is state. On the other hand, if a difference source is going to be manipulating it, then it should be a prop. In this case, the client side of relay will be changing the data according to instruction from the server (e.g. a new message arrived). Therefore, the state is being passed as a prop.

</comment></comment><comment><USER21> Does Facebook list browser requirements for all of this anywhere? (Translation: can I use any of this at my day job?)

<comment><USER22> Relay is positioned as being complementary to React, and React itself currently works on IE8+. There is talk of phasing out IE8 compatibility from React (probably later this year), but as of today it works on IE8 perfectly fine for us.

<comment><USER21> Thanks!

None of this tech requires much promotion since it's clearly the new hotness, but there is a silent majority of developers that would appreciate knowing when they can start paying attention professionally. Hopefully soon all JavaScript projects will include a list of supported platforms alongside their corner GitHub banner.

</comment></comment></comment><comment><USER23> This is very interesting. I'm currently a little bit of the way through solving some of the problems solved by Relay using an existing open source stack, and I'm curious if anyone has any thoughts on how it would compare. I've only skimmed the Relay video, and I haven't created a full React app yet, so forgive me if I get something wrong.

First, for the framework-level handling of fetching all data before rendering, where the data needed by each component is defined in each component, just copy how it's done in react-router's async-data example [1], modified to expect a hash of promises as in [2].

The promises return Backbone-Relational models [3]. You can model arbitrary relations using Backbone-Relational, although many-to-many is apparently kind of hacky (but just needs work to be seamless). It supports parsing REST API responses with nested models and collections as related models. A REST API generator like Flask-Restless [4] creates these responses with a single efficient query.

You have the flexibility to either sync all models before rendering, or render any component without all data already being fetched, and have it automatically re-render when loaded.

Components subscribe and unsubscribe to model events at the proper points in the component lifecycle using react-backbone-component.[5] I missed this and wrote my own version [6] before I found it, but mine is cleaner, slightly more featureful, and presents a simpler API.

Anyway, this requires some work to pull together, but I think it presents a viable alternative that:

\- uses existing libraries that do one thing well and allows as much departure from each elements of the architecture as you want

\- works with react-router, which is the shit

\- works with your existing REST API

Relay looks wonderful, but it's possible to build the abstractions that do pretty much the same thing that support existing REST APIs.

[1] [https://github.com/rackt/react- router/blob/master/examples/a...](https://github.com/rackt/react- router/blob/master/examples/async-data/app.js#L121)

[2] [https://github.com/rackt/react- router/wiki/Announcements](https://github.com/rackt/react- router/wiki/Announcements)

[3] [http://backbonerelational.org/](http://backbonerelational.org/)

[4] [https://flask-restless.readthedocs.org/en/latest/](https://flask- restless.readthedocs.org/en/latest/)

[5] [https://github.com/magalhas/backbone-react- component](https://github.com/magalhas/backbone-react-component)

[6] [https://gist.github.com/mwhite/f763c189f58de7af5d34](https://gist.github.com/mwhite/f763c189f58de7af5d34)</comment>


What made Xerox PARC special? Who else today is like them? - <AUTHOR> https://www.quora.com/What-made-Xerox-PARC-special-Who-else-today-is-like-them/answer/Alan-Kay-11?share=1 <comment><USER2> _" You know what makes the rockets fly? Funding."_ \- The Right Stuff.

What really made PARC work is that they were funded to develop the future of computing by building machines which were not cost-effective. It was too early in the mid-1970s to develop a commercially viable personal workstation. But it was possible to do it if you didn't have to make it cost-effective.

That's what I was told when I got a tour of PARC in 1975. They had the Alto sort of working, (the custom CRT making wasn't going well; the phosphor coating wasn't uniform yet) the first Ethernet up, a disk server, and I think the first Dover laser printer. All that gear cost maybe 10x what the market would pay for it. But that was OK with Xerox HQ. By the time the hardware cost came down, they'd know what to build.

Previous attempts at GUI development had been successful, but tied up entire mainframe computers. Sutherland's Sketchpad (1963)[1] and Engelbart's famous demo (1968)[2] showed what was possible with a million dollars of hardware per user. The cost had to come down by three orders of magnitude, which took a while.

Another big advantage which no one mentions is that Xerox PARC was also an R&D center for Xerox copiers. That's why they were able to make the first decent xerographic laser printer, which was a mod to a Xerox 2400 copier. They had access to facilities and engineers able to make good electronic and electromechanical equipment, and thoroughly familiar with xerographic machines.

Ah, the glory days of Big Science.

[1] [https://www.youtube.com/watch?v=6orsmFndx_o](https://www.youtube.com/watch?v=6orsmFndx_o) [2] [https://www.youtube.com/watch?v=yJDv- zdhzMY](https://www.youtube.com/watch?v=yJDv-zdhzMY)

<comment><USER3> _> Ah, the glory days of Big Science._

This still happens! Silicon Valley gets a lots of long-term oriented funding from taxpayers via DARPA and other government agencies. Siri (named after SRI International where Engelbart did his work) and autonomous driving (DARPA Grand Challenge) are just a couple of recent examples.

In fact PARC still does too. Although owned by a private company, PARC does government-funded research.[1]

I would say generally people in SV are less consciously aware of the major role government funding plays in it to this day. It's probably because of the mythos of private entrepreneurship and the uncomfortable narrative of all this so-called "free market capitalism" being supported by billions in govt funds, with only a fraction of the profits returned to the public coffers via taxes.

[1] [https://www.parc.com/news-release/97/parc-awarded-up- to-2-mi...](https://www.parc.com/news-release/97/parc-awarded-up-to-2-million- from-darpa-to-develop-vanishing-electronics.html)

<comment><USER4> I've been funded by DARPA in one way or another and DARPA is not big science. DARPA is an applied R&D agency, meaning they want to see a path from what you are talking about to some broad application, preferably in the military space. If you can't describe that path to them, the odds of getting funded by them are low (this is drawn from experience of winning more than 10mil in funding from DARPA on many different programs).

The DARPA model is also not big science because the researchers on the outside do not pick the problems, the PMs at DARPA do. The model works when a visionary becomes a PM and is given a "big" (20-80 mil) bucket of money to disperse to researchers to enact their big ideas. If the PMs are truly visionary, then this works. If they are not, you wind up with a sort of soup of crap.

Additionally, since it's applied, DARPA will do frequent (once a quarter and once a year) check-ins, measurements, and progress reports. If you don't measure up during those, your funding gets cut. So as a researcher, it is a challenge if what you want to do is a little bit off the path of what the PM wants to do.

I have much more limited exposure to IARPA but it seems to be the same way there.

I have more experience with NSF, which is the total opposite: researchers propose their own projects and there are infrequent touchpoints, and no cut points really. However, NSF will give you one to two orders of magnitude less money than DARPA.

<comment><USER5> I work on several DARPA programs and agree with most of this. But some programs are by design far more basic or applied than others. Also worth noting - DARPA generally doesn't pay contractors anything like what the private sector pays employees.

The programs (and their vision, and their success) depend quite a bit on the PM, and on their ideas and engagement. To a lesser extent success depends upon the SETAs as well.

<comment><USER4> > DARPA generally doesn't pay contractors anything like what the private > sector pays employees.

Eh. You can get like a $200/hr rate. If you're a small company with low overhead, you can get paid quite competitively with the private sector in base comp. Difficult to match big G stock grants, though, no one is becoming a millionaire off of this work.

Unless of course what you do on the grant can be turned into a billion dollar company, because (generally) contractors walk away from research programs with liberal rights to the IP they create, with the government retaining some rights to use, but very rarely (IME) retaining direct ownership. Of course, it's probably not that likely that what you do can turn into a billion dollar company but hey, one can dream...

<comment><USER6> Thankfully one doesn't (usually) need to create a billion dollar company to become a millionaire.

</comment></comment></comment></comment></comment></comment><comment><USER7> To be like Xerox PARC today you'd have to move back to the time when Xerox did what they did there. It's not just the company or the people but the total environment in which that took place.

Once the canvas is no longer blank it becomes a lot harder to be that innovative. All kinds of brakes on the system engage almost automatically: conventions, languages, processors, window managers have all become a lot less open to really new concepts.

The biggest changes of the last couple of years are deep learning coupled with the advent of GPUs that have computing power that was only affordable to universities not that long ago for very little money. Possibly that will engender a totally new computing environment in which our 'old' stuff no longer matters as much and we'll be more free to pursue things that are less anchored in the practical requirement to make money.

I suspect the whole 'deep learning' revolution will be as big as the original invention of the transistor or the web. It won't give us full AI but maybe by the time we've mined that for all it's worth we won't feel the need for it anymore.

<comment><USER8> do you really think that about deep learning? it has zero application or effect in my job (i don't see that changing for at least the next decade) and in my personal life, it only serves to produce "better ads".

<comment><USER7> > do you really think that about deep learning?

Yes, absolutely. To put it bluntly: how many jobs do you think are affected by being deaf and blind?

Computers are now able to see and hear, and on top of that they have become better at most classification tasks than humans. Those are game changers, this goes much further than advertising.

<comment><USER9> What you state is factual. In the context of "as revolutionary as transistor", then I'd say yes as well. But when it comes to jobs, deep learning's impact is overstated.

When I hear claims on how many jobs will be replaced because of deep learning (in contrast to the base rate of the long, steady slope of automation over the last 175 years), it's often about an abstract and simplified notion of the complexities of jobs outside the claimant's area of expertise. In such cases, it's useful to ask the claimant whether _their_ profession is soon to be made obsolete. Will AI replace the pundit anytime soon? The economist? The enterprise programmer? The AI researcher?

<comment><USER7> The welder, the courier, the truck driver, the cab driver, the pilot, the GP, the gardener... I could probably make a _really_ long list of jobs that will be affected, pundits are safe for now (but composers and painters are not), economists are probably safe too if only because they always seem to manage to weather the storm without damage even if they caused the storm and still failed to predict it. Enterprise programmers are safe - for now -, but keep in mind that humans already know how to teach each other stuff, as soon as programming becomes hard to distinguish from teaching by example that enterprise programmer had better watch out.

Let's review this in a decade or so and see what happened.

<comment><USER10> Well, what do you mean?

I think it's obvious that machines can, for example, weld better than humans can. But machines can't decide _what_ to weld. For now in that arena, things are mostly still human controlled.

I think your argument gets significantly weaker when you push truck, car, and plane driving onto the conversation stack.

Even the best of self-driving AI automation isn't nearly as good as bad human driving. Yet.

But the absolute best human weld joints are no better than the absolute best robotic weld joints.

I think you're talking about two entirely different domains here when you conflate welders and couriers. One of those needs a human decision to place the components to be welded next it in front of a robot that basically does one thing. The other is an actual adaptive AI that's trying to make decisions on it's own.

Yes, it's obvious that the lowest-wage and lowest-skilled workers are going to be displaced by robots the soonest. That's like arguing that the sun is going to rise. And as a society, we need to account for that.

But arguing that the lowest hanging fruit of automation is going to displace taxi drivers and gardeners in the next 10 years is pretty nuts, even for HN.

<comment><USER11> It is definitely not obvious that machines can weld better than humans can. I think a lot of computer tech people would be surprised by how much welding is still done by hand. Most of the welds on a Boeing 787 are done by humans, for example.

I feel like this fits the description in the comment above:

> When I hear claims on how many jobs will be replaced because of deep > learning (in contrast to the base rate of the long, steady slope of > automation over the last 175 years), it's often about an abstract and > simplified notion of the complexities of jobs outside the claimant's area of > expertise.

<comment><USER12> Machines have nowhere near the flexibility of humans, so obviously they're worse at tasks _in environments designed for humans_.

But were you optimize the Boeing manufacturing process for machines, the way car factories are optimized, you could utilize strengths of machines while sidestepping their limitations.

(Why this does not happen often is I believe a combination of robots having high initial costs, coupled with products starting as human-assembled prototypes, and companies just optimizing that process incrementally, instead of redesigning it around machines.)

<comment><USER7> And unions.

<comment><USER13> And relatively low volumes. If you're going to pump out 3 million cars a year vs 2000 of that plane ever, it changes the equation somewhat.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER14> I'm less of a PARC fan and more of a Lampson fan. In fact, I'm a huge Butler Lampson fan. I've read his PARC valedictory _Hints on Computer System Design_ many times and he's updated it recently. He went from PARC to DEC SRC (maybe 5 miles). I saw him give a talk at SRC and for about 15 minutes afterwards, I understood.

 _Hints_ is the favorite paper of a lot of my heroes like John Regehr.

[https://www.microsoft.com/en-us/research/wp- content/uploads/...](https://www.microsoft.com/en-us/research/wp- content/uploads/2016/02/acrobat-17.pdf)

[http://bwlampson.site/Slides/Hints%20and%20principles%20(HLF...](http://bwlampson.site/Slides/Hints%20and%20principles%20\(HLF%202015\).pdf)

[http://blog.regehr.org/archives/1143](http://blog.regehr.org/archives/1143)

From SRC, he went to Microsoft and he also taught at MIT.

[https://ocw.mit.edu/courses/electrical-engineering-and- compu...](https://ocw.mit.edu/courses/electrical-engineering-and-computer- science/6-826-principles-of-computer-systems-spring-2002/)

<comment><USER15> Let me encourage you to be both. Butler is one of the most amazing people I've met and had the great pleasure of working in the same environment with him for many years. I also think that all of us who were there would not want to try to separate "the great people" from "the great environment" nor would it be possible without great distortion (this is the point that most people miss about ARPA/PARC).

<comment><USER14> Thanks Alan. If my current project succeeds, and it should, I'm going to try to reach out to Butler and present it to him because frankly, it has Lampson written all over it with maybe some Thacker graffiti here and there.

<comment><USER16> May I ask what your current project is?

</comment></comment></comment></comment><comment><USER17> Microsoft Research Silicon Valley (MSR-SVC) used to be like PARC of old. Too bad it was shut down a few years ago. I don't know if any place comes close. To be fair, there are pockets of awesomeness at places like IBM T.J. Watson and MSR Redmond .. you need to be lucky enough to work with the right group of people.

Edit: I should point out that while it is awesome to work in such a storied place, there is some stress associated with it. Read about the weekly "Dealer" meetings at PARC.

<comment><USER18> Interesting read on "Dealer" meetings.

From The Myths of Creativity By David Burkus

>> In the 1970s at Xerox PARC, regularly scheduled arguments were routine. The company that gave birth to the personal computer staged formal discussions designed to train their people on how to fight properly over ideas and not egos. PARC held weekly meetings they called "Dealer" (from a popular book of the time titled Beat the Dealer). Before each meeting, one person, known as "the dealer," was selected as the speaker. The speaker would present his idea and then try to defend it against a room of engineers and scientists determined to prove him wrong. Such debates helped improve products under development and sometimes resulted in wholly new ideas for future pursuit. The facilitators of the Dealer meetings were careful to make sure that only intellectual criticism of the merit of an idea received attention and consideration. Those in the audience or at the podium were never allowed to personally criticize their colleagues or bring their colleagues' character or personality into play. Bob Taylor, a former manager at PARC, said of their meetings, "If someone tried to push their personality rather than their argument, they'd find that it wouldn't work." Inside these debates, Taylor taught his people the difference between what he called Class 1 disagreements, in which neither party understood the other party's true position, and Class 2 disagreements, in which each side could articulate the other's stance. Class 1 disagreements were always discouraged, but Class 2 disagreements were allowed, as they often resulted in a higher quality of ideas. Taylor's model removed the personal friction from debates and taught individuals to use conflict as a means to find common, often higher, ground.

<comment><USER15> This is overdrawn and misses the process and the intent. They weren't staged, they were not "designed to train their people", etc. It was part of the larger ARPA community to learn how to argue to illuminate rather than merely to win. PARC came out of the ARPA community and Bob Taylor had been the third director of IPTO.

The main purposes of Dealer -- as invented and implemented by Bob Taylor -- were to deal with how to make things work and make progress without having a formal manager structure. The presentations and argumentation were a small part of a deal session (they did quite bother visiting Xeroids). It was quite rare for anything like a personal attack to happen (because people for the most part came into PARC having been blessed by everyone there -- another Taylor rule -- and already knowing how "to argue reasonably".

<comment><USER17> As a relatively young scientist, I feel I lack the "argue reasonably" skill. How does one get better at this?

</comment></comment></comment></comment><comment><USER19> This link led me on to a little bit of wikipedia reading where I learned something that _really_ surprised me: according to wiki, Xerox today still employs more people than either Microsoft or Apple, 130k to their 115k each. Am I the only person who finds that shocking? I had no idea they were still so huge. And this despite their market cap being a hundredth of Apple or Microsoft's.

<comment><USER20> Wow. What do those people _do?_ For that matter, what does _Xerox_ do these days?

<comment> jon-wood Xerox these days still make photocopiers, but they also work as really nice printers and network connected scanners.

I imagine a lot of their employees are in the service division. When you buy a high end printer it also comes with a service contract where someone will proactively come and do things like clean the printer and make sure toner is stocked.

</comment></comment></comment><comment><USER21> "Who else today is like them?"

I don't know, but for sure, they're not in computing. PARC was special, among many other reasons, because it existed (and had the vision and the funding) in the early, gold rush era of computing. Google Research isn't it, not because they're not generously funding important and worthy research, but because computing as a field is too far along for them to have a chance of introducing truly fundamental research in the area. Self-driving cars comes close, no doubt hugely important, but even they have a quite incremental feel to them, especially next to inventing something like the graphical user interface.

<comment><USER22> I'd say quantum computing is still in a very early stage with many unsolved problems, especially on the implementation side.

</comment></comment><comment><USER23> There are some especially qualified answers on Quora. But to have your question answered by Alan Kay on the topic on Xerox PARC is truly special.

<comment><USER24> Agreed. I think he is a hackernews user as well

<comment><USER25> Wasn't he going to do some kind of work with ycombinator attempting to recreate some of the spirit of Xerox PARC? Maybe I just dreamt it.

<comment><USER7> HARC

[https://news.ycombinator.com/item?id=11679680](https://news.ycombinator.com/item?id=11679680)

<comment><USER25> That was it. Official site: [https://harc.ycr.org/](https://harc.ycr.org/) Nothing super interesting there yet, at least to me :/

<comment><USER26> Bret Victor (worrydream.com) is a PI at HARC, having seen his previous demos, I'm very optimistic about HARC's future.

</comment></comment></comment></comment></comment></comment><comment><USER27> I've been reading the book he mentions, "The Dream Machine", by Mitchell Waldrop. It has been a great read so far (I'm a little past the point of the creation of ARPA), particularly the section about John McCarthy developing LISP and conceiving of the architecture for time-sharing.

Reading it has felt like I'm paying my respects to the pioneers of our field, because I am humbled by what they achieved.

<comment><USER28> It's interesting (to me at least) how much of the ideas they had back then are still waiting to be expounded on, they (and people like them) did the foundational work we still build new things on now, I read a book (I wish I could remember the title) about the architecture of the 2nd and 3rd generations of IBM's mainframes as they battled with the problem of "how do we keep the same software running on different hardware" and came up with virtualisation etc.

I wonder how many dusty copies of papers sat in university libraries contain ideas that brushed up and given a new coat of paint would be considered revolutionary.

The other side of it is I still use stuff those guys _wrote_ every day, while typing this I switched a bash terminal to run an install command using a program that is pretty much identical (if a superset) of a program written in 1977, 3 years before I was born.

</comment></comment><comment><USER29> For those interested, more answers from alan kay available here: [https://www.quora.com/profile/Alan- Kay-11](https://www.quora.com/profile/Alan-Kay-11)

</comment><comment><USER30> I'd strongly recommend the book Dealers of Lightning. Now I should comment that Alan Kay was at Parc and its where he did amazing work that holds up to this day so pay the most attention to his answer of course. But I learned a ton about Parc's history from Dealers of Lightning.

I'd also point out that Bob Taylor apparently had a hard limit of 50 researchers because he felt that was all he could manage. This meant that he, by this criteria, had to get the absolute best, smartest scientists / researchers he could find. If you look at the sheer number of absolutely brilliant people assembled at Parc during the same time period, it is astonishing: Alan Kay (smalltalk), Butler Lampson (alto, *), Bob Metcalf (ethernet), the founders of Adobe (postscript), Charles Simonyi (bravo which later became Microsoft Word), etc. Close to 100% of modern computing directly came from Parc.

<comment><USER31> This might be relevant: in the AMA that he did less than a year ago [1], Alan Kay said [2]:

> "Dealers of Lightning" is not the best book to read (try Mitchell Waldrop's > "The Dream Machine").

That said, I have read Dealers of Lightning myself, and really liked it. I have not yet got around to The Dream Machine.

[1] [https://news.ycombinator.com/item?id=11939851](https://news.ycombinator.com/item?id=11939851)

[2] [https://news.ycombinator.com/item?id=11940756](https://news.ycombinator.com/item?id=11940756)

</comment></comment><comment><USER32> > Who else today is like them?

> PARC still exists, but Google advanced technology projects is probably the > closest. Neither of these is that close to the old Xerox PARC since they > tent to focus on near term commercializable projects.

[https://www.quora.com/Whats-the-most-similar-thing-to- Xerox-...](https://www.quora.com/Whats-the-most-similar-thing-to-Xerox-PARC- that-exists-today)

...

While I can see how Google is an engine of scientific progress, Silicon Valley is bigger than Google. Stanford deserves a lot of credit.

Without diving into "what makes Silicon Valley Silicon Valley," I think I should point out that Stanford has consistently produced disruptions since at least Xerox PARC's founding.

(Obligatory: I have only ever visited Stanford, long after graduating from a different university.)

<comment><USER33> When you look at PARC's contributions (laser printer, bitmap graphics, GUI/windows/icons, WYSIWYG editor, Ethernet, OOP, MVC) or those of Bell Labs (transistor, laser, information theory, Unix, C & C++, radio astronomy), we haven't seen anything comparable from Google's Advanced Technology and Projects program. We can give them another 20-30 years and reassess, but so far, it's not there. Most of the projects have been announced with great fanfare and then quietly scrapped, or are solutions that haven't found problems.

PARC and Bell Labs were at the right place and right time to make fundamental contributions in the nascent areas of digital computers, software, and digital communications. They caught that wave perfectly. Now we're searching a similar revolutionary technology that will open the floodgates of innovation, but it's not apparent yet. Machine learning and AI? If that pans out, Google Brain/DeepMind would be well situated.

<comment><USER7> > we haven't seen anything comparable from Google's Advanced Technology and > Projects program

And we won't because all those things have already been done.

The laser didn't come from Bell but from Hughes btw.

> PARC and Bell Labs were at the right place and right time to make > fundamental contributions in the nascent areas of digital computers, > software, and digital communications. They caught that wave perfectly.

Precisely.

> Now we're searching a similar revolutionary technology that will open the > floodgates of innovation, but it's not apparent yet. Machine learning and > AI? If that pans out, Google Brain/DeepMind would be well situated.

Machine learning is disruptive to a degree that the web never was. The web is augmentative, machine learning is pure disruption. Jobs that require lots of people will soon open up to automation, this is going to change the world in very fundamental ways if it keeps going at the rate that it does right now.

The last three years have seen one humans-only benchmark after another give way and the party is just getting started.

<comment><USER34> I 100% disagree. The web is far more significant than machine learning. Machine learning hasn't changed _anything_ yet and I doubt it will ever significantly affect society.

Web has made society unrecognisable only 20 years later.

<comment><USER35> Unrecognisable means that if you take someone from 1997 and transport them into the present they wouldn't recognise today's society.

In reality societal changes in the past 20 years are superficial, so they would have no trouble recognising it.

<comment><USER28> I think that is a little unfair, unrecognisable would only really apply after a revolution/war, and even 1955 Germany would be recognisable to 1935 Germans (as one example).

To say that the changes have been merely superficial understates the case.

Online dating, online gaming, the disruption of existing media companies, Facebooks influence over the election, a president of the united states who tweets from the can, khan academy, youtube, the fact you can learn almost anything you can wish to learn by pulling a device out your pocket that is attached to an appreciable part of all human knowledge.

Computation on demand, I can pull out a credit card and have access to computing power that would have been unimaginable in 1997.

Social movements that have leveraged the web to achieve greater reach.

Those are things that mostly existed prior to 1997 but not in the sheer scope and _reach_ that they do now.

The social changes in current teens who live an always connected life (I'm not sure that's a good thing but I'm 36, I'm too old to judge without it sounding like 'back in my day').

I think when it comes to the web things are just getting started, the utility of the network is so great that barring the fall of civilisation I can't see it ever going away and the impact will just keep growing and we'll just keep connecting more and more stuff to it until it becomes a planetary zeitgeist.

<comment><USER35> The changes you mention are almost invisible in day to day life though, so there's nothing to recognise.

Perhaps those innovations which the tech community considers revolutionary didn't really change society in a recognisable way?

</comment></comment></comment></comment></comment></comment></comment><comment><USER36> A desire to recreate great things from the past always comes with some hindsight bias. What we'd like is a dataset about hundreds of labs like PARC and what happened to them. Of course, we could never get it, so we have to work with our observed history. But sometimes, in the case of these big labs, I wonder how much we can conclude.

I recently read The Idea Factory, about Bell Labs, and it has great insights, to be sure, but enough information about the causality to recreate Bell Labs? I don't know.

Maybe it really does come down to one thing, like funding, as the top comment (currently) on this thread suggests. But I doubt it.

When I was younger, my siblings and I played this game that we sort of made up as we went (too detailed to explain), and it was awesome. Years later, in a bout of nostalgia, we tried to recreate it and it was just awful. Enough small details had changed that it didn't work. One of the important details that changed was a total lack of spontaneity. All of us knew what the outcome _should_ be like, and it made us behave differently. I don't think big orgs are at all immune from this effect of expectations.

Don't get me wrong, I'm obsessed with the famous labs like anyone, a big fan of Alan Kay, etc. I just think somebody needs to call attention to a giant hurdle in learning from them.

<comment><USER26> There's another lab that was successful in a somewhat similar manner, a way larger scale, but still great results.

I recently bought a book on the Philips Natlab, same idea as Xerox PARC. They invented the optical drive (cd's), the wafersteppers that bootstrapped ASML, the company behind the machines that create chips and some other inventions that I can't find right now.

I have more details in the Natlab book which I have at home, if you're (or anyone else is..) interested.

</comment></comment><comment><USER37> >There was no software religion. Everyone made the languages and OSs and apps, etc that they felt would advance their research.

I feel like there is a lot of software religion in this industry today, however it is mostly perpetuated by mediocre developers.

<comment><USER38> Naturally that group does not include you or most of HN.

<comment><USER37> Me? I try not to. I don't like windows but I don't preach about it. C++, Java,C#, etc. I like em. I prefer Python. But I don't preach about it. Python 2 vs 3? Who freaking cares? Just get stuff done. But I don't preach about it.

I just go about getting my work done.

I think my only true religion is that I want open protocols. Chat, home automation, auto, etc. should all use open and documented protocols.

</comment></comment></comment><comment><USER39> > The commonsense idea that "computer people should not try to make their own > tools (because of the infinite Turing Tarpit that results)". The ARPA idea > was a second order notion: "if you can make your own tools, HW and SW, then > you must!"

All the best breakthroughs of my career have come from a build don't buy bias.

<comment><USER40> Got some examples to roughly outline? Am curious for encouraging anecdotes as a chronic (semi-willing) NIH syndrome "sufferer" in all areas I can hypothetically attack with just a laptop and a compiler..

</comment></comment><comment><USER41> I can vouch for the "fund people, not projects" aspect of ARPA funding in the early 70's.

I was a lowly undergrad but working with Tom Cheatham (who ran the grad Harvard Center for Research in Computing Technology) and others, and helping in minor ways with their annual ARPA proposal. ARPA pretty much was sending money our way, and we just had to cast the annual work in terms of what was "hot" at the time (mostly "program understanding" at Harvard) to get the funds.

</comment><comment><USER42> To like PARC you need the following things:

1\. A monopoly that prints money

2\. Company desire to investigate cool stuff

3\. No pressure to productize the research

4\. Smart people hired and given lots of leeway.

I think parts of Google, Microsoft,AT&T, and IBM are/have been like this.

</comment><comment><USER43> As mentioned by Alan right at the beginning of his answer, the true visionary behind our current technological age was Licklider. He was an ARPA researcher who, it is argued [1], initially dreamt up the connected network we now know as the internet. Interestingly, when an early iteration of the 'net was put to UCLA academics, they refused to get involved!

[1] Sharon Weinberger, The Imagineers of War (2017).

</comment><comment><USER44> YC HARC ([https://harc.ycr.org](https://harc.ycr.org)) has a lot of talented people working on PARC-like problems. Alan Kay has close contact with a lot of the team as well.

<comment><USER45> Having worked there, HARC is explicitly modeled after PARC (it's even there in the name) e.g. give a few visionaries a relatively small amount of funding and let them go. Even if nothing interesting happens your investment wasn't very large, but if anything interesting does come out of it then it might be as big as the personal computer and networking (so the theory goes).

</comment></comment><comment><USER46> Related to this special time in computing that Kay discusses is the book "What the Doormouse Said?" It's a good, relatively quick read about the rise of personal computing in the 1960's.

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

</comment><comment><USER47> i wonder why he (presumably) did not think "dealers of lightning" was a good book. not read "the dream machine" yet, but i thought "dealers of lightning" was a great look at the history of xerox parc.

<comment><USER48> Superb book, recommended reading for those managing engineering teams as you will learn a great deal about the culture at Xerox Parc, and what made it so successful (peer review was a huge part of it, or as they called it "beat the dealer"): [http://amzn.to/2nLvMFO](http://amzn.to/2nLvMFO)

<comment><USER47> recommended reading for engineers too; I found it very inspiring in a "makes you feel like building things" sense.

</comment></comment></comment><comment><USER49> It is special because it happened in a different era and its technological and cultural ideas are no longer legible. Time was computers were for mathematics, now they are Potemkin villages and vehicles for almost stunning cultural paranoia and new sectarian hatreds.

<comment><USER40> > vehicles for almost stunning cultural paranoia and new sectarian hatreds

Expound =)

</comment></comment><comment><USER50> Kay's own Viewpoints Research Institute is worth mentioning in this context. [http://www.vpri.org/](http://www.vpri.org/)

</comment><comment><USER51> Organization succeed when people understand and believe in WHY they do what they do and how.

PARC's mission was to "create the architecture of information" in a way that enabled strategic business growth.

In hind sight, it's obvious how important this was, but back then, it was just a belief, and one that turned out to be adopted in mass.

If you want to be like PARC, understand WHY you do what you do and how in a way that makes sense strategically for the organization, it's members, and those it impacts.

</comment><comment><USER52> I was working as my department's internal R&D director a couple years ago and I was interested in the first question as well. Note that that position probably sounds way more important than it actually was. Coincidentally, it was at one of the places Alan Kay mentions in an answer to the linked Quora question.

I pretty much focused on 3 different entities: DARPA, Xerox PARC, and Bell Labs. These are the books I read to try to answer that question:

[1] Dealers of Lightning. [https://www.amazon.com/Dealers-Lightning-Xerox- PARC-Computer...](https://www.amazon.com/Dealers-Lightning-Xerox-PARC- Computer/dp/0887309895) [2] The Department of Mad Scientists. [https://www.amazon.com/Department-Mad-Scientists-Remaking- Ar...](https://www.amazon.com/Department-Mad-Scientists-Remaking- Artificial/dp/0062000659) [3] The Idea Factory. [https://www.amazon.com/Idea- Factory-Great-American-Innovatio...](https://www.amazon.com/Idea-Factory- Great-American-Innovation/dp/0143122797)

I personally thought that having access to a diverse set of disciplines & skills and a reasonable budget were two of the more important things.

</comment><comment><USER53> Xerox was an immensely profitable business once. Being first to market with photocopiers, and keeping a large market share for a long time.

In the Palo Alto Research Center (PARC), they had the right team, the right ideas and research was absolutely going in the right direction.

For instance, they had former SRI International researchers that participated in the Douglas Engelbart's "oN-Line-System", presented in 1968 in what is now known as "the mother of all demos" ([https://www.youtube.com/watch?v=yJDv- zdhzMY](https://www.youtube.com/watch?v=yJDv-zdhzMY), [https://en.wikipedia.org/wiki/The_Mother_of_All_Demos](https://en.wikipedia.org/wiki/The_Mother_of_All_Demos)).

Their achievements include the creation of the excellent Xerox Alto computer system featuring a GUI and a mouse as input device, which inspired the Apple Macintosh and MS Windows (a story dramatized in multiple occasions, notably in the classic "Pirates of Silicon Valley").

Xerox leadership failed to visualize how innovations like the Alto could be converted into profitable products... even if it looks self-evident today. That's a once in a lifetime opportunity that they let go and as a result other companies heavily profited from PARC's findings and continue to do so today.

In addition, photocopiers are no longer at the center of business activities, and usage paper is decreasing. This makes Xerox a company of the past, like Kodak or Blockbuster (not trying to be offensive, but it is fair to say so).

</comment><comment><USER54> > _What made Xerox PARC special?_

All expenses paid, pure but pragmatic research without having to rush to market and add buzzwords and marketing-inspired crap. Oh, and no compartmentalization between teams and narrow-focused projects either.

> _Who else today is like them?_

Nobody. Google research labs for example is more like a "throw something out there as a marketing gimmick to show we do 'innovation', and see if it sticks" affair.

</comment><comment><USER55> It's probably not anywhere in america.

Szhenzen is pretty close to being the global center of hardware innovation and getting into software in a climate where state funding and commercial enterprise is merged in a way california havent seen since the rise of modern liberatarian economics in the 80ies.

The birthplace of the web at CERN is also still in play as a center where lots of things happens.

And thats before we head into the fringes where the oil exploration industry is leading in VR research almost as an afterthought of having to process and visualize the kind of big data most big data start ups only dreams about being able to handle.

Remember that Xerox wasn't an IT company but a printing/photocopier copier so it's just as reasonable to expect that the next big leap will come from someone that is not currently seen as an IT giant, as to go looking within the Californian IT industry.

<comment><USER56> The Shenzhen model is really nothing anywhere close to Xerox PARC. If any place gets close, I'd say it's Microsoft Research.

But even that has changed a lot in the last few years.

Disclaimer: I work there.

</comment></comment><comment><USER57> I'll say it: Microsoft. They have a lot of research stuff that never makes it onto (mass) products. It's atrange that Apple does not publish its internal research projects; maybe they are more focused on actual direct applicability, which is decidedly un-PARC like.

<comment> jon-wood I feel like Apple's culture is one of extreme secrecy even where its counterproductive or unnecessary. I once worked at an ad agency who did a lot of work with Apple and it was ridiculous. People working on banner ads for artists to be shown in iTunes had to go and sit in a windowless office behind a card lock. This wasn't highly secret stuff, this was stuff like "You can buy the new Coldplay album on iTunes".

</comment></comment><comment><USER58> They did great groundwork for Apple, they monetized on it while Xerox was left behind empty handed.

</comment><comment><USER59> There's a few, not quite the same, but bits of pieces of places like this exist. Monopoly driven companies like Google or Microsoft have nice R&D arms, car companies can get involved in weird things. There's the big research universities, who are these days just as commercial as PARC ever was. There's also DoE National Labs who, because of the downturn in the nuke business, get involved in all kinds of cool R&D and are surprising to most people only semi- government. And finally there's pure government R&D centers, mostly in the military.

<comment><USER60> Control F for national labs, and this is the only comment that came up. That makes me sad.

The DOE and NNSA national labs are enormous R&D institutions and have grown far beyond their original propose in the atomic weapons complex.[1]

I personally work for an office that pumps over 100 million annually into the system, and frankly that's small change. Probably about 40%-60% of that money goes into overhead and facilities which enables research outside of my project.

There are a lot of fair criticisms of the system, but most of that is because real R&D works like ycombinator. Lots of investment, with the hope that eventually something pays off in a huge way. Like the system or not, most people who are unhappy with it are really just unhappy about government sponsored R&D. Almost by definition, it's not going to be "efficient" in the short term.

If people are interested in big money, complex problem science, i encourage you to take a look at the labs. They cover everything from supercomputers, to marine science, to renewable energy.

[1] [https://energy.gov/about-national-labs](https://energy.gov/about- national-labs)

</comment></comment><comment><USER61> > Fund people not projects — the scientists find the problems not the funders. > So, for many reasons, you have to have the best researchers.

> Problem Finding — not just Problem Solving

Lessons not yet learned

</comment><comment><USER62> I've always wondered what enabled Xerox PARC to 'succeed' and Interval Research to languish. PARC was developed more or less organically where IR was an intentional construction. To me, that contrast is a proxy for other regions attempting to re-create Silicon Valley.

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

</comment><comment><USER63> I try to run the R&D side of my sports science business like Xerox PARC. I take a ton of inspiration from them.

</comment><comment><USER64> Different space, but after reading Alan Kay's answer, the only current entity that comes to mind is CERN.

</comment><comment><USER65> I'm not sure what places are like Xerox PARC now, but I want to create something like it again in the near future. Only for space-related ventures.

My uncle was on the original PARC team so I'll see if I can get an answer from him to answer the quora question.

</comment><comment><USER66> I remember thinking a lot about PARC when visiting biohacklabs. The feeling of random ideas implemented by people of various skills organically without clear goals. Lesser costs, new designs, new implementations.

</comment><comment><USER67> We are (playing the Wayne Gretzky game of invention).

</comment><comment><USER68> Zzz, suuwuuuojuuusujuuojoljllujluo ass wasàhhhhhl

</comment><comment><USER69> Bob Taylor made it that way.

</comment><comment><USER70> 1) Smart people who have great ideas

2) A business model that has no need of those ideas

3) Management who have absolutely no idea how to capitalise on those ideas outside of a core business?

...

That's Google. Google are Xerox.

<comment><USER71> Google is an ad company which makes products to put ads on

<comment><USER72> Like self-driving cars? I think they are desperately groping for something to diversify, because the ad models come and go, and the revenue can some day dry up.

<comment><USER73> Well, what are you going to watch while you're being driven around?

</comment></comment></comment></comment><comment><USER74> A blank check from the Feds in the hopes that giving money to smart people will make tgem develop something we could use to blow up the Russkies. That's what made Xerox PARC.

<comment><USER75> You mean DARPA. But DARPA was far from being a blank check. It was highly controlled, and based on projects not talent.

</comment></comment><comment><USER76> A similar organization today is DARPA.

You can submit proposals to them and they may fund you.

<comment><USER15> It isn't similar, either to PARC or to ARPA-IPTO (before the "D"). It was that "D" that caused PARC to happen, because of the qualitative change in what "Advances Research Projects" were supposed to mean.

</comment></comment><comment><USER34> Yeah people go on and on about how much 'amazing' stuff Google does or Microsoft does as if they just have a knack for picking the right people.

No, they have some good people and a huge amount of money gained from monopolies, which are by definition not legal.

<comment><USER77> > monopolies, which are by definition not legal

By exactly what definition?

Monopolies are not illegal. Abusing a monopoly is illegal in some cases.

<comment><USER34> If it's not illegal, it's not a monopoly.

Microsoft still has an illegal monopoly with Windows. There's no political will to deal with it, but it absolutely exists and has for years.

<comment><USER77> > If it's not illegal, it's not a monopoly.

Where are you getting this information from?

"The courts have interpreted this to mean that monopoly is not unlawful per se, but only if acquired through prohibited conduct."

[https://en.wikipedia.org/wiki/United_States_antitrust_law#Mo...](https://en.wikipedia.org/wiki/United_States_antitrust_law#Monopoly_and_power), which cites a 1945 court case United States v. Aluminum Corp. of America.

<comment><USER34> Why would American law be relevant?

<comment><USER77> You've mentioned two companies - Microsoft and Google. Both of these are American companies so they're subject to US competition law in at least their home markets. No other country would have the power to do anything fundamental about their monopoly such as breaking them up. They could only fine them, require them to support competitors, or lesser things like that.

If you want to talk about some other countries, a monopoly is also not illegal in the UK. Again, only abusing the monopoly may be considered illegal.

[https://www.gov.uk/cartels-price-fixing/overview](https://www.gov.uk/cartels- price-fixing/overview)

If you were thinking of a different country's law (which would be odd since you mentioned two US companies) can you name one where a monopoly is by definition illegal?

<comment><USER34> >You've mentioned two companies - Microsoft and Google. Both of these are American companies so they're subject to US competition law in at least their home markets. No other country would have the power to do anything fundamental about their monopoly such as breaking them up.

That's quite untrue. Any sovereign country can impose whatever restrictions they like on any company they like. That company can withdraw from that country, but in doing so they are giving up on all the income they could get from that country.

They might not be able to _force_ them to break up, but they can _certainly_ force them to either break up or fuck off.

>If you want to talk about some other countries, a monopoly is also not illegal in the UK. Again, only abusing the monopoly may be considered illegal.

You don't seem to understand. By definition, if it isn't abusive, it isn't a monopoly.

<comment><USER77> > You don't seem to understand. By definition, if it isn't abusive, it isn't a > monopoly.

That's not what you said originally. You said 'if it's not illegal, it's not a monopoly' I've shown that it at least is not true in the US and even referred you to a precedent which says that you can have a monopoly that is legal - 'monopoly is not unlawful per se'.

So if you weren't referring to the US, which country do you think your claim is true in?

<comment><USER34> I'm going to end this conversation before you get too confused

<comment><USER78> We've banned this account for repeatedly violating the site guidelines and ignoring our requests to stop.

<comment><USER75> Could you please undo that? I don't know this person, but all his arguments are worth discussing, his points are valid, and don't see any other site violation, than the monopoly discussion being of course only a side discussion of Google/Microsoft. I also don't see any request to stop. His last post on this was 19 hrs ago, you de-attached it 15 hrs ago, and then banned him 15 hrs ago.

Rob Taylor by himself explained how important it is to let discussions happen at PARC. They trained it. RIP

<comment><USER78> Even if that were true, it's like arguing a good hockey player shouldn't get penalties or ever be suspended.

Taylor did not foster a 'no-holds-barred' culture. Alan Kay has explained this many times, e.g. [https://news.ycombinator.com/item?id=14120241](https://news.ycombinator.com/item?id=14120241).

There were many violations and several warnings.</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment>