chenglou

BuckleScript’s author works for Facebook for years now.

There are, for example: https://www.youtube.com/watch?v=VMP2w5o4Yco

Their algorithm also addresses your concern of how to make pages “line up”.

This method’s likely subject to the criticisms around this post.

Yeah it’s not inspired by adapton. Plus, they work differently. Their data flow in opposite directions.

> Also for context on why I'm writing this, I'm just naturally inclined to compare the design of Swift to Rust, because those are the two languages I have helped develop. Also some folks like to complain that Rust doesn't bother with ABI stability, and I think looking at how Swift does helps elucidate why that is.

I went to their open house twice. Since it the article says Bret is on sabbatical, maybe we should wait a year for the next one. It's not easy catering to waves of new people.

Oh man, that repo's stale. The official instructions are here: https://reasonml.github.io/reason-react/docs/en/installation

Nice to see the author here. Note that I still do appreciate the post. You're also right that establishing simple, potentially extreme profiles isn't the goal but does help with understanding. The nuance I wanted to convey was lost while describing the folks above; I don't think I have much more to add about it, though here are some related thoughts.

My personal answer to your question for me is "It depends. Lemme check what feature we're talking about here". My mentality isn't "nice, an occasion to exercise my principles", and judging from the talks two of the three aforementioned people gave, I'm positive they adopt a similar attitude: happen to take a stance, but don't actively seek it.

When I go over some codebases, I often find flavors of code that smell like someone tried too hard taking a stance. E.g. code that overly future-proofs, code that definitely needs less ad-hoc-ness, code that prematurity optimizes in an obviously naive way, code that tries too hard to use a functional/OO concept, etc. Note that these all belong to different categories in your post, but one thing they share is that they all feel like p̶e̶o̶p̶l̶e̶ ̶w̶i̶t̶h̶ ̶d̶i̶f̶f̶e̶r̶e̶n̶t̶ ̶p̶r̶i̶n̶c̶i̶p̶l̶e̶s̶ ̶s̶l̶a̶p̶p̶i̶n̶g̶ ̶m̶e̶ ̶i̶n̶ ̶t̶h̶e̶ ̶f̶a̶c̶e̶ ̶w̶h̶i̶l̶e̶ ̶l̶e̶c̶t̶u̶r̶i̶n̶g̶ ̶m̶e̶ ̶a̶b̶o̶u̶t̶ ̶h̶o̶w̶ ̶t̶o̶ ̶c̶o̶d̶e̶ folks shoehorned principles back into the project rather than the other way around.

So an alternative way of categorizing things is whether you go from the principle to the project, or vice-versa (aka whether you go from abstract to concrete or vice-versa). A result of that is that Jon Blow and Rich Hickey end up in the same category while Bret Victor and Alan Kay ends up in another (without speaking too much for themselves, and thanks to the nice confluence that is HN, I’d say that this categorization has been empirically verified if you check these people’s discussions with each other).

Also, as computing domains grow, you'll probably need to create many more categories if we cross-cut the way you did in your blog post; on the other hand, this alternative way of cross-cutting, I believe, would stay constant. But hey, that doesn't mean your way of cutting it is wrong. The alternative one might be simpler but more abstract.

Maybe this explains why many people in this thread debate on whether the cross-cutting is fair. If you ask the alternative question "which direction do you work from/to", you might get some better partitioning.

This post is nice, but...

Rich Hickey and Bret Victor here are squashed into overly simple (and/or wrong) categories whose descriptions go like "the best programs [...] formally prove correctness" and "beautiful code is more important than beautiful UI". Both have been very vocal against these points.

Jon Blow is definitely not (just) in category 2. "But one of the reasons his last game (The Witness) took so long to write was that he wrote his own engine instead of using something off the shelf [...]. I understand". He'll probably have a heart attack reading this deep, deep assumption that creating his own thing slowed down his unique game rather than enhanced it.

As someone who does OCaml (and who maintains ReasonReact), shoving it into the category of "poetry is more important than execution speed" and "code over UI" is exactly what we're going _against_. It sucks to emphasize pragmatism, compile & runtime and UI, only to be shoved back into the "poetry" category.

I get a weird feeling criticizing a blog post that mostly gets the right idea across but then goes e.g. "don't worry, we get that you're a poet and care more about that than real-world execution and we empathize with your different perspective" or "we get that you don't prioritize writing simple beautiful code". Like, I _do_ care and these folks _don't_ abide by what you're describing. There's gotta be a name for this.

Eh where did you see that? ReasonReact is runtime-free, unless you’re explicitly using some of the extra helpers.

Related question: do you know how leveraged GPUs are in shortest path implementations and research?

1) That's a pattern match. Nothing to do with pipe

Yeah, more practically speaking, this “flattening” behavior of nullable(nullable(foo)) = nullable(foo) makes type checking much harder. This is one of the things that’s subtle and hard to get right when you tackle a type system on top of an existing dynamic language. The general case also induces horrible type checking performance. Another example of flattening would be JS’ promises, where awaiting on nested promises “flattens” every level into one (in FP jargon, it’s map and bind combined into one function).

With the right sugar, the non-flattening version, option type, is actually _much_ better for not just type checking, but also developer ergonomics. Consider if you want to distinguish a map missing a value, or having a value that happens to be null. Or an iterator that asks you to return null to signal termination, but you just happen to want to provide the value null.

So, language-agnostic dead code elimination by intercepting at much lower level? That’s great. How does it work with dynamic linking?

I see what you’re trying to say here, but Reason (and its compiler BuckleScript) aren’t the kind of puristic language folks might think they are. BuckleScript has one of the most comprehensive way to bind to whatever piece of JS you have: https://bucklescript.github.io/ and you can also just include raw JS code as a last resort, all type checked still, while keeping type soundness (in this case, almost like `any` but not really).

HN’s too short to describe the extent of it; if you’d like some language that shares a similar spirit as TypeScript (with extra features such as native compilation), please do check out Reason and BuckleScript. Our main goals are great JS interop, fast build, robust type system and a familiar syntax for JS users.

I’m familiar with these positions (static types, ADT, parsing, etc). But my comment on “less surprising” was meant for Python; it turned out that you can get pretty far with it with no static types nor ADT. So it’s very possible that Go can fare not too badly. The reason why I wondered about Go is because I’ve seen several HN posts about using Go for writing parsers/compilers with surprisingly ok result.

(I don’t advocate dropping static types or ADT; just that in the spirit of this blog post, it might be worthwhile to examining our assumptions.)

Hey trishume! It’s been a while (this is the Reason person).

Great post; it echoes all the experiences I/we’ve personally had, especially the alternative Rust section: on the spectrum of how much intelligence one needs to understand fancy abstractions, all of us programmers, good and bad, are pretty much lumped to the lower end. I’ve seen plenty of skilled folks “decompensate” their expertise by reaching for overly complex abstractions. The definition of a “strong” programmer, as per the post and usually in real world, should probably be rectified to include not only “the person knows how to use this abstraction”, but also “the person knows when to stop”.

In the same vein of idea, it’d be interesting to know how Go would fare in this project. Go’s philosophy is pretty much the opposite of a language that’s usually used for compiler research; but I’ve seen indicators that using it could be surprisingly effective (and in light of this post, maybe less surprising).

More importantly, it’d be nice to know the perf characteristics of each project =)

By viz directory did you mean https://github.com/damelang/nile/tree/master/viz/NileViewer

And yeah, it'd interesting to build one. Is there enough info on it to build such compiler though? That NileVM.js is helpful. I've posted a list of resources in another comment below, but maybe I've missed a few

Do you have an easy way to set up Nile and get it running? And did you run Frank too?

Since Alan Kay mentioned Nile, I'm gonna dump here the list of relevant resources on Nile and its derivative works that I've found over time:

Ohm, the successor to the parser (Ometa) used by Nile: https://github.com/harc/ohm

Maru, Nile's compiler/interpreter/whatever: https://www.reddit.com/r/programming/comments/157xdz/maru_is...

Nile itself: https://github.com/damelang/nile (pdf presentation in README) https://programmingmadecomplicated.wordpress.com/2017/10/11/...

Gezira, svg drawing lib on top of Nile: https://github.com/damelang/gezira/blob/master/nl/stroke.nl http://web.archive.org/web/20160310162228/http://www.vpri.or... https://www.youtube.com/watch?v=P97O8osukZ0 https://news.ycombinator.com/item?id=8085728 (check the demo video) https://www.youtube.com/watch?v=ubaX1Smg6pY (live demo on stage later on) https://github.com/damelang/gezira/tree/master/js/demos (downloadable and runnable in browser)

KScript, UI building on top of Nile: https://www.freudenbergs.de/bert/publications/Ohshima-2013-K... http://tinlizzie.org/dbjr/KSWorld.ks/

Final Viewpoint Research Institute report, where the entire system (antialiasing, font rendering, svg, etc) was rendered using Nile into Frank, the word/excel/powerpoint equivalent written completely in Nile + Gezira + KScript): http://www.vpri.org/pdf/tr2012001_steps.pdf

VPRI wiki restored from archive.org: https://web.archive.org/web/20171121105004/http://www.vpri.o...

Shadama, which the Nile author (Dan Amelang) worked on too: https://2017.splashcon.org/event/live-2017-shadama-a-particl...

Partial DOM reimplementation on top of Gezira: https://github.com/damelang/mico/blob/master/gezira/svg.js

Partial reimplementation of Gezira: https://github.com/Twinside/Rasterific

And the famous Nile Viewer itself (everything interactive): http://tinlizzie.org/dbjr/high_contrast.html https://github.com/damelang/nile/tree/master/viz/NileViewer

Commentary: http://lambda-the-ultimate.org/node/4325#comment-66502 https://fonc.vpri.narkive.com/rtIMYQdk/nile-gezira-was-re-1-... http://forum.world.st/Vector-Graphics-was-Pi-performance-fun...

Since Alan Kay himself is on Hacker News, maybe he can comment with more links I couldn't find. It's hard to fire up the live Frank environment, though understandably reproducing the working env might not have been a top goal. Maybe someone more cunning can merge these into a single executable repo or whatever so that I can stop playing archaeologist =)

Sounds about right. Thanks! And I’d guess that the perf overhead would be nontrivial either even in Rust.

Where would you say that Rust core folks stand, regarding usage/overusage of such patterns? Sugar for common unwrappings?

Appreciate the pragmatism =)

People buy the Apple hardware but stay for the software. Scott Forstall might have been considered but he didn’t play well with a few other key design and hardware people at the time. In an alternative world where SF is CEO, you’d end up with an iPhone X that looks like iPhone 4/5 and might have had weaker hardware but largely compensated by better software (as demonstrated by iOS 12, early iPods and macs, etc.). Then with time, the skeumorphism would dial down and meet iOS 7’s extreme minimalism in the middle, like current iOSes are doing anyway. SF knew machine learning, so Siri would definitely have been his focus too.

There’s a niche of folks who are waiting for SF to make a come back the same way SJ did =)

Apple uses and maintains https://sproutcore.com, not Cappuccino. The latter was made by ex-applers a long time ago. Though Apple also isn't monolithic and has many teams independently evaluating Angular, React and others.

Not too coincidentally, the author of Objective-Smalltalk, who said above that he wants to leverage Cappuccino, has also written up his criticism of React here: https://blog.metaobject.com/2018/12/uis-are-not-pure-functio...

Related: I've talked to a Cappuccino founder recently too, and my casual observation (which he agreed with) was that had they done Cappuccino all over again, they should have probably dropped Objective-J. Imo it's just a bit too much of a language bikeshedding and I don't think it would have changed framework _that_ much (proof: Swift works well with UIKit and AppKit). Though my opinion was just based on practicality of adoption; if Objective-smalltalk wants to take its time exploring around more than anything else, then I'd say it + cappuccino seems like a nice fit.

I'm really looking forward to Cappuccino staying alive for another ten years (and I wish all the luck to Objective-smalltalk's author) =). Though the recent Cappuccino conf doesn't feature many younger programmers.

Nice! The one big problem with most visual programming paradigms is that they’re not abstraction resistant. Pane counteracts this through aggressive concretization, not by suppressing your expressively, but by showing all the concrete data flowing through it. The usage of data here is multiple folds:

- it serves as static, TDD-like documentation.

- it serves as reactive cells you can manipulate. Note that you can be wishy washy about the reactivity’s semantics here because it’s only used for example and quick-and-dirty explorations, not for runtime correctness of the program. Pragmatically speaking, this is crucial. Some of the future directions mentioned at the end might conflict with this and make the environment less appealing.

- it serves as a very convenient mechanism for defeating the double-edged sword that is program abstraction.

The pragmatism of this project gives me more hope than most of the cited references. Actually, I believe that the more you dive into these paradigms, the more pragmatic you need to stay in order to achieve success. This is intrinsically related to the fact that dimensionality reduction (part of un-abstracting a real-world software program) can only be 80% correct. Visual paradigms that enforce you into a black-and-white way of doing something don’t scale.

Kudo to the author for resisting the temptation of Exploring some of the overly puristic directions! The polish definitely helps too. Some of the perf problems are beginning to show in the latter examples though.

Also, in terms of editing efficiency, this paradigm might work better on tablets, especially through some intuitive multitouch gestures. But then your audience decreases dramatically.

Edit: oh wait, this is the Joshua from Dynamicland! Small world...

It’s actually broadly available on iCloud.com and works very well.

There’s actually another category: type reification WITH type erasure! https://github.com/mrakgr/The-Spiral-Language/blob/master/re... (search for default_of)

Well, kinda cheating since the language’s about inlining these away. But technically true...

> even though the underlying rules (or underlying “language”) used in different areas of mathematics are different, there ends up being some way to translate between them—so that at the next level of abstraction the path that was taken no longer critically matters.

This and the previous arguments made me feel much better about the value of using proof assistants to advance mathematics! For example, there’s been quite a bit of controversies surrounding the usage of e.g. Coq to prove the 4-color theorem; folks complain that although the proof can be verified, brute-forcing it doesn’t provide us with further mathematical insight. But that might be fine, since we’d use the proof to build up other abstractions, and if we felt the need, we can always come back and re-prove 4-color using a more humanly explanable method.

The other nice insight is that maybe we get to define “simplicity” with a bit more rigor than how we usually define it (I’m aware of Clojure’s definition of it): a few number of somewhat orthogonal axioms, that enable the biggest reduction of quantity of steps needed when proving things with said axioms. For software engineering, this means having relatively few primitives, that are composable enough to greatly simplify a program either statically or dynamically. No need to try too hard to reduce the axioms/helpers into a single one, as the ratio of utility might tip to the wrong side.

It’s also cool to notice that such common definition of simplicity might change depending on what new concepts we assimilate. Also interesting that you can somewhat quantify it by using a probability distribution over the common use-cases of your axioms!

Yep! The video explains why at the end. These models are often very GC-unfriendly unless you know what you're going & have reasonably good hooks into the GC. Jane Street talks about this aspect here too: https://www.youtube.com/watch?v=G6a5G5i4gQU

verg related: check out Adapton: http://adapton.org/, specifically, the May 2017 video in the videos section.

There’s a comment in the initial Incremental blog post about it: https://blog.janestreet.com/introducing-incremental/?utm_sou...

Yep, though we don't put much emphasis on it for now: https://twitter.com/jaredforsyth/status/1026706210043490304

This is a lisp syntax for Reason, that works already with our language-server integration, etc.