MVC is dead, it's time to MOVE on (2012) - <AUTHOR> http://cirw.in//blog/time-to-move-on.html <comment><USER2> Events are an anti-pattern in my opinion. They allow the ultimate flexibility, but in essence are worse than global variables. With events, it is very hard to reason about behavior. Objects respond to messages from "god" at arbitrary times in an untestable way.

Whenever I am tempted to use an event, I ask myself if there a way to solve this problem with delegation or data-binding or some other solution.

I fall into the event trap all the time, but when I come across an event-free solution like Angular/Ember or using delegates in Obj-C, I am immediately sold.

Any pattern that promotes events as first class ways to communicate are a recipe for hell. Every Backbone application I have seen is nothing but a messy event hub that mangles arbitrary DOM events with arbitrary Model events, and there is a metric shit ton of code that just re-invents data-binding and delegation.

<comment><USER3> Model change listeners are the anti-pattern, not events. Mouse and key events are essential complexity.

\--

MVVM: model change listeners on each state mutation: response to state mutation is immediate, never batch multiple listeners, requires dependency tracking (if the collection changed, then the count also changed). change listeners fire immediately and can trigger more change listeners. Lots of callbacks to keep track of and easy for things to get out of whack. (Backbone, Knockout, Knockback)

Angular ("MV-whatever"): state changes detected by dirty checking, but changes are immediate (digest loop), never needs dependency tracking. Digest loop runs until the state settles (no more change listeners fire) to ensure consistent views. Magic data binding.

Facebook React: state w/ dirty checking: state changes are always batched, views are a pure function, reconciliation step to merge desired view with existing view, no events or change listeners. Render process is a lot like a 3D game - draw the buffer, whack the buffer, loop. No magic. Facebook doesn't call it MVC but in my eyes it is.

\--

The more complex your view and state, the more events/mutations/callbacks, the more you need React.

<comment><USER2> You seem to know what you are talking about, but I just don't understand what you are saying. Can you explain the React thing a bit better?

> Mouse and key events are essential complexity.

I disagree, but probably not with what you mean here. Mouse and Key events are the first thing I want to abstract away, and are an example of the pitfalls of events. The majority of internet connected devices have neither a mouse nor keyboard. I don't want to care about key events or mouse movements, but rather user intent. "submit" and "change" describe user intent; I don't give a shit about clicks and keydowns, or blitting glyphs into an input box or moving the cursor on command-a. What does keydown mean when a Chinese person is swiping chinese characters?

I think of events as chemotherapy. It is one hell of a powerful tool, but should be avoided for most problems. If every problem looks like cancer, then your worldview is missing simpler and less powerful but better tools.

<comment><USER4> For anyone wondering how Chinese/Japanese/Korean input works interms of DOM events check out the W3C's working draft of the IME API [[http://www.w3.org/TR/2013/WD-ime- api-20130815/](http://www.w3.org/TR/2013/WD-ime-api-20130815/)]. Specifically the sequence diagram near the end of the page.

<comment><USER5> Technically speaking it's the Google proposal, Mozilla is working on a counter proposal at [https://wiki.mozilla.org/WebAPI/KeboardIME](https://wiki.mozilla.org/WebAPI/KeboardIME).

</comment></comment></comment></comment></comment><comment><USER6> _I 'm certainly not the first person to notice this, but the problem with MVC as given is that you end up stuffing too much code into your controllers, because you don't know where else to put it._

No, that's just with the bastardized version of MVC popularized by Rails et all, which treat the views as little more than templates.

In the original MVC papers from Smalltalk, the views did actually send messages updating the model:

       A view is attached to its model (or model part) and gets the data
      necessary for the presentation from the model by asking questions.
      It may also update the model by sending appropriate messages.
      All these questions and messages have to be in the terminology
      of the model, the view will therefore have to know the semantics
      of the attributes of the model it represents.

[http://heim.ifi.uio.no/~trygver/1979/mvc-2/1979-12-MVC.pdf](http://heim.ifi.uio.no/~trygver/1979/mvc-2/1979-12-MVC.pdf)

<comment><USER7> Rails didn't bastardize MVC, users of Rails bastardized MVC. Over the years we've seen the progressions of fat controllers to skinny controllers and fat models. Now, we're seeing the progression of using models only for responsibilities related to persisting the object. This leads to extracting additional domain logic into Presenters, Value, Service objects, etc.

Avdi Grimm has a great book about this called Objects on Rails[1] and Bryan Helmkamp from Code Climate has a good introductory blog post on it as well[2].

Rails implementation of MVC is perfectly fine. It's when people lean on MVC for everything without applying "classic" Object-Oriented design. That's when things become a mess.

1 - [http://objectsonrails.com/](http://objectsonrails.com/)

2 - [http://blog.codeclimate.com/blog/2012/10/17/7-ways-to- decomp...](http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose- fat-activerecord-models/)

<comment><USER8> As an aside on terminology, why do we use the terms "skinny" and "fat"? Shouldn't it be "short" and "tall" since code is represented vertically?

<comment><USER9> Because that's the title of this blog post: [http://weblog.jamisbuck.org/2006/10/18/skinny-controller- fat...](http://weblog.jamisbuck.org/2006/10/18/skinny-controller-fat-model)

The only times 'fat' and 'skinny' are mentioned in the title.

</comment></comment></comment></comment><comment><USER10> The author's idea of moving events into the name suggests a poor understanding of OOP in general (with messages/events being the basis of object oriented approach). Ok, maybe he is talking about some special implementation of events but there are a lot of GUI oriented MVC interpretations which use some special events/signals implementation without trying to put it in the name of the pattern/framework because events are a common part of GUI domain then it suggest a lack of experience.

Without the E in the MOVE we have just MOV.

Let's talk about Operations now. There are several MVC frameworks which use different names for the classes related to controllers (for example Commands). Some implementations let you compose them. They usually live inside controllers _package_. Do the authors of those implementations rename the C into somethings else? No!

There are some cases with different names (think MVP, MVVM) but they have a different form of relationship between the three parts of a pattern. Let's look at the MOVE's diagram. We actually have the original MVC diagram with a strange quirk: the controller (made from Operations) can directly affect the view. Now we have a problem. There are two places in this architecture where the view gets updated: the view can get events from the model and update itself (oh horror! it's active view!) or it can be directly updated by the Operation.

This doesn't solve anything but makes programs built with this architecture harder to reason about and debug.

There are two ways to fix it: 1\. remove direct changes on view from controller then we have just MVC 2\. stop sending events from model to view and send them to controller then we have MVP

In the end I don't see enough justification for calling it something new and using a special name for this particular pattern. Also this pattern is broken. Talking about the article itself, it's neither academic, nor pragmatic and looks like a blatant attempt at self promotion. It's a bullshit which puts words over meaning and misleads beginning programmers.

</comment><comment><USER11> Inner-platform effect in the land of nouns.

Most programming languages already have operations, you don't need to tack them on as objects, objects generally perform one of these operations when passed a message.

'events' are generally known as 'messages' and are again built into the language.

So now we're left with MV, we just need some sort of object that can send/receive messages from views and models. I think I'll call this object a controller.

<comment><USER12> I think you make a good point, but there seems to be more to the OP's events and operations than you suggest. The 'events' are implied to be broadcast versus 'messages' which are sent to a particular object (i.e. point-to-point) in languages that I know.

The OP is also suggesting a hierarchy of 'operations', with sub-operations communicating with the parent operations. I don't think this maps directly onto language features (again, in languages I'm aware of).

I'd be interested to hear which languages you had in mind, and some more detail on how you envisage the mapping to language features.

<comment><USER11> As for operations communicating this is generally known as a return value. Parent operations and sub operations is just cleverly disguised procedural programming.

It sounds like half procedural programming, half partial application.

'Events' sounds alot like [NSArray makeObjectsPerformSelector] / KVO/KVC / Multicast delegate.

Honestly, the more I think about it the more MOVE sounds like functional reactive programming.

<comment><USER12> Thanks, I haven't heard about multicast delegates before, and I need to learn more about FRP.

</comment></comment></comment></comment><comment><USER13> This is actually remarkably similar to Backbone.MarionetteJS, only, swap the O with C for Controller (but don't be fooled, even their docs say it's not the most fitting name).

For those interested in learning more about Marionette, Amy Palamountain made a fantastic presentation you can check out at her site: [http://amy.palamounta.in/2013/04/12/unsuck-your- backbone/](http://amy.palamounta.in/2013/04/12/unsuck-your-backbone/)

</comment><comment><USER14> I once presented Rails as an example of "MVC" in my software architecture class the the Prof. kind of ripped me apart saying either Rails it not MVC or I am misinformed.

After a lot of research I realized that the true MVC architecture is not something that Rails implement. In MVC the views are updated when models change without the controller in between. Something like YUI App framework is true MVC in that sense, but not Rails.

<comment><USER7> The original MVC was invented in the context of a fat client which were desktop-esque applications back in the day. In the context of the Web and HTTP (which is a stateless protocol) MVC had to be adapted to fit this context.

While your professor was right he's also a moron for being overly pedantic and ripping you apart.

<comment><USER15> He thought about it deeply and learned something, though, so +1 for the prof.

<comment><USER16> +1 for the _professor_?

<comment><USER15> Yeah- by 'kind of ripping' tn13 he made tn13 think hard about it. He made tn13 better.

</comment></comment></comment></comment></comment><comment><USER17> This is quite amusing, as it was one of the biggest complaints I had when coming to an RoR shop from a Java shop (please don't immediately take this to mean that I advocate Java over anything else).

In my Java shop, we used the service pattern. We had our views, our controllers, our models (which were simply meant to hold data), our services, and our data access objects. Services performed the business logic, and data access objects interacted with the database.

This pattern worked extremely well for every application we developed. Entering the RoR world, I quickly found that most developers forget about all the lessons we learned back when we used other languages, and are repeating the quick-and-dirty mistakes we already corrected.

</comment><comment><USER3> _" You have models, which are nice self-contained bits of state, views which are nice self-contained bits of UI, and controllers which are nice self- contained bits of...What?"_

Business logic

<comment><USER18> Amen. Except... the current trend I'm seeing/hearing is "nothing in controllers". There seems to be some hatred of controllers controlling anything.

<comment><USER19> One of the big ideas for me was that the controller is the least reusable, most application specific piece. With that in mind, keeping the bulk of the business logic and view logic in highly testable and reconfigurable models and views makes a lot of sense. I think of a controller as a mapping between model and view -- it takes internal state and pipes it to some views then takes external stimuli and pipes it to some models.

<comment><USER3> exactly, and the application specific-ness is what makes them hard or poorly understood. General DOM management libraries can't provide a controller. For one thing, it needs to interface with your backend.

</comment></comment></comment></comment><comment><USER20> I'm very pleased to see the GUI topic mentioned here. For all of those who seek a UI advise, I have a tip.

I have done a lot of pondering about GUIs since I began programming. I ended up in mantaining a 12 year old project, with more than 400 individual forms (that's for a single client, we've got 4 more). Damn, I was lucky.

The project really blew my mind! It crushed most of the assumptions which I made while reading articles or developing toy applications.

And here's the thing:

It uses most of the "bad practices", "anti-patterns", or however the internet calls today the "I was bitten once and didn't find the way out" thing, in it's codebase and still is ridiculously maintainable. With very much likelyhood it will survive another 12 years. Partly, because of the contract, but the point still holds. :)

So, my bold advice: just ignore all the naysayers and make up your own mind. Event's are bad? It they solve a problem giving another one or two in exchange, there most probably is another solution fixing those two too. And while the problems never end, at one time you end up with a framework that covers 90% of needs, correctly.

"Yeah, we can't notify the remote client about the update on the model, when it's in a form rollback phase and when it has at least one two-dimensionally time tracked attribute. It isn't possible, because it interferes with the data history stack. We should not have used events at the very beginning at all." Damn, that's a tough problem. Wait, what does your UI do !?

At the project I'm working on it took a lot of work and at least one PhD thesis to get it where it is today. I can't give out all details, but if anyone's interested, there are few open sourced parts. But You will find plenty of good libraries already.

I also made a simple JAVA Swing project on github using some of the gained knowledge. If anyone would find that interesting, just leave a comment.

I hope such good UI articles come up more often in the HN feed. And please, do write as much technical details as possible.

<comment><USER10> Is it satire?

<comment><USER20> No, it wasn't meant to be a satire.

</comment></comment></comment><comment><USER21> Previous discussion from when it was posted(Very active):

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

</comment><comment><USER22> A problem is that a lot of developers equate MVC with magical framework that does a lot for me and just happens to have folders named "models", "views", and "controllers" where they put stuff. This can be Rails, but is common in other frameworks as well (even if the names change)

I found working with a barebones MVC framework a bit enlightening. One is Framework One by Sean Corfield. It was originally written in ColdFusion, consisting of a single class (CF calls them "components") with very little magic. (it does do things like implicit views and queue up service/model calls with an event lifecycle, but in general, nothing happens that you don't have direct control over) He's also written a version for Clojure, though it's less mature

[https://github.com/framework-one/fw1](https://github.com/framework-one/fw1) [https://github.com/framework-one/fw1-clj](https://github.com/framework- one/fw1-clj)

</comment><comment><USER23> If you want a nice alternative to MVC (or event-based systems in general), take a look at functional reactive programming (FRP). Instead of modelling time implicitly using mutable state and callbacks, FRP provides time-varying values as first-class citizens. I've found FRP to create much neater code for most of the UI tasks I've worked with.

<comment><USER24> Thanks for that, made me finally go and look up FRP, finding this (again, I think):

[http://elm-lang.org/learn/What-is-FRP.elm](http://elm-lang.org/learn/What-is- FRP.elm)

It's a nice abstraction when(if) the alternative is to work with the DOM, javascript and browsers -- but the examples would be trivial in a smalltalk- like environment: The various labels would reference the mouse, and on redraw they'd use the current value. So I'm not sure it's so much an alternative to MVC as it is a fix for our broken environment (the browser+dom+i/o as a GUI system).

<comment><USER20> Bookmarked, thank You.

Mind sharing a bit about Your experiences? Are the initial investments cost high or low? Are there any drawbacks which inhibit any other functionality (what to do to avoid memory leaks)? Is the end-product really mantainable? Does compose easily?

I'm eager to learn :)

</comment></comment></comment><comment><USER25> whenever i read a headline like "X is dead" (whereby X is a technological concept or even a piece of technology) my first reaction is, that the author has probably a very limited understanding of the technology at hand (or about the underlying concepts of that technology)

       * vinyl records are dead, http://www.nytimes.com/2013/06/10/arts/music/vinyl-records-are-making-a-comeback.html?pagewanted=all
       * CDs are dead (yes, they are, optical data storage isn't)
       * flash is dead (but still, most videos are still streamed via flash and a gaming company i know prototypes all games in flash...)
       * SEO is dead
       * social media is dead
       * java is dead
       * progressive enhancement is dead
       * print is dead
       * native is dead
       * desktop is dead
       * ...
       * ...
       * mvc is dead

lets call it "Franz's law of deadliness"

</comment><comment><USER26> Talking about an architectural pattern without specifying its applicability or limitations or context is just completely wrong.

In architecture it's not optional to proceed as follows: 1\. describe a problem, 2\. describe a solution to the problem

They don't do that. This is a classic mistake: describing a solution and looking for a problem to solve. Don't do that!

Furthermore, MVC is used because it's widely applicable to a bunch of problems and contexts - with its pros and cons, clearly. It's actually a very rare thing for a pattern to have such a large sphere of applicability. So, no, you don't throw it away just like that. It doesn't make any sense. Sure, there are other patterns that work better in some very specific context. CQRS is an excellent pattern for building NoSQL databases for example. That doesn't mean it should be applied to any random problem!

<comment><USER27> I totally agree.

Also sometimes I feel engineers spend WAY too much time worrying about architecture of CRUD. I mean, MvC, non-MvC.. who cares? Adopt one and run with it. Then spend the rest of your time about crucial technical problems(ie semantic analysis, machine learning, spam detection, whatever)

</comment></comment><comment><USER28> I've been doing something similar to this with Backbone. Backbone has Models, Views, and Events. I put the "Operations" in the Model and Collection extended classes, so the login operation is performed by the User model. So I would call something like currentUser.login(credentials).

</comment><comment><USER29> I think there's an easy answer to the question of what the controller is - it's the business logic. My main problem with the MVC pattern is actually related to the model and view communicating directly. I started using the MVP pattern and then switched to passive view ([http://martinfowler.com/eaaDev/PassiveScreen.html](http://martinfowler.com/eaaDev/PassiveScreen.html)) to eliminate as much code (and therefore testing) as possible from the view.

<comment><USER30> No that's what the model is for. The controller is just for handling framework specific input. It takes the framework specific part, puts it in a form that the business logic can understand (eg: business logic shouldn't even know what a mouseEvent is), and hands it off to the model's business logic to handle.

</comment></comment><comment><USER31> You know what its time for ? To go back bit, beyond the patterns, read "A Pattern language" by Christopher Alexander. Understand why those patterns become the way they are, and build software that makes as much sense as real world buildings. Things that are much more costly than software to tinker with. Given how much complex shit is becoming today, imposing any fixed label on how we devs build things would become very restraining very quickly.

</comment><comment><USER32> Why is this new in 2012? The "event" component is generally implemented using the Observer/Listener pattern in Java and has been done like so for yonks. The most "modern" concept he alludes to in that section is the idea of everything being modelled as operations (and sub-operations) which is pretty much Command-Query-Responsibility-Segregation.

This obviously is not convenient in terms of web facing applications. Don't forget that web pages are intrinsically static which means your model has no way of pushing events to your view. Unless we (in 2013) are suddenly advocating that every site now should be using WebSockets (Just as bad as using PostBacks in ASP WebForms... unless you are writing a client-side application)? And lets not forget that each web application endpoint (HTTP_METHOD + URL) is in itself already an intent/operation described here -> GET = Give Me Information. POST = Mutate Information.

In any case, MVC isn't fully dead as it has evolved into MV(C)VM instead. Instead of the View getting the data from the Model, the Controller gives the required information to the View.

<comment><USER26> Maybe you mean "devolved". MVC is alive and kicking where I sit. Instead I constantly see the passing corpses of MVVM and CQRS projects... Honestly, not trolling - this is what I have seen for many years.

<comment><USER32> Well it depends on how people are using it I guess? ;) just because there are plenty of MVVM/cqrs projects that have failed doesn't mean that mvc is more successful... One could propose that devs are more familiar with the steward of traditional architecture?

Pretty much all iOS projects are MVVM - See UITableView. AngularJS is arguably MVVM: in this case the views are databound to the view model which is held by the controller, which is essentially the "Events" component.

Additional Edit: All MVC Java Swing apps could arguably be classified as MVVM -> all your JComponents are all... MVC! Which really leads me to think that MVVM is really just nested MVCs... perhaps =)

<comment><USER26> Well, the problem is that if you find Controllers badly defined in MVC, good luck in understanding how to use View Models properly. MVVM seems to me on many levels a re-hash of the old Document/View concept, which is... not so good, because of coupling. And in fact, Many MVVM codebases end up being tightly coupled - bear in mind, also many MVC projects, especially of the ActiveRecord sort.

My comment obviously relates to my experience, which is admittedly more webby than application-y.

I thought iOS was inherently MVC though (or at least, that's what they claim)

<comment><USER32> I'd argue that MVVM is a subset of MVC. So technically they're accurate.

And also, anything that is "badly done" becomes bad. I'm not really sure why it is hard to understand View Models... your controllers shouldn't define your view models. Your VIEWS determine what information is needed to render itself. Any templating engine that requires you to pass in a model (i.e. Handlebars, Jade etc.) is, in effect, MVVM. This makes your views more concise since it doesn't get access to a whole model when it isn't required. Its dependency is specifically only on the View Model itself.

</comment></comment></comment></comment></comment><comment><USER33> Actually that's what MVC is supposed to be. Whether you use events, callbacks, delegates, or dirty checking really doesn't matter. Views inform the controller, controller updates the model. Events and Operations are the Controller, but lets not shove MVC into some specific implementation based on events, it's an abstract pattern for software architecture, not a framework.

<comment><USER34> >Views inform the controller, controller updates the model

No, that's not how it is supposed to work. The idea that everything has to pass through a controller for no reason, and that we need a controller per view, is the rails bastardization, not actual MVC.

</comment></comment><comment><USER19> For those interested in this stuff, Apple has some really nice docs on their version of MVC: [https://developer.apple.com/library/ios/documentation/genera...](https://developer.apple.com/library/ios/documentation/general/conceptual/CocoaEncyclopedia/Model- View-Controller/Model-View- Controller.html#//apple_ref/doc/uid/TP40010810-CH14)

</comment><comment><USER35> Have definitely had an excellent experience using an experimental MVC setup in Kivy. Can't chip into any MVC death exclamations. First I should mention that Kivy uses data-binding liberally. It's not events, it's publisher-subscriber where bound functions receive the changes as their arguments. This fixes many things, but Kivy uses a widget tree. Trees are great for reasoning about context, scope, relationship etc between graphics elements in layouts.

Trees are also an awful topology when something has a relationship to an element in another branch. The controllers as I'm using them are globally visible and thus don't need to be passed. This would pollute namespaces except that a minimal number of controllers will recreate the topology of the problem space and not in tree-space. The whole application can see "out" of the 2D tree into a graph that connects things with many fewer connections. These few controllers have tons of logic, but it's all program. There's very little related to how widgets display themselves, so this fat code is also very high- calorie, rich or whatever.

Fat controllers make me happy. My program, the part that I think of as the program, exists all in one place and the bits that control how everything looks all belong in the tree. Widgets don't send events to my controllers often. Occasionally it's easier to reason through a problem using the property/data-binding system, but more often the data already exists in the on_press callback of the widget or whatever and there's no need to secondarily send it through more sub/pub plumbing when I can just call a function of my global controller on the data.

I'm busy getting my code cleaned up and contributed. It has really saved me untold time even in it's nascent stages because of the fundamental topology conveniences.

</comment><comment><USER36> I was never a fan of "strict" web MVC. It felt like you were jamming far too much into your models.

Take Symfony2's architecture, for example. Controllers, Entities, Repositories, Views, Services, Listeners, Events, etc. Each layer has its own distinct purpose that do something very specific by themselves, but when brought together form a very cohesive whole.

<comment><USER37> >Take Symfony2's architecture, for example. Controllers, Entities, Repositories, Views, Services, Listeners, Events, etc. Each layer has its own distinct purpose that do something very specific by themselves, but when brought together form a very cohesive whole.

But the end result is so very complex and the benefits gained are doubtful at best.

<comment><USER38> You obviously never worked with javaEE ... Symfony is a breeze compared to how the former works.

</comment></comment></comment><comment><USER39> Should be mentioned that this is from 2012.

</comment><comment><USER40> I like to think that its not model view controller, but instead model-view- behavior (or the strategy pattern)

Events are a given. Models can fire/handle events, views can fire/handle events. The behavior/strategy pattern is just a bunch of singleton objects that know how to mediate between the view and the model. Sometimes the behavior pattern handles events (as a strategy), but it doesn't fire events (only the model and view can do that).

The model knows how to generate the behavior. The View contains the behavior and asks the behavior questions with the model.

This separates responsibilities nicely in my opinion.

</comment><comment><USER41> "A common operation for applications is logging a user in. It's actually two sub-operations composed together: first get the email address and password from the user, second load the "user" model from the database and check whether the password matches."

Why do you need to have Operations when that code could be into the model? The view tells the model: login(username, password); and the model just do that and saves the state in it's model.

So there will be models that contains state and models that contains data...

Why add another layer?

</comment><comment><USER42> looking at the comments, few programmers even understand MVC yet. Maybe it's just a lack of understanding that causes people to think it's time to MOVE on...

</comment><comment><USER43> >O: Operations encapsulate everything that your application does. >E: Events are used to join all these components together safely.

So my controllers are just there to work with the repository/service layers. This is just the next logical step after straight MVC and is already a pretty well established pattern.

 _My understanding of MVC is the context of web development._

</comment><comment><USER44> Sounds like my reaction on Apple's version MVC: "Do I have to stuff ALL of this stuff into a Controller???". But if I use something like LESS with a ORM or Microsoft MVC with EF and nice IOC and builder patterns all of a sudden the controller does nothing else but evaluating the request and giving the right kind of response.

<comment><USER45> Indeed. Even if you are not using an ORM, controller functions should be short. Functions are just not supposed to be 30+ lines.

If my controller function isn't less than 20 lines of code I look over it and figure out what code can be placed in a library or a model or a view. The controller function should do very little.

</comment></comment><comment><USER46> Can someone provide a basic introduction to the concept of MVC, for a beginner?

<comment><USER47> Basically, you have your program in three parts. Model, view, and controller. The model is the meat of everything. It knows the system, it interacts with other programs, it determines everything. The view is what gets shown to the user. The controller is what the user interacts with. Both the view and the controller should be as minimal as possible, only serving to relay information between the model and the user.

<comment><USER24> And one place that is easy to trip up, is that you'll probably want to model your data, eg do normalization. That is your applications data model. But that is _not the same_ as the model in MVC.

The "MVC-model" of a bank account is an account number with a balance attached: the _data model_ of an account is a series of credit/debit transactions that can be summed up to a current balance.

</comment></comment></comment><comment><USER48> Blindly picking a design pattern before you develop your application will always be bad. Don't do it. If you do be prepared for tired legs because the chase to find a better one will be never-ending.

</comment><comment><USER49> Sounds very similar to CQRS, but from a UI perspective. Interesting.

I wonder how this applies to stateless systems (HTTP) though. It seems like it's really geared toward thick client applications.

</comment><comment><USER50> AngularJS is the future.

<comment><USER51> We built a prototype app using AngularJS. For our specific usage of AngularJS, while we achieved our goal with the least LOC, its performance is so poor [on mobile] compared to Ember.js, CanJS and MarionetteJS that it was certain that AngularJS is indeed designed for the future, but not the present.

<comment><USER52> If you did any kind of systematic comparison of those, write a blog post and post it here. I bet it would get a lot of discussion. Angular's mobile performance is very interesting, but not something that seems to have gotten much attention yet.

</comment></comment></comment><comment><USER53> I think the key takeaway is that your view is read-only. An abstraction that's great for reading isn't necessarily great for writing.

</comment><comment><USER54> Who cares what you call it? As long as it does what i need. Models, Workers, Controllers, Views, Events, Masks, Filters, Actions...

</comment><comment><USER55> Not talking about the content of the article, but this 2-column style of reading is not very pleasant for the web.

</comment><comment><USER56> Sshhh... I have just moved us on to this in the office.

<comment><USER57> I dunno, this and most the other complaints about MVC are about the ambiguity of the controller definition, not the fundamental concept.

</comment></comment><comment><USER58> MVC is dead, long live MVC.

<comment><USER59> The reports of the death of MVC are greatly exaggerated.

</comment></comment><comment><USER60> can we see a node.js framework with MOVE principles?</comment>


Ask HN: Your optimal way to start Computer Science? - <AUTHOR> what better place to ask this question than HN? If you could do it all over again, how would you it? Imagine yourself in your early teen years, fully capable of self-teaching and already with a solid foundation of maths and sciences, yet you never really got into much computers technology (have not done any programming). But now you want to get into it, you have the time and want to make it a learning experience with the future in mind, rather than an immediate goal of being able to program on a language or two ASAP. At the same time you'd want it to have it moderately exciting, practical, that you can start using somehow computers in projects that a child is more interested, like robotics rather than pure software. How would you do it? What resources you'd use? Would you start with a functional language when you'll start applying the concepts you learn or not? This is not a hypothetical question, somebody needs your advise. <comment><USER2> Are you sure they want robotics rather than pure software? For the longest time I was really put off of programming because of all the libraries and magic going on and people trying to show me the "cool stuff." It was cool stuff but I could never really get into it because I never felt I had a good feel of what was going on and there were so many components involved. I think if I was introduced to competitive programming earlier I would have loved it. Nothing messy to think about but the problems themselves and some kids might be motivated by the competition or puzzleness of it.

</comment><comment><USER3> C is still useful to know, its not nice and clean and modern like Rust but C11 has some new useful modern parts. When I was a kid you had to be in the know to know about open source, I didn't have the benefit of seeing lots of other people's code and looking at projects back then, wish I did this ia a great environment for learning with all the free online resources compared to the late 80s BBS era.</comment>


Venting Anger Makes People More Aggressive - <AUTHOR> http://www-personal.umich.edu/~bbushman/bbs99.pdf

<comment><AUTHOR> This isn't new, but it was news to me. Thanks to DGCA (<https://news.ycombinator.com/item?id=5712250>).</comment>


Cloudflare's Ethereum Gateway - <AUTHOR> https://blog.cloudflare.com/cloudflare-ethereum-gateway/ <comment><USER2> "But Jonathan," I hear you say, "by providing a gateway aren't you just making Cloudflare a centralizing institution?"

The problem is the market share of these institutions. Google could argue that they aren't the sole gatekeeper to search since services like DuckDuckGo exist. This isn't really valid when you control a huge amount of the market share. I'm worried about how the internet is becoming super homogeneous, it really hurts startups. I'm not saying what Cloudflare is doing is bad, but the amount of control Cloudflare has is increasingly worrying based of all the services they are launching. Look at what it did to The Daily Stormer (I think they are disgusting and have zero support for them), it's clear that they aren't unbiased. If Cloudflare blocks your service on their VPN, DNS, DDoS protection, IPFS site, Ethereum, etc you are majorly screwed. Most people aren't willing to change their setup just to visit your one service. I still think what Cloudflare does is awesome, not trying to be too negative, just a little worried.

<comment><USER3> I think with tools like ipfs the situation is similar to git and GitHub. Yes github could screw you over but it takes very little work to get off their platform. With ipfs you just change your DNS (which is something you do every time you update the content anyway.)

<comment><USER2> Yeah you're right, I might just be a little alarmist. Having these services is better than not.

</comment></comment></comment><comment><USER4> From what i know about cryptocurrencies, Ethereum has so many more use cases and functionalities built in than Bitcoin. It seems like this is what blockchain tech is all about, not just transacting money. Is there some real reason why Ethereum coin market cap is so much lower? Is it just the hype and Bitcoin being first?

<comment><USER5> Ethereum has been around for nearly 4 years now, and despite some wacky smart- contract experiments, the most compelling use of it as a platform has been CryptoKitties.

Other than that, it is mostly just a cryptocurrency.

Ethereum is novel, but it doesn't solve the right problems.

<comment><USER6> Prediction markets are interesting but I don't think they've taken off at all.

One of the larger issues with Ethereum is that Solidity, and the EVM as an extension, make it really, really difficult to write correct, cheap contracts.

Off the top of my head, choices like:

* uint256 as a standard word size

* the possibility of reentrancy attacks

* overflowing integers wrap around

* contract upgrades are non-trivial (particularly upgrading solidity versions using an upgradable contract paradigm).

* Operator semantics are confusing

* State mutability is not as explicit as it ought to be

I know bad language features like hoisting were fixed a while back (and maybe some of the stuff I listed as well), but many of us are stuck on pinned older versions of solidity because upgrades.

Questions like: "what transactions are present for a particular address" have non-trivial answers. Key management is difficult even for experienced users, as are addresses and identity management.

There is some momentum toward using WASM instead of EVM in future Ethereum versions, but I honestly think the proper move is to develop and use a standard language for the purposes of building secure financial contracts.

Running a full-node and keeping it healthy (let's say with state pruning, i.e. not a full archive node) is actually pretty difficult. Most people probably use infura because of this. I still don't have a great answer on how to properly determine that a node (geth, unsure about parity) is effectively 1. up to date and 2. healthy (i.e. can be load balanced), making it difficult to automate stuff like load balancer promotion / demotion.

Last week the gas price on the network went up like 20-40x for 4-5 days because of an individual contract spamming transactions with a high gas price. It seems like few people noticed and few people cared.

<comment><USER7> What do you think of Vyper?

</comment></comment></comment></comment><comment><USER8> If I am understanding - Cloudflare is suggesting that we use IPFS hashes ( [https://developers.cloudflare.com/distributed-web/ipfs- gatew...](https://developers.cloudflare.com/distributed-web/ipfs- gateway/automated-deployment/) ) - hence the need to update DNS records everytime you deploy... So disregard of IPNS

<comment><USER9> IPNS is currently pretty slow when it comes to retrieving content. Updating DNS records ensures a faster user experience for those retrieving the content from gateways. That being said, Protocol labs is currently working on speeding up IPNS so hopefully IPNS can be relied on more in the future.

</comment></comment><comment><USER10> So as someone who is working in this space (on distributed applications using Ethereum), I want to call everyone's attention to a very important API that Cloudflare thankfully did implement: eth_getProof. As far as I am concerned, this is the most important API offered (and if anything, it is mostly sad no one has built out a few more APIs designed to make getting to the point where this is useful).

For those who don't know much about the inner workings of Ethereum, every account has state associated with it: not just its balance, but in the case of a contract its memory and its code; the memory of a contract is pretty much a sparse 256-bit addressable hash table, with everything from a single contract hashed into the same address space. This makes directly working with the memory of a contract really trivial; and, if/once you know of a specific storage slot you want, you can get it using eth_getStorageAt.

Now, what most people know is that each block contains a hash of the previous block, and "the contents of the block"; but, the setup is actually way more useful than that: each block "contains" (by hash reference) the entire current state. So, given a block header you trust, you can work off of a merkle tree of the entire Ethereum state that is rooted at that block and obtain a proof that some specific account state value is valid.

This means that light clients can opt to sync only block headers and then request proofs of the specific tiny bits of information they need from other nodes. Instead of using eth_getStorageAt to pull a storage slot from the memory of a contract, or eth_getBalance to find out how much money the account is storing, you can use eth_getProof to get a merkle path demonstration that "given the block headers you trust, you can now trust this random value you wanted to pull".

A really light client might alternatively sync some subset of block headers to some total amount of difficulty into the past (similar to people who wait for "confirmations" on Bitcoin blocks), to say "someone who is trying to fool me about this event having happened would have had to spend a million dollars of electricity to target me with fake information here, which wouldn't be worth it given the relatively small amount of my transaction I am verifying".

Another way of doing this is to correlate the current block hash from multiple providers to make sure that it is the same, and then use that opaque agreement as the root of trust for calls to eth_getProof. (An important detail: doing it like this, as opposed to correlating the thing you wanted to check, happens before any of the providers know what you are looking for, so if they are colluding they wouldn't be able to target you and the information you want to read with corrupt data.)

Essentially, since Cloudflare has implemented this specific key API (which is notable as it is a newer one that has greater resource usage on their end than other APIs, and so I have seen providers decide not to bother as they just don't get it), you don't actually have to trust them all that much when you are using this API: it feels more like working with IPFS, where "well, I asked for the file with this hash and they gave me a file that in fact does have this hash... I guess I would be shocked if it weren't the right file".

</comment><comment><USER11> Using Cloudflares centralized node defeats the purpose of a blockchain. Cool feature though that adds to the Ethereum network.

<comment><USER12> FTA: "But Jonathan," I hear you say, "by providing a gateway aren't you just making Cloudflare a centralizing institution?"

That's a fair question. Thankfully, Cloudflare won't be alone in offering these gateways. We're joining alongside organizations, such as Infura, to expand the constellation of gateways that already exist. We hope that, by providing a fast, reliable service, we can enable people who never previously used smart-contracts to do so, and in so doing bring the benefits they offer to billions of regular Internet users.

\-----

I wouldn't say it defeats the purpose. Unless you expect every user to run their own node you really have no choice but to provide one for them or rely on a trusted service like Infura. It also makes nontrivial transaction/history lookups possible by providing a more performant search layer, the results from which you can cross reference against the actual on-chain data.

Further, client-side libraries like Ethers.js use a quorum w/ multiple centralized services to help guard against censorship/errors/etc. at that level. It's an okay middle ground.

</comment></comment><comment><USER13> Any idea if cloudflare supports test networks like rinkeby to start developing?

<comment><USER10> FWIW, the API they provide here is a subset of the API provided by a local Ethereum node, and also the same general API surface (with the exact same protocol) as the APIs provided by Infura, AlchemyAPI, and myEtherWallet. While I also went looking for a testnet endpoint from Cloudflare (and didn't find one), it is arguably superfluous as it is drop-in compatible for things that do have testnet endpoints.

</comment></comment><comment><USER14> Can it be used as a full-fledged Infura replacement?

<comment><USER15> Yes</comment></comment>


Cheap cab ride? You must have missed Uber's true cost - <AUTHOR> http://www.theguardian.com/commentisfree/2016/jan/31/cheap-cab-ride-uber-true-cost-google-wealth-taxation <comment><USER2> I don't really understand why Morozov is singling out Uber here, aside from clickbait. The situation would be exactly the same if all the legacy taxi firms were bought up by a multinational corporation.

The issue is that governments are bad at raising revenues in the face of an increasingly globalized economic system. That's all there is to this. It's not a problem that is uniquely associated with Uber, successful startups, or even the tech industry in general. When governments don't rigorously enforce their own taxation requirements, and fail to eliminate gaping loopholes that are exploited with impunity, _of course_ there is going to be an issue with government revenue streams.

Though the concern about tax revenues here is legitimate, this article is more or less just more of Morozov's typical approach of finding a way to blame technology for deeper sociopolitical issues.</comment>


What Every Startup Need to Know About IP in China - <AUTHOR> http://formdevices.com/blog/No-Fools-Errand.html <comment><USER2> If you found this interesting, you might also like:

\- [http://www.chinalawblog.com/2013/09/china-trademark- basics.h...](http://www.chinalawblog.com/2013/09/china-trademark-basics.html)

\- [http://www.chinalawblog.com/2013/04/register-your-china- trad...](http://www.chinalawblog.com/2013/04/register-your-china-trademark-or- go-home-part-ii.html)

\- [http://www.chinalawblog.com/2014/04/the-trouble-with- madrid-...](http://www.chinalawblog.com/2014/04/the-trouble-with-madrid- system-trademarks.html)

\- [http://www.chinalawblog.com/2014/07/when-to-register-your- ch...](http://www.chinalawblog.com/2014/07/when-to-register-your-china- trademark-ask-tesla.html)

</comment><comment><USER3> I'm curious about copyright infringement in china and what _practical_ options there are. Hope it's not too OT.

We're building an anatomy learning platform[0], and produce original illustrations and videos that cost us a lot of time and money to create. When we see copies on US or EU website we can use DMCA or EU takendown notices, which usually work. In China our emails were pretty much ignored...

Now we're not some huge company, we're a small bootstrapped startup which isn't even ramen-profitable yet (mostly due to large expenses on content- creation). We cannot even afford a lawyer locally, let alone someone who can represent us in China. I'm wondering if anyone has some tips or experience in this area?

(all being said, the number of infringements we know about is pretty small, but it's worrying nonetheless)

[0] www.kenhub.com

</comment><comment><USER4> China is many things, but one of those is practical. They're planning for a future in which they're not just a low-cost manufacuring hub (much of that is indeed already leaving China for places like Vietnam). To that end, they're making a very concerted effort to modernize their legal system, importing many ideas from the U.S. (e.g. they have American legal academics helping reform areas like the law of evidence) and introducing twists of their own (e.g. lightweight arbitration for small civil disputes).

</comment><comment><USER5> > Chinese trademark registration costs are typical internationally.

To the OP, this sentence does not parse or I fail to understand what you mean with it.

<comment><USER6> Perhaps it's suggesting that trademark registration costs in China are on par with those of other countries?

<comment><AUTHOR> Poorly worded perhaps, but michelmior's interpretation is correct.

</comment></comment></comment><comment><USER7> Great article. Thanks for sharing your experience

</comment><comment><USER8> Thanks for information about trademarks. What about utility, utility models and designs? Can it be protected in China?

<comment><AUTHOR> Yes, they have a system with design and utility patents that is ~similar to the west. When you talk to local lawyers they always emphasise the importance of trademarks as the most effective way to protect your IP, but if you are have the budget getting patents could be good as well. The one thing to note is that you have to file a Chinese patent within a year of any other application worldwide. (I don't know nearly as much about this subject as I've learnt about trademarks, so caveat emptor.)

</comment></comment><comment><USER9> Interesting to see the tides changing. Whether the IP laws are enforced is another story.

<comment><USER10> I'm preparing to lodge a patent application in China. Not because I think it might be realistically enforceable _now_ , but because in its lifetime the degree to which the Chinese system will enforce it is going to rise.

It's a 20-year bet on the legal trajectory of what it is going to be the largest market in the world.

</comment></comment><comment><USER11> Are hardware+software startups like fitbit & withings copied as well?

<comment><USER12> Yes, at the price of $13. [http://www.cnet.com/news/xiaomi-to-sell- its-13-fitness-band-...](http://www.cnet.com/news/xiaomi-to-sell- its-13-fitness-band-starting-august-18/)

<comment><USER5> This is one of the reasons why I will probably never again do a hardware start-up.

<comment><USER13> Lemme give you a counter example. Chinese copied Neato or irobot Roomba, their hardware was even superior and price is 30% as much, but ultimately failed as a product. Because the route planing algorithm is completely shit. You often found it stuck or running out of power.

Neato or iRobot does not sell in China, Chinese users actually pays extra to get one. And they are happily doing so.

The moral of the story? Chinese can not copy the soul of your product.

<comment><USER14> Kindof surprising that they did not manage to obtain the routing algorithm of the Roomba.

</comment></comment></comment></comment></comment><comment><USER15> Very helpful and something we have worried about as well.

</comment><comment><USER16> Very helpful - thanks!

</comment><comment><USER17> nice</comment>


Study of over 1m people finds association between lifespan and blood iron levels - <AUTHOR> https://www.nature.com/articles/s41467-020-17312-3 <comment><USER2> For those of us who aren't in the life sciences, is this saying too much iron is good or bad?

<comment><USER3> I think the article says iron levels are negatively correlated to longevity, but "the association might be due to a already-known correlation to haemochromatosis" which I have no idea what that is. I presume it's some known population that's old that happens to also have an enrichment of haemochromatosis but where individuals in that population without it do not show a positive defect in longevity?

Edit: specified as negatively correlated

<comment><USER4> Due to them saying that "the association might be due to an already-known correlation to haemochromatosis" I'm assuming they didn't have the data to correlate haemochromatosis to the data.

Haemochromatosis is a genetic disorder where individuals are unable to get rid of excess iron. If properly diagnosed, this is easily treatable with bloodletting (blood donation in this century :-)

Haemochromatosis is the sort of genetic disease that could really screw with data like this. Undiagnosed haemocromatosis leads to early death....so the correlation of excess iron to longevity should be treated as a weak piece of evidence until we can exclude people with the genetic disorder.

<comment><USER5> Great comment! For the iron - ageing link, we used two pieces of data: the effect of DNA on blood iron levels, and the effect of DNA on how long and healthy you live. We found the mutation that causes hereditary haemochromatosis had a large effect on early death (as expected). However, other genetic variations that increased blood iron levels also had a proportional effect on early death. So it looks like it is higher iron levels, not just haemochromatosis, that may accelerate the rate of ageing.

</comment></comment></comment></comment><comment><USER6> How did they remove the correlation with sex? Did they control for the females living longer and having lower blood iron levels

<comment><USER7> If only there were a section of scientific papers devoted to explaining the Methods used to obtain the Results. It'd be especially great if it came after an Introduction explaining the context and was followed by a Discussion of the merits, weaknesses, and impact of the study.

<comment><USER8> Hey friend. You're 100% right for pointing out that this stuff is addressed in the paper. I think the sarcasm is a disservice to everyone, both you and the parent comment included. Further, he may not have had (or may not have) the time to fully analyze the paper, and may be asking if others are aware if that specific concern is addressed, which seems like a reasonable comment.

<comment><USER9> Sorry, I don't really agree. HN is full of people who react to headlines without reading the article and the underlying materials, and in my opinion it greatly decreases the quality of discussion.

<comment><USER10> I was reading ..somewhere.. that a person having a negative interaction on an online forum increased the likelihood of that person then going on to make a negative comment themselves 300%. When I read that HN's zealous downvotes of slightly impolite comments started to make a bit more sense to me. It's better to avoid snark and sarcasm, as fun as they are.

<comment><USER11> If your life revolves around acceptance by HN mods, then you need to wakeup from The Matrix!

Nobody wants another cesspool like /. was in its hay day, but ultimately only HackerNews/Ycombinator are harmed by this phenom of over-moderation.

For example, whose brilliant idea was it to create a user community that downvotes on comments hostile to Chinese Communist Party (that aims nuclear weapons at us while supporting North Korea in every sense and planning to kill our trading partners in Hong Kong and Taiwan) or on comments brutally critical of Apple for abusive trade practices? A lot of the downvotes also come from users that are obviously very inexperienced and unable to understand subtle contexts leading one to believe that a great way to solve this "problem" would be to only allow moderation by senior members of the community, as determined by peer votes, not by account age.

<comment><USER10> Isn't 500 karma needed to downvote? Karma might be an indicator of seniority indicated by peer vote. As for the other issues, there are ways of being highly critical without needing to be brutal.

<comment><USER11> "peers" lol

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER12> So if iron accumulation is bad does that mean the medieval doctors with their bloodletting were on to something after all?

<comment><USER13> Blood donations are the modern positive equivalent.

</comment></comment><comment><USER14> Rubbish HN article title. The Abstract and Intro in the article do not mention the word iron at all.

Later on we get: "Mendelian randomisation of iron traits" and the HN title looks very suspect. The sort of cobblers a supplement pusher might write.

<comment><AUTHOR> >Haem Definition and Examples - Biology Online Dictionary

>What does haem mean in biology?

haem. 1. (Science: biochemistry) compounds of iron complexed in a porphyrin (tetrapyrrole) ring that differ in side chain composition.

</comment></comment><comment><USER15> > Twenty one of the 24 multivariate GWAS loci reaching genome-wide > significance had directionally consistent effects in the three studied > datasets and 18 were nominally significant (P < 0.05) in two or more > datasets (Supplementary Fig. 1).

Unrelated to the content of article but why are "twenty one" and "three" and "two" spelled out but 24 and 18 are written as numerals? Is there any rhyme or reason to this? I find this kind of inconsistency so distracting when reading technical papers. It makes me think some of the numbers were edited/changed last-minute in subsequent drafts.

<comment><USER16> Style guide. Sounds like the one my work uses (Associated Press):

\- Numbers up to ten are written as words

\- Numbers 11 and higher are numerals

\- Any number that starts a sentence is written as a word

<comment><USER17> What does your style guide say about periods? I notice none of your bullets ended with a period. As a programmer I often struggle with whether I should end my comment with a period.

<comment><USER16> First, I dislike the AP style guide. So my own writing will sometimes violate it just to please me.

As for periods, any phrase that is a complete sentence must have a final punctuation mark. So my bullet points would've required periods in a report. They also could've been connected by semicolons with a conjuction at the end of the second-to-last point:

\- A;

\- B; or

\- C.

The idea is to stick to proper English sentences. The bullet points are just incidental formatting.

</comment></comment></comment></comment><comment> Munky-Necan > The effects of loci of interest on male and female lifespan are largely the > same, although their effect on survival may be slightly stronger in middle > age (40–60 years) compared to old age (>80 years).

This is interesting. I have a feeling that because there are many congenital cardiovascular and other congenital diseases that one usually succumbs to in the 40-60 range that is what we are seeing a stronger link to genes here. Unless a parents passes away before the age of 55 from a heart attack it's not considered hereditary.

I find it interesting when studied like this are performed. One of the best predictors of life expectancy in elderly individuals is grip strength; not because of the fact that one has a strong grip, but because a stronger grip means more muscle mass leading to longer life. When I see that iron levels are correlated to longer lifespans I wonder if there's something else going on. Many women, in particular, walk around with iron deficient anemia and don't realize their fatigue is because of their lack of iron. Anyway, I'm excited for this line of research to be further delineated.

</comment><comment><USER18> from the article: "Interestingly, protective variants near FOXO3 are associated with a reduction in metabolic syndrome, but also with a reduction in cognitive ability."

</comment><comment><USER19> Is this what is called "p hacking"? Looking a among many different criteria until you find one that is statistically significant?

<comment><USER20> This is a good question to ask and I am not sure why you are being downvoted. The answer is that p-hacking was a real problem back when these kind of large multi-gene frequency analysis studies were just starting out. Not intentionally, mind you, just that the people running the studies were biolgists first, and statisticians only on an ad hoc basis. In the late 90s and early 2000s there was a lot of debate about the poor quality of statistical analysis in the field and things started to improve. Today these studies have a bunch of descriptivist and bayesian tools they can use to sort out real positives and negatives from false ones. The result is that these studies now discover real and important genes that impact complex diseases. We are finally getting close to the dream of personalised medicine.

A good further read is the 1998 paper that describes the problem in detail: [http://ib.berkeley.edu/labs/slatkin/popgenjclub/pdf/terwilli...](http://ib.berkeley.edu/labs/slatkin/popgenjclub/pdf/terwilliger- weiss1998.pdf)

</comment></comment><comment><USER21> Misleading title. Mention of blood levels are few, and the authors say it's uncertain and needs further research anyway...

</comment><comment><USER22> For these kinds of articles, it is important to remember that correlation does not imply causation.

<comment><USER23> People say this so much that is now used as a way to dismiss any study. It's almost becoming a meme.

I think is clear that the baseline of any study is that correlation does not imply causation. You start there. That's a basic intelligent start. You never take for granted that one thing causes the other. The ideas is to try to identify if there are any potential paths for causation.

Otherwise there's not even a point in sharing or discussing these studies.

I'm not saying that bringing this up is wrong, but does it need to be said so much? I think it's more interesting to analyze beyond that and try to see if there's causation. We already know there's an abysmal amount of correlated things but there must be a percentage of those things which are in fact caused by another at a certain level. I would love these discussions to be more focused on this and not just doing the plain classic dismissal of "correlation doesn't mean causation".

<comment><USER24> It needs to be said so much because people weaponize scientific studies in the pursuit of their political agenda, media twist headlines to get clicks, etc. I've lost track of the number of articles that bury the "the authors of the study caution against any definitive conclusion about causation/correlation"

<comment><USER25> If the goal is rhetoric and not truth, no amount of repeating droll truisms is going to prevent that. Additionally this comment thread has been fairly tame.

It doesn't need to be said so much, obviously. I've counted what, 3 times so far in just this thread?

It doesn't make you sound smarter.

</comment></comment></comment></comment><comment><USER26> Is there a TL;DR version of what to take away from this article?

I read it, but didn't understand what the conclusion is, or if it's actionable or not. Should I better monitor my iron intake or something?

<comment><USER27> The tl;dr is they found some genes relating to iron metabolism and other key cellular processes that are correlated with longevity and healthy ageing. It doesn't seem particularly actionable unless you're a DNA researcher.

</comment></comment><comment><USER28> Someone wants to sell his supplements, uh?

Title is: "Multivariate genomic scan implicates novel loci and haem metabolism in human ageing".

</comment><comment><USER29> Longevity (lifespan) is only part of the picture.

Frailty is another metric, probably more important as you want to live a long live while being able to use your days.

<comment><USER30> The authors explicitly address this point, calling it "healthspan".

<comment><USER29> They say they do, but I'd say they didn't do that properly.

Quoting the relevant part for you that lead me to this conclusion:

> "For one, there are currently no widely accepted standards for measuring > healthspan. Zenin et al. define healthspan based on the incidence of the > eight most common diseases increasing exponentially in incidence with age in > their sample. "

> "Recent estimates suggest the genetic components of both human lifespan > (i.e. the number of years lived) and healthspan (the number of years lived > in good health free of morbidities) are only around 10%"

> "Parental lifespan correlates strongly with both healthspan (rg = 0.70; SE = > 0.04) and longevity (rg = 0.81; SE = 0.08), while healthspan and longevity > show a weaker correlation with each other (rg = 0.51; SE = 0.09)"

The authors may pretend they studied healthspan, but I'd rather say they studied biased data (as death is well reported, while autonomy is harder to asses according to their own words), on something poorly correlated with healthspan, which even if we assume perfect correlation can only explain about 10% of the difference.

> healthspan correlated more strongly with metabolic traits (such as type 2 > diabetes) than the other studies, and showed negative genetic correlations > with depression and cancers, especially melanoma

So I would not call the article rubbish, but I would be careful to extrapolate that iron matters so much:

> These correlation estimates ranged from 0.013 between healthspan and > longevity to 0.094 between healthspan and parental lifespan, reflecting a > small degree of sample overlap and/or phenotypic correlation

Indeed, parental lifespan may explain more! Even better, look at the coefficient in table 3:

> > [https://www.nature.com/articles/s41467-020-17312-3/tables/3](https://www.nature.com/articles/s41467-020-17312-3/tables/3)

βlongevity is 5x more than βhealthspan , and one coefficient even changes sign (ferritin) possibly due to haemochromatosis (I'm too lazy to check, I've already spent too much time on this article) so I wouldn't jump to conclusions</comment></comment></comment>


Ask HN: Equity and cofounder title for first hire? - <AUTHOR> I started a company this year with the mission to help end metabolic disease influenced by lifestyle. We do this right now by selling ketogenic cookies and teas directly to consumers. The company is Fat Snax, fatsnax.com. I started selling in April and will do $80,000k in sales this month and $100,000k in sales next month.
I hired a marketing consultant in April and he has been integral to our growth and success. My deal with him at the time was a $600 monthly retainer plus 15% commission on sales with monthly contract review and renewal.
He's asking to made a co-founder, given equity and still draw a small salary. My question to you is what is reasonable given that he hasn't put money in, he gets paid, I'm still a volunteer and founded this long before I hired him? <comment><USER2> I'd consider actually doing it. Consider who's the dog and who's the tail- is your company making him rich or is he making your company rich?

By transitioning him to equity, you still get the benefit of his continued hard work but now the company's profits don't all go to him. Don't drop it in his lap- set it up with a standard 4-year vesting schedule, but I'd actually do one better and go above the 30% he asked for. (Maybe 33%).

I seriously doubt you could replace him under the same terms. Find someone else, sure. Find someone who performs this well, not as likely.

You have a golden goose here. Don't begrudge him his grain. Just quietly collect the golden eggs, keep him so happy he lays more eggs, and give him zero reason to think it's only a matter of time before you slaughter him for meat.

<comment><USER3> Yeah, I agree. The company was started in April, and the consultant joined that same month. Obviously you, Jeff, know better than we do, but it seems likely that he's been a huge part of the company's success. What would happen if you lost him?

<comment><AUTHOR> I would not be where I am today if he wasn't a part of this. What would I do if I lost him? Answer is I don't know. The company would not implode and we would keep moving forward but at what cost?????

Talking this out helps. Thanks for the input.

</comment></comment></comment><comment><USER4> I did have a CMO/COO for my first company. Transitioned him to equity and cofounder status after a few months with him. It turned out to be an awesome deal. He got us acquired in the end because of his connections and hard work.

The thing is that for maximum stability, most businesses need a cofounder. Partly to bounce ideas off, to keep you focused and slap you when you get distracted, and to act as an emotional pillar when things inevitably go bad.

For a lot of solo founders, their real co-founder is actually a family member: brother, spouse, daughter/son. If your first hire is the only person you're bouncing ideas off, they deserve a co-founder title. An employee, even as a right hand man, will have much more difficulty shaking sense into you.

Another thing to consider is that putting someone as cofounder status makes this company their life focus. How much would that improve his performance?

It's normal for cofounders to not take put money in and take salary, they just get a much lower share. One digit equity normally. But the drawback is that one digit equity doesn't qualify for a cofounder status. Maybe you can start with 5% but offer to sell him an additional 10%.

</comment><comment><USER5> I personally will not do it, and will go with early employee, but you need to evaluate what's right for the business. If you do give equity - setup a vesting.

[https://www.quora.com/What-is-a-fair-amount-of-equity- for-a-...](https://www.quora.com/What-is-a-fair-amount-of-equity-for-a-late- co-founder-with-2-original- founders/answer/Jason-M.-Lemkin?share=89d9137a&srid=ivbn)

<comment><AUTHOR> What if I said he's asking for 30% equity?

<comment><USER6> Laugh him out of the room. The guy is pulling in $15k/month from the job. Some equity might certainly be in order, but definitely setup a standard vesting schedule with a one year cliff. 1%-5% equity for an early hire makes perfect sense at your discretion.

<comment><AUTHOR> Thanks! I was thinking 5% as well.

</comment></comment></comment></comment><comment><USER7> As an aside: nice idea! I'd buy the product, if I lived in the US.

The cookies are still quite high in calories per 100g, so if you could get that down all the better.</comment>


Episode 31–Steli Efti–Closing Software Sales and Your Mental Game–Chasing Product - <AUTHOR> http://www.chasingproduct.com/episodes/episode-31-closing-software-sales-and-your-mental-game-wsteli-efti <comment><USER2> Enjoyed this episode, particularly the habits/building momentum vs setting goals philosophy :)</comment>