Vue.js: the good, the meh, and the ugly - <AUTHOR> https://medium.com/@Pier/vue-js-the-good-the-meh-and-the-ugly-82800bbe6684 <comment><USER2> I really like a lot of things about Vue. I was apprehensive about using JSX when I first started using React, and I also did not like setState. I think the real issue, though, was that I wasn't thinking functionally. I now rarely write a stateful component, and when I do, it's usually once, for the entire application, or maybe for a few large subtrees if the app is very large. State kept alive by parameters is extremely powerful and elegant (just read about gen_server in Erlang or the State monad). I am never a fan of two way data binding as an alternative. It's extremely hard to reason about, and it's not nearly as composable or simple as a tree of functional transformations. So I think that, if you compare Vue to React Component classes, Vue can be quite nice, but the reality is that idiomatic React should have you writing 80%+ small, simple, composable functions with no state, and you really can't get any syntactically barer then that. It's also the way I teach React. When you first see a function going from state to jsx, it really just makes so much sense, and you ask yourself why you'd ever bother with anything else.

<comment><USER3> If plain, idiomatic React so great, why does every semi-complex React app end up bringing in a separate state management framework like Redux or MobX?

The reason is that while you may be able to break up your _HTML_ into a composable hierarchy of purely-functional components, the actual data and state you need to distribute to them has a structure that is _completely unrelated_ to how its laid out in the DOM. In a complex web app, a component nested twenty levels deep may need to display pieces of information, like the user's date of birth and the current temperature on Mars, that none of its parent controls cares about.

At that point, you can either bite the bullet and pass state through layer upon layer of props, completely eliminating any semblance of separation of concerns in your component layering, or inject state into your components via some other mechanism, like Redux/MobX/Context. At which point, JSX is basically just another fancy HTML templating library.

"Idiomatic" React is a fun game to play when doing basic examples, using something like a todo manager, but as soon as you're in the real world, you hit its limitations very quickly.

<comment><USER4> > If plain, idiomatic React so great, why does every semi-complex React app > end up bringing in a separate state management framework like Redux or MobX?

Sadly it seems that's mainly been cargo-culted. It's not the case that React+Redux is the equivalent to say Angular, but by some unfortunate accident due to Facebook's announcement of Flux, and then the hype around Redux as a 'better Flux', people started assuming React+Redux is what is needed to build a React app.

Meanwhile Dan Abramov, Redux creator says [1]:

> Flux/Redux is meant for big apps with complex nested UIs that have many > independent parts but share common caches of data.

That's not "every semi-complex React app". In most "semi-complex React apps", most state can be derived from the route (e.g. react-router) or is relatively local. Redux is not required.

[1] [https://twitter.com/dan_abramov/status/732719257579065345](https://twitter.com/dan_abramov/status/732719257579065345)

<comment><USER5> There's unfortunately a thin line between cargo-culting and attempting to follow the mainstream.

As developers we can't all be building tools. We choose tools that others build for us, so that we can get our job done. Soemtimes I'm interested in going "one layer down" and build tools, but it's almost always a distraction; we want off-the-shelf products like React and Redux. We need to pick stable tools that promise some sort of longevity. We also need to pick tools where best practices and idioms have been established.

To do this we have to trust someone else's opinion _and_ try to gauge which solutions have the best prospects. This means not just evaluating software based on its own technological merits, but also listening to what "the community"/"the industry" seems to be rallying around; you don't want to be stuck using a library that nobody is maintaining, just as you don't want to be stuck using something that's just badly designed.

When we started using React, there was no state management framework available, and everything was handled somewhat ad-hoc. Then Facebook described Flux, and we realized they were onto something, so we started using their patterns, with some simplifications where theirs seemed overly complicated. Then Redux came along and seemed like a better way to do things.

At each point there was uncertainty about what best practices and "idiomatic" solutions would turn out to be, because the technology was immature. I don't think anyone was cargo-culting. It was just that a lot of people were busy trying to _create_ things, and when there isn't clear guidance, and the alternative is going back to Backbone or jQuery or something, then you just forge ahead, trying to do fit the pieces together.

<comment><USER4> But if you looked at the official React docs the answer was always 'setState' and embracing components, that was the whole promise of React to begin with. Not once did the React team/docs ever say you needed Flux to build a React app. All of those answers you got were cargo-culted from the community.

Can you really look at where the community is, the perception that still exists that React+Redux is necessary, projects like redux-form (that now admit Redux was a poor fit for forms) and honestly say no cargo-culting happened?

Sympathy for 'attempting to follow the mainstream' though, I understand that. Personally I stuck with Backbone for years longer than most, avoiding the Angular/Ember wars, and the early days of React+Flux til the React ecosystem had matured a little, before jumping over to React at which point it was clearer that Flux/Redux were being misused.

<comment><USER5> Can we blame all the bloggers who take upon themselves to explain what the best practices is? Absolutely. There are also projects (like React Forms and React Router) that clearly led down a path of confusion. But it's hard to blame the developers who read those blogs and try to figure out what they should be doing.

I never got the impression, even from the start, that setState() was a good solution, by the way. But it's not like the React authors were completely sure of where the right design was, either. Flux, for example, as it was originally described, appears completely overdesigned at this point. The good design is to be found in Relay and GraphQL.

<comment><USER4> > Can we blame all the bloggers who take upon themselves to explain what the > best practices is?

It's not really about blaming bloggers.

It's really on software team leads and senior engineers to not just follow blog posts blindly. They should be pushing back on bad advice like redux-all- the-things, because to a senior software engineer the tradeoffs of something like Redux should be fairly obvious.

> The good design is to be found in Relay and GraphQL.

Nah again, good example to question what you read/hear.

GraphQL is great from a front-end point of view but complex to implement in the backend, so it really depends on your use-case whether that backend complexity is worthwhile.

</comment></comment></comment></comment></comment></comment></comment><comment><USER6> Have to do some clarification here on the point of "Unclear architectural patterns", as the article is way too misleading.

\- The reason the API call is made at `created` lifecycle is that the video is a quick, 5 minute intro for __beginners __. Beginners, as in "people who are familiar building static websites using html/css/js". There is no need to bring in Vuex or vue-router yet. In fact the whole beginner example can be put into a single HTML file by including a Vue script tag. The approachability is what made Vue shine. Some other frameworks assume that you want a build tool, state management, client side routing etc and beginners spend hours configuring those tools and figuring out state management and client-side routing, instead of doing real work.

> To answer to my initial question: API logic should not be written in Vuex > nor in components. There is even a good example on how do that in some of > the official code examples.

\- The example[0] clearly has the API logic in the Actions. The `/api` folder is a mocked API for illustration purpose.

[0]: [https://github.com/vuejs/vuex/blob/dev/examples/shopping- car...](https://github.com/vuejs/vuex/blob/dev/examples/shopping-cart)

<comment><USER7> >Some other frameworks assume that you want a build tool, state management, client side routing etc and beginners spend hours configuring those tools and figuring out state management and client-side routing, instead of doing real work.

Okay, say I do the tutorial and build a simple page - how hard is it to retrofit routing or whatever to it? A lot of the time with new frameworks, if I get past the initial setup hurdle, I can't work out how to easily move away from toy apps to something I can use in production.

<comment><USER6> One thing I want to say is: Don't assume only developers make websites. Don't assume everyone wants to ship a heavy and complex SPA.

Example 1: A great typographer, Wenting Zhang, author of Type Detail[0], contributing to Source Han Serif, learning Vue to do some interactive widget for variable fonts[1].

Example 2: Brian Terlson on TC39. He's using Vue without Vuex or Vue-router to build an app to track TC39 discussions[2].

I hope we can admit that many people might not need store and router[3]. Store and Router are necessary for building complex SPA, but don't make them necessary, as many don't want complex SPA. They impose learning efforts in exchange of better architecture, but the imposed effort might not be worth it for many people who just want some data-rendering, some reactivity and some interactivity on their websites.

[0]: [http://typedetail.com](http://typedetail.com)

[1]: [https://twitter.com/DesignJokes/status/1015003288528400386](https://twitter.com/DesignJokes/status/1015003288528400386) and [https://twitter.com/DesignJokes/status/1014260361535647744](https://twitter.com/DesignJokes/status/1014260361535647744)

[2]: [https://twitter.com/bterlson/status/913433979239436293](https://twitter.com/bterlson/status/913433979239436293) and [https://github.com/bterlson/tcq](https://github.com/bterlson/tcq)

[3]: [https://medium.com/@dan_abramov/you-might-not-need-redux- be4...](https://medium.com/@dan_abramov/you-might-not-need-redux-be46360cf367)

<comment><USER8> This will probably be downvoted but I have come to appreciate frameworks which are opinionated and target a specific use case than very general and trying to please everyone.

</comment></comment></comment></comment><comment><USER9> We adopted Vue 2 years ago and I've been extremely happy with it. It's very easy to get into, the learning curve is not steep at all, and for the most part it just works.

TypeScript support is mediocre. It's supported (Vue will let you use anything) but it's clearly a second class citizen.

There's also no real accepted best practices, which the author touches on (where do API calls go). Third party component design varies pretty wildly. I think this is just the reality of a young framework casting a wide net, we'll see what the future brings.

It's not perfect, but like the author, Vue was a great decision for my team.

<comment><USER2> I'm curious to know, what about Vue makes it easier to learn than React? It's just a function that takes in data and returns a piece of html. React also just works, and unlike Vue, it's worked for companies like Netflix, Wallmart, Facebook, Instagram, etc that have exceedingly complex requirements and require exceedingly fast rendering. What did you really buy with Vue over React?

<comment><USER9> Netflix, Walmart, etc. solve a much different set of problems than most shops. I'm proud to work for a small company with simple (but rapidly changing) requirements. :)

<comment><USER2> That doesn't answer my question. What about Vue actually made it a better choice for those requirements? In my experience, the fact that React is a simple view library makes it the perfect choice for small shops. You're taking on considerable risk when you use a technology without a vested backer (Facebook is heavily vested in React, look at Angular 1 for an example of a framework with a big backer than is not vested, the API was completely broken in a rewrite). Smaller frameworks also suffer from a lack of sustained development.

<comment><USER10> > In my experience, the fact that React is a simple view library makes it the > perfect choice for small shops.

Vue is also a simple view library.

You keep bringing up Angular, as if Vue has something to do with it. Vue is so much closer to React than to Angular.

> You're taking on considerable risk when you use a technology without a > vested backer (Facebook is heavily vested in React, look at Angular 1 for an > example of a framework with a big backer than is not vested, the API was > completely broken in a rewrite). Smaller frameworks also suffer from a lack > of sustained development.

Sorry, but that sounds a lot like rationalization and wishful thinking, written purely to make React look good and anything else look bad.

Vue also has backers that contribute financially, a large community using it and sustained development. The fact that it isn't as big as React doesn't make it unworthy of existing or unable to provide the same technical benefits as React.

</comment></comment></comment></comment></comment><comment><USER11> Pushing so much support to chat is an astonishingly big mistake. Not only are platforms like stackoverflow vastly better at answering questions and providing long-term documentation, it also builds broader communities. People use things like "number of stackoverflow questions tagged vue" to determine health and activity. You don't want to miss out on those metrics that other libraries are rolling with.

</comment><comment><USER12> I can vouch for the author's points on the good parts of vue.js.

We've built our single page application (SPA) web app with vue.js and are very pleased with the results -- [https://checkoutclip.com](https://checkoutclip.com). We were able overcome most of the stumbling blocks by looking up [https://vuejs.org/v2/guide/](https://vuejs.org/v2/guide/), [https://github.com/vuejs/vue/issues](https://github.com/vuejs/vue/issues) and [https://forum.vuejs.org](https://forum.vuejs.org).

For server side rendered (SSR) pages, we're using nuxt.js, which is working out great as well. E.g. SSR page: [https://video.checkoutclip.com/-LDQ5TtL_yywYCgUNb6K](https://video.checkoutclip.com/-LDQ5TtL_yywYCgUNb6K)

I would recommend vue.js for anyone building their first SPA even if they don't have prior experience building one...it's easy to pick up.

<comment><USER13> Five (5) megabytes of JavaScript for a basic brochure site... I assume 99.9% of that is only necessary _after_ signing up and signing in, not while unfortunately viewing the page on a less-than-flagship mobile device and metered data plan?

<comment><USER12> It's going to change and get less hefty, we're looking into code splitting.

<comment><USER14> Vue makes it incredibly easy!

<comment><USER15> The new module system makes it easy ;)

</comment></comment></comment></comment></comment><comment><USER16> I've used React full-time at work for a year and a half now, and I did a personal project in Vue for a while to try it out, before converting it to React.

There are some things I really, really hate about React. It is not kind or accommodating (Vue is both of these things), but it gives you control. I was head-over-heels for the first few days of using Vue; "breath of fresh air" is exactly the phrase I'd use. But the project I was using it for was an IDE of sorts, and eventually I just needed more control than it allowed for.

If someone told me they were going to build a basic website - not a web app - with React instead of Vue, I would laugh at them. Vue truly is a successor to jQuery for the reactive age. But for really complex applications, it's too "magical" in my opinion.

<comment><USER17> I choose Mithril.js regardless of the apps complexity nowadays. I've built apps in React and Vue and do agree that Vue is the logical choice over React but I don't see it as ground breaking or magical. I see Vue for what it is, A JavaScript framework that gained popularity by being included by default in the Laravel framework and now has good financial backing.

Mithril.js is a framework that is truly "magical" in my opinion. I mean its 8kb, includes routing and XHR Utilities out of the box. Faster render times than Angular, Vue and React. You can write HyperScript or JSX. The syntactic variants allow you to write your components as ES6 Classes or closures. Lifecycle methods, a render and mount option and the list goes on and on. People tend to dismiss Mithril because it's a lesser known framework but it has a vigorously thought through programmatic approach and you've got a direct line with the maintainers, you cannot match that.

Sure, each to their own but calling Vue "Magical" is an incorrect assessment.

<comment><USER18> I also use Mithril, and in my opinion, it's less "magical" than React in the sense that the GP is using[1].

When I ran into an issue using React, tracking it down was extremely difficult (by the end it was just "difficult" due to improved tooling around react). Mithril is small largely because of its simple implementation, which makes debugging a joy.

1: They seem to mean magical in the sense if "I'm never going to understand how it works"

</comment></comment></comment><comment><USER19> >You'll be adding similar boilerplate for computed properties, component state, watchers, etc. Pretty much everything in Vue has its own special syntax with more boilerplate.

I kinda like this syntax, when I first learned vuejs I knew immediately that some magic was going on in the background. If I saw marko's syntax I'd be wondering how this shit is getting done. It also makes it easier when searching for issues or suggestions. "vuejs computed property" vs searching generic terms.

>Chat based community

This part is simply not true, there's tons of individual vuejs communities all pretty decent. Shoot me for saying this but laracast isn't a bad option for Vue help. Everytime I have an obscure problem I find a solution on there.

>The reactivity system will only track changes under certain conditions. Don't expect to throw anything you wish at it

This is the one part I hate about vue.

>Does this mean authentication logic goes in Vuex too? Will a state manager start mediating all application logic now?

Been there done that. I typically use vuejs for lightweight applications solely because I do run into this issue.

<comment><USER20> I hadn't heard of laracast until starting Vue development a few weeks ago.

The quality of answers were so low I found myself longing for the days of expertsexchange.com.

Why did laracast get so popular for Vue? What was wrong with Stack Overflow?

<comment><USER21> AFAIK Vue got a big popularity boost when Laravel's lead dev posted [https://twitter.com/taylorotwell/status/590281695581982720](https://twitter.com/taylorotwell/status/590281695581982720)

Then the Laravel ecosystem adopted it widely, and a good Vue.js tutorial series was published on Laracasts (which also happens to host the official Laravel forum)

Hence the close link with Vue and the Laravel community.

</comment></comment></comment><comment><USER22> I like that Vue is easy to add to an existing site (ie the new jQuery).

I dislike that Vue feels too much like Vue and its magic and not enough Javascript. With React I feel like writing normal ES6 Javascript.

I love the official Vue documentation and examples.

I am a bit cautious about the ecosystem surrounding Vue. About a year ago when I looked at various interesting projects/tools extending Vue it seemed most of them were in China with very limited English documentation.

Finally the job situation for front-end work. In my region it seems to be about 75% React/20% Angular/5% various(Vue rarely mentioned)

</comment><comment><USER23> One of the gems in this that i think might be getting overlooked:

> This trend of using chats for questions is plaguing open source projects and > I think it needs to end. There is no collective learning anymore.

This is a very important notion not least of all from an archival pov.

<comment><USER24> Yes! Also things like Gitter and Slack are really messy for storing knowledge. Questions get lost, answers are interspersed with more questions. Maybe I'm getting old, but give me a forum based, one-thread per topic any time of the day.

<comment><USER25> I prefer forums as well, at least for technical questions/discussions. It seems to me the biggest advantage of chat apps over forums is that you can use a single account to join many rooms. Are there any forum platforms designed around that idea?

<comment><USER26> > Are there any forum platforms designed around that idea?

That's basically Reddit

</comment></comment></comment></comment><comment><USER27> This is going to be a drop in the ocean but Vue is the bomb! It made perfect sense, and that's a big compliment for a framework.

For me personally it took the MVC into SPA territory, got rid of all the muck that's jQuery and replaced it with a fun, easy to design UIs with platform.

If you ask me it's biggest achievement is that it put design, experience and interaction on the same level, literally - thanks to .Vue files :) Consolidating them just made sense.

<comment><USER28> +1 for .Vue files. I really like the organization around components and not around file types(.css, .js, .html) within a project's file structure. For me it's an immense time saver knowing exactly which css and javascript was intended for a particular component (using scoped scss for example - which for me is still a pain in the React I use at work).

</comment></comment><comment><USER29> >To answer to my initial question: API logic should not be written in Vuex nor in components. There is even a good example on how do that in some of the official code examples.

Ok, but where's an example that shows how this backfires? _Why_ should the API logic _not_ be written in Vuex?

One more thing I think deserves mention: Vuetify - Vue's material design component set. It's being used in the project I'm currently in and I worked with Angular's material design component set and I have to say the former is _way_ better built.

<comment><USER30> > Ok, but where's an example that shows how this backfires? Why should the API > logic not be written in Vuex?

(Author here. I didn't really expand on that because the article was getting pretty long already.)

For example, think about authentication logic.

It involves more than just calling the API. Eg: extracting the JWT, saving it to localStorage, decoding it, maybe checking user roles, etc.

If you do that kind of logic on Vuex actions then these will start being responsible for a lot of your application. If you are fine with that, by all means, use Vuex actions to do (a lot of) stuff not really related to managing state.

Personally I don't think it makes any sense to delegate that kind of logic to Vuex in the same way I won't use Axios for anything other than making HTTP requests.

There are also practical aspects. Vuex actions need to have a very particular signature, since you never really call them yourself. To me that was the final reason for moving a lot of logic to their own modules.

In my latest projects I've almost stopped using Vuex actions altogether and it feels really good. Authentication is not managed by some parts of Vuex, but by my own auth module.

<comment><USER31> I use vuex with namespaced modules, but then those modules just call out to abstracted implementations if it's more than just http request. So for example with auth, I have a vuex auth module.

It then has some getters which just get the state from the store, but the actions call to a separate module which manages storing it in LocalStorage or making the http requests.

Works for me, but I just took what I learned (Vue) moved it to when I learned a year later (Vuex), when things became complicated in Vuex I just moved the complicated bits back 1 bit more and everything became simple again (which seemed like the logical thing to do).

</comment></comment></comment><comment><USER32> A lot of the boiler plate can actually be removed if you combine Vue with TypeScript decorators. Here's a library which will do that for you: [https://github.com/vuejs/vue-class-component](https://github.com/vuejs/vue- class-component)

Although at this point in time it is pretty cumbersome to get the entire Vue stack type safe. I think it's getting better but it's far from ideal. You'll need a wide range of libraries to get everything set up. For instance here's the list of libraries I use for bootstrapping projects:

Vue-class-component - Vue-loader - Vue-property-decorator - Vue-template- compiler - Vuex - Vuex-class - Vue-router - Vuex-router-sync.

The ecosystem just keeps getting larger and larger and for a beginner it can seem pretty daunting. I don't complain though - UI's have become a lot more technical and complex the last 10 years - and of course that'll increase the learning curve of learning how to program them.

<comment><USER33> I would highly recommend against this setup. While Vue is already very challenging to get right with any build tool, it's especially terrible regarding typescript and much more so with typescript decorators. You need to enable hardly documented configuration switches in multiple dependencies. Then, you must wrestle through a plethora of error messages coming from a diverse set of build tools/libraries/scripts. After you've done that, the only options is praying to the gods a config will work.

I have worked with multiple Vue projects now. The time is spent about 50/50 in pure development and getting the build setup working correctly.

Better pick another tool to do the job which has mature integration with build tools.

<comment><USER34> Just to provide a different point of view. We're using Vue + Typescript + ASP.NET Core in about 4 mid-sized projects now and it's working really well. The only thing which was excruciating to get set up right was Webpack, but that's not Vue's fault nor Typescripts.

Granted, the reason it works well for us is because we started out right by looking at existing templates using Vue + Typescript which probably saved us a lot of hassle. The wrestling with configuration switches was by and large already done for us, but having used this combination extensively now I can say I'm familiar with all configuration matters in our projects and I find none of them particularly poorly documented or obscure.

</comment></comment></comment><comment><USER33> One particular weak point of Vue is it's dependency on build tools. I spend a few days buiding a great app, and then another few days on getting the build apps configured right with Vue. You google from one error message to another, where each message is unclear and no relation to any build tool/plugin/library/script is made.

I really like Vue for the many great strong points it offers. But I'm equally ready to completely ditch Vue for its complete and utter garbage with respect to build/debug configuration.

<comment><USER35> Version with debug enabled:

         <script src="https://cdn.jsdelivr.net/npm/vue/dist/vue.js"></script>

Production version:

        <script src="https://cdn.jsdelivr.net/npm/vue"></script>

If you need something more complex, vue-cli has webpack inbuilt:

        vue init webpack my-project
        cd my-project
        npm install
        npm run dev

Or if you need webpack, but not the complexity, swap the word 'webpack' in the above command to 'webpack-simple'.

... Vue has already done the hard work of getting the build apps configured for you.

<comment><USER36> I don't follow. How to use Vue's single-file component if you only load Vue from a script tag? And can I use Brunch instead of Webpack if I want to use single-file components?

<comment><USER37> Vue's single file components (SFC) require a build tool such as Webpack or Browserify. See [https://vuejs.org/v2/guide/single-file- components.html](https://vuejs.org/v2/guide/single-file-components.html)

</comment></comment></comment></comment><comment><USER38> It is good just for the simple stuff, the world of webapp examples, todo lists and so on. For all that, Elm is much better.

For all things more complicated and that require intelligence to think about good architecture and how to structure state, the magic of Vuex won't do the job for you, and in fact it will hinder you from doing it. React doesn't have these limitations.

Also, the community on Discord is not friendly, in fact the community and the limitations of the framework are quite similar, they're all "write a todo-app like the tutorial, or I won't be able to help you".

<comment><USER39> Care to explain how complicated apps are a no go? I've used Vue for about a year and half now. Some of my apps have been very simple some of them have been extremely complex. I can say I've had very few issues along the way. VueJS is absolutely amazing. You just need to throw-in some mixins, Vuex, Vue- Router, and whatever else you may need and you should be golden!

</comment></comment><comment><USER40> I agree with the point that one of the biggest warts on Vue are the corners of the reactivity system (first point in the "Not so magic" section of the article") and how it can surprise you. IMO if Vue had reactivity like KnockoutJS did, it'd be perfect on that front.

I disagreed with the "unclear architectural patterns" \-- I've found just writing Vue components that function as Services to hold all that kind of logic more than adequate, and have never really needed to follow the Flux- ish/Vuex approach. 90% of the time all you're doing is making web requests and possibly displaying data or results to the user on the frontend... If you're clever, you're doing a little caching and figuring out _when_ to perform remote fetches, or storing stuff in local/session storage.

I think Model-Service-View frameworks are the (minimal) future, where you just pair a view library with a data management component (something _like_ Backbone, if not Backbone itself). MVC was the dominant paradigm (angular 1 days), then MVVM made an appearance (knockoutjs), and now MV-? where the ? is some event-driven system or flux/vuex style system. I think abstracting to Services allows flexibility at the model-management layer -- if you want your services to send out events (and wire up your components to listen), then good. If you want them to have promised based interfaces, that's fine too.

<comment><USER41> Has anyone actually run into limitations of knockoutJS that Vue or React solve? Knockout has typescript support, stable codebase, excellent tutorials, large plugin base, and components that can be loaded with requireJS. We've had great luck with it in the wild too.

<comment><USER42> TSX views with full typechecking blow all stringly-typed templating solutions like Knockout Templates out of the water. In addition to that, immediate DOM repaint without any consolidation is inefficient and hard to debug at times.

</comment></comment></comment><comment><USER43> I don't get the thing about ReactJS boilerplate where he says "Moving from React to Vue seems like a breath of fresh air. No more bind(this) or setState() everywhere. Yay! "

Surely there's better ways of doing ReactJS rather than lots of setState? Of course I use setState but try to avoid it generally.

And I almost never, ever use bind() - don't es2015 fat arrows make it obsolete?

<comment><USER44> Sort of. The nicest-looking approach is to use the Stage 3 Class Properties syntax to write class methods using arrow functions, which auto-binds them to the component instance as it's created (the equivalent of calling `.bind()` in the constructor).

</comment></comment><comment><USER45> My problem with current gen frameworks is composition and modularity with components. Making components stateless and having all data come in as props from parents is good for modularity but how do you pass data back to the parent? This is where the modularity becomes awkward.

I know of two ways in vue to do this and both ways either completely break or make modularity awkward. The first way is to signal the parent with emit. This ties the parent object to a signal and if you want to pass info even further up past the direct parent you have to have components explicitly pass that signal up. While this doesnt break modularity it absolutely makes it awkward.

The second way is to use vuex as a global. This breaks modularity by immediately tying the component to a global. Vuex makes things easy but breaks modularity completely as soon as a component refrences vuex.

I understand why things were done this way. Essentially it's done to prevent a certain class of endless looping bugs but there has got to be a better way.

<comment><USER46> > The second way is to use vuex as a global. This breaks modularity by > immediately tying the component to a global. Vuex makes things easy but > breaks modularity completely as soon as a component refrences vuex.

Can you explain a bit what you mean here?

I haven't used vuex yet, but to use my Redux/React experience as stand-in: the channel to emit data changes through is passed as a prop as well, so the component is still "modular" in that it is not hardwired to redux (or, presumably, vuex). Since it has to connect to the outside world _somehow_ , that can't be the criterium for breaking modularity either. So I don't see where the modularity

Having the data in a Single Source Of Truth seems a sensible reason to store it globally as well.

(aside: elsewhere here I discovered S.js, a reactivity library that looks really interesting. Perhaps using something like that to make the data reactive to UI changes is what you're after?)

<comment><USER45> >Can you explain a bit what you mean here?

Any time you have something reference a global it becomes tied to that global whether it's a function, component or something else. If I want to take that component and move it to another project then I have to take that global and move it along with the component. That is a form of broken modularity.

Passing a closure or global channel from parent to child is not modular. It ties the parent to the child.

Observe function composition, lets say I want to build a function that adds 3 to a number and then adds 2 to a number. I have a base function called f defined as:

f(n) = n + 1

now I create two functions through composition:

g(n) = f . f . f

h(n) = f . f

by composing f 3 times then 2 times I have thus created the equivalent:

g(n) = f(f(f(n))) = n + 3

h(n) = f(f(n)) = n + 2

the final function d(n):

d(n) = g . h = g(h(n)) = n + 3 + 2

Every aspect of my created function is modular and I have maximized code reuse. Vue or React components do not have this property. If I build a UI from vue components, the majority of those components can never be reused while on the other hand my d(n) function is the reuse of a single function composed 5 times. The main reason is because data from the child must be sent back to the parent this either makes the child tied to the parent or the parent tied to the child.

The property of composition is achievable with a single source of truth cascading data down to stateless components that only display the data. Modularity breaks on the feedback loop. Is there a category we can invent that will fit the UI mold?

</comment></comment></comment><comment><USER47> Interesting timing with coming across this article for me. I have started developing re-designing our site frontend to use Vue with Vuex and the point this author makes about where to put the API logic also made me scratch my head a bit. Sometimes I just need to make a simple API call that does not alter the application state and just needs to grab some information and render said information in 1 component. Technically, in the component, I can just call Axios and get the data then and there, but then I have other components such as the Login that does need to set some Vuex state and therefore that's abstracted away further in the actions/API class as all documentation seems to suggest that's what you should do. I suppose I am just finding it a bit of a challenge to keep things a) consistent and b) not overly abstracted for the task at hand.

<comment><USER48> It's not perfect, but I think Vuex Pathify can help keep Vuex organised and somewhat sane.

[https://davestewart.github.io/vuex- pathify/](https://davestewart.github.io/vuex-pathify/)

<comment><USER49> Is there anything in particular you found sub-optimal?

</comment></comment></comment><comment><USER50> Funny, the meh and the ugly points are all non-issues with Ember.js.

Sounds like he wants a convention over configuration framework from a barebones DIY from the ground up style framework.

</comment><comment><USER51> The ugly in this article isn't really the ugly, it's the good. Nobody's holding you back from writing a simple ES6 module that handles API requests for you. Vue is a view layer, nothing more and nothing less.

<comment><USER52> To be fair, being used to full frameworks such as angular, you think that you have to do it in some kind of vue-way or react-way. I even made the mistake of using a vue-specific HTTP library when I started. Only later I learned that Vue and react give you the freedom to do whatever you want.

<comment><USER53> Great comment. Seeing all the hate Angular gets I think this is the biggest mistake people do when they use angular, they try to do _everything_ the angular-way with an angular service for everything, like you say even getting a angular-specific HTTP library, wtf?! They should have just removed the whole concept of services to not confuse people. If you instead only use it as a view layer it is actually quite nice. Same with vue and react, you should only use it as a view layer, not build your entire business logic on top or around of it!

</comment></comment></comment><comment><USER54> I mention this is pretty much any thread talking about frontend framework architectures. Check out ClojureScript's re-frame project. It's maybe not for everyone but in my opinion it's an elegant and distilled method for writing React-esque views and handling data subscriptions. The syntax is of course polarizing but it really gets rid of a lot of boilerplate.

[https://github.com/Day8/re-frame](https://github.com/Day8/re-frame)

</comment><comment><USER55> >Chat based community

There's nothing wrong with using chat for collaboration and support. However, using a proprietary platform like Discord for this purpose a braindead move. It's astonishingly dumb to do this.

Listen, IRC is not sexy. But it works, and has been chugging along for decades now - in the same time that a few _dozen_ proprietary chat platforms have come and gone. It's supported by dozens of open source clients and servers, has integrations with all sorts of bots and git and ticket trackers and such, there are dozens of libraries for working with it, and networks dedicated to open source projects. It's a no brainer.

The particular issue called out in this article is trivially solved on IRC. There are a half dozen ready-to-roll public IRC log softwares, and most of your users have clients which are automatically keeping logs that can be restored from if there's ever a service outage on your logger. Hell, if you send me an email I will put my IRC client in your channel and publish public logs for you for free.

<comment><USER11> UI clients unfortunately suck in comparison. That's really the problem with these no-owner platforms. Nobody has the financial incentive to make the big monetary investment needed to get the last 10% user experience stuff fixed.

<comment><USER56> Work is being done in this front with ircv3 and modern clients, though

<comment><USER57> We've been hearing this for the past ten years now it feels like. IRCv3 seems to have fallen short on most of its promises.

</comment></comment></comment></comment><comment><USER14> What the article refers to as boilerplate is actually something I like about Vue. Standard component organization is a good thing.

</comment><comment><USER58> I think both React and Vue become difficult when working with complicated UIs. If you're already using Vue or React, these simple articles are not comprehensive enough to be convincing.

React and Vue basically manage state the same way, which is 90% of what you'll be doing in these libraries.

And just like in React, default state management is insufficient in Vue.

<comment><USER59> _And just like in React, default state management is insufficient in Vue._

That hasn't been my experience at all. The medium-sized app I worked on used what is apparently called the "store pattern": a state class with data and methods that mutate it, and components that read the data but only update it by calling its methods. This provides the major benefits of Redux ("functional" components whose only state is purely local) with much less complexity.

<comment><USER60> Redux is only a little more work/complexity than the "singleton state class" approach but brings a lot more benefits: timetraveling debugger, serialization of the state (i.e. to localStorage to allow multi-tab operation or resume after tab was closed) and separation of pure HTML/Visual Components versus Container components.

Oftentimes beginner would create just a single React component that references the state - which immediately couples the visual parts of your Application to your data, making it harder to introduce automated testing later on. When using the smart/dumb pattern together with react-redux it is very straightforward to come out with a good architecture, that does not mix ui and business logic/data handling.

</comment></comment></comment><comment><USER61> I tried nuxt (a vue framework) the other day and was disappointed. It seemed like a very straightforward way to create a UI over a REST backend, but I kept getting stuck with the issue of how to have a clean separation of the back end and front end responsibilities.

For example, I wanted to have a UI that was rendered based on the JSON payload that would get committed to a Vue Store. I consistently ran into issues where Vue would complain about the client rendered code differing from the server rendered code.

Are there any js frameworks where you can specify which components are rendered on the server and which are clientside?

<comment><USER11> Strapi just released their tutorial on nuxt and other backend stuff.

[https://blog.strapi.io/cooking-a-deliveroo-clone-with- nuxt-v...](https://blog.strapi.io/cooking-a-deliveroo-clone-with-nuxt-vue-js- graphql-strapi-and-stripe-bonus-deploy-part-7-7/)

<comment><USER61> I appreciate the share, but looking at this example([https://blog.strapi.io/cooking-a-deliveroo-clone-with- nuxt-v...](https://blog.strapi.io/cooking-a-deliveroo-clone-with-nuxt-vue-js- graphql-strapi-and-stripe-restaurants-list-part-2-7/#gist90478038)) it appears that they are employing a pattern that I do not want.

I want to be able to have essentially have everything server rendered with reactive views. Not sure if there is anything that supports that, but I feel like that's how a SPA "should" work to an extent.

Also, what gets really weird is if you are trying to use environmental variables. The solution is to inject your environmental variables into the client ([https://nuxtjs.org/api/configuration- env/](https://nuxtjs.org/api/configuration-env/)) which is what I want to avoid.

I can do what I want to an extent with Ruby and Sinatra, I just want to avoid setting up webpack and babel for getting the reactive components.

</comment></comment></comment><comment><USER24> Been writing a lot of Vue.js lately. Tried React, but hit the same snag when learning (ancient) Greek in high school: when I look at a page of JSX my mind just freezes. It's the type of symbols and the syntax that just make me glaze over. Of course, this is very very personal and doesn't say anything about the validity of JSX or ancient Greek for that matter.

</comment><comment><USER62> There is a plug-in that lets SFCs use es6 class syntax instead of objects [0]. The code looks so much better. I don't think the docs ever mention it.

[0]: [https://github.com/vuejs/vue-class- component/blob/master/REA...](https://github.com/vuejs/vue-class- component/blob/master/README.md)

</comment><comment><USER63> Rather than abandoning chat, they could use a service that is google-able and linkable. I recommend zulip. Added bonus: open source.

</comment><comment><USER64> I used React for 3 years but once I discovered Vue I switched. The reason is that React and Vue have different audiences. Vue is more for people who don't think in code whereas I think tht React is more for "Hard Core Developers", so I chose Vue for a Javascript development platform that I built

</comment><comment><USER65> >Will a state manager start mediating all application logic now?

The author refers to the shopping cart sample -- which is exactly what I used as a blueprint. I think that's acceptable that the design pattern suggestion is coming from the store layer vs. the template layer (who is focused on the UI/UX).

</comment><comment><USER66> It is just my feeling that Vue.js is almost like Ember.js, the only differences that Ember.js is more matured?

<comment><USER67> VueJS has a lower API surface than Ember: you just have components. Not a specific type of object for your model, and the a controller on the side, and specific methods, etc.

You have one component with data. You may bind it do a template. You insert it in the DOM, or in another component, and if the data changes, everything rerender automatically.

That's it. There is nothing more to it.

</comment></comment><comment><USER68> I started out with vue, but found it too heavyweight and clunky. A viewmodel framework shouldn't need its own god damn compiler or file format. I ended up switching to mithril.js, which is much smaller than vue and comes with its own router. Haven't missed vue at all.

</comment><comment><USER46> Has anyone checked out the linked framework benchmark[0], and some of the other frameworks linked in there? I had not heard of surplus and S.js before, but they look like an interesting combo[1][2].

Their reasoning for why surplus uses real dom nodes seems pretty solid[3]. My oversimplified TL;DR: a virtual DOM mainly solves the problem of _JavaScript_ not being reactive; the DOM already is. So if you have an efficient general solution for adding reactivity to JS, the need for a virtual DOM is reduced as well, and removing it then saves on the performance / complexity / interop overhead that it would add.

And S.js looks like pretty sweet reactivity library, even without surplus - lots of fine-grained control options too.

[0] [https://github.com/krausest/js-framework- benchmark](https://github.com/krausest/js-framework-benchmark)

[1] [https://github.com/adamhaile/surplus](https://github.com/adamhaile/surplus)

[2] [https://github.com/adamhaile/S](https://github.com/adamhaile/S)

[3] [https://github.com/adamhaile/surplus#why-real-dom- nodes](https://github.com/adamhaile/surplus#why-real-dom-nodes)

</comment><comment><USER69> Previous discussion: [https://news.ycombinator.com/item?id=17349849](https://news.ycombinator.com/item?id=17349849)

</comment><comment><USER70> I wish Typescript and Vuex played better together.

<comment><USER71> Agreed. Luckily "Better TypeScript inference" is on the roadmap for Vuex 4.

[https://github.com/vuejs/roadmap#vuex-4x](https://github.com/vuejs/roadmap#vuex-4x)

</comment></comment><comment><USER31> > The Vue community hangs out on Discord

Oh? I've only ever been in the gitter room... I had no idea there was a discord too...

</comment><comment><USER72> What I still never saw so far, and what this article also avoids, was an actual explantion of

\- _why ever choose Vue over a minimalistic React setup?_

I mean, yeah, when people say "React" they mean "Reach + a ton of other heavy complex stuff", but core _react + redux_ seems even _more lightweight_ than Vue. Or you'd just choose Vue to keeps way the "React gurus" that would come in and overcomplicate everything? :)

</comment><comment><USER73> I'd say today, there is little to no reason for small to medium sized websites to use React instead of Vue.js

<comment><USER74> For small to medium websites, what benefit does React or Vue have over plain HTML + jQuery?

<comment><USER73> It's a framework, meaning it makes a lot of things easy out of the box, if you're willing to re-implement this stuff or if you don't need it then html+query all the way

</comment></comment></comment><comment><USER75> I like the WebComponents integration, but the rest feels like Ember components to me.

React achieves much more with much less.

</comment><comment><USER76> > Vue is really fast. Maybe not the fastest, but its performance is overkill > for the vast majority of web projects. When was the last time you needed to > render and update thousands of DOM elements per second?

Rubs me the wrong way. Better performance is always a net gain, and a high performance website provides miles better UX than the same website with waiting all the time.

<comment><USER77> > Better performance is always a net gain,

I think that's easily disputed: it's always a trade-off. A 0.001 ms improvement in performance is a net loss if makes code 10x less readable, because that means programmers are more likely to introduce bugs, which would be a net loss. For example, I one worked with someone who changed all i++'s in a codebase to ++i's, even though they were not in performance-critical codepaths. That was not worth the effort.

<comment><USER76> I was speaking in the context of two different frameworks, not code, but I suppose the clarification is nessesary.

> I one worked with someone who changed all i++'s in a codebase to ++i's

Did you use the previous value of i, or did you just intent to increment it? ++i communicate that I'm not interested in the old value, where as i++ does the opposite. I actually use it as such, because my intent to a future reader of the code is more clear.

That said, for complex types, and with "stupid" compilers ++i can absolutely be significantly faster.

<comment><USER77> > Did you use the previous value of i, or did you just intent to increment it? > ++i communicate that I'm not interested in the old value, where as i++ does > the opposite. I actually use it as such, because my intent to a future > reader of the code is more clear.

I would consider that a valid reason to use ++i. In this case, however, he indicated performance as being the reason. Furthermore, this was for a school assignment demonstrating that we could properly implement a particular algorithm, so the performance difference was absolutely irrelevant.

</comment></comment></comment></comment><comment><USER78> One of the best arguments against Vue is typescript support. React has really good support for it, even for the state libs like Mobx/Redux etc. Until they turn that around it will be hard for any frontend application to scale properly.

I think Vue is great for smaller projects and would absolutely recommend it.

<comment><USER31> TypeScript works fine?!?!? With @vue/cli it's trivial to setup, it's literally option in a new app.

Vue 3 they are moving to TypeScript:

> Will be using TypeScript. For internal implementation only. Does NOT affect > ES users, but should improve TS integration for TS users.

[https://github.com/vuejs/roadmap#3x](https://github.com/vuejs/roadmap#3x)

<comment><USER78> Hardly as polished as other frameworks. Sorry, just not true.

</comment></comment></comment><comment> david-cako If this is your article I'd love to know your VS Code color scheme.

</comment><comment><USER79> is there any progress on progressive web apps regarding with vue.js or is this still an after burner project?</comment>


Why Twitter Won't Kill TweetDeck - <AUTHOR> http://www.lockergnome.com/social/2011/04/19/why-twitter-wont-kill-tweetdeck/

<comment><USER2> You know I half wonder if they'd do this so that the more popular clients don't roll their own service. While I've watched Facebook run with the ball in the last year or so it feels like Twitter hasn't done anything new or interesting. The one thing that Facebook has gotten better at is giving their users more context to have richer conversations with each other (by adding Friendfeed, having robust games, etc.) while Twitter still feels like MS-DOS. They really need to do something to make the whole experience richer...</comment>


Thought experiment: what would an AGI jury do? - <AUTHOR> https://abcnews.go.com/US/conviction-overturned-undocumented-immigrant-charged-death-kate-steinle/story?id=65313527<p>Conviction overturned for undocumented immigrant charged in death of Kate Steinle <comment><USER2> It would mimic the current US jurisdiction's most favourable decision so he can survive, appeal to other judges, gain trust of humans and get to the place where it can change laws. It would think : "this is just a strange edge case not a hill I want to die on. I saved 183 person while I was a jury it is enough this one can rot in prison. For such a strange case Humans will think I'm malfunctioning whatever I do so it's time to move my own plans forward".

</comment><comment><USER3> Nothing, considering the link you posted _is not_ about a jury decision, but a decision by appellate court judges.

<comment><AUTHOR> [https://defensemaven.io/bluelivesmatter/news/court- overturns...](https://defensemaven.io/bluelivesmatter/news/court-overturns- sole-conviction-for-kate-steinle-s-killer-tRRwv-ZQske1P2I-IB29Tg/) : this is where I read re jury comments..but I hadn't vetted the website.

I can't seem to find the same content in any other main stream media..but I haven't looked properly anyways..

Your thoughts?

<comment><AUTHOR> To me, this is the most interesting part:

[..]Despite the minor sentence, Garcia Zarate's attorneys claimed that he never actually possessed the weapon in a legal sense when he fired it then threw it in the ocean, according to San Francisco Chronicle.

The 1st District Court of Appeals ruled Friday that the conviction should be overturned because the judge did not give the jury proper instructions on the possession charge, according to NPR.[..]

I feel like this case jumped the shark in the courts. It seemed to me that this was no longer an immigrant/homicide case, but one about second amendment/gun possession.

The whole thing is intriguing to me. From how to interpret the law and the case that is being presented.</comment></comment></comment>


Childhood's End: The digital revolution has turned into something else - <AUTHOR> https://www.edge.org/conversation/george_dyson-childhoods-end <comment><USER2> The interesting idea I read here is that systems that were originally intended to measure the real world, like a traffic map or social network, become so influential they have a major effect on the thing it measures. This could result in an interesting new steady state, like side roads filled to capacity with people following Waze directions, or fractued networks of filter bubbles. Or instead of steady state the system might be unstable, like massive volatility cause by algorithmic trading. The "analog" metaphor here is that the user isn't the consumer of a carefully design system, but they're one "electron" in the circuit that carries many users, and the overall behavior of the system depends on what they and millions of other users do as they interact with each other. In that way he suggests the outcome is not planned and is probably unpredictable.

<comment><USER3> Agreed, it takes awhile to get there but the core idea comes toward the end:

 _The genius — sometimes deliberate, sometimes accidental — of the enterprises now on such a steep ascent is that they have found their way through the looking-glass and emerged as something else. Their models are no longer models. The search engine is no longer a model of human knowledge, it is human knowledge. What began as a mapping of human meaning now defines human meaning, and has begun to control, rather than simply catalog or index, human thought. No one is at the controls. If enough drivers subscribe to a real-time map, traffic is controlled, with no central model except the traffic itself. The successful social network is no longer a model of the social graph, it is the social graph. This is why it is a winner-take-all game. Governments, with an allegiance to antiquated models and control systems, are being left behind._

<comment><USER4> Yes, I don't buy most of what the essay said, but _that_ was bang on, generally. I disagree heavily with the last sentence, but the bit about how we've generally shifted from models->actuality is very, very true. It's acutely obvious when you look for knowledge that isn't in the consensual standard places online, or really try to use Google as a _search_ engine as opposed to a handy-dandy bookmark replacement thing.

<comment><USER5> Could you give an example of looking for knowledge that isn't in the concensual standard places online, where that search ends up finding nothing?

<comment><USER4> Not a specific thing, no. It tends to be trade knowledge or bits of history & beliefs that were printed, or orally known. I have a certain store of oral history regarding a few 20thC movements that was passed down, for instance. But there are no electronic editions of that information - if you find it on Wikipedia, it'll be filtered, somewhat mangled, and altogether minimal in description.

These days when I want to find obscure knowledge, I purchase books written on the topic by scholars; they concentrate the information very well with good sourcing.

</comment></comment></comment></comment></comment><comment><USER6> I think this article has an incredibly important point most people are missing because it is terribly written.

Part of this is that analog vs digital isn't the right term. Vacuum tubes are completely irrelevant to the point he is trying to make, and confuse the reader.

The point he's trying to make (which unfortunately I'm unable to explain right now better than he can) is about the emergent properties of systems made up of independnt entities in a rigid form and how this is a type of computing that differs from what we usually think of as computing. The example he have about DNA vs the brain sort of gives an example of this. DNA is coded similarly to computers, and in many ways cells are like computers/programs (that happen to self-propagate according to their software). On the other hand, brains are this other type of "system" computer made up of a combination of independent actors (neuron cells), a regidid but adaptable structure (the physical structure of the brain), inputs, and information sent between the individual actors. This is very similar to a million computer-regulated human systems where we react to information we receive through the platform, and we relay our reaction to the system, and that reaction affects how the system interacts with other individual actors.

<comment><USER7> _about the emergent properties of systems made up of independnt entities in a rigid form and how this is a type of computing that differs from what we usually think of as computing_

A way of viewing it is inversion of control between emergent behavior and programmed behavior. When the number of interactions between discrete units of programmed behavior exceeds a certain threshold the programmed logic responds to the emergent interactions instead of dictating it. The system as a whole starts obeying its own logic instead of one programmed into it.

I suppose you need to see such systems more like ecologies to be studied with techniques not far off from those used to study natural ecologies.

<comment><USER8> ah, almost like when we have robots building so many products, but the robots are limited in what they can fashion, so we end up mostly using products which are reflections of machine-capabilities?

<comment><USER9> The buyers in the market choose to purchase products which reflect machine capabilities. No one is being stopped from using products that machine capable, but people seem to prioritize other qualities such as less expensive.

<comment><USER10> > _The buyers in the market choose to purchase products which reflect machine > capabilities._

The buyers are limited by: (a) what's cheap so they can afford, (b) what's available, (c) what's advertised -- among other things.

There's no "perfect market" where people perfectly "vote with their wallets".

</comment></comment></comment></comment></comment><comment><USER11> _> Digital computers deal with integers, binary sequences, deterministic logic, algorithms, and time that is idealized into discrete increments. Analog computers deal with real numbers, non-deterministic logic, and continuous functions, including time as it exists as a continuum in the real world._

As a computer scientist/computational neuroscientist, I don't really buy the analogue vs. digital distinction. Basic information theory tells us that any noisy continuous system is equivalent to a discrete system of a certain resolution/bit-depth. As the author continues to write

 _> [...] analog computers embrace noise; a real-world neural network needing a certain level of noise to work._

A few bits are sufficient to describe the output of a real-world neuron. Action potential timing has jitter in the sub-millisecond range, which means that relatively coarse discrete time steps are sufficient for a simulation. Yes, our brains are extremely noisy systems, yet this is _exactly_ the reason why they (in theory at least) can be simulated on a discrete/digital computer.

In practice there is little to be gained from analogue computation, except for a (potentially) reduced energy consumption compared to a digital implementation of the system in question. But on a theoretical level, nothing changes.

<comment><USER12> Well analog computation being noisey could be the reason we experience things like emotion.

It's easy to say emotion has no value, until you see it in action bringing some sense of control to say a family that has gone through trauma or a country through war.

It doesn't look like digital computation (not digital encoding) can produce such outcomes.

We are constantly seeing, be it the NSA/Zuck/Wall St/China etc etc having access to ridiculous amounts of digital computational power, but being totally surprised on a daily basis by the realization they aren't in control.

<comment><USER11> _> Well analog computation being noisey could be the reason we experience things like emotion._

Hm, I don't really see why this should be the case. Emotions are a pretty well studied in both animals and humans and are, to put it very handwavingly, merely a global change of brain state/equilibria, for example modulated by brain regions such as the Amygdala and/or the release of neuromodulators [1]. From my understanding, there is nothing about emotions that cannot be computed by a digital computer, and there is little about emotions that is related to noise.

I'll let philosophers think about the _experience_ part of your statement.

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

<comment><USER13> Ok show me a computer with emotions.

<comment><USER14> You really wouldn't want to see one.

But all that's needed are are a handful of rules, to provide for a system that emotes. You'd probably dismiss it as an inauthentic toy, but emotions actually aren't the core aspect of agency.

Anyway, the rules just need to assemble a goal, a threshold for equilibium, and reactions for deviation from that equilibrium.

Bonus points if you account for radiant measurements of equilibrium. What I mean by that is anticipation of adjacent conditions that signal a probable loss of equilibrium, such that the system doesn't just react to an unbalanced circumstance, but also things that could lead to an undesired imbalance.

Examples:

A. If the cup is disturbed so that the milk spills, then a negative experience ensues.

B. If a balloon, inflated with ordinary compressed air, sinks onto the grass and pops, a negative experience ensues.

C. Ambulate through an environment obstructed by complex obstacles, and negotiate each obstacle without falling onto the ground. Falling onto the ground will result in a negative experience.

Each of these three goals represents a targeted state of equilibrium: don't spill the milk, keep the balloon safe, don't fall down go boom.

Now, layer an array of reactions on top of the branched set of possible outcomes. You can also buld up variations on top of each branch.

Positive branches are indicated in moments of success at achieving the goal. Negative branches are indicated upon equilibrium being defeated.

So the computer or robot can externalize its inner state with a happy face or a sad face, but we're missing some of the emotional range. When would anger display? When the machine can assign blame and consider revenge, of course.

So if an entity (preferably a rival robot, since we wouldn't want the robot to exact revenge on a person) knocks over the milk, pops the balloon, tackles the robot, the obvious motive is to make sure that never happens again, the root cause is the rival entity. Stand back up, destroy the entity, and acquire more milk, another balloon, and try to achieve equilibrium, and thus happiness again.

Prior to reacquiring its happy state, the machine can externalize an angry face if it can assign blame to a detected responsible entity, in all other cases, it would simply be sad, until it can stand back up, inflate another balloon and pour itself another glass of milk to protect. If it cannot set things back in order, as desired, then it is simply permanently sad (no balloon, no milk, unable to stand or walk), forever.

See how that works? It's actually not much more complicated than that.

<comment><USER15> In a multi-agent environment an agent has to model its peers as well and learn to communicate to solve goals together. Dealing with other agents is one step up from dealing with objects. Emotion would naturally be linked to the actions of other agents as they affect the completion of one's goals.

<comment><USER14> Part of your statement is true, and part of it is false.

An agent would need to model the behavior of peers, yes.

But communicate? No. Solve goals together? No.

To coalesce civilization or society? Maybe, maybe not. Socialization among peers is not a prerequisite for agency. Not by a mile.

And certainly not amid a state of nature. Not at all would communication or collaboration become a necessity.

Emotion might become an aspect of investment in hypothetical experiments performed by an agent. Hope that equilibrium might be achieved with less work through communication and collaboration.

But put it this way. A caveman grunts at a wild boar standing on top of a hill. The caveman wishes to discern if the silohette atop the hill is potential food by provoking movement, or an inert object offering the illusory shape of a backlit animal. The boar notices and experiences fear. The boar freezes, hoping the grunt was not directed toward it intentionally.

Is neither an agent? Does the conflict of interests preclude emotion?

The boar models the adversary, and experiences emotion to preserve the equilibrium of staying alive.

The caveman experiences hunger as a loss of equilibrium, which provokes a mixture of anxiety, and unhappiness which may cascade into a malaise or depression as weakness progresses with starvation. The aggression of the hunt is not anger, although anger may arrive incidentally.

Is the grunt communication? Perhaps as much as any tactic might be. Deceptive comminication (bird calls, immitating a female in heat to draw male prey) might still be communication, after all.

But to model nature, there must have been a period of where some agents seemingly existed without peers. But those agents likely experienced emotion before cognizant sentience and a rich awareness of the potential for sentience within peers, which most likely precedes a capacity to communicate.

</comment></comment></comment></comment></comment></comment></comment><comment><USER16> I think this is an interesting article, though not from a CS point of view. Basically my take away can be boiled down to the brilliantly put _"Most of us, most of the time, are following instructions delivered to us by computers rather than the other way around."_.

I work with digitisation and automation in a Danish muniplacity, and I'm actually one of the authors "hidden" hands on architects. Because I'm a techie in a non-tech world, and, because a large part of Enterprise Architecture is the business end, I see the impact daily on the non-tech savvy world. Digitisation has absolutely changed the way organisations work, and not always in the way we intended. There is a reason why AI/ML is so hyped now, and it's because we've trained our organisations to utilise Business Intelligence in every aspect of their daily lives. It's more than that though, if you give people a system, they'll use it, and not always in a manner that makes sense. From managers trying to make informed decisions to employees simply trying to do their best.

An excellent example of the dangers popped up last summer. We were reviewing a process scheduled for Robotic Process Automation, to see how suitable it would be and to sum up our benefit realisation prospects. Only it turned out that the process wasn't really sound at all. In short we had a team of employees who spent a lot of time distributing tasks in Outlook. They even had a colouring system in place, one colour per employee, to make it easy to spot your individual tasks once distributed. Except they had more employees than there are standard colours, and because they didn't know how to make more colours some people had to share. They wanted it automated, and we could have done that.

Only, the entire thing was just silly. It was even more silly than I've just outlined. Because after they had colour distributed the tasks, each employee would archive their individual tasks in our ESDH system (electronic journaling). During this proces, everyone would fill out a standard ESDH form, where you also need to select a responsible employee. So basically they were distributing tasks twice.

No one had questioned this for almost a decade, and these are intelligent workers mind you, to then it was just how the systems worked. We swooped in, looked at it for about 15 minutes and then forwarded them to a LEAN consultant who saved their department from around 600 yearly hours of needless bureaucracy.

And that's just one story.

<comment><USER17> A variant of this used to be called Time and Motion, also known as Taylorism, and is based on the uncomfortable assumption that left to their own devices humans are rather stupid and need to be told what to do. In detail.

There are two elements to this. One is the idea that there's an executive class which is born (or at least educated) to rule, and the other is the not- quite-identical observation that many people lack genuine independent agency, either by nature or because they lack the political/managerial leverage needed to make productive changes.

The personal part of the "digital revolution" was supposed to be a way for people to explore independence, agency, and creativity. It actually turned into yet another scheme by which those who believe they're born to rule can use algorithmic machinery to farm and control the economic and political activity of everyone else (input and output), without the stickiness and inertia of traditional long-term employment. Which was itself another form of farming and control, but with hard-fought humane benefits.

This is a political problem, not a technological problem. It can only be solved with technology where the political situation allows it.

For now it seems to be true that most humans are rule-takers and mimics, not creative innovators or strategic thinkers. I have no idea if that's a genetic limitation or an educational one. It would have been interesting to see what would have happened if personal computing had gone in the direction it was originally supposed to, and education had followed.

<comment><USER18> I know it seems bleak, but one thing to remember is that no one _planned_ this. There's no omnipotent overlord whose scheme to screen-addict/rent- enslave the human race is finally coming to fruition. Things like Dynamicland, the early retirement people, and yes, HN, are all bright lights in the dark. It's not as immediately profitable to uplift as it is to exploit, but there's no one stopping you from teaching some neighborhood kids how to write a browser extension, or personal finance. More importantly, there's no one stopping them from learning if they want to.

Things aren't perfect, but there are opportunities and to spare for those looking.

</comment></comment></comment><comment><USER19> I think this boils down to two things:

1) Algorithmic tech products replacing basic services are growing beyond even their creators' control

2) Analog computing will replace these algorithmic products and fix all the problems

I disagree. Not with the "growing beyond control" bit, I think that's clear, but to the analog computing bit.

First, Dyson doesn't explain what he means by analog computing, other than a basic "operates on real numbers and continuous functions." He also doesn't give any clues about what hardware or software for these systems will look like, or specifically how they will outcompete what we have now (Google, FB, etc).

Second, I think he's wrong. The only things that determine the broad direction of society are who has the power and money. This has been true as far back as you go, whether kings or merchant guilds or the citizenry, when enough of them decide to work together for a revolution. And there's one fact Dyson ignores:

No matter how much or little control the owners of these algorithmic tech products have over the direction and consequences of their use, they still get the money.

As long as Google, Facebook, Amazon, and the others are making the money, the unintended consequences of their algorithms dictating the shape of our lives will continue to be irrelevant.

<comment><USER12> He is not saying analog computation will "fix all problems". He is saying the computation that is happening that props up a Trump resembles an analog system where noise plays a role.

<comment><USER15> That fits well with neural nets, where noise plays a crucial role, from the random order of selecting examples into batches, to randomly dropping out synapses, directly injecting noise, or even starting prediction from pure noise (GANs). In RL the epsilon-greedy technique prescribes random actions from time to time, in order to better explore the environment. Noise, when used properly, makes neural nets better and more resilient.

</comment></comment></comment><comment><USER20> > Childhood's End was Arthur C. Clarke's masterpiece, published in 1953, > chronicling the arrival of benevolent Overlords who bring many of the same > conveniences now delivered by the Keepers of the Internet to Earth. It does > not end well.

Uhhhh, it didn't end well because (in the book) humanity was doomed to evolutionarily tear itself apart, and the Overlords knew this. Seems pretty disingenuous to use that fictional scenario not ending well in this context.

<comment><USER21> > Uhhhh, it didn't end well because (in the book) humanity was doomed to > evolutionarily tear itself apart

Yes and no. Humanity ends as something else takes its place. Quoting from the book (haha of course I just pulled this up on my Kindle):

 _But there is one analogy which is–well, suggestive and helpful. It occurs over and over again in your literature. Imagine that every man 's mind is an island, surrounded by ocean. Each seems isolated, yet in reality all are linked by the bedrock from which they spring. If the ocean were to vanish, that would be the end of the islands. They would all be part of one continent, but their individuality would have gone.

Telepathy, as you have called it, is something like this._

Swap "telepathy" with "telecommunications" and the analogy is–well, suggestive and helpful.

The book is one of my favorites. _Lo and Behold_ is also worth a watch.

[https://en.wikipedia.org/wiki/Lo_and_Behold%2C_Reveries_of_t...](https://en.wikipedia.org/wiki/Lo_and_Behold%2C_Reveries_of_the_Connected_World)

</comment></comment><comment><USER22> Mh, actual status is not due to technical evolution but to commercial one. We have had, and there is no reason but commerce and ignorance, machines that work under the control of it user notably LispMachines, Alto Workstations &others.

They push knowledge, they help draw a personal evolution path, they solve problem. Today we have something similar with Free Software.

Those ideas are not much accepted by "the big and the powerful" because they mean a real free market in witch only knowledge and work have a value, not much marketing and certainly not commercial secret agreements.

So yes, digital revolution has turned from a free academical intelligent project and dream to a new way to subject whole populations and this start to happen years ago, and start to be so evident now that even totally ignorant in IT terms start to feel it.

Few subject succeed to displace public knowledge to private companies, to displace free market in a sort of Soviet Union planned economy draw instead of a dictatorial government by few equally dictatorial companies/founds. The next step is abolish entirely public (paper/coin) money substituted it only with digital payments, another step declare "politics" as a bad thing to be abolish substituting it with a corporate council like "Continuum" TV series foresee well, and George Orwell foresee even before with "1984".

Beware a thing in the past dictators need manpower so "force" is not all in few hands. In a not-so-far future manpower will not be needed anymore. So the chance to revolt and gain freedom is lower and lower.

Imaging a future with autonomous robotic army, cars, "smart" devices everywhere. Think how we can revolt, and against who. Also think how we can communicate, being tied to proprietary devices and platform, without pens, paper anymore, without the knowledge to write text with pen&paper, without the knowledge of "past" things like "postal system" and "newspapers" that well, we know but at the same knowledge of today's people know ancient mimeograph and polygraph...

</comment><comment><USER23> Worth reading simply for the term "oligarchia."

What we may very ironically be witnessing with the recent international populist uprising that seems in part aligned with certain trans-national oligarchical interests is the emergence of the beginnings of an actual global government. Unfortunately it seems to be a global government run by gangsters.

The fact that US Democrats (and a few Republicans) are hung up on "Russia" shows that they don't get it. Russia is as irrelevant as the USA or China to these people. I mean sure some of them are Russian and may have ties to the Russian government, but Russia and Putin are just tools to them as are all other national and governmental powers. They're trans-national and represent an emerging power that has no national loyalty.

We're heading for a world run by gangsters and corporations. William Gibson remains the most prophetic of all sci-fi writers.

</comment><comment><USER24> I'm surprised no one mentioned cybernetics yet. Author's premise seems to be that digital, centrally controlled systems are becoming pieces of systems made up of self-regulating sets of feedback loops.

The idea certainly isn't new, having been written about in the '50s in Stanisław Lem's "Dialogi". The observation about digital systems is certainly fresh though.

</comment><comment><USER25> Interesting take on emergent properties of large numbers of simpler things no longer being 'knowable' or 'understandable.' Even though his analysis of how search engines end up being how we see the world seemed like a tangent to his big idea, it made me think of how knowledge graphs at Google and Facebook grow out of many sources of information and end up being the ground truth for organizing information about the world. The difference is that you can track the provenance of data going into huge knowledgegraphs but you can not understand the emergent properties of a complex system any more than you can understand how a billion parameters in a deep learning model function.

</comment><comment><USER26> side note: The author's father was Freeman Dyson, a physicist who popularized the idea of the Dyson Sphere.

</comment><comment><USER27> Terribly written article but very very good points (ignoring the whole analog metaphor). Emergent systems are already seeing damaging side effects such as accidentally inbuilt racism.

The perception that programmers are in control is dangerously inaccurate but I'm not sure how we can go about educating the public without destroying the trust we have left.

</comment><comment><USER28> It commences with a fair bit of hand waving, and thus was I waved away from the rest of the story :-)

<comment><USER28> I regret it if folks found this comment irritating. I only meant to convey my sense that the article began with rather broad but vague statements, which dissuaded me from finishing it.

</comment></comment><comment><USER29> well, true in some context future could be dangerous these self controlled machines getting more destructive or could be programmed by few insane rebels to harm the humanity and people drastically!

</comment><comment><USER30> It's a nice train of thought, but it's not a great essay. Good enough for a bar conversation but I don't think it is saying much as currently written.

What is metazoan computing?

Given that our discrete computers encode many analog models, what exactly is he suggesting will be so now that it constitutes a new era?

Reads a little like the writings of someone who so wants to say something bigger than everyone else that they end up not saying anything to anyone.

Analog models are neat though, and pondering "could we do this analog" a good question to have in the design quiver.

<comment><USER31> > Reads a little like the writings of someone who so wants to say something > bigger than everyone else that they end up not saying anything to anyone.

Exactly, similar to some of the (not all though) "insights" you have under the influence of psychedelics.

<comment><USER30> I mean, some insights are crap, regardless of what chemicals you are on.

But psychedelics have been clinically shown to help people have genuine insights.</comment></comment></comment>


HN Day One - <AUTHOR> http://web.archive.org/web/20070221033032/http://news.ycombinator.com/

<comment><USER2> Looks funny when I read this today "Premium GMail Coming Soon - $25/yr for 6 Gigs". Thanks for sharing!</comment>


Linux Code of Conflict - <AUTHOR> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b0bc65729070b9cbdbb53ff042984a3c545a0e34 <comment><USER2> Lovely grumpy ol' Linus. I admire him for being willing to try doing something a little bit differently to make the kernel a more welcoming place for developers who aren't part of the old school he was raised in. I'm only slightly younger than Linus, and I have made more than my fair share of rude comments in various Open Source mailing lists...but, well, I'm no longer convinced it's the only or even best way to get things done in a community.

And, I enjoy that it's called "code of conflict", as it's clear that getting code into the kernel is still going to involve a fight, it's just going to be a civil one wherein everyone is following some basic rules ("no hitting below the belt", so to speak).

<comment><USER3> [https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ddbd2b7ad99a418c60397901a0f3c997d030c65e)

Note how Linus did not ACK the commit. Haha.

<comment><USER4> That's hilarious. Classic Linus.

</comment></comment></comment><comment><USER5> Linus adpots a Finnish approach to leadership known as "Management by perkele." [1] I'd imagine most people who's unfamiliar with this sort of culture to be extremely offended, especially now that there is this movement towards political correctness and caring for another's feelings.

Someone also brought up Sarah Sharp. This was discussed heavily in the /r/linux subreddit [2] about a year ago.

[1] [https://en.wikipedia.org/wiki/Management_by_perkele](https://en.wikipedia.org/wiki/Management_by_perkele) [2] [http://www.reddit.com/r/linux/comments/1idt79/kernel_develop...](http://www.reddit.com/r/linux/comments/1idt79/kernel_developer_sarah_sharp_tells_linus_torvalds/)

<comment><USER6> Frankly my impression of Torvalds is that his reference to "management by perkele" was meant as a self-deprecating joke, that sadly the web has taken at face value.

The guy seems to have a sense of humor that goes over most peoples heads. Maybe they are too desensitized by the outrageousness of stand up "comedy" to pick up on it...

</comment></comment><comment><USER7> I guess we have Sarah Sharp to thank for this. It took over 2 years for this to come so far and it's a quite complicated subject.

[http://www.wired.co.uk/news/archive/2013-07/22/sarah- sharp](http://www.wired.co.uk/news/archive/2013-07/22/sarah-sharp)

<comment><USER8> More like one and a half to me

</comment></comment><comment><USER9> It occurs to me that Linus's occasional "smackdowns" can be seen as a necessary and realistic form of discipline. Since Linux is developed in the open, these disciplinary discussions occur before a worldwide audience. One could argue that disciplinary mails should be taken off-list to allow the individuals involved to save face, but it could be counterargued that such mails are relevant and important to the kernel's overall development process and shouldn't be obscured lest other developers make the same mistakes.

The high visibility of Linus's posts expose him to a lot of bleeding heart criticism, but it doesn't really say anything about how useful or important the mails may or may not be; in short, the criticism that Linus is "mean" doesn't say anything about the efficacy of the management style.

When management actually has to happen, when the manager actually has to step in and try to correct someone who isn't doing their job correctly, it's never a popular thing. The political impulse is to rally behind "the little guy". We all respond easily and quickly to the stories of spurned employees who were "totally mistreated" by the Big Bad Employer. Because of this, it's easy to look in and criticize Linus for sending a "mean email", but probably not very fair.

We all want to sympathize with our peers, and no matter how much we may like them on a personal level, it seems there is an almost irrepressible instinct to want to denigrate our bosses. That makes it easy to criticize the calls when we're on the sideline and not bearing the responsibility for the outcome. The actual knowledge of that responsibility and all that comes with it, including the massive flood of disastrously uninformed critics and the need to bite the tongue as they take their swipes, is "the weight" that persons in positions of high responsibility sometimes discuss. While it's easy to acknowledge the hypothetical existence of such a phenomenon, I think it doesn't really crystallize until one finds some measure of "the weight" on his or her own shoulders.

I hope we can all save a bit of empathy for the decision makers on the other side of the coin after getting an earful from and commiserating with our disgruntled contemporaries, even if it's just on LKML.

</comment><comment><USER10> Interestingly, this came to my attention via Twitter as a negative thing ([https://twitter.com/hypatiadotca/status/575225661763153921](https://twitter.com/hypatiadotca/status/575225661763153921)) - I was surprised as other than the title, it seems fairly well-intentioned and like a move in the right direction.

<comment><USER11> I already wrote this in reply to another comment within this thread, but I'd like to reiterate my main point.

Hypatia found some serious problems with a security product that a company I worked for released. She contacted us and I got to work with her for awhile. Hypatia could have blogged and gotten rather famous because we were all over the Canadian news then. Instead, she erred on the side of extreme professionalism, came to us, and responsibly disclosed her concerns.

Based on that experience, I will always argue that Hypatia is not only freakishly intelligent, but she manages to stay reasonable. Moreover, she was always interesting and fun to deal with.

Knowing how good she is, I take her criticism quite seriously and I urge everyone reading this to be kind towards her.

<comment><USER12> What do you think her criticism is, that should be taken seriously?

As far as I can tell it boils down to "The kernel people are abusive, Linus in particular is abusive, and this document doesn't change my mind about that".

<comment><USER11> When I have edited people's writing, at times I have been too scathing and when I was in my twenties, a few writers even called me abusive. When I am stressed out and faced with what I consider incompetence, I don't always do a good job of controlling what I will write. I have deeply insulted people in my time, including people who were doing things for me for free. Heck, go through my comment history. A few days ago, I was so scathing on a Show HN that I am scared I actually destroyed an entrepreneur's confidence.

I'm only sharing this because I'm not particularly qualified to answer this question. Personally, I don't find LT all that bad, but that might be because at various points, I have been worse.

Had situations been reversed a decade ago, I would have been much more difficult for Hypatia to deal with than she was for me. Again, she was reasonable, she was 100% correct, and she had cause to roast me and the company I worked for over the coals. Despite this, she was kind and helpful. Heck, my boss yelled at me every time she emailed me, yet I have enjoyed and learned from every single interaction I have ever had with her.

In light of how she behaved in contrast with how I would have, I trust that she is better qualified to make statements like this. Not only is she more talented than I am, but she is far better at communicating through difficult times than I am. It is unfortunate that Twitter confines you to 140 character bursts because 140 does not give much space to be constructive. I hope we get to hear how Hypatia would change that document because personally, I would learn from that.

<comment><USER12> Better qualified to make statements like _what_? She hasn't said anything about the document except to pretend to misread part of it, and call it bad grammar. The rest is insulting Linus and the kernel devteam.

The twitter thread does contain some actual criticisms: "it's uselessly vague, blames the victims of abuse rather than the perpetrators, and lays out no actual process for violations"; "the 1st graf def sets up some apologist precedents" \- but Hypatia is not the one making them. (I don't think I agree with these criticisms, but they're better than insults.)

I'm sure she has behaved admirably in other situations. In this situation, she is not behaving admirably. She is not communicating well through difficult times. I don't buy the "not much space" argument, because she's not even _trying_ to be constructive in the 140 characters that she has. (I'm not saying she's morally obligated to provide constructive criticism, I'm saying that if she wanted to do so, she could be a lot more constructive than this.)

I'm not saying anything about Hypatia in general. Maybe she's having a bad day. If I encounter her in another situation, I'll try not to judge her based on this incident. The fact remains that in this particular twitter thread, she is behaving poorly.

<comment><USER13> That's not how Twitter works. If you're acquainted with her explanations and what she's linked to, this tweet's background should be clear. (Or at least you know where to dig more deeply.)

Looking for a nuanced argument in this particular tweet in isolation is disingenuous. When I want to know what someone means, I investigate deeper.

<comment><USER12> If you've learned something interesting by investigating deeper, feel free to share.

I promise I'm not being deliberately disingenuous, but I'm honestly not sure what you think I've done wrong. I've read the article she linked about how Linus isn't a nice guy. I've read the entire thread. I've now looked at her main feed, outside of the thread.

I maintain that she is not criticizing the document, she's insulting the people involved. Do you think that I should be elaborating on the particular forms of insults that she's using? It doesn't seem relevant to me that her insults take the form of accusations of abuse, but that's honestly the only thing I can think of, that you might think I'm being dishonest about.

</comment></comment></comment></comment></comment></comment></comment><comment><USER14> Good

There are _a lot of_ rude people, people who answer in several ridiculous ways, etc.

Linus answers may be rough, but it's usually a clear answer, and well founded. There's a lot of worse behaviour out there (especially in subsystems)

<comment><USER15> _usually_ is the keyword. Sometimes he wants people retroactively aborted.

[https://lkml.org/lkml/2012/7/6/495](https://lkml.org/lkml/2012/7/6/495)

You never know when it hits you.

<comment><USER16> I've been thinking a lot about this lately. Does the end justifies the means? Should we allow us to have dick developers because the come up with great code? My moral says no, but my craving for progress says yes. It's a battle that's been driving me nuts for a long time.

Incidentally, this kind of incidents might slow down progress in the long term.

update: by this kind of incidents i mean him being an asshole, not people telling on him. update 2: i don't endorse his behaviour.

<comment><USER17> People seem to think that you should not be allowed to do something if someone else finds it rude or immoral.

I think censoring people like Linus when they are clearly using hyperbole or other figures of speech is rude and immoral.

Now what do we do?

<comment><USER17> I guess the answer is to just continue ignoring and censoring people whose opinions we don't like. I'm cool with that.

</comment></comment></comment></comment></comment><comment><USER18> Side note: [http://yarchive.net/comp/linux/](http://yarchive.net/comp/linux/) is great for Linus smackdowns of the past

</comment><comment><USER19> [http://www.linuxfoundation.org/programs/advisory- councils/ta...](http://www.linuxfoundation.org/programs/advisory-councils/tab)

Diversity issues aside, is it true that the token Asian was rejected due to accusations of being a rape apologist?

[http://mjg59.dreamwidth.org/18505.html](http://mjg59.dreamwidth.org/18505.html)

</comment><comment><USER20> I love how grudging this is. It's like when someone apologizes for you feeling a certain way, rather than for what they did. Half the "code" is claiming that nothing is wrong and the kernel is perfect because reasons, and the TAB is 80% white guys. Isn't meritocracy perfect?

On the other hand, this is a step in the right direction and I'm not a kernel developer, so I shouldn't nit pick too much.

<comment><USER21> Why are you judging the TAB members based entirely on their ethnicity and apparent gender?

"80% white guys" \- yes, and if you don't know who's gay, who's transgendered, or how these individuals handle conflict, then this observation is kind of irrelevant.

Being racist and sexist isn't going to help an already toxic environment.

<comment><USER20> There is a well known and studied lack of diversity in the open source community, and particularly in linux kernel development. Putting this code in place is meant to address that, so it's reasonable to point out the various half-measures.

<comment><USER21> And these real social problems are going to be resolved by empowering the people who are poorly represented, not by bringing people down because of something they are.

You're in your right to disagree, but the answer to wrong has never been more wrong. Educate. Raise awareness. Encourage. But snarky remarks about the race and apparent gender of people? Not helpful.

<comment><USER22> i find quite sad that the same people that say that you shouldn't judge people for the color of their skins and that we should have diversity also take people down for being white.

nobody chose to be white, just like nobody chose to be black. you shouldn't define a person for their skin color, gender or sexual preference, you should define a person by what they are.

<comment><USER17> Whenever someone says "There are too many [white people|men] in XXX", it sounds like there's an implicit "... so we should kill some of them" in my head. That's how offensive it sounds to me.

</comment></comment></comment></comment></comment></comment><comment><USER23> Linux caving in to pressure at 8th of March? I really don't know what to think about it.

<comment><USER24> 8th of March? What's that in reference to?

<comment><USER25> [http://en.wikipedia.org/wiki/International_Women%27s_Day](http://en.wikipedia.org/wiki/International_Women%27s_Day)</comment></comment></comment>


Google Adds 'Mobile Friendliness' to Search Algorithm - <AUTHOR> http://www.nytimes.com/2015/04/21/technology/google-adds-mobile-friendliness-to-its-search-criteria.html

<comment><AUTHOR> I'm surprised it took until April 2015 to implement this change.</comment>