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

21–30 of 157 posts

Re: Obvious and possible software innovations

#21

Post by nixpulvis »

japhib wrote: post #9

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

I don't find it whiney at all.

I do agree it's a little condescending, and that it's got a bit of a rambling flow; from semi-technical to straight bitching, all the way around to political.

Re: Obvious and possible software innovations

#22

Post by madhadron »

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 (and including the wiring, not just drag-drop) and I'll write a reasonably complex GUI w/ web tech.

Two things on this: this was Java's promise (and Swing delivered on it for the desktop). And the expectations of a web app/electron app are still lower than those of a native app.

Re: Obvious and possible software innovations

#23

Post by roca »

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 whether the function actually took ownership of it. You don't even know how many bytes of memory 'param' has to point to, because you don't know whether 'param' points to a null-terminated string or something else. Likewise you don't know how many bytes of memory the returned pointer points to, you don't know whether the caller is responsible for freeing it, and if they are you don't know how to free it. You don't know whether it's safe to call this function concurrently from multiple threads. You don't know whether 'param' or the return value are allowed to be NULL or not. And this is nearly the simplest possible example!

Re: Obvious and possible software innovations

#24

Post by the_optimist »

dogman123 wrote: post #2

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

Re: Obvious and possible software innovations

#25

Post by jay_kyburz »

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.

Re: Obvious and possible software innovations

#27

Post by nixpulvis »

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 (and including the wiring, not just drag-drop) and I'll write a reasonably complex GUI w/ web tech.

I think you've missed the point of the title.

Re: Obvious and possible software innovations

#28

Post by rzzzt »

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…

JNA looks reasonable for accessing native code from Java: https://github.com/java-native-access/jna/blob/master/www/Ge...

Re: Obvious and possible software innovations

#29

Post by jandrewrogers »

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 though they were popular at one time. I thought they were a great idea until I actually used them. It is very difficult to write scalable high-performance software on those types of systems, so many edge cases.

Re: Obvious and possible software innovations

#30

Post by annica »

I 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 would be pretty cool. I could read a single book instead of 100 books on all the myriad tools and services and frameworks offered by Oligarch Bezos. 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.”

Comedy gold.

Post reply on HN