> Were women more likely to be junior, and therefore more likely to be cut? It's almost as if NPR just wants to parrot a narrative.
That last point read like BS to me. I’m willing to bet that number includes a good chunk of tech recruiters (which tend to be female). And yeah a lot of recruiters got laid off in the last year
I thought it was something that focused on women in tech but men were allowed to join.
If the organizers don’t want men attending it they should verify peoples sex before handing out tickets.
Personally I don’t see the point of segregation. It’s not like shunning men will make women’s lives any better. Your best bet to improve things is to make the one side understand the other. You do that by socializing them.
Another thing this event shows is that men tend to be more competitive and will be more aggressive towards their goals. Like it or not companies reward that behavior
> Personally I don’t see the point of segregation. It’s not like shunning men will make women’s lives any better. Your best bet to improve things is to make the one side understand the other. You do that by socializing them.
Sorry, but this reads as pretty disconnected from reality. On the surface what you're saying sounds nice and feels like it should be true, but it's not quite that way in reality.
I recently got out of school (well, 3 years ago), and I can say with absolute certainty that women need a safe space in their early career that is free of men. The behavior of sexually frustrated men towards women in CS can be vomit-inducing (just ask ANY female CS student). There is a time and place for socialization. If you integrate every career space, watch the numbers of women in CS drop precipitously.
The video actually makes it an important point that this is not the case since C and C++ are different languages with different design philosophies. However, in the areas where they overlap, it makes sense to eliminate silly differences (like 'func()' vs 'func(void)' or '= {};' vs '= {0};').
Auto and constexpr fix specific problems that also exist in C (auto is useful in type-agnostic macros, and constexpr finally fixes the problem that a const isn't actually a constant.
One interesting tidbit (which I didn't know yet) is that the C committee requires two real-world implementations for a proposal to even be considered (with the C++ standard counting as "implementation"), while the C++ committee doesn't require an implementation. Meaning C++ users are essentially guinea pigs for the C standard ;)
Explains why C++ has become such a hot mess, while C has been mostly spared any serious f*ckups (I can only think of one: VLAs, but those have essentially been removed from the standard in C11).
VLA were not removed. VLAs are almost always better than the next best alternative:
- They are better than alloca due to proper scoping and standard compliance.
- They use less stack than regular arrays on the stack with a worst-case size (e.g. a divide-and-conquer algorithm that may need O(N^2) stack space without VLAs could potentially be written using O(N log(N)))
- VLAs can allow more accurate bounds checking than with worst-case sized arrays.
- VLAs are faster than heap allocation.
There are issues with VLAs: If the size is controlled by an attacker, then this could cause security issues. This is largely mitigated by -fstack-clash-protection which transforms this into a DOS (same as unbounded heap allocation) and you want to have stack clash protection anyway. Static analysis tools and compiler flags can also help to detect cases where the size is controlled by input from the network. Assembler for VLAs worse than for fixed size array, but this goes at the cost of less space saving. But, again, people who avoid VLAs blindly because of these issues then often use something which is worse.
Also note that most other languages except C++ also have VLAs.
They were made optional in C11, which for real-world purposes makes puts it on the same level as a compiler-specific language extension. For instance MSVC will (most likely) never support VLAs:
The difference is that if there are there, you get consistent behavior across all compilers that support them. MSVC was essentially stuck with pre-C99 for a long time. So nobody in their right mind would use it for C programming if he had a choice.
Now they are catching up. Let's see how this goes. We made variably modified types mandatory in C23. I hope we make VLAs mandatory again in the next revision.
> Also note that most other languages except C++ also have VLAs.
I don't think that's actually true.
Lots of modern languages have "pointer plus length"--they call them lots of different things but I think "slices" is a common term. But those aren't VLAs.
Some languages have variable vectors backed by a compile-time fixed-size array (See Zig: BoundedArray). But, again, not a VLA.
I'm trying very hard to think of a non-GC language that allows you to allocate a run-time length array on the stack other than C, and I'm not coming up with one.
C has variably modified types (in CS usually known as dependent types), where the length is encoded into the type. A VLA has a dependent type: char buf[n] or a pointer to a VLA has: char (*buf)[n]. This is super powerful and theoretically sound concept although not yet really exploited in C. But the bound travels with the type and you can get bounds checking at run-time:
char buf[n];
auto foo = &buf;
buf[n] = 1; // run-time bounds check possible
Pascal, Ada, Fortran, D have VLAs and certainly more languages have VLAs.
Between the fact that most modern languages don't have VLAs and that the languages you mention are most certainly not modern, your statement of: "Also note that most other languages except C++ also have VLAs." is not even close to correct.
I guess this depends on whether you count higher level languages with GC which often have some kind of automatically managed dynamic array / vector type but not necessarily call them VLAs.
I also did not say "modern" - not that this is clearly defined. If you only count Zig and Rust as modern, then those two do not have VLAs as far as I know. But this was not my main point anyway.
Most of the stuff it imported from C++ are relatively minor convenience things, not radical paradigm shifts. You make it sound like C23 started adding stuff like classes or templates.
I think it's more that unsafe/unpredictable pre-processor features are being implemented in the compiler so that more errors can be checked at compile time
It's not dumb to suggest the existence of humans might be unsustainable for the entire planet at this point, and it might be a net good if we don't take everything with us. I don't agree with it, but it's not dumb.
Where do we even fix the issue in the U.S. right now? Solar is still out of reach for a lot of people and states refuse to subsidize it. Everything is built so far apart that we need cars. We can't correct our farming practices without starving the country. It's not even nihilism, it's just that we don't have any realistic options right now.
Convince enough voting Americans that America isn't #1 at everything and can in fact learn from other nations and improve things by copying what they do.
For example, the low-end supermarket brand here in Berlin actually sells fresh fruit and vegetables, so we don't get the "food deserts" that the US suffers from (or if they do exist, nowhere near as severely): https://www.aldi-nord.de/sortiment/obst-und-gemuese.html
Man, it's going to suck when the world ends in a fiery ball of death because some americans somewhere decided "Meh, we'll never fix the problems in this country, not worth trying".
Then you misunderstand my comment. The point is not to say we shouldn't try, the point is that we need to get real about what needs to be done. If we approach everything from "How do we fix this without inconveniencing ourselves, because we're the most important thing on this planet?" then we are screwed.
Individual death is not the same as an extinction. And after doing so they wouldn't be able to spread their idea, they'd be removing themselves from any ability to intervene.
A more appropriate response that still points out their absurdity would be to ask why they aren't committing any mass murders.
Same, I never code personally as much as when I'm in a management position. When coding during the day (which I like very much), I have less side projects or they tend to languish.
Technically speaking, batteries do get lighter when discharged! But not in any useful way, and entirely unlike the situation with aeroplanes, of course.
Do they technically actually do get lighter? Since it's a solid-state battery, nothing is actually moving outside the battery (the ions move from one electrode to another, but they remain within the battery while charging/discharging) and because of law of conservation of mass, the weight should stay the same.
But I'm no battery expert, maybe someone knows better.
I think even with a 50% weight reduction for the same amount of energy, it still doesn't come close to the energy density of jet fuel.
And furthermore, there are more things to consider than just the energy itself, if we want to deploy it widely. Things like charging time, changing existing infrastructure, costs for R&D and development and finally all the regulatory approvals you'd have to go through. Of course not impossible but I think we're still really far away from making it happen.
In regards to charging time, I would think physically switching batteries to a charged one (or many) would make a lot of sense. Just a new form of the current refueling process airplanes go through now.
Most batteries have ~1C charging time (Which translates to being able to go from 0% SoC to 100% SoC in 1 hour).
For most flights, you are looking to anywhere from 1 to 2 hours to get a plane ready for the next flight. Plenty of time to plug it in and charge it up.
The bigger problem would be delivering the massive amount of juice needed to charge a plane up in that time frame. For that, maybe it would make sense to swap batteries and have some on reserve.
The problem is that airplanes cost energy to stay in the air. There’s a well-known relation that an airplane operated at best economy (most are) costs ~0.4kWh/ton-km [1]. That per ton of total mass in the sky.
So the problem is that, with current battery technology, the total weight of a battery electric plane is around 3x that of a fossil plane[2]. Taking into account typical efficiency, that means a battery plane requires more energy to move a given amount of cargo a given distance.
And that’s with using relatively ancient fossil fuel engines. Unless batteries get markedly better, you’re better off just synthesizing liquid hydrocarbon fuel from atmospheric CO2 and solar panels.
[2] I’ve seen battery conversions of a Cessna 208 and a Cessna 337. After conversion, they have roughly the same payload of a Cessna 182 and Cessna 172, respectively. The gross takeoff weight of the battery plane ends up about 2.5-3x that of the smaller fossil plane, assuming same payload and fuel to fly equivalent distance. In both instances range drops from ~800 miles to ~200.
For another example, look at the Pipistrel Velis Electro: with daytime VFR reserves, range is less than 70 miles (my estimate, because Pipistrel actually doesn’t quote a range estimate, stating that endurance for training sorties is “the appropriate parameter to quote”). A Cessna 162 has the exact same gross weight (both are LSAs), but a 38% higher rate of climb, and roughly 5x the range with same payload. Pipistrel also had to make other compromises: 162 has a 20% shorter takeoff roll and 20% lower stall speed, too.
> Would this be something that might make electric aircrafts practical?
Electric will never replace jet fuel. It simply can't compete for long haul heavy airliner flights. But we only need ~1000wh/kg (cheaply, mass produceably) for general aviation to go electric. A 50% increase from current average LiPo specific energies gets us about half way there.
