-
I enjoy much of Codeless Code, but very few entries seem to qualify as “koans” in any true sense. Most seem closer to fables. The AI Koans entries from the Jargon file are closer.
-
-
I see that this has been submitted before with no discussion, but I think it’s worth bringing attention to it again. The quality varies a bit, but many of the entries are insightful.
-
joshuacc
1 month ago
|
link
| on:
There’s always more work to do—but you still don’t need to work long hours
This is good advice, but even when things aren’t planned in this fashion, there is still a good chance you don’t need to work long hours. I only work more than 40 hours a week a couple of times a year, and even then I’ll generally be able to work fewer hours the following week.
The trick, in my experience, is to just make sure that you consistently sign in and out of work promptly (at 9 & 5 in my case), and that people know they can call you for a true emergency. Working someplace that’s not a startup also helps.
-
I absolutely love this blog post. Not only does it address a longstanding false dichotomy, but does so in a very interesting and entertaining way, and each step along the way was pretty clear even to someone without experience in the domains in question.
Kudos!
-
I found the analogy to manufacturing kind of amusing in light of the fact that Lean and the Toyota Production System achieved huge improvements by focusing on small batches/single piece flow instead of trying to micro-optimize the efficiency of large batches.
-
I’m not particularly thrilled with either the tone or content of this essay.
First, there’s some revisionism:The first reason that WebAssembly is different is that it’s succeeded, and those technologies did not.
The essay goes on to redefine “success” in some super-niche way and qualify it, but this is rhetorically dishonest. I might as well write in an essay that “The first reason I disagree with them is that @steveklabnik is a fascist” and then go on to explain that by that I mean a fascist who supports government control of resources and careful policing of speech…sure, under that tortured definition I am both consistent and not wrong, but you wouldn’t be faulted for observing that I’m not right either.
They were never standardized, and that matters a lot.
Flash was not built on ES3/ES4 standards.
Unfortunately, just because something is standardized and went through the wringer doesn’t mean it isn’t hot steaming garbage.
If you built an applet in one of these technologies, you didn’t really build a web application […] You lost all of the benefits of other web technologies; you lost HTML, you lost CSS, you lost the accessibility built into the web.
Most of those features didn’t exist when Java applets first came out in 1995. Most of the useful stuff that Flash was good at didn’t exist in browsers for most of the 00’s. The essay is trying to sell you on a state of history that didn’t exist in any meaningful way.
“Don’t break the web” is a very, very important rule for browser vendors.
“…unless it gets you marketshare” is the rest of the sentence that the author leaves out. Browser vendors (and hell, let’s be real here: we mean Google, Apple, Microsoft, and that’s basically it these days) break things all the time and don’t care. https://caniuse.com/ is a monument to this fact.
Then there’s seeming misunderstanding about how browser development works:These companies have significant motive to make profit, not to make the web better.
“Making profit” is how IE managed to deliver the first working version of CSS. Similarly, how they delivered a little thing called XMLHttpRequest, a small api with passing utility later adopted by every other browser manufacturer.
Google Chrome delivered lots of neat features ahead of standardization specifically so they could feed the ad machine. And Mozilla happily rode those coattails for a good long time.
I think the notion of “let’s make the web better” ultimately–intentionally or not–boils down to “let’s serve ads better”, once you look at things in context.
…and how companies work…WebAssembly is a joint venture between Mozilla, Google, Apple, Microsoft, and others. It’s not trying to push anyone’s particular platform, but instead represents the shared interests of a wide number of stakeholders, both corporate and individual.
So, two ad-driven companies, a company known specifically for locking-down platforms (and goofing around in standards and industry groups if one’s familiar with OpenGL or the development of the Cell processor), and a company who is switching to moving as much of their stuff into the cloud–where it can be taxed and leased to users without fear of reprisal. I see why they might want to support WASM.
…and how maintenance works…It’s hard enough to maintain one runtime, let alone two. And then how do you integrate them?
Runtimes don’t all need to be integrated, and we handily managed to keep the runtimes for JVM and Flash maintained for more than a decade, by letting interested parties support them.
…and how language proliferation and the Tower of Babel work…Do we really want to christen one language as the next language of the web? We already have JavaScript. Are we someday going to introduce a third language? A fourth? An agnostic approach is significantly better for longevity’s sake.
Picking one language is better for longevity’s sake. Standardization–the shibboleth touched on here and there in this essay–would suggest that we take one language and adopt and update it as needed.
Wasm, as I rallied about many a time, is likely to make frontend dev skills even less portable than they already are. It’s an opportunity to let language writers and well-meaning developers rediscover every mistake in their language and find some way of introducing it into the browser and then saddling devs with their shortcomings!
…and how security works.Wasm is missing some features of regular assembly language that can cause security vulnerabilities, like stack smashing. Wasm is memory-safe, which is huge!
And yet it directly enables malware and side-channel attacks, while it’s proponents kinda ignore the issue and forge ahead.
~
We’re all going to be stuck with the outcome of this, and folks promoting the technology for their own career advancement or aesthetics are doing so, seemingly to me, without enough care for the ramifications of what they’re pushing.
EDIT: Cleanups to soften this up a bit…my annoyance got in the way of my politeness.
EDIT: Removed many “actually”’s in various headers, since I read them in my head as “well ak-shu-alee”
-
I’m going to give you one reply, but that’s it; we have such a divergence of opinion so often that I don’t feel like we’re really going to agree, but I would like to respond to some things.
The essay goes on to redefine “success” in some super-niche way and qualify it, but this is rhetorically dishonest.
I tried to be super clear here that this is from an implementor’s perspective. Success in this context means “becoming part of the web platform.” I don’t feel that’s dishonest, it’s about being clear about exactly what I’m trying to talk about.
JVM was never standardized.
That’s a specification, not a standard.
Flash was not built on ES3/ES4 standards.
“built on” does not mean “conforms with”; ActionScript and ECMAScript are similar, but different.
Unfortunately, just because something is standardized and went through the wringer doesn’t mean it isn’t hot steaming garbage.
This is true, but that’s why I qualified what this post is about. The user’s perspective is something else entirely.
Most of those features didn’t exist when Java applets first came out in 1995.
CSS was in development at the time, and shipped in 1996, it’s true. But regardless of the start, that kept being true. They could have added support, but they did not. It’s effectively the same.
https://caniuse.com/ is a monument to this fact.
CanIUse, to me, is more about when you can adopt new features. They ship in different browsers at different times, but eventually, a lot of stuff is the same. Crossplatform web development has never been easier.
Runtimes don’t all need to be integrated, and we handily managed to keep the runtimes for JVM and Flash maintained for more than a decade, by letting interested parties support them.
Yet they still were full of vulnerabilities. This was due to the disconnect I talk about in the article. It also doesn’t address the inherent complexity in coordinating two runtimes compared to one.
enables malware
This was already possible with JS, wasm doesn’t fundamentally change things here
and side-channel attacks,
This article is clickbait nonsense. It says that this could happen, but ignores that everyone involved with WebAssembly is acutely aware of these issues, and is not moving forward until they’re addressed. Heck, before Meltdown/Spectre was announced, I was in a room with one of the main designers of WebAssembly, and someone brought up SharedArrayBuffer for some reason. He said “yeah so you shouldn’t rely on that and I can’t talk about why”. Then we all found out why.
You’re letting your disdain bias you against the facts.
while it’s proponents kinda ignore the issue and forge ahead.
TC39 is not the body that standardizes WebAssembly.
We’re all going to be stuck with the outcome of this, and folks promoting the technology for their own career advancement or aesthetics are doing so, seemingly to me, without enough care for the ramifications of what they’re pushing.
This kind of slander is why I rarely post to lobste.rs anymore. I’m out.
-
This was already possible with JS, wasm doesn’t fundamentally change things here
It makes things easier, and the general increase in performance allows more interesting and obtrusive categories of malware than we saw with JS.
Heck, before Meltdown/Spectre was announced, I was in a room with one of the main designers of WebAssembly, and someone brought up SharedArrayBuffer for some reason.
There’s no sane way to have multiple threads and shared memory primitives of which I’m aware that don’t enable timing attacks at this time. The option seems to be to remove them entirely, and the Github link shows that at least a few people are hesitant to do that.
TC39 is not the body that standardizes WebAssembly.
Thank you for the correction–I don’t know if there is a lot of bleedover between the groups. If there is, my concern remains.
This kind of slander is why I rarely post to lobste.rs anymore. I’m out.
That’s my honest opinion, slander wasn’t my intent. This pattern is being repeated everywhere in our industry. If you don’t think it applies in your case, please correct me.
-
That’s my honest opinion, slander wasn’t my intent.
Making an unsubstantiated accusation in a public forum is slander, even if you happen to believe the accusation to be true.
And to be clear, you accused promoters of wasm of self-interestedly putting career/aesthetics above the common good. You made no allowance for the idea that they might actually have decent reasons for believing and acting as they do. If they disagree with you on wasm, then they are simply a bad person.
Putting all of that behind a “it seems to me” doesn’t actually change what you are saying. If you meant something else, I strongly suggest rewording. If not, then please don’t post such attacks on Lobsters.
-
Please consider the original phrasing–there’s a reason I picked it:
We’re all going to be stuck with the outcome of this, and folks promoting the technology for their own career advancement or aesthetics are doing so, seemingly to me, without enough care for the ramifications of what they’re pushing.
I state one thing as fact: we’re stuck with the outcome of the wasm debate.
I state the rest as opinion: the set of people promoting the technology, who are doing so for their own career advancement or aesthetics, seem to be doing so without enough care for the ramifications of widespread wasm adoption it seems to me.
There is a much more direct way of slandering people if that’d been my goal.
-
-
-
-
-
-
Browser vendors (and hell, let’s be real here: we mean Google, Apple, Microsoft, and that’s basically it these days)
I’m sure you know you’re writing to a Mozilla employee. Does saying “you’re not even a real browser vendor” really help your argument?
(I’ve worked at Mozilla. Loved it, but competing against some of the largest and most well-funded corporations in the world is hard, and it can be frustrating to see what they get away with. Jabs like this pile up and demoralize you.)
-
In my haste I plain forgot to list Mozilla. One of many glaring oversights I’ve made today.
That said, my point is that there are really only 4 vendors that matter, since the vast, vast majority of browsers are powered using one of 3 or 4 engines.
-
-
-
-
I agree with the overall thesis of the article, but find the suggestion of postmodern design rather lacking. Instead of looking at anti-rational movements like postmodernism, I think it would be more profitable to consider pre-modern or non-Western design as a source to draw from.
For example:
-
Yeah, I adore post-modernism (and I wouldn’t call it anti-rational), but it really doesn’t seem to be solving the problem the author is explaining. I like Material Design a lot (disclosure: I work for Google), but I was nodding along and preparing to learn something interesting about design… up until the article basically said, use post-modernism for everything, and gave some very non-UI-like examples, with no explanation of what using post-modernism means in a UI/UX context and no justification for why post-modernism over any other choice.
I do think it’s a fascinating point that web and app design focuses very heavily on functionality, and that doing so is a choice and not necessarily the right choice for everyone. In that sense, the focus on post-modernism makes sense, because if there’s one thing post-modernism isn’t, it’s functional. But, um… Yes, the two design languages you linked would both be much more interesting choices in this context.
-
For example:
These both seem like art styles to me. How would they translate to UI design?
-
-
Unfortunately, the term full-stack is one of those terms where everyone reads into it what they want it to mean. I’ve worked with some back-end developers who were good (not great) at front-end. By most people’s usage, they are “full-stack,” but not by the usage of this article, which seems to require great skill in all areas of the stack.
I for one, will happily admit that I’m not “full-stack” because while I can work on back-end systems, I am multiple times more effective when working on the front-end.
-
I think you could reimplement it easily yourself with a small shell script and some calls to mount; but I haven’t bothered.
I don’t have the expertise to criticize the content itself, but statements like the above make me suspect that the author doesn’t know nearly as much about the problem as they think they know.
-
This reminds me of a trope in the DIY (esp. woodworking DIY) world.
First, show video of a ludicrously well equipped ‘starter shop’ (it always has a SawStop, Powermatic Bandsaw, and inexplicably some kind of niche tool that never really gets used, and a CNC router).
Next, show video of a complicated bit of joinery done using some of the specialized machines.
Finally, audio: “I used for this, but if you don’t have one, you can do the same with hand tools.”
No, asshole, no I can’t. Not in any reasonable timeframe. Usually this happens in the context of the CNC. “I CNC’d out 3 dozen parts, but you could do the same with hand tools.”
I get a strong whiff of that sort of attitude from this. It may be that the author is capable of this. It may be possible to ‘do this with hand tools’ like Shell and some calls to mount. It might even be easy! However, there is a reason docker is so popular, it’s because it’s cheap, does the job, and lets me concentrate on the things I want to concentrate on.
-
As someone who can do “docker with hand tools,” you and @joshuacc are completely correct. Linux does not have a unified “container API,” it has a bunch of little things that you can put together to make a container system. And even if you know the 7 main namespaces you need, you still have to configure the namespaces properly.
For example, it isn’t sufficient to just throw a process in its own network namespace, you’ve got to create a veth pair and put one end of that into the namespace with the process, and attach the other end to a virtual bridge interface. Then you’ve got to decide if you want to allocate an IP for the container on your network (common in kubernetes), or masquerade (NAT) on the local machine (common in single box docker). If you masquerade you must make snat and dnat iptables rules to port forward to the veth interface, and enable the
net.ipv4.ip_forward sysctl.So the “small shell script” is now also a management interface for a network router. The mount namespace is even more delightful.
-
Exactly this! One of the most egregious things about the ‘… you could do it with hand tools’ is that it is dismissive of people who really can do it with hand tools and dismissive of the folks that can do it with CNC.
In woodworking, CNC work is complicated, requires a particular set of skills and understanding, and is prone to a totally different, equally painful class of errors that hand tools are not.
Similarly, Hand tool work is complicated, requires a particular set of skills and understanding, and is prone to a totally different, equally painful class of errors that power/CNC work is not.
Both are respectable, and both are prone to be dismissive of the other, but a hand-cut, perfect half-blind dovetail drawer is amazing. Similarly, a CNC cut of 30 identical, perfect half-blind dovetail drawers is equally amazing.
The moral of this story: I can use the power tool version of containers. It’s called docker. It lets me spit out dozens of identically configured and run services in a pretty easy way.
You are capable of ‘doing it with hand tools’, and that’s pretty fucking awesome, but as you lay out, it’s not accomplishing the same thing. The OP seems to believe that building it artisinally is intrinsically ‘better’ somehow, but it’s not necessarily the case. I don’t know what OP’s background is, but I’d be willing to bet it’s not at all similar to mine. I have to manage fleets of dozens or hundreds of machines. I don’t have time to build artisanal versions of my power tools.
-
-
And then you have Paul Sellers. https://www.youtube.com/watch?v=Zuybp4y5uTA
Sometimes, doing things by hand really is faster on a small scale.
-
He’s exactly the guy I’m talking about though in my other post in this tree – he’s capable of doing that with hand tools and that’s legitimately amazing. One nice thing about Paul though is he is pretty much the opposite of the morality play from above. He has a ludicrously well-equipped shop, sure, but that’s because he’s been doing this for a thousand years and is also a wizard.
He says, “I did this with hand tools, but you can use power tools if you like.” Which is also occasionally untrue, but the sentiment is a lot better.
He also isn’t elitist. He uses the bandsaw periodically, power drillmotors, and so on. He also uses panel saws and brace-and-bit, but it’s not an affectation, he just knows both systems cold and uses whatever makes the most sense.
Paul Sellers is amazing and great and – for those people in the back just watching – go watch some Paul Sellers videos, even if you’re not a woodworker (or a wannabe like me), they’re great and he’s incredible. I like the one where he makes a joiner’s mallet a lot. Also there’s some floating around of him making a cabinet to hold his planes.
-
-
-
My reaction was “if you had to write this much to convince me that there are easier ways than Docker, then it sounds like this is why Docker has a market.”
I’m late to the Docker game - my new company uses it heavily in our infrastructure. Frankly, I was impressed at how easy it was for me to get test environments up and running with Docker.
I concede it likely has issues that need addressing but I’ve never encountered software that didn’t.
-
-
I’ve never been part of a standup that hasn’t devolved into “make yesterday sound productive” competitions/drivels. I think there are a few causes:
- Stakeholders are present so engineers are vouching for their team
- Managers are present so engineers are vouching for their raises
- Engineers are afraid to look lazy when compared to their peers
So, to make standups more productive I’d remove Stakeholders, Managers, and Engineers from the meeting.
😉
Edit: I was being playful, but I don’t think standups are useful meetings… at all. The idea that you should wait until the next day to bring up that you’re blocked seems ridiculous to me. However, if I were to run them this would be the format.
- What are you doing today?
- Is anything blocking you?
Note how there’s no “what did you do yesterday?” Talking about yesterday would be strictly forbidden. Not only does it run a high risk of turning into drivel, but everyone already attended yesterdays standup, so it’s purely redundant information.
-
everyone already attended yesterdays standup, so it’s purely redundant information.
That very much depends on team context. I’ve worked on teams where that is mostly (though not always) true. And I’ve worked on teams where what people said they were going to do ended up varying dramatically from what they actually ended up doing.
During peak season for one of my company’s sub-products, the development team supporting that product is very likely to be pulled into debugging production issues. Occasionally a team member’s expertise is urgently needed by another team. And of course, if you say more than one thing in your list of intentions, if anything takes longer than expected, then the rest of your intended actions may or may not relate.
It’s important not only to communicate what it is that you are trying to do, but also what you actually ended up doing so that if the source of change is a problem somehow, that problem can be addressed.
-
Where does it say you have to wait until next standup to bring up blockers? The ‘What did you do yesterday, today, and what are your blockers’ is just a training exercise to get novices trained to bring up blockers daily. It’s to get people into a habit if bringing them up every day. Believe it or not, some people will struggle for weeks with blockers until they bring them up, or quietly fail. This is especially true for newer people in the field.
-
I’m sorry I don’t understand what this is. What would I do with this? Is this similar to like Electron?
-
-
-
because of the way it’s designed, as described in the talk. changing that would break way too much stuff, like libs which rely on linking to C in order to function.
one cool thing about Deno is that it seems like one could make a “codepen”-style JS code pasting/collaboration service really quickly, and not have to worry about sandboxing the code execution like you normally have to do. the fact that its package management works by using URLs makes it even easier. just
import React from "https://unkpkg.com/react-0.0.1/react.js"and you’re done. no messing around with package managers, no worrying whether it’s down, no worrying about depending on “yet another package ecosystem” if you’re coming from other places like Python or Ruby.
-
-
-
joshuacc
3 months ago
|
link
| on:
YES! I Compiled 1,000,000 TypeScript files in Under 40 Seconds. This is How.
Title is bit clickbaity, but the actual content is super interesting, too. :)
-
-
caryhartline
3 months ago
|
link
| on:
A New Dark Pattern: Tricking Browsers into Making Repeated Notification Requests
It’s a good thing that Firefox now allows users to preemptively disable all future notification requests.
So what is the end goal of this type of hack? I assume the assumption is that someone will just say “yes sure fine”, but then they could easily go into their system UI(?) to disable the notifications after they leave the browser. Notifications in browsers don’t exist in iOS so I don’t know the mechanism for how Android handles this.
-
-
djsumdog
3 months ago
|
link
| on:
A New Dark Pattern: Tricking Browsers into Making Repeated Notification Requests
I really hate browser notifications. I never click yes ever. It feels like preventing browsers from going down this hole is just yet another hack. The Spammers and the CAPTCHAers are fighting a continuous war, all because of the 2% of people who actually click on SPAM.
-
-
My firefox has that in the settings somewhere:
[X] Block new requests asking to allow notifications
This will prevent any websites not listed above from requesting permission to send notifications. Blocking notifications may break some website features.
help links here: https://support.mozilla.org/en-US/kb/push-notifications-firefox?as=u&utm_source=inproduct
-
-
there always has been in Chrome and Safari and since very recently, there’s also one in Firefox. It’s the first thing I turn off whenever I configure a new browser. I can’t possibly think of anybody actually actively wanting notifications to be delivered to them.
Sure, there’s some web apps like gmail, but even there - I’d rather use a native app for this.
-
I can’t possibly think of anybody actually actively wanting notifications to be delivered to them.
Users of web-based chat software. I primarily use native apps for that, but occasionally I need to use a chat system that I don’t want to bother installing locally. And it’s nice to have a web backup for when the native app breaks. (I’m looking at you, HipChat for Windows.)
-
-
-
There is a default deny option in Chrome, takes a little digging to find though. But I agree that it’s crazy how widespread sites trying to use notification are. There’s like 1 or 2 sites that I actually want them from, but it seems like every single news site and random blog wants to be able to send notifications. And they usually do it immediately upon loading the page, before you’ve even read the article, much less clicked something about wanting to be notified of future posts or something.
-
The only time I have clicked “yes” for notifications is for forums (Discourse only at this point) that offer notifications of replies and DMs. I don’t see a need for any other websites to need to notify me.
-
-
I’m in my company office this week to pair program with my coworkers and some consultants on our new React and Node tech stack. While I’m here and have fewer family responsibilities to take care of, I’m going to work on more improvements to my personal productivity system, as well as a bit of writing on my current novel.
-
JavaScript tag?
-
“I’m thinking of a larger program of work in which an entire solution has to be designed and delivered, (more or less) complete. Such projects have distinct beginning, middle and end phases, all of which must complete successfully if the project is to succeed.”
AFAIK, that’s not really a thing to which one applies Agile.
-
Why not? My company just did this for a year-long project, and it has worked out spectacularly well. We are nearing the end of the project, and everyone is really pleased at how it has turned out and how well by-the-book Scrum[1] worked for the process.
[1] I prefer Kanban, but doing Scrum by the book is actually pretty good compared to Flaccid Scrum
-
-
-
(Warning: not an embedded guy but read embedded articles. I could be really wrong here.)
“This big push is causing a vacuum in which companies can’t find enough embedded software engineers. Instead of training new engineers, they are starting to rely on application developers, who have experience with Windows applications or mobile devices, to develop their real-time embedded software.”
I don’t know. I was looking at the surveys that Jack Ganssle posts. They seem to indicate that the current embedded developers are expected to just pick up these new skills like they did everything else. They also indicate they are picking up these skills since using C with a USB library or something on Windows/Linux isn’t nearly as hard as low-level C and assembly stuff on custom I/O they’ve been doing. I’m sure there’s many companies that are either new not knowing how to find talent or established wanting to go cheap either of whom may hire non-embedded people trying to get them to do embedded-style work with big, expensive platforms.
I think author is still overselling the draught of engineers given all the products coming out constantly indicate there’s enough to make them. Plus, many features the engineers will need are being turned into 3rd party solutions you can plug in followed by some integration work. That will help a little.
“developers used “simple” 8-bit or 16-bit architectures that a developer could master over the course of several months during a development cycle. Over the past several years, many teams have moved to more complex 32-bit architectures.”
The developers used 8-16 bit architectures for low cost, sometimes pennies or a few bucks a chip. They used them for simplicity/reliability. Embedded people tell me some of the ISA’s are easy enough for even assembly coding stuff to be productive on kinds of systems they’re used in. Others tell me the proprietary compilers can suck so bad they have to look at assembly of their C anyway to spot problems. Also, stuff like WCET analysis. The 8-16-bitters also often come with better I/O options or something per some engineers’ statements. The 32-bit cores are increasing in number displacing some 8-16 bit MCU’s market share, though. This is happening.
However, a huge chunk of embedded industry is cost sensitive. There will be for quite a while a market for 8-bitters that can add several dollars to tens of dollars of profit per unit to a company’s line. There will always be a need to program them. If anything, I’m banking on RISC-V (32-bit MCU) or J2 (SuperH) style designs with no royalties being those most likely to kill most of the market in conjunction with ARM’s MCU’s. They’re tiny, cheap, and might replace the MIPS or ARM chips in portfolios of main MCU vendors. More likely supplement. This would especially be true if more were putting the 32-bit MCU’s on cutting-edge nodes to make the processor, ROM, and RAM’s cheap as 8-bitters. We’re already seeing some of that. The final advantage on that note of 8-16 bitters is they can be cheap on old process nodes that are also cheap to develop SOC’s on, do analog better, and do RF well enough. As in, 8-16-bit market uses that to create huge variety of SoC-based solutions customized to the market’s needs since the NRE isn’t as high as 28-45nm that 32-bits might need to target. They’ve been doing that a long time.
Note to embedded or hardware people: feel free to correct anything I’m getting wrong. I’ve just been reading up on the industry a lot to understand it better for promoting open or secure hardware.
-
-
-
Yup. Jack Gannsle is always a good read. I highly recommend anyone interested in embedded systems subscribing to his Embedded Muse news letter.
Whether the Open Cores will beat ARM? Hmm. Arm has such a strangle hold on the industry it’s hard to see it happen…. on the other hand Arm has this vast pile of legacy cruft inside it now, so I don’t know what the longer term will be. (Don’t like your endianess, toggle that bit and you have another, want a hardware implemented java byte code, well there is something sort of like that available, …..)
Compilers? It’s hard to beat gcc, and that is no accident. A couple of years ago Arm committed to make gcc as performant as their own compiler. Why? Because the larger software ecosystem around gcc sold more Arms.
However, a huge chunk of embedded industry is cost sensitive.
We will always be pushed to make things faster, cheaper, mechanically smaller, longer battery life,….. If read some of what Gannsle has being writing about the ultra-low power stuff, it’s crazy.
Conversely we’re also always being push for more functionality, everybody walks around with a smartphone in their pocket.
The base expectation these days a smartphone size / UI/ functionality / price / battery life ….. which is all incredibly hard to achieve if you aren’t shipping at least a 100000 units…
So while universities crank out developers who understand machine vision, machine learning, and many other cutting-edge research areas, the question we might want to be asking is, “Where are we going to get the next generation of embedded software engineers?”
Same place we always did. The older generation were a rag tag collection of h/w engineers, software guys, old time mainframers, whoever was always ready to learn more, and more, and more…
-
This week’s Embedded Muse addresses this exact article. Jack seems to agree with my position that the article way overstates things. He says the field will be mixed between the kinds we have now and those very far from the hardware. He makes this point:
“Digi-Key current lists 72,000 distinct part numbers for MCUs. 64,000 of those have under 1MB of program memory. 30,000 have 32KB of program memory or less. The demand for small amounts of intelligent electronics, programmed at a low level, is overwhelming. I don’t see that changing for a very long time, if ever.”
The architecture, cost, etc might change. There will still be tiny MCU’s/CPU’s for those wanting lowest watts or cost. And they’ll need special types of engineers to program them. :)
-
Thanks for the inside view. Other thing about Jack is he’s also a nice guy. Always responds to emails about embedded topics or the newsletter, too.
-
-
-
I just turn my phone off / on silent / in a small lead box when I want to get on with work. Is this not a common sense solution if you find yourself becoming distracted?
-
-
On iphone (I don’t know for other platforms) you have a DND mode with “favorites” that can still notify you. I’ve been on-call several time and just setting SMS/Phone Call on first method of contact on pager duty + using this DND mode was enough for me to let my phone upside down the whole day and still be notified when I needed to be.
-
-
This is pretty much the opposite of my experience with Flow and TypeScript. Flow has been extremely slow, to the point that it is much slower than transpilation. It’s also been prone to hanging/crashing. Maybe that’s down to the fact that I’m a Windows user?
I’ve also migrated a medium sized JS project to TypeScript, and as long as you are willing to relax some of the “—strict” settings, it’s not very difficult at all. You might need to sprinkle a few
anyhere or there at first, but that’s not really a problem.One other thing I’ll point out is that TS does allow you to use pure JS with JSDoc for type annotations and avoid the transpilation step if that’s what you prefer. That’s how the Webpack source code is written.