The world is the way it is because of a series of compromises and negotiations by competing interests. It's easy to look from one perspective and only see the hilltop, and think you can get there by taking the straight road.
Obvious and possible software innovations
61–70 of 157 posts
Re: Obvious and possible software innovations
#62I actually really dislike this whole post. There’s a really condescending tone lurking just beneath the surface for most of it. It’s also extremely hand-wavy about the problems, their causes, AND possible solutions. Also, so whiny. At this point I don’t care if he even has any good ideas because he’s made me so mad just by his writing style.
Perhaps he's a generation or two older, and doesn't want to go into a lot of technical detail to back up his opinion. I think his perspective is valuable. He's seen a lot, and he's right that we could do to learn a few things from the past.
I'm probably older than he is, and it seems whiny to me.
Re: Obvious and possible software innovations
#63I really dislike the article, here are some reasons (referencing the numbered arguments in the article).
1. There are many such parsers. Rusts bindgen [1] is one of them, I have written a proprietary one last year. This is pretty common to do for narrow use cases, there just isn't one for "Convert a C API to Ruby"..
2. "Most VM designs I’ve seen are basically just student exercises". Seriously? Create a better on and get rich then! I'm pretty sure Google would pay good money for something better than v8.
3. You can run z/OS on EC2. They do very different things. It's like saying I wish that cars were as simple as a strawberry.
4. "People used to make GUI frameworks which did more than electron apps, looked better and fit in the tens of kilobytes range." That's correct and that's why lots of apps are based on native UI frameworks. For some use cases, electron seems to hit a sweet spot (mostly not having to write UI for each platform and the web too). If you don't like electron apps, don't use them, most run in the browser too.
5. "Compilers and interpreters should learn how modern computers work." I don't know where to begin here. Modern compilers optimize for latest hardware all the time, one recent example out of thousand others is this [2] where V8 redundantly inserts short functions into memory regions close to the code they are called from in order to get more instruction cache hits.
[1] https://github.com/rust-lang/rust-bindgen
[2] https://www.techradar.com/news/google-chrome-is-now-dramatic...
Re: Obvious and possible software innovations
#64Feels like a list of stuff where he massively underestimates the complexity of the fields he's talking about. Drag and drop UIs have, as he indentified, been tried. They were a leaky abstraction where incremental functionality was difficult to implement.
I think he means things like XCode's Interface Builder. He's not massively underestimating the complexity as much as saying that huge swaths of that complexity are unnecessary, were it not for business requirements that often require us to do things the cheapest way possible (like hiring "fungible" web engineers to build an electron app instead of paying native platform engineers to build a first-class native app) --…
I have lightly used both web UI stuff and native UI stuff, and on the desktop at least, web UI concepts are lightyears ahead. I think native UI development for PCs will return when and if the concepts there catch up with the present state of the abstractions and patterns that work for web dev. GTK, the one I know the best, is still in an era where object orientation is a new and technically difficult thing to achieve. Not bad at all, but we can do things so much more advanced than that if we port over the lessons learned when inventing ways to manipulate and efficiently push updates to the document object model.
There are some projects working on this but they are not yet at the level of "copy paste works," or "you can use either a retina or non-retina display and it won't look badly scaled or blurry on either." But I hope this will be sorted out soon because there is a lot of software I want to write with it.
Re: Obvious and possible software innovations
#65“He would be hailed as a Jobs-like technical innovator if he had some of his slaves do this, and he would be remembered with gratitude, rather than as the sperdo who dumped his wife for sexorz with lip filler Cthulhu.” Misogyny is really cool! Thanks Scott Locklin!
There is nothing in this quote which implies a hatred of women, and perhaps you inferring it says more about you than about the quote.
Did you miss the "lip filler Cthulhu"?
Re: Obvious and possible software innovations
#66An incredible optimization of Dunning–Kruger × Bravado.
Re: Obvious and possible software innovations
#67I only had to read the first few sentences of the first point to see that the author thinks problems are easy because they don't understand the difficulties. Parsing C function prototypes doesn't give you enough information to write safe language bindings. For example if you see "char* make_stuff(const char* param);", you don't know whether the memory pointed to by 'param' can be reused after the function call, or wh…
[flagged]
Re: Obvious and possible software innovations
#68I actually really dislike this whole post. There’s a really condescending tone lurking just beneath the surface for most of it. It’s also extremely hand-wavy about the problems, their causes, AND possible solutions. Also, so whiny. At this point I don’t care if he even has any good ideas because he’s made me so mad just by his writing style.
Contrarily I love this post. The first point I don't care about because I avoid C whenever possible but I agree with all the rest.
Electron is awful. So are phones. These things don't have to be so.
Re: Obvious and possible software innovations
#69I only had to read the first few sentences of the first point to see that the author thinks problems are easy because they don't understand the difficulties. Parsing C function prototypes doesn't give you enough information to write safe language bindings. For example if you see "char* make_stuff(const char* param);", you don't know whether the memory pointed to by 'param' can be reused after the function call, or wh…
... and yet, Ada95 managed to include (as part of the standard for the language) the ability to bind to C, C++, Fortran and Cobol. All of which have absurdly different calling conventions and assumptions about memory.
Re: Obvious and possible software innovations
#70I actually really like this whole post. Every time I think about quitting HN altogether a rare gem like this comes along. You should be able to have a little fun with common pain points we all have to deal with. The author has some pretty good suggestions as well. But I almost lost my drink with this one: “ Imagine if the EC2 were as clean as, I dunno, z/OS, which has more or less been around since the 1960s. That wo…
Part of what makes it funny is that if Bezos somehow got IBM to license z/OS to AWS to offer z/OS as a service on-demand, that it would likely be incredibly lucrative.