HN user

_hardwaregeek

2,494 karma

Student (on leave) at NYU Cloudflare intern for fall 2020 Interested in compilers and programming languages

GitHub: nicholaslyang Email: nick@nicholasyang.com

Posts1
Comments383
View on HN

This article is bugging me for some reason. I don't disagree with it. It's certainly easier to make a language now, even more so than in 2016 when this article was published. But it feels like saying "it's easier to make a bridge than ever". That statement isn't wrong. I'd much rather make a bridge with modern technology. But it's still a damn hard task.

And citing parsing isn't a great example. Parser generators have been around for ages. And they're usually not the hard part anyways. Defining a simple grammar and parsing it, even manually, isn't that terrible of a task. Getting decent error messages and figuring out recovery? That's trickier.

Code generation has certainly gotten easier. But you still need to go through the process of figuring out how to lower your abstractions. My language is still extremely basic but I've still had to map my high level types and control structures down to WebAssembly. LLVM won't do that for you.

There's also more that your average user expects if you want a language that people use. Decent tooling is important, so a language server and some syntax highlighting packages in different editors. Good error messages. Decent type inference. Most of these you can eschew in the first few iterations of your language but eventually you'll need them.

I feel bad criticizing this post because writing a language has been one of the most instructive experiences I've had. I've learned so much about code generation, typechecking, the WASM spec, etc. But it's still a lot of tough work to get to something people can use. I'm not sure parser generators and LLVM make it that much easier.

No More Coffee 6 years ago

Key point here is that you probably fixed your sleep schedule sometime after high school. Coffee dependency is a pretty common hotfix for a poor sleep schedule. Once you take away the poor sleep schedule, coffee becomes less necessary and more a nice to have.

It'd be interesting seeing the long term effects high school sleep schedules have on people. I wouldn't be surprised if poor sleep patterns in adolescence lead to insomnia and other issues later in life. I definitely felt like my high school sleeping patterns were damaging to my mental and physical health.

I agree and sympathize with what you're saying. Coding screens are a necessary evil. But perhaps they can be omitted in certain situations. I know I completed the Google foobar challenge far enough to alert a recruiter, only for the recruiter to send me a snapshot test. Like c'mon, I just solved a whole slew of harder problems than this.

I wonder if companies like TripleByte are actually successful in solving this issue. I've avoided them because I'm skeptical of recruiting companies, but it might be a good idea to have people take one coding screen and have it apply to multiple companies.

Agreed that it's tricky, but there needs to be some feedback loop. Otherwise you end up with seriously broken processes that never get fixed. Companies tend to care about false positives more than false negatives, but there's a decent possibility that some companies have an extremely high false negative rate.

Is it just me or does Quora straight up not work on Firefox? Whenever I click the Continue Reading button, it fails to load more and gives me a generic "Something Went Wrong" error. Do people just not test on Firefox anymore?

So happy to see the Dekalog here. It's hard to find it streaming. Dekalog 1 is a particularly relevant film for HN since it deals with a programmer and his idolization of technology. There's a small moment at a shrine with wax that is immensely beautiful. Kieslowski has such a great eye for the small details and poetry within the scene.

I've tried to use iterators and closures in my code, but it's not as easy with error handling and lifetimes. Like I could figure out the magic incantation that lets me map over an iterator with a function that returns a result. Or I could write a for loop that pushes to a Vec.

Or I could chain an ok_or_else on an Option but ugh now Rust is complaining that I'm capturing a reference to self. Screw it, I'll rewrite it to be an if let with a return. Part of the problem there is that we know an ok_or_else with try! will execute the closure and return if the value is None, but Rust's borrow check doesn't know that.

None of this is Rust's fault. It's just that it's hard to combine ergonomic closures and borrow checking.

It’s a little too early to see the effects of Jony Ive’s departure. He left less than a year ago. He probably had a decent role in designing Big Sur. Plus all the remaining designers were probably hired by Jony. I doubt we’ll see big change until a few years out.

I use a sous vide machine to keep the yogurt at a consistent temperature. If you're working with non dairy milks, that extra time can help a lot.

If you're looking for another good fermentation, kimchi is a great one. There's nothing better than making kimchi fried rice or kimchijjigae with homemade kimchi.

I highly recommend reading The Little Typer if you want a great book that bridges math and code. It starts out describing Pi, a Lisp with some interesting restrictions (limited recursion, types can have values, etc.). They build up some cool stuff like vectors with the size encoded in the type. All of a sudden, they explain that equality is a type, and any value of said type is a proof! Turns out you can think of many proofs as manipulating data structures to get a value of a certain type.

I wonder how long until we get a somewhat mainstream language with pi types. I know Rust considered adding them. And I recently learned that Rust does allow for quantification over lifetimes^[1]. I could certainly see a language that implements dependently typed arrays. Midori for instance looked into eliding bounds checks with compiler proofs^[2].

[1] https://doc.rust-lang.org/beta/nomicon/hrtb.html [2]: http://joeduffyblog.com/2016/02/07/the-error-model/

It's definitely not the worst to be overly well read in programming literature. But oh man does it get old arguing with someone who is taking advice from a very niche, very particular field such as game development and applying it to general software development.

YouTube was (and still largely is) written in Python, way before it was cool and well-known

That's a good point. I wonder how many successful apps used tech that only appeared boring after the fact. Rails is a fairly boring stack today but back when GitHub started, it probably wasn't.

That's true, but JavaScript is something especially controversial :D. I've yet to find a programmer who doesn't have some sort of stance on JS

Also yeah it is fine to say "I don't care for JS" sans explanation. But if someone were to ask why, it'd be reasonable to expect a list of justifications that had some nuance.

I'm starting to develop a theory that a person's stance on JavaScript reflects their ability to critique reasonably and therefore their maturity as a developer (to an extent).

JavaScript undeniably has some problems. It's also undeniably useful and eating the world. If you can hold both of these stances in your head and reconcile them into a nuanced opinion, then that's a great sign. If your viewpoint collapses into "JS sucks!!!" or "JS rules!!!" then you're not providing an opinion as much as a dogma, often one that is regurgitated from some other source.

I'm not saying that one should find JavaScript good or bad by the way. Someone who abjectly dislikes JavaScript but also understands its utility is quite useful. The creators of TypeScript, ReasonML, etc. all had to dislike JavaScript in some form. But they had to dislike it in a productive, nuanced manner.

I recently watched Tarkovsky's The Sacrifice which also deals with the threat of nuclear destruction. The main character is having a birthday dinner when the news informs everybody about the nuclear threat. The simplicity in which this information is revealed and the transition from the mundane to abject fear connected really well to modern times.

It's interesting seeing film ideas repeat and be interpreted by multiple directors. It's almost like some ideas need to bounce from director to director before they find the right outlet. I Live In Fear begets Dr Strangelove begets The Sacrifice.

People in all countries get measles. Should we help every country equally? If, gasp, there's a rich kid in Pakistan who may get a free measles vaccine, is that evidence to stop fighting measles in Pakistan?

White families have ten times the average wealth versus black families. Putting aside the significant mountain of evidence racial bias in hiring, in tech, in basically every facet of life, that single statistic should be evidence enough that more funding is necessary for minorities.

And what hypocrisy? You can say that black people are not inherently different but face different circumstances due to societal problems. That's not hypocrisy. That's simply acknowledging that race plays a factor in nurture but maybe not nature.

Atget, and Abbot after, were one of the great photographers who documented cities in flux. Paris for Atget and New York for Berenice Abbot.

Another artist who I've been thinking about is Michelangelo Antonioni. There's something about his juxtaposition of the characters' alienation with the spaces they inhabit that resonates with the pandemic. The phrase "social distancing" beautifully sums up so many of his films.

Oh yeah we're on the same page that taking classes in a different, specific topic is a great way to amplify your existing CS skills. I'm mostly making the point that going into college with the mindset of double major or bust can be counterproductive. The difference between a minor and a major can be a few extraneous courses, a lot more stress and a little less time to pursue your main interest.

I know I came into college determined to do a double major only to realize that I probably should have made that decision after taking a few courses and evaluating my level of interest in the two subjects.

The rise of React 6 years ago

Did Flux really bring one way data flow? Because that's a pretty essential part of React. Even if React adopted it later, it's a core part of React's appeal.

Do you legitimately see no difference in websites from 2012 and 2020? I'm honestly baffled if that's true. Payments are a massive difference that I've noticed. Every decent ecommerce site these days uses quite a lot of slick tricks to make the purchase flow really easy. Whether it's autocomplete based on Google Maps address data or being able to do everything without any obvious page refreshes, payments are significantly slicker. React definitely facilitates this.

There is no 'round trip' for server render

Uhh there is a round trip. You click on a link, the new page does a request, loads new HTML, new CSS and paints the new page. Sure, an SPA takes longer to load up front, but you can now ensure that everything past that point is seamless. On a site like Facebook where the initial load won't kill conversions (because people are already addicted), you can take a 500ms hit so that stuff like infinite scroll and seamless notifications keep people on the site.

The rise of React 6 years ago

Meh, React is great for more reasons than modularity. One way data flow combined with automatic updating and rendering is really really nice. I just wrote a simple UI for a terminal and having to manually call a function to paint to the screen felt rather...quaint. We've had modular templates for years. It's only recently that we've had the ability to think of UI elements as functions that automatically get called when their arguments update.

This article also doesn't delve into why Facebook supports React so much. Or why Twitter, Reddit and the rest are switching to React. The answer being that React lets developers make really smooth, really addictive websites. I wouldn't be surprised if there was some studies showing that any flash of unstyled content, i.e. a server render round trip, lowers conversions by x%. Therefore having a client side app is imperative if you care about having your users on your site. Multiply it by Facebook's revenue and paying the few million to fund a team of developers is a really good deal.

I've written a lot about this. If you want a job, start applying early. But don't feel like you have to get one immediately. If you're sufficiently motivated, consider taking time off to work on your own projects.

1. Don't take all CS classes. Try other subjects and diversify your knowledge. 2. Get good at sending emails. It can help you get a job, get contacts or just gather information. 3. Even though you should take non-CS courses, that doesn't mean you should get a double major. It's not always worth it. 4. Make sure you like CS. Having experience is a good sign, but people can be advanced or good at a subject they don't like. Make sure you like it even when it gets tough.

[1] https://blog.torchnyu.com/2020/03/04/take-fewer-cs-classes.h... [2]: https://blog.torchnyu.com/2019/12/19/sent-from-my-iphone.htm... [3]: https://blog.torchnyu.com/2020/05/15/the-case-against-double... [4]: https://blog.torchnyu.com/2020/05/14/do-you-like-it.html

ReasonReact has been used in production for 3 years now, with billions of page views a day. I'd still call it immature in many^[1] regards :D

The particular point of this project was to prove that each successive simplification that my friend proposed, i.e. avoiding Webpack for native ES6 modules, using lit-html instead of React, etc. introduced its own complexity. I'm not saying that these were all bad ideas, but just that they're fundamentally tradeoffs. I'm quite sure lit-html is a great stack. But it's not "better" than React any more than React is "better" than Angular.

[1]: Lack of async/await, or its equivalent, let+ in OCaml 4.08, is a big one. Mediocre typings for browser APIs is another.

Yeah I bet once you get the stack up and running, as well as smooth out the inevitable early adopter bugs of lit-html, you'll have a great experience. The subtext of this was my friend constantly telling me easy and simple it'd be versus React. When in fact each stack has its tradeoffs and incidental complexity.

What I like about the Joel Test is that it's not a test about whether your company has good working environments. Good is extremely subjective. Good depends on what you want. The Joel Test is a test about whether your company has adequate working conditions. Many of the points are no brainers. If you don't use source control and you don't have testers and new candidates don't write code, well shit, that's pretty damn bad.

My friend and I decided to start a project. This friend and I have had discussions where he espoused how libraries like Webpack, React, Redux, etc. just overcomplicate the web. I decided to humor him and do a "simple" stack of lit-html, vanilla JS and ES6 modules (since they landed in browsers). It took us maybe...a day to pedal that back? The first thing to go was doing ES6 imports in the browser. I forget the exact sequence of events but the MIME issue definitely showed up, along with maybe an untrusted source issue. Say what you will about Webpack, but native ES6 modules are definitely not here yet.