If Magic Leap had a cash cow business, they could be relentless about their vision (heh) for VR, whether it takes five years, ten, or even twenty(!) to realize.
Oh Gawd, I remember that. I believe that Apple never had any intention of making that successful, and were planning on backstabbing Motorola no matter how the Rokr turned out.
A little perpendicular to the subject, but this kind of thing always brings my mind back to iPhone. Apple had AT LEAST four kicks at the can with mobile devices.
They had the "Knowledge Navigator" vaporware in 1987, twenty years before iPhone.
They started working on realizing the KN concept in 1987, and shipped Newton in 1993, fourteen years before iPhone. Alas, the state of tech was not up to their ambition.
Then they shipped iPhone in 2007. The greatest hit in product history.
What made it possible to have so many kicks at the can was, of course, having a successful(ish) business selling Macs.
With VC funding, you strip all the legacy/cash cow business out of the equation. In exchange, you get tremendous financial leverage for founders, but you also have a very limited window in which to ship a hit.
Speaking as an author who deliberately chose to use JavaScript as the language of communication...
I both agree and disagree with you. It is nearly impossible to make one post that communicates strongly to all audiences. If you use an example problem simple enough to be understood by everyone, you almost certainly give up some of the nuänces that would be surfaced by a more complex problem to solve.
Likewise, using a language like JavaScript that is popular but doesn't embrace modern FP, you necessarily end up reinventing a lot of wheels like composition and chaining and partial application.
This can be very instructive for the newcomer, but is nothing but incidental complexity for the more experienced functional programmer.
In the end, I think the world benefits from authors not trying to be all things to all people. We all win if there are a variety of posts about a similar subject, using different languages and solving different complexities of problem.
So yes, 100% this post is not going to meet a lot of programmers' needs. But if there is some set of programmers--no matter how small--for whom it is a good fit, then let's agree that it's valuable and well-written for iuts target audience.
Speaking as a frequent commenter and author, I suggest this is teh system working as intended. There are not letters to the editor you put in in envelope and mail away.
When HN "published" your letter to the editor, it's not printed on atoms and distributed all over town, or mailed out to subscribers.
You can post a comment, edit it, and maybe even fix something based on feedback. I suggest that without being completely slipshod, it's better to go ahead and make a comment when you have a coherent thought.
The community will help you sort out any spelling, grammar, or attribution hiccups. I think this is a good thing for everyone, reducing friction and eliminating even self-gate-keeping.
Mixing up two homophones is not a tragedy. Someone not contributing because they fear that they'll be snubbed for getting a word wron? That's a tragedy.
I have done lots and lots and lots of enterprise sales and consulting, and a big part of bringing in outsiders is to provide the illusion of social proof.
"Well, we had the experts in, and they found..."
That sounds really, really terrible when put so cynically, but the flip side of that is to view it as insurance. If you bring the consultants in, hoping that they will recommend Plan A, and Plan A is truly terrible, a reputable consultant will find a way to sell you on Plan B, by couching it as "A few adjustments to Plan A."
So in effect, yes, it is about making changes management wanted all along, but in addition to providing the illusion of social proof, you can also get an extra set of eyes to make sure that you don't completely footgun yourself.
Sometimes. Maybe. If the consultants are good at both analysis and selling management on adjusting their plans...
Or you do the math and realize that with a modern, safe automobile, your chance of dying in an accident with a pickup is so small that upgrading your own vehicle to a pickup is a rounding error.
To be clear, I agree that humans being humans, we do love to get into escalating arms races.
I wondered this myself. I mean, I can test it and see that it appears to give the correct result, but how do I prove that it gives the correct result?
I didn't include it, but you can do reductions, successively replacing the names with their expansions, and you see that it works out was we want.
And in Combinatory Logic, there really is nothing else. If an expression has the correct "type," then it works. There's nothing except rearranging terms, duplicating terms, and erasing terms.
But that being said, I don't know if that's a "proof," and I especially don't claim that a proof about Combinatory Logic would say anything at all about JavaScript.
If you like esoteric, I learned this algorithm for obtaining the exponent of a 2x2 matrix, which amusingly enough is part of an interesting fibonaccialgorithm.
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.
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?
If Magic Leap had a cash cow business, they could be relentless about their vision (heh) for VR, whether it takes five years, ten, or even twenty(!) to realize.