Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Obvious and possible software innovations

scottlocklin.wordpress.com

Post reply on HN
Print view View original

41–50 of 157 posts

Re: Obvious and possible software innovations

#41

Post by andrewflnr »

speedgoose wrote: post #19

There are many reasons why developers use Electron for GUI development. The size of the final package is not very important, and creating many times the same native application is not that appealing. Having a cross platform, responsive, and a modern high quality framework is much more appealing.

> The size of the final package is not very important

You can only install so many packages with this philosophy before size starts to be important after. More to the point, you can only run a few of them at a time, on machines with gigabytes of RAM. This is a profound embarrassment to our industry. If by "responsive" you're referring to input latency, Electron apps are at best on par with native, usually worse IME. If by "responsive" you mean accommodating different displays... it's a desktop app. Your statement about a "high quality framework" is basically orthogonal to reality, but I'd like to see you justify rating React "higher quality" than Qt5.

Re: Obvious and possible software innovations

#43

Post by kodablah »

sudosysgen wrote: post #31
kodablah wrote: post #10

> have all the functions described in it turned into reasonably safe FFIed function calls Many langs get close with the ease of importing C headers (Go, Rust, etc), but once you ask for reasonably safe FFI'd calls, you're asking a bit too much since ownership goes out the window. Otherwise, if you mean turned into acceptably-unsafe FFI'd function calls, agree just about every lang with C interfacing built in should h…

Many Electron apps are native on mobile. So we really mean on all 3 desktop platforms. The answer is obviously Qt or Java. It works.

And many Electron apps are not native on mobile, just use a web view, and share many resources with their Electron cousins. Same with the web apps.

As someone who has written multiple Qt and Java GUI apps, it always seems fine at first until your UI needs become more unique (and you're subclassing QWidget/JComponent) and you have to jump through hoops to get something a web view has (e.g. streaming video).

I don't like the lack of native any more than the next guy, but I can understand sacrificing native benefits for cohesion/features. If you can tolerate a middleground of non-native but no-browser-bloat, Flutter or .Net Maui may mature enough to help for the complex uses.

Re: Obvious and possible software innovations

#44

Post by ajarmst »

If they're so easy and obvious, why hasn't the author done it, at least as a demo? The article also reeks of "this doesn't work for me, therefore it won't work for anyone" I doubt I'm the only one who absolutely does not concede that everything should have a GUI interface.

"Why does shit like DPDK exist?" I don't know, but I bet you could find out with a little investigation, which might make this sound more like a well-researched position and less like a tantrum.

"people who absolutely insist that the Church Turing thesis means muh computer is all-powerful simulator of everything". Yeaaah...we're done here.

Re: Obvious and possible software innovations

#45

Post by andrewflnr »

RcouF1uZ4gsC wrote: post #14

> Automated FFI parsers. In 2021 I should be able to point any interpreted language at a C include file and have all the functions described in it turned into reasonably safe FFIed function calls, The big issue with doing this is that C does not have enough of a type system to exactly specify the interface. Is that char pointer, a null terminated string, or is it a pointer to an untyped buffer? What is the ownership…

There's definitely still a lot of scut work the compiler could (and therefore should, in my view anyway) be doing for you. Even if it got you to the point where you can setup those safety invariants in your interpreted (or whatever) language, that would be nice.

Re: Obvious and possible software innovations

#46

Post by nixpulvis »

TimTheTinker wrote: post #33
roca wrote: post #23

I 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…

You raise a good point, but the OP's point still stands. All we'd need is comments in header files with the extra type information encoded, and automated FFI would be possible. Not to say that would be easy... building a type system on top of a language that lacks it is anything but easy, but it's possible. TypeScript is an excellent example.

Did you just imply that we put the comments of C headers into our types?! Comments are lower than whitespace as far as the compiler should be sure.

As I'm sure you are aware https://github.com/rust-lang/rust-bindgen does basically what you want.

I'm actually quite curious where exactly rust-bindgen falls short in the eyes of the author. I'm not as familiar with the other FFI libraries the OP linked.

Re: Obvious and possible software innovations

#49

Post by pjc50 »

underwater wrote: post #8

Feels 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.

No, Visual Basic worked fine. People built an entire generation of native business apps in it. Drop a bunch of labels, buttons and textboxes, wire the list view up to the database, and away you go.

The hard problem is native vs. cross platform.

Re: Obvious and possible software innovations

#50

Post by upforgrabs »

jolux wrote: post #32
pdamoc wrote: post #18

Gerald Sussman of SICP fame was asked why they stop teaching SICP and he said that the way programming was being done changed mid 90s. It moved from programming from first principles to programming against an API. This is still the reality of most. You have to be big enough or brave enough to move back to reinventing the whole universe. In theory, any large company could use projects like Oberon and "STEPS Toward The…

Apple could absolutely do it (or Microsoft, or Google, or Amazon) but there’s no justification for it from a business perspective.

fuchsia seems like a solid attempt by goog to write a ground up os
Post reply on HN