If cheap labour is no longer possible/desirable, then near fully autonomous factories driven by next-gen AI and robotics becomes significantly more viable.
From Mozilla's point of view its probably that people might get confused between the old and new themes and wonder why all the highly customisable themes we use to have no longer work. So we have to have a new the colourways name so Mozilla can market the 'new' feature and sidestep the problem.
I don't think its about best practices, its about good design and communication. Even if we are just talking about PhD students, the majority of them are fresh graduates. They are no different than fresh grads in a company. Those grads work with experienced senior software engineers to guide them and provide design advice (not just best practices). Those engineers are often the ones writing the complex/difficult areas of code.
> RSEs should not be writing code for students doing PhD level projects in my opinion
So should a mechanical engineer PhD be designing and making all their own robot parts? Or should the shop engineer help them? The few mechanical engineer PhD's in robotics I know made a few early prototype test parts themselves with help from the shop engineer, but the shop engineer made and even helped design most of it, especially the final prototype.
> As you say, this is a great idea in principle. In reality I think that it's really difficult to make it work.
The point I'm making is that it does work and its proven to work very well (which is why the major industry labs do it). In my experience its Academia that doesn't like it. Anything which appears to take power/freedom away from scientists and gets in the road of their research is rejected. Though I think the core reason is (as other comments have mentioned), there is no incentive for Academia to make it work. The funny thing is that having a RSE working with them would actually help the scientists in the long run and allow them to focus more on the research because they wouldn't have to do everything themselves.
RSE's can and often absolutely should be involved at the PhD level. In my experience, collaboration between the scientist and engineer in the process of research iterations almost always produce better results. Each has insights the other may not, likely leading to better outcomes for the research, final product/tool and time taken.
The scientist just wants to focus on their research and once they have a barely working proof of concept, hand it over to the engineer to figure the rest out. The engineer wants a well specified design and prototype that they can lightly refactor to clean up, scale up and turn into a product/tool.
The reality is that approach makes it way harder for both, though most often harder for the engineer as they are generally at the end of the chain in Academia and have little power. For example, the code or spec from the scientist is often terrible, so the engineer needs to start from scratch and keep going back to the scientist to spec out the design as they were not involved at any stage prior. They may even find edge cases or flaws the scientist had not considered that are fundamentally problematic to turning it into a viable product/tool.
This is why the big corporate/industry research labs often have high level RSE that are involved in the research process and get their names in papers (they sometimes have PhD's themselves). They are not optimising for the scientists time, but for the companies resources
As I mentioned in my other comment, the gun related deaths halved 2 years after the gun laws [1]. Furthermore, in 1996, the gun deaths per capita were 2.84, the homicides were ~650 per capita. So of course you will barely see a difference with the homicide graph. The real difference is that there have been no mass shootings for 20 years.
So yes, it really is that simple and completely obvious.
Yep, my mistake its 25 years, not 35. Though the difference doesn't negate the point that its been decades since a gun related massacre.
That linked source is for all massacres, most of which are not gun related and have < 6 deaths. Even if you include the 2002 Monash University shootings, its still 20 years.
If you look at [1], when the Australian gun laws came into effect, a year later the per capita number of gun related deaths halved. 25 years later and its halved again and the trend continues downwards. For reference the US numbers are here [2]. What is interesting is that when comparing the number of firearm possession per capita between the US and Australia, the US has roughly 10 times more guns [3]. Based on [1] and [2] the US has roughly 10 times the number of gun related deaths per capita. The reason why Australia has historically had less problems than the US with gun violence is that even at Australia's peak, it had 5 times fewer guns [4] than the US [5] did per capita.
Interesting. When compared to places like Australia, where guns are highly regulated and barely anyone owns a gun, such that there have been no mass shootings for 35 years, the solution really is obvious.
Decoders are notoriously harder to support than encoders due to the various internal formats and encoding/decoding options. Until it supports all the different formats (a lot of effort), it will only be able to play back a few videos.
By focusing on an encoder (at least initially) you can just support a subset of features that work well for you. Then focus on making a decoder that can at least play back videos from your encoder.
More people will find it useful to have an encoder that works all the time, rather than a decoder that only works on a subset of videos.
> I get that the most direct way of learning is to make mistakes and learn from those. But there's an easier way too. Read books, talk to people, get the benefit of others experience without needing to make those same mistakes again.
> We don't go about individually discovering why modular design is a good thing, or why at certain scales microservices are a better option. We do the research, talk to others, and figure out that the general consensus is a reasonable one that we can use.
> I think we need to do a better job at explaining why something is a bad idea to junior developers. Learn to see things from their perspective, and communicate in a way that relates to their experience rather than ours.
Not everyone learns the same. Some people may learn significantly faster and/or more effectively if they are allowed to make mistakes - to see/experience the difference. I think this a good approach for simple problems. However, if the problem is highly complex and time consuming, its not as practical as the time cost to redo, as the work is too high. Thats where you do the research and reading. It requires a balance.
You misunderstand, I'm saying that if Telstra were properly separated right from the start (when the Howard government privatised it), the Rudd government could have easily gotten Telstra wholesale to do what Chorus in NZ is doing now. Most of Australia would probably have FTTP by now, or at least FTTN/HFC.
When the Liberals privatised the government owned monopoly telco (now called Tesltra), they didn't properly structurally seperate it in the first place. The government, like NZ, could have gotten the wholesale part of Telstra to start upgrading network infrastructure. If they had done it properly the first time, we wouldn't be in this mess.
Yep, and try getting the government to pay the billions required to get public transport up to standard to be able to just provide adequate transport for the majority of people in those cities.
I worked for a BLDC company in their research division for a few years and there are many things that can still be improved. At the time we were working on reducing the size of motors without sacrificing torque or efficiency. This was particularly the case for industry motors where we developing a motor half the size of an older industry standard AC motor, but with the same power and 94% efficiency.
Size is where the majority of advancements for BLDC motors will come.
Due to the publication requirements/incentives, academia greatly favours those who take on short term low risk research that will likely result in a few quick easy papers. Furthermore, due to the limited positions available in academia, generally only those who are good at this will rise up in academia.
Getting to a point where you control your own research and have financial stability for research that could span 3+ years with very little output (paper wise) is something comparatively few academics achieve. Even fewer of those who have, did so by conducting longer term research. Most academics I know are just trying to produce as many papers per year as they can and do whatever research in their field they can do, to do it.
Unless I'm mistaken, if you're using smart pointers, the memory wont be freed until the destructor has executed its code. Use after free should only be an issue if you're using raw pointers.
Whilst I agree it is hard to consistently write safe/secure code in C for increasingly more complex code bases, and that C is no longer the best tool for the job in these cases (there are better tools/languages out there), I think the author unfairly lumps modern C++ (>C++11) in with C. Modern C++ has many of the tools necessary to mitigate many of the problems C (and <C++11) can encounter.
I do think Rust is a viable replacement for C, but not a replacement for modern C++, rather an alternative - at least for the foreseeable future.
Even when only part of a system/process can be automated and it looks like the rest is too hard to automate, doesn't mean there wont be ways around it, or ways to cheat. Just look at how automation in factories has developed. Sometimes all it takes is to change the process slightly.
In the case of your delivery example, a person is not necessarily required to drop off the package. A system could be setup where you can request a delivery time frame for your package (e.g. between 7-9pm). When the autonomous delivery van arrives, it parks outside your house and notifies you of its arrival. You go down, scan your card and the van dispenses your package. The van then goes off to its next delivery.