So we start out with an attempt to build an anonymous recursive function. That's cool I suppose. But doing it in a language like javascript (or java)? It turns out that tail recursion == stack overflow. Not daunted, the plucky author decides that we can solve this particular issue by creating a closure over stack variables and put them on the heap instead!
You know, if you want to use Haskell, use Haskell. Trying to shoehorn this stuff into languages designed for loops instead of recursion just means impressionable JS developers are going to see this and rush out to implement it in some project to prove how smart they are. Then everyone suffers. The implementation is slower because it goes to heap. The memory usage explodes because it goes to heap.
Purely for illustration of a Y combinator, this is great. But there should be a big red warning somewhere on the page as a reminder of the downsides of this approach.
We actually don’t start out with an attempt to build anonymous recursion.
That is the goal of the Y Combinator in the Lambda Calculus and Combinatory Logic, but here the initial goal was to decouple an anonymous function from itself so that we could decorate it.
Going out to main memory is orders of magnitude slower than hitting cache. Even a stack overflow would be preferable to debug vs an out of memory error. At least with the stack overflow, the stack trace pinpoints the problem.
Like I said, I have no problem with this article as an illustration of a ycombinator for JS devs. The problem is it does not warn them sufficiently of the very major drawbacks in using it. This is why we have Gate's law; Developers using inefficient constructs because they're neato.
Well, given that the post links to two different discussion forums, I attest that it’s not my responsibility to outline every single consideration of every single technique, nor is it my responsibility to include the entire syllabus of computer science to explain the background.
Instead, I outsource that to people like you. You voice your concerns here, and people can read them and make up their own minds.
Speaking of making up their own minds, please explain in more detail how the trampoline’s memory consumption grows unboundedly, to the point where it could cause an out-of-memory error. That would be most interesting for the community to ponder.
A loop is not just fewer LoC and easier, it is orders of magnitude faster than the ycombinator decoupled trampoline. The first alert is nearly instant. The second one takes almost a minute. My chrome dev tools are hard locked waiting for the ycombinator to finish.
This is not something I would encourage JS devs to use in practice.
Well, refactoring isEven or exponentiation to a loop is faster. But wait, you know what's even faster? Using built-in math primitives.
I wrote an entire article about refactoring tail-recursion to iteration and linked to it in TFA. I've also written a Scheme interpreter that can perform this optimization for certain functions on-the-fly. But arguing that the code is slow is missing the point by a country mile, and then some. The article is not arguing that the code is fast, or that you should always do this. I find it amazing that every time a programming technique is discussed, people want to worry about whether it belongs in production.
Is there no recreational programming any more? Or is it all about shipping the next app to deliver food by electric scooter? My world would be depressingly boring if the only things I thought about were the things I use at PagerDuty every day.
Now as to what I asked you about:
What you said was that this implementation leaks memory in such a way that using the trampoline it trades a stack overflow for an out-of-memory error.
I wish to understand that problem. Specifically, how does the decoupled trampoline leak memory?
That incivility ("You get a trophy, smart person.") is the inevitable end of this sort of pedantic flamewar.
Since you've frequently broken the site guidelines and we've already given you numerous warnings and requests to stop, I've banned this account. If you don't want to be banned, you're welcome to email hn@ycombinator.com and give us reason to believe that you'll follow the rules in the future.
> There are plenty of people who will read it, then rush right out to duplicate it. That will bring bugs and chaos all over the javascript world.
Citation needed.
I seriously doubt that there's a horde of developers who--at this very moment--are pushing Y Combinator JS apps into production all thanks to this thought exercise.
I have the commit bit to the repo backing my blog. You do not. I f you have some serious suggestions, feel free to submit a pull request.
I'll review your PR and decide whether it matches the tone and style of my blog. If it doesn't , regardless of what you see as its merits, it will be rejected.
That state of affairs is not acceptable to most people, and fortunately, there is an alternative route forward: Instead of trying to lecture me about what to write in my own blog, and instead of lecturing me about what I should consider important to mention, and why, YOU CAN WRITE YOUR OWN BLOG POST REFUTING MY POST.
I am not being sarcastic. Great things have transpired in history when two or more people engage in a conversation via essays.
Words are so vague. I don't even know what "hard locked the dev tools" even means!
But if you write your own essay, with your own code illustrating your own ideas. Ah! That clarifies things for me and for everyone else reading.
It has never been easier to publish words. Avail yourself of this opportunity.
---
As for bugs and chaos all over the javascript world...
I have been publishing essays on the Internet for fourteen years. Most have been of a highly impractical nature: I save my practical thoughts for my work, and I scratch my "boy this is interesting" itch in my writing.
In all that time, I haven't broken the Internet. No hordes of people rushed out to implement macros in Ruby when I released Ruby.Rewrite.Ruby.
The JavaScript world was not taken over by decorators when I released Method Combinators. My book has an entire chapter on implementing traits in JavaScript. Where are all the traits?
(tumbleweeds)
I write to provoke thought. I think most people grasp that. You should have a little more faith in people.
Some people find these things interesting, even provocative. They may wonder if such a thing makes sense. But few people rush to implement an idea just because of one essay on Hacker News. Typically, they need to see a preponderance of momentum.
An essay from me. A library from someone else. A major framework baking it in. Only then will people bet their projects on it.
Until then, it's nothing more than one person, me, saying "Here's something interesting," and a bunch of other people saying, "indeed," over their coffee breaks.
Then we all go back to work and the world carries on just fine.
Honestly, with the exception of your statement that my trampolines will cause an out-of-memory error, you are not wrong about performance and the fact that practical applications for greenspunning your own trampolines are rare to the point of statistical non-existance.
I sense that everyone agrees with you, they just don't worry that hordes of Eternal September JavaScript n00bs will start swapping iteration for anonymous recursion powered by recursive combinators.
I find it unsettling that Silicon Valley employees would rather see a foreign nation win the race to build autonomous killing machines. It's not just the open contempt they have for their own countrymen, but it seems borderline suicidal.
Blame the judge for the laws congress passed. Blame the congress for the law the executive misused. Blame the executive for misleading the fisa judges. It's a perfect circle.
Stories like this, the Uber story, and the recent one about Google tracking location even when you opt out, are why I'm looking forward to Purism 5 with PureOS and kill switches.
How does having some kill switch solve the issue of an app that needs geolocation selling the data or otherwise using it in a way other than you intended?
Having an OS and apps I can trust to not send location data solves that problem. The kill switches ensures no roving bugs, modem AT commands, and passive tower triangulation when I'm not using the radio. Pretty simple really.
That argument is so tired. Just because there's no perfect privacy, doesn't mean you can't significantly increase it. At some point you also have to trust that the chair you're sitting on will hold you and the one that isn't visibly weak has the best chance of doing that.
Only using “app you can trust” seriously limits what you can do on your device. This might be a solution for you, but it’s really not a solution to the privacy problem, it’s duct-tape on something that needs to be fixed on a larger scale.
>A solution for a few outliers doesn’t really influence the big picture.
There's nothing stopping anyone from buying a Purism 5. If someone doesn't care about their privacy, they don't deserve it. Freedom isn't free, and all that.
> it’s going to need to know where I am to provide me the forecast
Why would you think that? I don't need to give a weather app my location. It only needs to have one or more locations of interest to me. My weather widget pulls multiple locations for me, and has no access to my location data.
Not sure what kind of strawman you're building here but there's quite a big difference between giving location to a map app that will help you if you're lost, and a weather app. Having to use location data to get weather seems like the pinnacle of laziness to me, if you don't know where you are than you have bigger problems than the weather.
>There's nothing stopping anyone from buying a Purism 5
Apart from the fact that it doesn't actually exist yet.
Not to mention it's already a badly specced phone commanding top dollar being made by a small company that could easily go broke in a year.
I'm all for what they are trying to achieve and really hope they succeed, but history is full of privacy phones that have failed spectacularly.
For half the price I could get a flagship Xiaomi, flash LineageOS on it and have a completely degoogled high quality Android phone likely supported for most of the next decade.
>Apart from the fact that it doesn't actually exist yet.
Well, sure, I'll give you that point, but it's going to happen.
>it's already a badly specced phone commanding top dollar
The selling point isn't the specs. It's the RYF certification and kill switches. Even if they can't get the RYF, it's still a better option than anything else out there.
>being made by a small company that could easily go broke in a year
I really doubt that. They have a laptop business already. They've been doing hardware for a while. This one might ship months late, but I'm confident it will happen.
>For half the price I could get a flagship Xiaomi, flash LineageOS on it and have a completely degoogled high quality Android phone likely supported for most of the next decade.
Yep, and you still have a sealed battery, a backdoored baseband, and binary blobs. The iMX.8 is pretty sweet. It has open source GPU. Can't say that for mali or powervr. I can consider making Librem 5 my convergence device.
>I want to write on these things and your response motivates me to do that.
I would caution you not to. What goes on the internet stays there forever. Google will fight your right to be forgotten. Real names are a great way to attract batty twitter haters who want to ruin your life due to some perceived slight from reading your stories. You can easily go from pity story of the day to "ZOMG I hope you never get a job and die in the streets" in just a few words on this board. Be wary.
Hey Jesse, pick up a solar panel. You can get waterproof two usb port that'll crank out 20-30 watts ~$50. I'd recommend an ARM laptop too. They're cheaper and Intel is generally too power hungry anyway. A Samsung Chromebook Plus used on swappa would be really nice. It has a really bright display so you can still see it outdoors in the sun. For data, T-Mo is unlimited for $30/mo pre-paid.
Put your panel in the sun, sit in the shade at a park, tether your phone for internet, and you're golden. You can strap the panel to your backpack and charge on the move too.
Most of these don't provide anywhere near the advertised wattage. And when they do, it's usually in direct bright sunlight (i.e. depending on where you are and what season it is, it can be that efficient only for a few hours, and sometimes none at all).
If you want a decent portable solar panel, get the non-flexible monocrystalline one.
Logically speaking, this is incorrect. Both could be true given a circumstance, like say, the sun goes red giant in the later case.
Furthermore, "the reason" can usually be whatever you want it to be if you go far enough back in the chain of causations. My hands were wet this morning when I dropped the jelly jar. But that wasn't my fault, it was the water company's fault for supplying the wetness on my hands. Or perhaps it was the Roman's fault for kickstarting the whole thing with aqueducts. But that's really just mankind's fault for existing, so human activity is at fault for my loose grip on the jelly jar today.
Overall, I found this article interesting, and frankly: Go mankind! We averted an ice age and certain death/destruction with farming. If we want to talk about problematic climate change, look at how living on top of a mile of ice works out for our species.
It's also manufactured by Google, which is equally adept in spying and probably more unworthy of trust.
But more importantly, it's just a bad deal. A yubikey neo can do GPG, PIV, OATH, OTP, HMAC challenge response, and a few other things in addition to NFC U2F for the same price. The Titan dongles package just does U2F, and U2F isn't even that great.
You know, if you want to use Haskell, use Haskell. Trying to shoehorn this stuff into languages designed for loops instead of recursion just means impressionable JS developers are going to see this and rush out to implement it in some project to prove how smart they are. Then everyone suffers. The implementation is slower because it goes to heap. The memory usage explodes because it goes to heap.
Purely for illustration of a Y combinator, this is great. But there should be a big red warning somewhere on the page as a reminder of the downsides of this approach.