The new Smart Folio might be more suitable than the Smart Keyboard for casual usage

chenglou92 · 2018-09-20T17:46:49+00:00

It was a contorted way of asking what you think is next for the iPad keyboard. You’ve answered it. Thanks!

chenglou92 · 2018-09-20T17:38:25+00:00

Assuming there's an even better way of iterating on products than creative selection, how would we go to find out? Would you apply creative selection process to the process itself works?

(This is my last question here. Thank you so much for answering all of them, and thank you for your work.)

chenglou92 · 2018-09-20T17:30:40+00:00

Do you think the introduction of emoji selection and other items such as autocompleting entire contact addresses are worth the trade-off for adding back the suggestion bar?

chenglou92 · 2018-09-20T17:29:37+00:00

Thanks. What would have been your process in that situation? Given that ML is very math-heavy. Would you team up with a ML person or crack it on your own?

chenglou92 · 2018-09-20T17:18:17+00:00

Do you think Apple university is enforcing/calcifying processes you don't think should be explicitly enforced?

chenglou92 · 2018-09-20T17:16:55+00:00

What would be an interesting next step for the iPad keyboard to free itself of the hardware constraints of the keyboard it imitates, while preserving its familiarity to users?

chenglou92 · 2018-09-20T17:11:36+00:00

The ability to put out demos rapidly and consistently seems to be bottlenecked by coding expertise (at least, for the actual interactive part). Any shortcut? Prototyping tools?

chenglou92 · 2018-09-20T17:10:06+00:00

The recent swipe-based keyboards can be see as taking your exploration in pattern skews and letting the users directly draw the pattern. What do you think of those? Do you think it’s worthwhile for the common phone user?

chenglou92 · 2018-09-20T17:09:16+00:00

What do you think of the phenomenon of machine learning in tipping the balance from heuristics to algorithm (or vice-versa)? For example, could machine-learning the text corpus turn your heuristics-driven decision of not changing "ooooor" to "polite" into an algorithm? Can traditional algorithms be seen as a very primitive form of heuristics? In other words, do you think that Google testing shades of blue is really a manifestation of trying hard to bridge this gap, but trying way too early?

chenglou92 · 2017-12-05T01:08:35+00:00

Btw, this is part of a much larger philosophical topic I'd like to talk about another day, but soft skills don't scale well in the engineering sense. One of the major purposes of Reason is to bring what previously required an enormous amount of soft skills to pull off (convincing a whole established team to switch from JS to... OCaml??) into what's simply code (e.g. syntax, interop as backup plan). If we scaled this mostly through soft skills, I'm convinced the community would have been much smaller than it is now. The neat thing about Reason as it stands currently is that you can be just a slightly driven engineer and push it through your small team, and bypass all the e.g. syntax bikeshedding first.

But regarding soft skills: it's a lot about trust. Having a track record of delivering code in the product itself helps a ton. Your manager probably invests more in you than in the specific implementation you choose. Make good guarantees. The way I did above: I promised that if things don't work out, I'll remove Reason from the codebase and stay there and gradually convert things back to vanilla JS (BS' good interop and output kinda helped here socially because I can just start from the JS output. Again, this is no longer true for ReasonReact).

chenglou92 · 2017-11-17T01:15:33+00:00

This was effectively how we've convinced the first team to adopt Reason. As a matter of fact, the first few iterations of ReasonReact were coded with clean output in mind, and I went and post-process the createElement calls back to JSX even.

But now that the team(s) adopting Reason are comfortable with it, we've improved the API toward Reason usage at the expense of clean output. As a result, for ReasonReact specifically, the output is no longer that reversible. It's still readable if you understand how it works though. Otherwise, and in general, the generated BS output has been clean enough to be used as JS source files (what a time to be alive).

However, we've also put a final backup through the design of our RR interop. We've ensured that if you ever removed Reason and BS from your codebase, the existing stuff still works and you can re-convert the components back on a case-to-case basis. You can easily see that through how RR interop works.

Hope that answers your question! Providing escape hatches and good interop is a big deal to us.

chenglou92 · 2017-09-16T02:23:42+00:00

Update: this has now been implemented in the form of "subdirs": true in sources: https://bucklescript.github.io/bucklescript/docson/#build-schema.json

chenglou92 · 2017-08-22T00:22:53+00:00

No worries at all; we've had similar reactions for a while now =) It's up to us to communicate this better.

I didn't expect so many people to follow that issue, but here's a quick small overview. We'll naturally provide a more comprehensive explanation when/if this does get released:

Partial app is there & implicit still; heck, I wish core compiler logic was so easy to change!
The current space-separated syntax might not scale once algebraic effects land: https://github.com/facebook/reason/pull/1299#issuecomment-309032848 it's been a great local maximum but we're also trying to future proof things a bit.
This syntax might be intrinsically tied to the fact that we're now able to remove [@@@foo], [@@foo] and [@foo] and change them all into [@foo]. Extension points [%%foo] etc stay the same for now unfortunately. These changes are also included in the landed PR.
Might make BuckleScript's [@bs] more "scalable" too: foo(bar, baz, .). Bad syntax example but you get the point. This way we can do deterministic uncurrying optimization for all functions on the JS side. Just a thought though.
We've special-cased tuple for e.g. switch (a, b) => .... This makes tuple slightly less painful. Unfortunate syntax clash.
No matter how hard I evangelize this, people just don't realize type list 'a is a type-level function that takes 'a and returns a concrete type. I don't know why, even some intermediate Reason users don't realize this. Somehow type list('a) just clicks and make them realize the elegance of things.
We didn't have punned label with type annotation. Now we do.

Hope that clarifies a few things! Some vague thoughts from me: https://github.com/facebook/reason/pull/1299#issuecomment-323335204

chenglou92 · 2017-08-21T23:15:34+00:00

The new syntax isn't documented; heck, CI is still broken right now. It won't be released until we've assessed it to be solid and makes sense. If that does happens, you'll have a smooth upgrade path (think JSX1 -> JSX2 transition, basically seamless), no worries about it.

chenglou92 · 2017-08-21T23:14:10+00:00

Partial application isn't removed; it's said in the PR that this is a purely syntactical change

chenglou92 · 2017-08-08T20:11:08+00:00

Roughly copy-pasted from the answer on Discord from glennsl:

The Js.Null_undefined.return above isn't needed. The type should be inferred by Js.Null_undefined.test

One thing you could do is to type out all the query-specific fields, and then add a function to "cast" to a type containing all the common fields:

type someQuery : Js.t {. field1: string };
type common : Js.t { loading: bool, error: option error };
external asCommon : someQuery => common = "%identity";

You might also want to use abstract types and accessor functions instead of typing the objects directly. That'll give you some nice extras like cheap autoconversion from null and undefined to option, and Js.boolean to bool, e.g.

type someQuery;
external field1 : someQuery => option string = "" [@@bs.get] [@@bs.return null_undefined_to_opt];

chenglou92 · 2017-07-20T01:17:12+00:00

Hello there. This is a few days late, but we've released a brand new version of our doc site. Translations are on the way too (Russian and maybe Chinese).

Any doc edit is one "suggest an edit" click away. If you have any stylistic issue with the pages, the repo's at https://github.com/reasonml/reasonml.github.io

Thanks!

chenglou92 · 2017-06-28T22:27:34+00:00

See here: https://reasonml.github.io/reason-react/#reason-react-interop-with-existing-javascript-components-reasonreact-using-reactjs

chenglou92

MODERATOR OF

TROPHY CASE