Live data from Hacker News

High-Level Is the Goal

bvisness.me

151–158 of 158 posts

Re: High-Level Is the Goal

#151
post #8

I enjoyed reading this article but I think the author overlooked that "low-level" languages aren't just less supported, they're also character-dense. You can accomplish more with less, simply because it's a higher level abstraction. If you choose to abstract through this problem, aren't you creating a high-level language?

As I mentioned in another comment, I find it easier to use Dear Imgui from a "lower-level language" like Odin or Go than to use any web framework with JS. You'd think that because web frameworks are so "high level" they would be better at expressing my intent. But actually the "lower level" tools are easier and faster and universally better. So which one is "high level" now? Which one is doing "more with less"?

Re: High-Level Is the Goal

#152

> a Redux action, which would update the global Redux store, which would cause all Redux-connected components on the page to update, which would cause all their children to update as well. In other words, collapsing one comment triggered an update for nearly every React component on the page. No amount of caching, DOM-diffing, or shouldComponentUpdate can save you from this amount of waste. yeah this is pretty much 1…

It's very easy to say the New Reddit devs were just "doing it wrong" and oversubscribing their components to Redux state, for example. (I love me a good `state => state` selector.) But also, this irrelevant-update problem was pervasive across all of New Reddit, across the app I worked on professionally for five years, and across many other applications I've looked at with the React and Redux dev tools. Irrelevant updates happen all the time with this stack.

If everyone who uses it seriously ends up "doing it wrong", I say it's the framework's fault.

Re: High-Level Is the Goal

#153
post #50

The Reddit example is about two different design choices. The DOM is a tree of state that needs to stay in sync with your app state. So how to make that happen without turning your code into a mess. The old Reddit had to first construct the DOM and then for every state change, determine what DOM nodes need to change, find them and update them. Knowing what needs to change gets ugly in a lot of apps. The other alterna…

We measure computer performance in the billions and trillions of ops per second. I'm sorry but if it an app takes 200ms to hide some comments, the app or the tech stack it's on is badly made. > The web has complexity also of client/server with long delays and syncing client/server and DOM state, and http protocol. Desktop apps and game engines don’t have these problems. Hugely multiplayer games consistently update at…

I don't know why people always bring up "but networks! but client/server!" when I point out that 100% client-side behavior is slow on the web.

Re: High-Level Is the Goal

#154

I think the point about tooling being the problem deserves more emphasis. I'm a firm believer that the right thing to do should be the easiest thing to do. Currently, the easiest place to innovate is at the top of the stack, using web technologies and languages like JavaScript. You can see this with languages like Rust and Go—they're some of the first low-level programming languages with actually good tooling, and, a…

Most of the time it's genuinely much easier to use Rust or Go than to use Python or Node because the tools are just so much better. This is why I don't like judging "high level" or "low level" by some perceived position in the stack. All I care about is how well it lets me express my intent as a programmer.

Re: High-Level Is the Goal

#155
post #30

Earlier quoted context omitted.

> The main consensus in the native space is that Qt is still miles ahead of any other cross-platform desktop framework (including WxWidgets). Doesn't mean that Qt is anywhere good - it's just the least worst option out of all. That's not consensus. I very much reject a "desktop framwork". Qt has its own abstractions for everything from sockets to executing processes and loading images, and I don't want that. It force…

> Anything that forces a specific language and/or runtime that I don't like is dead in the water. Ftfy.

No. Any forced runtime is bad because overall it will have few users. The ideal is a C library with the API described in some IDL that allows mechanical generation of bindings for all language runtimes.

Re: High-Level Is the Goal

#156

Earlier quoted context omitted.

Why would C# be the worst choice? Do you gave any real arguments or is it just your biased opinion.

Sorry, made a typo with 'gave' -> 'have'. But the point stays , why would C# be (one of) the worst choices here (when C# has small AOT binaries, hot reload etc)?

> when C# has small AOT binaries, hot reload etc

In 2015?

Re: High-Level Is the Goal

#157

Earlier quoted context omitted.

They've picked Dart because it was the only language that could have small aot binaries, hot reload capable runtime without compromise and most importantly because they could influence development of the language. C# is one of the worst choices they could make at the time.

I don't think so, I think that some teams at Google were trying hard to push Dart that no one wanted. And so Flutter was about to create a framework that was supposed to be the main and only one for Android app and co in the future (at that time) to force us on switching to Dart.

No.

Re: High-Level Is the Goal

#158

The author doesn't understand the point of low level, and strikes me as a person who's programming to "fit in"

I work at Mozilla on their wasm compiler.

> Their view of the world was too high-level. If all you know is React, you have no choices—you can only use React, or meta-frameworks on top of React. But the lower level you can go, the more the tree opens up to you.

This is quite honestly the stupidest thing I ever read, and I read a lot of uncle bob

Post reply on HN