Hacker News new | ask | show | jobs
by pjc50 2350 days ago
The major problem areas are those where it's economically "best" to do the computationally inefficient thing.

The obvious example is the quick-to-build MVP, but many of the bigger problems come from platform conflicts. Because we have at least five different actively uncooperating operating system platforms, it's hard to build portable native apps - so people build electron apps instead. We also use the web browser as a competitive battleground; due to coordination problems only one programming language and UI model is possible, although another is creeping in via webassembly.

Then there's the ongoing War On Native Apps. Every platform holder would love to take the 30% cut of the profits and veto which applications can run on the platform. We're left with Windows (non-app-store) and sort of MacOS (although watch out for notarisation turning into a veto in the future). And sadly this has very real benefits in malware prevention. Systems which run arbitrary code get exploited.

Beyond that there's cryptocurrency, where finding a less-efficient algorithm is a design goal to maximise the energy wasted, in order to impose a global rate limit on "minting" virtual tokens.

8 comments

Don't forget the benefits of portability and the need to hire people as factors contributing to the use of higher level, generally less efficient languages: a few days back I read a description of C as a "hard to find skill these days".
There are plenty of people with real skills in C working in embedded. It might even be easier to find C than C++ developers.
I challenge you to find a C “boot camp.”

In fact doesn’t this point to a gap in the marketplace? Where are my “IOT ALL THE THINGS / 5G / Edge” bootcamps? Where are the “leetcode” challenges that talk about proper sampling rates for an 8-bit A/D converter, or implementing a closed loop PID in a 16-bit architecture?

I suspect that that’s what the Grandparent comment is commenting on — there’s so much talking about the former and so little talking about the latter - even if every computer engineer graduating from a ABET-certified institution is these skills.

> I challenge you to find a C “boot camp.”

C isn't a language that lends itself to bootcamp-stye learning.

With Javascript, you can get something on-screen in a few minutes, and even if you make mistakes, you will normally see something. It's a more forgiving environment.

With C, a small error prevents compilation at all, and it's going to be a relatively long time before you're ready to progress past the "printing text to the console" stage.

C is flatly harder to learn, and unless you're the kind of person who likes mental challenge, it's less rewarding than Javascript. It isn't the kind of thing you tackle because you need hirable job skills by the end of the month.

There are still some excellent C tutorials out there (for example, I think Handmade Hero's[0] intro to C is good, and Handmade Hero itself gets you to the "shiny colors on the screen" stage very quickly), but HH has a different mentality than a bootcamp. HH is about learning, exploring, breaking things, and figuring them out on the fly. A bootcamp is about gathering the minimum knowledge necessary to be productive as quickly as possible.

[0]: https://www.youtube.com/watch?v=F3ntGDm6hOs

A bootcamp is about gathering the minimum knowledge necessary to be productive as quickly as possible.

...and that nicely sums up the problem with software today.

That's a sunny view of the software of yesteryear.
That's what the market wants. Too many buyers who don't care about what's under the hood
> it's less rewarding than Javascript.

This varies with goals, attitudes, background, bias, etc. Besides, if you know a little C, you can livecode over at glslsandbox or shadertoy and be immediately rewarded.

> It isn't the kind of thing you tackle because you need hirable job skills by the end of the month.

No, not really. This also roughly says "JS doesn't necessarily require lots of experience" which is not much of a plus, as someone already pointed out.

The C "boot camp" is called K&R (plus a plain Linux development environment). Plenty of devs have gotten started with just that, and in around the same time.
The problem with K&R is that is useless for building actual, working C applications. Even being up to date with the language's specs means very little as getting every different library up and running in each platform is a fairly high barrier, much more so than other platforms.
The companion Kernighan and Pike is very good on building full Unix command line utilities. But yes, the platform learning process of getting to hello world can be remarkably hard.
Looking at the typical salaries in embedded, can't be that hard to find ...
Plenty of people make Electron apps only aiming to target a single platform it just happens to be so easy to add the others that most do it. The real problem is native platforms suck to code for or have too high a barrier of entry.
It often seems the main target is the web, then Electron steps in to provide an “app”. Slack really comes to mind here.
For that I already have a browser installed.
I just realized that this situation hasn't improved much in twenty years. But the problems are really commercial (or maybe "political") not technical.

Then there's the ongoing War On Native Apps.

I'm no prophet, but I did predict then that the browser would have eaten all the business applications space by now. It was just obvious. Colleagues objected that the web could not match rich native programs.

Well it can't, but it doesn't matter in the way your colleagues thought it would.

Excel is a much better product than Google Sheets, but having the better product doesn't mean having the winning product.

Some times, there's one feature that's so useful it justifies the lack of many others. Google Docs is a terrible word processor compared to Word or even Pages, but being able to edit a document at the same time as someone else (with full features and little friction—IIRC Pages doesn't support Track Changes while collaborating) is so useful that I end up using Google Docs anyway.
Whats most annoying to me such "onlinedness"/"cloudness" that people (myself including) associate with web apps are not really dependant on the front end being web based. You should be able to build as good collaboration etc features as easily with native apps as with web tech. In mobile the the lines are blurrier, but on desktop there feels to be division between offline native apps and online web apps, with very few bridging the gap with native online apps.
Your comment also showcases how IMO a lot of software companies don't compete on tech. They compete on UX [1].

When I first came on HN and learned about YC's motto (build something users love) this idea was reaffirmed.

[1] Google optimizes for a collaborative quick spreadsheet program (handy for consumers), and as other comments say, Microsoft focuses on pro spreadsheet use (e.g. finance).

I won't say that they compete on UX, more that they address different needs from different users groups. Some users need collaboration, others need niche math functions.
We switched from google docs to Dropbox paper. It has one very useful feature which would prevent me from moving back: tracking todos with name and date. Every day I get an email which lists all upcoming todo deadlines across all paper documents. Super convenient way to track your todos.
How is google docs a terrible word editor? Do you mean that it lacking the advanced but rarely used features of word?
Yep, WordArt...

Honestly though, I do think Word captured a really nice standard feature set. And docs does a darn fine job of matching that set one to one. The image placement and handling can be a little wonky at times (at least the last time that I used it) but that's what one gets for trying to handle it all in html/javascript/canvas? For what it does, it's a mighty fine product.

Conspicuously missing for me:

- Always-visible word count (added recently, but missing for nearly a decade)

- Custom text styles—you can modify the existing ones, but not create new ones with new names

I do believe a browser app can do pretty much the same as a native one, but I agree that the important bit is they didn't see the big picture: mostly free tech, no installation, safer, low mantainance, out-of-the-box truly client server, etc.

Actually the web now is 100X more beautiful and responsive than at that time. I mean what you can do with an intranet server, not the radioactive media monstrosities.

Not really a spreadsheet person, I can believe Excel is better than Sheets. But is web vs native the reason?

There's browser-based versions of excel and probably every other component in office. It's always clunkier in my opinion, and loses some features or other depending on what it is. The added layer of security also adds annoyances (like getting constantly kicked out after a period of inactivity) and new bugs.

To the user I'd say it's a trade-off that gains you little or nothing and loses a lot over native apps. The benefits of switching to browser and cloud based apps go to the organization you work for the and software companies selling the products.

The web is the ultimate "just write code" platform there ever was, literally everything that's not your PWA and API is handled by someone else in the chain.
Excel is still king in finance and much of other demanding cases.

Google Sheets ate the lower end, though; it's a bit like iOS vs Android.

> Excel is a much better product than Google Sheets, but having the better product doesn't mean having the winning product.

Much better product? Sheets takes literally seconds to download and install and runs on all your devices. Also it automatically syncs your data between devices and sharing data with other people is as easy as sharing a website. These are very important features in my view and makes Sheets into a better product than Excel. A power user might have different opinions, but to me writing sheet.new in my browser is just so much more convenient.

It's been possible for multiple people to edit an Excel file simultaneously for a long time. Since 2017 (at least) you can use OneDrive as the file location, so you get all those syncing and sharing benefits you mentioned. The newer Click-to-Run installer takes about 2 minutes to get the app to a usable state, and if that's just too long, there's always https://office.live.com/start/Excel.aspx
Excel also has a web client that can be downloaded in seconds and has more features than Google Sheets.
I didn't know that, pretty neat. One feature it has is that it picks my local language and I see no option to change it to English like I have everywhere else, so I still wont use it. I really dislike internationalization efforts, they are often so bad that it makes everything a lot harder to use for non-Americans than if they just got the same page as Americans.
Too many features.
Why are you comparing sheets to a desktop app when the comparable product is excel 365? (Which handily blows sheets out the water)
> this situation hasn't improved much in twenty years

It's gotten much worse. Now you have iOS, Android, Windows, Mac, wed, and Linux(?). In 2000, you had Windows. You couldn't do anything interesting on mobile, Web 2.0 (cringe) wasn't a thing, and Mac's market share was about 3%.

It's pretty weird to me to try to picture Microsoft's monopoly as a better situation than the current one?
I think the point they were trying to make is that in a world with platform monopoly, just making your app for that platform is a logical path for a developer
Thankfully not everyone is getting into Electron bandwagon.
Flutter looks promising for solving a lot of the platform conflict problems.
Except then you have to use Dart, or call into Dart from some other language. There are many people who dislike Dart or otherwise prefer to use other languages.
I really feel like Flutter would have taken off so much more if Google had just used Typescript instead of using it to push Dart.
Any multi platform framework will inevitably hit the hurdle of supporting only the common denominator. For many applications this is fine, but for the sake of consistency I hope native applications will still live for a while.
Having worked with React Native and Xamarin: wherever platform specific problems come up, there is some sort of "escape hatch" you can use to tailor to it.

Still room for improvement but it's not so restrictive about the common denominator.

Sadly the flutter team seems more focused on mobile and web than desktop.
It’s a bummer but the reasons are obvious. Mobile is the reason of Flutter’s existence, if they don’t win there there’s no win anywhere else.
Ok, but web?
Google is a web company ( at least in their heads ) and Dart was supposed to replace Javascript ( lol ), they used GWT for their projects since forever and now many use Dart and Angular - Adsense for sure and many other very important products for them ( $$$ ) so it's important they capture the Web side of things with Flutter because Google and their PMs and VPs are the most important clients in order to ensure the future of Flutter.

Please note I didn't mentioned anything technical, it's pure product management and strategy and that's one of the reasons I'm optimistic about Flutter's future.

Good point.

Honestly I seriously doubt Flutter will ever be popular for web. It recreates everything already included in browsers like DOM, CSS, text editing, etc. There is already too much bloat with modern JS apps.

Now this is horror.
Electron anecdote : I joked with a coworker that they had left their "out of office" status icon on slack in order to work in peace.

Turns out that it was already removed but slack was still displaying it.

⌘ + R (refresh page shortcut) solved it.. Electron might help devs getting something out quickly but all these layers have a cost

Client and server side state sync is a hard problem regardless of whether your app is native. A native app wouldn't automatically handle this.
Some IRC clients would change the nick of the user if the user toggles that they are AFK.
for some reason pretty much every time I have such an issue, command + r solves it, must be my luck
>Beyond that there's cryptocurrency, where finding a less-efficient algorithm is a design goal to maximise the energy wasted, in order to impose a global rate limit on "minting" virtual tokens.

I don't disagree with the gist of this, but from a your technical description verges on nonsense. I'm questioning if you're serious.

>...finding a less-efficient algorithm is a design goal...

At no point is anyone searching for an algorithm. Most mining algorithms were chosen at random or for novelty; Bitcoin uses double SHA-256, Litecoin uses scrypt, Primecoin searches for primes.

>...maximise the energy wasted...

Energy is wasted during mining in order to maximize security. The waste is a side effect.

>...in order to impose a global rate limit...

This is plain false.

>..."minting"...

It's called "mining". I wouldn't complain if this wasn't in quotes.

The whitepaper is only nine pages, but nobody seems to read it. https://bitcoin.org/bitcoin.pdf

I actually prefer "minting" as it is a more accurate name for the activity. Usually governments mint coins. No one mines a coin whole from the ground. The quotes show they know it is an odd usage. I mine cryptocurrency. I "mint" new-type coins.
>The quotes show they know it is an odd usage.

Using scare quotes to mean that nobody else says something strikes me as odd, but you're probably correct.

Imagining you were doing so, what would you do to denote an intentional odd usage? (sic) is used if the originator is incorrect.
The word "mint" really takes the meaning out of the word "mine". True though, minting is part of the economics included in mining.

Usually governments mint coins, but no government (or centralized entity) currently operates a legitimate network that matches up with the same properties as bitcoin.

I might have used an asterisk, maybe? :)

Governments need to mine or turn to mining companies to get the raw material that makes their coins. This is what you are doing with cryptocurrency. You look for the bits that make a coin valid and then the network mints the coin.
That's not true. The coins that advertise ASIC resistance have chosen algorithms which are deliberately stubborn to optimize with HW. In other words, inefficiency (=> high resource consumption) is an explicit goal.
I did forget about ASIC resistant coins. I think my general point still stands.

You're making a logical leap between intentional GPU/CPU coins and inefficiency as an explicit design goal. GPU/CPU coin developers are most likely true believers in a distributed security model. They could also own GPU farms or botnets. I highly doubt developers design cryptocurrencies while dreaming of squandering global resources.

If it's a real consequence of their actions that they're aware of, they're complicit in the continuance of that effect.
I have read the paper; unsurprisingly, it doesn't address any of the subsequent developments in the field.

>> finding a less-efficient algorithm is a design goal

The Bitcoin paper doesn't actually specify a specific algorithm at all, it just says "such as":

> To implement a distributed timestamp server on a peer-to-peer basis, we will need to use a proof of-work system similar to Adam Back's Hashcash [6], rather than newspaper or Usenet posts. The proof-of-work involves scanning for a value that when hashed, such as with SHA-256, the hash begins with a number of zero bits.

The Hashcash paper uses the term "minting".

>>...in order to impose a global rate limit..

> To compensate for increasing hardware speed and varying interest in running nodes over time, the proof-of-work difficulty is determined by a moving average targeting an average number of blocks per hour. If they're generated too fast, the difficulty increases.

ie to limit the global rate of block generation. Which is what makes it useful as a global distributed timestamp server.

>> maximise the energy wasted

> The steady addition of a constant of amount of new coins is analogous to gold miners expending resources to add gold to circulation. In our case, it is CPU time and electricity that is expended.

As everyone noticed fairly early on, like gold mining, this creates a means of expending energy to produce something which can be sold. Just as it's economically advantageous to burn down rainforest, it's economically advantageous to perform a trillion SHA operations and throw away the results of almost all of them.