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

71–80 of 157 posts

Re: Obvious and possible software innovations

#71

Post by CheezeIt »

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 can perfectly well make a tool that emits incomplete JS API’s with some human interaction to specify details of ownership and object representation.

In you could reuse much of it for multiple target languages.

In fact, you can also make FFI wrappers automatically, and handle the memory safety with wrappers on the JS side.

Re: Obvious and possible software innovations

#72

Post by ironmagma »

jacobsenscott wrote: post #59
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.

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 lot of different technologies at your disposal -- grid, which is probably the most intuitive; flex box; or just `position: fixed` divs.

Re: Obvious and possible software innovations

#73

Post by la_fayette »

jacobsenscott wrote: post #59
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.

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…

Is a gui tool really faster or better then directly writing the code? It is like using a cli vs using a gui... propably a hybrid approach would be best...

Re: Obvious and possible software innovations

#74

Post by bigiain »

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.

So the answer is _Electron?_

I think way to many people massively underestimate the complexity they add to a problem when their solution involves Electron, React, and npm…

I’m less convinced than most commenters here that he’s underestimating the difficulty of some of what he proposes, he ends with:

“ The reality is they’re all quite possible, but nobody makes money doing them. Engineers are a defeated tribe; it’s cheaper to hire an “AI” (Alien or Immigrant) slave to write the terraform or electron front end rather than paying clever engineers well enough to build themselves useful tooling to make them more productive and the world a better place. ”

Amidst his snark (which I’ll acknowledge will put some readers off) and some borderline probable racist dog whistling (which certainly put me off a bit), he is totally acknowledging that these ideas require smart engineers with budgets and mandates to spend the time making them come true. He’s not suggesting the 12 week boot camp front end engineers should be parsing c header files and inspecting deeper I to he c code to discover the stuff you need to use those to auto generate interfaces for other languages. But surely some of the senior AWS engineers should be spending their time investigation his ideas about ec2 and cloud and OSes?

Re: Obvious and possible software innovations

#75

Post by vzaliva »

"Pretty much all compilers and interpreters think computers are a PDP-11 stack machine" shows that authour have no idea how modern compilers work. A ton of low-level optimizations and code generation are utilizing intrinsic knowledge of details of underlying computer architecture.

Re: Obvious and possible software innovations

#76

Post by carapace »

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.

Delphi was pretty awesome.

https://en.wikipedia.org/wiki/Delphi_(software)

Re: Obvious and possible software innovations

#77

Post by _ph_ »

RcouF1uZ4gsC wrote: post #14

> Automated FFI parsers. In 2021 I should be able to point any interpreted language at a C include file and have all the functions described in it turned into reasonably safe FFIed function calls, The big issue with doing this is that C does not have enough of a type system to exactly specify the interface. Is that char pointer, a null terminated string, or is it a pointer to an untyped buffer? What is the ownership…

I think this points to the real answer: libraries should be defined by something else than the C headers we are using now. All automated solutions or parsing C headers require a C compiler present and as you write, there is a lot left unspecified.

Re: Obvious and possible software innovations

#78

Post by strken »

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…

As someone who found an old I-94 in his wallet last week and spent a while as an alien, I try to be sympathetic to those sort of rants. It is genuinely frustrating when employers solve problems by finding a cheaper labour force instead of automating an unnecessary process or fixing the underlying technical issue.

A company I once worked for that will remain nameless paid an entire team of people in the Philippines to read global weather reports and respond to them instead of integrating with the relevant APIs, solely because it would have been a higher upfront cost to get expensive US-based engineers to do the work, and I found it infuriating: partly because the time of the two groups was valued so differently, but also because it was just so inelegant and pointless.

Re: Obvious and possible software innovations

#80

Post by StandardFuture »

approxim8ion wrote: post #53
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.

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.

Post reply on HN