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

31–40 of 157 posts

Re: Obvious and possible software innovations

#31

Post by sudosysgen »

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.

Re: Obvious and possible software innovations

#32

Post by jolux »

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.

Re: Obvious and possible software innovations

#33

Post by TimTheTinker »

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.

Re: Obvious and possible software innovations

#34

Post by nixpulvis »

jay_kyburz wrote: post #25
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…

>Ok, on my mark, you write a reasonably complex native GUI for the 5 common platforms oh, it has to run in a browser too so that users don't need to "install" it.

Can Qt help with this? I'm unaware of it's WASM support, but it seems like just a matter of time before they have all the GUI elements.

Re: Obvious and possible software innovations

#36

Post by roca »

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.

The OP's point is very clearly "we could just parse C header files and do it all automatically", not "we could parse C header files and a bunch of extra handwritten metadata and then do the rest automatically". The latter point is certainly more defensible but it's not the point they made, and it's much weaker ... I mean of course if you add extra metadata you can generate whatever FFI glue you need. The devil is then in the details.

Re: Obvious and possible software innovations

#37

Post by jolux »

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.

I think having to manually annotate C headers with extra type information starts to reduce the benefits of automatically generating FFI interfaces. Rust already has bindgen which goes pretty far.

Re: Obvious and possible software innovations

#38

Post by nivertech »

jandrewrogers wrote: post #29
nivertech wrote: post #4

1. Some modern PLs and frameworks are making ffi easier, without requiring writing manual wrappers, or using a code generators. I can't recall project names now, but they do exist. But yes, they're not widely used or supported. 2. BEAM (Erlang VM) has several native mechanisms to communicate with the outside world (both in-process and out-of-process). In-process ones: linked-in drivers (.so/DLL), NIFs (.so/DLL, like…

I’ve written software for a few different Single System Image systems. They are uniformly terrible in my experience because they actively hide material information about the system architecture that is critical for software performance and robustness. I wouldn’t recommend them at all — the “benefits” are greatly outweighed by the downsides in real operational environments. There is a reason they disappeared even thou…

There are two different things called Single System Image systems:

1. LISP machines, Smalltalk dev environments, etc. A modern example would be the DarkLang.

2. Distributed OS with process migration like MOSIX - https://en.wikipedia.org/wiki/Single_system_image

The (1) are a good direction, but they're usually not distributed. I guess you're talking about (2) which was never properly implemented, or maybe they were problematic by design.

BTW, what do you think about Inferno and Plan9? They still have hobbyist communities around them, and some of their ideas influenced current mainstream SW like 9P protocol and GoLang channels.

Re: Obvious and possible software innovations

#39

Post by injidup »

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…

My thoughts exactly. For somebody complaining that these tools don't exist because people are too lazy or whatever he himself is too lazy to do a quick google search to see that these tools do exist. I was using SWIG (http://www.swig.org/) 15+20 years ago to bind C/C++ to Perl and Java and it still exists. However your point above stands in that you have to annotate the headers with enough information about memory ownership to make it work.

The tone of the article also goes mad bigot when he starts whining about (AI) ( Aliens and immigrants ) taking our jobs for less money.

Re: Obvious and possible software innovations

#40

Post by drewcoo »

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.

"The reality is they’re all quite possible, but nobody makes money doing them."

The fact that he thinks they would take money implies that he believes they would be complex. Simple problems shouldn't cost much to fix.

Post reply on HN