Why was this article censored? Was it done without an explanation? I do not find one.
Obvious and possible software innovations
131–140 of 157 posts
Re: Obvious and possible software innovations
#132I 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…
> 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.
It's because you haven't read it till the end. He explains these things haven't been solved exactly because they are difficult and (he believes) unmonetizeable.
Re: Obvious and possible software innovations
#133Earlier quoted context omitted.
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…
> (OK, who broke the * for italics markup?)
You did by including a space after the asterisk ;)
The trailing one can have a space but the * leading* can't have one
Re: Obvious and possible software innovations
#134Earlier quoted context omitted.
That's a strange distinction to make. Websites are a type of GUIs. You can build some pretty complicated things without JavaScript, but if you need JS, then yes, most of them support it in some form or another, Plasmic probably being the most sophisticated.
Calling websites GUI is a bit streched. A phone can be called a computer but the computations it does are limited to data collecting. Websites also could have good UI (even GUI) but most are limited to (again) data collection and the UI is the same like the one between Ice age humans and first domesticated animals.
I think you're overcomplicating this; the meaning of these words is in the acronyms themselves. What's a UI? A user interface -- any layer that goes between the user and some machine. What's a GUI? A user interface that is graphical, or: a layer that uses graphics to go between the user and a machine. Since websites use graphics (pixels, on a screen), and they sit between the user and a computer, they are GUIs.
Re: Obvious and possible software innovations
#135There 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.…
I understand the performance criticism. But people don't have that many apps, storage is cheap and we have plenty of ram. Today a high end smartphone has 128gb of storage and 8gb of ram. Some have 512gb of storage and 12gb of ram. An actual high end desktop computer has at least 64gb of ram and enough storage to have quite a lot of Electron runtimes installed side by side.
My M1 MacBook pro with only 8gb of ram, I asked 16gb but someone did an ordering mistake, has no issues to run multiple electrons apps at the same time and storage is not something I think about.
By responsive I mean accomoding different display sizes, to have a layout that makes sense on a small laptop with a touchscreen or a 4k 32" external display.
For most usages, I will rate react much higher than Qt5, like almost everyone one in the the industry. The only Qt interface that I think is nice and up to modern standards, and that I remember is the Tesla user interface. It may be a few others because sometimes Qt makes sense, but not for desktop in my humble opinion.
Re: Obvious and possible software innovations
#136Gerald 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…
> could use projects like Oberon and "STEPS Toward The Reinvention of Programming"
Like Dart, Flutter & Fuchsia?
Re: Obvious and possible software innovations
#137Earlier quoted context omitted.
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…
I agree that static or dynamic analysis of the implementation or users of the API would let you do some interesting things here. But that is not easy and not the OP's point. The OP's point was that all you need to do is parse the prototypes and why hasn't anyone implemented that already.
Re: Obvious and possible software innovations
#138Earlier quoted context omitted.
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…
I respect you for generously steelmanning the OP's argument here but it is very clear the OP's intent is "just parse C header files and do it all automatically":
> not only could you technically parse .h files and turn them into JNI
Well, no, technically you can't do that at all.
Re: Obvious and possible software innovations
#139Front ends could be drag and drop native GUIs instead of electron apps We had Visual Basic. We had Dreamweaver. We had Microsoft FrontPage. What went wrong? Most web pages really aren't doing anything that exciting.
> Front ends could be drag and drop native GUIs instead of electron apps > We had Visual Basic. We had Dreamweaver. We had Microsoft FrontPage. What went wrong? Visual basic was only used to run macros in Office documents. And then viruses. And then MS killed it. Dreamweaver ? Hello Adobe. Frontpage ? Was broken by design. SW is only about inovations. It does not need to last. It must be new. > Most web pages really…
>Visual basic was only used to run macros in Office documents. And then viruses. And then MS killed it.
No, it got used to do a lot of things, so did Delphi.
VB6 was awesome, then they decided to abandon a good thing and went off on the stupid .NET folly.
Re: Obvious and possible software innovations
#140Earlier quoted context omitted.
Perhaps he's a generation or two older, and doesn't want to go into a lot of technical detail to back up his opinion. I think his perspective is valuable. He's seen a lot, and he's right that we could do to learn a few things from the past.
What value is an opinion if you can't back it up?
David Hilbert published a list of 23 open problems in mathematics near the turn of the 20th century, and they served to goad the mathematics community into action for the next 75 years at least (some are still unsolved, but most were solved).
Saying "this is a problem that should be solved" might betray a lack of knowledge of an existing solution, but hand-waving such an assertion away and saying "he can't back up his opinion" isn't helpful.
If he's wrong, anyone can show why by demonstrating a correct solution to the problem - and then we'll all learn something.