I hate this post.
Obvious and possible software innovations
91–100 of 157 posts
Re: Obvious and possible software innovations
#92Earlier quoted context omitted.
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 li…
Let's be honest, if you're making a webview for the mobile app it's going to be pretty different from the desktop Electron version. You're going to share many resources, yes, but there's going to be a lot of divergence.
Sure, writing your own UI components sucks, but it's not that much worse than writing a UI component for Electron. If you need to stream something from the web, QMediaPlayer works fairly well from my experience.
Also personally I consider Flutter to be native.
Re: Obvious and possible software innovations
#93Earlier quoted context omitted.
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.
When is SWIG finally going to support Generalized Whitespace Overloading in C++ 2000? It's been 23 years, 2 months, and 19 days since the technical details were published in AT&T Labs Technical Report no. 42!
Re: Obvious and possible software innovations
#94> 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. 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. There’s no excuse for this from an engineering perspective; Bezos was smart enough to know he was going to do timesharing, he was also smart enough to constrain the spaghetti into something resembling an OS. Same story with all the other cloud services. Really, they should all run like Heroku and you’d never notice they were there. You could also draw flowcharts for most of this shit and replace devops with something that looks like labview. Nobody will do that either, as innovation in core software engineering, or even learning from the past in core software engineering is basically dead.
Heh, no Bezos was not smart enough to realize he was building a horizontally scalable mainframe out of commodity parts. All he knew was that they'd driven IT costs down below what anyone in the business had seen in other companies to the point where they could drop some APIs on it and sell it. Plus google was publishing papers like GoogleFS and coming up with GMail and everyone wanted to be seen to be as smart as them. This bit in particular: "he was also smart enough to constrain the spaghetti into something resembling an OS" is "lol, no". The big pile of web APIs was his vision. Literally its called Amazon Web Services.
Re: Obvious and possible software innovations
#95Earlier quoted context omitted.
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 the…
I took his point in general to be a rant about the unwillingness to give priority and effort to things that are schleppy, but doable. An unwillingness to address the devil in the details.
The main idea being that an unwillingness to solve these problems once, generally and completely is dooming "us" to solve it partly, inefficiently and repeatedly.
I would take the detail he gives for the specific cases as incomplete. Specifically this one.
I would NOT say that the article as a whole is "clearly "we could just parse C header files and do it all automatically""
All of these should be doable. Each of these obviously has significant schleppy or technical difficulties/constraints.
For none of these does he address the actual reasons they haven't been done or suggest plans for overcoming them.
I kinda agree with him at a high-level in this case FFI _should_ be solvable.
I think for this case he's just saying "there should be _some_ way to automatically generate FFI glue code (and we should be reusing it)"
Re: Obvious and possible software innovations
#96I 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 actually tried doing the native GUI thing, but I gave up when I found out I couldn’t do that without having to reimplement something as simple as an autocomplete dropdown. Yes, the native select has something like it, but it only reacts to typing the first characters, and you can’t style the results.
I guess some would call this a feature, but the customizability of HTML makes for a lot of good things as well.
Re: Obvious and possible software innovations
#97Gerald 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.
Google sort of did it with Android and Apple with iOS and it worked out really well for them.
Re: Obvious and possible software innovations
#98Earlier quoted context omitted.
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.
> All we'd need is comments in header files with the extra type information encoded, and automated FFI would be possible. That’s SWIG. It’s something like 15 years old, possibly more. > 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. That has nothing to do with the issue at hand. You can compile haskell to c, that does not help FFI…
https://en.wikipedia.org/wiki/SWIG
>Initial release February 1996; 25 years ago
http://www.swig.org/history.html
>July, 1995. Dave develops SWIG while working in the Theoretical Physics Division at Los Alamos National Laboratory. Originally, it was conceived as an extension building tool for a customized scripting language that had been created for the Connection Machine 5.
David Beazley, the author of SWIG, is a brilliant programmer, mad scientist, and excellent presenter.
https://en.wikipedia.org/wiki/David_M._Beazley
Check out his many talks about programming, especially his epic PyCon 2014 talk on his work as an expert on a patent infringement case.
https://www.youtube.com/user/dabeazllc/videos
https://www.youtube.com/watch?v=RZ4Sn-Y7AP8
>David Beazley: Discovering Python - PyCon 2014
>So, what happens when you lock a Python programmer in a secret vault containing 1.5 TBytes of C++ source code and no internet connection? Find out as I describe how I used Python as a secret weapon of "discovery" in an epic legal battle.
>Slides can be found at: https://speakerdeck.com/pycon2014 and https://github.com/PyCon/2014-slides
Re: Obvious and possible software innovations
#99Earlier quoted context omitted.
I've never seen a web UI that couldn't be built, and built better, in an hour with an old school drag and drop gui builder. Unfortunately the web was built on markup, and markup is a terrible way to define a UI. There is really no way to make a good gui builder for html/css, so we are stuck with literally the worst possible way to build UIs today. CSS is 24 years old, and nobody has figured out a sane way to use it y…
There are a ton of effective drag and drop GUI builders for HTML/CSS: Webflow, Squarespace, Wix, and Plasmic to name a few, and that's just the current generation (see also: Dreamweaver et al.). > Even html frames and tables were better than what we are using today How? CSS and HTML can do practically everything frames could do (the only thing I can think of that doesn't apply is independent histories). There are a l…
Are those building a GUI? Or just a website? As far as I know they’re mostly about markup.
Re: Obvious and possible software innovations
#100I 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 was using SWIG 15+20 years ago to bind C/C++ to Perl and Java and it still exists.*
(OK, who broke the * for italics markup?)
I've used it. It took the entire thing you want to call and generated one giant file of munged C. That's sort of where that idea takes you.
But the author is on to something. There's a C to Rust translator. It sucks, because it works by emulating C pointer arithmetic in unsafe Rust, using its own set of primitives along the lines of "offset this pointer by this much". Now you have ugly, unsafe Rust.
What's needed is something that infers the meaning of an ambiguous function call from the code. Something that reasons like this:
Function call:
int read(char* buf, size_t n)
Is "buf" an array, or a reference to one item?
Examine C code for "read". Is it ever used in an array context, like subscripting or pointer arithmetic? Possible results are "no, definitely not an array", "yes, definitely an array", and "can't decide, code is too confusing". One would like the third case to be rare.
If it's an array, how big is it? Possible results are inferred from the highest subscript seen, as an expression. Is it an expression on some variable at the interface? If it can be determined that the length of buf is n, the function call can be changed to a Rust slice for which .len() will work.
Pointer arithmetic needs to be analyzed by symbolic execution, treating each pointer as an (array, pointer into array) pair. If the array associated with a pointer never changes during the lifetime of the pointer, tracked all the way down the call tree, then the pointer can be represented as a subscript. Subarrays passed by pointer become slices.
This won't work all the time. Sometimes you'll need hints from the user. It would be tempting to guess using something like GPT-3, doing the conversion to safe code, and seeing if it worked. Most of these things are idioms, which is how humans convert them. Translation can be wrong in two ways - subscripts going out of range and being caught, and things using too much memory because a worst case overestimated something.
All the heavy work is in figuring out the equivalent, but not identical, data representation. Once that's figured out, converting the executable code is reasonably straightforward. There's already a dumb C to Rust translator for most of that.