Investors Bet Against Tesla–and Lost $8.4B in Five Weeks - <AUTHOR> https://www.wsj.com/articles/investors-bet-against-teslaand-lost-8-4-billion-in-five-weeks-11581284236 <comment><USER2> Those sensational headlines. TSLA is 22% below the peak 3 trading days ago. Can we have a silly headline like this, given the change in market cap?

> _TSLA bulls lose $38B in 3 days._

<comment><USER3> the shorts had to cover their positions, doesn't matter how the stock is doing days or weeks after that..."The market can remain irrational longer than you can remain solvent" and all.

<comment><USER4> It's very hard to short stocks. Most high flyers will eventually collapse. The problem is that you can't tell the difference between the bubbles and the actual winners.

You don't have to cover your shorts unless you breach a limit that the brokerage has set. That limit is based on how much liquidity you have. I suspect the majority of the shorts that can continue to hold their position are still shorting hoping to get out at a better price.

</comment></comment></comment><comment><USER5> Traders don't bet for or against companies like Tesla. They bet on the movement of their stock, which is governed by the behavior of crowds.

<comment><USER6> What?

Markets are driven by the collective perception of the future performance of the company. Sure it is wildly speculative at times, but buying or shorting a stock is ultimately a bet on the future performance of the company.

</comment></comment><comment><USER7> [http://archive.is/uYhKN](http://archive.is/uYhKN)

</comment><comment><USER3> Live by the word, die by the sword. I know short sellers play a vital role in the game, but they also play dirty tricks. Sometimes they win, sometimes they get slaughtered.

<comment><USER7> What kind of dirty tricks?

</comment></comment><comment><USER8> 'Markets can remain irrational far longer than you can remain solvent'

I have little sympathy for short sellers. Betting on any company to fail is a negative perspective. It's particularly foolhardy to bet against Elon.

I also do not find the common economic argument, that short selling introduces price efficiency, compelling. Most public markets are able to efficiently manage price discovery without negative pressures, such as housing markets, wages, etc. Furthermore, the advantage appears to be extracted purely as profit by the short seller.

<comment><USER9> Short sellers have a place in the market. They put in place a mechanism, in real markets, to hold a stock to honesty.

Imagine if WeWork could be shorted, people would have been able to hold the stock price down. Instead of the last minute moment where everyone looked around and went: It's a REIT!

Where I share your sentiment on short sellers and longs are the ones who fake information / overpromote it to make some money, which distorts the market for the commoners.</comment></comment>


Create a new poll on HN - <AUTHOR> http://news.ycombinator.com/newpoll

<comment><USER2> _"1 Mar: Polls

Since polls are so common on News.YC, we just added explicit support for them. To prevent the site being swamped by polls for the next few days, we'd appreciate it if you'd only use this feature because there was something you already wanted to ask. There isn't currently any link to it, so you have to go to <http://news.ycombinator.com/newpoll> to make a poll, and for the time being only users with over 200 karma can make them. Once people get used to this we'll open it up to everyone."_

Seems that has now been reduced to 20 karma - but I believe the logic of not linking to it to prevent polls taking over the site still stands.

</comment><comment><USER3> Weird. I get the error "Sorry, you need 20 karma to create a poll, " despite having karma of over 1000. Perhaps this still has some bugs.

<comment><USER4> [EDIT: The last polls are from a user with 250 points, so the following explanation is wrong.]

In the last months the site grow a lot, and the administrator made all(?) the karma thresholds bigger. Probably he changed the threshold for polls, but he forgot to update the error string.</comment></comment>


Keep Control of Your Start-up Forever - <AUTHOR> http://www.inc.com/andre-gharakhanian/keep-control-of-your-start-up-forever.html <comment><USER2> "Make hockey stick growth a reality." Wow, great advice. I almost forgot to do that one.

</comment><comment><USER3> No VC money will come in if you want to keep full control.

Keep full control (and don't take VC money) == 0.00001% success rate (Google, Facebook). Same as lottery.

Give up control (but take VC money) == 0.5% success rate. Still better chance of making something.

<comment><USER4> Google and Facebook had gobs and gobs of VC.

</comment></comment><comment><USER5> 787 words and still so low on anything resembling content.

Does anyone have some comments regarding voting agreements in the context of VCs ?</comment>


Phratch: A port of Scratch on Pharo - <AUTHOR> http://www.phratch.com/ <comment><USER2> Can someone give me a TL;DR on what Pharo is? It's website is infuriatingly vague. It seems to be a visual programming environment based on a language related to Smalltalk? In which case, it's similar to Scratch, and in which case what's the point of porting Scratch to it?

Edit: ah, the old Pharo website (accessible through the link at the top), puts front an center "Pharo is a clean, innovative, open-source Smalltalk-inspired environment". OK then. Good job on redesign that _loses primary information_. /rant

<comment><USER2> Extra rant: I love the idea of Smalltalk and of reactive environment/IDE (projects like excellent Lighttable try to emulate it), however in the case of Scratch and Pharo this comes at the cost of bootstrapping. You're doing the Bender thing: "fuck your OS and tools, I'll create my own OS and tools! With Blackjack! And hookers!". As a result, it discards all the tools and facilities we've built and are familiar with. I'm using a tiling window manager and I love it. Why should I discard that entirely that to use Pharo's own inferior window manager? I've invested much pain and effort into learning Emacs. Can I bring over no skills from there to your environment?

Essentially, the transition cost to these Smalltalk environments (be it Scratch, Croquet, or Pharo) is too high to ever gain critical mass. And that's a shame. Considering how regularly this situation is repeated, I have to ask if it's something inherent to Smalltalk? Or its legacy?

<comment><USER3> You got it wrong actually. Smalltalk is not supposed to integrate with everything. It is everything which is supposed to become Smalltalk based, the desktop/working space, the GUI and the IDE, right down to the OS and the kernel.

Smalltalk was not designed to be a programming language. It was intended to be the whole system. I think those developers who are treating and developing Smalltalk only as a programming language and a development environment have got it wrong, although it is the pragmatic thing to do. People who are ignorant of Smalltalk simply don't understand how backward contemporary computing its, relative to the way it should be now, 30 - 40 years after the first implementations.

After it emerged, the industry majors simply diverted it way from the original vision of its developers, which was focused on exploring and developing for personal use either recreational or work related, and turned it a development tool costing thousands of dollars.

My own interpretation is that the industry majors stifled it, masking the process as bad business and marketing decisions.

I mean what could be possibly have been wrong with Smalltalk when the IBM's first Java implementations and IDEs were built with Smalltalk, and Sun bought out the company which developed one the fastest Smalltalk implementations to put their developers into creating Java?

I think the current problem with open source Smalltalk is that the developers are spread among different implementations. It would be better if there was one vision and one implementation that they all focused on.

<comment><USER4> > It is everything which is supposed to become Smalltalk based, the > desktop/working space, the GUI and the IDE, right down to the OS and the > kernel.

Correct. This is a strength and a weakness. I was enamored to Smalltalk early on (back in 95 when I learned it in a course) for this very reason. But then the Internet was happening, the world of computing became a lot more heterogeneous, and the idea of a mostly uniform world of computing mostly faded away.

> I mean what could be possibly have been wrong with Smalltalk when the IBM's > first Java implementations and IDEs were built with Smalltalk

It was handy after IBM's acquisition of OTI.

> Sun bought out the company which developed one the fastest Smalltalk > implementations to put their developers into creating Java?

This is inaccurate. Animorphic was bought out for its compiler technology to improve Java; Java was already invented at that point.

> It would be better if there was one vision and one implementation that they > all focused on.

Developers are moving on to new things. There is Dart of course (if we are talking about developers of smalltalk), and Kay's VPRI which are attempting to develop the next best thing.

<comment><USER3> > Correct. This is a strength and a weakness. I was enamored to Smalltalk > early on (back in 95 when I learned it in a course) for this very reason. > But then the Internet was happening, the world of computing became a lot > more heterogeneous, and the idea of a mostly uniform world of computing > mostly faded away

I don't think it was the world of computing becoming more heterogeneous, it was more the desire of the industry majors to push their own backward technologies.

What prevented Smalltalk from being used as the tool for developing web pages instead of Java, other than Sun wanting Java to proliferate by making it free, and IBM and the other Smalltalk developers messing up Smalltalk? And today we have Oracle threatening Java by insisting that copying of APIs is infringing.

What prevented the Smalltalk interface from becoming the browser interface as well as its main development tool? This was the original idea, the original vision the Dynabook vision.

Smalltalk developers should develop it along the lines of Smalltalk/X or Smalltalk/MT and build it all the way up and down as well. Trying to fit it into environments which the industry majors are bent on fragmenting and thwarting in order to buy time put their software, multimedia and storage rental models into place simply won't work.

> Sun bought out the company which developed one the fastest Smalltalk > implementations to put their developers into creating Java?

I meant the VM

> Developers are moving on to new things. There is Dart of course (if we are > talking about developers of smalltalk), and Kay's VPRI which are attempting > to develop the next best thing.

The Dart developer experience will never match the Smalltalk developer experience and VPRI is also building on the crippled Javascript/HTML/DOM foundations.

I can't see why these smart guys don't see that you cannot build on systems which the industry majors are deliberately hobbling in order to buy time to put the rental models into place. They break it and complain that the standards bodies are slowing things down _when they and their proxies are the standards bodies._

Smalltalk developers need to knuckle down and get their NPAPI/Pepper/NaCl act together. As that is the only way they can succeed with a browser based act.</comment></comment></comment></comment></comment>


Fun with SQL: Window Functions in Postgres - <AUTHOR> https://www.citusdata.com/blog/2018/06/01/fun-with-sql-window-functions-in-postgresql/ <comment><USER2> Window functions are actually part of the SQL 2003 standard.

Here is the best way that I've found to think about them. Sometimes you run across a SQL problem that makes you think, "This would be easy if I just sorted my table, and ran a program over it breaking it into partitions then processing each partition in order." Whenever you do that, window functions will solve that problem.

Note that in practice I've found that queries using window functions often are best done by something of a form: SELECT ... FROM (SELECT ...) foo WHERE ... GROUP BY ... where the window functions are all in the inner query, and the outer query's group by collapses each partition into a single row.

<comment><USER3> Window functions are super handy to turn a correlated subquery into a join, because they make group-wise limits fairly easy (just put a ROW_NUMBER() concerning the relevant partition, i.e. what would be your GROUP BY in the correlated subquery, in your query and select from that query filtering on rank; then join on whatever you previously correlated on).

Basically: SELECT ... FROM (SELECT ..., ROW_NUMBER() OVER (PARTITION BY my_group [ORDER BY...]) AS rank) AS foo WHERE foo.rank <= 10

Without window functions you can usually only do this using a correlated subquery, which usually is much slower for fairly obvious reasons.

<comment><USER4> Yup, if all you ever learn is one windowing function, the "greatest N per group" pattern with ROW_NUMBER() is easily the most common.

</comment></comment></comment><comment><USER5> There's a nice set of challenges for learning window functions and testing your window function knowledge: [https://www.windowfunctions.com/](https://www.windowfunctions.com/)

</comment><comment><USER6> I've noticed that ntile(n) can give unexpected results when there are fewer input rows than n, so cume_dist might be a safer choice (or percentile_disc or percentile_cont). I wrote some more details here:

[https://stackoverflow.com/questions/27883999/how-to- calculat...](https://stackoverflow.com/questions/27883999/how-to-calculate- percentile-in-postgres/39535688#39535688)

This behavior means that ntile(100) is not the same thing as percentile.

But I've always wondered if I was just misunderstanding something. I wonder what others think?

<comment><USER4> ntile() is one of those functions that just never seems to work the way users expect regardless of the RDBMS. I don't know if the spec's definition was just poorly thought out or what, but it's often flaky, poorly performing, or both in many RDBMSs.

In PostgreSQL, you should generally use cume_dist(), percentile_cont() and percentile_disc(). Most later releases of other RDBMS have similar window functions that work more like users expect. I'm not certain what's up, but it's definitely led me to believe that ntile() was just poorly thought out at the spec level.</comment></comment>


Compiling To Javascript In Continuation Passing Style, Can We Optimize? - <AUTHOR> http://jlongster.com/2012/05/11/cps-optimizations.html

<comment><USER2> I've spent a number of months working on using CPS and trampolining to add proper tail calls to Clojure. I have a video presenting my work here: <http://www.chrisfrisz.com/blog/?p=220> . You can also take a look at the code here: <https://github.com/cjfrisz/clojure-tco> .

The punchline is that there are several things you can do to improve your performance: first, a number of more efficient CPS algorithms have been developed over the last 10+ years. I currently use one presented by Danvy in the 2001 paper "A First-Order One-Pass CPS algorithm" linked here: www.brics.dk/RS/01/49/BRICS-RS-01-49.pdf . It's major focus is to distinguish between "serious" and "trivial" expressions, because the serious ones are the only ones that actually require a new continuation to be generated. This saves a lot of administrative redexes that can kill your performance.

Some other CPS-related avenues you may want to look into include "The Essence of Compiling with Continuations" (co-authored by one of my heroes, Amr Sabry) which formalizes A-normal form, an alternative to compiling with continuations that was ground-breaking in pointing out the number of unnecessary redexes introduced by traditional CPS algorithms. There's also a more recent paper by Andrew Kennedy at MS Research called "Compiling with Continuations, Continued" which I admittedly have not gotten a chance to dig into yet. It's stated goal is to revive some of the ideas of the original "Compiling with Continuations" by Andrew Appel.

Of course with the method you present, continuation application isn't your only performance hit. If you're using a trampoline, you're undoubtedly thunkifying the code to delimit the bounces on the trampoline. I also need to do some work in this area, but I'm familiar with at least one paper on doing minimal thunkification from 1993 and linked here: [http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.158....](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.158.7919) .

I'm a big fan of both CPS+trampolining and the work like ClojureScript that's bringing efficient Lisp programming to the JavaScript arena. I'm hoping to get a chance to look over the work that you've done with Outlet and I'd love to chat with you about it. It sounds like we share quite similar interests.

<comment><AUTHOR> I already watched your video! It was one of the things that inspired me to try this. Some of it was over my head (not extremely involved in the academic world), but I'm at a place now where I can dig into clojure-tco and see what you've done.

Thanks for the papers, I'll look at them. I'm worried about spending a lot of time on this, only to realize that the performance hit is simply too large. I want this for debugging, and what I really want to try is to write a web-based byte code VM and compile Outlet to it. But the same concern exists there: can I get it fast enough to run sufficiently?

I'm leaning more towards the CPS route though. First of all, there's tons of research going into it. Secondly, I lose all the benefits of JIT-ed Javascript if I run it in a VM. There's actually a much higher chance that I'll be able to get CPS-ed code running fast than compiled byte code.

I admit that my current implementation is naive, and yes, the trampolines require even more thunks.

I'd love to talk, I'm very interested in this as well. How far has clojure-tco come? What's the performance hit, and how do you return code to the trampoline? I will look at your code soon, and be lurking around #clojure as jlongster.

<comment><USER2> I've been finishing up grad school for the past couple of weeks, so Clojure TCO hasn't seen updates for a while. One of the things on my to-do list for it is to do more extensive benchmarking, but I've thrown a lot of ad-hoc tests at it, and I'm getting remarkably close performance to standard Clojure code. Especially with your interest, I want to nail down some numbers to have solid performance comparisons.

I noticed that somebody commented about allocation being a big source of slow down. Someone suggested to me that if you have low-level enough access to your implementation, you can reuse the thunk after each invocation. It took me a while to get my head around it, and I'm not even sure it can be done in Clojure TCO. If you can change the contents of a underlying closure data structure, then you only have to allocate one thunk. I suspect that you're taking advantage of JavaScript's closures, so you may not have any more luck with it than me.

If you're interested, one of my next goals now that I'm done with school is to start writing about the algorithms that Clojure TCO uses. I want to write something fairly accessible that describes the Danvy CPS algorithm.

<comment><AUTHOR> "... I've thrown a lot of ad-hoc tests at it, and I'm getting remarkably close performance to standard Clojure code"

That's amazing!

"Someone suggested to me that if you have low-level enough access to your implementation, you can reuse the thunk after each invocation ..."

Yep, I thought of that when I was looking at the generated js code. I'm think of out of luck as well. However, as I mentioned at the end of my article, I think you should be able to hoist all the functions into top-level forms and pass around an environment. This way, functions are statically allocated once, and the performance hit of passing around environments can't be nearly as great as function allocation.

</comment></comment></comment></comment><comment><USER3> Why do you need to transform to CPS? The answer to your question will depend very much on your answer to that question. In the extreme if you are not doing anything with the CPS form, then probably the best optimization of the CPSed form will completely undo the CPS, transforming it back into direct style. Of course if you are actually making use of the CPS form, that's not possible anymore.

Depending on why you want CPS, you can apply the following strategy:

Keep all code in direct style. For each function, designate a special return token CaptureCont that indicates that the continuation should be captured. The source of this token will be callcc. After each function call you check if it returned a token, and if so, extend it with the continuation for the rest of the computation. Then on the main() function of your program, pass the continuation to the appropriate place. This strategy avoids most overhead in the common case: one if instanceof check plus a branch per function call.

For example, take this function:

        def foo(x,a):
          y = g(x)
          return y+a

Transform to:

        class CaptureCont:
          member target # the function that we will pass the continuation to once we finish constructing it
          member partialCont # the part of the continuation captured so far
          def extend(f):
            newCC = new CaptureCont()
            newCC.target = target
            newCC.partialCont = lambda v: f(partialCont(v))
          def invoke():
            target(partialCont)

        def foo(x):
          y = g(x)
          if y is CaptureCont:
            # now y is the part of the continuation captured so far
            # our job is to extend it with our stack frame
            # and then return it so that the callee can build it up further
            return y.extend(lambda y2: y2+a)
          else:
            return y+a

Instead of just invoking main(), do this:

        loop:
          v = main()
          if v is CaptureCont: v.invoke()
          else: exit(v) # well I guess this is not necessary in JS

Eventually the CaptureCont will bubble up to main, and at that point main will invoke it so that the continuation is passed to the right target.

Callcc:

        def callcc(f):
          cc = new CaptureCont()
          cc.target = f
          cc.partialCont = lambda x: x
          return cc

There are various optimizations that can be applied (like eliding the capture code for functions that you statically know don't call callcc and thus will never return CaptureCont), and this approach also (trivially) works for the more general delimited continuations. As described capturing the continuation is O(n) in the size of the stack. You can make it amortized O(1) with some more trickery by lazily rebuilding the stack, but the current approach is already blazingly fast in the case of no continuation capture. I'm really tired now, so there are probably lots of errors in the above description, so tread with caution. I don't know if this approach is new or not, but it probably isn't given that it's a fairly obvious approach to capture the stack. Does anybody know what it's called? Then the OP can find a better description.

<comment><AUTHOR> That's a smart trick, and it's possible I might be able to do something like that.

The reason I want to do CPS is for debugging in the browser. I want to be able to control the stack, so when a breakpoint hits I can pause everything and step through the code. The browser is non-blocking so I need explicit control of the stack.

You're method is neat. My language doesn't support continuations, so I don't need them until I hit the debugging mode. You've made me curious if I can compile out both CPS-ed and non-CPS-ed versions of the code and somehow switch between them.

<comment><USER4> I did a very similar thing with a python-implemented LISP interpreter, mainly so that I could implement a trampoline so I could do tail call optimization. It required CPSing the _interpreter_ (and built-in functions), but not the interpreted program- this works because the continuation of the interpreted program is contained in the continuation of the interpreter that runs it. The interpreted "stack" ends up as a chain of Python closures.

You might be able to get away with compiling a runtime environment slightly more complex than your simple trampoline loop that does the same thing, building a chain of JavaScript closures to represent continuations without actually CPSing the rest of the program. Continuation calls would then show up on the JavaScript stack and allow you to step through them.

<comment><AUTHOR> Wouldn't that be even slow though? Not only is it CPS code, but it's a program being interpreted by CPS code. I think I see what you're getting at though. Sounds neat; I definitely have a lot of new ideas for implementing CPS in a performant way now.

Outlet is a compiler which compiles straight to js, no interpretation.

<comment><USER4> Not sure; I haven't got anything to benchmark my implementation against. My suspicion is that it would be faster because you get chains of interpreted- continuations-implemented-as-interpreting-closures that call each other normally, rather than trampolining absolutely everything. But I would not be surprised if I turn out to be completely wrong about that.

> Outlet is a compiler which compiles straight to js, no interpretation.

Right; hence, you would have to include the implementation of the CPSed run time environment in the compiled output, just as you have to include the extra trampoline function when you do the current CPS transform.

</comment></comment></comment></comment></comment><comment><USER5> 1) Using one of the more efficient CPS transformations will help remove many stupid constructs that are harder to statically find later.

2) In our CPS-based intermediate representation, we rely heavily on control flow analysis (CFA) to enable many classic compiler optimizations (inlining, untupling, unreachable code elimination, cases where only one member of a datatype is constructed/destructed, etc.).

CPS is a great transformation and makes for a wonderful IR, but you have to pay a decent static analysis cost before you will be able to perform many classic optimizations and get great performance. That said, we've done pretty well (<http://manticore.cs.uchicago.edu> ), but it's taken years of development. I'd also like to second cjfrisz's pointer to Appel's green book. It's a fabulous introduction to compiling in a CPS-style IR, though you'll find you still have a fairly large performance gap if you don't implement the CFA-based versions of them.

<comment><USER6> Re the manticore home page, a minor nit: the antonym of fine-grained is _coarse_ -grained, not course-grained.

<comment><USER5> Thanks! That text has been there for at least 6 years and we've never noticed.

<comment><USER6> It's also in the wiki, I believe.

</comment></comment></comment></comment><comment><USER7> I think your intuition is exactly correct; it's the function allocations that are killing you.

Fascinating stuff.

</comment><comment><USER8> If you haven't read it already, this paper is quite interesting with regards to supporting TCO in javascript (using trampolines as a last-resort). <http://www-sop.inria.fr/indes/scheme2js/files/tfp2007.pdf>

</comment><comment><USER9> I went down this road before.

I had an idea but never got around to implement it. Is to use the new es- harmony generators to pause execution in non-cps-ed version of the code. I'm happy to further elaborate on that if you're interested.

<comment><AUTHOR> I thought of that at one point, but the lack of browser support kills it for me unfortunately. :/

</comment></comment><comment><USER10> Could you try your code in some other JS-based Schemes for comparison, e.g. <http://www.biwascheme.org/> ?

<comment><AUTHOR> I don't see any reference to continuations in there.

<comment><USER10>
       biwascheme> (call-with-current-continuation (lambda (k) (k 12)))
       => 12

It's based on Dybvig's "Three Implementation Models for Scheme" <http://www.cs.unm.edu/~williams/cs491/three-imp.pdf>

<comment><AUTHOR> Oh, cool. It appears to be an interpreter, which is interesting, and worth profiling to see how it performs. I'll have to do that later.</comment></comment></comment></comment>


100,000 free bottles of Vitaminwaters new flavor: Facebook Connect - <AUTHOR> http://ryanspoon.com/blog/2010/03/06/vitaminwater-connect-facebook/

<comment><USER2> This is the kind of innovative, interactive advertising that we need to see more of. Forget banner ads, engaging users is so much more effective.

</comment><comment><USER3> Tastes like Teen Spirit.</comment>


Capitalism at bay - <AUTHOR> http://www.economist.com/opinion/displaystory.cfm?source=most_commented&story_id=12429544

<comment><USER2> Capitalism FTW! The current crisis, far from being a failure of capitalism is actually a major success of capitalism. Because, despite contrary to the best efforts of some people, the market place has not been hoodwinked and is currently, of its own volition, revaluing assets inline with their true values. That isn't to say that this readjustment won't be painful, for some people it will, but that is not the fault of capitalism but the fault of people playing silly buggers.

<comment><USER3> Permit me a moment of apoplexy.

I'm back.

 _[T]he market place [is] revaluing assets inline with their true values._

This begs the question of how the assets became overvalued in the first place. The answer, though hard for market apologists to swallow, is that the market did it. We can't simply presume that every good thing that happens is due to the market and every bad thing is some unexplained phenomenon.

 _[T]hat is not the fault of capitalism but the fault of people playing silly buggers._

This is the No True Scotsman fallacy. We can't say that "True Capitalism" would have fixed this, but _people playing silly buggers_ are the cause of all the trouble. News flash: The market is composed of people playing silly buggers! This is the very crux of the point. "True Capitalist Markets" may always value assets best when unregulated, but "True Capitalist Markets" don't exist. Classical free markets are a mathematical construct in which all the agents act rationally but with imperfect information. Real markets are real constructs where the agents are silly stupid human beings with all their irrational beliefs and psychological frailties. This is why there is an emerging field called "Behavioral Economics." This is why there was an article by Paul Krugman featured here the other day about why real markets failed English Cuisine for a century or more.

The point can be beautifully summed up in a joke I read once: An economist and his granddaughter were walking along when the granddaughter saw a $20 bill on the sidewalk. Anxious for moral guidance, she tugs on her grandfather's shirt and asks, "Should I pick up that $20 bill?"

"Nonsense," replied the economist. "If that were a real $20 bill someone would have picked it up already."

<comment><USER2> Hmmm. I don't think we're in disagreement. I never claimed the market is perfect. My point is its miraculous tendency for self correction even in spite of fraudulent practices and bad government policy. You cannot expect this kind of silly buggery to fall under the jurisdiction of market forces and we don't. That's why we have laws and tried and tested policy. When you violate this that is when you get into trouble. And that is exactly what happened this time. It wasn't business as usual that got us into this mess. However at least we have a free market to get us back on track. Heavily socialist systems can shield people from the truth of the problem and they can languish indefinitely as a result (an extreme example: The Great Leap Forward). Free markets won't.

<comment><USER3> I appreciate your reasoned reply in the face of my (sometimes) animated post! (I hope you could tell, even through the flattened nuance of a forum post, that I was having a little fun and not being a jerk.)

However, I think that we really _are_ in disagreement. There _was some_ government policy that was bad for the market (easy money leading to bad lending) but the creation of credit default swaps certainly has to fall under "the (real) market."

This is my point about the No True Scotsman fallacy. Buying a credit default swap certainly had to be a bad idea from the very beginning. You're insuring an asset that you don't (necessarily have to) own. This falls right under the classical definition of a "Moral Hazard." However, they _were_ bought by the very agents (or at least agents indistinguishable by market theory from the actual agents) that compose the market that is now correcting itself. The agents were incapable of seeing the disaster ahead. This either means that they weren't rational (in which case we don't have a 'market') or that they were rational (in which case free markets really did get us into this mess). I don't know which is more frightening.

The analogy is often made that free markets allow a kind of evolution to occur. The fitness function is profitability/solvency, and the organisms are investors, organizations, consumers, et al. I think this is a great analogy, but it does have some interesting implications. Fraud happens in nature (caterpillars that mimic ant pheromones to invade ant nests). Boom/bust cycles happen in nature (algal blooms, even in the absence of agricultural runoff). Parasitism happens in nature. All of these things have market analogues. Indeed, all of those analogues figure highly in the current debacle.

While "[h]eavily socialist systems _can_ shield people from the truth of a problem," they _can_ also shield people from the worst of market excesses. There doesn't seem, to me at least, to be any kind of fundamental reason why regulation and government action, socialist or otherwise, either has to shield people from truth or is incapable of shielding people from what could turn out to be very dire consequences.

 _Free markets won't [languish indefinitely]_

The Krugman article I mentioned (<http://web.mit.edu/krugman/www/mushy.html>) actually talks about a case in which a free market will languish indefinitely, namely, if nobody knows to expect any better than they're currently getting. This is just one of the many consequences of the fact that the agents that compose real markets differ significantly from the rational agents of classical economics. I mean, presumably, people who advocate for free markets aren't heartless and bloodthirsty. They advocate, fundamentally, because they want what's best for everybody. I think it's important for them, in light of their desire to do good, to take an honest look at the limitations of the theory and ask, "Are we going to get what's best for everybody by blindly implementing classical economic theory with disregard for the differences between the model and reality? Or are we going to do better by implementing it only so far as it goes and then putting other systems in place to ameliorate the worst of its excesses in the fairest manner we can find?" This is fundamentally a philosophical question, not an economic one.

<comment><USER2> Great response. Don't worry I didn't think you were being a jerk before. In truth I was enjoying advocating a contrarian position and I expected a reaction. (I like to think I wasn't trolling(!) because what I said was my honest opinion). Also I think for a forum discussion not to quickly disappear down the toilet you have to assume the best of people.

Regarding what you actually said, I'll have to do some more investigating/thinking. I will concede you seem more knowledgeable than myself on this matter however the INTP in me won't concede defeat until my spidey senses stop tingling! I'll let you know if it does.

(I do like the evolutionary analogy. I think they're extremely apt).

</comment></comment></comment></comment></comment><comment><USER4> It's satisfying reading an article on this subject by someone who (seems) to know what they are talking about. I've been hearing so many opinions from so many different sources, but few seem to really understand the big picture of this issue; no doubt because it is very complex.

I found an interesting connection made between the internet bubble and the housing bubble caused by interference from the Fed (the source has a capitalist bias):

 _"Injections of liquidity to stop the meltdown in the wake of the failure of Long Term Capital Management fueled the internet bubble. Injections of liquidity to avoid a market crash when the internet bubble burst fueled the housing bubble. Now, following the bursting of that bubble, the Fed is making historically huge amounts of credit available to keep the economy afloat."_ <http://www.atlassociety.org/cth-43-2085-credit_crisis.aspx>

Another piece of the puzzle.

</comment><comment><USER5> Capitalism will succeed only when race to the bottom is prevented in rest of the world <http://en.wikipedia.org/wiki/Wage_slavery>

<comment><USER6> Have you seen the recent wage inflation in China and India?</comment></comment>


A Curated Collection of Over 150 API's - <AUTHOR> https://medium.com/@benjamin_libor/a-curated-collection-of-over-150-apis-to-build-great-products-fdcfa0f361bc#.orsmyk9r4 <comment><USER2> The article starts with "Let's talk about a few awesome API's[sic] today." Sorry, the list is not usable.

I can only comment on the location/geo API, that's what I'm most familiar with.

[http://www.housingmaps.com/](http://www.housingmaps.com/), is a mashup from 2005, and not updated since and not an API.

Yahoo maps ("We are shutting down this service."), Fireagle (closed years ago), Placefinder (closed), Zillow Neighborhood data (not an API, it's data to download and on a different URL).</comment>


Writing a Non-Blocking JavaScript Quicksort - <AUTHOR> http://www.breck-mckye.com/blog/2015/06/writing-a-non-blocking-javascript-quicksort/

<comment><USER2> The obvious solution is to use a Web Worker,

      var code = "onmessage = function (evt) {evt.data.sort(); postMessage(evt.data)}";

      function asyncSort(data, cb) {
        var worker = new Worker(URL.createObjectURL(new Blob([code])));
        worker.onmessage = function (evt) { cb(evt.data); };
        worker.postMessage(data);
      }

Example,

      asyncSort([3, 2, 1], function (res) { console.log(res); });

Prints,

      "[1, 2, 3]"

<comment><USER3> It is not efficient to use a webworker when transferring the data into it and out of it takes O(N) time.

<comment><USER4> Not with transferable objects.

<comment><USER3> From [1]:

> when transferring an ArrayBuffer from your main app to Worker, the original > ArrayBuffer is cleared and no longer usable

This is really too restrictive in many situations.

[1] [https://developers.google.com/web/updates/2011/12/Transferab...](https://developers.google.com/web/updates/2011/12/Transferable- Objects-Lightning-Fast)

<comment><USER5> That may be what the API requires, but is it actually implemented as a physical move/copy of memory? It sounds like they can just make the array _appear_ to be cleared, while keeping it in place in memory.

<comment><USER6> The way I understand it is that they usually just move the pointer to the ArrayBuffer's underlying data store. No block copy occurs.

</comment></comment></comment></comment></comment></comment><comment><USER7> I've actually got a bunch of sort algorithms written as async javascript:

[http://stestagg.github.io/sort/](http://stestagg.github.io/sort/)

</comment><comment><USER8> The 'long tail' really oughtn't be that long if they switched to the native sort when a partition becomes small enough.

<comment><USER9> That's going to be tricky to do with quicksort... you could definitely do it with mergesort, though, but you'd have to abandon the in-place guarantee.

The basic problem is that Array.prototype.sort() does not accept indexes for a slice of the array to sort between.

<comment><USER8> It's simple enough if you split the list at the partition point, but hard if you do it in place.

</comment></comment></comment><comment><USER10> Is computation becoming a special case of being blocked (on I/O)?

I remember seeing this in an event-driven server framework (computation as the special case), this usage of "non-blocking" suggests it might be a trend.

<comment><USER11> In the browser, Javascript (outside of webworkers) is single-threaded, and while running it blocks the browser run-loop (for the given webpage.) This means the page can't accept or respond to any incoming events. It's "blocked" from interaction.

<comment><USER10> Yes, I am aware of that.

It used to be "blocked" meant "process is waiting for an external event, usually I/O". Doing computation was typically referred to as "busy". "Non- blocking" meant "without putting the process to sleep".

There seems to be a shift in the meaning of this particular piece of terminology that I find interesting, because it seems to reflect the reality that "computers" actually do very little "computing". Instead computers mainly communicate, and even the CPUs themselves probably spend most of their time waiting on main memory (60ns) rather than doing actual arithmetic (sub ns in most cases).

<comment><USER12> Just to get a little more specific with this: the shift is in the accepted "main engine of computation" (to make up a mediocre term). We used to have something of an engineer's viewpoint, that the physical location of the electrical operation of the mathematics (i.e., the CPU) was this main engine. It's been a long road, but the new viewpoint is a bit more philosophical: the main engine is the human-computer nexus.

Of course, "human" in the above isn't strictly correct, since we know that computers talk to each other all the time, too. Indeed, when that happens the main engine of computation isn't really one or the other of the computers, but the link between them (i.e., the protocol).

So now "blocking" means requiring the main engine of computation to "sleep" and wait for "external input". For a human UI this means the classic sense of waiting on the wetware end, but it can just as easily mean waiting on the hardware end.

We strive to build responsive systems, so we wish for them to be "non- blocking" in every case. This means, if the human wants to communicate to the computer, it shouldn't be prevented to because the computer is currently working on a solitary operation. Ultimately it's the same principle we've already accepted from the reverse direction.

</comment></comment></comment></comment><comment><USER13> You need to add a test at the start of your quicksort function - when the number of elements for this invocation is < 500, invoke native sort on the current subset.

</comment><comment><USER14> The main takeaway for me was lesson #4:

"setTimeout and browser timing are deceptive and shouldn't be wholly trusted"... and as a result, use the setImmediate API.

<comment><USER14> Eek... "[setImmediate] is not expected to become standard, and is only implemented by recent builds of Internet Explorer and Node.js 0.10+. It meets resistance both from Gecko (Firefox) and Webkit (Google/Apple)."

[https://developer.mozilla.org/en- US/docs/Web/API/Window/setI...](https://developer.mozilla.org/en- US/docs/Web/API/Window/setImmediate)

<comment><USER15> Wah! I just skimmed through the Gecko bug that is linked from the above link. I recommend reading reading it through if you are interested in using these techniques on multiple browsers.

It's a bit of a mess. I think there is some misunderstanding here of what the requirements are. I should be able to queue callbacks and have them execute using 100% of the CPU, but still yield to browser and IO events so that the broswer (or IO processing) is responsive.

A lot of the talk is about minimum waits. For example setTimeout(0) apparently has a minimum timeout according to the spec. It's not that I want the minumum wait to be any particular value. It's that I want it to be as small as it can be while still yielding to browser and IO events. While I have callbacks queued and executing, I want the CPU to be pegged at 100%. While it is pegged at 100%, the browser should still be responsive if my callbacks yield often.

So reading the thread it seems that on Gecko setTimeout(0) does not max the CPU (because it is waiting -- I'm going to give this a try next time I get a chance). Also using .then() on a native Promise does not seem to yield to the browser (apparently this is what the spec asks for).

<comment><USER16> One of the comments in the Gecko bug links to a post by Chromium developer James Robinson, which explains a lot of the technical details quite clearly: [https://groups.google.com/a/chromium.org/d/msg/blink- dev/Hn3...](https://groups.google.com/a/chromium.org/d/msg/blink- dev/Hn3GxRLXmR0/XP9xcY_gBPQJ)

<comment><USER15> Thanks for this. The rest of the thread is also very illuminating. I finally understand what they are opposed to. It makes sense.

</comment></comment></comment></comment></comment><comment><USER9> > There's just one problem – now we've made the function asynchronous, how do > we know when it has finished?

The most obvious thing is just to call out to a (semi-) global:

        function quicksort(arr, cb) {
            var thread_balance = 1;
            function thread(start, end) {
                if (not trivially solved) {
                    partition_stuff;
                    thread_balance += 1;
                    setImmediate(...);
                    setImmediate(...);
                } else {
                    thread_balance -= 1; // this thread is done.
                    if (thread_balance === 0) {
                        cb(arr);
                    }
                }
            }
            thread(0, arr.length);
        }

This is why concurrent datatypes are often interested in simple registers that you can only increment/decrement, they are still super-helpful for coordinating when a workload is complete.

Taking this a little further, we can wrap setInterval in a Promises library which gives you back a promise for the sorted halves of the array; the thread(start, end) promise resolves with the [start..end-1] indices being sorted, and in the nontrivial case returns Promise.all([thread(start, pivot - 1), thread(pivot, end)]) (the promise-library's merge of the two promises to complete the work). Same idea really.

<comment><USER17> I was also curious about the lack of promises

</comment></comment><comment><USER18> Wouldn't it be faster to run built-in sort on each 1/8 of array, than each 1/4, 1/2 and the whole array in the end?

Does Array.sort run much faster when the array already has some order?

EDIT: It doesn't. Sorting even totally sorted array takes as much as sorting shuffled array.

</comment><comment><USER3> Instead, one could use an altjs compiler to generate nonblocking code. For example, ghcjs does this.</comment>


The rise of robots and the future of jobs - <AUTHOR> http://timharford.com/2013/12/the-robots-are-coming-and-will-terminate-your-jobs/ <comment><USER2> Two quotes come to mind:

"Never send a human to do a machine's job." \-- Agent Smith

"We must do away with the absolutely specious notion that everybody has to earn a living. It is a fact today that one in ten thousand of us can make a technological breakthrough capable of supporting all the rest. The youth of today are absolutely right in recognizing this nonsense of earning a living. We keep inventing jobs because of this false idea that everybody has to be employed at some kind of drudgery because, according to Malthusian-Darwinian theory, he must justify his right to exist. So we have inspectors of inspectors and people making instruments for inspectors to inspect inspectors. The true business of people should be to go back to school and think about whatever it was they were thinking about before somebody came along and told them they had to earn a living." \-- Buckminster Fuller

</comment><comment><USER3> It's been my worry for a while that we will achieve the marxist workers utopia technically, where the vast majority of work is done by robot, but culturally we will be stuck with a small group of people enjoying the rewards of capital and technology and an enormous group of miserable poor fighting each other to get the rare chance to work.

Even if you think that such an outcome is 'deserved' for the capitalist and technologist in the short term, in the long term, as the divide grows sharper, I believe most people will come to see that there's something appalling about giving all of the wealth of the world to the descendants of the few and nothing to the rest. Already one family in the USA control more wealth than approximately half the population. And this will get starker.

Technology enhances power, and we are currently stuck with a system where much more worrying than the 'rich getting richer', the 'powerful get more powerful'. And the technological concentration of power in the hands of capital goes alongside the concentration of military and political power too. In the past, when capital got too far ahead of labour, there was always the spectacle of revolution to act as a last ditch moderator and equaliser, but the future will give those in power unprecedented access to surveillance, intelligence and military ability to allow the divide to grow bigger than ever before.

We need to find a way to share the amazing gains that technology brings with labour as well as with capital, and do so in a way that doesn't disincentivise the creation of new technology, and we need to start coming up with this really soon to have any chance of heading off a disaster. I think this is one of the most serious issues facing us as people who care about technology and the world.

<comment><USER4> That's why I think Guaranteed Income schemes are inevitable politically, in the developed countries. Sooner or later, one is going to do it (Switzerland?), and within a couple of decades, all the rest will follow.

Hopefully, this will lead to a realignment of society's sense of "value" away from currency and things exchangeable for currency. Money-driven thinking is the curse of Marxists as much as capitalists.

<comment><USER5> The problem is that capitalism, as any other paperclip maximizer, will not stop working just because of one country decision. Minimal income will increase cost of labour because nobody would want to do shitty job. This will make local products more costly and less competitive, and most of the labour will be outsourced. Most of the export will be natural resources.

Switzerland owns huge chunk of world's banking system and due to direct democracy has minimal corruption, so it could afford minimal income by exploitation of other countries. How to make it work for Ethiopia without Earth's unite government and worldwide wealth redistribution system?

<comment><USER4> A few problems with this. First, most of the modern crap jobs are service- oriented jobs that are done locally because they _can 't_ be outsourced. You're talking about "products", which often can be outsourced, and thus have already been outsourced. Not every job is manufacturing. You can't outsource your janitor or dishwasher.

Second, Ethiopia doesn't have a functioning modern economy. So no, they can't do Guaranteed Income. If they want it, they need to modernize to the point where they can provide a stable economy first. Exploited? No one bothers to exploit them. Given the political and economic instability, it's not worth exploiting. Much better to exploit countries like Indonesia that can provide basic stability.

But you're also stuck on the whole exploitation thing. That's a very 20th century attitude. Exploitation for natural resources is no longer the driver of economics. The primary resource now is labor, particularly skilled labor, and that becomes increasingly expensive as it becomes successful - in other words, being "exploited" is the best and fastest way for countries to become wealthier and more independent.

</comment></comment></comment></comment><comment><USER4> Robots have been taking over jobs for a long time. The problem is that people have too narrow a definition of "robot". Is a Bobcat a robot? A job that 30 years ago might have been done by a row of men with shovels can now be done faster and far more cheaply by one guy with a Bobcat. How about a forklift? Hauling 100 pound bags of stuff around used to be a major source of human employment. Now, we put those bags on a pallet and carry them with a forklift.

Is a food processor a robot? A century ago, fine French cooking was defined by its labor-intensive sauces, manually grinding and sieving vegetables down to liquids. Now, it can be done in seconds by a cheap little machine. Meanwhile, two people and a Hobart can wash all the dishes generated by a large restaurant. Is that Hobart a robot?

Automation doesn't just replace labor. It allows new forms of labor. Most of us here work on computers. What would we have been doing 100 years ago, before there were computers? Would we have been clerks? Adding numbers manually? Artists drawing things by hand for print?

</comment><comment><USER6> So I was having a debate with a colleague a few weeks ago: the suggestion was that in 20 years time the a large percentage of surgeries done in hospitals will be done by robots .

Importantly, we didn't specify which surgeries, but through the conversation the implication was not that robots would be removing millions of weird moles and skin marks - we're talking serious, long surgeries.

I'd be really interested to hear the HN community's view on this. I have my own (strong) opinions based on my knowledge of AI and ML as a field, but perhaps other people have their own strong opinions (and perhaps people can change my mind!)

<comment><USER7> If you think that liability issues pose a significant barrier to entry for self-driving cars getting to market, just wait until you consider robotically automated surgeries.

<comment><USER8> Just wait until the probability of error with a robot surgeon is _lower_ than that of a human surgeon.

<comment><USER9> Even if it's lower, a single mistake from a robot surgeon will not be forgiven. That's the same problem with self-driving cars. I'm pretty sure that they're already safer than a human driver, but a single mortal accident for a technical problem will be all over the news and block any progress in legislation.

<comment><USER10> Driving is different. Thought `robot is better driver than me` is much harder to accept than `robot is a better surgeon than someone i don't know`.

</comment></comment></comment></comment></comment><comment><USER11> This is a key reason why I feel it's important to be working in technology, especially as a developer. It will take longer before your job is automated away.

My wife works in a position that I feel could be automated, and it's scary when you give it much thought.

When the time comes that there are people who are able to work because their skills keep them valuable and people who can't work because their skills are no longer needed, I know which side I want to be on, regardless of any sort of moral implications.

</comment><comment><USER12> Things that are formulaic, repetitive and doesn't necessarily need "human" input will inherently be reached barring any catastrophic events that set all of humanity back. Terminator is robots with agency bias added, so that scenario happening is a bit unlikely. Elysium on other hand might be a slightly better portrayal of things to come.

There are some other serious implications of the rise of such technology too, political ones. The "elite" & "powerful" have depended on the masses for labor, economic output etc. When a good chunk of the masses become somewhat "useless", what happens to them? Thanks to drones and "big dogs", it can be somewhat ensured that a massive population of people will have no real recourse to socio-economic or other inequities and injustices.

<comment><USER13> > Thanks to drones and "big dogs"

What are "big dogs" in this context? (Bit of a challenge for the Goog!)

<comment><USER14> It says in the article that Big Dog is a robot made by a company Google bought. Here's a video: [http://www.youtube.com/watch?v=cNZPRsrwumQ](http://www.youtube.com/watch?v=cNZPRsrwumQ)

</comment></comment></comment><comment><USER15> Personal service will probably continue. In fact its a large part of the American job scene. Somebody cuts your hair, your lawn. Somebody does your taxes. Some of these can be done by robots, but its hard to replace the human interaction.

Will that mean personal services will become as rare as employing a butler is now? Maybe. Or maybe some of these will never be efficiently replaced by bots. And new ones may come up.

In some countries, the 'haves' employ dozens of 'have-nots' in an effort to allow everybody a position in society. With robots, it may be enough to nanny an industrialist's children to school each morning. Then return to your bot- run apartment to enjoy automatic perfect coffee and read your blogs.

<comment><USER3> There will not be enough industrialists for there to be many of these jobs. The wages will be driven down, the expected duties will increase, they'll be fought over by the large numbers of unemployed. They'll probably end up being given away as prizes on reality TV shows.

</comment></comment><comment><USER16> The article's central point at least partially hinges on the continuation of Moore's Law. However, if the exponential rise in computing power at stead cost does not continue, the coming 'rise of robots' might be substantially slower.

There is some evidence that Moore's Law might come to an end: [http://www.economist.com/news/21589080-golden-rule- microchip...](http://www.economist.com/news/21589080-golden-rule-microchips- appears-be-coming-end-no-moore)

Our knowledge of AI suggests that performing basic human tasks like perception and navigation in the physical world is extremely computationally expensive. Even though improvements in algorithms would speed things up somewhat. The required computing resources would still be fairly expensive for complicated tasks many workers routinely perform.

On the bright side, this might give us time to adjust our institutions to the new reality.

Thoughts?

</comment><comment><USER17> "We tend to miss this because the bloated copies of Microsoft Word we use do not seem faster than 20 years ago." \- person obviously not familiar with Office 365.

"Even the Chinese must fear the robots." \- especially them IMHO (world's manufacturing outsourcing center).

<comment><USER18> > person obviously not familiar with Office 365

More like, a person in an office. Adopting new technology has less to do with new technology becoming available, and more to do with retraining, support and backups. I imagine the majority of the workforce is not familiar with Office 365.

</comment></comment><comment><USER19> Moore's law has not much to do with computational power anymore, it's always been about transistor numbers in cpus. While this has traditionally mapped 1:1 with computing power, it doesn't work like this anymore. It's not an exponential growth in computing because our techniques of parallelism and algorithms haven't been keeping up with all this power.

Very interesting article nonetheless, just felt like clarifying this tiny point.

</comment><comment><USER8> And this is why I want to find work in automation, robotics, or AI or something.

Labor against capitalist. Sharpen the contradictions! Radicalize the moderates[1]! Bring it all on!

[1] [http://www.youtube.com/watch?v=Z6GLoKkkCtY](http://www.youtube.com/watch?v=Z6GLoKkkCtY)

<comment><USER20> Steady comrade.

<comment><USER8> Let me have a _little_ fun with it. Glory to Arstotzka!

</comment></comment></comment><comment><USER21> This other article on the front page of HN today seems to contradict this [1].

[1] [http://www.economist.com/news/21589080-golden-rule- microchip...](http://www.economist.com/news/21589080-golden-rule-microchips- appears-be-coming-end-no-moore)

</comment><comment><USER22> Automation and the mass annihilation of jobs will be the biggest story of the next five years.

<comment><USER23> I remember reading a story in Analog science fiction about just this scenario: inexpensive, multi purpose robots (and the riots they caused when people realized they could be replaced).

The solution? Have each robot owned by one, and only one, human being, who could lease out the robot's "labor" as they wished.

I doubt that solution is possible, but I do think the issues the story raised are going to be, as you put it, "the biggest story" of the near future.

(I wish I could remember the name of that story!)

<comment><USER24> This one is similar:

[http://marshallbrain.com/manna1.htm](http://marshallbrain.com/manna1.htm)

<comment><USER23> I love that story--the contrast between the US and Australia illustrates the fact that it really is a political choice how to spend fantastic wealth that automation gives us. (It's not _only_ a political choice, there are moral components as well.)</comment></comment></comment></comment>


Learn React for free - <AUTHOR> https://scrimba.com/g/glearnreact <comment><USER2> Why would you even pay to learn React? The official doc is free and takes only few hours of reading.

<comment><USER3> I learned most of it myself but bought a Udemy course for Black Friday. I find the docs to be quite confusing to be honest. I know it's not React but Redux's docs aren't great either. Concepts quite hard to understand at first.

<comment><USER4> Hi, I'm a Redux maintainer.

FWIW, a lot of people tell us Redux's docs are "great", but we've also had people tell us they aren't helpful. Kinda hard to figure out how to make improvements based on that kind of conflicting feedback :)

We are actually looking at revamping the Redux docs in the near future [0]. If you've got any specific concerns or suggestions on how we can improve things, please let me know directly, or comment on that issue.

Also, besides the docs, you may be interested in my suggested resources for learning Redux [1], including my own Redux workshop slides [2].

[0] [https://github.com/reduxjs/redux/issues/2590](https://github.com/reduxjs/redux/issues/2590)

[1] [http://blog.isquaredsoftware.com/2017/12/blogged-answers- lea...](http://blog.isquaredsoftware.com/2017/12/blogged-answers-learn-redux/)

[2] [https://blog.isquaredsoftware.com/2018/06/redux- fundamentals...](https://blog.isquaredsoftware.com/2018/06/redux-fundamentals- workshop-slides/)

<comment><USER5> Maybe I can help on this one. I'm midway through learning Redux - enough to have stuff working, but not enough to write complex UI code with it.

The problem for me is that Redux uses a set of higher order constructs, which requires a set of functional abstractions that are pretty unique to Redux and Redux-likes. There isn't remotely enough documentation to explain _why_ the boilerplate is put where it is or named the way it is, so I have working code, but no real understanding of why the boilerplate is this way vs. any other way.

So what happens in the docs is that I follow the tutorial along, and it's great about setting up the problems to show why Redux is useful, but then it goes "ok so to solve the problem you use this magical incantation in Redux." Yes, I can adapt the magical incantation, but that doesn't really help me grok who owns which callback that makes which modifications or transformations to be consumed by which objects.

<comment><USER4> Can you point to some specific "boilerplate" examples you're having trouble with, and possibly also docs pages showing those items?

</comment></comment></comment></comment></comment><comment><USER4> This actually looks like a pretty good resource. The combination of a voiceover and an interactive editor looks pretty neat. Noting this for future reference.

If anyone's interested in further resources, I'd suggest checking out my suggested resources for learning React [0], my React/Redux links list [1], and the Reactiflux chat channels on Discord [2].

[0] [http://blog.isquaredsoftware.com/2017/12/blogged-answers- lea...](http://blog.isquaredsoftware.com/2017/12/blogged-answers-learn-react/)

[1] [https://github.com/markerikson/react-redux- links](https://github.com/markerikson/react-redux-links)

[2] [https://reactiflux.com](https://reactiflux.com)

<comment><USER6> It's pretty nice. You might like Imba too!

[http://imba.io/](http://imba.io/)

</comment></comment><comment><USER7> I use React daily so wasn't expecting to learn much, but the vids on forms were helpful! Handling form submission can actually get pretty annoying in React if you want to do anything remotely customized.

Also love the idea of including "Project Ideas for Practicing" as its own module. Two thumbs way up.

<comment><USER4> I can highly recommend Gosha Arinich's articles on working with forms in React:

[https://goshakkk.name/on-forms-react/](https://goshakkk.name/on-forms-react/)

</comment></comment><comment><USER8> I started listening to this yesterday and really like it! Great, short videos!

</comment><comment><USER9> Am I the only one who thinks that courses that don't teach TDD from the start are useless? How can you write an app and not programmatically prove it is working as expected?

<comment><USER10> I imagine it would be very difficult to teach a topic no one is familiar with by teaching how to test it _first_. A TDD approach to teaching a brand new topic would be very hard to follow and require the viewer to go back to re- watch the testing portion. (Imagine teaching a total beginner how to test a function before teaching them what a function even is...)

However, I think there's a lot of validity to the idea that every tutorial should include lessons on how to test it that new topic, and even give examples of how to implement a TDD approach. But those lessons would (IMO) have to come after the initial parts of the tutorial that taught the concept first.

</comment></comment><comment><USER11> Have you listened to the "Why React" video? He says there, repeatedly, that, quote, "For now, it's enough to know that the virtual DOM helps make React work a lot faster than vanilla JavaScript". How can anyone make such a statement and expect to remain a credible source of information? I mean, even if you are targeting complete novices, how?!

<comment><USER12> Because it's kind of right, in the way that it's not technically accurate, but a bit of an approximation that's reasonable for a beginner-level introduction.

<comment><USER11> But how, how? I wouldn't be able to bring myself to say something that I knew to be strictly inaccurate. Even if you are talking to beginners, don't you owe it to them to say only things that you believe to be true? There are lots of ways to put it differently so that it wouldn't be so outrageously inaccurate and so that, if you are a beginner, more senior developers don't laugh at you if you repeat those things.

<comment><USER12> It's not _that_ inaccurate. It's in the right ballpark, just glossing over all of the details of what that means in practice. Would you prefer "The virtual DOM helps make React work a lot faster than doing direct manipulation of the DOM using vanilla Javascript"? Doesn't really seem like it makes that much difference – and the author links to an external video that explains it all in more detail.

Anyway, any senior developer who laughs at a less experienced one for repeating that kind of thing is a bad developer. I'd like to think they'd take the time to correct the inaccuracy :)

<comment><USER11> > Would you prefer "The virtual DOM helps make React work a lot faster than > doing direct manipulation of the DOM using vanilla Javascript"?

I am not sure this is even correct. Firstly, the famous js framework benchmarks ([https://github.com/krausest/js-framework- benchmark](https://github.com/krausest/js-framework-benchmark)) based on adding/removing list items used to have vanilla JS as an unbeatable winner, despite its direct manipulation of the DOM, and React was definitely significantly behind. Secondly, as the README for morphdom says, the real DOM is very fast ([https://github.com/patrick-steele- idem/morphdom](https://github.com/patrick-steele-idem/morphdom)). If I remember correctly, virtual DOM was supposed to solve the particular performance problem where you would otherwise just throw huge chunks of DOM away rerendering them anew every time your app state changed. But this is a very special (although brilliant) approach to keeping your UI in sync with your app state; you wouldn't necessarily do so if you wrote your app with vanilla JS.

<comment><USER11> Oh, I am sorry, I re-read your sentence, and I think I misunderstood it. Yes, if React were using real DOM rather than virtual DOM it would have been slower, but the author was not trying to make _that_ point.

</comment></comment></comment></comment></comment></comment><comment><USER13> The title could really be a lot better :p It's not like all the other resources cost.

<comment><USER10> The title doesn't suggest that _all_ other programs cost money. But many people do turn to paid lessons on Udemy (or similar paid programs) first.

</comment></comment><comment><USER14> I can't adjust the volume on the player, every time I hover over the soundbar to adjust it it disappears.

</comment><comment><USER15> Excellent. Thanks for sharing.

</comment><comment><USER16> How does this compare to, say, Wes Bos's course?

<comment><AUTHOR> It's created with the Scrimba technology, so you can edit the code in the videos whenever you want.

<comment><USER10> I find this ^^ to be one of the main selling points. All online courses are in danger of falling into the "Tutorial Hell" category, where they spend all their time teaching you without the student actually being more capable afterword. The Scrimba platform significantly lowers the barrier for students to get their hands on the code and actually obtain new skills. I have yet to find another platform that lowers that barrier as efficiently/well as Scrimba.

</comment></comment></comment><comment><USER17> Great platform, not the best React course.

<comment><USER10> I'd love to know which IS the best React course out there so I can learn more for my next time around the block :) (Sincerely)

</comment></comment><comment><USER18> Awesome, thank you for posting this!

</comment><comment><USER19> Great work Bob!

</comment><comment><USER20> this is great

</comment><comment><USER21> React is boring. It's just a javascript function which returns a Virtual DOM on every local state or external props change.

</comment><comment><USER22> What on earth is the purpose of non-informative comments from non-informed accounts like these:

\- I started listening to this yesterday and really like it! Great, short videos!

\- Excellent. Thanks for sharing.

\- Great work Bob!

\- this is great

The same time you can't find other background info about the company except that they collect VC money and the video's you create are MIT licensed.

<comment><AUTHOR> What would you like to know about our company?

The accounting for Norwegian companies are public, ours can be found here:

[https://www.proff.no/selskap/scrimba- as/oslo/internettdesign...](https://www.proff.no/selskap/scrimba- as/oslo/internettdesign-og-programmering/IF6MBF90C2C/)

We're two co-founders, Sindre and I. Our Twitter profiles are here:

[https://twitter.com/perborgen](https://twitter.com/perborgen) [https://twitter.com/sindreaars](https://twitter.com/sindreaars)

If you actually spend some time researching, you'll find plenty of information about us and the company.

As for "collecting VC money" we've raised around $250K from angel investors and one Norwegian VC and we've also gotten a loan (which we're partly personally reliable for) from Innovation Norway.

Feel free to ask if you'd like more info.

<comment><USER22> Thank you for the information. I am however not an investor but a developer. When 'a free tutorial' is advertised i am always afraid i'll be forced into later payments or becoming the product myself, especially when professional investors are willing to support the company financially.

Giving information on your website about the user do's and don'ts are always appreciated without having to file a request in triplet to the board of directors. Still I highly appreciate the links to the company information.</comment></comment></comment>


Tubemote: Turn a browser into a YouTube remote - <AUTHOR> http://news.cnet.com/8301-27076_3-20014286-248.html?tag=cnetRiver

<comment><USER2> I've been thinking about how to make a similar service for watching TV at home. It'd be great if they offered more than just YouTube, but YouTube is the obvious place to start.

My plan was to make a web interface to some Selenium scripts and then run the web app on my home network and connect to it from my phone. After seeing this, my way of doing it may have been way too complicated. I could just have an app that generates a redirect to the page I want to visit, whether it is YouTube, or Last.fm, etc.

<comment><AUTHOR> Indeed, YouTube is just a start... we're working on other stuff ;)

</comment></comment><comment><USER3> This is pretty neat. I've been playing with "Leanback" as a means to show segmented videos one after another- I am addicted to SC2 screen cast _sigh_. Another method I have found, but do not like very much, is javascript. The YouTube player API gives back status codes when a video is Playing, Paused, Ended. After the Ended status is given I use js to place the new video in a div.

<comment><AUTHOR> Thanks, we think it's pretty neat too :) Hope we're not enabling your addiction though! Ok, maybe just a little bit ;)</comment></comment>


Canada cell provider tells 88-year-old to wait 4½ years to get refund - <AUTHOR> https://www.cbc.ca/news/canada/nova-scotia/bell-telcos-cell-phones-business-customers-1.5103393 <comment><USER2> Well that seems perfectly reasonable to me. Read the terms of service or ask important questions when you before you start paying them once a month like "what happens if I don't use all my minutes?" (They rollover) "Do I have to keep paying if I have minutes already?" (No) "are the minutes refundable?" (No). You can't just walk into a store and say "talky talky please" and walk out with a phone. Allowing her to use the minutes toward internet and TV is generous of them.</comment>


Facebook will limit reach of groups that share misinformation - <AUTHOR> https://www.theverge.com/2019/4/10/18304739/facebook-groups-reduce-misinformation-harmful-content-changes-messenger <comment> xkcd-sucks A bunch of civilians were killed in Tiananmen Square in 1989? FAKE NEWS!

</comment><comment><USER2> Good start. But if Facebook really wants to stop making the world a worse place, they should shut down.

</comment><comment><USER3> Just groups? Not pages?

Most of the false information I see shared on Facebook is from pages, not groups.

<comment><USER4> Pages already had this treatment. Many pages were just shut down entirely.

</comment></comment><comment><USER5> And Facebook will decide what misinformation is?

<comment><USER3> > The Associated Press is now going to start fact-checking some videos in the > US, and Facebook will start including "Trust Indicators" when users click to > see context around a publication. Those indicators come from The Trust > Project, a group built by news organizations that makes those > determinations.

<comment><USER6> I agree, good start.

But I think it will take decades, not years -- before western journalism, and major online news distribution sources will rid themselves of stigma of being 'propaganda arm of US coup orchestrators'.

So trusting the members of trust project will have to be earned, not assumed...

Recent revelations about Google

'The manual adjustment of search results by a Google-owned platform contradicts a key claim made under oath by Google CEO Sundar Pichai in his congressional testimony earlier this month: that his company does not "manually intervene on any search result.'

is not helping the trust rebuilding either.

[1] [https://www.breitbart.com/tech/2019/01/16/google-youtube- sea...](https://www.breitbart.com/tech/2019/01/16/google-youtube-search- blacklist-smoking-gun/)</comment></comment></comment>


Training AI to Win a Dogfight - <AUTHOR> https://www.darpa.mil/news-events/2019-05-08 <comment> chris-hexx Fascinating that they say so bluntly that the end goal isn't a machine that performs well at a task, but warm fuzzies for the people that have to specify the tasks for that machine: "Turning aerial dogfighting over to AI is less about dogfighting, which should be rare in the future, and more about giving pilots the confidence that AI and automation can handle a high-end fight."

Reading further, it's also interesting that they're looking not into how legible the end results are, but how legible the system's behavior during training is.</comment>


You probably don't need input type="number" - <AUTHOR> http://bradfrost.com/blog/post/you-probably-dont-need-input-typenumber/ <comment><USER2> > While input type="number triggers numeric keyboards on touchscreens leading > to better mobile UX, that can also be accomplished by configuring the > pattern attribute in a certain way (Zach Leatherman has a great deep dive > post into all of this).

The pattern attribute workaround is fine but limited to iOS as Leatherman himself notes, and its implementation treats other mobile users as second class citizens, reduced to the non-existent numeric row (at least on Android). The root cause of this mess is IMO the spec that inexplicably defines two fields of near zero ("tel", except for autofill I suppose) or ambiguously weirded utility, i.e. the described, broken "number"/roller field that encourages browser devs to surprisingly treat vertical mouse movements as inputs to typeable fields.

</comment><comment><USER3> I feel like this is a poor example. In this case the input should never have been number in the first place.</comment>


Startup Jacket, engineered for the startup people - <AUTHOR> http://startupjacket.com/

<comment><USER2> Or you could just, you know, wear a suit jacket :)

</comment><comment><USER3> I have no idea what this is. A vest?

<comment><AUTHOR> Its like a vest I guess</comment></comment>


Commodore64 + Raspberry Pi + 6502 assembly = Slack client! - <AUTHOR> http://1amstudios.com/2016/11/27/c64-slack-client/ <comment><USER2> Awesome work! I noticed that you'd also done some work getting animated gifs displaying on the c64, seems like that would be a cool extra feature to have inline images display in the channel output, though I guess you'd have to do colorspace reduction & image resizing on the PI to avoid memory limitations on the c64 side.

</comment><comment><USER3> Probably one of the more interesting things to do with slack.</comment>


What I Learned About Your SXSW Experience - <AUTHOR> https://medium.com/@kunalslab/what-i-learned-about-your-sxsw-experience-5e213f0d818c <comment><AUTHOR> ...and how I accidentally started a research sprint on Twitter.

Building products in secret is hard/no fun. That's why I'm sharing my experience build as I build @SlidesUp. The first post is about using research sprints to inform your product design activities. What topics do you want to hear about next?

Please comment here, on Medium, or @KunalsLab on Twitter.</comment>


Show HN: TLDRs of 300 articles for developers - <AUTHOR> http://insnippets.com/ <comment><AUTHOR> We started a daily newsletter aimed at developers where we email you with 1-3 TLDR versions of interesting articles. Finally got around to putting it all on a single website. Happy reading!</comment>


WRLD and Udacity Create 3D Simulator for Flying and Autonomous Cars - <AUTHOR> https://www.wrld3d.com/blog/wrld-to-power-udacity-universe-for-autonomous-transportation/ <comment><USER2> Sadly this is exclusive.

"Udacity Universe offers virtually limitless opportunities to interact, collaborate, and problem solve, and is exclusive to students of our Flying Car and Self-Driving Car Engineer Nanodegree programs."

</comment><comment><USER3> Wouldn't photo-realism here be nice? The Microsoft simulator is a little more photo-realistic[1]. At first glance, WRLD looks a little cartoon-y. Wondering if anyone's tried this?

[1] [https://www.youtube.com/watch?v=GB- sBpXvM3s](https://www.youtube.com/watch?v=GB-sBpXvM3s)

</comment><comment><USER4> Are there any driving simlators with accurate (as much as possible) world maps? It would be so nice to practice driving around Boston without fear of getting lost in random one way streets or picking the wrong turn on five way intersections.

<comment><AUTHOR> WRLD is a 3D model of the world based on a real world coordinate system, including building heights. The platform has a good chunk of the world mapped but continues to add new areas based on customers. Boston is included!

</comment></comment><comment><USER5> I can hear a single plane or helicopter miles away. It's going to take massive improvement in noise dampening to have roads of flying cars. Not to mention all the other challenges.

<comment><USER6> As far as cars are concerned, above ~30km/h, the noise produced by air resistance is louder than the tire noise. Cars, however, are on the ground, i.e., surrounded by massive sonic breakers (i.e., buildings). It should be quite difficult to have a large amount of flying vehicles without an enormous noise impact, unless they're flying very high.

<comment><USER7> This seems like an odd claim. I've watched quite a few gliders landing at an airport and you never really hear them. Is this really true?

<comment><USER8> I've done glider pilot training and gliders are an aberration as they are built to be supremely aerodynamical. Yet, once you go high speed (>100km/h), they are noticeable and at 140km/h they sound like an approaching storm, so you definitely won't miss them nearby.</comment></comment></comment></comment>


Ask HN: Please review my startup: flashissue.com - <AUTHOR>

We launched FlashIssue, a web app for curating newsletters quickly using existing web content about two months ago and got great reviews from users, but we would like to help convert more users to the point of sending the newsletter through us (or the mailchimp integration)
We would also like to hear any comments or suggestions on our Chrome web clipper extension that integrates with the app (link to it in the app)
The app is before a professional design iteration (we are aware it doesn't look pretty), but we would like to improve usability as much as possible when we brief the design agency.
Appreciate your comments <comment><USER2> I like the concept and the editor - it looks very smooth and easy to use, however, your landing page doesn't really convey the greatness of the app!

Some of the issues I had with it: \- the first screenful of the landing page doesn't tell me anything. Only at the very bottom of the page you get to what flashissue is actually all about - the editor. The "Super simple" box that you use to describe the tool or the workflow doesn't really doesn't really help me to get the concept, of course a video would be great, but if you don't have it, maybe you could do a better job at illustrating how "fetching" and "creating" is done. Since I didn't get the first two screenfuls (help picture & super simple), I'm not really going to get the "we work with these guys either). So rearranging the messaging could help a lot.

\- could you consider allowing visitors to use the editor without logging in? And require them to log in only after they're getting ready to publish the newsletter. This could help you to show the ease of use.

\- Some of the tutorial boxes in the editor went off the bottom of my screen (13" mac book pro with chrome)

\- The web clipper doesn't really stand out, I had a hard time finding it. Once I installed it, you threw me on a new page recommending me to restart my browser and sign-up (I was already signed up). I know you're still early, but I would have liked to be able to choose the element I want to clip from the page instead of just clipping the whole page.

I hope this helps!

<comment><AUTHOR> This is really great feedback, thanks, will update once we have something new to show as remedy of all the above. Thanks again, this is very helpful.

</comment></comment><comment><USER3> I like the page. It looks simple but professional. Don't care so much about the design. Of course it shouldn't be ugly and hurt my eye. But on the other site you don't have to win a UX contest with your page.

I like the approach to fetch content from a website or a blog and create a Newsletter out of it. Most time I create a blog post and the same content I send out as a newsletter.

2 points I don't like. First of all, there is the pricing? Is it really for free? How do you make money? And the second point. There is the registration form? I saw that I can login via FB and Google. That's cool. But sometimes I want to sign up with my corporate identity. Login with FB and google should always be optional. But beside that it should be possible to sign up with username, email and password.

I hope my feedback is helpful.

<comment><AUTHOR> Thank you so much for the feedback, Yes we intend to have a pricing soon, we are still trying to improve our experience and conversion rates before we do :)

I am glad you mentioned it (login), we started working on it and will put this as a higher priority. I think this is one of the big barriers indeed for corporate users.

again, thank you so much</comment></comment>


Why we're not overreacting to the coronavirus, in one chart - <AUTHOR> https://www.vox.com/future-perfect/2020/3/20/21179040/coronavirus-us-italy-not-overreacting <comment><USER2> A related and well worth-reading analysis: [https://www.zerohedge.com/health/covid-19-evidence-over- hyst...](https://www.zerohedge.com/health/covid-19-evidence-over-hysteria) which makes the point that none of these numbers are adjusted for country population (or pop density)

Also, why the article is not on medium, where it was originally: [https://www.wsj.com/articles/controlling-the-virus- narrative...](https://www.wsj.com/articles/controlling-the-virus- narrative-11584899715)

</comment><comment><USER3> So they align the graph to start Italy at February 23 and US to start at March 2. They say because that is when both counties reached 100 cases, but that doesn't sound like a good reason. Why not 50 or 200? Then, they don't even adjust for population (US has more than 5 times the amount of people as Italy). And lastly, the big spike that we see in the graph of the US comes from the fact that now they are testing more people, it doesn't necessarily mean that a lot more people or getting the virus.</comment>


Completely unfair comparison of JavaScript syntax highlighters - <AUTHOR> http://softwaremaniacs.org/blog/2011/05/22/highlighters-comparison/

<comment><USER2> The unfortunate thing about JS syntax highlighters, is that people reading your site via an RSS feed don't get the highlighting. On the other hand for some sites that isn't an issue.

</comment><comment><USER3> I hate Javascript syntax highlighting. I have never seen a library that doesn't degrade horribly in cases like naming a variable x' ("x prime") in Haskell (or when merely quoting a symbol in Lisp). They also tend not to support Perl at all, and definitely don't highlight q{Foo} as a string.

My advice is to use Emacs or Vim to do your syntax highlighting. They highlight well enough to please people actually doing work, and when people get annoyed with the rules, they fix them.

[http://search.cpan.org/~geoffr/Text- VimColor-0.11/lib/Text/V...](http://search.cpan.org/~geoffr/Text- VimColor-0.11/lib/Text/VimColor.pm)

[http://search.cpan.org/~jrockway/Text- EmacsColor-0.03/lib/Te...](http://search.cpan.org/~jrockway/Text- EmacsColor-0.03/lib/Text/EmacsColor.pm)

<comment><USER4> Highlight.js does support Perl, does mark up q{...} as strings and has no problem with quoting in Lisp. I'm not sure about Haskell thing you mention because Haskell is a new contribution. But I'm sure it's fixable if it doesn't do the right thing.

You're probably talking about a hoard of simplistic regexp parsers. Highlight.js is not one of them, it's a proper context-aware parser.

</comment></comment><comment><USER5> <http://ajaxorg.github.com/ace/build/editor.html> is pretty sweet, real time text editor (many languages) with highlighting support.

See more info at <http://ace.ajax.org/>

</comment><comment> guard-of-terra GNU Source Highlight is an amazing thing.

Last time I tried, it mishandled xml elements containing hyphen. Only the part before the first hyphen was highlighted, the rest was just left as it was.</comment>