Live data from Hacker News

Obvious and possible software innovations

scottlocklin.wordpress.com

151–157 of 157 posts

Re: Obvious and possible software innovations

#151

Earlier quoted context omitted.

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 hi…

David hilbert's list is like the opposite of this list. It was a list of pretty fundamental problems with huge implications.

The author of this list specificly states that they are problems that should be easy to work on. That's very different. Most of the ideas are ideas that have been done in the past. Some are just bad ideas, others just didn't catch on, perhaps due to chance or fashion. None of them really have compelling stories behind them.

There's millions of things in the world that could be solved. A list of some subset is boring. The "Why" is the interesting part.

Re: Obvious and possible software innovations

#152
post #144

Earlier quoted context omitted.

That person is no David Hilbert. As multiple comments says, many of the problems he talks about are already solved. And some of them were solved in the past and solutions abandoned. If you want to learn something, you will be much better off starting from a post which does not ignore existing state of the field.

I'm mostly interested in this post because the contrast he draws between AWS and z/OS deeply resonates with me. What if someone built an OS to deal with cloud-scale problems at the ground level - in the kernel? This isn't to say the likes of S3 or DynamoDB should be implemented in kernel space ( far from it). But the mishmash of services AWS does offer seems to be more about solving cloud-scale problems without imple…

Well that might be an interesting research project, AWS (especially at the beginning) is not the right party to do that. AWS's success was because it was a drop-in replacement for existing linux servers with easier management.

I do agree this is one of the more interesting ideas in the post. But its also the least satisfying because its so vauge. "Imagine AWS but less shitty and more mainfrane like" is beyond vauge.

Re: Obvious and possible software innovations

#153

Re: Point 4: I think C# Windows Forms are a great example of that (drag and drop GUI for creating GUI forms), and I wonder why no one is making things that easy in a cross-platform manner anymore!

It would take the resources of a Microsoft, with their decades of language and OS experience to create such a thing. And, Microsoft has no interest whatsoever in encouraging a cross platform desktop ecosystem.

Microsoft is working on it, it’s called MAUI: https://github.com/dotnet/maui

Re: Obvious and possible software innovations

#154
post #63

I really dislike the article, here are some reasons (referencing the numbered arguments in the article). 1. There are many such parsers. Rusts bindgen [1] is one of them, I have written a proprietary one last year. This is pretty common to do for narrow use cases, there just isn't one for "Convert a C API to Ruby".. 2. "Most VM designs I’ve seen are basically just student exercises". Seriously? Create a better on and…

Look, I agree that the article could've used a more productive tone but saying "just don't use Electron apps" is misguided. We don't have a choice. IMO it's perfectly fine to be consistently unhappy on that point and to rant about it.

You can be perfectly unhappy, sure. My point was just to go a little deeper than just rant and talk about the economics of why companies choose electron in spite of all the disadvantages it comes with.

Re: Obvious and possible software innovations

#155
post #154

Earlier quoted context omitted.

Look, I agree that the article could've used a more productive tone but saying "just don't use Electron apps" is misguided. We don't have a choice. IMO it's perfectly fine to be consistently unhappy on that point and to rant about it.

You can be perfectly unhappy, sure. My point was just to go a little deeper than just rant and talk about the economics of why companies choose electron in spite of all the disadvantages it comes with.

I agree on that but from my side the answer of "why use Electron?" is fairly obvious at this point. I could be wrong.

For a guy like myself it'd be more interesting to have the much more tricky discussion of "how can we not use Electron without spending millions on inventing a cross-platform native GUI toolkit?".

I recognize that's a personal preference, yep.

Re: Obvious and possible software innovations

#156

Earlier quoted context omitted.

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

You did not actually prove how exactly launching criticisms of the writing style over the content is not cheap. You can hate and critique the writing style all you want, but focusing on that in your HN comments is in fact the very notion of cheap commentary.

So, would you like to try again? Are you intellectually capable of providing a proper retort?

Re: Obvious and possible software innovations

#157

Earlier quoted context omitted.

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

> and by extension the author.

I love how idiots on HN are justifying blatant ad hominem attacks in their commentary as being perfectly valid.

WTF is HN becoming? Are people really getting this stupid?

Post reply on HN