it goes much further back than that, think it was xp
the issue is that it sucks, it's at least 10x slower than 7 zip, maybe more, showing lots of files/folders freezes the explorer gui on w10 and it only supports .zip (which could've been changed on w11, never used, never tried)
there was a German startup (Sono Sion) some years ago that had a very similar idea and had even prototypes [0], but they filed for insolvency 2-3 years ago. Now I think they pivoted to something more boring and practical - putting solar panels on vehicles. I hope aptera gets to production though
There’s also Lightyear. But so far the Zero (formerly One) ran into the ground after a barely existent production run, and the Two I’m not sure exists in any way.
It is interesting that 2 years later the same reviewer changes their mind a bit:
> Now, a few years after writing that review, I must return to say that as much as I hate this book, it's probably the best textbook that I have. I constantly return to it to reteach myself basic concepts or math. The problem with the text is that in order for it to be useful, you pretty much have to already understand the material. It's a dense, technical manual that, when paired with an easier to understand text such as Griffiths, grants tremendous power. Don't get me wrong, if there is a hell, I personally hope John David Jackson is burning in it right now, but I also have to tip my hat to him
on NXP K60 with FreeRTOS and lwIP IP based networking runs without problems with 256k Flash and 64k RAM. Of course it depends on the application, because the throughput is not high, but that is not the point here
I have thought about this myself. I do not think it is directly related to China. I think it is just not trendy to be an embedded developer. And the reason is that it is extremely difficult to start a hardware company (even more with the chip shortages in the last 2 years) because one needs to take care of delivering components that are rare or not available for months, to create the firmware for the board, to manufacture it and deliver it to the customer. Working from home office is often not possible, because soldering stations are needed, oscilloscopes, power supplies etc. The tools are also often not cheap, a debugger can cost 10-15$, but often for bigger projects the debuggers are 100x more expensive, the compiler could also cost a couple of thousand dollars. Then if there are bugs in the SW (there are always bugs) it is again difficult to update the software (this has improved in recent years with all the connected devices/cars etc., but it is still difficult). And as far as I know there are not that many hardware companies that have big exits.
On the other side, being a web developer does not require being in an office, buying expensive hardware and tools, nothing is physically delivered and at the end there is a chance to be part of a big tech exit. Big exits -> big salaries
> I do not think it is directly related to China. I think it is just not trendy to be an embedded developer
Not true at all. Pay has nothing to do with trendiness, but the other way around, being a webdev is trendy because of the high pay, great benefits like WFH and low bar to entry. Meanwhile embedded dev has a higher bar to entry due to the difficulty of the work, low relative pay and low flexibility in terms of WFH, making the jobs untrendy.
And no, the outsourcing of most HW related dev work to China has had a big impact in lowering embedded dev wages in the west, coupled with the fall of great electronics giants in the west. When I started uni to become an EE there was Nortel, Blackberry, Siemens, Ericsson, Nokia, Motorola, Sagem, Philips, etc. developing HW and mobile devices in Europe, or the west, and were hiring like crazy. Fast forward 6 years when I finished my Master's and most of those companies have either went bust, or have become just brand names for Chinese OEMs, or have become sweatshops for far east workforce, keeping only some of their sales and senior management in the west.
The EE market in the west has went way down in the last 10-15 years in comparison to the web dev market which went way up. The only western HW company making insane profits is Apple and semi titans like ASML, Intel, Nvidia, AMD, Quallcomm, while the Japanese, Korean and Chinese companies fighting for the rest of the scraps, and most of the European ones throwing the towel completely. The commodization of HW and FW dev has meant the commodization of dev wages as well.
After graduation, some of my colleagues went into mobile app dev (the iPhone has been out for a few years but were far away from becoming the norm) and are now making several times what I do as an embedded dev at the same level of YoE. Talk about betting on the wrong horse. I still can't stop kicking myself for choosing such a poor career path and wonder if I can still switch as most companies seem reluctant to hire a thirty-someting embedded senior to do junior web dev work usually done by a teen or twenty-something out of bootcamp.
'most companies seem reluctant to hire a thirty-someting embedded senior to do junior web dev work usually done by a teen or twenty-something out of bootcamp.'
If you are based in UK, drop me a line.
If you are an embedded developer with experience, you probably understand the difference between a linked list and an array, I am interviewing 'senior' web devs and half don't.
Many 'boring' companies like corporate accounting or whatever, need developers badly and pay maybe 70-80% of what 'fashionable' ones do. It could a good place to break in.
In my opinion age is not an issue, but lack of experience in the field is. If you want to get a good compensation in a different field, you need to gain experience there. This means either developing something in your spare time, or finding a job that is willing to let you learn on the spot (probably the pay will not be that great at first).
I work at a big tech company doing web-dev. One of my coworkers is 36 and was a marketer till he joined a boot camp three years ago. I don't think age should be an issue.
My instructor told me that the size is what matters often in real life. He was sailing a 45 foot yacht from Europe to South America (ARC race) and in the middle of the Atlantic Ocean they were very close to hitting a huge tanker. They were with sails at night, but the tanker was not willing to change course for such a small boat so around 50m before the impact the sailing boat changes course. All the time they were on the radio talking with the captain of the tanker, but they could not persuade him to change course. And for them this is a race so they always wanted to follow the optimal course, therefore they were reluctant to change their course
He may simply not be able to change course. An oil tanker at speed plots its course radii in miles, whole ones. Those things don't turn on a dime and as a pleasure boat (sailing in a race is entertainment) claiming priority over such a huge commercial vessel is just plain arrogance.
Instead of arguing, they should have used that time to make a slight adjustment. Their hubris caused them to make a last-minute change which wasted significantly more time. Races of any type are almost always subject to external factors.
(I know this is not the only presentation in the existence but it's one that I found; there's one by the author of Plover within some longer presentation about it.)
thanks, it also does not look fast to me and does not seem to improve the process the way it does for speech. Additionally I guess there is a steep learning curve so it is definitely not for everybody
considering typing time isn't even close to the most time consuming part of programming, I don't think this will be relevant to programmers apart from the programmers who want to do it for fun
While nobody can deny the fact that most of the time in programming indeed is not spent writing, how about this: you type slower than you can think.
So, when you get an idea, it's nice to be able to transfer the idea to the source code, so you can then move on the next idea or next part of the same one. You don't want to be held back by an inferior input method or a language with a lot of ceremonial about doing simple stuff. This happens in short bursts, even if the total time is quite short.
Sometime it happens so that one thinks faster than one can speak. This usually leads you to get mixed up in words.
A fast way to enter ideas is an important part of developing ergnomics.
Docstrings, writing documentation, talking to colleagues on Slack, asking questions on stackoverflow, writing mails, browsing, working in the terminal. We spend a lot of time writing. How much time could one save by e.g. doubling the speed?
Another aspect is of the working memory - will it free your brain's resources? Will allow writing at the speed of thought allow for new/more thoughts?
I think we should explore these waters, and steno is a solid choice.
Stenography is inherently language-dependent, and most existing steno "theories" (i.e. input systems) are tailored towards natural-language text; hence one would have to design a special "theory" for each programming language, and provide custom steno chords (or chord sequences) for each identifier within any given project. So it would involve a lot of work, but the benefit could also be significant since steno seems to be a lot less RSI-prone than traditional keyboard typing.
Usually the "busy work" of repeated idioms in code are best handled by snippets. Most IDEs, Emacs, and Vim have really advanced support for snippet expansion.
The actual custom typing in code is pretty small in comparison. A few var names that auto complete assists with anyway.
I'm sure there is some gains to be had with using steno on code. But I'd bet there's less a return on code than with English prose.
To balance the views, Mirabai, the person who started this project, does live transcription in vim and uses it for editing the notes as well. Ted, one of the lead developers, uses steno daily for programming. Emily, another user and plugin developer, has developed dictionaries to help with symbolic input and modifiers (e.g. ctrl+shift+x). There are plugins for changing case (camel, lower, snake etc.)
I'm not saying it's impossible, but it's just not worth learning steno if you mainly do programming. It will be complicated, require complicated chords, require you to constantly add new words and remember what you saved them as, simple chords (short cuts) like C^n turn into complicated ones. It's just not that optimized for programming.
> it's just not worth learning steno if you mainly do programming
I think this will be better answered by someone who has crossed that bridge than you simply jumping to that conclusion with no experience or data to back up your claim.
CamelCase is built in to Plover! [1] symbols work too - they might have less intuitive memorisation, but you don't use that many anyway (unless you're in APL...but that doesn't work with normal keyboards either).
You can set up Vim-like navigation e.t.c. too (e.g. [2]), for moving about in code. I haven't tried it.
I think however that the benefits of coding with Plover aren't really great enough to justify the huge struggle it would be to get proficient with it.
Switching modes requires an extra chord. Movement in your editor now takes chords with a bunch of keys instead of 2. Steno is really flexible, but when you try to shoehorn it into situations where it's not good at the average chords per character typed.
In addition to that, I’d wager few people have long bouts of thinking code faster than they can type it. The act of typing is usually the easiest part of the whole process.
