I write embedded rust full-time and can say there's nothing that I can do in C that I can't do in rust. Sure the tools/frameworks are a lot more mature, but a combination of the PAC for register access (maybe a bit of community maintained HAL) and a framework like RTIC is pretty much all I need.
Maybe I'm missing something, but I don't understand why his comments are deemed sexist. Isn't he saying that 13 year old girls aren't as interested in computers as much as 13 year old boys? What am I missing?
This was my take too. I disagree with the opinion piece linked by the op.
My take was that he wanted more girls to be involved at a younger age in tech.
If you look upstream at hiring, If I have 20 candidates and they all graduated from either a bootcamp or a cs degree, then my pool will probably reflect that ratio.
If we want to fix the representation of people in any workforce that has a barrier to entry such as previous training. Like with Engineering and college. You have to get more representation in the engineering programs.
If you want that you have to have more applications to the engineering programs. If you want that you have to de-stigmatize engineering at a young age.
That was my take away from what he said, but maybe I'm projecting.
Because they go against the narrative the proponents (irony...) of cancel culture want to impose. Why doesn't anyone ask why 13yo girls are not interested in becoming loggers, or police or trash collectors? Why are most 13yo boys not interested in becoming ballerinas?
Sure the proponents of cancel culture try to pretend there is no such thing as human biologically encoded biases: everyone is a supposed blank slate. That's why it seems a bit stupid for people who don't share their views, why try to fix human nature (as if it were possible) when you can just live with it?
Because it isn't true. It is him inventing a cause of a problem by simply ignoring many, many womens' experiences with discrimination in STEM that starts at a young age, which is extensively documented. This is what privilege looks like: "I never experienced it so it doesn't exist."
Dude, you're missing the point. Women are actively chased out of tech. This has been going on for decades. Don't you remember a few years ago when half of the guys of 4chan doxxed and threatened to kill dozens of female gamers because those women dared to ask if games could treat women a little more fairly? I mean, its not like this is ancient history.
Can't you take some responsibility and educate yourself rather than asking me to educate you? I'm sure you taught yourself how to program by researching online, why can't you do the same thing to understand how shitty girls and women are treated in tech domains? Unless you just don't care? I don't get it. smh.
No no they aren't; there is an enormous political, academic and corporate movement to get and keep them and they certainly haven't dealt with anywhere near the general BS any nerd deals with growing up or being in tech; 90% of the time it's just complaints identical to yours;
- Complete fabrications to appear a victim.
- Complaints about things that everyone else deals with but due to equality feeling like oppression, suddenly the treatment equal to others feels oppressive.
- Complaints about consequence for doing shitty things.
Re your point about 4chan; provide the story or it's just another fabrication
I guess I'll give an opposing view of LabVIEW since I've worked on and off with LabVIEW over the past 7 years. I don't think it's too different from other text-based languages where it can be turned into a huge mess if the code is not organized properly. This is probably compounded by LabVIEW being targeted towards people who don't start with software backgrounds and don't understand best practices of software design. Using design methods and frameworks like the actor framework (comes with LabVIEW) can go pretty far to develop clean code that can rival or exceed the best examples of text-based source code.
Definitely LabVIEW has it's strong areas though. Anything to do with more complex UIs is probably not something you want to use LabVIEW for. I'd probably say LabVIEW is definitely strongest when paired with National Instrument's hardware (CompactRIO) which gives you access to data faster than you can do with any other system that I've seen. It's also super easy to develop FPGA applications which is a big plus when working with high-frequency data processing.
Overall I think it fills its niche quite well and don't think it's dissimilar to any other language where you can also make a mess of things if you don't know how to best structure the code.
Yep, LabVIEW is just a gateway drug for NI hardware. The integration with their hardware stack is top notch (as you would expect) and can go from scratch to sampling a signal _very_ quickly.
National Instruments does not make (tons of) money with LabVIEW licenses. The real dollars are in their hardware offerings, which are very good, but also very expensive.
The hardware isn't even that good. What you're really paying for is the idiot proofing (i.e., input protection) and the warranties. Which -- even speaking as someone who has designed competing hardware -- is often a good tradeoff.
Interesting. Are you talking about the cRIO line or the PXI one?
My experience with the PXI line was that it was absolutely top notch. I’ve seen some really cool things done with that. Most electrical folks I’ve worked with loved the hardware but absolutely despised the price gouging. They were constantly looking for alternatives yet NI hw remained for most things.
The cRIO line.... it’s getting better and it has improved a ton, but in the early beginnings it was extremely buggy, both hw and software.
I'm mostly referring to the analog sections of a few PXI cards I've looked at. This was in the context of "turn this benchtop prototype built with PXI into a form-factor product". I was surprised at how simple most of it is. There are a couple TI/BB highly-integrated PGA/ADCs that NI gets a lot of mileage out of.
But even if it's not as complex or interesting as, say, a Keithley electrometer, NI's execution really is top notch. Technical brilliance alone does not a product make.
I see. My experience was with medium test stands (couple of thousands of channels) in a more industrial setting, we didn’t really need high-accuracy or specialized ducers (there were maybe one or two of those and we usually wrote custom software for talking to then). Reliable, accurate enough and with strong platform support was killer for us. I don’t think anyone beats NI at that level of integration.
Based on the description in your Wikipedia link there is a relationship for sure -- but I don't see a strong connection. Here's how I see it:
An Active Object is essentially an OO encapsulation of a worker thread. It provides clients with a synchronous call interface where all results are resolved asynchronously (e.g. using futures for results). Internally, the Active Object converts client requests into asynchronous operations, enqueues the operations, and executes them on a private worker thread using object-specific dispatcher logic.
In an OO system, not all objects are required to be Active Objects. So there may be a mixture of synchronous and asynchronous execution.
In contrast, in an Actor system all communication is via asynchronous messages and there is no inherent requirement for multiple concurrent threads of execution.
Active Objects use a mechanism such as futures to return results. On the other hand, if there is a request-reply message exchange in an Actor system, both the request and the reply will be separate messages. The client would receive the result of a computation by receiving a message.
The relationship I see between Actors and Active Objects is that both require some kind of queue for dispatching operations (since Actor behaviors are never re-entrant). Active Objects convert synchronous calls into asynchronous operation requests, whereas Actors use asynchronous messages for _all_ inter-entity communication.
I agree with the GP that event loop programming is the closer OO analogue of Actors.
Prolucid | Mississauga, Ontario, Canada | Onsite/Full time | www.prolucid.ca
Prolucid specializes in embedded systems, cloud-enabled Industrial Internet of Things (IIoT), big-data, and machine learning. We provide solutions to customers from startups to large multinationals, and work in a variety of regulated markets including Energy, Medical, Manufacturing, and more.
I've actually thought about using those Decawave chips for tracking players in hockey. You could mine a wealth of analytics from this including who wins puck battles and face-offs, zone entries and exits, player acceleration and speed, how player dynamics change through a shift and through the game, etc.
Couple technical issues with this kind of system though, including position resolution (maybe Kalman filter with an IMU to improve?), determine players that are active on the ice as opposed to being on the bench (maybe position based), tracking all players and puck simultaneously, plus making the hardware small enough for placing it in the players clothing and in the puck.
Business problem would be in trying to get teams signed up to collect data. Getting data from one team would be good, but from both teams and the puck would be best. You almost need to get a league to agree to use the system. Then you have to deal with data ownership issues, CBA agreement, etc. Plus the whole barrier of people in hockey thinking this stuff is useless and unless you've #playedthegame you shouldn't be making the decisions.
There are a few companies doing something similar. Zebra technologies is using RF tracking in the NFL (they do warehouse tracking normally). A bunch of others try to do it through IR systems with cameras or video processing of broadcast video, but these methods have their own issues (occlusion, HW needs to be visible, etc.).
In any case, the wealth of data and statistics you could mine would be fascinating to say the least.
How does a company like SpaceX fit into this? They seem to promote the opposite and are seeing some pretty amazing success. Do they succeed because of or despite working long hours?
This isn't an absolute. Of course you can do "sprints" successfully. You just can't do it for very long. And we don't know and never will if one or the other problem they had might not have been prevented if the guy designing or making the part had had enough sleep - so it's always a discussion with insufficient data. After all, we've had enough research to show that a lack of sleep impacts the brain, from psychological studies to neuroscience, which now tells us that the brain is actually cleared of toxins during sleep. For the cases who still get enough sleep, well, not sure how the lack of "a live (outside work)" impacts various factors short and long term.
For my coding work I have stopped doing certain kinds of coding after evening, basically, anything that isn't "mechanic" but requires design decisions. Even if it's "urgent". Executing what I had decided earlier is okay, but decision making just doesn't work as well for me that late in the day, even if I still feel great. The next morning always seems to bring a fresh perspective.
Maybe I've seen it in the past but I don't remember it now -- what is their employee turnover rate? I imagine they have no shortage of applicants willing to put in 70 hour weeks until they burn out, just to get that name on their CV.
This sort of thing makes it hard for me to respect Elon Musk. He is, personally, doing great things, but I wonder if his overall effect on the world is negative in the long term because he's promoting some views that I find very harmful. So many people around him, who admire him, yet he feels like a one man team.
Fun fact -- I originally wrote "80 hour weeks" in my post and thought, "Nah, that's too much," and bumped it down to 70. Looks like I was way off, haha.
Maybe with a less stress, fewer hours culture they would have even more success in the long run. But how can we know that? I think we need leaders willing to take this kind of risk at their companies. Because the outcomes could really change the world.
SpaceX is not your typical company - it's a vehicle created to instantiate an idea (getting humans to Mars and beyond), and not a specialized instance of a generic Company class with a Product parameter set to Rockets. That is, people who work there are the ones who believe in the idea; for them it's more of a vocation, a life itself. Those who don't fit that bill burn out pretty quickly - hence the turnover rate.
