Nobody's Talking About Nanotech Anymore - <AUTHOR> http://time.com/4068125/nanotech-sector/ <comment><USER3> One of the startups that fizzled out was Nanorex, which is where Nanoengineer was made. Thankfully they were open to releasing the source code and version control repository when they decided to shutdown. The results of that are here: [https://github.com/kanzure/nanoengineer](https://github.com/kanzure/nanoengineer)

I think everyone is stuck wondering how to make the tooltips from the tooltips paper: [http://diyhpl.us/~bryan/papers2/nanotech/Optimal%20tooltip%2...](http://diyhpl.us/~bryan/papers2/nanotech/Optimal%20tooltip%20trajectories%20in%20a%20hydrogen%20abstraction%20tool%20recharge%20reaction%20sequence%20for%20positionally%20controlled%20diamond%20mechanosynthesis.pdf)

All of that was motivated by goals of making nanofactories like shown in this eye candy video: [http://www.youtube.com/watch?v=vEYN18d7gHg](http://www.youtube.com/watch?v=vEYN18d7gHg)

Because positional, precise molecular manufacturing still doesn't exist, I have been increasingly interested in using DNA synthesis (using phosphoramidite chemistry) to combinatorially build proteins that lock together in pre-defined shape based on ligand-specific binding affinities between the blocks. The Nanosystems book left out a lot of biology that can be hijacked to help out goals like these.

Long-term we might be able to coerce enzymes into creating molecular machines anyway: [https://groups.google.com/group/enzymaticsynthesis](https://groups.google.com/group/enzymaticsynthesis)

<comment><USER4> _All of that was motivated by goals of making nanofactories_

I wonder how we can hope to make nanofactories, when we don't even have a robot arm that can fold my laundry for me.

<comment><USER5> We had such arms for decades already. Just because nobody bothered to make a laundry folding product out of them doesn't mean we can't do it with a robot arm. For better or worse, many (if not most) interesting projects aren't viable as business products.

<comment><USER6> The arm is not the hard part. That is why this doesn't exist.

</comment></comment></comment></comment><comment><AUTHOR> As always Amaras law comes to mind:

"We tend to overestimate the effect of a technology in the short run and underestimate the effect in the long run."

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

<comment><USER7> Are there any specific instances which Amara poses? Neither Wikipedia nor its PC Magazine reference list any.

<comment><AUTHOR> Not that I know off. But the first internet bubble seems to be a good example to illustrate the point.

<comment><USER8> Just to flesh out my parent's point, while the internet existed and was widely available in 1995, its impact over 3 years was far less impressive than expected, but its impact over 20 years is far more impressive than expected.

The internet "bubble" is the surest sign of this. Many people thought that everyone would buy groceries via the internet by the late 90s. Grocery delivery via the internet can be a good business, but it wasn't ready 3 years after web browsers got popular. The experience wasn't good enough, the cost of operation was too high, and not enough people were there to use it.

Today though, I can speak a few sentences to a wireless black glass box I keep in my pocket, and groceries will arrive at my house in the hour. Beyond that though, I can instantly feel a tingling buzz when someone on the opposite side of the globe wants my attention. Major celebrities have lived their entire careers on the internet. World leaders converse and issue statements via a short-message public-ish broadcast system we can all see instantly. Multiple currencies powered solely by shared public work and cryptography are in wide use. Major mathematical discoveries have been made by free associations of mathematicians in blog discussion threads.

That's just the tip of the iceberg, but it's already far more profound than online groceries. The effects of the internet over decades are essentially unfathomable, but we were far too optimistic about them in the short term.

</comment></comment></comment></comment><comment><USER9> Thus is the natural course of the hype curve: [http://na1.www.gartner.com/imagesrv/newsroom/images/HC_ET_20...](http://na1.www.gartner.com/imagesrv/newsroom/images/HC_ET_2014.jpg;wadf79d1c8397a49a2)

<comment><USER10> wow. Gartner seems spot on with this. Seems like a ready-made guide for investors.

<comment><USER11> Gartner made a a while ago: [https://en.wikipedia.org/wiki/Hype_cycle](https://en.wikipedia.org/wiki/Hype_cycle)

</comment></comment></comment><comment> gene-h The interesting thing is in research at least, 'nano' is starting to deliver. We've had artificial molecular switches, motors, transistors, and other components for years but we have not been able to put them together. Now we're starting to organize these components to make 'machines' and systems. Not very complicated machines, but machines nonetheless.

A great example of this is rotaxane containing metal organic frameworks. A rotaxane is molecule consisting of a ring on a rod. Make your molecule just right and you can get the ring to move back and forth using electric charge which allows you to store bits. Recently, there has been success of organizing these rotaxanes spatially by putting them in a self-assembling molecular space frame type structure called a metal organic framework. This is getting us closer to making ultra-high density data storage that just self-assembles. Some well respected researchers(not Drexler) are even starting to seriously consider robot arms capable of moving individual atoms.

There is even a name for this sort of research: supramolecular chemistry. In short, 'nano' is coming back, it's just not going to be called nano.

</comment><comment><USER12> I feel the term "nanotech" is meaningless. Everyone piled into the term and it has became too broad an umbrella and includes what one would usually describe as "materials science", "biochemistry" and "molecular biology" among others. "Data science" feels like another similar, ultimately meaningless umbrella term.

<comment><USER13> I would totally disagree with the term "Data Science." It maybe used loosely but it certainly is more than statistics and more akin to science. Any inter discipline study has these issues.

It is science since you are taking data to answer a question. If your not answering a question or using a scientific method it falls short.

Good example is all the medical data science that has been happening in the past decade or so. [http://www.oreilly.com/data/free/how-data-science-is- transfo...](http://www.oreilly.com/data/free/how-data-science-is-transforming- health-care.csp)

<comment><USER12> I think the danger with opaque terms like "nanotech" and "data science" is they are so ill-defined that they become Rorschach tests. This is very good at attracting buy in--people see what they want to see and the get cover by joining a larger movement and get to ride the trend's growth. But then eventually everyone's doing "nanotech" or "data science" and people need to use other terms to clarify.

Data science is already much more than statistics. That's why the term was invented in the first place.

Additionally, your definition of science seems pretty lacking. Merely using data to answer questions isn't what defines science. Some questions are scientific and some are not.

</comment></comment></comment><comment><USER14> "Nanotechnology never had its Facebook."

"And while Facebook, like the most celebrated of Silicon Valley's startups, went from idea to ubiquitous product in less than a decade, most nanotechnology applications taking much longer to find a market."

Does anyone, even here on HN, think that it is really absurd to make these comparisons? Comparing Facebook with an advanced technology? Come on.

<comment><USER15> > "Does anyone, even here on HN, think that it is really absurd to make these > comparisons? Comparing Facebook with an advanced technology? Come on."

It is a bizarre comparison, but the author appears to be using it as a colloquial way to describe a runaway success, which makes sense even if the industries are not directly related.

From the limited knowledge I have on nanotech, I'd suggest the closest it's come to a runaway success so far has been in superhydrophobic coatings. If a food-safe and long-lasting superhydrophobic coating was discovered, I could imagine the market would be huge. Consider plates/bowls/cutlery that you'd never/rarely need to wash up, that could take off massively.

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

</comment></comment><comment><USER16> I went back to school to get into "nanotech". Then I quickly realized it's been around for 3.5 billion years, and promptly switched into biology.

<comment><USER5> Yeah. This is the basic point many people decrying nanotechnology as a pipe dream are missing - that life itself is _nothing but_ nanotechnology, only one that we didn't design and we don't know how to control _yet_.

<comment><USER17> Clearly it is possible to use self-replicating microscopic things (cells) to produce macroscopic objects. Life does indeed prove this.

But, you know, it takes billions-of-years evolved plantlife about 20 years to produce a simple structural element able to support maybe a thousand lbs and 20 feet long (ie, to grow a tree). We notably do not see anything in nature that does "molecular assembly" from microscopic cells to differentiated macroscopic objects in a time-scale of less than months.

<comment><USER5> Well, having already a working process, speeding it up will be easier. In nature, you don't really have dedicated nanoassemblers that do only structure scaffoldings with no other considerations - they have to support a whole organism. So when, for instance, growing a skeleton, you need it to go slow enough that the more complex parts like veins and nervous system can keep up. But if we needed biology to grow us a particular object, we can learn how to put the relevant process on overdrive and ditch the rest.

Also, even if the initial version of nanotech worked as fast as tree grows, you could still put _a lot_ of products in parallel, so for most intent and purposes, after few months of waiting, you'll be getting new copies daily. We do that a lot with traditional manufacturing today.

> _But, you know, it takes billions-of-years evolved plantlife about 20 > years..._

Well, evolution is _really stupid_ and really slow. Having brains, we can now iterate many orders of magnitude faster, so I wouldn't worry. Comparing things to evolution is comparing to the simplest and dumbest possible process imaginable that still works.

</comment></comment></comment></comment><comment><USER18> The only technology that has consistently grown at an exponential rate of doubling each year is IC/computing. It is utterly unreasonable to expect other sciences and technologies to exhibit similar growth. There doesn't exist a Facebook for nanotech because nanotech doesn't grow and scale like computational resources.

Now, if you consider nanotech as a new term for some or all of the traditional fields of materials science and pharmaceuticals, then it is bullshit to claim that the hype died out. The traditional materials science companies soldier on and continue to grow at very impressive rates (stocks returning an annual 10-30%): P&G, Dow, Du Pont, 3M, etc.

The barrier for entry for startups is too high. Forget about building a manufacturing line, running a manufacturing line for a couple of days can cost in the order of millions of dollars. It is hardly a thing that one can do in one's parents' basement or garage. That is how most materials science-y and pharma companies have all been in the business for 50-100 years or more. Naturally, the successful companies in this area will be rather few in number.

<comment><USER19> I don't know that you could measure it with something like Moore's Law, but aerospace capabilities grew at an astonishing rate at the beginning of the 20th century. From the Wright Brothers' first powered flight in 1903 to the first commercial flight in 1914 to flying around the world in 1924 to fighters and bombers and rockets in WW2 to breaking the sound barrier in 1947 to landing on the _moon_ in 1969 . . .

That sort of progress over 70 years strikes me as very comparable to the progress made in computing since the 1950s. Small wonder the science fiction writers of the previous generation thought we'd have flying cars by now!

I would expect to see such an explosion of capability in a brand new field, in a society that had a lot of resources to dedicate to exploring it. It could happen with anything we really, really cared about, I think. Aerospace and computing both saw tremendous amounts of commercial, scientific, and military research during their accelerated growth phases.

I don't know about nanotech. I'd say that sort of energy in this generation seems to mostly be going into building our society a hivemind. And I'm not gonna say that's wrong.

<comment><USER18> A good analysis of this is by Vaclav Smil (One of Bill Gates's book club guys) [http://spectrum.ieee.org/energy/renewables/moores- curse](http://spectrum.ieee.org/energy/renewables/moores-curse)

</comment></comment></comment><comment><USER20> "Nanotechnology" was originally about building "assemblers" to move atoms around and build structures at the atomic level. Then the name was take over for surface chemistry technologies, and then it was used to describe finely divided powders. Hence the declining interest in the term.

</comment><comment><USER21> I'm tempted to say, thank god, now that all the idiots are out of the way the real science can get funded, tested, and refined. But that offers up a question, does a whole lot of popular buzz really help out a field, or does it usually just turn out to be noise? Is there a measurable "actual progress" delta during times of increased popular attention and is it positive?

<comment><USER22> I did my PhD work on colloidal semiconductor quantum dots right at the peak of the nano fad. I would say that popular buzz doesn't help or hurt, it's mostly noise. Academically, we're expected to spend some time on outreach, so if your field is in the public eye at the moment it does make outreach easier.

Believe it or not, the hype among scientists was even worse than among the public, to the point of (in my opinion) hurting good science. Everyone was shoehorning "nano" into their proposals, regardless if their work was legitimately nano[1], and that really hurt the SNR for manuscripts and grant proposals.

[1] I define nanotechnology as dealing with something sufficiently small to access properties not seen in bulk materials. For many materials, restricting one or more dimensions below 100nm will lead to side-dependent properties. There was a lot of stuff during the Great Nano Hype that was claimed to be nano, but was say 500nm—that would be "submicron".

<comment><USER23> As an alternative medicine/new age wellness woo moneymaker, any product _at all_ that's labelled "colloidal semiconductor quantum dots" would clean up. (I'm thinking little colourful stickers, perhaps with a bit of glitter in a varnish suspension.)

<comment><USER22> I decided when I heard about the maple water fad that if I ever Break Bad, I'm going to sell snake oil patent medicines to the Whole Foods crowd. Walking down their alternative medicine section was… inspirational. I especially liked the colloidal silver[1].

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

</comment></comment></comment></comment><comment><USER24> I just finished "The Forever Peace", a book in-part about with the economic implications of nanotech. Using nano-forges, machines that take raw materials like carbon as input and can turn them in to diamonds, America is able to gain an extremely huge foothold.

I found it extremely interesting, and finished it in 2 days.

<comment><USER25> If you haven't already, check out "The Diamond Age" as well. Different story but deals with the sort of "idealized" form of nanotech that people dreamed of when the concept was getting a lot of hype in the 1990s (along with socio- economic conflict and plain old sci-fi, action, and adventure).

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

<comment><USER5> There's also the classic of Eric Drexler, who coined the very term "nanotechnology", "Engines of Creation". I highly recommend the read. It's very good at extrapolating possibilities and issues, though I personally don't agree with the conclusions about 'defense against nanotech attacks' outpacing the offensive capabilities.

</comment></comment></comment><comment><USER26> Nanotech "assemblers" are coming in a sense, but they got the scale wrong. They're called 3d printers and they operate at the macro scale, but they are not really any less disruptive.

As far as true nanotech goes, we've had it for about 4.5 billion years. It's called biology. You are basically made of nano-assemblers holding hands. Genetically engineered biology and "wet artificial life" are engineerable nanotech, but if you want to see Turing-complete universal assemblers in action right now go plant a tree.

In other words, I sort of think nanotechnology is a useless neologism for biology and bioengineering and I doubt that anything other than carbon-based systems are going to do much better than biology... and those are basically synthetic biology.

<comment><USER27> >but they are not really any less disruptive.

Where's the disruption exactly? Everytime I look at the 3D printing scene its a bunch of neckbeards printing Star Wars figures and other useless knick- nacks. What industry has cheap 3D printing attacked? The argument seemed to be "Oh we'll make spare parts and such," but that never happened. It was supposed to make a new market, but seems to have completely fizzled out.

<comment><USER26> SpaceX is 3d printing rocket engines, for one.

<comment><USER27> Yeah but that has absolutely nothing to do with home 3D printers that make cheap junk using plastic. We've had 3D printing, in some form or another, for decades for industry.

</comment></comment></comment></comment><comment><USER28> If someone is interested in real technical description of molecular manufacturing, you may read Eric Drexler's "Nanosystems: Molecular Machinery, Manufacturing and Computation". Most parts of this book can be read on the author's website [http://e-drexler.com/d/06/00/Nanosystems/toc.html](http://e-drexler.com/d/06/00/Nanosystems/toc.html) , and if you know how to google you can find the whole book.

The book contains a careful physical analysis of molecular machines. The technical material is unchallenged to the present day.

</comment><comment><USER29> Nanodot still exists; worth reading if you want a view of what is going on these days.

[http://www.foresight.org/nanodot/](http://www.foresight.org/nanodot/)

</comment><comment><USER27> Or memristor. By now we were supposed to have all memristor storage. At least Intel is still working on bringing it to market:

[http://arstechnica.com/gadgets/2015/10/hp-and-sandisk- join-f...](http://arstechnica.com/gadgets/2015/10/hp-and-sandisk-join-forces- to-finally-bring-memristor-like-tech-to-market/)

I guess they're calling it "3D XPoint" now, which is a shame because memristor has such a cool retro-future sound to it. 3D XPoint sounds like what a bunch of bored marketing execs would whip up over a short lunch.

While I'm at it, what ever happened to 3D printing? It was supposed to change everything, except its expensive and everything it makes looks like piled spaghetti. The resin/liquid based printing never took off and the few that did were troublesome and crazy expensive for materials.

Or that quantum computer that company was selling, except it was huge and cooled with liquid nitrogen and no one could prove it was doing quantum anything.

I'm also skeptical of the new VR fad. Yeah FPS addicts will probably love it, but grandpa and grandma aren't putting giant tissue boxes on their faces to watch a movie or skype with the grandkids.

All the cool stuff from just a year or two ago are either dying, forever in the "we're working on it" stage, or were just vaporware. Nano hype has been here from the 80s and, unsurprisingly, has gone nowhere.

<comment><USER30> You're the grandpa or grandma in the story of VR.

<comment><USER27> Maybe, but you would have said the same thing when I was skeptical of practical gaming applications of the Kinect. Now, its not even bundled with the Xbox and pretty much dead. Nintendo can't sell motion games anymore either. Four years ago this all would have been unheard of.

Be careful about buying into hype, grandson.

<comment><USER30> I'm not buying into hype, I'm simply pointing out that if your grandparents aren't willing to do something, that doesn't mean you won't be willing to do it. We're not talking about an age-dependency, but a culture-dependency. I couldn't care less about commercial VR.

</comment></comment></comment></comment><comment><USER31> Companies that claimed to be doing "nanotechnology" in 2005 or 2015 are basically fraudulent. "Nanotechnology" is a well-defined term: it means, as kanzure said, "positional, precise molecular manufacturing." Unfortunately, lots of gold-digging hucksters jumped on the term to tout anything involving small particles, extending the term to the point where it could plausibly be used to describe the process of smoking meat.

</comment><comment><USER32> Yet everyone is talking about biotech. What are proteins if not nanomachines that we actually have the tools to make?

</comment><comment><USER33> I've read a lot about graphene recently (including claimed breakthroughs [1] by IBM and Graphene 3D Lab regarding the cheap production of carbon nanotubes). Perhaps some of this tech just requires more patience to fulfil its promises?

[1] [http://3dprint.com/98086/graphene-3d-lab- patent/](http://3dprint.com/98086/graphene-3d-lab-patent/)

[http://www.zdnet.com/article/ibm-claims-breakthrough-on- carb...](http://www.zdnet.com/article/ibm-claims-breakthrough-on-carbon- nanotubes/)

<comment><USER34> Graphene is a hype cycle all of its own.

</comment></comment><comment> norea-armozel Nanotechnology couldn't come to fruition since nano-fabrication at this point in time just doesn't exist in an effective form. Having to manually assemble a complex nanomachine one molecule at a time isn't viable. Until there's a way found to make the machines assemble themselves from the simplest possible unit then we're going to be stuck with just nanomaterials which is great IMO. Nanodust has many uses and we're discovering many dangers (health hazards) now.

</comment><comment><USER35> s/Nanotech/Big Data/ s/Big Data/Machine Learning/ s/Machine Learning/Deep Learning/ s/Deep Learning/???/

<comment><USER36> s/Deep Learning/Parametric Omniscience

I hear there's at least one stealth mode startup in SV working on it...

</comment></comment><comment><USER37> With the average size of the transistors in the teens of nanometers - <USER2> is here.

<comment><USER38> Yea as someone with a PhD in Materials Science, I'd say nanotech rules everything around me. :D

<comment><USER39> Biology and medicine are walking smoothly into this territory. Organ generation seems plausible in a few decades.

</comment></comment></comment><comment><USER40> Awaiting molecular 3D printing.

</comment><comment><USER41> as someone who just finished a doctorate on nanotech and is looking for a job in nanotech, this is incredibly disheartening

</comment><comment><USER42> The Time demographic likes patient explanations, but I like quick analogies, so in that vein; do people talk excitedly about all this air we breathe?</comment>


A Comment Is an Invitation for Refactoring - <AUTHOR> http://blog.pragmaticengineer.com/a-comment-is-an-invitation-for-refactoring/ <comment><AUTHOR> I think the author makes a good point here. But I also think a comment can serve as an invitation for a new test case (i.e. Bugfix comments as he describes them).</comment>


Thinking Of Customers As Your Guests - <AUTHOR> http://52weeksofux.com/post/1087338409/customers-as-guests

<comment><USER2> The one argument goes that if you simply view your customer as a data point you tend to lose the 'customer perspective'. However, data doesn't lie, if you can augment your results with qualitative customer feedback, this is the best scenario.

This makes me think that the tool of using personas in product development might go away.

For example, this is from the Wikipedia article on personas:

"Personas are said to be cognitively compelling because they put a personal human face on otherwise abstract data about customers.

Before we had the means to collect data and easily reach certain customer segments they played an important role, but now that we have powerful analytics to measure our decisions and new ways to interact with customers I could see personas being used less often.

<comment><USER3> I think they go hand in hand. You can only treat someone as a guest if you know something about them. It is the influx of data that has given character to customers. The more data you have, the more you will build their persona.

</comment></comment><comment><USER4> If you come too close to somebody your view can be biased. This can affect you when making tough decisions which can be vital for your business survival.

</comment><comment><USER5> I guess this works if you're a good party host. I've been to some pretty terrible parties, and some terrible websites.

I like seeing where the analogy goes though. The login is your ticket, the captcha is our bouncer, etc...

<comment><USER6> The 404 is an empty closet.

The 403 is a locked bedroom.

The error stack trace is someone's vomit on your shoe.</comment></comment>


The Windows Store is open  - <AUTHOR> http://blogs.msdn.com/b/windowsstore/archive/2012/10/26/the-windows-store-is-open.aspx

<comment><USER2> I would like to be excited about the Windows Store, but I didn't want a Surface RT or a Thinkpad Yoga, so I'm pretty much out of luck for three more weeks.

For the last month or so, I've been researching all of the cool new hybrid devices that were supposedly going to launch when Windows 8 did. Now that Windows 8 is out, almost every single one of them has been delayed until the middle of November. Most of the articles I read specifically stated that the devices would be released with Windows 8. I've also seen at least 1 website that was taking pre-orders with a shipping date of Oct 26 that has now been changed to Nov 16.</comment>


IBM Announces Magic Bullet to Zap All Kinds of Killer Viruses - <AUTHOR> http://www.fastcompany.com/3059782/ibm-announces-magic-bullet-to-zap-all-kinds-of-killer-viruses <comment><USER2> I'm very optimistic and excited. But I'm also afraid. Fear isn't science and this isn't my area, but I can't think of something more dangerous for cell biology. "Whoops, it also blocks all cell reproduction when...."</comment>


Best web UI you've ever seen? - <AUTHOR>

URL and reason for your admiration please. I'm a big fan of http://hipmunk.com and http://heroku.com. <comment><USER2> New improved <http://www.w3schools.com/> is very simple but effective.</comment>


Tell HN: Get HackNews OnePage Extension for your Safari 5 now - <AUTHOR>

HackerNews OnePage Safari Extension:
http://blog.libinpan.com/SafariExtensions/HackerNews/HackerNews.safariextz
http://j.mp/hn4safari
So fat this extension just does one thing:
Provides users with the ability to browse Hacker News articles and comments without leaving the page.
It's a port from Tim Dupree's "Hacker News OnePage Chrome Extension". Thank you Tim! <comment><AUTHOR> The links are not working in the post, so paste them here again:

[http://blog.libinpan.com/SafariExtensions/HackerNews/HackerN...](http://blog.libinpan.com/SafariExtensions/HackerNews/HackerNews.safariextz)

<http://j.mp/hn4safari></comment>


Mike Bostock Leaves NYT Graphics to Work on Visualization Startup - <AUTHOR> https://twitter.com/mbostock/status/595252571658260481 <comment><USER2> From his following tweets:

 _I'm leaving @nytgraphics to work full-time on visualization tools! I'm deeply grateful for the opportunity to work with such amazing people on important (and sometimes silly) topics. I will miss you. Why? It's hard to go beyond incremental maintenance of open-source projects while publishing on deadline. Long thoughts take time. And there's still lots of room for improvement in visualization tools, particularly for discovery. Need less arcana, better interaction. Don't have the answer yet, but it's what I want to focus on. So, here I go. Adventure!_

I am excited for the next revolution!</comment>


The Last Language War / Language Trolling Post You'll Ever Need To Read (Hopefully) - <AUTHOR> http://davidrupp.blogspot.com/2007/10/last-language-war-language-trolling.html

<comment><USER2> The COBOL part made Coke come out of my nose.

The bash part was also brilliant.

</comment><comment><USER3> Lisp's closure at the end was fantastic!

</comment><comment><USER4> Haha! I loved the first comment (by innervision).

</comment><comment><USER5> I'm waiting for the day when someone cracks jokes about Lisp that don't involve parens. Still, 50 years on, I'm really not holding my breath.

</comment><comment><USER6> It's cute, in a faddish sort of way. Doesn't quite work as a troll, nor as good satire.

</comment><comment><USER7> I missed Python. :-( Assembly language would've been awesome too.

<comment><USER8> What is 'Python'? Should I've heard about him/her/it?

<comment><USER9> huh? <http://python.org/>

<comment><USER8> I prefer Pythons: <http://pythons.com/>

<comment><USER9> that's even cooler

</comment></comment></comment></comment></comment><comment><USER10> perl says, '$_="krJhruaesrltre c a cnP,ohet";$_.=$1,print$2while s/(..)(.)//;'</comment>


Tech Diets Catch on with Apple Executives, Facebook Billionaires and Googlers - <AUTHOR> https://www.bloomberg.com/news/articles/2018-02-05/tech-diets-catch-on-with-apple-executives-facebook-billionaires-and-googlers <comment><USER2> Kinda ironic that their technologies are the principal drivers of tech and internet addiction.</comment>


Significant Visualization Developments - <AUTHOR> http://engagingcities.com/article/ten-significant-visualization-developments

<comment><USER2> The MBTA visualization[1] of the Boston subway system is phenomenal; a clear homage to Marey's trains[2], a beautiful train schedule graph from the late 1800's which I first came across in Edward Tufte's "The Visual Display of Quantitative Information".

[1] [http://mbtaviz.github.io/](http://mbtaviz.github.io/) [2] [http://www.edwardtufte.com/bboard/images/0003zP-18547/VDQI_P...](http://www.edwardtufte.com/bboard/images/0003zP-18547/VDQI_Pg31.jpg)</comment>


FaaS (Feedback as a service) for startups - <AUTHOR>

As I am building ClipPod, I have noticed that it's incredibly hard to collect people's feedback and thoughts on what they think about your product - Why they did not sign up, why they discarded it within a minute of use, were they looking for a feature but couldn't find etc.
So I am offering FaaS (Feedback as a service) for free to startups. I will spend about 30 minutes on your app, use it inside out and send you my thoughts and feedback on the following areas:
1. User interface, user experience 2. Bugs and problems I faced 3. Possible competitors that I am aware of 4. Features I would like to see in future 5. Technical optimizations to make your site faster. 6. Anything else, you would specifically like me to review.
I will be taking up 1 startup every week on first come first served basis. All you need to do is send me a link to your app. Do not explain me anything about your app or product in the email - I would like to review your site just like any other visitor would do.
Send me an email on firstname.lastname@example.com with a link to start things off. Just include [FaaS] in the subject line. <comment><USER2> Emailed, great idea. Excited to hear back from you.

</comment><comment><USER3> Thanks. This is an awesome idea. Sent you an email.

</comment><comment><USER4> Email sent. Thanks for your generosity!</comment>


Atrium lays off lawyers, pivots to tools - <AUTHOR> https://www.axios.com/law-firm-startup-atrium-lays-off-most-of-its-lawyers-e4637120-27a7-44c5-8a52-37e2b0194928.html <comment><USER2> I think anyone considering a job at a company founded by a serial entrepreneur should heed this as a warning.

These founder raise pre product market fit because they can, and often raise too much money. Having too much money when you don't really have a viable product that people want can easily turn your company into a zombie, where people are just sort of going through the motions because there's nothing else to do but chug along.

I've seen it many times. Some end up eventually finding the market after a few pivots but it's really not a fun place to be as an employee with little decision making power. And the founders are usually wealthy enough at that point independent of the success of this current company that it isn't "do or die" for them which creates another layer of zombie-esque behavior.

<comment><USER3> I had the opportunity to interview with Atrium over a year ago. It was very clear that they weren't doing well. Their founding team had opposing ideas about how to do things. Their CTO was fired very early on. Clearly, it hasn't worked out smoothly. To me, it looks like they just rode on the wave of eager investors.

I've seen the issue with wealthy enough employees at all the startups I've been at too. Once you get people who no longer feel a certain hunger, they lose ambition and direction quickly. I've seen it happen as startups go from mildly successful to unicorn. Where the founders were able to cash out enough to buy a house in the bay, they suddenly were way less eager about being acquired or IPOing. And I've seen it with people who are on the tail end of their careers, exiting one startup with a very sizeable amount to enter another. The hunger is gone for them, they're just coasting, and they don't seem to have any real reason to even be working beyond avoiding boredom in retirement.

And the worst part is that it feels like these types of people are way too well represented at the top of the hierarchy. The part of the hierarchy where these attitudes matter the most!

<comment><USER4> I disagree with this, like anything else it's going to depend on the person. It's really hard to generalize when it comes to people's ambitions.

There are so many examples of serial entrepreneurs doing it over and over. Likewise of employees of startups going on to do even better in the next startup they join.

Serial entrepreneurs do get to raise more money, markets reward success, and I am with you that it's not always deservingly. I also think many startups can and do pivot and serial founders aren't more likely to pivot than the non serial kind.

I would bet on Justin Khan finding a way to success, much more so than not.

</comment></comment></comment><comment><USER5> [https://www.atrium.co/inside-atrium/the-future-of- atrium/](https://www.atrium.co/inside-atrium/the-future-of-atrium/)

For someone who has spent so much telling founders to cut buzzwords and speak in plain and simple English, this blog post by Justin Kan is something special. Case in point:

> Similarly, at Atrium, we've made the tough decision to restructure the > company to accommodate growth into new business services through our > existing professional services network.

Simple facts hidden in positive-sounding buzzwords, as if, they believe that the reader doesn't know better. It seems like a variation of 'Our incredible journey..' template

Honest question, why do companies do this? It seems disrespectful to everyone - employees (both fired and current), customers, and any adult for that matter.

<comment><USER6> >Honest question, why do companies do this? It seems disrespectful to everyone - employees (both fired and current), customers, and any adult for that matter.

generally because it keeps the person who wrote it hire-able post closure, and makes those that lost money or effort on the deal feel as if their loss is actually being spun into something else, like concepts, innovation, future profitable IP, whatever.

I agree, I think it's disrespectful, but then again there's a lot about business that I feel that way towards.

<comment><USER2> He got the same feedback on his accompanying tweet [https://twitter.com/justinkan/status/1216896251754450946?s=2...](https://twitter.com/justinkan/status/1216896251754450946?s=20)

Bigger red flag from his tweet is there's basically zero engagement from others in the tech community. For someone who is that high profile to tweet something big about his startup and get almost no responses is _really_ strange.

<comment><USER7> That does seem super strange. Any ideas why that might be the case? Most of his day-to-day tweets seem to get a pretty solid amount of interaction.

This tweet from December 10 seems pretty weird now: Justin Kan @justinkan "Early-stage fundraising: \- need a great narrative \- can get by with bad metrics \- but MUST know those metrics"

<comment><USER2> Digging deeper on Twitter there's a ton of pissed off lawyers (obviously including the laid off ones) and customers who both felt blind-sided.

The corporate legalese speak made things worse, of course.

I guess I underestimated the anger this would cause, so makes sense people are not going to touch it.

</comment></comment></comment></comment></comment><comment><USER8> My company used Atrium to help us think through some very complicated niche legal issues. We were on a flat rate plan, and it was nice to be able to brainstorm without watching the clock. We were pretty happy with their service, but it all came from one attorney, who also was the one who found us and brought us in. Whenever we dealt with anyone else there, it was disorganized and low quality. When our main attorney left, of course we followed them.

I had bought into their philosophy at first but the experience showed me why law firms have the partner-oriented structure they do. Legal work is built around trust in the lawyer in most cases and that's hard to automate.

<comment><USER9> It's always been weird to me when a law firm tells me about all the services and such they have. It's not the firm, it's the lawyer, and if they decamp, you follow. Likewise just because I am really happy with lawyer X at firm Y Doesn't mean I'm interested in Y's patent practice when I need patent assistance.

For his reason I've always been puzzled why law firms merge. You ever pay multiples of revenue; it's just literally a pro data merge with a little goodwill thrown in from one side.

<comment><USER10> Cross selling is often a major source of business for law firms and there may be rewards for successfully introducing an existing client to a new part of the firm.

<comment><USER9> Those are dumb clients! It's like assuming your developers are all the same.

</comment></comment></comment></comment><comment><USER11> > Even lawyers aren't immune to the unpredictability of working for a > startup—and the appeal of generating high margins from selling software > instead of human services.

Companies tend to do the opposite, though, right? Apple could increase its margins by selling iOS and the Ax processor IP. But it makes more "boatloads of money" selling hardware, even at lower margins. Instead of selling IP, Apple uses its superior IP to dominate the market for phones.

Its likely the issue isn't margins, but scalability. Scaling a law firm is difficult to impossible due to conflict of interest rules. That's why the largest international law firms have 4,000 lawyers while PWC has 230,000 accountants and advisors. That puts a low ceiling on how much you can scale while doing actual legal work.

<comment><USER12> Conflicts of interest rules make it harder for law firms to scale but it is possible by setting up Chinese walls ([https://uk.practicallaw.thomsonreuters.com/3-100-8763?__lrTS...](https://uk.practicallaw.thomsonreuters.com/3-100-8763?__lrTS=20181218001936411&transitionType=Default&contextData=\(sc.Default\)&firstPage=true&bhcp=1)) ensuring lawyers from the same law firm can work in parallel. Ultimately, conflicts of interest rules apply to each lawyers individually, not to the law firm.

<comment><USER11> The US has stricter conflicts rules, and typically impute conflicts to the firm, except inherently personal conflicts (spousal conflicts). Chinese walls require client consent, and some jurisdictions, like Texas, do not give effect to Chinese walls at all.

</comment></comment></comment><comment><USER13> As far as I can tell, Kan fundamentally misunderstood the nature and value of automation in the legal services industry.

Kan was quoted in 2018 as saying "The goal with the tech side has always been...to help attorneys spend more of their time on meaningful work and less of their time on crank-turning work."

Time spent on "crank-turning work" constitutes a relatively negligible portion of billable time for any attorney billing at a reasonably high rate. They delegate as much of it as possible to people who bill at lower rates, like assistants, paralegals and junior associates. So you're not really automating much of the attorney's work at all. Even if you build an ergonomic software platform for routine tasks (like Atrium's glorified Dropbox), the amount of time/money it would save over the course of a large engagement is de minimis. And if you aren't dramatically saving time, you can't dramatically reduce client costs under any fee structure.

So they end up with this software group making tools that don't help the legal side make more money. And the tools don't contribute meaningfully to the legal side's pitching for work in part because they don't save the prospective client much money. Meanwhile, the software side can't sell the tools to other law firms because the software side is tied to a law firm. Ultimately, they end up with a bunch of lawyers and software developers who can't help each other. This outcome is so predictable that it's downright hilarious they ever thought it would be a money-making strategy, and apparently the investors didn't understand or think it through, either.

What Kan mostly got wrong was thinking that automation would be _profitable_ for a law firm. There are lots of automation tools that would be extremely _valuable_ to a law firm, but that usually means you should be selling them _to_ a law firm, not _from_ a law firm.

<comment><USER14> Kan tried to sell $36k/yr fixed price legal packages as "efficiency" to early stage startups. He generated leads with bait-n-switch tactics - by pretending to be a startup accelerator with a YC-style application - afaict the accelerator did not actually exist. I will never forget that he tried to pull that on me.

</comment></comment><comment><USER15> FWIW - This was my product hunt review 3 months ago, after using them for about 4 months. Reads like a post mortem now.

All in all, I actually feel I overpaid for subpar legal services.

I will credit them with a smooth and enlightening (albeit overpriced) corporation formation, and maybe they are pearing down the product to just that - because that was the only thing that worked, IMO.

I felt as if they were taking advantage of early stage startups preparing to raise capital. You can't bill their rates and then ghost them, those are precious dollars and precious time.

"I have been trying to cancel for over a week, and more of the same. NO ONE RESPONDS FOR WEEKS! These are ATTORNEYS! Waste of money.

I've dealt with many lawyers coming from my last startup which was in a highly regulated space.

Atrium is like an expensive legal zoom, but overpriced. Understand it's cheaper to use a lawyer at any other law firm because your retainer is a deposit on future services.

With Atrium your paying $6k a year in subscription fees for "legal advice" which is otherwise baked into any other law firm, and they don't provide much advice.

They really specialize in financing, using ycombinator docs. These docs are publicly available templates. All other services are limited to their "al la crate menu"... again all templates. It takes days to get a email back from them. It takes a week to get a call setup, if they have the time, and if they will even discuss the matter.

Litigation? Find someone else

Overseas? Find someone else

Doing something outside of California like an asset purchase? Find someone else

So you basically need other lawyers anyways if you use atrium, The rest of their menu is boiler employment agreements, NDAs, and terminations - all of which are 2x local rates.

They custom quote TOS and privacy policies - and again it's all template based - and 2x local rates.

I asked them about the impact of California's new AB5 and yep, ask someone else! Save your money - don't buy the hype.

All your doing is helping VCs cover their recurring legal expenses by paying Atrium to overcharge you and build valuation based on their "tech" which is just a drop box and bad customer service, and no legal support."

</comment><comment><USER16> I worked at a company that experimented with them. We had a lot of legal spend to white shoe firms (multiple) and wanted to give Atrium a try.

They had a flat monthly rate, and then a la carte billing if you needed extra things, IIRC. The real problem was, when we needed something reviewed or worked on, they couldn't deliver on time or promise any guaranteed deadline. My CEO was very frustrated.

<comment><USER17> It's kinda like buying something that saves you money by cutting support....and then calling support.

</comment></comment><comment><USER18> I get that this shit is hard but who thinks that saying "[o]ur in-house attorneys _will shift to have the option to become_ preferred providers in our professional services network" is ok?

This is such a gross way of putting it.

This isn't a publicly listed company ffs, just say what everyone knows it means: "our startup's Plan A performed unexpectedly so some of our great colleagues, who believed in us and worked hard for up to 2.5 years, are losing their jobs, and this sucks, but based on what we all learned, including thanks to the valuable work the in-house guys did, we're kicking off Plan B today".

</comment><comment><USER19> I will always remember them for their outreach emails that pretended to be from Justin and included "Sent from my iPhone" to deepen the illusion. After talking to them - and already having competent counsel - it was clear they wanted to turn legal services into a predictable cash flow SaaS business more than they were actually solving anything.

</comment><comment><USER20> It's not looking good for self-driving cars if we can't make a self-driving lawyer.

</comment><comment><USER21> so what exactly is Atrium now? A dev shop?

        tech tools it developed for lawyers and law firm clients, and for new areas it will expand into.

This press-release feels was very shallow to me, can anyone explain?

<comment><USER22> Could NEVER understand what the heck they do and how they got $75M. Just sounded like they were a law firm specialising in start ups. Big whoop.

<comment><USER23> > how they got $75M

Justin Kan sold Twitch to Amazon for nearly $1B after 7 years, Socialcam for $60M in 18 months, and Exec for "under $10M" in 2 years.

That's how he raised $75M. The company/product was completely irrelevant.

<comment><USER24> That downward trend is a little concerning. And honestly, "under $10M" is probably a bad exit (although I don't have enough context to say for sure).

</comment></comment></comment></comment><comment><USER25> Did they prove or felt like they proved product market fit before they hired loads of lawyers? I wonder how that worked. (Serious question, not trying to be critical).

<comment><USER13> They're probably now on the long list of law firms that tried and failed at alternative fee structures. Legal services consumers have shown time and again that they like regular old hourly billing.

<comment><USER26> Can you expand on this? It sounds plausible, but then so does the narrative being pushed by the "new law" firms – that clients want alternative fee structures because they don't like the open-ended cost of time billing.

<comment><USER27> Not OP but former litigator turned programmer here. This gets very complicated because saying "legal work" is a giant generalization for a broad field. But talking about this with my peers (still a slice of the market) we arrived at this:

There are three types of legal work (exceptions, yada yada, but mostly):

1\. Normal people shit. Parking tickets and most criminal law, etc. Flat fees fine and usually nice so your clients understand (and understand their ability to actually pay your rate). Work itself can be pretty predictable, or taken on contingency for civil stuff.

2\. Line of business legal work. If you fuck this up it sucks, but rarely is it a material risk to the value of the company. _This work is usually brought in-house ASAP, to control costs._ Before that point, you see both hourly and flat fee work, mostly based on client sophistication to negotiate such things.

3\. Bet-the-company (and white collar/wealthy criminal) work. Here clients only care about one thing: WINNING. You win M/A by closing. You win regulatory work by clearing the way for profit making activity. You win bet the company litigation by....winning. The cost of legal services, even at hourly rates, are negligible compared to the profit making ability success unlocks (or unlocks the continued existence of the company, a guy not going to prison). Clients rarely give a shit what or how you charge as long as you win. They will pay whatever "winners" charge. They will only bitch about costs if they percieve themselves to not be winning.

You cant talk about this as if legal work is the same. That's probably why you percieve a disconnect as an outsider.

<comment><USER26> So, contrary to the OP, you would argue that clients _don't_ like time billing, but when the stakes are high, the price doesn't matter. That makes more sense to me than the idea that clients actually like a pricing model that encourages inefficiency.

</comment></comment></comment></comment></comment><comment><USER17> >Its goal was to improve on the traditional law firm model, by developing software to improve efficiency for both its attorneys and clients.

Any word on what they actually were doing to gain these efficiencies?

<comment><USER28> If I had to guess based on parsing these articles, Atrium went up against incentives in the legal industry and lost. [0,1]

Legal firms bill hourly. Efficiency means less billable hours.

(warning: moving into personal experience and conjecture) Yes, boilerplate forms for repetitive use cases seems like it should be a thing, but in my experience building businesses, every lawyer I have dealt with has found any reason possible to have custom documents.

It's also not clear they ever found Product/Market Fit. [2,3] > _This week Kan confirmed that the company has completed its fundraising process, raising $10.5 million_ > _as Atrium goes through its product development phase and tries to achieve product-market fit._

[0] [https://abovethelaw.com/2017/09/competition-is-for-losers- th...](https://abovethelaw.com/2017/09/competition-is-for-losers-the-rise-of- atrium-part-i/) [1] [https://abovethelaw.com/2017/10/justin-kan-answers-the- call-...](https://abovethelaw.com/2017/10/justin-kan-answers-the-call-the- rise-of-atrium-part-ii/?rf=1) [2] [https://techcrunch.com/2017/06/15/justin- kan-atrium-lts-fund...](https://techcrunch.com/2017/06/15/justin-kan-atrium- lts-funding/) [3] [https://techcrunch.com/2018/09/10/atrium- legal/](https://techcrunch.com/2018/09/10/atrium-legal/)

<comment><USER17> I wonder what the yin and yang in customer's minds are with

"Thank goodness my law firm is saving me money by generating these documents for cheap!"

And

"You know this is kinda important but I'm not sure I want discount lawyer's on this who automate paperwork...."

<comment><USER29> Most/all law firms have templates they hold internally and modify slightly for their clients. Very few billable hours are going into handing you your standard agreements like NDAs, offer letters, CIIAA, and so on. Your lawyers are really there to help you when things go non-standard, which is inevitably going to happen with any non-trivial business.

I evaluated Atrium out of curiosity when I was looking for a law firm for incorporation purposes. I filtered them out after the first call because they weren't set up to handle the slightly unusual setup I had, which other law firms had no trouble with.

<comment><USER17> Yeah I have some limited visibility to a very large law firm. Paperwork you can just script never comes up as a problem and it's not like these organizations would just duplicate effort like that if they could avoid it / save themselves money.

Also I never got the impression that the really profitable customers are shopping for those kinds of efficiencies....

<comment><USER30> "... really profitable customers ... ." I agree. If an attorney can choose their customers, they are not going to choose the penny pinchers.

<comment><USER17> Yeah I've worked enough to see companies chase budget products, customers, etc .... to see them regret it often.

</comment></comment></comment></comment></comment></comment></comment><comment><USER31> Last I heard part of the idea behind the lawyering was that it'd give valuable in-house experience to develop the tools. What changed there? Did they get a big contract with Orrick to replace the in-house lawyers?

</comment><comment><USER32> "Startup Straight Talk"

[https://pbs.twimg.com/media/EONrLRRUYAATmAp?format=png](https://pbs.twimg.com/media/EONrLRRUYAATmAp?format=png)

</comment><comment><USER33> So now they are competing with Relativity? (Chicago based)</comment>


Explore a more complete front-end testing strategy - <AUTHOR> https://medium.com/@unadlib/explore-a-more-complete-front-end-testing-strategy-e60b07cee621 <comment><AUTHOR> There are many factors we need to consider when developing a test strategy. From the point of view of correct verification based on AC, we should also consider the operation strategy, operating efficiency, writing and maintaining the cost of testing, bugs easy to find and refactoring assurance and other important factors, and should not go to extremes. In the case of ensuring a certain AC, we hope that this E2E/IT3/IT2/IT1/UT can be guaranteed in many ways to the quality of the code and the quality of the project engineering, while being agile enough for continuous delivery.</comment>


Why Class? - <AUTHOR> http://hadihariri.com/2013/11/24/refactoring-to-functionalwhy-class/ <comment><USER2> There is a fundamental point here that really bears thinking about.

Software design has as a fundamental problem being able to express yourself in a way that is clear and remains clear as things change. Basic principles of good software design, like reducing cohesion, remain good principles no matter what "paradigm" you think you're using. When you change paradigms, be aware that the basic principles remain the same no matter what label you give them. And since design is all about tradeoffs, if you are going to have to violate a principle, you might as well do it in the clearest and most straightforward way possible.

Let me give an example. A singleton is bad for all of the reasons that a global variable is bad. If you need one, I prefer to make it a global variable simply because that is honest about what design principle has been broken. (Unless I want to make it lazy - then it is easier to write with a singleton!)

So learn the principles. Figure out what they look like and are called in your paradigm. Get on with life and solve real problems.

Let me give a concrete example. I learned more about good OO design from the first edition of _Code Complete_ than any other book that I ever read. Even though it was entirely about procedural programming. Because the principles that it discussed, from how to name functions to the value of abstract data types to information hiding, all apply directly to OO. And to functional programming. And to aspect oriented programming. They are truly universal. Learn the principles, they are more important than the labels.

<comment><USER3> As someone self-teaching their way into software engineering, would you be able to suggest any resources aside from Code Complete for these principles?

<comment><USER4> Try "Clean Code" by Robert C. Martin.

But also remember that there's no one proper way of doing these things, it's all heuristics, not laws written in stone.

</comment></comment></comment><comment><USER5> I really like Hadi's criticism of OO, and in fact I would like to hijack it and take it a few steps further, to paint what in my mind is a more realistic picture. Functional programming is only _an alternative choice of paradigm_. Expert programmers will use the best tool for the job and eschew the pointless search for the _absolute best_.

Why OO? Classes exist to decouple behaviors from data. In fact, their purpose is to think in terms of cohesive sets of behaviors instead of data-driven functions.

Does this apply to any possible case? No, it's a leaky abstraction.

Why FP? Functions exist to decouple behavior from other behavior. In fact, their purpose is to think in terms of completely decoupled sets of behaviors instead of cohesive functions.

Does this apply to any possible case? No, it's a leaky abstraction.

Why AOP? Aspects exist to decouple behaviors that apply across classes. In fact, their purpose is to think in terms of orthogonal sets of behaviors instead of hierarchical sets of behaviors.

Does this apply to any possible case? No, it's a leaky abstraction.

Why Procedural Programming? To separate the functionality of the application in separate behaviors. In fact, the purpose of procedures is to think in terms of behaviors instead of sequences of operations.

Does this apply to any possible case? No, it's a leaky abstraction.

Why Declarative Programming? To express solutions in terms of goals instead of behaviors. In fact, its purpose is to think in terms of desired state, not sequences or compositions of behaviors.

Does this apply to any possible case? No, it's a leaky abstraction.

Why Logic Programming? To explore the logical consequences of given facts, instead of focusing on behaviors or desired outcomes. In fact, its purpose is to find new truths starting from given truths.

Does this apply to any possible case? No, it's a leaky abstraction.

Why spaghetti code? Wait, no that's just crap ;-)

<comment><USER6> > _Why OO? Classes exist to decouple behaviors from data._

This seems like the opposite of how it generally works. Classes tie behaviors to data. This is what people generally seem to mean when they talk about _encapsulation_ in OO — the behavior and the data are bound together very well.

<comment><USER5> If you have a datetime object you can stop thinking about the fact that it's internally implemented with e.g. ticks since the epoch. In fact, you don't care anymore what _data_ it depends on, because you only depend on _behaviors_.

<comment><USER7> That's more polymorphism than encapsulation.

<comment><USER5> I was thinking more in terms of different versions of the same library, which is clearly one of the reasons why we have encapsulation :-)

<comment><USER7> I can see encapsulation being useful in that case, though I'm of the opinion the use-cases for encapsulation don't outweigh the disadvantages it brings.

</comment></comment></comment></comment></comment></comment><comment><USER8> I think that the article uses a bad example. OO is actually really bad in db apps (DTO apps). OO shines when you are in one big continuous memory space, and don't have to worry about the data behind the objects. I see OO as a good way of abstracting the data away from the logic of your program.

This abstraction works well with classical desktop apps (lots of code, one big heap, pointers are always valid), but breaks down badly when your program is about communicating data and you start to cross memory address barriers.

A lot of modern apps are about data. You see a lot of networked apps, db apps and layered apps with different technologies in every layer, communicating with each other only through shared data formats. Such an app is primarily concerned with shuffling data around, and oo breaks down into a horrible mess. Each transition to a data representation requires a complete serialization of the object graph to a reasonable data representation and back again at the other side. This means that you essentially have twice the amount of work than if you would operate on the data directly as you would do with FP.

Once the amount of "internal juggling" with the data exceeds a certain limit, OO might be beneficial. But for data-centric apps, forget it.

<comment><USER7> > I see OO as a good way of abstracting the data away from the logic of your > program.

Why would you want to do this?

<comment><USER9> "Bad programmers worry about the code. Good programmers worry about data structures and their relationships." \-- Linus

If your data structures don't exist outside of your functional code acting on them, it's hard to reason about the data structures themselves in a vacuum.

<comment><USER7> Isn't this an argument against hiding your data structures behind an opaque object structure?

<comment><USER9> To my mind, it's an argument for explicit definition of data structures (from me, not Linus).

It seems to me that structs and/or objects do that pretty well. I'm not sure what you're talking about with 'opaque object structure'. class MyClass { member1, member2 } seems pretty transparent to me.

Anyways, I was just explaining why many people prefer to have struct/object definitions separated from the code that operates on them. YMMV, you don't have to agree.

<comment><USER7> If you're just treating a object as a map of keys to values, then it can be fairly transparent, but unless you're using a language like Javascript, where maps and objects are synonymous, objects are much more difficult to work with. It's hard to transverse them, or to merge them, or often even to look up a list of keys.

I'd suggest that a better solution would be to just use maps, at least in languages with good support for raw data structures.

<comment><USER9> "It's hard to transverse them, or to merge them, or often even to look up a list of keys."

That's exactly what I'm arguing against in my comment on making your important structs/objects and their relationships explicit. Randomly mutating them together all over your program might seem more flexible but at a cost of making you worry about your code rather than your data definitions. And that's without even getting into performance implications.

If you actually need a Map, of course, that's a different situation than the ones I'm thinking.

<comment><USER7> Using a map doesn't necessarily mean random mutation, or giving up on your type system. In languages with immutable data structures and a sophisticated type system, you can type-check the keys and values in a map.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER10> If you think of classes as namespaces and not objects (which is what they are half the time), it becomes a bit saner. Pragmatism makes the world work.

You can still write functional code in OO. Heck if it makes you feel better, you can just make a macro to rename 'namespace' to 'class' and then you can write code like

      namespace Utils {
       function thingy() {...}
      }

Namespaces are generally an improvement over globally defined functions as it lets you mix and match libraries without having to worry that you included the right header files, etc. Again, pragmatism.

<comment><USER11> Agreed. I think the problem with OOP (at least in most common implementations) is that objects (and/or classes) just do too much. They serve as complex data types, records, code modules, contracts, callback containers, etc. It's hard to grasp disparate concepts when you keep calling them the same name. Even harder to construct and explain more advanced stuff layered on top, such as various design patterns that actually make those objects useful.

<comment><USER12> Agree. I find it quite interesting how the concept of classes resp. objects has been adapted and moved away from what they really were let's say in Smalltalk (message processing entities) ... and I think this "progress" was not for better regarding the clarity of the concept.

I think this progress has to do with "type systems" and additionally with the very powerful tools c++ f.e. added to the tool box. The more powerful the toolbox the harder it is to truly grasp it, it seams which steepens the learning curve considerably unless only the very rudimentary "features" of oop are used, as it happens mostly in commercial 9-5 software development.

<comment><USER13> Have you programmed in Smalltalk? Classes tend to do a lot more (well everything that can be done) compared to C++. Smalltalk has a clean design for the core parts so these hang together pretty well. Nonetheless, inheritance hierarchies are deep and there are many fat classes. So small size in itself is usually not a virtue, clarity in role is on the other hand.

</comment></comment></comment></comment><comment><USER14> I think of learning OOP much like learning Chess. In Chess it's very easy to learn how the pieces move and start playing, but becoming a master is incredibly difficult, requiring years and years of deliberate practice. When I see people complaining about OOP, it makes me think of two beginners playing Chess, thinking victory is a random outcome.

The dialogue of the article is entirely about coupling, and in OOP figuring out how to make a loosely coupled system is what separates the grand masters from the beginners. Designing a loosely coupled system is incredibly hard and requires years of deliberate practice to master. So when someone who's a beginner or not very good at OO design claims OO isn't a valuable paradigm, I don't listen. Bad OO can be less valuable than no OO, just like anything else, and just like anything else, that doesn't make the whole paradigm bad.

I've explored functional programming in a couple of college courses now, and find it very intriguing. When it's time to go a make a system, however, I find it difficult to boil down functional principles into the system I want. This is a complaint in the same vein as the OO complaints. Functional programming is incredibly impressive when designing a behavior, but what separates the masters from the beginners seems to be when it's time to model an entire system. This is the current separation in my mind: OO is designed and really good for modeling a complex system that involves lots of mutation, and functional programming is really good for modeling and separating behavior within a system.

I don't think we have grounds to say one is better than the other yet. Both OO and Functional have their niches where they're amazingly effective, and both have a giant gray area where it's difficult to mold the pure paradigm onto a solution.

I think the best solution so far is a mixture of the two, such as we see in Scala. Though, a mixture too has its own set of drawbacks. Mainly what seems to be an explosion of language complexity and a giant need for design conventions and limitations when there are so many possible routes to a solution.

The best of the current climate is a mixture of the two, with a framework that clearly defines and separates where and when to use one paradigm over the other, so you aren't bogged down with the additional complexity.

<comment><USER7> > OO is designed and really good for modeling a complex system that involves > lots of mutation

I'd argue that this is where OOP struggles the most. Because mutation in OOP is implicit and unconstrained, it's more difficult to manage than in FP languages, which typically have more sophisticated controls and constraints for handling state.

<comment><USER15> Isn't that more a problem with the mainstream implementations of OOP, since one could concievably have an OOP language with fine-grained mutability?

<comment><USER7> Yes, I suppose it would be possible. It might work better with Smalltalk-like languages that revolve around message-passing.

</comment></comment></comment></comment><comment><USER16> Not to get into the oo vs functional debate, but generic advice about how big a class should be and how it should relate to other classes is guaranteed to be inappropriate some of the time.

Classes are a tool you can use to design a solution to your particular programming problem. Sometimes the problem with call for a few large classes. Sometimes it will call for an evenly balanced network of small classes. Sometimes there will be a lot of DTOs, and sometime none. Sometimes large classes will cause maintenance problems because there is a lot of complexity confusingly jammed in one place, and other times they will be a boon because you don't have to look in lots of confusingly named files to discover what you are looking for.

Criticizing a design by how well it conforms to abstract rules, rather than criticizing its fit to the actual problem will often lead to confusion.

These rules of thumb are useful, but only as a way to question whether your design is a good fit - I.e. "Would it be better if this class had more behavior or less behavior? Would it be better to split this class into smaller components, or should this group of similar classes be coalesced into a single entity?"

</comment><comment> dj-wonk This is a nice narrative. Some people have misconceptions about what OO gives you in comparison to other paradigms. OO provides specific abstractions, which may be useful in many cases, but also may be too much. In some cases, simpler abstractions may be preferable. Less complected (baked together and inseparable) abstractions can often be found in other paradigms. For example, in Java, a person might use a class even though all they need is a namespace. In many functional languages, you can just create a namespace without the other trappings of OO. Sometimes that is just what you want.

I've seen some nice slides from Clojure talks that talk about how many OO abstractions are complected (combined) versions of simpler abstractions. If anyone has seen the slides I'm talking about, please share. For example, a class is combination of a namespace and ___. Possible answers include mutable state, shared data, and so on.

<comment><USER17> I think that was Rich Hickey's "Simple Made Easy" talk: [http://www.infoq.com/presentations/Simple-Made- Easy](http://www.infoq.com/presentations/Simple-Made-Easy)

I think one of his most important points is that objects _are_ good for representing, well, actual objects. As in, you have a mouse, or screen or some little robot that you are controlling through code. And that's _all_ they are good for.

Need a way to define a bunch of static methods and avoid name collisions? - you want a namespace.

Need a place to store a bunch of data about something? - you want a associative array.

Need a way to call the same function on different types? - you want an interface.

I'm not sure about this, but I suspect part of the problem stems from the fact that object-oriented languages (usually Java these days) are the first language that students are exposed to. Once you start thinking in OO abstractions, it takes some effort to break out of the mindset.

</comment></comment><comment><USER18> > _Why Class?_

To enforce an invariant but of course. Just ask Bjarne.

[1] [http://www.artima.com/intv/goldilocks3.html](http://www.artima.com/intv/goldilocks3.html)

<comment><USER19> You can have Abstract Data Types without classes and object orientation.

<comment><USER18> Sure.

</comment></comment></comment><comment><USER20> I've found the most critical difference between OO and FP to be state. Objects are stateful from the moment they are created until they are destroyed. FP is remarkable for its general lack of side-effects - i.e. computations do not normally affect shared state.

I believe this distinction is a critical one because an application with a lot of shared state is more difficult to scale than one without. As another poster pointed out, in a shared addressed space such as a desktop app, this isn't a concern. But if you want to scale an application across multiple address spaces, communicating and synchronizing the state of objects between these spaces tends to be difficult.

So, my tendency is:

Small and shared address space? Tend to use OO patterns and implementations.

Big and distributed address space? Tend to use FP patterns and implementations.

Note, I don't consider OO vs. FP a language choice – I consider it a programming paradigm choice.

<comment><USER21> The problem is that whether or not we have shared mutable state on a logical level is not for us to choose. It's ultimately a property of the task at hand. Pushing shared state onto the database doesn't make it go away. Workarounds like MapReduce or monads only help us defer the moment of truth. If shared mutable state is what users ultimately expect to see, these approaches are merely simulations of shared mutable state that exploit a time gap in users' perception.

That gap is very brittle. Nightly batch windows become too short. Users expect real time updates leading to major redesigns of entire systems, like Google dropping MapReduce for their search index.

But I think your point about state being the major difference between OO and FP is absolutely true. In OO systems, statefulness is the default everywhere. Nothing is formally known about state in OO system and that is a bad thing. We need state to be explicit and formally specified.

</comment></comment><comment><USER22> I think OO and FP can coexist peacefully. You just need to pick out their good parts and discard the rest, and use a programming language that allows this.

Do put your object in classes, but don't put behaviors there. Use classes to allow static type checking so that functions taking them can guarantee certain field exist.

Separate behaviors out into its own module. I'd avoid calling them classes here because there will be confusion. Interactions between objects can be implemented in FP style. This is where you get to use map and reduce.

I've been learning about DCI (data context interaction) recently. I can't say I've fully grasped it yet, but it did opened my mind on how to do design differently.

<comment><USER23> OO and FP coexist peacefully. FP is all about passing functions as parameters into other functions.

Its exists on decent languages. Which in case allow OO also.

ie. perl, allows all that, and has Moose which allows Class and Roles and Types. So you can build classes like lego, literally.

<comment><USER24> > FP is all about passing functions as parameters into other functions.

That's a common misconception. First-class functions and higher-order functions are definitely commonly used in functional programming, but they are not what makes it functional programming. As with any paradigm, there is no universally agreed-upon definition, but most functional programmers will likely agree that lack of mutable state and lack of side effects are much more central to functional programming than first-class and higher-order functions. The latter are really just useful and elegant tools to help accomplish the former.

<comment><USER25> Without side effects you couldn't do anything. Pure functional languages make side effects explicit, but it isn't about them being missing.

<comment><USER24> > Without side effects you couldn't do anything.

Not true.

> Pure functional languages make side effects explicit, but it isn't about > them being missing.

True. I should have been more clear about that.

<comment><USER25> Yes true. Running a program with no side effects is a no-op. All side effect free programs are identical, and do nothing. This is one of the most common misconceptions people afraid to learn haskell bring up, because people keep saying "functional programming is having no side effects".

<comment><USER24> So you're saying that a library that has no side effects but performs a complicated data transformation "doesn't do anything"?

<comment><USER25> A library is not a program.

<comment><USER24> Your claim was "Without side effects you couldn't do anything." I was rebutting that claim. Again, unless you want to claim that libraries "don't do anything."

The more specific claim that you need side effects for a program to do anything is also false. You can prove mathematical theorems with programs that have no side effects. Of course now you'll say that that only works because of the compiler, which does have side effects, but that's really just moving the target so you can be "right" (as you did with this post).

Even if theorem proving isn't good enough, since the entire purpose for having the term "side effects" is to be able to usefully discuss referential transparency, the other poster who noted that IO can be an effect and not necessarily a side effect was correct. If IO is isolated, it is not a side effect, it is just an effect. A good example of this is the execution of the main action in a Haskell program.

<comment><USER25> You are not rebutting that claim, you are being obtuse.

>You can prove mathematical theorems with programs that have no side effects

No, of course you can not. How do you see the result? That requires a side effect of some kind.

>A good example of this is the execution of the main action in a Haskell program.

That is a terrible example, as executing main precisely _is_ a side effect.

<comment><USER24> > No, of course you can not. How do you see the result? That requires a side > effect of some kind.

The result is whether or not the program type-checks.

Your original claim was, again, that "without side effects you can't do anything". So, again, unless you are claiming that functions and libraries "don't do anything", your original claim was incorrect. Your new claim, that _programs_ must have side effects to do anything, is still wrong but more debatable.

You can call me obtuse if you want to, or you can learn how to communicate clearly and say what you actually mean. Doesn't much matter to me either way.

<comment><USER25> >The result is whether or not the program type-checks.

Ok, you are very confused. Type checking has nothing to do with program execution. Type checking is done at compile time. Any program with no side effects, the compile can safely optimize into nothing, since it does nothing. The compiler does the type checking, not the program.

>Your new claim, that programs must have side effects to do anything, is still wrong but more debatable.

It is the claim I made and you replied to. If you want to be pedantic and obtuse you can't expect people to not call you out on it.

<comment><USER24> Seriously? I'm directly quoting you in a post that is still visible, and you're denying it? Again, the quote that I originally replied to: "Without side effects you couldn't do anything."

> Ok, you are very confused.

You are both very arrogant and wrong. Not a pretty combination. Thank you oh so much for telling me that type checking is done at compile time, as though there were the slightest possibility I didn't know that given what I've been saying.

If you took some time to learn how to have a conversation on the internet _without_ being an asshole, you might actually learn something. Until then, I'll stop wasting my time trying to have a discussion with you. Cheers.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER26> This is a great piece and probably mirrors the process that a lot of us have gone through over the years. I know it definitely rang true for me.

I would hazard to guess that functional programming or any other solution will go through the same type of evolution and we will be looking back in 10 years at how immaturely we used the technology. Then we will circle back to yet some other technology that was previously used and went out of style, with some new insights added.

It seems to me that we go in a great big circle over and over again, picking up a little bit of new info each time around.

<comment><USER27> Also applies to the eternal wheel of centralization / decentralization. Or the peculiar 3-phase of interpreted / tokenized / compiled.

On a larger scale paradigms usually pick a spot along the verbosity continuum. Concise and information dense or verbose and information free? This is another eternal cycle. Some modern java looks about the same as 1960s COBOL to me.

</comment></comment><comment><USER28> Object-oriented in the large, functional in the small. Makes sense to me.

<comment><USER29> Gary Bernhardt has a nice talk about that:

[https://www.destroyallsoftware.com/talks/boundaries](https://www.destroyallsoftware.com/talks/boundaries)

A lot of people I know consider object-oriented design orthogonal to the programming style — that the real improvement is moving from a procedural to functional approach. Any system that grows large enough to clearly define an architecture technically _is_ object oriented, so long as it's passing messages among stable interfaces.

You want to have that functional core and imperative shell. Tell above, ask below.

It's just unfortunate that a lot of "object-oriented programming" that you learn in school is really just imperative programming with interfaces ;)

<comment> dj-wonk Re: "Any system that grows large enough to clearly define an architecture technically is object oriented, so long as it's passing messages among stable interfaces."

@straws: I'm curious, why do you think that the situation you mention above implies that such a system is 'technically' object oriented?

If I'm understanding your claim, I disagree. All you need are mechanisms for:

(1) function-calling or message-passing (I don't think you were trying to emphasize an extremely rigourous definition of 'message passing' were you?)

(2) namespacing

(3) validating a 'stable interface'

There are many definitions of OO, but this is one is good enough for my point: "Objects, which are usually instances of classes, are used to interact with one another to design applications and computer programs" (from [http://en.wikipedia.org/wiki/Object- oriented_programming](http://en.wikipedia.org/wiki/Object- oriented_programming))

You _don 't_ need object-based inheritance (e.g. Java) or prototype-based inheritance (e.g. Javascript) to build large systems in this way.

For example, you can build very large systems in Erlang (passing messages too!) without any kind of OO.

There are lots of examples of how functional languages can enforce interfaces without classes, including Haskell.

<comment><USER30> Erlang processes are basically objects passing messages to each other. They have state and behavior and communicate via message passing, they are objects.

<comment><USER29> I think we're mostly in agreement, @dj-wonk. Objects are about bundling that state and behavior, nothing more. _How_ they're created or instantiated is secondary.

It's unnecessary to create classes for functionality when it's unnecessary to create _objects_ for functionality. Here's an eloquent article on that subject:

[http://me.veekun.com/blog/2013/03/03/the-controller- pattern-...](http://me.veekun.com/blog/2013/03/03/the-controller-pattern-is- awful-and-other-oo-heresy/)

</comment></comment></comment></comment></comment><comment><USER23> Use a better OO meta object system, ie. Moose.

And then you can build a class like LEGO, literally.

Because, it has Class and Roles, a class can extend another class. And a Role can be built with multiple roles. And a class can be built with multiples Roles.

Your OO is outdated if it doesnt implement classes, roles, types and at least method modifiers.

And your language should allow first function class to allow functional programming if you desire.

Perl has all that and comes installed in any unix/linux/mac.. try in your terminal: $ perl -v

Every linux/unix/mac system runs perl. So your company is probably using perl and they dont even know.

</comment><comment><USER31> I do agree the "noun" vs "verb" analogy when classes are taught are horrible..actually the way classes are taught in general are just confusing.

Ultimately, classes are about code organization and reuse. Done properly, it leads to a well maintained program. Functional programming...it still needs to be organized somehow, whether you put them in classes or namespaces, the last thing you want is spaghetti code. Now depending in the type of programming, you may need to preserve state, which can be quite challenging in a purely functional environment.

<comment><USER32> _Now depending in the type of programming, you may need to preserve state, which can be quite challenging in a purely functional environment._

What makes you say that?

</comment></comment><comment><USER33> [http://c2.com/cgi/wiki?ExpressionProblem](http://c2.com/cgi/wiki?ExpressionProblem)

<comment><USER34> [http://mitpress.mit.edu/sicp/full-text/book/book- Z-H-18.html...](http://mitpress.mit.edu/sicp/full-text/book/book- Z-H-18.html#%_sec_2.5.2)

</comment></comment><comment><USER35> I can somewhat relate to the conversations in the article. While I admit that I don't think I used OOP correctly, since I started using more functions instead of classes (in Python, my primary language), I observed that it has been more convenient to reuse and refactor existing code.

Another observation is that it's far easier to read someone else's code if there is no mutation. For eg. I have enrolled for the proglang course[1] on coursera and only yesterday I completed this weeks homework which involves enhancing an already written game of Tetris in Ruby. Major part of the assignment was about reading and understanding the provided code that uses OOP and makes heavy use of mutation. It was quite difficult to understand what one method does without having a picture of the current state of the object, specially with side effecting methods that call other side effecting methods. A few times I had to add print statements here and there to actually understand which one is being when and how many times. While I could score full marks in the end, I am still not confident about completely understanding the code and have a feeling that if I ever need to work with it again, the amount of time it will take to load up everything again into my mind's memory will be equal to what it took for the first time.

Of course, one could only make a true comparison by studying an implementation of Tetris written in FP style. But from my experience with reading and writing code in Erlang (for production) and Racket, Clojure (as hobby) I find it relatively easier to study functional code written by others.

[1]: [https://www.coursera.org/course/proglang](https://www.coursera.org/course/proglang)

</comment><comment><USER36> It's not like one paradigm is perfect for everything. But there's one thing that the author wrote that stood out for me: writing a "utils" class for stuff he doesn't "know where it really belongs."

That's one of the benefits of OOP: it forces you to think harder about where things belong, and this really helps as codebases grow. A "utils" class is often a sign that things could be better organized.

<comment><USER37> I couldn't disagree more that thinking harder about where things belong is a benefit of OOP: it's an entirely unnecessary tax caused by the requirement to wrap every symbol in a class.

Another aspect of this is unnecessary effort expended on deciding if A.operateson(B) or B.operateson(A). Sometimes, you want to Operate(A, B). If your language doesn't allow that, you end up with operator.Operate(A, B).

Classes are not always the best organizational tool.

</comment></comment><comment><USER38> Will someone give me a few concrete, practical examples of using functional programming in JavaScript?

I'm interested in this concept, but I'm not sure how to go about applying it to my own work as a front-end web developer. Most of the resources online are theoretical.

<comment><USER29> Everyone using jQuery is benefitting from functional programming. Querying, traversing, and filtering are based on `each` and `map`. It turns what was formerly looping and saving values as temporary/instance variables into declarative, collection-based compositions of functions.

Beyond that, Michael Fogus — big in the Clojure + Clojurescript community — has Functional Javascript which explores functional concepts using Underscore: [http://www.amazon.com/Functional-JavaScript-Introducing- Prog...](http://www.amazon.com/Functional-JavaScript-Introducing-Programming- Underscore-js/dp/1449360726/)

Marijn Haverbeke — a big Lisp hacker and the creator of Codemirror — has a nice chapter in (the free!) Eloquent Javascript as well: [http://eloquentjavascript.net/chapter6.html](http://eloquentjavascript.net/chapter6.html)

You should also check out how Javascript supports functional programming in languages that compile to Javascript such as LiveScript or Elm.

[http://livescript.net/](http://livescript.net/) [http://elm- lang.org/](http://elm-lang.org/)

</comment></comment><comment><USER39> :D. Why is anyone even considering FP vs OO programming a choice? I've used functional patterns within OO before and I'm sure the opposite is possible.

Both have merit depending on the skill-set and staff available to you, scale of project and existing infrastructure.

I was however very disappointed when the author bundled interfaces into the mix as if it was the same as the rest of it. The interface enables you to support many different types of behaviour and enables you to structure your libraries in different ways. It's a different aspect from just classes themselves.

Genuinely I don't think shit like this is healthy. Smacks of religion.

</comment><comment><USER40> I might be a little late, but does anyone have any examples of simple CRUD web applications written in a functional language? There seems to be a lot of meta discussion about the suitability of functional programming for the web, but not very many concrete examples. Thanks!

</comment><comment><USER41> 'Don't be silly Jake. Where else are you going to put functions if you don't have classes?'

The core argument is more of philosophical in nature in terms of paradigms, because from functional programming view a function just acts on a data transforming it to other form. But in pure OO world (like Java) one can not dare to think beyond objects so for them it has to be in a object.

</comment><comment><USER42> In one of the initial posts of the series, OP mentions that functional programming doesn't have app state. Can anyone point out more details on this?

I don't know if I am understanding it correctly but one of the reasons I absolutely loved Backbone.js was that it kept state of our DOM. Is this relevant to above discussion? because state surely looks pretty beneficial.

</comment><comment><USER43> One can argue that Javascript's prototype is probably the future, not the traditional class-based OOP.

<comment><USER44> After nearly 20 years of Javascript there still is no consensus on how to structure object-oriented systems. This is somewhat reminiscent of lisp's failure to succeed in the marketplace because it's so flexible that no one can agree and get behind enough core ideas to build a large ecosystem. Javascript had the weight of the web behind it to force adoption, but that clearly has been in spite of the OO model not because of it.

I'm not trying to hate on JS either, I think it was a bit of a small miracle what Brendan Eich pulled off under the constraints he had and I'm thankful for JS every day. However I think it's fair to say that something like Ruby's metaclass and mixin system gives you 99% of the modeling power of advanced prototypal modeling with 99% less confusion. Obviously there are ways it could be done better and more explicitly than in Javascript's typeless object world, but even then I don't see where the win is. We need better ways to manage state and mutation in mainstream languages, not more ways to compose objects.

</comment></comment><comment><USER45> > Don't be silly Jake. Where else are you going to put functions if you don't > have classes?

I'm seeing where this is going: GoLang.

</comment><comment><USER46> +1, Nice to see your post man, keep it up! :)

</comment><comment><USER47> Ever since I started playing around with Java (or even earlier with C++) having data co-mingled with functions has never felt right to me. It just never seemed very extensible to me, especially in a language like Java. Even in C# where you have extension methods, they are second class citizens.

But also the old question of where to put a method seems like unecessary mental overhead for solving a problem. Use modules and just pass things in. You could probably even put some syntactic sugar in the language so that you could use the "object".method notation on the first argument passed in if you really wanted to.

So someone give me clojure with optional typing, a Python-like syntax, and get off my lawn!

<comment><USER48> > clojure with optional typing, a Python-like syntax

[http://julialang.org/](http://julialang.org/)

</comment></comment><comment><USER49> IMO, most critics of FP or OOP do so because they lack a full understanding of one or the other. Either paradigm can be applied incorrectly and cause plenty of problems. Both have their merits and strong points. Each fits a different type of project better than the other. Also different people tend to grasp or appreciate one or the other better naturally depending on how their brains are wired. More logical, abstract thinkers tend toward OOP while more right brained people tend toward FP. There is nothing wrong with this. There is also nothing wrong with learning the benefits of the "other side". If fact it is quite beneficial.

some language designers see and fully appreciate the benefits of both. They start putting class synonymous structures in FP languages or FP functionality in OOP languages. This is the future of the mainstream (Ex: EcmaScript 6 has classes/types, C# has Linq, closures, lambdas ETC).

<comment><USER50> Haskell seems pretty left brained to me!</comment></comment>