Mark Pilgrim reboots the discussion on Silverlight - <AUTHOR> http://diveintomark.org/archives/2007/05/02/silly-season <comment><USER2> An excellent put-down of vendor lock-in. For the good of the industry, I hope he's right, and the standards-based web continues (for the most part, i.e. overlooking multimedia) to thump vendor-specific solutions.

However, MSFT has a much greater ability than either Adobe or Sun to cram things down the user's throat. They have their 'update' services, their ability to bundle, and their presence on the desktop with which to nag. This could help them w/ Silverlight market penetration, a prerequisite for making that platform a competitor to the standards-based web .

<comment><USER3> ....And for the good of the poor schlubs who ask for nothing more than decent quality video and well performing, featurefull apps delivered to their computer or phone, I for one hope whoever can deliver an infrastructure capable of doing that thumps whoever can't. Standards are a nice way of encoding minimal required commonalities for a class of something, but should never be used to prevent anyone from going above and beyond.

I also suspect MSFT's ability to cram anything down the throat of subjects opposed is highly overrated. I personally bought my first windows machine a few months ago, having been (still am) a mac, sometime linux, user for years. If Silverlight (or flex/flash) gains huge penetration, it is likely because people prefer having it to not, not because of any 'cramming' by MS/Adobe.

<comment><USER2> Just to clarify: The whole point of a healthy industry (i.e. a vibrant, competitive one) is to provide low-cost, high-quality products to the consumer. Standards are a means to that end. Vendor lock-in, on the other hand, stifles competition, and produces lower quality at a higher price.

Consider how unfortunate it would be if, for instance, the WWW were built not on W3C standards, but on proprietary technology; say IIS, IE, and an undocumented network protocol. In that case, innovation would slow remarkably. Competitive browers (Firefox, Safari) could not be developed because they couldn't talk to the IIS servers (the protocol is secret, remember) and competitive servers (Apache) could not be developed for the same reason. The only way competitive products could emerge would be for some firm to develop a client/server/protocol stack, and market the hell out of it until it achieved sufficient penetration to be successful.

It's a lot cheaper to compete when the protocol is open, competition is what produces great product, and that's why I think it best that solutions built around open standards not just thump, but crush any proprietary alternatives. Multimedia is a bit of a disaster in this regard, but I see no reason RIA need go the same way.

I can't get on board with the notion that standards are only good for lowest- common-denominator sorts of things. The internet seems to work ok, for instance. As for people going 'above and beyond', to the degree that such activity represents the 'extend' part of E/E/E, standards can't prevent it, but responsible people ought to shun it.

As for MSFT's ability to cram product: they can bundle with an OS that has 90%+ of the market. I don't think their ability to guarantee their products penetration (not necessarily use, not necessarily sales, but availability) is a matter for serious dispute. If they want Silverlight to be a viable platform, they just have to roll it into IE 7.X or IE 8.0.

</comment></comment></comment><comment><USER4> Bravo Mark for saying what a lot of us were thinking!</comment>


The End of Full-Time Work in the American Retail Service Sector - <AUTHOR> http://www.forbes.com/sites/warrenmeyer/2013/04/17/the-end-of-full-time-work-in-the-american-retail-service-sector/ <comment><USER2> The author is being deceitful with his chart and it throws this entire article in question. Just because you draw a line and call it stagnation doesn't mean it is. The chart is a monthly change in employment not cumulative growth.

[http://reflectionsofarationalrepublican.files.wordpress.com/...](http://reflectionsofarationalrepublican.files.wordpress.com/2011/07/bush- vs-obama-total-private-jobs-full-picture-june-data.jpg)

</comment><comment><USER3> News Flash: This has been going on for a long time. I remember while working at the Palo Alto Whole Foods (2008-last year), that almost no one in my department worked 40 hours, except the supervisors. Of course the article is a bit biased to begin with-its like reading an indictment of unions from a manager who doesn't want the wealth to trickle down to the peons.

<comment><USER4> I'm just going to throw this out there: the UFCW has had Kroger, Safeway, Supervalu, and the other major players paying for fully subsidized insurance. Every employee working more than 80 hours a MONTH has had medical insurance for their families for more than 20 years.

And Safeway's president reworked the plan 10 years ago to require preventative care like annual physicals, arguing that the ounce of prevention was cheaper than the pound of cure.

</comment></comment><comment><USER5> The conclusion drawn at the end, via chart, is completely wrong.

It's wrong for the same reason the old Bush vs Obama job chart from the election period was wrong (both sides context dropping).

There is a reasonable limit to the number of jobs an economy will or can lose, unless you're talking Zimbabwe style economic armageddon (that takes decades typically top to bottom). Even then, in the most extreme of scenarios, it runs out.

After the point of maximum damage, job losses will revert to close to nil by default. The side the author is claiming as recovery, is not recovery but rather it's continued job losses in fact (at a gradually lessening rate). So it's remarkable to see it used as an indication of recovery, when it doesn't inherently indicate any sort of thing. A chart with an arrow pointing up does not mean recovery.

If you took a look at the Spanish economy right now, which suffers from intense 27% unemployment, you could run a similar chart on their unemployment. For it's a mathematical requirement that eventually the job losses must slow to a trickle, and at that point some idiot economist could claim that as a proof of recovery via a similar chart with a fun arrow pointing up to lessened job losses. Noone would confuse 27% unemployment, in which there are low job losses, as a proof of recovery - context matters.

In the same vein, producing 100k jobs per month on average is no proof of stagnation just because the average is flat. That is to say, there's literally zero strong evidence to suggest it would have been better without Obamacare. The US economy has problems far worse than the mess that is the implementation of Obamacare. We began losing massive numbers of manufacturing jobs at far back as the 1970s, all the way through the 1990s and 2000's. The inflation disaster the Fed gave us over those 40 years, is continuing today, and is approximately a million times larger a financial issue than Obamacare. If you wanted to look for the reason for the destruction of below middle class paying jobs in America (most service jobs), that'd be the first place to start (the impossibility of keeping up with just 3% to 5% perpetual inflation).

A real discussion on all of this would require detailed information on the types of jobs being created, the number of hours those workers were getting, the portion of those that are 2nd or 3rd jobs, and so on. It would also require examining the number of people falling out of the work force versus jobs created, and on and on and on. That would be context.</comment>


The Rise Of Functional Programming: F#/Scala/Haskell and the failing of Lisp - <AUTHOR> http://blogs.msdn.com/brandonwerner/archive/2008/09/16/the-rise-of-functional-programming-f-scala-haskell-and-the-failing-of-lisp.aspx <comment><USER2> Can someone please explain in basic terms, what exactly are the advantages of functional programming, over other mainstream approaches like OOP? AFAIK, some FP support was added to the newest version of C#, but I couldn't immediately tell how exactly can I make use of it.

<comment><USER3> Just look at some simple uses of closures and you'll see they open a world of possibilities. (and there's so much more to it than this!) They also let you make compilers easily but I won't get into that here.

      CL-USER> (sort (list 1 8 3 2 5) #'<) ; sort just needs a function of 2 arguments that tells if the first parameter is strictly less than the second
     => (1 2 3 5 8)
     CL-USER> (sort (list 1 8 3 2 5) #'>)
     => (8 5 3 2 1)
     CL-USER> (sort (list "hello" "HELLO" "hey" "bye") #'string<)
     => ("HELLO" "bye" "hello" "hey")
     CL-USER> (mapcar #'1+ '(1 7 3 9))
     ;mapcar applies a function to each element of the lists passed as arguments and returns a new list with the results
     => (2 8 4 10)
     CL-USER> (cons 1 2)
     => (1 . 2)
     CL-USER> (mapcar #'cons '(A B C) '(1 2 3))
     => ((A . 1) (B . 2) (C . 3))
     CL-USER> (defun make-adder (how-much-to-add)
     	   (lambda (initial-value)
     	     (+ initial-value how-much-to-add)))
     => MAKE-ADDER
     CL-USER> (mapcar (make-adder 10) '(1 7 3 9))
     => (11 17 13 19)
     CL-USER> (defvar *my-favorite-adder* (make-adder 42))
     => *MY-FAVORITE-ADDER*
     CL-USER> (mapcar *my-favorite-adder* '(1 7 3 9))
     => (43 49 45 51)
     CL-USER> (defun make-modifier (operator operand) ; a bit more general than make-adder
     	   (lambda (initial-value)
     	     (funcall operator initial-value operand)))
     => MAKE-MODIFIER
     CL-USER> (mapcar (make-modifier #'expt 3) '(1 7 3 9))
     => (1 343 27 729)
     CL-USER> (find-if #'numberp '(a "hi" nil 8 "test" 100))
     => 8
     CL-USER> (find-if #'numberp '(a "hi" nil 8 "test" 100) :from-end t)
     => 100
     CL-USER> (apply #'+ (remove-if-not #'numberp '(a "hi" nil 8 "test" 100)))
     => 108

That's _not even_ (by a long shot) the tip of the iceberg.

<comment><USER4> It's simple to compile because lisp is essentially a parse tree, which eliminates the parsing stage in compilation.

<comment><USER3> I was referring to the ability to traverse a tree structure (made of conses or objects) and generate a tree of closures from that.

Instead of interpreting the tree structure, you make a first pass where you do a lot of dispatching in advance (at runtime you'll just do what you must do instead of first figuring out what to do and then do it), generating a tree of closures. Then you call your "top-level" closure for a nice optimized run. You can optimize your source tree before compiling this way, for some crazy speed.

All this without having to read advanced books about low-level compilers, parsing, machine architecture and optimization!

<comment><USER4> V. interesting, thanks:)

</comment></comment></comment></comment></comment><comment><USER5> I'm intrigued by the idea of Lisps built on top of other run-times.

Clojure is the example here that all the cool kids are talking about. But I just notice Nu in the list of functional languages the article mentions, which is a Lisp built on top of Objective C. The creator of Nu points out he wanted a Lisp to extend C, and that Objective C provided a dynamic run time to build on while still allowing the incorporation of straight C code. I suspect there is a good .Net Lisp out there somewhere, I just don't know what it is.

Building a Lisp on top of these languages gives you macros, code as data, culture of functional programming, etc. while still making all of the underlying libraries available.

<comment><USER6> That is probably the future of lisp - I mean we can see it already. Clojure is one example (in use in some startups) and arc is another (being built on MzScheme - although thats probably more for practical reasons).

</comment></comment><comment><USER7> A response by Dan Weinreb: [http://danweinreb.org/blog/the-failure-of-lisp-a- reply-to-br...](http://danweinreb.org/blog/the-failure-of-lisp-a-reply-to- brandon-werner)

</comment><comment><USER8> _It was the most thorny and un-inspiring community I've ever participated in, despite my extreme interest in the language. It's jaw dropping that a language with such promise has sat out the resurgence, and speaks to what an un- friendly and un-inviting community can do a technology platform._

As a Lisp newb who frequents #lisp every now and then, I've noticed quite the opposite. People in the channel are very open to newcomers and as friendly as hackers can get.

Uninspiring? Why? Lack of smug as Cal Hendersen says?</comment>


MNT Reform: DIY portable computer - <AUTHOR> http://mntmn.com/reform <comment><USER3> Tiny quibble, but it's mentioned more than once in the article that the NXP i.MX6 is an "ARM9" processor. It is not.

i.MX6 uses ARM Cortex-A9 which is very different from ARM9.

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

[https://en.wikipedia.org/wiki/ARM_Cortex-A9](https://en.wikipedia.org/wiki/ARM_Cortex-A9)

<comment><AUTHOR> You are right, although I found only one place where this was stated. It is corrected now. Thanks!

<comment><USER3> There's also "ARM9" in the "fake amazon" pic from the article: [http://mntmn.com/reform/photos/fakeamazon.png](http://mntmn.com/reform/photos/fakeamazon.png)

</comment></comment></comment><comment><USER4> I prefer desktops because they are more modular, which gives me the ability to precisely choose components and upgrade incrementally. This also helps foster a competitive marketplace without thirty layers of vendor lock-in.

However, I'm not against laptops intrinsically, and if someone could make a modular one I'm all for it. When paired with a docking station connected to multiple monitors, keyboard, mouse, speakers, etc then laptops lose most of their downsides in terms of productivity and ergonomics.

My love of mechanical keyboards is a limiting factor, of course, but this keyboard looks half way decent.

</comment><comment><USER5> This is just fantastic, because it gives us laptop owners a way to prevent "planned obsolescence". I'm very sure many of us HN readers would like not only to repair our computer ourselves {which can already be done with regular laptops, to a certain extent}, but also to _upgrade_ them fully.

</comment><comment><USER6> This is very much like the Novena[1] laptop from 2014.

[1] [https://www.crowdsupply.com/sutajio- kosagi/novena](https://www.crowdsupply.com/sutajio-kosagi/novena)

<comment><AUTHOR> Yes, I referenced the Novena multiple times in the article. I also read bunnie's book, The Hardware Hacker. While Novena is a brilliant pioneering effort, you have to spend 550$ only on the board, though. Our board is less ambitious and cheaper, though, and we target a complete DIY package including a "chassis" in the 500-600 EUR range.

</comment></comment><comment><USER7> Exciting project! That thing looks like a lot of fun.

I agree on the trackball.

I'm interested in having something like a XD75RE ortholinear keyboard on it. Using all 1x1 keys should simplify the build.

<comment><USER8> i have DIY ortholinear keyboard. 1x1 spacebar, and lots of usefull buttons under my thumb, i was thinking about making it low powered portable device which can work as a regular keyboard, onion or raspberry with small powerbank an 7" screen. I really hate modern laptop keyboards, we can make them so much more usefull and convenient, but yet, all fancy new devices come with ancient typewriter layout which was result compromise resulted from engineering and mechanical challenges. We have no mechanical challenges now, but still using misaligned, less usable keyboards, why?

Pure opensource device would be really nice, i am not willing to waste money on MS Surface(it can run linux well, and i can use my keyboard with it) or experiment with low powered cheap raspberry, should be enough for typing notes, communication, and vim, something more powerful with proper keyboard, or just a tablet would be perfect for me

<comment><USER9> I hate the tiny key travel, flat keycaps, removal of pgup/down/ins/del, and putting the function keys as secondary functions of media keys I never use.

> We have no mechanical challenges now, but still using misaligned, less > usable keyboards, why?

Inertia. And I have trouble finding an intuitive reason why an aligned grid would make typing easier; just sounds like something slightly different for my muscle memory to adjust to. I can imagine something like the combination of aligned keys spread into a slight arc shape being nicer, just because of the angles involved.

<comment><USER8> Grid is a bit more intuitive for me, i am not sure how curves and arcs will do for me, grid is really easy mental map, befor this grid keyboard i was not 10-finger typist, now i am, even on regular keyboards.

Biggest downside of regular keyboard - spacebar lots of useless space, put 5 buttons instead of one, your thumb can push a lot of buttons while other fingers do not leave home row, make 2 of them space, shift, ctrl, backspace buttons under your thumb. This is main reason ErgoDox or Kinesis are good, and regular backspace and return key position sucks, keeping index finger on J while pressing Backspace with pinky is a challenge that moves your palm.

</comment></comment></comment></comment><comment><USER10> I'd go with a ThinkPad X60 or T60 keyboard + trackpoint plugged in via the ribbon cable. Hundreds of them on eBay + many loyal fans looking for a modern housing.

</comment><comment><USER11> This is really cool. I've wanted to do something similar for a while now. I've lately just taken to buying stupid cheap laptops from chinese manufacturers. That way if they go belly-up I'm not out more than a few hundred dollars.

I may have to try building one of these sometime though.

<comment><USER12> I keep having similar thoughts as well. Something based around a raspberry pi, with a thinkpad style keyboard, including the pointer stick. Then have a small (~7inch) touchscreen and you're good to go.

I've been inspired by this:[https://gizmodo.com/heres-a-pretty-legit- gibsonian-cyberdeck...](https://gizmodo.com/heres-a-pretty-legit-gibsonian- cyberdeck-1787039243)

<comment><USER13> Have you heard of the GPD pocket [1]? It's not so far from what you describe, although I often find myself wishing it had an extra inch or so: the keyboard is pretty cramped.

[1] [https://www.windowscentral.com/gpd-pocket- review](https://www.windowscentral.com/gpd-pocket-review)

<comment><USER12> I hadn't heard of the GPD (thanks for sharing). I have been keeping an eye on the Gemini: [http://www.zdnet.com/article/a-retro-computer-brings- touch-t...](http://www.zdnet.com/article/a-retro-computer-brings-touch-typing- to-a-smartphone/)

</comment></comment></comment></comment><comment><USER14> An e-ink option is mentioned but I wonder where they can even find a supplier for the screen. I looked but could never find one.

And I love this. I would buy one in a heartbeat

<comment><USER15> it looks like 9.7" e-ink displays are pretty easy to source, I wonder if a bezel around it would help move toward an e-ink display.

</comment></comment><comment><USER16> This has a PCIe x1 if I gather correctly. Not sure how would you attach a USB C chip to that.

Speaking of, I really would love if someone assembled a tiny computer with an USB C socket on one end and an M.2 key M (just PCIe 2.0 x2 is enough) with a simple copying firmware thus creating an external enclosure for M.2 key M disks. As Intel does not allow selling Thunderbolt enclosures empty there really is no other way. But, this could work and while 10 gbps is not the fastest, it's still quite a bit faster than 6 gbps SATA... Right now, the cheapest you can get is the BOXNUC7I3BNK and then probably run networking over Thunderbolt which is stupidly limited to 10gbps as well...

<comment><AUTHOR> You probably mean USB 3.1 for which PCIe 2.0 x1 Bandwidth seems not sufficient, but USB-C can also serve USB 2.0 and charging independently of that, or am I wrong?

</comment></comment><comment><USER17> Notably this is the same person behind InterimOS[0], which is a from-scratch OS targeted at the raspberry PI.

0: [http://interim-os.com/](http://interim-os.com/)

<comment> unkown-unknowns That link has an interesting write-up which includes a story about a computer he made himself using a micro-controller and then it goes on to talk about making the OS for the Raspberry Pi and also has some criticism of the Raspberry Pi. Would recommend reading.

</comment></comment><comment><USER18> Interesting. It's a bit of reinventing the wheel (Novena, Pandora/Pyra), but I can definitely see the appeal. This is a way to truly "own" your own system, because you have complete control over every aspect of its existence.

<comment><USER19> The Novena is a really cheap reverse-engineering work station but it's also a really expensive underpowered laptop. I think this is a different class of device.

</comment></comment><comment><USER20> This is exactly something I've been looking to do for myself. Highly inspiring!!!

</comment><comment><USER21> A side note, and probably I am completely wrong, but wouldn't it be possible to use/find a suitable pre-made "normal" mini keyboard?

It seems to me a lot of work to assemble even the keyboard, switch by switch and cap by cap...

For a small project I made (using an old decommissioned "thin client") I used and el-cheapo (paid it some 5 Euro) mini USB keyboard, and while surely it is not a model M, it feels much better than a number of "recent" laptop keyboards (with 0 or almost 0 key travel) I happened to try.

</comment><comment><USER22> This is really cool! One of my dreams is to own a modern Tandy 100/200 - <USER2> hackable, portable ARM machine that preferably lasts forever (hopefully the battery thing is straightened out..)

</comment><comment><USER23> Two rows of function keys! That's an interesting design decision, I suppose as long as you have the real estate, why not.

<comment><USER24> There is only one row. The one below the top is a strange and alien one called "number keys".

<comment><USER23> Sure, I am used to them being doubled up on laptops, nice to have dedicated keys for a change.

</comment></comment></comment><comment><USER25> Interesting. Does this have a built-in speaker or speakers? What about a headphone jack?

<comment><AUTHOR> The first prototype doesn't have speakers, but I want to include some in the second prototype. This is something that I missed putting in the article. For sound/headphone jack, I am currently using a tiny Renkforce USB audio adapter.

</comment></comment><comment><USER26> It was very mature of them to admit defeat on the trackpad and put a trackball on it instead.

A lot of big PC manufacturers really shouldn't bother putting trackpads on their computers until they manage to manufacture or source a decent quality one.

<comment><AUTHOR> Happy to see the love for trackballs here. I was using a trackball as a relief from hand joint pain and found it kind of nice and more exciting than a mediocre trackpad. (But: the idea is to have the input/pointing device of your choice!)

<comment><USER27> Looking at the thickness of the device (I do realize you want to thin it out a bit), I would use the area as a storage bin for a wireless mouse:) Seriously... I'm not kidding - I can't get comfortable with anything else.

I can imagine having a sliding panel in that area that closes securely and seamlessly - so as to blend nicely with the casing.

</comment></comment></comment><comment><USER28> why reinvent the wheel on keycaps?

I want to turn my 60% keyboard into a C64 clone and the full keyboard would have fit in there. also would have just used an ipad for a screen.

<comment><USER29> Openness of their component parts was a key goal. Reusing a legacy keyboard and using a super-closed platform like an iPad to get a display going seems really counterproductive in that regard.

Additionally, how would you link the iPad display linked to an i.MX board in the first place? Some kind of remote desktop app? Sounds like a terrible solution to me...

<comment><USER7> Amazon sellers have replacement iPad screens going for less than $50.

Open source display adapters do exist: [https://hackaday.com/2014/03/12/an- open-source-ipad-display-...](https://hackaday.com/2014/03/12/an-open-source- ipad-display-adapter/)

<comment> unkown-unknowns Someone in the comments linked a cheaper alternative: [http://abusemark.com/store/index.php?main_page=product_info&...](http://abusemark.com/store/index.php?main_page=product_info&cPath=3&products_id=47)

Seems that the firmware for this cheaper alternative is not open source but from what I gather it doesn't need any proprietary drivers on Linux. Since it interfaces over Display Port and USB I don't think it should be able to do anything nasty so the closed firmware doesn't matter much IMO.

It's not clear to me whether either of the one you linked and the one I linked has touch support.

</comment></comment></comment></comment><comment><USER30> Nice attempt, too many regressions.

Needs just a bit more aesthetics, compute* and ios.</comment>


Minimal Acyclic Finite State Automata in Go - <AUTHOR> https://github.com/smartystreets/mafsa

<comment><USER2> In case you are wondering who is behind it: [https://smartystreets.com/](https://smartystreets.com/)

</comment><comment><USER3> Very cool.</comment>


Show HN: Cloud-based GIF editor to augment any video - <AUTHOR> https://gifs.com/?source=https://www.youtube.com/watch?v=bpuGdkZ6ovU <comment><USER2> Hi all! We're the team behind gifs.com. Would love to answer any questions, and take any feedback requests!

</comment><comment><USER3> Great work guys! Definitely the smoothest way to make gifs I've found

<comment><USER2> Thanks so much for the kind words kobbad!

</comment></comment><comment><USER4> LOVE the new editor. Good work guys!

</comment><comment><USER5> Well-done product. Love this a lot.

<comment><USER2> Thank you Tzhong <3\. Appreciate the kind words.</comment></comment>


Ask HN: What is the Bitcoin price level at which miners will leave? - <AUTHOR> Is there a price point at which mining is no longer financially viable. I'm guessing the point is higher for the smaller mining pools/miners and lower for the bigger mining pools. At what levels is the risk of a 51% mining power to one pool likely. <comment><USER2> Bitcoin Can Drop 50% and China Miners Will Still Make Money [https://www.bloomberg.com/news/articles/2018-01-10/bitcoin-c...](https://www.bloomberg.com/news/articles/2018-01-10/bitcoin- can-drop-50-and-china-s-miners-will-still-make-money)

discussed 6 days ago in [https://news.ycombinator.com/item?id=16120062](https://news.ycombinator.com/item?id=16120062)

Money quote from the top comment: "The break even is 1 BTC = $922". Personally I have my doubts, but even at the $6,925 the bloomberg article claims is still very profitable.

<comment> semi-extrinsic As we've learned from oil production lately, quite a number of people/companies are willing to do things that are "globally unprofitable".

E.g. if you adopt the mindset that your CAPEX is a sunk cost, which is reasonable if you already own something nobody wants to buy (unprofitable oil or mining rig), your break even becomes much lower (just has to beat cost of operations/electricity).

With mining it's even more difficult, since mining at an "unprofitable" point in time could later actually become a very profitable venture if the price goes back up, assuming that the mining difficulty also goes down in unprofitable times.

<comment><USER3> Mining at a loss is not a good idea.

Say your [marginal] production cost is USD 100, but BTC market price is USD 50. You could spend USD 100 to make 1 BTC, or you could turn off your mining equipment and spend USD 100 to buy 2 BTC...

Added: and when the market price goes back up to say USD 1000, would you rather have the 1 or 2 BTCs in hand?

<comment> semi-extrinsic No, that's right.

But there are (perhaps edge) cases where your operation cost is essentially zero. A couple of friends are using their gaming rigs for altcoin mining, and simultaneously as space heaters (we live in cold climate). If they stopped mining, they'd have to turn on the actual space heaters, no electricity cost saved. And they already have the hardware, so no expense there either.

<comment><USER3> There has to be _some_ additional power expense, otherwise mining rigs would be sold in the "space heater" aisle.

<comment> semi-extrinsic No, simple thermodynamics ensures us that when no significant mechanical work is being done by the rig acting on the environment, and no significant exchange of mass between the rig and the environment is happening, all net electric energy going into the box will come out again as heat.

The reason why mining rigs aren't sold in the space heater aisle is that people usually don't buy $2000 space heaters.

</comment></comment></comment></comment></comment></comment><comment><USER4> Disclaimer: I'm not a bitcoin expert, so please correct me if I'm wrong.

With that said, here's what I think would happen:

1\. Bitcoin price goes down enough that a lot of miners leave

2\. The difficulty decreases since blocks are taking more than 10 minutes to produce

3\. It gets cheaper to mine bitcoins, since less hash calculations are necessary per block (on average)

4\. Miners want to join the system again, since it's cheap, thus taking away the risk of a 51% miner

So, bitcoin should self-correct

<comment><USER5> Mostly correct, except the price dropping squeezes out some miners who have less efficient hardware or more expensive electricity.

It's possible those miners would find it more profitable to 51% attack, or sell their hardware to someone who wants to.

<comment><USER6> If prices drop, miners may get priced out of mining if they don't have free electricity. Just like what happened when BTC was mined with CPUs and later GPUs and later ASICs people just stopped mining or using that method. Bitcoin is self adjusting, the only thing that doesn't adjust is the supply which is why some people found value in mining BTC when it was basically worthless.

I don't see how a dropping price has any bearing on a 51% attack.

All IMHO

<comment><USER5> > I don't see how a dropping price has any bearing on a 51% attack.

Sure it does. Lower miner income = lower security.

</comment></comment></comment></comment><comment><USER7> I don't think it's only a matter of Bitcoin price, rather a difficulty adjustment + bitcoin price.

So the question is how many miners will leave at what price.

</comment><comment><USER8> I have an S1 I received for free. At this point I'm losing $7 a month on it...I'm using it to poorly launder money from my checking account to the power company to my bitcoin wallet.

The GPU is doing a little better, but it's not even rent money, more like 'lunch once a week' money.

<comment><USER9> You could do some immersion cooling to reduce power usage. Not sure about the S1, but the S7 is still very profitable if you do immersion cooling on it. Although you're also risking damaging the miner (it might have components that dissolve in your coolant).

</comment></comment><comment><USER10> Miners were mining when Bitcoin was at $10.

Marginal capacity that's barely profitable at $19,000 will disappear at $18,000.

As the hashrate decreases at same difficulty level and transaction volume, fees go up which attracts more capacity.

The difficulty level adjusts approximately every two weeks, so if mining isn't profitable and blocks aren't created fast enough, difficulty will drop to make mining more profitable.

In the last 30 days during the latest bloodbath du jour, hashrate is actually way up from 13 exahashes/second to 17 exahashes/second.

[https://blockchain.info/charts/hash- rate?timespan=30days](https://blockchain.info/charts/hash- rate?timespan=30days)

</comment><comment><USER3> The cost of production is simply the cost of the (produced) factors of production (see Böhm-Bawerk's "Value and Price", part of his "Capital and Interest" works).

So the answer to your question is that miners ought to leave when the market value of their mined product is less than the marginal cost of production (assuming they keep track). If you have already recovered the cost of the mining tool, then the marginal cost is determined by power (electricity, cooling) and difficulty. At that point you'd be better off turning off the mining tools and using your money to buy BTC rather than power. On the one hand, BTC can go a long way down before that point, and difficulty would change; on the other hand, if the market price were to fall so much as to stop mining it would be tantamount to a complete destruction of the BTC system; I'm not sure how that would happen, it would surely not be simply a question of BTC pricing.

</comment><comment><USER11> Depends on the cost of electricity, difficulty adjustment, etc

So if you're running a miner right next to the hoover dam, with your basically free hydro-electricity, you can mine for a lot longer than someone in San Francisco where PG&E quadruple charges them for any use above a certain threshold at an already high electric bill rate

</comment><comment><USER12> The answer is that no one knows for sure, but you'll be able to see when by looking at this graph, which is an estimate of the global Bitcoin hash rate: [http://bitcoin.sipa.be/speed-lin-10k.png](http://bitcoin.sipa.be/speed- lin-10k.png)

</comment><comment><USER13> What is a more interesting question for me, is what will happen to bitcoin when mining (almost) stops.

</comment><comment><USER14> It isn't about BTC price anymore. It may go down or not - doesn't matter. The fees is much bigger game now, and given the hard limit on the tx slots number, the fees don't really have space to go down.

<comment><USER15> Fees are denominated in BTC, though.

</comment></comment><comment><USER16> I have read an article that $6500 is the point where the chinese miners with custom ASIC's will not be able to mine anymore.

<comment><USER17> Does that include plane fare to Québec?

[https://www.forbes.com/sites/sarahsu/2018/01/15/chinas- shutd...](https://www.forbes.com/sites/sarahsu/2018/01/15/chinas-shutdown-of- bitcoin-miners-isnt-just-about-electricity/)

</comment></comment><comment><USER18> What happens when the Bitcoin mines close down?

<comment><USER19> There can't be transactions, so nobody can move bitcoins around.

<comment><USER20> There is an adjustment every 2016 blocks, roughly 14 days (under the assumption that a block is mined every 10 minutes). When too many miners drop out, the block time will increase until 2016 blocks are mined and the difficulty readjusted. So transactions _can_ be made, they simply will take longer.

In the possible but unrealistic scenario of _all_ huge miners disappearing overnight right after an adjustment and thus making it impossible to reach 2016 blocks, the users will offer higher transaction fees and so make mining profitable again (or, at least, provide incentive to the miners to come back).

<comment><USER21> What you describe as an equilibrium really involves lots of disappointed people whose transactions take far longer than expected. Some wallets probably don't support CPFP, lots of people don't have any idea where to look for features like this.

While the system will ultimately reach stasis eventually, it will be seen as an "outage" that will end up playing to many altcoins' strengths (more frequent/softer difficulty adjustments, no-PoW coins, etc).

<comment><USER20> > that will end up playing to many altcoins' strengths

So what, then the difficulty gets adjusted and that's it. People won't stay on altcoins except for speculation, they're not usable anywhere except on trading platforms or, in case of Dogecoin, on Reddit. The "big whales" BTC, ETH and LTC have sucked up the market - most of the other currencies can't even be directly traded against the dollar but trading has to be done against BTC... thus, whenever BTC drops, everything else drops.

The problem is/will be that BTC has lost its value as an usable payment instrument due to high tx fees, confirmation time and the ridiculous price volatility. I hope this will reverse a bit.

[disclosure: holding ~500€ in BTC]

</comment></comment></comment></comment></comment><comment><USER22> never. if it's not profitable miner will leave diffoculty will drop and miners will make profit so the ones that left will come back etc.

</comment><comment><USER23> It's already at the point where you have to spend lots on money on hardware and have cheap power to make it work.

</comment><comment><USER24> I can't find the article right now, but there was one on HN recently were the number, at least for chinese miners, was in the high 6k range.

</comment><comment><USER25> When the price of producing bitcoin > the cost of bitcoin, it will stop. It's like all other forms of mining. For many miners, that's probably the cost of electricity, which could be free in some parts of the world, or very, very cheap.</comment>


1.78 Million Facebook Users May Die in 2011 - <AUTHOR> http://www.fastcompany.com/1718473/178-million-facebook-users-may-die-in-2011

<comment><USER2> 1.78 out of 600 million users is a pretty low mortality rate. (Edit: oh sure, go and fix the headline on me...)

<comment><USER3> wait 70 years and it's going to be REALLY high.

</comment></comment><comment><USER3> well it's good to know that Facebook users are not robots and have mortality. Always love interesting statistics.</comment>


Early lessons from the micro-purchase experiment - <AUTHOR> https://18f.gsa.gov/2015/11/06/micro-purchase-lessons/ <comment><USER2> Instead, the learning point here maybe is that, if you spend the time to spec something out properly, and make it into a nice little package, and say its for the good of the government and community, maybe you can get some altrustic programmers to help out, if you give them sufficient credit.

Maybe instead you should think about how to better create a list of timeboxed /scopedtasks that any programmer can come and submit a PR for, and how to better reward those people with fame or other perks

\- Leaderboard of contributors, # of prs, dollars saved taxpayers?

\- Let users link to their contributions / put in resume?

\- personal letter from the mayor once you submit 3 successful PRs that are accepted?

<comment><USER3> I'm not sure if your comment is sarcastic or not, but it actually wouldn't be a bad idea. Working on a well defined, self-contained task in an open source project can be very rewarding in itself.

<comment><USER2> not sarcastic at all.

</comment></comment></comment><comment><USER4> HN is always full of news about startups that burn millions of dollars in order to, perhaps, eventually, have enough of a product and enough exposure to become a profitable business.

How is what the winner of this bid did any different from what all these startups do every day? At least they staked _their own_ money to make a name for themselves.

Isn't the term for this a "loss leader"?

</comment><comment><USER5> They say that functional (and by all accounts fantastic) code was delivered for the winning $1 bid, and then they claim that the experiment was a success. But was it really? Is a $1 winning bid in the spirit of this? Couldn't someone who just wants to pad their resume submit $1 bids for everything, thereby "winning" 100% of the time and depriving of actual income these legitimate businesses who might count on these contracts for survival?

I'm not making a judgment either way, but allowing a $1 bid seems... strange. Are there other considerations that go into the "success" of the platform, or success merely defined by the delivery of functional code for the price of the winning bid?

<comment><USER6> I'm the author of the blog post, but the claim of success is based on a number of factors _other_ than the $1.

As we note re the $1: > "This unexpected development will no doubt force us to rethink some of our assumptions about the reverse-auction model."

Also, the success is borne out of the data: > "Given these statistics, we think it's fair to say that there is a market for open-source micro- purchasing, though we obviously will need to spend some time and effort refining our methods.

The success is in validation of the idea, not the actual result in this case. That said, the result is new, functional open-source software for the American public. So that's still a pretty good outcome.

<comment><USER7> If you don't mind me asking, do you have any plans to prevent extremely small bids like this in the future?

<comment><USER8> I hope they don't. In fact, I hope they encourage these kinds of small bids from qualified individuals.

100% test case coverage for $1 is amazing and to the benefit of all taxpayers.

<comment><USER7> I think they're great too. I'm just curious what 18f thinks about them.

</comment></comment></comment></comment></comment><comment><USER9> To anyone who might argue that the resume-building bidder has taken food off the plates of other contractors, consider this: thanks to the low bidder, the government can now afford to process that data, build that resume, pay the low bidder, and give money away to the other bidders for free.

<comment><USER10> > and give money away to the other bidders for free.

I'm not sure what you mean. Surely the money will be spent, but this wasn't some kind of lottery, the remaining money isn't split among those that lost the auction...?

<comment><USER9> I was being facetious. There is no "remaining money" because the total cost of that work was $1.

</comment></comment></comment><comment><USER11> As per previous comment threads this is currently just an example of experimental bias.

[http://www.smbc-comics.com/?id=3025](http://www.smbc-comics.com/?id=3025)

Although I have heard of this behaviour before in government bidding, the fame makes it meaningless atm.

The 10th iteration will/would be interesting.

</comment><comment><USER12> "the experiment also validated the core concept that open-source micro- purchasing can work, and it's a thing we should try to do again"

This leap in logic seems entirely unsupportable. This was not a "purchase". It was a donation, very much within the long tradition of donations to open source projects.

<comment><USER13> There were plenty of bids before it dropped to $1 (Note: I work at 18F)

<comment><USER14> But those other bids dont matter. Only the winning one does

<comment><USER13> My point is that the other bids offer some support to the concept, regardless of the final bid and PR.

</comment></comment></comment></comment><comment><USER9> Previously: [https://news.ycombinator.com/item?id=10471677](https://news.ycombinator.com/item?id=10471677)

</comment><comment><USER14> The big question is: will this work on scale?

Sure, 1 programmer can use this donation to pad his resume, but will this work if everyone is doing it?

<comment><USER15> Well if it doesn't scale, presumably the market price will converge on average back towards what is actually fair.

</comment></comment><comment><USER16> There seem to be so many things wrong with this.

How about if the person didn't deliver? Would the project be delayed and reauctioned?

Haven't the problems of lowest-bidder quality been illustrated over and over?

Wouldn't they garner a lot more good will if they just ask for volunteering?

</comment><comment><USER17> I'm glad the US Government adheres to and pays the minimum hourly wage for work such as this.

<comment><USER13> Quoting the blog post on the the $1 bid: "It was a plot twist that no one here at 18F expected. This unexpected development will no doubt force us to rethink some of our assumptions about the reverse-auction model."

* I work at 18F</comment></comment>


Golden Ratio - <AUTHOR> https://www.melted.design/golden-ratio/ <comment><USER2> "Golden Ratio is a natural ratio found everywhere. From flowers to shells, from our fingers to the galaxy, this mathematical ratio makes all forms look visually balanced and gratifying."

Both of those claims have been broadly debunked, and the so-called golden ratio is grossly oversold.

<comment><USER3> It does show up in plants (artichokes, cactuses, sunflowers, pineapples, etc.), as the angle between successive leaves/seeds/petals. This is called spiral phyllotaxis. You can make some cool art out of this idea with a strobe light, [https://www.johnedmark.com/phi/](https://www.johnedmark.com/phi/)

It also shows up anywhere with pentagonal (or icosahedral) symmetry, since the golden ratio is the ratio of the diagonal to the side of a pentagon. So that includes e.g. various viruses with a shape based on icosahedral symmetry.

The stuff about shells, galaxies, etc. (and the supposed advantages of this specific aspect ratio for design / visual art) is generally bullshit.

<comment><USER4> Definitely not bullshit with respect to art—it is used in many aesthetically pleasing and well balanced designs.

<comment><USER5> But that doesn't mean the golden ratio is the reason it's aesthetically apealling. There is good art that uses the ratio, and bad art that uses it, and good art that doesn't use it.

<comment><USER4> Agreed, but it's recursive nature does make it appealing in ways other ratios do not.

</comment></comment></comment></comment></comment><comment><USER6> While the Golden Ratio is really popular, there are many other ratios that are aesthetically pleasing for different scenarios. I've tried to visualise some of them: [https://github.com/hnarayanan/orthogons/blob/master/README.m...](https://github.com/hnarayanan/orthogons/blob/master/README.md)

<comment><USER7> That reminds me of the classic proportions described by Jay Hambridge in _The Elements of Dynamic Symmetry_ (1926). He was an art historian who argued that the Greco-Roman art and architecture was based on _root rectangles_. [https://en.wikipedia.org/wiki/Dynamic_rectangle#Jay_Hambidge](https://en.wikipedia.org/wiki/Dynamic_rectangle#Jay_Hambidge) I just noticed that Wersin is mentioned right after him!

Hambridge's theories were quite controversial, but the book is an enjoyable read anyway. [https://archive.org/details/ElementsOfDynamicSymmetryHambidg...](https://archive.org/details/ElementsOfDynamicSymmetryHambidge)

<comment><USER8> Have you found any utility in this stuff with your work?

I mostly just use frameworks that think about this stuff for me while working hard to keep consistency in spacing (padding, margins, etc) which functional ones like basscss and tachyons do a good job of pushing you towards (much more than Bootcamp and others).

<comment><USER6> What frameworks do you use that think about this? All the "big ones" that I know of, Bootstrap, Foundation, ... have really standard 12 column grids.

<comment><USER8> I'm talking about letting frameworks handle the space ratios for padding/margins/headline size in addition to grids. Whether they use golden ratios specifically or not wasnt the point rather deferring to the library designers who most certainly are aware of the golden ratio.

</comment></comment></comment></comment></comment><comment><USER9> To me the connection between the golden ratio and beauty is tied to iterated function systems, and fractals. I feel like it boils down to efficiency of representation of a larger system. If a complex, balanced system can be represented efficiently by a small number of values, variables, and operations, then it's favored by the universe somehow, and by our mind's eye. It "snaps into place" more easily, it aligns with itself, and therefore our conception of it is also performed with less work, more "naturally."

The golden rectangle and spiral represent this best to me. The whole is found in the parts, infinitely, the further you iterate, like looking down a well and seeing all the way to the bottom. It's gratifying to conceive of more by doing less. I wish I were better with words, but I do feel φ's beauty somehow boils down to efficiency of representation.

<comment><USER10> There's an interesting correlation to information theory and compressibility. Someone did an analysis of pop lyrics[1] where they compressed the plaintext using a lossless compression algorithm and determined that (as expected) many pop songs compress very well and are highly redundant. But taken another angle, this could also represent that we as human beings find lyrics which have high degrees of self-similarity with small amounts of variation to be pleasing to the ear, which tracks with what makes pop music (which must be singable and usually danceable to go viral) successful.

[1] [https://pudding.cool/2017/05/song- repetition/](https://pudding.cool/2017/05/song-repetition/)

</comment></comment><comment><USER11> Not content-related but... I dislike the inertial scrolling on this page. Something about inertial scrolling with a mousewheel feels off. Maybe it's because mousewheels have discrete ticks that I subconsciously use, that get broken by the inertial paradigm?

<comment><USER12> It's just unexpected and unnecessary. On mobile I'm pretty sure all the browsers already have it, on desktop it completely breaks expectations for what should happen.

Also it is turned up to an extreme degree here. I'm using Firefox and the scrolljacking doesn't happen in FF, but when I open it up in another browser, a scrollwheel flick that would normally scroll down 1/4rd of the page is enough to continue down all the way to the very end. Even with smaller scrolls, it goes around 1.5-2.5x the expected distance.

Scrolling is muscle memory and the consistent behaviour of it makes us have expectations for what scrolling should do, flagrantly destroying those will cause unease.

</comment></comment><comment><USER13> Dentist here. I use it all the time, front teeth proportions, size, etc when reconstructing them.

<comment><USER14> The artistic aspect of dentistry is often underestimated

</comment></comment><comment><USER15> Did you know that the golden ratio defines the temporal structure of the brain?

While the main brainwave bands are harmonics (theta is roughly double delta, alpha is roughly double theta, beta is roughly double alpha and so on), the band _widths_ have a ratio of the golden ratio. That's because the golden ratio is the most irrational number. While harmonic oscillations will overlap regularly, irrational frequency ratios will _never_ overlap. This allows for multiplexing in the brain, EMG , where high theta and low theta don't interfere with one another.

Pletzer, B., Kerschbaum, H., & Klimesch, W. (2010). When frequencies never synchronize: the golden mean and the resting EEG. Brain research, 1335, 91-102.

</comment><comment><USER16> The golden ratio is the _most irrational_ number: [https://www.youtube.com/watch?v=CaasbfdJdJg](https://www.youtube.com/watch?v=CaasbfdJdJg)

This is why it creates some distinctive patterns when applied to circular/spiral shapes.

<comment><USER17> It's the fraction that converges the "slowest", in a sense. (It's the continued fraction of all 1's.)

<comment><USER18> It might converge more slowly than any other simple continued fraction, but there are some super-slow to converge generalized continued fractions. A couple of examples that are slower than phi: [https://en.wikipedia.org/wiki/Approximations_of_%CF%80#Conti...](https://en.wikipedia.org/wiki/Approximations_of_%CF%80#Continued_fractions)

</comment></comment></comment><comment><USER19> I love this because it is both bullshit and awesome. Like many things thats either a rule-of-thumb or subjective, it has been studied thoroughly, confirmed, debunked, and applied succesfully many times.

<comment><USER20> It's just like Pareto Principle: it only works in 80% of cases.

</comment></comment><comment><USER21> For travelers wanting a rough-and-ready conversion of miles to kilometers, the ratio is useful: 3 miles ~= 5 km; 8 km~= 5 miles; etc.

Discussion at: [https://www.reddit.com/r/math/comments/2zop5o/i_realised_the...](https://www.reddit.com/r/math/comments/2zop5o/i_realised_the_golden_ratio_is_by_a_coincidence/cpkw3fr/)

<comment><USER22> Even easier don't think about the ratio! Think about the Fibonacci sequence: 0 1 1 2 3 5 8 13 etc. Then you are doing just addition.

</comment></comment><comment><USER23> The coolest thing I learned recently is that you can create a isocahedron by connecting the vertices of three perpendicular golden rectangles.

<comment><USER24> It's _icosahedron_ :-)

This relation is seen in the coordinates of the vertices of the solid: all permutations of (0, ±1, ±golden ratio).

</comment></comment><comment><USER25> This isn't too insightful. The article swimmingly explains that there is a "golden ratio" and then goes on to just repeat "you can use that in design", with no concrete examples or explanations aside a small use case for font sizing

<comment><USER18> The idea is that you can use it anywhere you need to make a decision about proportions. It's not complicated. Designers know that it's no use if you need a proportion close to 1:10 or 1:1, but there is often enough flexibility to use it (say when designing a window or a floor plan.)

</comment></comment><comment><USER26> All articles about the Golden Ratio mostly make me think about when Donald Duck in "Mathmagic Land"

See: [https://youtu.be/fwYfuJfIgaw](https://youtu.be/fwYfuJfIgaw)

</comment><comment><USER27> A gigantic image that fills my screen, and then teeny tiny text that I need a microscope to make out. This is design, I guess. Thanks, golden ratio! What ever happened to "Type is to Read"?

</comment><comment><USER28> This is a great tool I use anytime I sketch an interface: [https://goldieapp.com/](https://goldieapp.com/)

</comment><comment><USER29> __(a) + (b) = (a) + (b) / (a) = 1.618 __

They can 't into math, can they? Or is it a special notation of some sort?

<comment><USER30> It should be

a / b = (a + b)/a = 1 + b / a = 1.618..

</comment></comment><comment><USER31> Should have 'in Design' in the title [but I should've guessed from the domain].

<comment><USER32> More like Fiction than Design, frankly.

</comment></comment><comment><USER33> Terrible article:

> Let's imagine that you need to start your design by creating a line. Next, > you copy it and divide it into two parts, getting two shapes a) the first > line, and b) the second one.

What does this even mean? What are the constraints between these two lines that leads to that ratio to be the golden ratio?!?

</comment><comment><USER34> The page forces a very bad type of smooth scrolling with js.</comment>


Ask HN: How do I package up a side project to make it easy to sell? - <AUTHOR> I've been running a side project that's been (ramen) profitable for the last 5 years.  I've had interested buyers contact me and I've always turned them away because I was busy trying to build it into a lifestyle business.  Another group contacted me today and I'm now at the point where I'd sell it.
Is there a checklist or process I can follow to make this side project easy to package up and sell?
I'm a US citizen living in the US. <comment><USER2> Patrick McKenzie(patio11) has written a lot of useful stuff about this here:

[https://training.kalzumeus.com/newsletters/archive/selling_s...](https://training.kalzumeus.com/newsletters/archive/selling_software_business)

and talked about it here:

[https://www.kalzumeus.com/2016/08/26/kalzumeus-podcast- episo...](https://www.kalzumeus.com/2016/08/26/kalzumeus-podcast- episode-13-selling-online-businesses-with-thomas-smale/)</comment>


AI chip startup Graphcore raises $50M to battle Nvidia and Intel - <AUTHOR> https://venturebeat.com/2017/11/13/ai-chip-startup-graphcore-raises-50-million-to-battle-nvidia-and-intel/ <comment><USER2> Good luck to them.

However, it's very difficult to compete with big Silicon. I suspect they want to prove that they have valuable IP, and then look for an exit, like nervana systems.</comment>


Facebook reportedly launching 15-second autoplaying ads - <AUTHOR> http://www.engadget.com/2013/04/16/facebook-report-video-ads/

<comment><USER2> Has the day come for Google+?

I'm willing to put up with a lot from Facebook, but the one thing I absolutely detest are these full-page video ads. I've given up a lot of websites (e.g., Yahoo!) because of them. In fact, the only place where I'll tolerate them are porn sites.</comment>


Loyal Opposition to Const, Private, Freeze, Non-Configurable, Non-Writable... - <AUTHOR> https://mail.mozilla.org/pipermail/es-discuss/2011-November/017872.html <comment><USER2> I'm somewhat of two minds about this.

On the one hand, I think he has a point that said features of JS.next are cutting against the grain of present-day JS. There are quite a lot of people programming in JS, many of whom may or may not deserve to be called good programmers but who nonetheless can produce functioning web pages, that would have to switch to a very different coding model to work with JS using these new features.

On the other hand, it's difficult to program your code when you know than any of your invariants can be accidentally stomped on by any other code that happens to run on the same page. It's also difficult to write libraries when everything's guts are exposed, even with red tape. Raymond Chen over at MSFT has an entire blog that could be titled "How Implementation Details Become _De Facto_ Interfaces Due to Insufficient Encapsulation."

I think my final thought on the matter, is that when you think about it, it's really quite silly that we only have one language for front-end web development. It is, in fact, unacceptably silly. Like, seriously guys, what the hell? This is totally crazy. If you want to do server work, or non-web client applications, or embedded, or whatever else, you have a full array of programming languages. These run the gamut from ball-gag-and-leather- straitjacket static languages to walk-into-anyone's-house-and-drink-their-milk dynamic languages, from concise expressive languages to low-level bit-fiddly- ones, from parens to curly braces to significant whitespace to perl.

On the web we have JavaScript. Not that it's a bad language, it has its warts (what doesn't?) but it's actually a cute little language. But I don't have the option of using a language with static guarantees. Or deterministic memory management. Or asynchrony. Or macros. None of these are strictly better, they're all just personal preferences, but the point is, you don't have the choice.

That lack of choice is probably what's driving these against-the-grain additions to JS.next. They're adding more features to JavaScript so that it can cover some of the bases that it currently doesn't, and all the different directions it's being pulled in are understandably causing some stress. I think it's the wrong solution, but it's also the one with the easiest transition path. The ideal solution, is that we could use different languages from different paradigms, but how the hell do you crowbar them into existing browsers?

So uh... do I have conclusion? I dunno, language evolution is hard, let's go shopping.

<comment><USER3> Being able to declare member variables as private (really private, not the private alluded to in Ruby) is good. As the OP said, you don't _have_ to declare a member variable as private if you want relaxed 0constraints. But when you want to for good design reasons -- it's great that the language you are working with allows you to do so.

<comment><USER4> If you really need private member variables you can probably whip something up with lambdas, though it might be a little awkward.

<comment><USER5> It's super easy:

      function A {
        var secret = 0; // <</comment></comment></comment></comment><comment>---- private variable
        this.method = function() {
          alert(secret);
        };
        this.increment = function() {
          secret++;
        };
      }

      a = new A();
      a.increment();
      a.method(); <</comment><comment>-- prints 1

The main problem is just the inefficiency of declaring methods inside constructors.

Edit: Hence, the keyword.

</comment><comment><USER6>
      "const" does not add anything new to a variable.
      If you don't want to change the value of a variable ...
      don't change the value of the variable.

I've got a better idea: how about we mark the variable in some way and get the compiler to remember this for us. Then, when we come back to the code in 6 months, we won't make mistakes.

I have a decade of experience in "dynamically" typed languages, and I prefer modern statically typed languages in _almost_ all situations. Now it turns out you can have both: see Racket and Typed Racket for instance.

<comment><USER7> "I've got a better idea: how about we mark the variable in some way" — if all you need is a mark, the Python convention to add an underscore in front of your private method or variable works just fine, as does the convention to make constants uppercased. I've seen quite a bit of JS code use these conventions too.

The trouble with true private/protected variables is that you never really know how your code is going to get used and which parts of your library people may want to mess with. In that case, you can either play around with things you aren't really supposed to touch, or if that's not possible because everything's encapsulated, being in a hurry, you'll just fork the code and turn private methods into public ones. Both approaches suck, and the problem exists regardless of whether your language supports `private` and `const` keywords or not.

<comment><USER8> "if all you need is a mark, the Python convention to add an underscore in front of your private method or variable works just fine, as does the convention to make constants uppercased. I've seen quite a bit of JS code use these conventions too."

Until you have a user subclass your class and accidentally stomp over one of your private names, causing your class to mysteriously fail. I've been bitten by this before, and it'd be nice for JS to offer a solution.

</comment></comment></comment><comment><USER9> jashkenas is one of the most prolific and talented JS devs around (CoffeeScript, backbone.js, underscore, docco are among his credits). I can see why he and other library producers would want as much flexibility in the language as possible.

Library _consumers_ , on the other hand, will reap the most benefit from the proposed constraints.

`private` is important metadata for a library consumer. Documentation generators can ignore private members, and private tags serve as roadsigns that the member can be ignored if one is only interested in the API. `private` is a very powerful filter.

The same can be said for `const`: indicating a value shouldn't change eliminates one more thing one needs to hold in their head as they explore a lib's boundaries.

I don't care at all about the performance benefits; I care about communication. `private` and `const` are nearly-free, expressive documentation.

I actually like Ruby's "red tape" approach; it offers library consumers helpful metadata while still allowing flexibility. Maybe the best solution is for library developers to rigorously use the _private and CONST naming conventions, and reserve `private`, `const`, and `freeze` for security- sensitive code. Wouldn't that offer the most flexibility?

<comment><USER3> To be honest, there are very few languages where 'private' and 'const' modifiers can't be gotten around. That doesn't decrease their usefulness though if people agree to code to the _spirit_ of the language's design.

</comment></comment><comment><USER10> This is similar to the divide I see in the PHP community.

There's been such a big movement towards more strictness, more Java-like features and frameworks, while the more interesting development today seems to be moving away from that, towards more concise, flexible, and expressive languages like Ruby and Python, more FP ideas, and the rise of server-side Javascript.

I started programming professionally in Perl, where you were handed a loaded gun and learned the hard way not to shoot yourself in the foot. I appreciate the discipline that demands, making you think hard about what you're doing.

I really hope the Javascript community doesn't start to compromise its dynamic nature and lose one of the things that made it great. There are areas where syntax could certainly be improved/made more concise, but keep the dynamism and flexibility all the way (and add more!). Good on Jeremy for fighting for that.

</comment><comment><USER11> My general feeling is that these un-features take things away, and what they purport to provide in exchange is fewer bugs by virtue of being able to check certain constraints at 'compile time'.

I'm all for taking things away, but I personally want more in exchange. For example, if you're going to give me immutable or const declarations, give me lazy evaluation as part of the bargain.

So I'm not opposed to taking things away, I am just optimistic that we can provide a lot more value than 'constraints' in exchange. And if we aren't going to provide more value, I think we're setting our sights too low.

<comment><USER12> Have you considered the value that these keywords add to a team environment, or as reminders when visiting an api that you haven't worked on in months? It's something a little more standardized than "_privateVar" and "maxCount =4; // NOTE: Constant Variable!"

<comment><USER11> I have, and speaking as a guy who spent a big chunk of his career working with large teams on large code bases, I think private and const are small potatoes next to really big domain-specific semantic constraints. So to me, providing small value in exchange for making other things harder to do is not a win.

It feels like we're circling around a local maximum and nobody is trying to make a really big leap when thinking about JS.next. We're getting the warmed- over leavings of middle-of-the-road language ideas.

If you really want constraints that are tailored for a team environment, make them programmable and put const and private in the standard lib. Then let Alice write something that prevents Bob from putting text in a SQL query or opening up an XSS vector in raw HTML. Or let Carol write something that ensures that all code makng certain writes to the database have an authorization check baked in.

<comment><USER13> FYI, <http://disnetdev.com/contracts.coffee/> is built on ES6 proxies and CoffeeScript.

I agree on circling a local maximum, but some of this is just JS catching up to Ruby and Python. Syntactic affordances for usability that desugar to only lightly extended kernel semantics.

The big ticket items are modules, proxies, weak maps, binary data, and the like.

When I liken JS to x86, I'm not comparing it to assembly so much as to a ubiquitous target for compilation. JS is even stickier and longer-lived than x86 -- witness ARM's rise on mobile while the web evolves mostly-compatibly, including JS content and the JS language.

Contracts and macros are on the Harmony agenda, further out.

<comment><USER14> I came across contracts some time ago and found it very appealing and inspiring, but for all my professional projects I am successfully using my own library schema.js ( <https://github.com/akidee/schema.js> ) - you can use it in pure JavaScript, too. (Usually I do not validate forms on the client-side, since the data must be validated on the server-side anyway. And with schema.js, you can add custom localized error messages.) Furthermore, schema.js has several modes that allow tolerant adaptation of values, so that they can be casted. "5", for example, is casted to 5. But you can switch to strict validation mode as well. You can do everything, that contracts allows, with schema.js, too. The best is that, with JSON schema, 1) you define secure validations, since with the default properties you do not forget important constraints, and 2) you do not need to test your validators any more. Conclusion: I agree that such features must make it to the core of a language. Probably you can find some useful ideas in JSON schema and schema.js. I found the JSON vocabulary to be very useful to validate JS data.

</comment></comment></comment></comment></comment><comment><USER15> As a long time writer of JavaScript I say bring it on. If you want JavaScript to succeed outside client browsers in a big way you must to consider performance. If it wasn't for incredible perf gains in the past couple of years you would not see JavaScript pushing into the server side.

However JavaScript performance still leaves much to be desired - [http://stackoverflow.com/questions/6216888/is-nodejs- faster-...](http://stackoverflow.com/questions/6216888/is-nodejs-faster-than- clojure).

I want JavaScript to close the gap without sacrificing dynamism. And it won't - these feature are _entirely optional_ and they free the implementors to make assumptions which allow further optimization.

"Pay for what you use"

To be totally honest I don't see myself writing plain JavaScript much longer, I'm closing in on 7 years now. At work I use quite a bit of CoffeeScript and very likely in the near future I'll leverage ClojureScript.

<comment><USER16> Why not allow for C extensions to Javascript, and create a compiler capable of easy generation of these extensions with optional typing?

An example of this would be Cython for Python, which lets you get to C speed within 1 to 5% slow down due to interfacing with Python, and it has you write in a Pythonic dialect of C/C++.

<comment><USER17> Because, all else being equal, writing your code in one language is better than writing your code in two languages.

</comment></comment></comment><comment><USER18> > "private" does not add anything new to a property. If you don't want the > > property to be used outside of the class ... don't use the property outside > > of the class.

I think the author missed the point of private, because it does add something new. Specifically, it adds the ability to know that the property is not being altered outside the class without reading the entire code base.

<comment><USER19> Not even reviewing the code can prove that any property is inaccessible, when its name could be constructed anywhere at runtime and used via object[propName]. Without actual language and runtime enforcement, there are almost no pervasive changes safe enough to make without the kind of thorough regression testing most teams aren't prepared to do. Which is not to say they don't do it anyway, and sometimes get lucky.

</comment></comment><comment><USER20> I've done a lot of low-level JavaScript work via my time developing SproutCore 1.0.

Jeremy is right on. Keep JavaScript open. Add red tape if you must, but don't ACTUALLY lock it down. The openness (and lack of package management) are killer features.

We are lucky that JavaScript is the language in the browser; it could easily have been Visual Basic (shudder).

</comment><comment><USER21> He seems to be under the misapprehension that libraries would be impossible or extremely difficult if you added restrictions to the language. This is illogical. Languages with many _more_ restrictions, like Haskell, can still have useful libraries. Sure, jquery wouldn't be able to work in exactly the same way it does now, but it could still work. (I would imagine wrapping objects instead of actually changing their prototypes).

Also, he doesn't go over the most useful aspect of static OO, which is interfaces. Being able to force an incoming argument to have attached methods often makes code much simpler, because you don't have to deal with the possibility of someone passing different arguments into your function.

Arguments like this usually degenerate into shouting messages, so I would like to conclude that even though I am a huge fan of static typing, I don't think it's for javascript. You can always add a static type checker on top of a non- static langauge, so people like me will be happy. It might be more difficult to go the other way around.

<comment><USER22> > He seems to be under the misapprehension that libraries would be impossible > or extremely difficult if you added restrictions to the language.

It seems to me that the restrictions he's talking about adding to the language are akin to making JS closer to Java, not closer to Haskell. Those similar restrictions - in Java - make extending an existing library much more difficult since you can't do things like add methods to an existing class/object; that method has to exist elsewhere & take the object you're extending as a parameter. This isn't an issue in Haskell since functions don't exist on an object, but are defined outside the types & operate on them.

<comment><USER21> Of course I have never programmed in Haskell, so perhaps I am showing my ignorance, but my impression of Haskell is that it has all of the type restrictions of java plus many, many more. My point is that a language like Haskell (or Java, take your pick), can still have easy to use libraries written for it.

Sure, you can't change the methods of a class has at run time. Who cares? Like I said you can just create an object wrapper, sometimes called a decorator if you are into design patterns, that has all of the methods of the original object plus a few more (or even a few less, doesn't matter). This gives you all of the functions of the original object plus more, just like modifying a class at runtime does. Possible in Java, possible in Haskell, possible even in JavaScript.

The only difference is that you have to explicitly call into the wrapper classes. You can't expect objects that you instantiate from outside your library to have these methods.

But again, who cares. If you want to use the cool new library functions, use them. Otherwise don't.

Specific example: if we are talking about jquery, you can't expect document.GetElementById('foo') to have special jquery functions. But you can expect $('#foo') to have them, which is the same thing so you really have nothing to complain about.

<comment><USER23> I think Jeremy's real point is that Javascript is an entirely different beast than Haskell or Java or Ruby. Why? Javascript depends on a free and open code environment to get around the fact that the actual language's development moves glacially, you have no control of the deploy environment (unless you are a browser developer or are working in node) and it is not easy to manage large projects (inclusion and namespacing features are lacking or limited in JS). In fact, the only feature that allows JS to keep up at all with these other languages is that it tells its developers "Look, I don't have a lot of fancy features and I haven't really changed in about a decade, but I'm entirely open. Hack and abuse me at your pleasure, codify me if you must, I'll take it. I always do."

None of the proposed object-lockdown would _prevent_ anything. You could use decorators, you could use an adapter, hell you could rewrite or fork the useful library and take out the object-locks. But all of those introduce the very overhead that JS benefits from avoiding. I mean compare the size of "Javascript Pattern" to the GOF book. What's more, languages like Java are written with a sensitivity toward design patterning, Haskell has robust types/interfaces. Javascript just has a big empty box, prototypes and closures. (This is an exaggeration but if you declaim it loudly enough you will get a chuckle.)

</comment></comment></comment></comment><comment><USER5> I'm not sure where the opposition to private is coming from, outside of being anti-additional-syntax. _Private variables already exist in Javascript._ They're just inefficient, because they mean that any of an object's instance methods that reference them have to be declared inside of the class's constructor function, instead of on the prototype.

Private variables may be accessible outside of classes in Ruby -- but they already aren't in JS. And JS has extremely strong encapsulation through scoping and closures, so arguments against encapsulation based on the "language grain" fall a little flat for me. If an explicit private keyword enables optimization of existing functionality, then why not have one?

</comment><comment><USER24> > The freedom of having every object and every property be configurable, > settable, introspectable, readable and writable, at least at the language > level, is worth the trade off. If we add const, private, and other lock-down > syntax, or make class properties private by default (shudder), I guarantee > you that many potential innovative libraries that otherwise might spring up > will never even be conceived, and frustrating situations that could have > otherwise been solved by a quick patch will instead require convoluted work- > arounds.

If you say so.

</comment><comment><USER25> I've been asking a lot of dumb questions today, so here's another: Do we have any decent tools to measure memory usage / allocation when running a Javascript program?

Once we start introducing these data structures we will have to figure out actual memory storing (16bit? 32bit? 64bit?) which obviously introduces another layer of complexity to "standardizing".

</comment><comment><USER26> I think my biggest problem with the "if you don't want X to happen, then don't do X" statement is that it only makes sense in the context of working as an individual who controls all possible moving parts. It doesn't make sense (at least, for me) in the context of a team.

<comment><USER20> I've noticed that people are always trying to outsource code review to the computer.

In my experience, no compiler is sufficiently intelligent to outsource this to. And if you have to review the code anyway (and you do), enforcing coding conventions is the least of your problems.

</comment></comment><comment><USER27> Doesn't seem like many people are considering the "security" benefits of having private, constant and frozen.

Being able to freeze an object to prevent anything modifying it would be useful for preventing 3rd party scripts you include on your site from deleting or modifying your code's behavior.

<comment><USER28> So is proper namespacing.

<comment><USER27> Having thought about what you meant... Even with namespacing you still have a global object that can be maliciously overridden or modified

<comment><USER28> If an attacker is in a position to make malicious modifications 1) You've got a larger problem than optional language features on your hand and 2) locking down a few properties (or the entire object) isn't going to save you.

<comment><USER27> From your example below: think of one of those ad network scripts (or any other 3rd party script you include on your page) you have no control over what that code is doing. It could override any of your global objects

<comment><USER28> This is accurate regardless of language features. You can't control 3rd party code. Using generic object names greatly increases the odds that at some point you're going to run into a namespace collision and something important will be overwritten. Proper object namespacing your objects vastly decreases the odds of this happening with benign 3rd party scripts, no additional language features required.

</comment></comment></comment></comment></comment></comment><comment><USER29> From the article: ""private" does not add anything new to a property. If you don't want the property to be used outside of the class ... don't use the property outside of the class.

"const" does not add anything new to a variable. If you don't want to change the value of a variable ... don't change the value of the variable.

"freeze" does not add anything new to an object. If you don't want to change the shape of an object ... don't change the shape of the object. "

Now, having started to dabble a little in Rails and Node--and hence getting exposure to Ruby and JS--I do have respect for a lot of the interesting things you can do in those languages.

That said, I've also got a experience dealing with libraries and software engineering on various sized projects, and I'm sensing a pattern here.

It seems like good practices (encapsulation, static typing, etc.) are being ignored because they get in the way of "free programming". Now, is this actually an accepted attitude in the web development world, or are these people actively promoting terrible design practices?

I understand that programming routines for web pages and the like is not the same as for thick-client applications, but is the use of your library by other people through an interface or namespace collisions really not a large concern?

</comment><comment><USER30> _The recent JavaScript renaissance that we're all enjoying owes debts to JavaScript's foresight as a "free", dynamic language._

Bollocks. If javascript wasn't the language of browsers, nobody would use it. Its got nothing to do with javascripts awesomeness. Indeed, that it took so long for the community (or in this case Mozilla and Google) to finally say "fuck it, this is the shitbag we're stuck with so at least lets make it faster", just tells me how much they wanted something else to be the standard.

The only argument for NodeJs etc is that programmers can code the same language on client and server. Was there some "foresight" that made javascript the language of browsers? No.

That said, why fuck with it? There are ways to encapsulate fields and methods in javascript. There are also ways to get around it. Just as there are ways to get around private and const in C++.

If private and const really float your boat use GWT.</comment>


Neural Networks Are Essentially Polynomial Regression - <AUTHOR> https://matloff.wordpress.com/2018/06/20/neural-networks-are-essentially-polynomial-regression/ <comment><USER2> How and why did this end up on the homepage again?[a][b]

This is a silly claim, backed only by _tiny toy experiments_ on _tiny toy datasets_ with _tiny toy neural networks_. See links to the paper in [a] and [b] below.

Using the same logic as the authors of the paper, I could make the claim that neural nets are "essentially the same" as _any_ universal approximator (GP's, SVM's, RF's, GLM's, etc.) and then run a few experiments only on tiny toy problems to back up my claim.

The authors should try to fit a polynomial regression model to cognitive tasks such as language translation, image generation, or modeling the game of Go... they won't get very far without running into the curse of dimensionality.

Please stop posting this on HN.

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

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

<comment><USER3> I came here to say this ⬆ Glad someone else did it for me, better than I could have.

</comment></comment><comment><USER4> This feels overly sensationalist.

It's no surprise that in domains where low-parameter models work at all, they often work better than NNs. In econometric forecasting, where the traditional methods encapsulate more prior knowledge than could ever be inferred from the data, neural networks aren't anywhere near competitive. Even in domains where NNs are state-of-the-art, they might not be worth the training costs over GLMs or gradient-boosted forests or whatever.

But there are many other domains, like raw waveform modeling, large natural images ( _not_ MNIST), or NLP, where anything that isn't neural fails miserably. These are the domains where people are most excited about neural networks — problems that otherwise have no solution at all. Neural networks won't help you get a better interpretation of your n=25 daily-resolution cohort study, or predict user retention from your 300-column, 20K-row Excel spreadsheet.

In their paper, the authors dismiss most of NN's greatest recent successes as being "specialized" applications that only work because they incorporate tricks like recurrence and convolution, and not because they are neural. This is a much clearer, bolder claim, but they hardly support it as far as I can tell. The things that they call "specialized" (RNNs and CNNs!) are what most would recognize as the bread-and-butter of neural network design.

<comment><USER5> Right, the whole point is that neural networks let you apply tricks like convolution or recurrence to capture a lot of the structure in the model domain and exponentially reduce the search space for your model when dealing with large inputs like detailed images or waveforms.

<comment><USER6> Could one say, in a sense, that recurrence is essentially differential equations and convolution essentially more complicated operations than those of arithmetic polynomials?

This might sound like nonsense. On the one hand, most trivial convolutions use trivial operators; "polynomials" might include higher operations anyhow, or approximate some of the more important ones, none of which is appealing if simplicity equals efficiency. On the other hand, I never really understood diff-eqs; ODEs seem like polynomials over self similar polynomials, to me, hence "recurrent"; All the other diff-eqs I can't begin to fathom.

<comment><USER7> There's many perspectives on everything. Deep ConvNets, for instance, can be expressed as a continuously evolving ODE. Here's a fantastic paper on this view:

[https://papers.nips.cc/paper/7892-neural-ordinary- differenti...](https://papers.nips.cc/paper/7892-neural-ordinary-differential- equations)

</comment></comment></comment></comment><comment><USER8> At the beginning the authors claim they're not just making a restatement of the Stone-Weierstrass theorem (any continuous function on a compact set can be approximated arbitrarily well by a polynomial), but reading through, I'm not sure what they're proving besides that. In fact, on pages 6-7 they simply appeal to that theorem before stating "NNs can loosely be viewed as a form of polynomial regression". Most of the rest of the paper is comparing polyreg and NNs on various datasets. Sec. 9 doesn't have anything doesn't have anything especially novel in it. For instance, in 9.3 they say they'll explore the causes of overfitting in the context of their "NN <-> PR" principle, but never actually do so...

Polynomial regression is nice because it's a little easier to interpret, and it's also a convex problem with a single, global minimum. OTOH you have to design features yourself, otherwise for high-dimensional problems polyreg quickly requires way too much memory and compute to solve in a reasonable amount of time.

This paper might have been more interesting if it had somehow connected neural nets to those facts, or if it had shown how insight on the way in which neural nets work can be used to improve polyreg. But (admittedly, from a brief reading) I don't anything like that here.

<comment><USER9> I agree. All I see here is: "We know any reasonably smooth function can be approximated by a neural net, likewise it can be approximated by a polynomial. So they're the same!" Imagine how it's going to blow their minds when they find out about Fourier transforms or wavelets!

There are lots of ways to approximate functions; the property of NNs that make them attractive for ML isn't the universal approximation theorem. It's that there's a fast, robust method of training then that's easy to implement, easy to vectorize, easy to parallelize, and easy to customize for different applications.

</comment></comment><comment><USER10> This is an essentially meaningless finding. Neural networks had the dark days they did in the late 90's/early 2000's because computational power didn't allow for the depth they needed to be applicable to most problems. Once GPUs caught up to the method, deep neural nets have thrived on some problems.

Those problems are precisely the ones that this paper doesn't evaluate (image recognition, text processing, etc.). In most other domains, tree-based models crush neural nets and statistical regression methods, and so this whole thing just ends up being an academic exercise.

<comment><USER11> It's not a finding. They never compare their results to literature benchmarks, just to the networks they've managed to estimate in R. They also say that charitably they've refrained to reporting the "worst results", but fail to present a summary of quality of results found over the many networks they ran.

<comment><USER10> I agree, though they do make the pretty strong statement of

      NNAEPR suggests that one may abandon using NNs altogether, and simply use PR instead.

in the blog post, which sounds to me like they're going for a finding.

</comment></comment></comment><comment><USER12> Important point:

> _Our work so far has primarily been on general feedforward NNs. Our > investigations have not yet involved much on specialized networks such as > convolutional NNs (CNNs) for image classification, recurrent NNs (RNNs) for > text processing, and so on. Though we intend to adapt our ideas to these > frameworks, we view them as separate, orthogonal issues._

<comment><USER13> >Though we intend to adapt our ideas to these frameworks, we view them as separate, orthogonal issues.

The authors should read about dynamical systems. I don't understand why the physics/controls folks, DSP folks, and ML folks don't read each other's papers. They're using the same math and using the same concepts. The latter two groups seem to be working together more often however.

</comment></comment><comment><USER7> Their applications are tabular data (for which MLPs have never been the method of choice) and MNIST (which I could classify at 85% with a rusty nail), so it's not super impressive.

NNs and the associated toolkit shine with structured high-dimensional data where CNNs, RNNs, or modern shenanigans like Transformer networks excel. I sincerely doubt that these networks turn out to be reducible to polynomial regression in any practically useful sense of the notion. But who knows.

<comment><USER9> Terminology note: data like images and voice which have strong spatial or temporal patterns are actually referred to as "unstructured" data; while data you get from running "SELECT * FROM some_table" or the carefully designed variable of a clinical trial are referred to as "structured" data.

If this seems backwards to you (as it did to me at first) note that unstructured data can be captured raw from instruments like cameras and microphones, while structured data usually involved a programmer coding exactly what ends up in each variable.

As you say, deep neural networks based on CNNs are SOTA on unstructured image data, RNNs are SOTA on unstructured voice and text data, while tree models like random forest and boosted trees usually SOTA on problems involving structured data. The reason seems to be the that the inductive biases inherent to CNNs and RNNs, such as translation invariance, are a good fit for the natural structure of such data, while the the strong ability of trees to find rules is well suited to data where every variable is cleanly and unambiguously coded.

<comment><USER7> Yeah, that's right. Doing too little proofreading with HN comments...

</comment></comment></comment><comment><USER14> Is the relevant model here simply a sum of 2nd order terms?

It's widely known to practitioners vanilla Neural Nets don't do very well on small datasets because of overfitting issues -- which can probably be corrected with very careful regularization and parameter optimization, but where generally it's best to just use simpler methods.

Polynomial regression is one of those, but I'm not sure how it compares to other methods such as random forests and KNN variations.

Those methods don't scale very well, in particular PR (if I'm interpreting correctly) doesn't scale, because depth is essential to solving complex problems with computational efficiency.

The researchers conveniently refer to those more complex tasks as a 'work in progress'... when they are what NNs are mostly used for (i.e. it starts getting interesting with CIFAR-10). That said, I would be curious to see performance of deeper polynomial regression networks. They become almost identical to NNs then, but maybe some methods of PR could be extended to give an edge in some cases (e.g. perhaps better regularization techniques than dropout/etc).

</comment><comment><USER15> Previous discussion (June 24, 2018): [https://news.ycombinator.com/item?id=17385383](https://news.ycombinator.com/item?id=17385383)

</comment><comment><USER16> Dismissing more interesting architectures, and ignoring the different approaches to fitting makes this seem very incomplete. I've long thought that neural networks are principally useful when the architecture can be chosen to exploit structural features of a problem - it hardly seems surprising that feed-forward neural networks with a given architecture have an alternate representation as polynomial regression. The focus on multicollinearity is also sort of odd here - I usually take it as a given that neural networks provide an over-complete basis which only works due to various kinds of regularization (and the use of optimization techniques like gradient- descent/back-propagation, which aren't really concerned with globally optimal parameter estimates, but rather in producing good fitted values/predictions).

</comment><comment><USER17> > Our work so far has primarily been on general feedforward NNs. Our > investigations have not yet involved much on specialized networks such as > convolutionalNNs (CNNs) for image classification, recurrent NNs (RNNs) for > text processing,and so on. Though we intend to adapt our ideas to these > frameworks,we viewthem as separate, orthogonal issues.

This is a interesting insight. Future work is needed though. The vast majority of impressive results using NNs have been achieved by specialized networks, with special mention for resnets in vision [and Go] and transformers for NLP.

</comment><comment><USER11> This is a... preprint. It's clearly not ready for the prime-time yet.

The main interesting finding for me was the utility of variance inflating factors in debugging neural networks. But not only the thing lacks a lot of polish (what is their metric for "accuracy"?), but it's still quite "unscholarly", most noticeably lacking:

* serious comparisons with classic literature benchmarks (I'm not even saying state-of-the-art) of NNs rather than whatever they were able to find with R. (Who uses R in academic machine learning?)

* a better developed argument about how Taylor is good enough. I'm not saying rigorous, but an article about reinforced concrete that just said what they said wouldn't be enough. An example of a workable engineering-type Taylor argument would be something that says that all minima are locally like parabolas and h~=0.01 is a very conservative upper bound for the needed approximation because the material is almost 100 times as strong and we just need 10 times for this calculation.

* reproducibility, reproducibility, reproducibility. Don't R people have Jupyter notebooks? Does their Keras package not serialize network structure and weights? Keras for Python does.

<comment><USER16> > Don't R people have Jupyter notebooks?

Yes, though I prefer Rmarkdown documents.

</comment></comment><comment><USER18> They revised the paper in response to earlier, uh, response.

[https://matloff.wordpress.com/2018/07/01/update-on- polynomia...](https://matloff.wordpress.com/2018/07/01/update-on-polynomial- regression-in-lieu-of-neural-nets/)

[https://arxiv.org/abs/1806.06850](https://arxiv.org/abs/1806.06850)

</comment><comment><USER19> I suppose it depends on the activation function, but many of them are bounded. Polynomials are unbounded at the extremes, and as such should really only be trusted (sometimes) for interpolation, not extrapolation. If you get a new input which is outside the radius of your training set, the answer could be pretty extreme and not supported by the training data.

<comment><USER11> > Polynomials are unbounded at the extremes, and as such should really only be > trusted for interpolation, not extrapolation.

Very well noted. There's also this, which is usually taught in second year engineer "numerical calculus" and again extensively studied in graduate programs involving [something numbers inside computers something]:

[https://en.wikipedia.org/wiki/Runge's_phenomenon](https://en.wikipedia.org/wiki/Runge's_phenomenon)

<comment><USER19> It was exactly that topic which is why I included the "sometimes" qualification :-)

</comment></comment></comment><comment><USER20> ANN's aren't that much different than polynomial regression, the issue is that there are upwards of millions of parameters. Totally intractable for the human mind.

</comment><comment><USER21> They are also almost exactly functional composition. Were it not for the activation terms, this composition would reduce to a simple linear equation.

</comment><comment><USER22> This isn't a serious ML result; it reads more like course notes/toy experiments rather than a serious research effort. The funny thing is, this is still only for tabular data; we don't see any actual classification results with any proper robust metrics (also the PCA setup seems a bit bizarre in this setting).

</comment><comment><USER23> The actual blog post: [https://matloff.wordpress.com/2018/06/20/neural- networks-are...](https://matloff.wordpress.com/2018/06/20/neural-networks-are- essentially-polynomial-regression/)

<comment><USER24> Thanks, we've updated the link from [https://www.r-bloggers.com/neural- networks-are-essentially-p...](https://www.r-bloggers.com/neural-networks-are- essentially-polynomial-regression/).

</comment></comment><comment><USER25> I mean both are ~general classes of functions, so not surprising they can represent each other?

</comment><comment><USER26> A biological neural network does much more than neural models. How much more and why? we don't even know.

Most neural models don't use spikes or dynamical systems, or some of the most intrincate stuff going on in neurons.

</comment><comment><USER27> I'm not an expert in ML. However, with what little I do know, I wonder how well "training" a neural network really mimics the brain.

Our brains grow as we mature and along the way reinforce pathways as we internalize information. Our interpretation of the world is internal and unique to our individual consciousness.

The part that is "trained" is how we relate that information externally to our environment and other entities.

A child says "Da da" because it learns that sound elicits a reaction. The internal representation of its father is not trained. It is where the neurons grew and reinforced.

Maybe poorly communicated on my part to people who know much more about it than me. Tl;dr: maybe focus less on perfecting the training of recognition and more on the training of mapping the external to what was naturally recognized where the neurons fell.

<comment><USER28> The so-called 'neural networks' have nothing to do with the brain. They're only called that as a branding exercise. Because math is scary and boring, biology and brains are warm and fuzzy.</comment></comment>