matthewtoast

Nice work! I'm really happy to see this kind of restrained approach to introducing React. I wish it had been the first tutorial I encountered. I hope it inspires other teachers.

Tutorials should be about teaching others. But many tutorials today seem to be more about showing what the author knows.

Maybe part of the "JavaScript fatigue" is that, as each shiny new toy rolls in, the ensuing commentary immediately elevates it to The One Solution We've All Been Waiting For --- followed just as quickly by No This Is The Most Flawed Solution Ever They Got It All Wrong And Here's Why....

The reality is that many species can coexist in the same habitat. You don't have to pick just one. Cats don't have pincers, but does that have to mean lobsters are superior? Nope.

Are you aware of any existing, serious effort to build such a thing?

I love the idea - and it strongly appeals to me as a developer - but what would make the average user switch to it?

That title I would call sensationalist. Our tooling choices don't have to take this king-of-the-molehill, all or nothing, "did X just kill Y?" extreme stance. (I thought the article made some reasonable points, though.)

With so much conflicting wisdom to sort through - "yuck, monolith!", "omakase!", "YAGNI!", "not enough abstraction!", "too much abstraction!" - we should admit that we often end up leaning on instinct/emotion when making these decisions.

Just remember that you don't have to pick one philosophy and stick with it for all time exclusively. Often down the road you'll see the value in something you thought you had sworn off.

The God Delusion gives a handful of arguments both for and against the existence of God. Your summary comes across as a straw-man, a misrepresentation that's supposed to convince us that the real argument is poor. Where did he make this before/after argument?

Intelligent design is just one hypothesis among many to explain the complexity (the apparent "design") of the universe. But it posits the existence of an even more complex entity. If we really need intelligent design to explain where eyeballs and bird wings came from, why don't we also need an explanation of the omnipotent designer?

Via Wikipedia, science is defined as:

> a systematic enterprise that creates, builds and organizes knowledge in the form of testable explanations and predictions about the universe.

The key word being "testable". The fallibility (or falsifiability) of scientific hypotheses is the great strength of science: We can improve, or prove wrong, our understanding.

Dawkins writing celebrates this, and I think it's unfair to characterize his passionate (OK, sometimes strident) advocacy as "unquestioning" fanaticism.

If it's a "leap of faith" to accept the axiom that we can refine/invalidate knowledge through experimentation, then "a leap of faith" isn't a very profound deed.

Very cool. It's amazing to me that the developer got it under 1KB.

This is the first I've heard of that project, but based on a quick skim, I can point out a few differences between it and Runiq - although the two are certainly similar in that they execute over a very simple plain-array-based AST. (Clearly miniMAL and Runiq were created with different ultimate aims in mind, so any fair comparison ends there. :) )

- Runiq is fully designed around async. (At first glance I'm unsure how you would express, say, an HTTP request or file I/O in miniMAL - i.e., anything which in JS would require a callback.) In Runiq it would look something like this:

    ; assuming 'print' and 'read-file' are defined in the DSL... ;
    (print (read-file "foo.txt"))

- Runiq execution happens in parallel (taking a cue from functional languages) and the tree can be reduced stepwise; Runiq has a built-in mechanism for pause and resume. It looks like miniMAL executes wholesale, but I may be mistaken.

- Runiq has no (built-in) JavaScript interop, although it would be trivial to add that feature via Runiq's DSL-building API. I specifically avoided adding any type of sytnax to talk to JS directly because I wanted Runiq to be a safe sandbox by default, with the option to add "dangerous" functions easily if need be.

But, that's super cool and I wish I'd come across that earlier!

Runiq is my attempt to tie together a few ideas from Lisp with some features of JavaScript inside an interpreted language. Syntax, flexibility, data-as-code DNA would come from Lisp, while a JS backing could give reach and a big module ecosystem.

Runiq more or less does this translation:

    source: (hack (the) (planet!))
    ast: ["hack", ["the"], ["planet!"]]
    reduce order: "the" "planet!" -> "hack"

Function tokens map to predefined CPS JavaScript functions:

    "hack": function(a,b,cb){...}, // add numbers
    "the": function(cb){...}, // return 1
    "planet!": function(cb){...}, // return 2

Outputs produce new trees that eventually reduce to a value.

    -> ["hack", ["the"], ["planet!"]]
    -> ["hack", 1, 2]
    -> [3]
    -> 3

Runiq is very much an experiment, and some design decisions I made have trade-offs (speed, for one). But Runiq could still find a niche somewhere between grown-up projects like Clojure(Script) and single-purpose languages like PuzzleScript, both of which I admire.

I agree and that's what I like to do too when these issues come up (time permitting). Still, I hope my basic point came through: the small modules approach isn't a panacea; it can add its own set of problems; "monoliths" can be a good choice, not always, but sometimes.

Correct and I shouldn't have mentioned XHR -- it was just a fake example for the sake of my point. I just went back and ninja-edited my original comment above to call it "ABCXYZ" so that it's clear I didn't intend to call out any specific package/author.

I'll share a thought or two while I wait for $ npm install to finish.

I agree that other ecosystems could learn a lot from the Node philosophy. And in general I enjoy working with the technology. But it's not all roses. In an ecosystem of small modules, you often find yourself wading through many -- equally small -- annoyances which can add up to a lot of friction. Here's a contrived fake example:

Your app needs ABCXYZ. So you go shopping for a module. The most popular one looks good, but when you Browserify it your bundle ends up with 1,000s of extra lines of code for the Buffer shim. So much for keeping that footprint small. So you keep looking and find another one that has a good footprint, but a weird API and it hasn't been updated by the maintainer since 2011. The next one you find looks great, but the maintainer decided they were tired of ES5 and didn't feel like adding a distfile, so you would have to install a bloated transpile toolchain to use it. You're getting annoyed but you keep going. The next one's author inexplicably decided to implement everything with streams. But you're too busy to spend a day grokking streams and reworking your entire API to be compatible. The next one is packaged as a jQuery plugin. The next one doesn't have a license. The next one uses Web Workers for no reason you can see. Etc. etc. etc. Repeat.

Any of these could be problems with a monolith (and monoliths certainly come with their own pile of frustrations), but monoliths are less likely to hit these problems simply because they consolidate effort and personal emotional investment around a certain set of techniques and standards, which leads to more consistency overall.

The article's main point is solid: Learning to code is hard mostly because coding is hard -- not just because there aren't enough learning opportunities and not just because we aren't welcoming enough. And learn-to-code merchants who say "Coding is easy!" are a bit untruthful in the infomercial kind of way. As those of us who do it professionally know, coding is often tear-your-hair-out difficult. Misery loves company! :-)

That said, I have two problems with the article.

#1 - I don't like the idea of qualifications. Sure, the lack of career-path guarantees sucks, but that anarchy also benefits us. If I can get my hands on a computer, I can learn to code on my own (with lots of hard work, yes), build what I dream of, change my life. I can sidestep red tape, bias, prejudice, and credentialism that might work against me elsewhere.

#2 - I dislike the vague word 'aptitude', which the author uses many times. The idea of 'aptitude' may help distinguish Mozart from Salieri, but not Salieri from his cousin Fred. What I mean is, at the level most of us operate at, mightn't factors like motivation, persistence, and health affect us more than 'aptitude'? If the article replaced the word 'aptitude' with 'motivation' I'd like it better.

I've been looking for something like this. This cleanly solves the basic (majority) case and doesn't try to boil the ocean. It looks like it would be easy to build a higher-level API with more features on top of this, which is great. Nice work. Also kudos for documenting the shims in lieu of bundling them.

I'm not the parent commenter but here are a few that come to my mind:

    - Functions
    - Abstraction
    - Modularity
    - Design patterns
    - Programming paradigms
    - DSLs
    - Conventions for naming/formatting/arrangement

Although I grant that any of these could possibly work even better when codified into a framework.

Author. Looking back at this project now, I think the real takeaway is that the act of programming can teach. (Even when you program like I do.) I built this to learn concepts that had always frustrated me in school: fundamental math that I was fed up, as a 27 year old, never having understood. Building this really helped me wrap my mind around trigonometry for the first time, and I still open up this visualization when I need a reminder.

Mentioned in this article is "The Third Culture" by John Brockman of Edge.org. That book is worth a read, even nearing 20 years in publication. It introduces the ideas of several fascinating scientists (among them Dan Dennett and Lynn Margulis) whose work manages to transcend the stated "two cultures," bringing science to bear on what were traditionally seen as "humanist" problems and vice-versa. These are thinkers who've taken responsibility for bringing their ideas directly to the public, rather than waiting for writers, journalists and, ahem, "insight pornographers" (if you follow HN) to do it for them. I first read it after obtaining my English degree, and it felt like I'd been shot with a sudden antidote to a haze of intellectual nonsense. I wonder how well it contrasts against the current trend in glossy pop science, which I suspect may be the flip-side of the same coin.

Hi, Matthew Trost (author) here. I'm actually a bit mortified that this found its way onto Hacker News, as now my admittedly bush-league JavaScript code is getting the brickbats. :-) In truth, I made it mainly as a practice exercise: code, UI, documentation .... So, please check out the links offered by others here, as many talented folks out there deserve attention for their far-more-sophisticated work!

In any case, I love this discussion. Programming is fun.