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

81–90 of 157 posts

Re: Obvious and possible software innovations

#81

Post by xfer »

There are some conflicting things, why would you do a clean OS design(this would be great and i would very much like to see some experiment with serious effort) and write it in C? You would already be throwing most of useful programs that exist today. If you no longer write it in C why would you need to parse C headers for calling "foreign" code?

The point on software not taking enough advantage of hardware is on point. I would also like the hardwares(e.g. SSDs) to expose a bit more how they work rather than have another CPU emulating spinning disks.

Re: Obvious and possible software innovations

#82

Post by l33t2328 »

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…

I’ve never heard of C function “ownership”. What does it mean?

Re: Obvious and possible software innovations

#83

Post by sparkie »

upforgrabs wrote: post #50
jolux wrote: post #32

Earlier quoted context omitted.

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

What are the advantages/disadvantages of Zircon over seL4?

I've read up a bit on seL4, but can't seem to find the rationale or design decisions behind Zircon. Not sure why Google needs to roll their own microkernel when there is a fast, secure, formally verified one they could use.

Re: Obvious and possible software innovations

#85

Post by coopsmoss »

StandardFuture wrote: post #80
approxim8ion wrote: post #53

Earlier quoted context omitted.

Author belongs to the special class of people who think sounding like a dick makes them more authoritative. All their posts are like that.

> class of people who think sounding like a dick makes them more authoritative It's a writing style. Like it or hate it. Nonetheless, criticisms of writing style are far too cheap and shallow for HN. Be better.

I disagree, I think it's a perfectly reasonable to critique someone's writing, and by extension the author.

You can't be rude and justify it by saying "it's just my management style" or "it's just my personality".

Re: Obvious and possible software innovations

#87

Post by bigiain »

JohnJamesRambo wrote: post #5

> Cloud providers should admit they’re basically mainframes and write an operating system instead of the ad-hoc collection of horse shit they foist on developers. Oh I like this one so much. I love the era and idea of the mainframe. I caught the tail end of it in college. Our research professors would send their statistics jobs over to the mainframe and get the dot matrix printouts back showing what treatments showed…

> I just love the idea of one big central computer doing all the processing.

And yet at the same time, having a super computer in my pocket is spectacularly cool!

Re: Obvious and possible software innovations

#88

Post by roca »

solresol wrote: post #69
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…

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

I don't know anything about Ada95's FFI but it can't magically answer the questions I posed. Either it requires extra information not in the prototypes, or it makes assumptions about the C code that won't always be true (and will have catastrophic consequences when they're not true), or it gives up on safe binding and offloads responsibility for handling those issues to the programmer.

Re: Obvious and possible software innovations

#89

Post by psyc »

injidup wrote: post #39
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…

I didn’t take the AI bit to be about “tik er jurbs” but rather about employers’ attitude towards developers. That would be more in keeping with the theme of the overall rant.

Re: Obvious and possible software innovations

#90

Post by pjc50 »

l33t2328 wrote: post #82
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…

I’ve never heard of C function “ownership”. What does it mean?

Pointers passed in and out have a very important property that's critical for writing secure reliable programs but is not encoded anywhere in the language, and that is lifetime and ownership.

If you pass a pointer to a function, will it free() it? Or store it somewhere where it will later free it? Can you now free it yourself safely or not?

Same applies to returned pointer values: don't free or must free?

Post reply on HN