Facebook is showing a real time like count on Mark Zuckerberg's status updates - <AUTHOR> http://www.facebook.com/zuck/posts/999900229761

<comment><USER2> This has worked for a while, it's just much more apparent on his posts:

<https://www.facebook.com/note.php?note_id=496077348919>

<comment><AUTHOR> ahupp - That is referencing the real time comments (where comments are pushed to you without reloading the page).

This is different. Facebook is showing the actual like count change in real time. This is fantastic feedback for big brands.

<comment><USER3> You might want to check the credits at the end of the post ahupp linked to. :)

</comment></comment></comment><comment><USER4> Wolfram Alpha shows 9993 days.

[http://www.wolframalpha.com/input/?i=May+14%2C+1984+to+today...](http://www.wolframalpha.com/input/?i=May+14%2C+1984+to+today+in+days)

<comment><USER5> Python 2.7 shows 10,000 days.

        >>> datetime(2011, 9, 30) - datetime(1984, 5, 14)
        datetime.timedelta(10000)

<comment><USER5> Also, Ruby 1.9.2 shows 10,000 days.

        irb(main):017:0> (Time.utc(2011, 9, 30) - Time.utc(1984, 5, 14)) / 60 / 60 / 24
        => 10000.0

<comment><USER6> So does PHP!

        echo date_diff(date_create('1984-05-14'), date_create('2011-09-30'))->format('%a days');
        => 10000 days

Is this silly yet? ;)

</comment></comment></comment></comment><comment><USER7> The like updates are timed improperly and the number keeps going down and then up and then down. I got a lot of shit at work for a similar bug on a JS ticker, I'm glad I'm not the only one!

<comment><USER8> Could this be because some people (at 120,000 now) are unliking and dropping the count for a moment?

<comment><USER9> More likely a propagation/aggregation issue.

</comment></comment></comment><comment><USER10> Doing a little network sniffing this seems incredibly inefficient. Apparently the page is polling the server up to 8 times per second and getting back a 7-800 byte chunk of Javascript. The infrastructure to support this at Facebook's scale is mind boggling. This is the kind of stuff that Websockets was invented for.

<comment><USER11> web sockets or, in most browsers, long polling. long polling is easy to implement and they must already have the infrastructure built out since they have chat...silly Facebook.

[edit] just took a closer look at the network activity. this really is the worst way to implement this feature. polling several times a second, sending back a bloated response, and updating much more of the DOM than necessary. this is just terribly hacky. probably done very quickly at the last minute though.

<comment><USER12> Zuck maybe wrote it himself for fun?

<comment><USER13> Stop kidding yourself.

<comment><USER12> Amused that my comment was down-voted when It's widely known that Mark would work 'hands on' on the codebase [1] as recently as last year.

[1] [http://techcrunch.com/2010/04/14/apparently-mark- zuckerberg-...](http://techcrunch.com/2010/04/14/apparently-mark-zuckerberg- still-writes-code/)

<comment><USER14> <http://kottke.org/11/09/zucks-gonna-write-code>

This excerpted anecdote indicates it was mainly a leadership gesture to rally the troops. Still pretty cool that he'd bother, though.

</comment></comment></comment></comment></comment></comment><comment><USER15> I don't have a Facebook account, does it only work for logged in people?

<comment><USER16> Probably, I don't click anything with Facebook in the URL.

</comment></comment><comment><USER17> It has done the exact same thing for my friends posts for a looooong time. This isn;t specific to his account, its just more prominent because there are more people "liking" it.

</comment><comment><USER18> If they keep adding people at the rate they are, in 10 years they'll have wired together the entire human race. I'm not sure if I should be scared or thrilled or skeptical.

<comment><USER19> But they won't and can't. These sorts of hyperbole are getting really old.

</comment></comment><comment><USER20> On my client if js is disabled then yes the count is "real time" otherwise nothing happens.

</comment><comment><USER21> Seems buggy to me; it doesn't register my like and unlike very well.

</comment><comment><USER22> cute little easter egg

</comment><comment><USER23> way to toast yrself zuck</comment>


Color Picker Pen - <AUTHOR> http://www.tuvie.com/color-picker-by-jinsun-park/ <comment><USER2> This will be great...once somebody inverts the law of physics; it says it uses RGB inks, which is physically impossible.

<comment><USER3> It says it would mix ratios of the three inks. How is that any different than a printer?</comment></comment>


Open source firmware for the TSDZ2 mid-drive motor on DIY e-bikes - <AUTHOR> https://github.com/OpenSource-EBike-firmware/TSDZ2_wiki/wiki <comment><AUTHOR> Just finished building my bicycle around this motor and with the open source firmware. It's a great piece of software and it feels much better than the stock one.

This particular motor is torque sensing: it feels how hard you're pushing down on the pedals and multiplies the force from the motor, unlike most aftermarket motors that either apply full power as soon as they detect pedal rotation and/or only function with a throttle.

This particular motor gives more of a bionic legs feel, very much like the (much more expensive and less powerful) Bosch and Yamaha prebuilt units.</comment>


Windows PowerShell to get a package manager - <AUTHOR> http://blogs.msdn.com/b/garretts/archive/2014/04/01/my-little-secret-windows-powershell-oneget.aspx

<comment><AUTHOR> I saw nothing about it actually appearing in Windows 10, so I change the headline from this article's headline, wherein I found the MSDN blog link. [http://www.howtogeek.com/200334/windows-10-includes-a- linux-...](http://www.howtogeek.com/200334/windows-10-includes-a-linux-style- package-manager-named-oneget/)</comment>


Airless Tires Roll Towards Consumer Vehicles - <AUTHOR> http://spectrum.ieee.org/cars-that-think/transportation/advanced-cars/airless-tires-roll-towards-consumer-vehicles <comment><USER2> Michelin has been marketing their "Tweel" ([http://www.michelintweel.com/](http://www.michelintweel.com/)) product for industrial applications for a while, and I've read a couple of articles about their trials of the Tweel on passenger vehicles. I suppose that the challenges of higher speed applications have prevented that product from appearing.

Personally, I want some Mattracks :) ([https://www.mattracks.com/](https://www.mattracks.com/))

<comment><USER3> I've seen them on construction equipment, which admittedly moves very slowly.

<comment><USER4> They get rather wobbly and noisy as you reach higher speeds.

</comment></comment></comment><comment><USER5> If they can get the requisite approvals planes seem to be an ideal application of these, as burst tyres upon landing or takeoff are actually rather frequent and the shrapnel can cause extra damage... sometimes leading to catastrophic results:

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

</comment><comment><USER6> Something I always wonder about is the mass. Airless tires have a lot more mass around their edges than pneumatic ones do and so at higher RPMs would seem to put more stress on both the axle and the wheel, especially when turning. That seems like a really hard problem which gas solved really well.

<comment><USER7> Yes, also known as unsprung weight. This is one of the reasons airless tires have a long way to go before they can hope to replace regular tires.

</comment></comment><comment><USER8> The pneumatic tire is an awesome invention. They have the ability to cancel out imperfections in the road surface over a wide range of frequencies and amplitudes. Bicycles have traditionally used no other type of suspension.

To make a non-pneumatic tire you have to invent something equally as awesome. Normally you end up with something that produces a very rough ride.

<comment><USER9> A rough ride is the least of your problems. In a powered vehicle, the primary purpose of suspension is to keep you in contact with the road. If you're not in contact with the road, you're not in control; braking, steering and acceleration don't do anything if they can't react against the surface.

</comment></comment><comment><USER10> > The series of "rigorous tests" that the company is putting its tires through > are meant to prove their durability, hardness (efficiency), stability, > ability to take high-speed turns (slalom), and ability to _maintain their > integrity at high speeds (up to 130 kilometers per hour)._

That's only 80 MPH. I'm interested in the no flats and potential fuel savings but I'd want to be able to travel at freeway speeds on long trips with them too without having to change out tires.

<comment><USER11> What exactly do you consider freeway speeds?

Even in the metro ATL area which is notorious for thinking the speed limit is a suggestion, the vast majority of traffic is moving under 85 MPH.

<comment><USER5> [https://en.wikipedia.org/wiki/Tire_code#Speed_rating](https://en.wikipedia.org/wiki/Tire_code#Speed_rating)

 _In many countries, the law requires that tires must be specified, and fitted, to exceed the maximum speed of the vehicle they are mounted on, with regards to their speed rating code (except for "temporary-use" spare tires)._

I see it as a safety factor - the speed ratings of most common tires (S or T, 180 or 190 km/h) are far beyond what most people will ever drive at. If this one is only rated to 130km/h, that decreases the safety factor.

</comment></comment></comment><comment><USER12> Great article about a previous innovation of Michelin that failed: In the 1990s Michelin developed a revolutionary new kind of tire with sensors and an internal hard wheel that could run almost perfectly for 125 miles after a puncture. They forgot to involve the ecosystem.

[http://www.forbes.com/sites/frederickallen/2012/03/05/why- gr...](http://www.forbes.com/sites/frederickallen/2012/03/05/why-great- innovations-fail-its-their-ecosystem/)

(edit: not being negative on this new product, just providing some context)

</comment><comment><USER13> I am pretty happy with my run flat tires on my bmw, even after a blowout they remain normal and handling is near normal as well, plus you can drive like 100miles and 50mph to a nearest tire shop. The only downside is they are more expensive and sometimes if you cought nail close to a tire sidewall it means you I'll have to replace a tire since it's not fixable

<comment><USER3> And they ride more harshly, are less compliant, are heavier (look at how much some spend on light-weight rims; tires are even further from the center of the wheel), more expensive, can get bent / dented, and rely on finicky tire pressure monitoring systems.

<comment><USER13> They might be heavier but they allow you to get rid of a spare wheel, so overall the car is lighter.

<comment><USER14> Beyond the issue with unsprung weight, that seems like a truly awful trade- off. A run-flat still needs to be serviced if punctured and is still vulnerable to sidewall damage and potential blow-outs. If you carry a full size spare (I sure do) in the event of most tire failures, you still have the ability to get much further down the road with less drama.

<comment><USER13> None of the new sedan vehicles carry a full sized tire, they all carry a temporary one, which can only be driven 50 miles at low speed. So still worse than broken run flat

<comment><USER14> They don't come with one stock, sure, but there's nothing to stop you from going and buying the correct sized steel (or cheapo alloy) wheel and a decent tire that's the same size as the ones on the car and carrying it with you (and throwing the junky temporary spare out). Yeah it requires you to work a touch extra on the setup, but it is worth it. The extra full size spare will cost about the same as going with run flats vs non-run flats each time you swap out tires.

If you're interested, it's pretty easy to get the correct sized wheel from somewhere like RockAuto or Discount Tire Direct.

</comment></comment></comment></comment></comment></comment><comment><USER15> The demo video touts them as "eco-friendly", and I'm assuming they mean relative to traditional pneumatic tires, so how are they actually better in that regard?

<comment><AUTHOR> There might be multiple factors: how much you pollute to produce them (much less, considering that there is almost no metal involved, unlike with traditional tires which have alloy wheels); how much they get consumed by usage, compared to traditional tires; how much they pollute to dispose of them.

</comment></comment><comment><USER16> That's a cool video, but I've seen enough CG-salesy examples from vaporware projects--with similar animation and admittedly high-quality concept videos-- to feel skeptical.

Given how well similar tires seem to work for the military, and potentially low-cost replacement road-contact parts, I'd support it. However, my worry is... what if the manufacturer and or distributor went out of business? Will I have to replace all my tires just because one got a little shredded up from some debris? (I assume mixing tires which might have different sizes / radiuses is a bad idea)

</comment><comment><USER17> Watch for stats on rolling resistance, tire weight, impact on suspension / size, and cost before getting excited.

Punctures occasionally cause blowouts, and those are awful, but still subject to tradeoffs. If airless tires tank the efficiency of your vehicle you'll think to yourself, "Well, _I 've_ never had a catastrophic blowout... and changing a tire is a pain, but isn't _that_ bad."

We've used airless for decades, just not in cars. We aren't just waiting for a simpler manufacturing process, there are other constraints at play.

</comment><comment><USER18> Inb4 congress tries to pass a law prohibiting them because they can be used by villains to defeat LEO's spike strips.

<comment><USER19> Wouldn't run-flat tires then already be banned?

<comment><USER20> No. The purpose of run-flat tires are to get you to pull off the road safely, or travel a small number of miles at low speeds to somewhere where you could have a replacement mounted and installed immediately. They are not intended to run without air for extended periods of time, or at highway speeds. They are also not to be driven on AT ALL in the event of a sidewall puncture.

The casing would still fail catastrophically at high speeds (i.e. pursuit scenario), and having a tire down over 30psi on one wheel would very seriously affect handling at any significant speed (40mph or more).

</comment></comment></comment><comment><USER21> I'd be interested in better efficiency and lower operating cost. As for safety, I'd have to see the stats on how often modern tires blow out. And a demonstration that lower operating costs on the tires doesn't translate into higher costs for maintaining other components such as bearings and suspension.

</comment><comment><USER22> I wonder if you can 3d print a rubber tire shape someday. You might be able to engineer a shape that might be hard to make otherwise and solve some of the issues not having air.

<comment><USER23> I'd be interested to know how well layers of 3d printing holds up to that much rotational mass, lateral forces, and vibration at freeway speeds. I have my doubts at this point of its feasibility.

<comment><USER24> A 3D printer could be used to create the mold for the rubber perhaps.

<comment><USER25> You can easily do a lost-wax process with a 3D printer.

(Although getting the precision may be difficult.)

<comment><USER26> Some folks have already moved on to a lost PLA casting process. I've seen some pretty decent results.

[http://3dtopo.com/lostPLA/](http://3dtopo.com/lostPLA/)

</comment></comment></comment></comment></comment><comment><USER27> I remember seeing this concept appear over the years. I suppose this means they solved heat dissipation and vibration issues?

</comment><comment><USER28> Would love to see a bicycle tire with this. Way too many glass pieces on bike lanes :-(

<comment><USER29> Puncture proof bike tires work extremely well. I have Continental Top Contact tires. Except for overinflation (my fault), never had a flat over thousands of miles. They feel nice to ride on too. Before that, I had Panaracer ribmo tires. No flats, ever. However, the ride was a little bit stiff.

Both were a little heavy, but worth the extra weight.

If you're getting flats, that's a much better solution.

</comment></comment><comment><USER30> These have been around a long tme, especially for armored cars (I saw them on an Audi W12). I was told the ride is rougher than pneumatic tires but have the advantage that they can't be punctured by gunfire, or whatever.

<comment><USER31> The point of these is, presumably, to be as comfortable as conventional tires.</comment></comment>


This new search engine could be way smarter than Google - <AUTHOR> https://www.washingtonpost.com/news/the-switch/wp/2016/05/24/this-new-search-engine-could-be-way-smarter-than-google/?tid=sm_fb <comment><USER2> having to look for it using google is somewhat of a paradox, imho</comment>


Bye Bye Blackberry. Hello iPhone 3G. - <AUTHOR> http://ryanspoon.com/blog/2008/06/14/why-im-turning-in-my-blackberry-for-an-iphone-3g/ <comment><USER2> He didn't give any reasons for _not_ doing number 2 (waiting for the Blackberry Bold)...

<comment><USER3> he did indicate that the "open"-ness of the iphone platform is the main reason he is giving up/selling out/buying in. And as there is no reason to believe the new blackberry will be any more "open" than the last it is ruled out by that same logic.</comment></comment>


Yahoo planning 10% layoffs as early as this month, report says - <AUTHOR> http://www.bizjournals.com/sanjose/news/2016/01/07/yahoo-planning-10-layoffs-as-early-as-thismonth.html <comment><USER2> Don't worry people; I am sure the CEO will be okay.

<comment><USER3> Mayer will be walking away with a $158M golden parachute[0], and will undoubtedly have another nice executive position lined up in no time.

It's amazing how much respect she's garnered in the tech community. From all the public info on her, she doesn't seem to have much product vision - rather, she's just a manager who's good at making data-driven decisions (the infamous "41 shades of blue"[1]) to incrementally optimize products that already have their flywheels spinning, and got insanely lucky by betting on the right horse back in 1999.

0: [http://www.usatoday.com/story/money/markets/2015/12/04/maris...](http://www.usatoday.com/story/money/markets/2015/12/04/marissa- mayer-severance-benefits/76781384/)

1: [http://stopdesign.com/archive/2009/03/20/goodbye- google.html](http://stopdesign.com/archive/2009/03/20/goodbye-google.html)

<comment><USER4> I agree and disagree with your point. It's incredibly hard to determine how much good a new CEO has done, and how much is inertia. I think that's a strong argument against the incredibly high CEO pay in contemporary companies, it dramatically underestimates the importance of the work of the rank and file.

That being said, if you ARE going to judge her by contemporary CEO standards, the question is, would anyone else have done better? And of the set of people who could have done better, how many would take an offer to fix yahoo contingent on performance? I think the answer is probably zero.

The whole system is rigged, companies feel like they have to pick someone out of a relatively narrow talent pool, and since they are (wrongly) in such demand, they can all command extremely high salaries.

<comment><USER5> If no one could have gotten better results, I can think of many capable people who could have gotten similar results for a lot cheap. Yahoo! is almost paying MM $400 million and the $110 million exec who stayed about 11 months she fired. For all the Meritocracy talk about general foot soldiers, the SV execs seem to get a lot of "Participation Trophies".

<comment><USER6> She's making more than Tim Cook? No way

<comment><USER7> My thoughts exactly. IIRC Tim makes around 10 mil per year.

<comment><USER8> 10 mil + ~45 mil in stock grants. Still a pretty good bargain, all things considered.

<comment><USER9> Steve Jobs took no pay at all for years. If he had played hardball with the board, he could've become the richest man in the world. Tim Cook is not doing it for the money either.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER10> Yahoo needs to kill off half of their products and just focus on four things:

* news (finance & sports)

* Search & Portal (that's where they make $$$)

* YMail (because there are still millions of users)

* fantasy sports and extend it.

Spin off Tumblr and Flickr into a startup focus on content and high-quality photo source (TBH there is very little quality content on Tumblr and the attraction / hype is gone - speaking from user after five years of using Tumblr), and other applications should be killed, including their article reading mobile app, Developer network, and the newly resurrected Y! Messenger.

BTW, Yahoo is one of the most generous companies out there paying security bounty (good and bad for too many submissions :] )

<comment><USER11> Disagree about Tumblr.

A year ago it was still the fastest growing social platform, and it still proves to be (especially in 2015) the big source of viral internet content.

<comment><USER10> Fastest doesn't mean actually making tons of money. Sure vaulation on # of user, but a business can't live forever with # of users. How many of these users are making original contents? I keep seeing posts from years ago getting liked over and over by the people I follow on Tumblr.

</comment></comment></comment><comment><USER12> Don't kill Tumblr please. It is my go to source for porn.

<comment><USER13> There's still Bing Videos[0]. It's super effective!

\---

[0]: [https://www.bing.com/?scope=video](https://www.bing.com/?scope=video)

<comment><USER14> Strangely enough Bing Videos doesn't work anymore. I don't know if it's a regional thing or if they killed it.

</comment></comment></comment><comment><USER15> That's the second time : [http://www.huffingtonpost.com/2012/04/04/yahoo- layoffs-2000-...](http://www.huffingtonpost.com/2012/04/04/yahoo- layoffs-2000-jobs-cut_n_1402470.html)

<comment><USER16> second? how quaint...

every single CEO did that. some every year.

mayer did her's in small installments to not show up in the media. but still got the same cut at the end.

i think it's some textbook the board have

<comment><USER17> There has to be a better way to run a company... this kind of thing from so many companies world wide cannot be good for society as a whole.

<comment><USER18> Why? Releasing the workforce from an unproductive company is exactly what society needs.

The opposite is zombie companies.

<comment><USER17> Perhaps Yahoo should have been split into smaller companies sooner. With better management, Flickr could have been Instagram.

<comment><USER19> I've been preparing to try to make an offer for Flickr in the event it goes up for sale (separate from the rest of the web business), organizing it as a benefit corp to be a long term business not to be put up for sale. It shouldn't be an Instagram. Its not a social network. Its a photo site that helps you organize/keep your photos, as well as share them (there's a difference).

Just bidding my time, ear to the ground.

<comment><USER20> Why? There are many great photography hosting services. Flickr is only special because Yahoo makes it free as a marketing gesture

<comment><USER19> Can you list one? I've found SmugMug and 500px to be significantly inferior to Flickr, which is why I'm still a Pro Flickr subscriber.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER21> I wonder if 10% is enough of a cut to make the business viable again, or if this is just pandering to the market. Seems likely that someone picked this number out of the air to make a statement.

<comment><USER22> Time to buy magic 8 ball stock as Yahoo is certainly increasing demand.

</comment></comment><comment><USER16> investors who bought YHOO just to wait the Ali baba sale would love the company cut 500mi/year over year in salaries (or disinvest on products?) so when the dismantling finally comes the pie slices are bigger.

</comment><comment><USER23> Been a yahoo mail premium member for so many years (along with its calendar) it's something I care daily. From about 2 years ago the new mail became a hit or miss randomly, overall a much worse experience than what I used to have, and I am unhappy about that.

To me since Mayer came to power, yahoo email became less reliable, a big negative.

<comment><USER24> I have accounts on the 3 main providers Hotmail, Gmail, Yahoo Mail. Which gives me the most trouble? Yahoo Mail.

When Mayer became CEO she told employees to start using Yahoo Mail. I wonder how many are actually doing so. I would think if they were actually using it the product would now have less glitches.

<comment><USER25> All of them.

<comment><USER26> That is correct, everyone at Yahoo uses yahoo mail

</comment></comment></comment></comment><comment><USER27> Preparing for a sale of their "internet business" perhaps.

<comment><USER28> When Nokia sold the Devices division to Microsoft it did the opposite, did not fire anyone, and let the new owner take care of it...

<comment><USER29> Nokia, in many ways, was the pioneer of SaaS. They developed a globally recognized product that would become both the iconic application associated with early cellphone applications and paved the way for a globally distributed market for mobile gaming.

However, as time went on while using the product, it became increasingly difficult to find room to move horizontally as well as vertically within the space. Ultimately, continually completing objectives made it more difficult to pivot.

Inevitably, their SaaS product became frustrating and deprecated and the marginal utility diminished. With a lack of new offerings Nokia was forced out of the market it created (Snake as a Service) and we were forced to go back to playing the helicopter game on the bewest RIM blackberry.

<comment><USER30> I never saw them involved in the service business at all, to me they were a hardware company and nothing else. That's how I look at my phone (and computers too), as pieces of hardware not tied to any particular service or eco-system unless I decide they should be. I don't buy subsidized phones with a 'plan' and what software comes with the computer I buy is wiped out before it even gets run once.

</comment></comment></comment></comment><comment><USER31> Next logical step - Yahoo should hire Elop as CEO ;-)

</comment><comment><USER32> Love the yahoo stock portfolio view. If you know a better one please let me know, just for my interest.

</comment><comment><USER33> I've thought for some time that Yahoo! should have moved into the streaming video business, including emulating Netflix and producing original content on a subscription basis. In the very least it would have been a way to lure people to their website and get them to spend a lot more time within/adjacent to the Yahoo! ecosystem.

Come to think of it, I'm not even sure if Yahoo! has ever done anything video related. I wonder why?

<comment><USER34> [https://yodel.yahoo.com/blogs/general/live-yahoo-saturday- ni...](https://yodel.yahoo.com/blogs/general/live-yahoo-saturday- night-232247921.html)

[https://en.wikipedia.org/wiki/List_of_original_programs_dist...](https://en.wikipedia.org/wiki/List_of_original_programs_distributed_by_Yahoo)!

</comment></comment><comment><USER35> 10% for Yahoo, given the current suite of products is low. for long time yahoo hasn't streamlined their product offerings. Just streamlining them alone will help them become more leaner. as far as CEO is concerned, yes, she is very much covered.

</comment><comment><USER36> new WhatsApp coming

<comment><USER37> This is the best comment.

</comment></comment><comment><USER38> They could have been serious contender in semantic search. I remember trying to reach out to some yahoos regarding an ambitious, yet serious proposal on semantic search using ThatNeedle.com. we could have made an impact. I could not get to the right audience even for a demo or a proposal. I guess they have too many silos built on top of an ivory tower. Nonetheless, it would be sad to see them fade away.

<comment><USER39> You mean you tried to peddle your startup (for acquisition likely) to them and you couldn't get your foot in the door? And that could have made them a "contender"? Please

<comment><USER38> outsourcing search to Bing certainly didn't help. Not sure they had much to lose in search.

</comment></comment></comment><comment><USER40> A society that has no saftey net except for the lucky and rather dumb 1%ers is one that will fall apart, sooner or later. Or experience radical disruption.</comment>


Classes are a way of writing higher order functions - <AUTHOR> https://stopa.io/post/250 <comment><USER2> > _Yup, really. Classes are just higher order functions, which accept > arguments (constructor) and return a list of functions that can manipulate > those arguments (methods)._

Nope, really they are not. Rather, objects are _run-time_ , _publicly accessible_ environments (bindings of names to slots).

Since functions also have environments, we can come up with some contrived use cases whereby a rigorously encapsulated OOP example revolving around a class that is sealed against extension and uses no inheritance or other OOP mechanisms is nicely mimiced by a vector of functions that share the same environment.

But imitating some facets of a thing is not being that thing. A dog standing on hind legs isn't a man.

A more fully featured OOP can be built up, which yet keeps using lexical variables for slots. Public access to slots by name can be implemented by having a standard function supported at the same position in the function table, which takes a symbol argument, and switches on it to map it to a variable in its environment.

Providing possible implementation mechanisms for thing is also not being that thing.

We can easily reverse this, too, and claim that functions are just objects. Compilers for lexical closures do things like flatten the environment into an array in which items are accessed by position. So, first class functions are, under the hood, nothing but code, plus an array, in machine language. And since data structures are also some code offsetting into arrays, it's all the same.

You know, the moment I saw a NAND gate schematic, my mind opened to an amazing revelation: we don't need both zeros and ones, just zeros and NAND gates! The number one is nothing but a zero, duplicated into the two inputs of a NAND gate.

<comment><USER3> > You know, the moment I saw a NAND gate schematic, my mind opened to an > amazing revelation: we don't need both zeros and ones, just zeros and NAND > gates! The number one is nothing but a zero, duplicated into the two inputs > of a NAND gate.

This is not as absurd as you think it is. The most commonly used definition of the natural numbers ([https://en.wikipedia.org/wiki/Peano_axioms#Formulation](https://en.wikipedia.org/wiki/Peano_axioms#Formulation)) is structured in a way similar to your description: we have a single explicitly declared natural number (zero), and all other natural numbers are defined as a sequence of function applications on zero (ie 4 is defined as S(S(S(S(zero))))).

Our notation for numbers is just "syntactic sugar" on top of this representation: useful when doing practical work with numbers, but only a hindrance when you're studying the concept of "number" itself.

Analogously, in programming language theory (studying the properties of programming languages moreso than trying to do program things in them), we often prove properties of languages by studying extremely frugal, tiny languages (often called "calculi"), that only have the absolute minimum primitive constructs.

Realizing that a construct can be expressed as "syntactic sugar" on top of a simpler one (objects on top of closures, for instance), is useful in this setting because it reduces the number of cases in proofs.

<comment><USER4> This touches on an interesting topic I've been thinking about for quite some time now. I have a somewhat reverse feeling about the definition of natural numbers (or for that matter, about the 'foundation of mathematics' as in ZFC set theory or whatever you want to choose) than you've presented above.

Those definitions were developed after we had something useful in order to 'codify' it and make it more precise. They are not, in my opinion, a basic blocks that the rest is built from but an added layer of abstraction _on top of_ whathever it is you're defining.

I don't mean I don't understand set theory and the role it has, or advocating for any other system, I absolutely love it.

What I mean is, in practical things (programming languages etc.), it feels a bit counter-productive to me to reduce them to the simplest possible definitions/terms (that have to fit to the particular use case by definition), declaring that a building block and then explaining every other concept in those terms as if it was a proof that we have trully found a foundation and the rest is just a 'syntactic sugar'

edit: You all probably know this famous gif of a ballerina that can rotate to the left or to the right depending on how you think about it. After writing the above post the notion of S(S(S(S(0)))) keeps flipping in my brain between being an abstraction of and simplification of natural numbers. It's weird.

<comment><USER3> I agree with what you're saying, actually. I think these questions require drilling down to philosophical questions such as "what are numbers", "what is the essence of 'number'", "are numbers even real", etc. So I'll give it a go and be shamelessly long-winded about it :)

I think that numbers, set theory, programming languages, etc, are all abstractions. Forming abstractions is a mental tool associated with our ability for language: we spot a pattern and we give that pattern a name. Once we've given it a name, we can talk _about_ the abstract concept as a subject of our statements.

Perhaps the simplest form of abstraction we're capable of is "categorization". Ie we see a pointy-eared small animal that makes meowing sounds, we another one, and another one, ... and even though none of them are identical, our brain picks up on certain patterns in these creatures. We know that when we next see one of them, we can expect certain behaviors. So we give it a name, let's say, "cat", and now we can talk about the abstract concept of "cat" without referring to any specific individual cat. To see how big a deal this is, I find it useful to remember that cats aren't explicitly defined in the fabric of the universe, like they would be in a computer program (where we'd have a "Cat" data structure or object, usually), they're just emergent behavior of interacting molecules.

But we can do more, we can also abstract out properties of objects. We can see that some frogs have a similar color to the leaves of most trees, so we can give this leaf-color a name, "green", and talk about the abstract concept of "green" without referring to a specific green thing. You can just say "I like green" (no one will ask you "a green what?"), or "mixing green and blue makes cyan" (no one will ask "mixing green and blue what makes cyan what?").

And then we also have "chunking", where we can talk about sets of objects as objects themselves. So we can talk about "a herd of sheep" as a singular thing. Our ability to abstract out properties of objects also applies to these chunked concepts. One property of a set of objects is "quantity". Speculation ahead. Initially we probably only had fairly vague terms to talk about quantity, perhaps individual words for small quantities (one, two and three, maybe), and after that it's just "many". But it seems we figured out pretty fast that counting sheep, counting apples, or counting pebbles are really in some sense "the same thing", so we might have first learned to count through some unary "notation" even though we had no names for quantities. We'd make carvings into bone or carry a bag of pebbles, one carving or one pebble for each sheep in our herd. Then we notice that certain operations on these quantities are also all "the same": it doesn't matter whether you're adding pebbles, sheep, carvings, ... you're always doing the same thing. So after a while we start using these operations to define bigger numbers (the French still call the number 80 "quatre-vingts" or "four twenties"). Now all numbers become nameable, and eventually we streamline and standardize these names.

So now we have a name for every number, and we can talk about "thirty-two" without getting back a confused reply "thirty-two what?". And we can talk about operations on these numbers, like addition, multiplication, etc, but our hunger for abstraction isn't satiated at all. Since now we can talk about operations, we can also talk about properties of operations, so we notice that you can flip the arguments of additions and multiplications, and we give that property a name, commutativity, and we go on to invent abstract algebra.

After doing maths for a few thousand years we start looking into patterns into the different, disparate branches of maths at the time (geometry, number theory, logic, etc), and notice that the common pattern is that all of them are doing deductive reasoning, and that should be modellable by logic. So we abstract out the common bits and come up with set theory and proof theory and the like. And in that process we notice that number theory has unnecessarily many axioms and Peano figures out we can just use induction to define the set of natural numbers.

So yes, our intuition for numbers precedes Peano's definition by millennia or far more than millennia. But I'd say that's how it goes for _every_ definition. We always start by noticing some pattern, which initially we can't quite put our finger on (for example, Leibniz had a vague intuition that a lot of work in mathematics was in some sense so mechanical that one should be able to have a machine do it; he couldn't quite define computation yet but his hunch was spot-on), and then we try to refine our thoughts and come up with a definition.

In that sense, I don't think it's more meaningful to worry about the "true nature" of a number (the Peano definition, or some other notation?) than it is to worry about the "true nature" of the color red (is it its wavelength on the electromagnetic spectrum? but a wavelength can be expressed as a number; so is the essence of red just a number? or its RGB value, which is linked to how humans perceive color?). Both numbers and colors are abstractions, and abstractions are mental tools. They are a means to an end: to make sense of the world and communicate about it to other humans. And we use just use the tool that is most helpful given the problem at hand. For most practical applications we're going to use a notation that's compact and easily manipulated (Arabic numerals), but when we're studying the foundations of mathematics, it's more sensible to reduce everything to its smallest, most elegant definition possible. Neither view is "more true" than the other, in both cases you're doing no more than naming patterns in herds of sheep and piles of apples.

<comment><AUTHOR> This is a fantastic explanation ookdatnog. Thank you -- if you have a blog would post this up! More people should see this :)

</comment></comment></comment></comment></comment><comment><USER5> Objects are just a poor mans closure.

Closures are just a poor mans object.

(Not sure where this quote is from originally? Maybe here: [http://people.csail.mit.edu/gregs/ll1-discuss-archive- html/m...](http://people.csail.mit.edu/gregs/ll1-discuss-archive- html/msg03277.html))

<comment><USER6> There also is the classical example of defining _cons_ , _car_ , and _cdr_ as closures in SICP:

      (define (cons x y)
        (lambda (m) (m x y)))

      (define (car z)
        (z (lambda (p q) p)))

      (define (cdr z)
        (z (lambda (p q) q)))

Here, _cons_ , instead of returning an object with two values, returns a closure that captures the two values. _car_ and _cdr_ call that closure, passing it another closure. The _cons_ closure calls that closure, passing the the two values.

Explanation at [https://stackoverflow.com/questions/21769348/use-of- lambda-f...](https://stackoverflow.com/questions/21769348/use-of-lambda-for- cons-car-cdr-definition-in-sicp).

<comment><USER7> [https://en.wikipedia.org/wiki/Church_encoding](https://en.wikipedia.org/wiki/Church_encoding)

<comment><USER8> Also, [https://en.wikipedia.org/wiki/Scott_encoding](https://en.wikipedia.org/wiki/Scott_encoding)

Of course, it completely kills (or "stress-tests", if you will) the branch predictor in your CPU.

</comment></comment></comment></comment><comment><USER9> This both is and isn't true, and the finer points revolve around mutability/concurrency and implementation inheritance.

Modern computers are inherently concurrent and mutable, and these fundamental realities have been shown over and over again to cause hard-to-understand issues in sufficiently complex codebases. In the vast majority of OOP languages, instantiated classes are mutable-by-default and can be mutated by multiple concurrent operators (threads, coroutines, etc). This makes them actually quite similar to the underlying computing model - even though they're a high-level abstraction, they force you to deal with the knowledge that the memory at any address can be modified at any time with no warning. [1]

Classes in most languages also offer implementation inheritance, which boils down to an approach to "rebundling" the constituent functions in ways that are arguably simple enough, but generally in practice it has been found to be hard for programmers to reason about. Dynamic dispatch is very powerful, and the way that most inheritance mechanisms expose this seems to be a model that programmers understand in theory but fail to consistently remember in practice.

In my opinion, the fundamental difficulty with classes is that in most languages, you get all of these tools bundled (complected) into the same toolbox without any say in the matter. If you didn't want inheritance, too bad. If you didn't want concurrent mutability, you're now being asked to design a complex state machine to prevent it, rather than it being excluded off the bat by most functional approaches. Functional approaches force you to opt in to most of the footguns that are included "out of the box" in OOP.

Classes will remain the best approach in many OOP languages for RAII-shaped problems, where some part of an application needs to encapsulate and manage a limited, shared, and potentially mutable resource (such as a file handle, a database connection, or an in-memory cache), because classes are an abstraction that maps cleanly to shared mutable state with locking mechanisms.

[1] You can of course also shoot yourself in the foot with closures that themselves contain mutable state (e.g. some kind of mutable container), and I think this is a rarely-considered danger for functional paradigms in languages that default to mutable data structures.

<comment><USER10> I'm not sure you are really disagreeing. Which is to say I don't see where the not "isn't true" part come from.

Yes classes are closer to the physical reality of modern computer (and that is one reason I prefer C++), but they are still the same construct as a closure and vice-versa. Everything is just implementation details.

Again I grant that languages designed around classes (or really in my opinion, around the physical reality of the device implementing them) are more useful _in practice_. But from a conceptional abstraction point the post is true.

<comment><USER11> It's not true in the sense that classes are higher order functions + a lot of junk that the GP examined in some detail. All that junk adds a lot of complexity and makes classes significantly harder to work with.

</comment></comment></comment><comment><USER12> OOP is an abstraction over functions, but it can be explained much more simply without closures. Classes introduce a convenient syntax / abstraction over polymorphism, and can be written with plain functions without the need for closures. Methods are just polymorphic functions that accept an implicit "self" argument, which is used to dispatch.

Taking the example from the article:

      function Person(firstName, lastName) {
        {
          type: "Person",
          fName: firstName,
          lName: lastName
        }
      }

      function getFullName(this) {
        switch(this.type) {
          case "Person":
            return this.fName + ' ' + this.lName;
          default:
            throw("TypeError getFullName is undefined for " + this.type ".")
        }
      }

      function setFirstName(this, firstName) {
        switch(this.type) {
          case "Person":
            this.fName = firstName;
            break;
          default:
            throw("TypeError setFirstName is undefined for " + this.type ".")
        }
      }

From here whenever a "method" is called, the program inspects the "type" attribute (this process is abstracted and hidden in OOP languages), and uses that to invoke the correct implementation of the method.

      let person = Person("John", "Foo");
      getFullName(person);

</comment><comment><USER13> It's a cool idea, and I'm sure everyone gets a pleasant jolt when they make the connection (I sure did), but you probably already understood this idea at some subconscious or conscious level in order to get anything nontrivial done with a functional language.

It's one of the first things you're taught if you are learning a functional- at-its-roots language. Not JavaScript, which is mixed-paradigm at its roots. For me it was Scheme in college.

If you're learning a functional language, combining closures and functions that return functions to carry around "instance fields" and "instance methods" is what you learn right after you've gotten over the basics like map/filter and tail recursion. The equivalence of this pattern to classes is something you'll understand intuitively, even if you haven't put words to it yet.

<comment><USER14> > Not JavaScript

Funny enough, I actually had the referenced epiphany while learning JavaScript, since this idiom is so common in it.

<comment><USER13> Is it actually that common? Using a higher order function that returns member fields/methods which you then actually call?

Higher order functions are common in JavaScript, and closures are as well, but I don't recall seeing them used as substitutes for classes or vice versa for years at this point. With JavaScript you don't have to use closures and higher order functions to do modularization because you have classes, and you don't have to use the functor pattern (like Java before Java 8) because you have higher order functions.

ES5's syntax for object types looked a lot more like "closures with syntax sugar" than ES6 and later JavaScript syntax with explicit class declarations.

<comment><USER15> It's probably not common, but for me the answer lies here:

> I don't recall seeing them used as substitutes for classes or vice versa for > years at this point

I had a fairly large school project developing a JavaScript application back before ES6, and kept searching for a better way to structure my code because I found it awkward using prototypes + binding this for events. Eventually I found a hidden golden nugget of a tutorial that showed me how to do it with closures and I was in awe that it somehow wasn't the norm (and obviously how cool it was to build objects out of functions!)

</comment></comment></comment></comment><comment><USER16> You shouldn't analyse programming constructs based on their implementation in my opinion. Go down deep enough in the rabbit whole, and you'll see everything is just a Turing machine.

A more useful analysis in my opinion is to focus on the developer ergonomics of the language. That includes how the construct is used or can be used, any properties it exhibits or guarantees, what it prevents you from doing, etc.

From that lens, the ergonomics of a Class and a Function Closure are not at all the same.

</comment><comment><USER17> Review:

Consider replacing:

      return function(method) {
        switch (method) {
          case 'getFullName':
            return getFullName;
          case 'setFirstName':
            return setFirstName;
        }
      }

With:

      return {
        getFullName,
        setFirstName,
      }

And leaving client code unchanged.

This leaves callers with a struct but is cleaner and more direct. So far as I can tell, modules and closure usage are objects in JavaScript.

I'm curious if you might have insight into what this approach might block other than exclusively using functions?

<comment><AUTHOR> Hey erikerikson -- I think your solution is indeed equivalent, and I would say even more idiomatic js.

The reason I chose the first option, was to really bring home the point that all of this could be expressed with closures.

</comment></comment><comment><USER18> A class, generally speaking, is a binding of functions and data.

In the functional example, where does Person store the fName and lName variables? Is there an intrinsic/hidden 'this' pointer? If functions persist data, are they really classified as functions anymore?

The message passing part isn't very relevant, as the concept of calling a function pointer via string lookup is present in many dynamic languages (Ruby, etc).

<comment><USER19> No this is a really important question, and it has an answer.

They are called closures. They are "environments" in which variables live, each of which can have a parent environment dictated by whatever rules there are. (Some programming languages have it where every use of curly braces creates a sub-environment; in JavaScript originally only the function keyword would introduce a sub-environment and if you write `if (something) { var x = 123; }` then `x` belongs to the parent closure and it might contain `undefined` if the branch was not triggered. Since then JS has introduced let/const which are scoped to curly brackets.)

When you declare a function it still has access to the full space of variables which it was lexically defined with. If you mutate those with one function then another function which has access to that environment can see those changes, etc.

<comment><USER18> Good point, I guess what I was trying to get at is that an object is more equivalent to a closure (function + data i.e. local stack environment) than just a function (which executes with input parameters). The top-voted response put that more eloquently than I did.

</comment></comment></comment><comment><USER20> Actually, the more precise formulation would be: classes are related to functions as both are abstractions.

The author conveniently leaves out the differences: classes yield objects, whereas functions yield any kind of value. Classes are second-class citizens, whereas functions (usually) are first-class. Functions _have_ a type, whereas classes (often) _are_ (or are isomorphic to) one.

</comment><comment><USER21> Higher order functions are just a fancy way of writing classes.

</comment><comment><USER22> You can implement an object-- a data abstraction technique where the said data (the attributes) is hidden behind a set of operations (the interface)-- with classes or high order functions or prototypes but that doesn't mean those are equivalent, especially software engineering wise.

</comment><comment><USER23> Well, somewhat. Passing messages is inherently more dynamic, as you can see: you can change the string to anything at runtime, even something that doesn't exist, you can intercept the message and send it somewhere else or handle it however you wish. Static dispatch doesn't let you do this, but you generally get the advantage of faster calls and better compile-time diagnostics. In simple cases, the programming style can be similar, but for more advanced features they really differ in the kinds of things they support.

</comment><comment><USER24> Maybe I'm confused by this particular example, but what languages would allow functions to store the value of the constructor like that without closures? The thing I don't like about closures is that they can get messed up easily, and not even all OO languages support them.

I often think of functions as intentionally "stateless", NOT persisting any value. For that a class is used, if anything for safety.

<comment><USER25> > Maybe I'm confused by this particular example, but what languages would > allow functions to store the value of the constructor like that without > closures?

It's javascript, where all functions are closures.

</comment></comment><comment><USER26> I don't get why so many JavaScript developers thing functional is cool. Functional has been around for 30+ years. OOP won against functional because OOP is easier to understand and leads to more maintainable code. These days people are taking a second look at functional because functional avoids state, which makes it easier to write concurrent code with no locks. (This has suddenly become important because Moore's law is coming to an end, and CPUs are adding more cores instead of making cores faster and faster.) But this advantage of functional is not applicable to JavaScript because there are no locks in JavaScript in any case!

Functional programming actually brings some benefits to backend code. To take advantage of the extra cores in a CPU you add threads, but if these threads are continually needing to lock in order to serialize access to shared state then concurrency is diminished. The more cores you have, the more threads you have, and then the more you have to lock. Functional style solves this problem by not having mutable state.

But when it comes to JavaScript these benefits don't exist. That's not to say there are no benefits at all to incorporating some functional style into JavaScript code, but wholesale replacement of OOP with functional style is not warranted.

<comment><USER27> Functional programming is getting popular in JavaScript not because of serializability of state changes across threads, but because immutable state and immediate-mode GUIs go hand in hand. React, as an example, works as an immediate-mode GUI (re-rendering VDOM on every state change) on top of a retained-mode GUI (the DOM). You manipulate your state using reducer functions and the library works behind the scenes to convert that to a UI. It alleviates all of the weirdness and performance issues of interacting with the DOM when state changes.

GUI programming is traditionally retained-mode. OOP is traditionally state encapsulation and mutability. OOP and retained-mode GUIs are conceptually similar, and Functional Programming and immediate-mode GUIs are conceptually similar.

Here's a good explanation of this: [https://medium.com/@puppybits/immediate- mode-reactjs-7a6302c...](https://medium.com/@puppybits/immediate-mode- reactjs-7a6302cd89cd)

<comment><USER26> I don't see parallels between OOP and retained mode, and functional and immediate mode the way you are describing. UI components inherently have state. Pretending they can programmed in functional style with stateless functions is bizarre because UI functions do have side effects. See prior discussion: [https://news.ycombinator.com/item?id=24363261](https://news.ycombinator.com/item?id=24363261)

<comment><USER27> Yes, ui components have state in the case of a retained mode GUI like the DOM, but in the case of React, relevant data is derived from the application state (eg IsDarkMode is a state property used to derive colors for a component, or the checked state of a checkbox) and a unidirectional flow propagates that state change to the VDOM on every re render. Functional doesn't mean stateless (state exists as closures within higher order functions, such as in the composition of functional components within React), it means side-effect-free, it means determinism in the derivation of additional state based on immutable state updates.

<comment><USER26> > _Functional doesn't mean stateless (state exists as closures within higher > order functions, such as in the composition of functional components within > React)_

Being stateless and side-effect free is pretty fundamental to functional programming. If you can't replace a function call with its resulting value (without changing the meaning of the program) then it is not functional programming.

React is neither stateless nor side-effect free. Mapping it to concepts from functional programming is counter-productive. You get something that is neither fish nor fowl.

</comment></comment></comment></comment></comment><comment><USER28> See also: Let Over Lambda for more on this.

<comment><USER29> +1. "Objects are a poor man's closure, and closures are a poor man's object."

<comment><USER30> I understand the amusement value of this quote, but I never quite understood what is so poor about a tuple of functions closed over same data into a closure. Apart from inheritance, what does it lose. In fact its good that it loses inheritance. Syntax of many OOP languages makes it way too easy to use inheritance -- common things ought to be easy and potential design mistakes hard.

<comment><USER25> > but I never quite understood what is so poor about a tuple of functions > closed over same data into a closure. Apart from inheritance, what does it > lose.

In the closure-based version, getFullName and setFirstName are defined anew for each instance of Person, using more memory each time. Typically isn't an issue unless you're creating a massive number of them, but the class-based version doesn't have this problem.

Also, just to throw it in the mix as well, the class-based version I believe is largely just syntactic sugar over the traditional way of creating objects in javascript, using prototype-based methods:

      function Person(firstName, lastName) {
        this.fName = firstName;
        this.lName = lastName;

        return this;
      }
      Person.prototype.getFullName = function() {
        return this.fName + ' ' + this.lName;
      }
      Person.prototype.setFirstName = function(firstName) {
        this.fName = firstName
      }

      const person = new Person("Ben", "Bitdiddle")
      person.getFullName()

Prototypical inheritance is interesting in that an instance of Person could be used as the class for another object, ad infinitum.

<comment><USER31> An optimizing compiler could easily detect that a bunch of closures share an upvalue block in an enclosing "constructor" and then instead make that block explicit, and rewrite an entire constructor in a way that doesn't involve multiple closures at all (given that escape analysis and lang rules allow that). E.g.:

      // optimized
      function constructor(...) {
        let this = {...}
        function method(this, ...) {...}
        return function (name, ...) {
          switch (name) {
            case 'method': return method(this, ...)
              // or return a temp closure
              // like it does in tfa

      constructor()('method', 42)

And vice versa, on a computer that does closures in hardware better than objects for some unrealistic reason.

That's why both are just _abstractions_ , whose semantics may better fit one or another implementation, but it really doesn't matter for maths.

</comment></comment></comment></comment></comment><comment><USER32> would any devs want to start a book club for books like this? the article mentions SICP, which is on my to-read list. it just seems so daunting. i'm currently reading practical object oriented design in ruby by sandi metz. would love to have somebody to discuss some books like this.

</comment><comment> aaron-santos Tangentially related is the idea that some OO constructs can be represented as co-data. Previous discussion here [https://news.ycombinator.com/item?id=24105755](https://news.ycombinator.com/item?id=24105755)

</comment><comment><USER33> Classes is a semantic way of organizing your zillion of higher order functions, that would otherwise be just floating around. Beans is the way to build higher order data. Mixing them with care is the art of programming.

<comment><USER8> God forbid the 'sin' function would be just floating around, outside of a static 'Math' class. Or 'reduce', for that matter—obviously you need a special 'Reducer' class for that.

That reminds me of Steve Yegge's "Execution in the Kingdom of Nouns", actually.

<comment><USER34> A math module or namespace would be nice. Also for C headers I'd like to do "from math.h import inf" to resolve conflicts with <cmath> and c++11 with non- compliant implementations.

</comment></comment></comment><comment><USER35> that's one way of formulating it. another would be: classes are just a set of methods with a common set of parameters (constructur) already applied (partial application)

</comment><comment><USER36> Isn't the function or OOO is just message passing?

</comment><comment><USER37> I see classes as nodes in the power grid that transmits and transforms data instead of electricity. These nodes are wired up to other nodes via methods - their binding points. To be precise, a class is more like a spec that can be used to build an instance of that node. In some cases there's only one instance.

The main advantage of classes, I think, is that they define one underlying principle for all these data transformer nodes: that each node has a few binding points with certain interface: named methods. The nodes don't have to look this way, but restricting the freedom of design choices to this pattern makes it easier to compose many nodes together. It's like setting the expectation that all cars are squarish: it's easier to build the infra around cars when you know how they can look in general.

</comment><comment><USER38> Ok. No. There's a lot of confusion with semantics. Following the most used definition of OOP as defined by JAVA, C++ and C#:

Classes are in no way functions in the FP sense because classes mutate state.

Classes are in no way functions because calling methods requires the instantiation of unrelated state. Example:

       class A
           def __init__(self, a, b, c):
              self.a = a
              self.b = b
              self.c = c
              self.banana = create_banana(create_gorilla(create_jungle()))

           def process_a(self):
              return process(self.a)

process_a cannot be used unless a, b, c and the banana plus the gorilla holding the banana and the entire jungle the gorilla lives in is instantiated.

Let's talk about terminology. There are three that often get mixed up.

       Procedure = a set of instructions that could encompass mutating and changing state.
       Function = a box that when given input produces an output. The box cannot modify the universe. It can only produce something new when given an input.
       Object = A grouping of a set of procedures and state that can mutate.

The javascript programmer OP is mixing up function and procedure. He defines a procedure and says that it can be a class. A procedure can be a class as it's just a set of instructions which can encompass defining scope, state and more procedures restricted to scope and state (aka an object).

This thing right here, written by the OP:

      function setFirstName(firstName) {
        fName = firstName
      }

Is not a function... it is a method or a procedure that mutates state.

A function can do none of the above.

That's it.

<comment><USER39> You're making an argument from definitions that would exclude ML from being a functional language, which is absurd.

<comment><USER38> No I'm using the mathematical definition of a function. ML is not Math nor is it purely functional.

All functional languages need to bend the rules a bit in order to have side effects but in general the person is not writing functions and therefore is not getting the benefits of using functions.

FP is about reducing and restricting these functions that break the rules. Defining a class in terms of mutations and side effects is going against the philosophy of FP.

<comment><USER39> > No I'm using the mathematical definition of a function.

 _Which_ mathematical definition? A "box" is not a mathematical definition. There are multiple mathematically precise definitions of "function" possible. Yours is none of them. Some of them accommodate objects that model mutable state.

I don't think many (any?) PL theorists or functional programming practitioners would agree with your dogmatic stance. Where are you coming from with all this?

<comment><USER38> I'm not having a dogmatic stance please stop voting me down. I'm tired of juniors who think they know what they're talking about. Just stop.

[https://www.wikiwand.com/en/Function_(mathematics)](https://www.wikiwand.com/en/Function_\(mathematics\))

That is the definition of a function. Quite complex. I simplified the explanation by using a Box. You will note in the wikipedia article they also have a picture of a Box with inputs and outputs. That is the essence of functional programming. Now please don't turn this into a immature pedantic argument about some obscure definition of a mathematical function.

>I don't think many (any?) PL theorists or functional programming practitioners would agree with your dogmatic stance. Where are you coming from with all this?

Uh they do (and it's not a dogmatic stance, the definition of FP is quite blurry, but immutability is universal). The point of functional programming hence the name is for the programming to follow mathematical functions as closely as possible.

In the ideal world your program in FP is just one giant pure function that is a composition of other smaller functions. Of course your functions need to have side effects so they come up with all kinds of tricks or bend the rules a bit so that you can have things like IO and side effects but these are just exceptions to the rule.

The philosophy of functional programming is to make your program as pure as possible and minimize or segregate side effects away from your program as much as possible.

This is essentially what and all that Haskell is. Haskell uses a trick, a VM that takes an IO monadic Value and does side effects with it. Outside of that VM all the user does to the program is write Pure functions and compose them all together into a single function called Main. That's it.

That's literally what haskell is, and if you think PL theorists don't agree with my "dogmatic" stance which is to say not "dogmatic" at all then you really don't know what you're talking about because Haskell is basically designed by the best in class functional PL theorists.

Let me put it simply for you.

If you can put your entire program in a single expression then you are doing functional programming. That is what functional programming is. There are no steps or procedures that happen one after the other. Every value is defined permanently. There's no concept of time or procedures in functions that's why you can't have variables getting assigned or mutated in FP.

You can only define things in functional programming as they are right now without the concept of time in FP. Procedural programmers tend to create buckets of empty data variables to be filled in over clock cycles.

If you don't get this, you don't understand functional programming.

In an expression, you cannot mutate values you cannot have procedures or loops. Why do you think FP is loaded with recursion? If they allowed setters and getters and mutation like the example then we might as well add a jump command while your at it and suddenly we can use loops in functional programming.

You just don't get it man. Dogmatic my ass, not even close.

<comment><AUTHOR> You have missed the point.

It's curious you think this piece is written by a "JavaScript programmer", and the person who responded to you here is a "junior" — the implication being that you know more.

It might help to take a step back and assume intelligence in others: what if these people are smart? What could you learn from them? If you think the idea is wrong, assume it's coming from a peer. One way you know you are doing that, is if you form your disagreement as a question.

—

I took the time to respond to you, because it looks like you have some real love for programming, but know less than you think. You can grow a lot more if you shift some of your thinking

<comment><USER38> >You have missed the point.

Tell me what you think the point is. Typically when someone thinks a point was missed they address the point rather than devolve the conversation into a condescending description about my character and how I should act. It's a sort of tactical what you're doing here. But who cares, no one is reading.

It's curious how you don't even address my points and just say that I missed the point when I'm the one dictating the point in my original comment. Typically this isn't how you respect other people and get them to respond positively to your comments, what you're doing will draw other people to support you but anger your target because of the condescension. I'm not sure what you're objective is because people aren't really reading this thread... it's already buried.

>It's curious you think this piece is written by a "JavaScript programmer",

The examples in the original piece are in javascript. Why don't you RTFA before commenting on the "point."

>and the person who responded to you here is a "junior" — the implication being that you know more.

The Junior thing was more of a retort. I said it with full awareness of what it implies and how the other person would take it because his tone obviously implies that he doesn't think he's a junior. Basically the replier has his own opinion which he is entitled to say (and that I respect) but when you say things like "dogmatic" and then vote me down... that's just not respectful. Since I can't vote him down I inject a bit of subtle rudeness in my replies as a subtle retort in return. Just being a mirror. Similar in a way to the subtle game you're playing. That's all this is.

>It might help to take a step back and assume intelligence in others: what if these people are smart? What could you learn from them? If you think the idea is wrong, assume it's coming from a peer. One way you know you are doing that, is if you form your disagreement as a question.

Maybe you should take a step back and look at your own post. Telling people to shift their thinking implies you have a sort of superiority complex. As if you're not the one that's mistaken. How do you know I'm not a peer? How do you know I'm not superior. Perhaps you should take a look at yourself. You seem like a guy who thinks he's superior to me in programming but you haven't demonstrated as much, you haven't even addressed the point.

You went on a side tangent talking about my behavior. Trust me, if you want someone to change or listen to you, talking to them like this is not the path.

You want to know what will make people respond to you and listen to you? Address them without any subtle disrespect. It's very simple.

You could've responded to me like this:

       I disagree with you. I also think there was a misunderstanding of the point. Here's why...

By proving the other person wrong without being disrespectful you can change the other person's' character. But obviously this isn't our objective here is it?

That being said take a look at this wikipedia post and tell me. Who missed the point?

[https://www.wikiwand.com/en/Functional_programming](https://www.wikiwand.com/en/Functional_programming)

       "Functional programming is sometimes treated as synonymous with purely functional programming, a subset of functional programming which treats all functions as deterministic mathematical functions, or pure functions. When a pure function is called with some given arguments, it will always return the same result, and cannot be affected by any mutable state or other side effects. This is in contrast with impure procedures, common in imperative programming, which can have side effects (such as modifying the program's state or taking input from a user). Proponents of purely functional programming claim that by restricting side effects, programs can have fewer bugs, be easier to debug and test, and be more suited to formal verification.[1][2]"

Literally that's the definition I'm following. It's one form of the definition and certainly a popular one. That's my opinion. You disagree? You think I missed the point? Elucidate. The original poster can disagree but my opinion is far from as he puts it "absurd."

Read the article. What definition of functional programming does that class with a setter even fit under? Ok he redefined it as a higher order function... Is what he doing procedural programming or functional programming. It looks to me he's doing a bit of everything and calling it a function. Does the guy even know that the class keyword is just sugar for "function" in javascript?

Look at this: [https://developer.mozilla.org/en- US/docs/Web/JavaScript/Refe...](https://developer.mozilla.org/en- US/docs/Web/JavaScript/Reference/Classes)

Literally it says "classes" are just special functions. He's just reiterating the javascript spec as if it's a new fangled discovery. In fact, before ES6 all "classes" were written with the keyword "function." No dude. The article writer doesn't get it and neither does the person who responded to my post. When you do OOP with LISP you're not doing FP period. The article writer just noticed an isomorphism and is likely amazed by what all JS programmers were doing before ES6. Not to be insulting but the parent poster likely doesn't have much experience.

>I took the time to respond to you, because it looks like you have some real love for programming, but know less than you think. You can grow a lot more if you shift some of your thinking

I too took the time to respond to you. Despite your condescending attitude/game. Let's see where this goes.

<comment><USER39> If you decide to dismiss a position by saying that it chose the wrong definition, you're not contributing anything useful. "Pure" functional programming is not more functional programming than "Functional programming", the adjective specializes it and makes it more narrow. I don't really care what a wiki article says. I can run a survey of my colleagues if you want?

As for calling me a junior, well, you don't know how much experience I have, do you? It's probably more than you, though. I've used and participated in the development of functional programming languages for over a decade at this point.

Unsolicited advice: Sophomoric pedantry isn't a good look.

<comment><USER38> >Unsolicited advice: Sophomoric pedantry isn't a good look.

Starting conflict and calling people "dogmatic" and voting people down is not a way to win people over. I can see a number of paths this road could have gone down where you can easily get another person to agree with your ideas as an alternative viewpoint despite a wikipedia article saying otherwise. You chose to take none of these roads, maybe largely because you don't know how to do this.

>I don't really care what a wiki article says.

Right because your opinion is the best opinion and only opinion that matters. The community opinion and the majority opinion has no relevance to you because you participated in "functional development for over a decade." Whoop dee doo. I chose a definition of functional programming that has huge relevance to the community at large. You on the other hand... haven't even stated your definition yet.

Unsolicited advice: Arrogance and the inability to admit your own mistakes is not a good look. A decade of experience does not earn you the right to act like an ass hole nor does it make you a good programmer.

<comment><USER39> You chose a definition among many and then dismissed the submission as "confused" because it does not meet your definition.

I noted that your definition would preclude ML functions from being called functions. Your response was that ML wasn't _purely_ functional, but that doesn't make it not functional. The pure in "pure functional" doesn't "to the exclusion of non-functional", it is simply a narrower category.

Considering that ML is one of the most impactful functional programming languages both in theory and practice, I think it's right to call that absurd and dogmatic. If you take it as a personal attack that I called your argument absurd, I don't know what to say. Maybe grow a little bit of skin?

> You on the other hand... haven't even stated your definition yet.

I don't need to provide a definition to find a flaw in yours. I did not come into this submission looking to smugly dismiss the topic at hand with my obviously irrelevant preferences for terminology. You did.

<comment><USER38> >You chose a definition among many and then dismissed the submission as "confused" because it does not meet your definition.

My definition? I quoted wikipedia. A lot of people use "my definition" Basically under "your" definition C++ and go might as well be a functional programming language.

>Considering that ML is one of the most impactful functional programming languages both in theory and practice, I think it's right to call that absurd and dogmatic. If you take it as a personal attack that I called your argument absurd, I don't know what to say. Maybe grow a little bit of skin?

Why grow skin? I literally didn't care. I just decided to call you junior because you were acting like one. It seems like you cared more. I was just explaining to the other guy why I called you a junior. I recognize the attack but I literally don't care, but that doesn't mean I won't respond or address it.

>I don't need to provide a definition to find a flaw in yours. I did not come into this submission looking to smugly dismiss the topic at hand with my obviously irrelevant preferences for terminology. You did.

My Definition doesn't have flaws. Like I said, if I expand it to encompass mutability (as you have) then you can place Go and C++ on the functional pedestal. I haven't used ML but clearly a language like ML only allows mutability as a small exception that's rarely used otherwise there's no point to classify ML as functional.

But let's get back on topic. You literally said that no PL theorist would agree with me. But look at wikipedia. Apparently many do. So you're wrong.

<comment><USER39> I don't take wikipedia to be authoritative about anything but I'll bite.

> Functional programming is sometimes treated as synonymous with purely > functional programming, a subset of functional programming which treats all > functions as deterministic mathematical functions, or pure functions.

Well, obviously in this context the author of the submission wasn't using that definition. So you coming in and dismissing the conversation because _sometimes_ people mean "pure functional programming" when they say "functional programming" is clearly erroneous. I know when people make this conflation, often when they're talking about Haskell. When talking about ML, no one would take that synonym. Context matters.

I just looked, you provided a set theoretic definition of functions, the wikiwand one. You chose a poor definition for the topic at hand. In most mathematical settings it would be a perfectly fine definition, but not here. Context matters.

Here are the problems with it: It assumes an interpretation in sets when there are a plurality of interpretations of functions qua functional programming which are not compatible with set theoretic models. For example, functions in homotopy type theory have higher dimensional structure than just being elements of a set. Functions in domains have more structure than just the extensional mapping from inputs to outputs. Your chosen definition also includes non-computable functions which are simply not admissible in this context.

So your definition is simultaneously too restrictive and too lax.

You seem to be confused by the existence of multiple definitions and how they are appropriate in context.

<comment><USER38> >I don't take wikipedia to be authoritative about anything but I'll bite.

No but it's more authoritative than a random person on the internet (you). For things like this it's good enough. I'm not writing a paper here.

>Well, obviously in this context the author of the submission wasn't using that definition.

>Context matters.

>In most mathematical settings it would be a perfectly fine definition, but not here.

In this context it's also perfectly fine. OP did not make a distinction between subroutine or function. He also uses the term higher order function wrong. It shows two things. He does not know what a higher order function is and he does not know what a function is.

>Here are the problems with it: It assumes an interpretation in sets when there are a plurality of interpretations of functions qua functional programming which are not compatible with set theoretic models. For example, functions in homotopy type theory have higher dimensional structure than just being elements of a set. Functions in domains have more structure than just the extensional mapping from inputs to outputs. Your chosen definition also includes non-computable functions which are simply not admissible in this context.

This is the garbage pedantry that I warned you about earlier. I'm choosing the generally accepted academic definition. Hopefully you're not one of those people who can't comprehend "generally accepted" without an expose into axioms and different obscure branches of math.

>You seem to be confused by the existence of multiple definitions and how they are appropriate in context.

Find the generally accepted definition in wikipedia that this person is using (Hint: no actual technical definition exists). Obviously he's using "function" in place of procedure or subroutine. But then he uses the term "Higher Order" to imply an actual functions instead of procedures.

Not only does he use "Higher Order" incorrectly but his usage of the term indicates he doesn't know what a function is and the difference between a function and a procedure.

Yeah I'm not going to reply to your shit any more. HN really needs to change the policy of not letting parent posters vote others down.

<comment><USER39> > This is the garbage pedantry that I warned you about earlier. I'm choosing > the generally accepted academic definition. Hopefully you're not one of > those people who can't comprehend "generally accepted" without an expose > into axioms and different obscure branches of math.

I think you should look into domain theory it is one of the most celebrated discoveries pertaining to the semantics of functional programming languages. And maybe you'll understand that from a programming point of view, what a function is is much more flexible and subtle than you think.

> Yeah I'm not going to reply to your shit any more. HN really needs to change > the policy of not letting parent posters vote others down.

Would it help if I pretended that you downvoted me? Every time I see my imaginary internet points I will subtract 5.

<comment><USER38> No you should just stop voting me down. I'm literally going to go negative soon, I just joined. I literally cannot talk to you if you continue voting me down. It's bad form.

>I think you should look into domain theory it is one of the most celebrated discoveries pertaining to the semantics of functional programming languages. And maybe you'll understand that from a programming point of view, what a function is is much more flexible and subtle than you think.

Sure I could. But "context matters." This is not the topic of the conversation. There's a level of depth we're operating at here. Very few people understand "domain theory" and you shouldn't assume as much when you communicate with anyone.

<comment><AUTHOR> Admittedly I downvoted this one: [https://news.ycombinator.com/item?id=24438137](https://news.ycombinator.com/item?id=24438137)

Yet again though:

"Random person (you)" "he does not know what a function is." "Yeah I'm not going to reply to your shit any more."

...give a good reason

\---

Anyways, leaving this thread. I certainly learned something from it, I hope you did too! : )

I now noticed you're at -1, went ahead and gave you an upvote. Hopefully you can still post, and be a bit more aware.

\--

Also, great work trying to explain bitdizzly. Def enjoyed reading your explanations, and will explore some the references you popped in

<comment><USER38> There's nothing for me to learn here other than domain theory which is very advanced math and how people behave.

If you follow the conversation you'll see that the entire argument turned into a battle of definitions with me turning to a very generally accepted definition of a function and bitdizzy turning to using more obscure mathematical definitions of "function" and arguments about semantics what context is relevant to what definition of "function." Whatever definition you choose to believe domain theory looks like very advanced stuff and clearly outside the scope of your average technical conversation.

Either way, I didn't have time to respond to your other comment below. But I will now.

Don't worry about the upvote thing. It's just for this thread I can switch accounts.</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment>


The reason Slack became a billion dollar company - <AUTHOR> https://medium.com/@satyavh/the-real-reason-slack-became-a-billion-dollar-company-f14c22b15a29

<comment><USER2> There's really no story here. This is just one persons biased and ill-informed perspective of slack, with a mix of twitter because why not.

Maybe to the author, these are brilliant insights. to me, they read as attempts at content and justification for an article on medium. I tried to pluck out some useful takeaways, but found none to be had. There's really no content to it.

Maybe it just needs more time in the oven; although I didn't notice any huge gramatical or spelling mistakes. Nor did I find the authors tone and presentation unpolished. Really, the article itself was just lacking.</comment>