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

11–20 of 157 posts

Re: Obvious and possible software innovations

#11

Post by TimTheTinker »

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 think he means things like XCode's Interface Builder.

He's not massively underestimating the complexity as much as saying that huge swaths of that complexity are unnecessary, were it not for business requirements that often require us to do things the cheapest way possible (like hiring "fungible" web engineers to build an electron app instead of paying native platform engineers to build a first-class native app) -- and thus cause long-term harm.

Re: Obvious and possible software innovations

#13

Post by Zviedris »

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.

Yeah, like could start list with just solve PvPN problem :)

Re: Obvious and possible software innovations

#14

Post by RcouF1uZ4gsC »

> 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 of the pointer you are passing in or is being returned from the function? Are you allowed to pass in null for the pointer parameter?

All of these are questions that the C type system does not tell you. You have to rely on some type of documentation to figure it out. And if you get it wrong, you have a memory leak at best or a security while at worse.

Re: Obvious and possible software innovations

#15

Post by TimTheTinker »

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.

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.

Re: Obvious and possible software innovations

#16

Post by nixpulvis »

I agree with the general sentiment of this post, but like others, I think some explanations lack depth and possibly miss important active developments.

This passage made me laugh though:

> The funny thing is, the same people who absolutely insist that the Church Turing thesis means muh computer is all-powerful simulator of everything, or repeat the fantasy that AI will replace everyone’s jobs will come up with elaborate reasons why these things listed above are too hard to achieve in the corporeal world, despite most of them being solved problems from the VLSI era of computer engineering.

Re: Obvious and possible software innovations

#17

Post by nivertech »

viksit wrote: post #6
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…

Do elaborate on (3)?

1. The first step would be to simplify and unify services. It's especially relevant to AWS, which has lots of overlapping services, built by independent teams.

Just look on this flowchat ("Which AWS container service should I use?"):

https://twitter.com/forrestbrazeal/status/140063975921564057...

2. The longer term solution would be something like DarkLang, "deployless" single image system development environment. Of-course it will be opinionated. It should include all best practices by default. I.e. think 128-factor, instead of Heroku's 12-factor.

3. Another direction is cloud-native or web-services oriented programming languages.

Re: Obvious and possible software innovations

#18

Post by pdamoc »

Gerald 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 Reinvention of Programming" as an inspiration and create a full stack that runs GUIs on all platforms.

In practice this is a monumental undertaking that not even companies like Apple could do. They still reused BSD for macos and KHtml for Safari.

Re: Obvious and possible software innovations

#19

Post by speedgoose »

There 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.
Post reply on HN