You couldn't pay me to work for Ballmer - <AUTHOR> http://37signals.com/svn/posts/2380-you-couldnt-pay-me-to-work-for-ballmer <comment><USER2> _I wish Microsoft had their evil genius back._

Not me.

I've had 3 career phases: BMS, DMS, AMS, Before Microsoft, During Microsoft, and After Microsoft.

I remember how cool things were back in the good old PHP/VAX/Microdata/CPM days before Windows fucked everything up. Then I suffered with every enterprise who had adopted all things Microsoft. Now that people feel we actually have choices again, I don't ever want to look back. Any wonder I feel like a kid again?

<comment><USER3> Just curious but could you fill me in on what PHP stands for? I've tried googling it but I'm, of course, getting the other PHP.

<comment><USER4> I think what was intended was PDP. (see DEC history on wikipedia)

</comment></comment></comment><comment><USER5> The OP is both right and wrong.

Ballmer may not be the best visionary, product person, or have a good nose for the market.

But I really don't think MS could do anything to compete with the Internet era, and its results would likely be extremely similar with Gates in charge.

Also... let's not be revisionist. Gates was there long enough into the Internet era for us to know what he thought/how he responded. His attitude and approach was quite similar, and in some ways worse.

He was much less complicit to web standards on both the client and server sides.

These days, MS's intranet products retain this approach (Sharepoint), but its Internet ones are really good citizens and saying all the right things (Azure, PHP friendliness. Silverlight is old-school, but still less borg-y than stuff released in Gates-era). It's only that we have absolutely no reason to use the MS web-stack, and (rightfully)have trust issues that explains their lack of popularity.

So yeah... Ballmer is a dork. But MS's gradual demise is a natural effect of the Innovator's Dilemma and the Internet.

<comment><USER6> And I think a lot of people misunderstand the Innovator's Dilemma, even Clayton to some extent. I've heard people say things like, "We should eat our lunch before someone else does". The problem is that starting lunch too early can result in you losing your core business too quickly.

For example, if MS is making $15B a year in client products right now. And over time, against Google and such, that number will drop $1B/year until it hits $3B. Or they could accelerate that drop, such that it drops $3B per year, but they can generate $1B dollars per year by eating their lunch.

While it may be "fashionable" to be the cutting edge company generate $1B/year on some cool technology. It's actually prudent to fight against the new technology as the incumbent for as long as you can. And try to find totally new markets, rather than eating your own lunch.

<comment><USER7> What does eating lunch mean in this context?

<comment><USER8> Undercutting your own existing, successful business with a new business better prepared to go into the future.

Specifically, think about Office. MS could have released a web-version of these at a price-point that competed with other web office stacks. Doing so would have put them in position to succeed in the Internet world, but it would have gutted their Office profits in the process.

Given their cost structures are set up around those profits, no sane business person will make that decision. Hense, the dilema: you can see you are going to die to companies who change the rules, you know what you would need to do solve that, but the economics of doing that would mean anybody who really tried would be out on their ear.

</comment></comment></comment></comment><comment><USER9> I don't think you could pay DHH to work for anyone but DHH.

</comment><comment><USER10> I found the questions the most telling.

Questions to Jobs were firstly about Apple and secondly about Google; with questions about Microsoft almost always having a historical "back in the day" feel about it.

Questions to Ballmer were largely about Apple and Google.

Apple and Google are just far more relevant. What are you gonna do? Ask Ballmer about Kin and Xbox?

<comment><USER11> Kin?

( /tongue-in-cheek )

<comment> daniel-cussen Kin?

(just don't know what a Kin is and looked it up)

</comment></comment></comment><comment><USER12> My favorite quote: "I wish Microsoft had their evil genius back."

Bill Gates is an amazing man in so many ways. He may have had an evil edge in business, but that ruthlessness is what brought him success. It would have been neglectful to his shareholders to act in any other way.

Now he works full time spending his fortune on making the world a better place. Truly a great man.

<comment><USER13> > Now he works full time spending his fortune on making the world a better > place. Truly a great man.

Remember, he amassed his fortune through monopolistic practices that valued control and subjugation of competition over product innovation and creation of value.

Is it possible to both be a notable philanthropist and also not engage in business practices that perhaps run counter to the generous philosophy of philanthropism?

<comment><USER14> Exactly, like Capone killing half of chicago to amass his fortune, then giving it away to aww-so-poor orphan kids (the same kids he killed their parents) to clean his face from blood stains?

<comment><USER15> Yes, because bundling a web browser with an OS is exactly like killing people.

<comment><USER16> Just curious, how different is IE in Windows versus Safari on OSX? (or iPhone)

<comment><USER17> Coz OSX doesn't run >90% of world's computer. Else it would have been same

</comment></comment></comment></comment></comment></comment><comment><USER18> From watching that I got the feeling that you could ask Ballmer about his thoughts on (for instance) the steel refining industry and receive a remarkably similar stream of business pseudo-speak.

<comment><USER19> >stream of business pseudo-speak.

My thoughts exactly -- and spending time at MS, that is the MS lingo, at all levels. I think the janitorial staff only speaks in business pseudo-speak.

</comment></comment><comment><USER20> Given the introduction, I expected to see Ballmer saying something outright idiotic. I didn't see it. He merely said that whether it's a tablet or a laptop or a desktop, it's still a personal computer. Fair point. Perhaps he used the word productivity to mean creative activities? Maybe someone could take issue with that? Sure, go ahead. I wouldn't work for Ballmer either, but this video is not why.

<comment><USER21> This reminds me of the interview with Ballmer about the iPhone <http://www.youtube.com/watch?v=BcUicfqelC8>

"Right now we [Microsoft] are selling millions and millions and millions of phones per year, Apple is selling 0 phones per year. In 6 months they [Apple] will have, by far, the most expensive phone in the market place."

<comment><USER22> I am still not sure he is incorrect in that. Maybe the time frame is wrong (when did he say it?), but still.

</comment></comment></comment><comment><USER23> I think part of the problem is that Ballmer doesn't have a deep technical background. And unlike Jobs, he doesn't have a world class sense of design to point him in the right direction.

<comment><USER24> possibly also that he doesn't seem to consider MS as a consumer company, pandering more to enterprises and OEMs.

And he seems to dismiss his competition with hyperbole.

...it's a wonder he's the CEO, really.

</comment></comment><comment><USER25> Without even reading the article, I thought, " _Ballmer probably feels the same way about hiring you_ ".

</comment><comment><USER26> For someone who espouses grand principles (Rework), David is taking the low road with his petulant ad hominum attacks. Calling Ballmer's stage presence uncool is a little disingenuous when it's clear that Ballmer was just being himself and trying to get his lethargic team pumped up. Before casting too many more stones, David should reread his mentor Kathy Sierra's post about how unhappy people drag down the level of discourse.

</comment><comment><USER27> I typically like what DHH has to say. Consequently, I expected him to actually produce good comparative graphs. He did not.

AAPL is '98-now() and MSFT is '89-now(). If he wanted to compare MSFT to AAPL, put them on a single comparative chart.

If he wanted to compare Gates to Balmer, use NASD-100 to factor out (very roughly) the environmental differences.

</comment><comment><USER28> Never mind the fact that the author didn't select the video of Jobs waving his hands about why their phones don't work, or that in this video he was well spoken but still didn't answer the questions as asked. What is the point of this?

</comment><comment><USER29> you could pay me to work for Microsoft, or Apple, or whomever(within reason)if the price was right...

Sure Steve Ballmer doesnt seem to be all that successful as MS' CEO. They are still very profitable, make _some_ great products and have some really smart people there. I would argue its probably middle managers and bureaucracy that is the bulk of their problem. I suppose a more charismatic leader would probably try to fix that though.

</comment><comment><USER30> You could pay me to work for Ballmer.

</comment><comment><USER31> Regardless of whether you want him back or not, the truth remains that Gates was, and is, a visionary.

Would I prefer seeing him back at MS or in his current role? Without a question, I would like to see him use his fortune to address bigger and more pressing problems like poverty, disease, and malnutrition.

I have no qualms about his 'evil genius' side - he ran a business, a wildly successful one at that, and I think you can fairly attribute the widespread use of PCs to Microsoft (I'm a Mac). But the world could make better use of a visionary, compassionate, and generous (isn't that ironic how his current role contrasts with his past business image?) person like him.

</comment><comment><USER32> The 10-year charts for MSFT and AAPL are pretty astonishing when plotted linearly, not logarithmically :

[http://www.google.com/finance?chdnp=1&chdd=1&chds=1&...](http://www.google.com/finance?chdnp=1&chdd=1&chds=1&chdv=1&chvs=Linear&chdeh=1&chfdeh=0&chdet=1275681600000&chddm=997050&chls=IntervalBasedLine&cmpto=NASDAQ:AAPL&cmptdms=0&q=NASDAQ:MSFT&ntsp=0)

<comment><USER33> even more so when plotted from 1987: [http://www.google.com/finance?chdnp=1&chdd=1&chds=1&...](http://www.google.com/finance?chdnp=1&chdd=1&chds=1&chdv=1&chvs=Linear&chdeh=1&chfdeh=0&chdet=1275681600000&chddm=2447660&chls=IntervalBasedLine&cmpto=NASDAQ:AAPL&cmptdms=0&q=NASDAQ:MSFT&ntsp=0)

<comment><USER34> Yes, but we're comparing executives, not companies. Jobs returned to Apple in 1996. Ballmer became CEO of Microsoft in 2000. It's relevant to compare the stock performance under their tenure.

<comment><USER33> Yeah, I was just responding to a post. What you say must be put in context though. Sure, without Jobs there would be no modern Apple - it's a fact, let alone current growth. However, considering microsoft during and after late 90's you must take into account there was this thing called dot-com bubble. Take a look at Cisco for example, during the same period (late 90's) [http://www.google.com/finance?chdnp=1&chdd=1&chds=1&...](http://www.google.com/finance?chdnp=1&chdd=1&chds=1&chdv=1&chvs=Linear&chdeh=0&chfdeh=0&chdet=1275675960000&chddm=1977104&chddi=86400&chls=IntervalBasedLine&q=NASDAQ:CSCO&ntsp=0)

I think they were the first company in history worth a trillion dollars if I remember correctly.

edit: or it was a talk about it being the first big T company, can't remember correctly, it was a crazy time with madness like DOW 36,000 and fantasies like that.

</comment></comment></comment></comment><comment><USER22> I don't know much about Ballmer, but I think the comparison of the interviews was not quite fair. They were completely different types of questions. Ballmer got a bla bla question and answered in the same vein. Jobs got a specific question that had been posed just shortly before all over the news, so there was plenty of time to think about it.

</comment><comment><USER35> Do you guys feel what I'm feeling? I'm feeling a general lack of mindshare on new development and new technology coming out of Microsoft. Linux, Mac, and Droid is where it's at -- where developers are flocking because of the cheaper costs, better direction without getting screwed over, stronger security, wider community base, and more innovation. It's coming to a point where you see more non-Microsoft platform developers than Microsoft platform developers. And Windows is popup and virus city.

</comment><comment><USER36> Is it just me, or does Ballmer appear to be on medication/drugs? He seems to be slurring, with lazy eyes.

Seriously. Is this just me noticing that?

<comment><USER5> Your comment just spurred me to watch the video.

I noticed something, too.

[Edit. I previously ID'd a specific condition. While I stick by my observation, and would comfortably say the same thing in a hallway conversation, it's probably not cool to say it in a public forum. I'm in no way important or a shareholder in any company involved in this discussion. But a commenter below got me thinking. HN is a widely-read, influential place. I don't want my passing observation to be responsible for anybody's pain.]

<comment><USER37> Hey, just a quick tip- it's probably best not to suggest specific diseases or suggest such a thing about notable figures (especially those whose health has an effect on their share prices).

It's better also if you can spell their names properly; "multiple sclerosis", a disease of the nervous system, isn't specifically describable as a neurological issue, however does cause many.

It's also just as likely that he was tired after having to travel and then appear on stage to talk about his competitors.

<comment><USER38> "(especially those whose health has an effect on their share prices)." if Ballmer were sick, would MSFT price go up or down?

</comment></comment></comment></comment><comment><USER39> It's cute to see someone's intelligence being insulted in a syntactically ill- formed sentence.

</comment><comment><USER40> Now compare both the Steves to Mark: [http://video.allthingsd.com/video/d8-video-under-mark- zucker...](http://video.allthingsd.com/video/d8-video-under-mark-zuckerberg- hoodie/F403BCCE-661B-451B-8BC8-12536D12A82A)

</comment><comment><USER41> Pay you on top of what you be paid for your paid job?</comment>


The rise and fall of the industrial R&D lab - <AUTHOR> https://www.worksinprogress.co/issue/the-rise-and-fall-of-the-american-rd-lab/ <comment><USER2> recent comments, [https://news.ycombinator.com/item?id=24321799](https://news.ycombinator.com/item?id=24321799)</comment>


Microsoft: Dropping Linux, Unix enterprise search will "accelerate innovation" - <AUTHOR> http://www.itworld.com/software/95599/microsoft-drop-linux-unix-versions-enterprise-search

<comment><USER2> Well, it will for them....

E.g. Rich Hickey started out building Clojure on the JVM and CLR. At some point, he realized he could double the speed of Clojure per se innovation by only developing for one, instead of implementing the same thing on two VMs.

(He picked the JVM and later others resumed the CLR version.)

</comment><comment><USER3> So... Easy solution: ditch Fast and get a Google Search appliance.

I am sure Google will have sweet deals for the Fast customers who no longer want to manage their own internal search engines and would rather not run them on Windows.

</comment><comment><USER4> You may call me stupid, but after skimming this article I still have no idea what they mean with "enterprise search"...

<comment><USER5> I think they license software to companies that want an internal search engine for their intranet, kind of like Google's search appliance: <http://www.google.com/enterprise/search/gsa.html>

</comment></comment><comment><USER6> Serious question: What innovation did they have WITH Linux & Unix?</comment>


Your templating engine sucks and everything you've ever written is spaghetti - <AUTHOR> http://www.workingsoftware.com.au/page/Your_templating_engine_sucks_and_everything_you_have_ever_written_is_spaghetti_code_yes_you <comment><USER3> Every programmer is on a long, cyclical journey where every stepping stone feels like a new kind of enlightenment. Blogging allows them to share their brilliance with the world, showing how they are surely amongst the first to attain their new level of purity and zen.

The funny thing about this post is that the author tells us to get off our high horses and come down from our ivory towers... and then proceeds to make a series of highly conjecturable claims presented with no factual evidence beyond his own confident assertion that he's in the know. There's like, no chance that in two years he'll be advocating for his new new philosophy.

In the meantime, I'm left to wonder "Iain Dooley who?" and be glad that I'm confident enough not to read an opinion-as-fact article and assign it significant credibility.

PS: A good first editing step is to ask "does my opinion-as-fact blog post question the capacity and potential of a professional web designer to understand simple concepts like string interpolation, and could they find this insulting?" before assuming that you've got it all figured out.

<comment><AUTHOR> Whilst this article is indeed an opinion piece and strongly hyperbolic (and perhaps even didactic), I'm not sure why that offends you. I don't have any statistics about large or small organisations putting this into practice so I'm not sure what other facts I could have included apart from the examples I provided.

The capacity of designers to understand anything isn't the subject of the post, so I'm not sure why anyone would be offended by that.

The idea is that it's easier to find someone to work on HTML/JavaScript/CSS in a static HTML context than it is to find someone familiar with whatever frameworks you're using and it's templating language, then to have that installed locally (especially when you're not working with a long term in- house team of designer/developers and don't have lots of time to spend on training people).

I also personally find it far easier and quicker to iterate and test new interface ideas quickly when working with static HTML so I like to be able to view my templates outside of the context of my application/framework etc. and then iterate without having to re-apply a bunch of templating code.

<comment><USER4> It's ok to write a little polemic here or there but don't be surprised when people react negatively to it. People are offended because you are saying they are incompetent at their profession.

Have the humility to understand that many of us have been doing this for years and have seen numerous attempts to revolutionize templating, and _gasp_ have written webapps before the idea of templating really took hold.

If you want to persuade people to take up your ideas regarding DOM manipulation in the controller, I'd suggest not starting by telling people they are writing spahgetti code. It's a great way to get page views, it's a poor way to persuade people.

People probably would have reacted much better to your argument if you started with "Hey, I'm doing things this way and here's why it works for me" instead of "You're all idiots who write spaghetti code". Embedding XSL selectors in HTML attributes which is processed by a half-assed implementation of XSL in PHP is the kind of thing I think when thinking spaghetti code.

What you don't realize is that you've invented a new templating language based on XSL but with half the features. Those of us who've been around the block a few times like to call this inner-platform effect. We've also seen this idea before when it was pitched with J2EE and used XML with an XSL templating system.

<comment><AUTHOR> Hi, thanks for the tips. I'm always interested in opinions on my writing style and how to communicate better.

Regarding your critique of Fragmentify, that's actually not so much what I'm advocating here as it is just the impetus for realising that there are 2 distinct components to templating which are: 1) the re-use of common assets, and 2) the application of some "logic" to display dynamic data.

It doesn't matter what you use to fragment your markup (I personally think that using XPath to manipulate an XML document isn't particularly off the mark but whatever, to each their own). Dreamweaver allows you to edit common assets pretty easily and then export a ZIP with head-to-foot complete HTML documents in it. I'm sure there are a million other ways to skin that cat.

What I'm saying is that the separation between "display logic" and "business logic" either doesn't exist or at the very least shouldn't be occuring between the backend and the frontend.

You could, if you wanted to, put your "view rendering" code in some other place in your application, but that's tangential to my case for completely removing any and all logic from templates and working solely with (and iterating solely with) HTML/CSS/JS when building your interfaces.

<comment><USER4> Personally I'd never use it because I intensely dislike the syntax of HTML and CSS and avoid it at all costs since discovering HAML/sass.

I find a text editor (vim in my case)/photoshop + haml/sass + live reload to be my most productive workflow, one screen for the text editor, one screen for the browser, when I save the browser reloads the page.

For me there are a lot of things that just work smoother by having the data populated, when I work with designers I just take whatever they give me (sometimes just a PSD) and work with it, if they need static HTML/CSS I just use wget/save as webpage to save the html and assets.

</comment></comment></comment></comment></comment><comment><USER5> Templating by manipulating the DOM is one of those bad ideas that just keeps on turning up. At first glance it seems like a eureka-moment flash of purity, but the practical realities of it are pretty horrible.

For any change to the page more complex than tweaking copy or maybe changing an element (a ul to an ol for example) you'll have to update both the HTML and the DOM manipulation code - killing your separation of concerns.

Even worse, you have to have a complete understanding of how what the DOM manipulation code does before you can edit any of the HTML at all - <USER2> you might accidentally kill the page by changing the order of two seemingly unimportant elements, or deleting an unused div.

You'll also be forced to make all sorts of compromises in your markup to accommodate the templating layer, which will drive your front-end engineers crazy.

Finally, there are extremely useful aspects of regular template languages (like template inheritance and includes) which don't map at all neatly to a DOM manipulation engine - so you'll probably have to compromise on those and end up inventing your own weird attribute-driven template engine.

I'd suggest approaching this idea with caution. There's a reason most popular template engines are designed the way they are: practicality beats purity.

<comment><AUTHOR> Actually, my suggestions is just to encourage template implementation and refactoring with impugnity. There are perhaps ways of refining workflow to ensure that ids and classes are perhaps changed less than other aspects of the markup and used as hooks to "animate" the templates, but any time lost fixing broken templates as a result of an incompatible change pales in comparison to the time spent going back and forth between designers and developers to fix a problem where the scope happens to fall in between 2 skillsets (particularly when dealing with people in different timezones).

<comment><USER5> I remain skeptical, but I'd love to hear about a collaborative project that used this technique succesfully

<comment><AUTHOR> Yes I have to put my money where my mouth is. I'm thinking the best way to do this will be to take a relatively simple application and have it built entirely through outsourced labour, then I can publish a more objective (and factual :) assessment of the merits of the method.

</comment></comment></comment></comment><comment><USER6>
      > As soon as I'm looking at more than one programming or
      > markup language in the same file, I'm looking at
      > spaghetti code.

By this definition the following is 'spaghetti code':

      $dbh->do("delete from my_table");

Following his logic:

      1. Realize there's SQL and Perl in the same line.
      2. STOP EVERYTHING
      3. Start attempting to fully abstract SQL into Perl
         so that no one will ever need to write a line of
         SQL again.
      4. Die an old man, never having accomplished this task.

<comment><USER7> I've actually seriously considered keeping all my SQL queries in their own files, and reading them into local variables on load. It would allow them to be tracked and edited individually... but I now use an ORM.

<comment><USER8> > .. but I now use an ORM.

"ORM is an anti-pattern": <http://seldo.com/weblog/2011/08/11/orm_is_an_antipattern>

<comment><USER9> Agreed ORM's are usually very sub-optimal. They make sense only because application developers aren't db people. And this is the problem.

I suspect for certain parts of some apps, ORM's might work OK. But in general for applications of any complexity they will break down hard and fast, and lead to bad db design, bad performance, or both.

<comment><USER10> ORM is just less work. If you write in OOP you are already creating objects anyways. Then writing get, save, and update procedures is just a lot of extra work.

<comment><USER9> The problem is then you build databases around your ORM but if you are doing a single app database, why use an RDBMS at all?

In other words, I see an ORM as an antipattern because the subset of cases where it works really well at bridging the gap you probably don't really want an RDBMS in there anyway.

And if you do make it work (encapsulating your db behind updatable views) without running into this, it's a heck of a lot more work than hand-coding SQL.....

</comment></comment></comment></comment></comment></comment><comment><USER11> I was inspired by this project for Node:

<https://github.com/hij1nx/weld>

And I tried the concept using Nokogiri in Ruby. I found that in practice it gets really tedious. I had to make sure that every single element I wanted to manipulate had a unique id. Then I had to account for updating the content of an element versus an arbitrary attribute for that element. Or adding an attribute, like some data-* attribute. I realized why string interpolation is just so much easier.

There's also the problem where the DOM parser changes the original HTML in some way. How will it deal with conditional comments for IE? Or slightly malformed HTML that you want to keep that way?

I ended up going back to Handlebars.

</comment><comment><USER12> Instead of including if/then/else logic in the template, templates are duplicated for each branch and the logic is pushed up to the controller. This takes on hand-managing duplicate code (because there will discrepancies between the "logged in" and "logged out" version every time someone forgets they need to change two files, or doesn't notice there is a second version to touch) to avoid having any code in templates (which it labels as technical debt without support).

This does not seem like a worthwhile tradeoff to me. And the author doesn't address loops, which often want to have special treatment of first or last elements, even/odd rows, and other small bits of logic. When you combine these things, you're going to have a combinatorial problem, I can just imagine a shopping cart table with templates like shopping_cart_item_list__table_row__last_item__logged_in__even_row__multiple_quantities__discounted_item.html

And what's with the really confrontational tone? This article would've been improved by spending a couple hundred fewer words putting words in the reader's mouth and insulting their tools/code. There's a chance this could be useful in some situations, but I sure don't want to spend any time talking to this guy.

<comment><AUTHOR> Loops with special treatment for first and last items is quite simply dealt with by including a list of items (for example) in the static HTML mockup, the first and last of which is different from the middle one.

EDIT: Also in response to the issue of double handling, I did mention this in the article:

 _In that second example of course, we've got a bunch of duplicate markup, but that's not our problem. That is the job of whatever system you're using to fragmentify your templates and re-use common assets_

</comment></comment><comment><USER13> > A typical example written in PHP would look like this:

That's not how templating works, that's just some messed up code.

I totally disagree with the idea that having static HTML as templates and transforming them with DOM manipulation is better then templating. When you do DOM manipulations you make assumptions about the structure, if that structure is changed by somebody, you are screwed. The less assumptions you make the better. Also last time I checked DOM parsing was a relatively slow process, even if it would be better than templating it still has to justify the performance overhead.

Also let's not forget that writing if's are easier than writing DOM queries.

Templating allows separation of view logic and business logic, I find it much cleaner to have the view logic in the templates, this is in fact what the author complains about, but how is having both database calls and layout logic in the same place cleaner?

</comment><comment><USER14> Funny, we've been doing this with a modified-Backbone.js site and have found it requires tedious, manual management of an excess of IDs and classes, plus an error-prone mountain of jQuery expressions.

What I'd really like to do is go 100% the other way: all functions, all the time.

A view could just be a named function, accepting the object(s) to be rendered as arguments, define some closures for callbacks/event handlers, then return a DOM structure.

<comment><USER15> I've been doing exactly that in my more recent projects, and it works extremely well for simpler views/shallow DOMS.

But it turns into write-only code pretty fast when you have tons of callbacks flying around for highly interactive elements.

<comment><USER14> For one-off actions, like the "save" and "cancel" buttons, callbacks don't descend into madness. Most UIs have very few _commands_ which need true event handling. And the ones that do, the commands are often pretty simple one- button -> one-command. Sometimes many-buttons -> parameterized-command.

For everything else, you can use data-binding. If you're already writing lexically scoped render functions, you can trivially create a data-bindable local object in a variable to eliminate the event management process. Instead of an onclick event for a checkbox, you can trivially set the checked property to be equal to an observable value box containing a boolean. With the right abstractions, callback spaghetti is not an issue.

</comment></comment></comment><comment><USER9> Well, the only time I have ever said exactly this was about SQL-Ledger which used a home-brewed template system (which sucks big time) and which is mostly spaghetti code (in the true sense, of logic wandering aimlessly between modules in ways difficult to understand and predict. Of course the fact that the template system sucked and the code was spaghetti were unrelated except the fact that they were authored by the same (IMHO inept) developer.

On to the article though.... I think that what the individual is discussing in fact is something different, which is the need for stable API's between layers of the application.

I am very skeptical of his idea that all projects can benefit from his proposed solution. Indeed in areas like complex reporting, a template is conceptually simpler than HTML mockups that have to be populated by Javascript. At that point XSLT on the client starts making a lot of sense.... However, not at all sure that's always a win compared to templates. But then XSL files pose all the issues he is complaining about!

The beauty of templates on the other hand is the ability to create diverse output. XSL is no different there. One can create a LaTeX file, an HTML file, a CSV. Anything else. For systems that need that diversity, going with HTML and Javascript is a net loss.

</comment><comment><USER16> Solution: don't use templates, generate HTML from code with a DSL that makes HTML and code the same thing. There is no longer the designer/programmer separation, now with CSS designers can do everything if your HTML layout makes a bit of sense. Also there is no need to generate complex HTML as it was the case N years ago, it is mainly a semantical affair, and fits perfectly inside the code.

Templates suck, they fake an abstraction layer that actually does not exist since the code and the template are strictly connected in all the non trivial cases. It's just a lame substitution layer forcing you to switch from one file to the other while coding.

<comment><AUTHOR> I think that having a separate DSL that abstracts HTML/CSS/JS is not the answer. When you abstract HTML (or SQL or whatever) you find that eventually your abstraction basically has to do everything that the thing you were abstracting needed to do in the first place.

I think the "just use CSS" or "we can boil HTML/CSS/JS down to a subset of reusable chunks" doesn't work. It's simpler to just let these technologies be what they are, and remove the need to care!

<comment><USER16> You are right, I don't mean "abstract HTML", I just mean to provide a way to generate it from code using the same syntax of your code. This is what I use:

[https://github.com/antirez/lamernews/blob/master/app.rb#L138...](https://github.com/antirez/lamernews/blob/master/app.rb#L1388)

For instance to write

        <foo>
          <bar id="4">content</bar>
        </foo>

You write:

        H.foo {
            H.bar(:id => 4) {"content}
        }

So everything you can write in HTML you can write in this DSL, there is no real abstraction, but it is Ruby code like in all the rest of the application.

<comment><AUTHOR> Okay so now here is my problem with this: I can't just find whoever knows HTML/JS/CSS and get them to work on this by sending them a ZIP file with the interfaces in it. They have to install the environment and application and then iterate using this DSL, refreshing the page to see it in the browser.

It is far easier to find a really good designer, who knows HTML/CSS and a bit of JS (probably jQuery) than it is to find a really good designer, who knows HTML/CSS and a bit of JS (probably jQuery) and then is also comfortable configuring a Rails environment and also proficient enough with coding Ruby to learn quickly and without support or input, this custom DSL.

There are already so many people that have the skills you need, why force the issue? Let the technologies be what they are. In my experience, communication between team members is the single highest cost in building software. Unless you're a designer/developer or you're working with a small team on your startup and you happen to have all the skills you need right there in one office and timezone, you'll need to confront the issues of resourcing, iteration and staff changeovers - what I'm advocating is that we play to the prevailing skill separations and reduce the communication overhead.

<comment><USER17> Think of your HTML as being data along the same lines of JSON, XML or any other data feed. Then tell your _designer/front-end person_ to just create the necessary CSS & Javascript to apply to it.

Thus you remain in full control of the data (HTML) and you've completely separated the design (CSS) & behaviour (JS) logic that gets applied to it.

</comment></comment></comment></comment></comment><comment><USER18> Views have logic, sometimes very complex logic. If views are not allowed to have "code" in them, or are functionally crippled in some way, then presentation logic is probably going to get mixed in with the domain model, because there won't be any other place to put it. The programmer needs to have complete discretion in where they draw the line between domain and presentation.

This codeless view mythos arose because HTML includes a lot of rich interactive capabilities, and it's tempting to declare that these capabilities are all you will ever need in your presentation layer, but that is arbitrary and false.

In most other contexts, e.g. GUI programming, a codeless view is nonsensical. Code is everywhere. And if it's difficult to write nice view code, that's likely a problem with your programming language and/or your APIs.

Also, don't conflate model/presentation separation with server/client separation. Ideally, they are orthogonal concerns. To create the best UX, your views, and possibly your models, will have to straddle the network.

In short, don't let your technology stack dictate how you modularize your application.

</comment><comment><USER19> What he's describing is best realized in the Enlive templating library for Clojure. You perform a suite of transformations on regular html files.

<comment><USER17> _Push style template_ is a phrase I've seen used to describe these kind of templating systems: <http://news.ycombinator.com/item?id=2238885>

</comment></comment><comment><USER20> The moment a programmer thinks they know the ultimate solution to a problem is the moment they understand the problem the least.

No, templating is not perfect. Nothing a programmer does is perfect. Our job, as programmers, is to make stuff suck less. We break stuff until it works. We squash bugs until we can't find any more. That doesn't mean what we've built is perfect. It means what we've built is the best we could build with our current understanding of the problem.

I don't think of spaghetti code as the presence of logic in presentation code, I think of it as a lack of separation of what SHOULD logically be abstracted. I find the code it labels evolves over time as the common abstraction level of things increases and we move closer and closer to fully isolating concerns.

</comment><comment><USER21> You are plain simply wrong. First of all, logic in templates is something which is OK to have. Different templates display information in different manners. Second thing, I don't think you've seen how awful and unmaintained code which manipulates DOM instead of templating looks like.

<comment><AUTHOR> The point I'm making, though, is that the challenge of solving "maintainability of DOM manipulation code" is a simpler problem to solve than the creation of the perfect templating language.

What's more, a good DOM manipulation strategy and library can be really easily ported to any language, freeing up your templates to go wherever you may feel is appropriate in the future.

</comment></comment><comment><USER22> The main problem isn't templating engines. And although a better solution is always welcome, a bit of procedural code inside a template is not a big problem either.

The real problem is that so many projects and frameworks don't have a powerful enough View layer that is _separate_ from the (preferably optional) templating engine. In many cases it's even worse, and the templating engine _is_ the entire implementation of the view layer. This pushes a lot of view logic into the templates, where it quickly degenerates into spaghetti. (In even worse cases, any logic the templating engine can't handle gets coded inside the controllers, and view logic starts leaking through the layers.)

Fragmentation into purely static templates is only a solution if you've dealt with with all the other view-related issues, and still end up with too much logic in your templates. And by "too much" I mean that it results in errors and maintenance overhead, not just that it looks ugly.

Intensive use of logic inside templates is definitely a code smell, but you have to be careful not to address the wrong problem. The templating method itself is rarely the root cause.

</comment><comment><USER23> Yeah, well, your website sucks and doesn't load.

<comment><AUTHOR> It seems to be serving that page in around 5 - 7 seconds but it's pretty heavily loaded. Yes I wish I'd gotten around to doing all that stuff that I know I should do in order to make it load faster than it does right now.

PS: If the site didn't load, how do you know it sucks?

<comment> ichc-werker Hey dools, these two images are broken for me:

Instead of splitting up the task of templating in the following, arbitrary fashion: [broken]

We can create a non-arbitrary, completely objective separation where the view/template layer truly contains no logic what so ever: [broken]

Cool article; made me think about how I've been handling views. I think I agree with you, but I'll need to mull it over for a while. Thanks!

<comment> X-Istence He has hotlinked to ditaa.org and that server has fallen over.

<comment><AUTHOR> Yeah unfortunately - I didn't actually mean to do that. I don't even have a cached copy of those images :(

</comment></comment></comment></comment></comment><comment><USER24> But now aren't you putting design into logic?

<comment><USER25> At first I thought this (and even typed out a long explanation of "the reason why you cannot make the assumption that your resulting document will be manipulated with DOM" involving "what if you want to change the presentation layer to PDF"), but then I realized that nowhere did he advocate mixing the DOM manipulation into his other logic; it could just as easily be a completely separate pile of "presentation to HTML" code that was entirely unrelated to the "generate content to present" layer.

<comment><USER24> Hmm. I do understand what you are saying, but in most cases where you are outputting HTML, how is this really different from using templates? I see templates as a way to reduce redundant code. The examples on the blog post are simple (e.g. removing a node, which is easier with 'if' statement), but it will probably be messier.

Regarding alternative formats like JSON or PDF, I guess you can add a layer there.

<comment><USER25> First off, let me be clear (as I'm concerned that your bringing up this unrelated "messier" argument is the beginning of me being used as a proxy for the author): I am not generally arguing in favor, I was simply countering that specific argument against. I will now describe why they are different, but I do not want this to be taken as a defense of the method.

The way it is different is that it is an inversion of control inside the template, not that it is changing up the layering. You still have a "construct data" layer and a "present data" later, and you can still swap out the "present data" layer with something unrelated, such as a normal template engine or whatever else you wish to use to generate JSON or PDF.

However, inside the "template", rather than having HTML with embedded logic (where you can almost envision the HTML calling into the logic to insert text or execute flow control at specific points), you instead have logic that manipulates the HTML via DOM, modifying the HTML to contain text at specific points. You could probably even make a compelling argument that these are duals of each other.

</comment></comment></comment></comment><comment><USER26> I've been thinking about some of the ideas in this rant for a while now. I might not have put it in quite such an opinionated manner (templating systems aren't usually my biggest problem), but I pretty much agree with a few things:

1) Fragmentation is a problem, particularly with some templating systems. Layouts should almost always be a single file. Things going inside the layout should probably be single files.

2) As long as templating means sprinkling extra tokens to process throughout a document, there's going to be some coupling problems. Transforming a document based on some external criteria is an interesting alternative.

There's certainly a number of transformation based solutions out there, some of them pretty powerful. But as I was thinking about this a few years ago, it occurred to me that maybe I don't want a powerful uber-transform set so much as I want a simple descriptive set of semantics for _addressing_ content into nodes of a document.

Then I thought about where I'd seen this kind of thing come up before in the realm of document styling: DSSSL and XSLT vs CSS. The simple descriptive CSS won out and has worked out more or less well.

So... I came up with something I called `CAST` (Content-addressed Style Templating):

<http://weston.canncentral.org/web_lab/CAST/about.html>

Basically, you use a subset of CSS selectors (or XPath queries) to pick out a node of a document, then you specify a content rule, and the engine drops a content string into the document node.

I ended up writing my blog around the idea. I ended up being pretty happy with a very simple set of rules, despite the fact that there's not much too the system beyond that -- for example, there are no rules for conditionally hiding a node based on whether or not it's needed, no rules for repeating certain nodes. I think those things might be nice, but it turned out if I was willing to push a _little_ bit of the view down into model layer, I didn't need them at all, and I was (I kindof tend to think that any application is going to have a bit of model-view bleed-across anyway, you just have to figure out how you'd like to manage it).

If anybody's curious, this post made me get off my behind and put the code up on GitHub:

<https://github.com/westonc/CAST/>

But it's in PHP, which I suppose will probably turn off a lot of the cool kids, so I should probably write a Ruby or Clojure version. :)

<comment><AUTHOR> Yep this is pretty much the idea. The key thing is, though: however you do it on the backend, that's entirely a coding problem. DOM manipulation sucks? Well, solve that problem, which is where something like your CAST library comes in.

It's easier to solve the problem of making a nice, easy way to "address" content (I used "animate" but basically they're the same thing :) than it is to solve the multitude of problems caused by choosing a technology stack and creating templates in it for your application.

<comment><USER9> To be clear, the primary use case here is in a case like Etsy, right? This doesn't work so well when we want to have a consistent interface to create HTML, PDF, CSV, XLS, and ODS files, correct?

Presumably DOM manipulation really can't be done beyond applications which are HTML-only in any reasonable sense without getting back to the things you don't like about templating, right?

<comment><AUTHOR> Well, the thing is that if your target output isn't HTML, then you wouldn't need to do any DOM manipulation. You'd just output whatever else it is you want to output (JSON, XML, PDF, whatever).

If you had, for example, a bunch of PDF code as a "template PDF" then you might just load that and do string replacement on whatever placeholder text you have in there - but yeah the primary use case I'm thinking of is in implementing web based interfaces.

<comment><AUTHOR> Sorry einhverfr I can't reply to your comment - but what I think you're talking about is trying to abstract display for HTML, PDF, LaTeX, whatever into a common markup language or template, then repurpose that markup for each output format. Does that sound correct?

So like, you'd want to be able to have something like:

      <article>
            <title><% print article.title %></title>
      </article>

then do something like:

      $tpl->article = fetchSomeArticleFromTheDb()
      $tpl->output('template_name',Format::PDF)

My argument to that would be that there's no realy need for that abstraction - you don't gain anything by it because you have to have some abstracted output engine that is capable of doing that HTML can already do, which is like, HTML :)

Hey, I'd love to continue the discussion, but I think the HN comments are kind of limited in how much they want you to discuss here, feel free to email me email@example.com

EDIT: oops, code formatting

<comment><USER9> Just to be clear, I am not entirely hostile to the idea here. I just think that there are plenty of cases where generating high quality printed content or the like doesn't work with it and templating is a lot cleaner in those environments. And when your application already requires templating for a reason like that, adding an entirely different way of handling another output format adds needless complexity.

One of the useful applications of dools' ideas is that you could have a mockup which included lorem ipsums or other dummy text. This would make it easier for web developers to test layout.

OTOH, as I say, I am not at all convinced that it is a net win for programs that generate multiple formats of output./

</comment></comment></comment></comment></comment></comment><comment><USER27> The idea of templating as a separate activity from coding is what, in my opinion, is wrong. It comes from the days when "front end" guys didn't want javascript or "back end" logic in their files. Personally, I would just prefer that the code _for_ a button be located _with_ that button. Crazy, I know.

Back in the day (2001) I didn't understand the separation of logic and presentation, although I grudgingly admitted that the front end guys had a lot of stuff to worry about that I didn't understand (cross browser issues, rendering issues). These days, with jquery and widely available standards compliant browsers, plus all the design resources available on the web, we should all be both front end and back end developers, to a greater or lesser extent.

So we should strive to have clean code, but that, IMO, doesn't have nearly as much to do with separating concerns like templating and application logic as the "pure-templates" guys think.

I disagree with the "pure-model" and "pure-controller" guys on the back end for the same reasons. They fall into the same platonic manichaeism: the world is a mess and if only The One Pure Way were followed, we'd be good. Instead, grouping things logically as best we can and trying to minimize spooky action at a distance ("where the _hell_ is the code associated with this button coming from?!?!") should be the goal.

</comment><comment><USER28> I agree that putting code in templates can lead to spaghetti. But the OP's proposed solution seems suboptimal because loosely coupling the template to the application code via "template animation" will lead to convoluted code with lots of hardcoded IDs on the application side, and brittleness on the template side because there's no way to see which IDs are used by the application.

A less extreme but more practical solution would be to disallow code in templates by making templates accept a data structure, like JSON, and giving them the bare minimum of capabilities to render it. So looping over an array is okay, checking for the existence of a property is okay, but querying the database from the template is impossible by construction. This way you also get language independence because many languages can generate JSON. Also, you can have compile time error detection (for both the template and the application code) if you use some sort of schema for the data structure, like Thrift or Protocol Buffers.

</comment><comment><USER29> I always get entertained reading the latest stories about templates and the latest innovations on how to make web sites work, and how (language x) is so old now, and everyone should use (language y) because it's more logical. I built my own custom CMS in 2008 and have been slowly improving it, and to this day I have a full dynamic site working on less than 600 lines of PHP, HTML and JavaScript. No JQuery, no need for a dozen includes, or keeping up to date on the latest patches of 12 different code bases. Yet the site keeps chugging along, even got to the front page of HN without any issue handling the load, while some sites mysteriously go down, but it's never the developer's fault, they just had a problem with their backend db server, or forgot a critical patch, or ne of their libraries didn't behave well with another library under heavy load...

Not sure what my point is, I guess that there's something to be said for keeping it simple, and not chasing new technologies without reason..

<comment><AUTHOR> Glad I could entertain :)

</comment></comment><comment><USER30> This approach reminds me of hquery (for Ruby on Rails) by choonkeat:

[http://blog.choonkeat.com/weblog/2008/10/hquery-an- unobtrusi...](http://blog.choonkeat.com/weblog/2008/10/hquery-an-unobtrusive- server-script-implementation.html)

<https://github.com/choonkeat/hquery>

<comment><AUTHOR> Yes! In fact, in the Q&A he even says this:

 _Nope. "hquery" is just a library I wrote to do USS in Rails. I believe any language / framework can have its own USS renderer._

I'm totally in agreement on this. Any language or framework can address this very simply - we don't need "one to rule them all".

</comment></comment><comment><USER31> So, he's trying to rewrite XSLT. Gotcha.

</comment><comment><USER32> Been working on something like this for a while and nearing a big push of version 1 to github. Glad others feel the same way!

<comment><AUTHOR> Make sure and post about it when you do - I definitely want to see more momentum around this and was pleasantly surprised when I saw that solutions already existed. My favourite thing about it is that it transcends "technology". The fact that you've been working on this is no loss to someone else who's been working on something similar as the cost of changing from one solution to another is so dramatically low when all the value is retained within the templates themselves.

<comment><USER32> Likewise. Two other template engines you might be interested in are Knockout.js (<http://knockoutjs.com/>) and the template engine from the Lift web framework. Both play relatively well within HTML.

And Stanford has done some nice work on segmenting the DOM into semantic chunks. The site appears to be down now, but it's usually hosted at <http://bricolage.stanford.edu/>. Check out their paper on the "Bento" algorithm.

<comment><USER33> The lift book is worth a quick look if you are interested in templating engines. In short, instead of logic in the view, css selectors are used on the server side to transform small chunks of the website in a statically typed and safe (the dom structure is carried around as xml instead of a string which makes it possible to prevent most of the common security problems on the web) way <http://simply.liftweb.net/>

</comment></comment></comment></comment><comment><USER34> I've talked about "template animation" (or "mockup-driven development" as I've called it) before, but focused mostly on how to achieve static files that can easily be opened in the browser (without any server components) and still be modular (layouts/partials): <http://timelessrepo.com/mockup-driven- development>

This article seems to solve modularity by splitting it out into different files. On the same page you can have dozens of modules that can have several different states;how are you supposed to combine them all? How do you say "this page contains a sidebar, a blog post, comment section" and that there should be a "new comment"-form if the user is logged in and "delete"-links if the user is a moderator? In the example in the article, it seems that would be solved by having blog_post.html, blog_post_logged_in.html and blog_post_moderator.html, where 90% of the content in the files are duplicated.

Beside, in the example templates you can't actually open the templates in a browser (because it only contains the content, not the stylesheets, script- tags etc. that you need). So if the designer wants to see how it actually looks, he still needs a server that can wrap the layout around it.

Okay, but maybe you don't need the "view this template without running the server"-requirement. I'd still argue that dools' current approach is brittle. The reason is that he's now tying together two layers (the template layer and the animation layer) and there's no easy way to see what the animation layer will actually do. This means that small changes in the template might invalidate the animation. You really don't want to re-write the animation just because the designer switched from <h3> to <h2>.

This problem is easily solvable though: Use custom attributes which doesn't conflict with HTML/CSS:

        <form>
          <dl class="error" id="whatevsError" animate="error">
            <dt>You have to do something about this</dt>
            <dd>The reason we ask you do do this is so that we can laugh all the way to the bank</dd>
          </dl>
          <dl>
            <dt><label for="whatevs">Whatevs:</label></dt>
            <dd><input type="text" name="whatevs" id="whatevs" /></dd>
          </dl>
        </form>

However, as you're adding more features to these attributes, you'll actually end up with _another template language_ ; it just happens to be encoded in HTML/XML. From here on we might wondering, why should we "hide" the logic inside attributes (where it can be easy to miss) when we can use a more distinctive and effective syntax?

To summarize:

\- If you want to separate the template and the animation (so that you can easily change the template without updating the animation) you need to stay away from HTML/CSS-semantics and use custom attributes/tags that you know won't conflict.

\- If you use custom attributes/tags you've essentially created another language which deals with the logic for you.

\- If you don't care about the "view the templates without running a server", you might as well use a completely different syntax (which probably is going to be easier to understand than the "hide everything in the DOM"-approach).

<comment><AUTHOR> These are great points, and I certainly agree that some convention is required in template development to ensure "less brittleness". I think it's simple enough to do this with ids and classes, though, and even when it _does_ break, the time it takes to fix it is going to have a pretty trivial impact on your overall project because the problem is solvable, quite simply and without much hunting around, by one person without the need to communicate with anyone else on the team.

Regarding the logic issue, I don't think you'd realistically end up with an intractable number of logic variations. If you have extra links that are there when the moderator is logged in, they should be there in any template with that structural element in it and then removed if the person logged in isn't a moderator.

Granted, though, I have to put my money where my mouth is and port one of my existing applications over to using this methodology (which is, in fact, what I plan to do so the proof the pudding will be in the eating).

Regarding the issue of "viewing the template without a server" - in the case of Fragmentify, all the frontend dev needs is the standard apache/php that ships with OSX. This is considerably less complex than having an entire framework/application environment installed and kept current. That being said, however, the _way_ in which templates arrive at the "animator" is not the animator's problem. Dreamweaver lets you edit common assets and then exports head-to-foot complete HTML files in a ZIP, so just use that. So long as the "animotor" has complete HTML files to work with, that's all that matters.

<comment><USER35> You're assuming the breakage will be something obvious and clearly visible. No doubt many of them will be.

However, I would foresee plenty of breakages in obscure or not immediately apparent places which may not be noticed for some time. For example they may be minor (yet still very annoying for users stumbling on them) or apparent in only certain circumstances.

<comment><AUTHOR> Well - that's kinda what testing is for. It would remain to be seen whether or not this proves to really be the intractable problem you're imagining it to be - let's not forget that any other method will also produce bugs. The question is whether they're produced at the same rate or not. I have no evidence to really say whether or not what you're imagining would be prohibitive to using this method but my (strong) opinion is that it wouldn't be (time will tell as I put this into practice though, and I'll be following up with more posts about it).

</comment></comment></comment></comment><comment><USER36> This is so confrontational, I couldn't even read it. Stop putting words in my mouth.

</comment><comment> X-Istence I've been waiting about 4 minutes for his web server to send me down the bits for the site.

\---

Your hotlinks to ditaa.org seem to be down because the server on the other end is serving stack traces ...

</comment><comment><USER37> Having to loop through arrays to translate data into html elements is the majority of the problem. I'd be happy with just a solution to that.

</comment><comment><USER38> Isn't this all the same?

<span><?=$salary?></span> <span>{{ salary }}</span> <span id="salary"></span>

<comment><USER39> There is one important difference: the server-side templating engine will probably retain the _id_ attribute in the last case, meaning that the templating information remains usable also on client-side.

We use RDFa for somewhat similar purposes.

</comment></comment><comment><USER40> Isn't this 2011 where web pages use Ajax and contain a lot of logic, because.. well.. Javascript and stuff?

</comment><comment><USER41> its a little more like native software's gui. that is, with website templating, its, well, template driven. pieces of codes are here and there in the template, following template's will.

with software, your app is code driven. the gui follows what the code tells, instead.

even if in both cases you have a mvc these days.

</comment><comment><USER42> Sounds like he wants Pakyow: <http://pakyow.com>

<comment><AUTHOR> Hmm not really. I mean, what I want is HTML/JavaScript/CSS and then absolutely anything I choose on the backend. The framework is completely irrelevant. The fact that there is an "itemprop" attribute in the Pakyow view construction already invalidates it as an option for achieving what I'm putting forward here.

</comment></comment><comment><USER43> I hate templating. There are just so many engines to choose from and you end up writing your own because none of them can do what you really need.

<comment><USER21> What are you building there? A nuclear reactor?

<comment><USER9> Probably a web-based one at that.

<comment><USER41> Show HN: our HTML5 nuclear reactor.

Oh dear. "BUT, ITS SANDBOXED ITS OK!" :)

<comment><USER9> Only functions properly on worstations powered by Intel Unobtanium Chips ;-)

</comment></comment></comment></comment></comment><comment><USER44> An article without a byline has zero credibility.

</comment><comment><USER45> They guy is wrong thinking that business logic does not exist. Then it all goes downhill from there. Extremely narrow view of the world he does not even try to uderstand.</comment>


Google to customer: Go fuck yourself. In the cloud. - <AUTHOR> http://www.zeldman.com/2013/03/18/cloudtastrophe/

<comment><USER2> Sounds like he needs to get himself an SPF DNS record (assuming his email is at the linked domain).

Yes, his situation sucks, and it's also bad that seemingly no-one at Google cares (though as was mentioned in the comments there, they do have phone + email support for paying apps customers). It doesn't really sound like Google's fault or problem, because raising whatever limit they have on his account won't fix a problem with someone presumably using his misconfigured domain to send spam, triggering the limit in the first place.

Of course, that doesn't change the fact that Google really doesn't seem to value customer service.

</comment><comment><USER3> Lame blog post. Totally wrong, and the user didn't go far enough to solve his own problem. px1999's reply about SPF/DKIM setup should be looked at. If that doesn't work, you can contact google and let them know the problem.

"The Cloud" as a robot that can't be interfered with by the operating company is a stupid notion. If that were the case most cloud and SaaS companies would go out of business because they'd never be able to fix problems that come up. Most systems can be looked into, and can be tweaked in numerous ways.</comment>


Entrepreneurs Find Gold in Gadget Startups  - <AUTHOR> http://blog.wired.com/gadgets/2009/03/changing-econom.html <comment><USER2> One problem I see is that most gadgets could just be replaced by a modern mobile phone. For example the fitness thingy from the article: what does it do that an iPhone app couldn't do with a nicer interface? Same for internet radios - an iPod touch is just 200$.

</comment><comment><USER3> "Today with a guy or two, a good idea and about $1.5 million you can get a contract manufacturer in Asia to do your gadget."

So probably not very easy with only a few thousand in investment, but I guess somewhat reasonable.

<comment><USER4> It's possible to mock up a hardware design in software (just look at console emulators). That gives one a cheap way to demonstrate ideas that can be used to attract investors. Plus, the software version is a useful platform for testing new ideas and identifying hardware bugs.

If your hardware idea is radically different from any existing device (rather than using software to make the hardware unique), you can still use physical models to simulate actual mechanical inputs (like accelerometers). Otherwise, you can just find an existing hardware platform and hack it to run your software.</comment></comment>


A 72 hour review of OnStar - <AUTHOR> http://technocracycheck.blogspot.com/2009/07/72-hour-review-of-onstar.html

<comment><USER2> nice review

</comment><comment><USER3> The review is nice as far as it goes, but given the tech bent of the author I'm a little surprised he isn't the least bit leery about turning control of his car over to somebody else.

All your movements can be monitored. Accidentally park near a crime scene last week? They can unilaterally disable your engine until the police have had a chance to interrogate and clear you.

Not scary enough? Envision your own nightmare, perhaps starting with a crook driving behind you and forcing your car to a dead stop, having broken the communications protocol.

I think the potential downside risks well outweigh the known benefits. To paraphrase Inspector Renault, it's the paranoid in me...</comment>


Make a Backup of Yourself Using Bitcoin and Spread Your DNA Across the Globe - <AUTHOR> http://genecoin.me/

<comment><USER2> OMG! Now I can be immortal and rich all at once! I AM MONEY</comment>


Ice cycles: the northerly world cities leading the winter bicycle revolution - <AUTHOR> https://www.theguardian.com/cities/2016/feb/12/ice-cycles-northerly-world-cities-winter-bicycle-revolution <comment><USER2> Plainly put: cycling in snow and rain and -10° C is not a big deal, once you are used to it. The trick is to start in summer, do it every day and just never stop for any weather, e.g. for your work or uni commute.

Obviously you need something that protects you from occasional rain or at least some dry and clean clothes to change into, but apart from that, the seasonal change will not be harsh. It is usually gradual, and yes, you will at some point want to wear gloves, and long pants, at some point even long underwear (or specific biking clothes), but it is never suddenly cold. Actually you become less sensitive to the cold overall. At least that was my experience.

To be fair, I stopped doing that a few years ago, since not having a shower at work makes slightly longer commutes uncomfortable with co-workers and clients, obviously. And I became more and more afraid of my laptop in my backpack, because yes, you will get wet, your stuff will get wet, you will slip on snow, etc.

<comment><USER3> Is it worth it to get bike snow tires, the ones with knobby studs, for the snowy months, or do you simply get used to the unsteady ground after a while?

<comment><USER4> It depends on how much snow you get. Normal tires are fine on snow once you get used to it. So if you have icy conditions just for a few weeks, it's probably not worth the hassle to switch. (I've been riding a road bike throughout all winter for more than a decade now. Riding on snow is fine. The only dangerous situation in winter is actually on warmer days without snow, where one doesn't expect anything, but when the road has frozen over invisibly in some dark corner.)

<comment><USER5> As a guy who has commuted by bike for the better part of 20 years, I leave my bike in the house and drive in my car when it's snowing or icy for the same reason that I wouldn't drive a motorcycle. Two wheels in those conditions is just dangerous. Watching the die-hards in Portland slide out and eat pavement on icy roads is humorous every year. While there was a time I relished the adventure, I'm just too old for that kind of risk. I suppose I'd be more comfortable with a 3/4 wheeled bike, but there's still the risk of other car drivers bouncing off you, which they do a lot in Portland in the winter.

<comment><USER6> It's best to leave the bike in the cold in freezing months, frequent thawing/freezing will result in water condensing in your cables and elsewhere and then freezing.

</comment></comment></comment></comment></comment><comment><USER7> One of the chief problems of transportation during winter is "How do we minimize accidents while half a meter of snow has fallen within a 12 hour period?" The problem is two fold: roads become slippery, and as they are plowed, the sides of them fill up with snow, reducing lane size.

Without dedicated bike lanes, a reduction in lane size is bad enough (it is hard to share the roads when there is no road to share). Add in drivers trying to swerve around bicyclists (a really dangerous action on icy roads), and you have a recipe for accidents.

As this article points out, advanced planning is key. But convincing Canadians (in places like Manitoba), who have very low population density and very far stretches of road to build/maintain, to sacrifice infrastructure dollars for bike lanes would be a tough political move. Finland is about half the size of Manitoba and has 4x the population. That's an 8x spending advantage in terms of roads!

Europeans have a much easier time with infrastructure than Canada (and the US to a lesser extent) because of significantly higher population density. I know I'd love to have European-style infrastructure, but it just isn't practical.

Personally, I wouldn't feel safe riding a bicycle in the winter. Not with our roads.

<comment><USER4> You know what happens to many bike lanes in winter around here (Germany)? The snow from the road gets heaped on them... It's usual for people to ride on the road then.

<comment><USER8> Much of Scandinavia (at least Denmark and Sweden) manages this by having small snow-removal vehicles specifically for bike lanes: [http://www.copenhagenize.com/2010/12/ultimate-bike-lane- snow...](http://www.copenhagenize.com/2010/12/ultimate-bike-lane-snow- clearance.html)

In fact in Copenhagen at least the bike lanes are cleared much more reliably than the road. The city owns many more of these bike lane snow-removal vehicles (which are small and fairly cheap) and only a few of the big road- plowing trucks. Salting the bicycle lanes also takes less salt, so tends to be done more readily.

</comment></comment></comment><comment><USER9> Just as cars would be useless for much of the winter if roads weren't maintained, well-maintained bicycle infrastructure works just fine in the winter.

Sensible clothing, just as one needs to walk or ski, is all one needs to bike in the winter. Studded tires can make up for defects in infrastructure maintenance.

And having sunny outdoor time midwinter is decidely good for my mood— people pay thousands of dollars to take ski vacations, after all.

</comment><comment><USER10> Winter biking is better than summer -- you can add layers to get warmer in winter, but never subtract to get cooler in summer. I've year round commuted for years in Boston. I am seeing more and more people ride all year. It's awesome.

<comment><USER11> I cannot agree more. I took a lot of wonderful bike trips this february when I had some free time, and the conditions were great because you cannot really get too hot. And to be honest, that not many other bikers are around makes it even nicer ...

</comment></comment><comment><USER11> To be honest, I think that riding in fresh snow is actually the best kind of riding you can have, and sometimes have been taking a longer route to work or home just to increase the joy of it (in traffic free areas). I also have the feeling that I am actually safer on two wheels plus two feet than just walking in icy conditions although one obviously has to be a little more careful. The only bug nucance about winter is melting, then it really sucks and I trie to get the shortest, driest path possible.

</comment><comment><USER12> I never heard of Oulu before so I did a bit of research:

Avg temperature -14c in Jan to 19c in July.

Avg precipitation 19mm April to 65mm August.

Avg windspeed <10mph year round.

UV index +4 in July (50% cloud cover).

Terrain: small and flat.

Conclusion: a tiny, flat city with cool, yet mild weather is a good place to ride a bike year round.

[https://www.worldweatheronline.com/v2/weather- averages.aspx?...](https://www.worldweatheronline.com/v2/weather- averages.aspx?q=oul)

[http://www.oulu.climatemps.com/](http://www.oulu.climatemps.com/)

[https://www.google.ca/maps/place/Oulu,+firstname.lastname@example.com,25...](https://www.google.ca/maps/place/Oulu,+firstname.lastname@example.com,25.51345,12.17z/data=!4m5!3m4!1s0x468032a8c02185c1:0x8bb02d322b12e97d!8m2!3d65.0120888!4d25.4650773!5m1!1e4)

</comment><comment><USER13> When I was a grad student I would ride a mountain bike up the hill to Cornell in Ithaca. I was more sure footed in the snow & ice with the bike than I was on foot, even using a martial arts collected run.

On a really bad day I would take the bus, but I almost always rode my bike. Of course there was that time I rode home in a thunderstorm and was so afraid of the lightning that I didn't see the parked car that I crashed into.

</comment><comment><USER14> Perhaps the Boring Company could build bike tunnels for winter commuting.

<comment><USER15> Yes. They could open those hyperloop tunnels for commuting, when there are no vehicles coming. With some snorkel equipment everything is possible.

</comment></comment><comment><USER16> my mtb it kitted out with 2.4 (front) and 2.2 on the back (Continental Xking) 29" tyres. That's about as wide as i can go given my forks and chainstays. Except for ice-covered patches, is this a sane rig to commute in the snow? Second, accumulated snow from the plows pretty much buries the bike lanes, no? anyone have experience whether cars reasonable about sharing more of the road?

</comment><comment><USER17> I really doubt this, I think this is a bunch of young, healthy enthusiasts doing something that being young and healthy can counter. I really doubt any form of wind chill at those temperatures will be pleasant, nor will slipping and sliding over a road covered with slush and salt

I know this place has an unhealthy worship of cycling, but this is a bit ridiculous.

<comment><USER18> People have a tendency to overestimate the hassle and inconvenience of things they don't like, and underestimate the hassle and inconvenience of their existing lifestyle.

I don't bike to work nearly enough, and I absolutely love cars, but it baffles my mind how much money and hassle people expend on cars that are (to them) just a transportation appliance.

<comment><USER19> For most people on HN, the all-in cost of operating a modest car (~$12/hr [https://www.nerdwallet.com/blog/loans/total-cost-owning- car/](https://www.nerdwallet.com/blog/loans/total-cost-owning-car/)) is significantly less than the cost of their time while they're in it. And for most people, car is the fastest way to go. So I don't see how the cost is baffling to you.

Yes, some people like to multi-task their exercise by biking (although then it's much harder to multi-task your audiobooks), and yes some people have short commutes that are slightly faster by bike, and yes some people just enjoy biking. But for most people, transportation is about fast reliable transportation, and if you're on HN your time is likely worth several times the car cost.

(Obviously, people can spend a significant fraction of even large salaries on a luxury car, but that's a personal choice that doesn't have much to do with economical transportation. It doesn't make sense to tell someone driving a Mercedes that they could save money by riding a bike.)

<comment><USER20> The problem with this time=money calculation is that some people enjoy riding their bike, just like some people enjoy driving their car. For me, the time I spent on my commute is not lost, is valuable relaxation time. If I had more time I would use it to ride my bike more :).

<comment><USER19> I explicitly acknowledged that this is an important factor for a minority of people in my comment. This caveat is not particularly relevant to the claim that people spend a baffling amount of money on cars.</comment></comment></comment></comment></comment>


Aspark, a bloated port of spark.sh in ANSI C for the enterprise - <AUTHOR> https://github.com/antirez/aspark

<comment><USER2> I don't see how he can even consider his project enterprise-worthy. It doesn't support XML-RPC and it doesn't even have an Ant build script!

</comment><comment><USER3> Now that's truth in advertising!</comment>


Saturated Fat is not the major issue  - <AUTHOR> http://www.bmj.com/press-releases/2013/10/22/observations-saturated-fat-not-major-issue <comment><USER2> _Saturated fat has been demonised since the 1970s when a landmark study concluded that there was a correlation between incidence of coronary heart disease and total cholesterol, which then correlated with the percentage of calories provided by saturated fat, explains Malhotra. "But correlation is not causation," he says. Nevertheless, we were advised to "reduce fat intake to 30% of total energy and a fall in saturated fat intake to 10%."_

It is frightening to think that such a fundamental piece of public policy is based on the "correlation is not causation" fallacious thinking.

Is there no one in power who is in the habit of actually thinking before approving actions?

<comment><USER3> Most things in the biological sciences are correlations, to be as precise as we are in the sciences, you have to point out that some relationship is correlational unless you specifically test for causation (which is unfeasible in most cases)...if you assume causation, even when there seems to be very little doubt as to the causative agent, your paper is going to get sent back to you by the reviewers (in most cases).

Add to that the fact that recommendations are based on erring on the side of caution, and that tight correlations do become predictors of an outcome, then you have a recipe for these recommendations. Nothing bad is going to happen by reducing saturated fat intake, for the most part, but there is a chance of it if intake is excessive, and in fact saturated fat intake is a fairly strong predictor of future heart incidents.

<comment><USER4> > Nothing bad is going to happen by reducing saturated fat intake

From what I've read, it depends on what you eat instead. For example, as the article says:

"a JAMA study revealed that a 'low fat' diet showed the greatest decrease in energy expenditure, an unhealthy lipid pattern, and increased insulin resistance (a precursor to diabetes) compared with a low carbohydrate and low glycaemic index (GI) diet."

<comment><USER5> Insulin resistance is caused by sugar intake (completely unrelated to cholesterol)... Arguing that in order to lower cholesterol you have to consume more sugar seems rather strange.

<comment><USER6> Although individuals did not consciously decide to replace fat with sugar in their diets, the reality is that this policy advisement lead food producers to reduce fat in their products and replace that fat with sugar -- so the practical result was indeed this. Most products that advertise low-fat have accomplished this with sugar. Sure, it didn't _have_ to happen this way, but thats irrelevant because it _did_ happen this way: their was public policy that labeled fat as the bad guy, fat was reduced (sugar increased), and these actions were applauded.

<comment><USER5> But I've seen no evidence that, that is what happened. There doesn't seem to be a logical reason as to why you'd need to increase sugar in order to lower cholesterol, so why would companies do that?

Can you point to an example food(s) that had high fat, and low sugar, and then after this policy, low fat, and high sugar... ?

<comment><USER7> Maybe to make the food still tasty. Go to your local store - check all low- fat, 2%-enters, etc. and then full milk - check the sugar content percentage. That's all... At least here in US, Los Angeles - usually it's the normal yogurt/milk (e.g. hihg-fat) that has lower sugary content (percentage-wise) than the rest. Sometimes it's quite significantly lower.

And I don't know how the whole craze about non-plain yogurt came. I'm bulgarian native, and it's "foreign" to me that yogurt is mixed with any sugar at all.

It's still yummy - you can mix it equal portions with water, shake it well - and you get a very good drink. Or make this cold soup - [http://en.wikipedia.org/wiki/Tarator](http://en.wikipedia.org/wiki/Tarator)

Or just eat it like this. No need for sugar...

<comment><USER8> I'm American and it took me until last year to learn that yogurt isn't sweet by default. 95% of the grocery store offerings are the sugary kind, and that's all I was ever exposed to as a kid, so I never noticed it. I spent years thinking I hated yogurt only to eventually discover that the unsweetened kind is really delicious. D:

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> There have been a lot of people saying this for quite awhile. Malcolm Kendrick wrote an entire book about the poor science behind our current belief that cholesterol causes heart disease. There are many others. But in the current medical environment where doctors want to prescribe a pill to fix everything and the biogen companies have enormous influence over public policy, dissent never rises above the level of a whisper.

Smoking, cocaine, stress, these things cause heart disease. Saturated fat probably isn't even a minor issue as it relates to heart disease. Every day, millions of Americans take a pill to reduce cholesterol when it's not even an issue. But don't expect that to ever change no matter how many doctors start saying saturated fat isn't the major issue.

<comment><USER5> Those with higher cholesterol have a higher percentage of heart attacks.

Doctors (in Australia at least) prescribe when your risk (calculated on your cholesterol, smoking, stress, exercise, etc) is lowered by reducing your cholesterol, and dietary restriction hasn't worked (i.e. your liver just isn't as good as it used to be). Is that not how its done in the U.S?

<comment><USER10> It's the HDL/Cholesterol and triglyceride/HDL ratios that predict risk. Check it out.

</comment></comment></comment><comment><USER4> A related pet peeve:

It's becoming difficult to find products with "all" the fat (vs "low/reduced" fat). Prime example for me: chocolate milk. It's pretty rare nowadays that I ever see anything over 1% milk used in it -- and of course the label touts the low fat formulation, but doesn't mention there's more sugar pumped in it than a can of soda.

Even if this was healthier than full-fat/less sugar chocolate milk, I'd still resent it. Chocolate milk is a treat, not a dietary staple. People should know that. Make it that way, market it that way.

But it's starting to look like it isn't healthier. Which makes the marketing more misleading and the formulation pretty ironic.

<comment><USER11> I think the biggest issue is that high (saturated) fat is often combined with high carb (refined sugars, starchy foods etc). My diet consists of high fat / low carb foods and it simply works (for me...). I've lost weight (without trying) and my energy levels are much more predictable and stable. I never watch how much I eat because my body will naturally stop be from overeating.

<comment><USER12> I found that "mentally" what worked for me was focusing on increasing fibre intake, rather than reducing sugar intake.

The effect is basically the same but I find it easier from a discipline perspective to focus on including more high fibre foods (even in "treats" and dessert foods) thank I do to "cut out" things that I enjoy.

<comment><USER13> I agree, I lost a load of weight doing this. I still eat treats but I make them with whole wheat flour and I typically reduce the sugar content as well.

</comment></comment></comment></comment><comment><USER14> About 10 years ago the journal "Science" ran a cover story called "The soft Science of Dietary fat". If you have access to back issues through a library (sadly it's paywalled), go pull it and read it. Your mind will be blown at how thin the evidence is for many dietary recommendations. We know shockingly little about how our bodies actually work.

<comment><USER15> Is this what you're talking about?

[http://garytaubes.com/wp-content/uploads/2011/08/Science- The...](http://garytaubes.com/wp-content/uploads/2011/08/Science-The-soft- science-of-dietary-fat.pdf)

<comment><USER14> Yes, that's it. If I recall there were multiple pieces in that issue about various aspects, but this was the primary one.

</comment></comment></comment><comment><USER16> I'm confused by the reference towards the Mediterranean diet being protective against heart disease, because it seems tangential to the argument presented in the rest of the article.

The clinical Mediterranean diet _is_ low in saturated fat. In one of the landmark papers measuring the effects of the Mediterranean diet on CVD risk, the "prudent" Western-style diet used as a control has 11.7% of calories from saturated fat, while the experimental Mediterranean diet has 8.0% of calories from saturated fat [1]. This diet is actually within the 10% limit the article references as out-of-date advice from the 1970s.

Another large intervention study has the calories from saturated fat on a Mediterranean-style diet falling from 13.7% before intervention to 8.0% after intervention [2], again below the 10% limit.

I am not at all suggesting that the Mediterranean lowers the risk of CVD because it is low in saturated fat. It just seems odd to use it as an example of saturated fat not being linked with CVD risk without addressing the fact that the Mediterranean diet is relatively low in saturated fat, and that intervention studies using the Mediterranean diet typically reduce the % calories from saturated fat in the intervention group.

It also seems odd to use the Mediterranean diet as an example in an article that paints refined carbohydrates as a major CVD risk factor. While the Mediterranean diet is relatively higher in whole-grain carbohydrates [2], it still includes lots of refined-carbohydrate foods (think pasta), and it introduces so many other dietary changes, particularly a vast increase in consumption of fruits and vegetables [2], that one can't assume that the increase in whole grains particularly is the source of the diet's protective effects against CVD risk.

[1] [http://www.drhirani.com/Assets/lyonfinalreport.pdf](http://www.drhirani.com/Assets/lyonfinalreport.pdf)

[2] [http://jama.jamanetwork.com/article.aspx?articleid=199488](http://jama.jamanetwork.com/article.aspx?articleid=199488)

</comment><comment><USER17> Good response to this article with, like, facts and that..

[http://theconversation.com/its-not-even-debatable- saturated-...](http://theconversation.com/its-not-even-debatable-saturated- fat-is-bad-for-you-19386)

<comment><USER18> Such a shame that the author apparently didn't read all of the linked "facts".

eg. "This cause and effect is now beyond reasonable doubt; science shows ([http://www.ncbi.nlm.nih.gov/pubmed/8043072](http://www.ncbi.nlm.nih.gov/pubmed/8043072)) that high levels of cholesterol cause arterial damage and this, in turn, causes coronary heart disease."

The linked paper and the comments to that paper disputing the findings completely contradicts the author's "beyond reasonable doubt" argument.

I don't have a "team" in this debate, personally I wish scientists would put their pride aside, stop the furious debating and find a definitive answer. I'm just pointing out an obvious flaw in this response.

<comment><USER19> Excellent point. It sounds like a conspiracy theory, but I find the anti-fat crowd to be chronically intellectually dishonest.

</comment></comment></comment><comment><USER20> The current post links to the BMJ press release on this topic. These links are to the full article:

[http://www.bmj.com/content/347/bmj.f6340](http://www.bmj.com/content/347/bmj.f6340)

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

</comment><comment><USER21> "Catalyst", the ABC's weekly science show, had an interesting investigation into this last Thursday [1]. Last week was Part I, which presumably means this week will be Part II.

[1] [http://www.abc.net.au/catalyst/stories/3876219.htm](http://www.abc.net.au/catalyst/stories/3876219.htm)

\---

Edit: Wed->Thu

<comment><USER21> Followup: Last week's program is generating some heat, with calls for the next installment not to be shown. The ABC plans on showing it.

[http://www.abc.net.au/news/2013-10-28/professor-says-abc- cat...](http://www.abc.net.au/news/2013-10-28/professor-says-abc-catalyst- episode-could-result-in-deaths/5050866)

</comment></comment><comment><USER22> They had me right until the end, with the quote from Timothy Noakes, who is not a cardiologist, and makes plenty of data-unsupported mistakes in his own writing, e.g. about barefoot running. It's like having Malcolm Gladwell back up your research findings.

Was this piece supposed to be science or it is entertainment-journalism? The latter, I think. (I.e. it is not the abstract of any particular research study.)

I'm not saying the anti-anti-saturated fat recommendation is wrong. I'm saying this piece is just another opinion, which adds nothing to my understanding. Obviously the vast majority of educated and well-intentioned physicians disagree with their recommendation.

<comment><USER23> Here is a transcript from a show that has cardiologists on the panel :[http://www.abc.net.au/catalyst/stories/3876219.htm](http://www.abc.net.au/catalyst/stories/3876219.htm)

</comment></comment><comment><USER24> Am I the only one to see a trend in the increasing number of articles like these?

Traditionally for centuries people in India have been consuming coconut oil, ghee, etc which are supposed to be high in saturated fats and never had problems. After globalization (1992), the food industry in here changed a lot as well. The business promotion and the usage of refined oils increased which is good for business, nevertheless not for health. These days, diabetes, heart attacks and other such illness are very common even among 20+ and 30+. The Indian food industry is one in which India (as a society) failed to nurture and preserve its rich, diverse and healthy food culture.

<comment><USER22> Diabetes and heart disease were widespread in India long before 1992. A simpler explanation, over the last century, is that Indians are eating more, and exercising less (i.e. not in the fields).

Aloo curry over white rice - nothing healthy about that, whatever oil you use to cook it in.

</comment></comment><comment><USER25> For what it's worth, my GP told me that old studies didn't distinguish regular fats from trans fats, so saturated fats got the blame for what's wrong with trans fats (which do mess up your cholesterol badly).

</comment><comment><USER23> Trusting nutritionists is like having surgery in the 19th century. Deadly.

This show was quite interesting. Makes a very similar case: [http://www.abc.net.au/catalyst/stories/3876219.htm](http://www.abc.net.au/catalyst/stories/3876219.htm)

</comment><comment><USER26> _...refined carbohydrates and sugar in particular are actually the culprits_

 _Adopting a Mediterranean diet after a heart attack is almost three times as powerful in reducing mortality as taking a statin, writes Malhotra._

</comment><comment><USER27> Coconut oil is perhaps the best with its anti oxidant and microbicide properties. More often than not, it is the lifestyle that causes health issues.

</comment><comment><USER28> or better yet, "saturated fat is not an issue"

</comment><comment><USER29> carbs + saturated fat = cholesterol

choose one</comment>