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?
High-Level Is the Goal
151–158 of 158 posts
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…
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
#153The 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…
Re: High-Level Is the Goal
#154I 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…
Re: High-Level Is the Goal
#155Earlier 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.
Re: High-Level Is the Goal
#156Earlier 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)?
In 2015?
Re: High-Level Is the Goal
#157Earlier 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.
Re: High-Level Is the Goal
#158The 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.
This is quite honestly the stupidest thing I ever read, and I read a lot of uncle bob