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.
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.
...and that nicely sums up the problem with software today.
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.
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.
Excel is a much better product than Google Sheets, but having the better product doesn't mean having the winning product.
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).
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.
- 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
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?
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.
Google Sheets ate the lower end, though; it's a bit like iOS vs Android.
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 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%.
Still room for improvement but it's not so restrictive about the common denominator.
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.
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.
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
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
Using scare quotes to mean that nobody else says something strikes me as odd, but you're probably correct.
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? :)
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.
>> 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.
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.