The state has taken the place of the father as the primary bread-winner amongst the working class in the west. Prior to universal welfare most women would never have risked pregnancy outside a stable relationship because of the financial risks. There are no risks now, in fact there is actually an incentive single mothers get more money via state benefits that a single women with similar qualifications can earn in work.
That is incredibly naive. Most women with a stay-at-home man become resentful and see them as a drain on their resources. They rarely succeed even if the man does the child raising household chores etc. Of course there are plenty of successful cases but they're in the minority. The reason why women don't marry men who don't earn more than them is because they want a successful guy, and by that they mean one that can earn more than them.
This articles is a bit flippant. The study apparently outlines a problem in these regions both socially and economically. The articles then goes on to pick a single case in order to imply that it's actually good news for women - and by inference nothing for us to be concerned about.
This is fantastic. I have heard of a few projects like this. I'm guessing you're natively compiling the C# code. I'd love to contribute but I'd probably just get in the way. Good luck - a glimpse of the future perhaps.
Could you provide a link to heavy numerical operations - btw, ones that use native libraries don't count cause it ain't the C# implementation doing the work? As I've said there are some routines where C# performs fine but for heavy-weight modelling requiring intense arithmetic matrix/vector operations it is just too slow. What's more the benchmark for a single run does not always scale to many. The overhead becomes compounded when you're doing the same operation over and over again due to GC and cache misses.
C is a pain in the ass to do the things that C# is good at. If it works for you across the board then fine but I would stop assuming everyone else is an idiot.
Just for fun try implementing gauss jordan method in C# - it is prohibitively slow once you go beyond a dimension of 10 where you have millions of linear systems to solve. C has no problem even with much, much larger systems. As for data size - rule number one, when implementing a numerical method you always vectorise and unroll where possible. That means padding your data to a multiple that eliminates remainder loops and helps compiler exploitation of SIMD or VXA. If padding cannot be applied for a particular numerical method then use sparse or elimination methods to get the requisite multiple. In short, you control the data size, alignment and packing - the programmer determines what is best for the target platform and doesn't leave it in the hands of the run-time environment gods.
In my experience there are orders of magnitude differences between C and C# when you get down to heavyweight number crunching. I implemented a simple kriging method in C# as a demo for my colleagues it took about 2 minutes for a really modest situation with handful of controls and low resolution grid. I was actually concerned that my implementation was really crap. I migrated the same algorithm over to C and it took about 5 seconds. In fairness that was about 5 years ago but makes the point. For other things like FFTs there is only a gain of about x2 migrating to the C language. But that modest change is probably due to the fact that both the C# implementation and C implementations are using native libraries for cos and sin which is typically where the bottleneck is for any DFT implementation.
Well if you use a poor implementation or the wrong algorithm then you're going to get poorer performance in any language. However, all things being equal, you're not going to get better performance from a higher level language and you certainly cannot fine tune the implementation for a particular platform as you can with lower level code - that's a fact. Now whether it is worthwhile doing that depends on each case and how long the process takes to execute. I often prototype in higher level languages including R, Python and C#. Once I need a professional implementation or put them into commercial software I use C even if the front end is written in C#. C is just orders of magnitude faster than C#, even when the C# multithreaded, is coded in unsafe mode and optimised and C is single threaded and compiled with no optimisation.
sametmax, I think C should be taught after a short course in assembly. Then you can review each compiler you use in terms of what it is likely to do to your source code as you write it. But I agree that for most developers C is probably too low level for day-to-say work. Therefore, you could loss a lot of potential developers but I think such an approach would make for better engineers. In fact I can see the notion of any compiled language becoming an anachronism outside system programming and possibly AAA game programming.
Well I'm one of those idiots then. Currently, I'm employed to write very fast scientific and engineering software. We work almost entirely in C because it gives the performance we need (and not just because of memory management). Programming in C makes it very easy to assess what is causing performance bottlenecks as the disassembly maps tightly to the C code (typically 1:3 to 1:6 source to instruction ratio). This makes it easy to assess if the symbolic code needs changing or the compiler just isn't doing a good enough job and you may need to use intrinsics or rewrite in assembly. And I can tell you this is a massive sector employing a lot of engineers.
pj I always detect a degree of "disdain" for C in your comments. Back in the 80s everything was system programming if you wanted performant software. C replaced Pascal during the 80s because it was a better language - simple as. Today I code almost entirely in C and rarely need to use Assembly. C started to be used beyond Unix during the 80s (AmigaOS was written in C except for third party IO library written in BCPL) because it is a small and very concise language; Pascal had just too much abstraction - for example how it dealt with bitwise operations. This meant C compilers could do better jobs in terms of optimisation. This is reflected in C replacing Pascal in PC game programming in the late 1980s and early 1990s. Also a lot of Amiga games were also written in C (Cinemaware games) and Megadrive games too (Sonic Spinball, Ecco etc.). In short C is just the best HLL out there when it comes to programming systems with meager resources. As for Rust - like Go - its supporters will eventually throw in the towel. C is king of system programming.