Sure, but the vast vast majority of C libraries have the same pattern as memcpy, strncpy, and so on where there's a paramter, then a size_t..
The fact I can make a typedef of a pointer and associated size_t is not much comfort when I'm dealing with dozens of external functions that are not so thoughtfully constructed.
I was thinking about the little pervasive choices adding up in aggregate. In python development, dict is so frequently the first choice of any data structure because it's generally very flexible and requires little thought. In C a struct is about as easy as using a dict in python, but massively better, and it can add up for good or for ill very quickly. It's not as flexible, but the majority of the time I see dict, the members are actually well defined and the flexibility is not really needed.
Just wanted to mention this, as folks generally 100% blame the runtime for a reputation of slowness, when language design empowering laziness is a significant contributor (and often worth it for the sake of developer time).
It was true then, and things have mutated a tad since then...
One the barrier to entry is even lower, and it is much easier for skilled programmers to provide API to higher level languages, whereas back then, assembly and C could interoperate, but not so much for enabling other languages.
Another is the C/assembly situation has flipped for most mainstream architectures. C compilers now generate much better assembly than 99% of developers, with all sorts of varying processor capabilities exploited in interesting ways. Ways that are massively more tedious to branch and execute on manually, even assuming you invest the effort to keep track of the processor features that are new and evolving.
While I have not made mistakes with pointers (so far), I will say that it is tedious to constantly be passing around the max size parameter to every little function because that's the only way for a C function to safely deal with pointer data.
Of course on the other hand, when I have reason to use C, it is refreshing and keeps me more aware of the limitations of the machine at all times. The coddling of other languages makes me forget and do slow algorithms out of laziness.
As a python developer, I'm totally there with you. I also see how it happens.
Currently all my projects I mandate to be compatible with python 2.6, 2.7 and 3.6 because I have a significant userbase still doing supported, but old enterise distros and I want them to be comfortable with the fact that it's mostly running from the OS provided runtime. *repeatedly* a developer comes along and say "why should we support old language runtimes? just make the users deal" Of course then I point to the large number of CVEs we'd suddenly be resposible for, in addition to how broken some of their suggestions would leave the customers python environments on top of how non-python developers view shenanigans like requiring your own python when a seemingly usable one is right there on the filesystem.
Then we get to pypi. We incur a lot of testing if a package *must* use PyPI content, and then package it as rpm and/or.deb if and only if distribution does not have it, and test with and without popular third party repoes (like epel, centosplus, etc. )Developers want to pull in a big pypi package over the most trivial of things. Suddenly we find a package in EPEL that isn't the same as the one in Ubunutu repoes and they have different API (because python developers tend to not give a crap about stable APIs either). So our code adapts to use the different API generations that may come about due to those sorts of differences.
Python is more accessible so you get more developers willing to work on it. The problem is that that large base of developers is not anywhere near as disciplined or caring about their userbase as would be ideal.
A case can be made for having canned functions that are performance sensitive in C, and then providing a pyhton API or similar to orchestrate. In scientific computing, there are a lot of folks who know htier science, but aren't that good at programming. For those the ability to describe their particular variant of a problem in a language like python, and have the complex computation execute according to those paramters inside a C library is valuable (see numpy).
It takes much longer to write all but the most trivial stuff in C. Languages like Python let you be exceedingly lazy. However like pretty much all managed runtimes, it is slow and inefficient, and even within the realm of managed runtimes, CPython isn't a particulalry fast or robust one.
Also a language that lets the programmer be lazy is one that leads to poor performance decisions. In C, if it is hard for the computer, you are made to realize it is hard because it's more work to program. In C, if something is an operator (like +/-/[]/etc) it's a fairly deterministic handful of assembly instructions (C++ does not have that characteristic, what with operator overrides and such of course). In Python, that could be simple operators, or it could be some mallocs and several memcpys, who knows. You want to use a hash? In C you are going to use moderately tedious function calls because hashes are an expensive choice compared to when you can get away with an array or struct. In Python? Sure, go to town, hash everything. You want to mix and match integers and strings in an array? In C, yeah, you know that's a stupid idea because it's hard to do. In Python, not a single thought required so people do it. Such code cannot be optimized by any language implementation.
Of course, the above doesn't matter much of the time because the difference in good and bad CPU performance is orders of magnitude smaller than the network IO delays that many applications are contending with, so the "let the programmer be lazy and produce crappy code" doesn't matter since a developer can just crank though the code they want to do without a thought and that's sometime totally worth it,.
Also talking about a language where there is threading, but made utterly useless by the GIL. The answer of course was "well you don't need threads anyway, other methods give the appearance of similar concurrency when I/O bound and are harder to screw up" (which is frequently true for many applications, but no comfort to the subset for which that is not true.
I suppose the question then becomes where do you find a more diverse, yet vaguely coherent collection of knowledge? I can't think of any knowledge base with more than 1,3000 contributors.
Here the raw number is a bit more informative than the percentage. In any very large open creative endeavor, there will be a massive number of people making a small handful of trivial edits to say they did and/or see if they can or because they notice one little thing in a very isolated incident. Such a large volume of trivial changes will bloat the total contributor list to unreasonable levels and distort percentages.
Similarly, take any big github hosted project. One I looked at had 3000 contributors, which seems incredible. But then look at the contributor graph, and it's clear there's a sharp dropoff after the first 6 or so and you get to moderately trivial volumes of commits and code well before you get up to 100. It does speak to popularity but it does not mean you have a 3,000 developer team suddenly working significantly on it. It also doesn't diminish the effort of the 1% of the developers that are still more numerous than most commercial software development teams working on the same sort of porject.
It is a very real phenomenon to use a fake door to door salesman to case the interior of a house. They'd much rather know for sure rather than guess based on outside appearances.
The deterrent value of the amazon camera should be low, since it is only *supposed* to turn on when a package delivery scan happens. They also don't look at all subtle, so a visual look to see where the cameras are would let you know pretty quickly where not to stand.
This is the solution that seems a lot better, and could even be totally offline and even electronic free.
A package drop that can take packages but not easily let people get at packages previously dropped without a key is a very well known mechanical design.
Not quite as good is still a fair assessment, though a bit complicated.
Intel has insisted on less scalable designs to avoid some dramatic latency penalties.
AMD has gotten bigger core count by going to a more scalable design, albeit with cross-complex latency penalties, which make things complicated.
Ignoring that, the AMD core isn't *quite* as good single threaded performance per watt or performance per clock, but has more cores to make up for it in the price point.
Things get more complex as you go to Epyc. Intel's offering starts to have offerings that have multiple memory controllers on a package, but still a very fast communication channel to use it. Epyc has more memory channels and PCIe lanes per socket, however they get divided up in somewhat limiting ways for memory performance and fast IO. This makes it of course very appealing for internet traffic (where the latency penalties of the design are a rounding error) and for bulk PCIe storage (where you are still *way* better than SATA or SAS). It is appealing for running many small VMs that don't mind single channel performance, but less so for big ones. Also Epyc is going up against Skylake-X, which has AVX-512 and as such has overwhelming floating point performance for workloads that can use it.
Basically, back in the Netburst days, it was a slam dunk for AMD technology. Intel did netburst and IA-64 when AMD stuck with a sane design, got hyper-transport and AMD64, basically advantaged in every single way except software ecosystem. Intel got smarter and then AMD went down Bulldozer path.
AMD versus Intel is now about the same as it was in the K6 generation, AMD good enough and as such much more cost effective, but Intel still edges them out per core and the pressure has thankfully made them move and deliver Coffee Lake.
Well also, financially the Macs are but a blip compared to the iPhone sales. Even iPads haven't seen consistent investment compared to their iPhones in recent history (a reasonable reaction to iPad sales trends).
In the wider market, Tablet form factor has in general tanked relative to the traditional laptop form factor. The 'two in one' form factor has a very vocal fanbase and logically would *seem* like the best of both worlds, but even there traditional laptops have higher sales (lower prices drive, though additionally the hinge of a normal laptop is hard to beat if you don't care about tablet usage so much).
If you are standing up some trivial web application and call it your 'software project', then maybe you are overthinking it to have a lot of people in different roles. Of course if your web application is more involved or more severe, then you need testing from a separate perspective.
If you are writing some particularly custom software for a particular market, then you should probably have a pool of testers that may not know how to program, but they are probably more in tune with your target userbase. I once worked in a copmany doing CAD/CAM software, and the software developers roughly knew what to do, but we hired mechanical engineers to do testing because they would call us on UI BS or make suggestions that are relevant to users.
Standard to identify devices and their vendors and automatically filter network access depending on vendor and vitality of vendor. If a vendor of your IoT device goes away, then no longer allow the device to reach out to the non-existant servers. If vendor is still around, limit connectivity based on addresses that would be relevant to said vendor.
This is of course a terrible sort of thing, but the IoT devices and vendors are themselves already terrible and limited, so in that context, it's a matter of picking the lesser of the evils, and these devices security problems can ruin the experience of everyone, not just those who opt into the silly things.
It really depends on how you measure 'productive'.
Certainly, some times it's nice to be a bit more out of reach to chase certain things.
However, when I get a better feeling for how my software is being used, it improves my work.
Also, helping others to succeed sometimes is more effective than succeeding yourself.
And finally, everyone feels more productive if they do what they want, but sometimes your view of your work and other's view of your work may disagree.
I know, you can leave a chat window open, I know you can have voice calls and screen sharing and video calls (though that last one has never added anything).
Ultimately, however, casual interaction in person is extremely valuable. A large percentage of things I address are things I overhear that folks wouldn't have thought to ask me about. Or else something that someone is comfortable bringing up face to face, but when I'm not there, they are more afraid of 'wasting my time' because they have no way to judge whether I'm available or not and they don't want to be rude by asking a 'silly question' when I could be overwhelmed with serious stuff.
We are just wired to communicate better face to face sometimes.
Actually the 180k is a Volt, and yes it has been driven *way* more than an average car of its age, and while yes it is technically a hybrid, for this person it spends most of it's life pure electric, and as such can illustrate the improved value compared to ICE vehicles.
Note that I know Volt and Leaf owners, all of them have a similarly positive experience (battery life strong after 180k miles, regenerative breaking making the brakes last a long time, and no mechanical issues with the motors to speak of).
So if it should come to pass that the financials tank Tesla, *hopefully* other vendors shall provide.
My biggest worry is so much of the world pinning all their electric vehicle viewpoint on Tesla, and if it fails at executing on the more mundane facets of running a large automotive company discouraging the rest of the market.
None of the explanations are 'good' for microsoft.
1) It's locked down and fails to notify the user. Means either edge is blocking it badly or their javascript is terrible at handling error codes. The problem is I have a hard time imagining what sort of group policy would lock edge down so much that it would fail what they were doing, and yet work on *other* parts of their application. 2) Their javascript has a problem with the edge runtime, which means either edge sucks, or their javascript sucks and/or they hate edge themselves 3) Their javascript/server struggles with a 'well-used' browser that accumulates stray session cookies and DOM storage. This is probably the most likely scenario, given a long lived browser and a domain like 'microsoft.com'. This happens all the time in web development land, and is probably the *least* specifically microsoft being bad scenario.
Slashdot Mirror
Sure, but the vast vast majority of C libraries have the same pattern as memcpy, strncpy, and so on where there's a paramter, then a size_t..
The fact I can make a typedef of a pointer and associated size_t is not much comfort when I'm dealing with dozens of external functions that are not so thoughtfully constructed.
I was thinking about the little pervasive choices adding up in aggregate. In python development, dict is so frequently the first choice of any data structure because it's generally very flexible and requires little thought. In C a struct is about as easy as using a dict in python, but massively better, and it can add up for good or for ill very quickly. It's not as flexible, but the majority of the time I see dict, the members are actually well defined and the flexibility is not really needed.
Just wanted to mention this, as folks generally 100% blame the runtime for a reputation of slowness, when language design empowering laziness is a significant contributor (and often worth it for the sake of developer time).
It was true then, and things have mutated a tad since then...
One the barrier to entry is even lower, and it is much easier for skilled programmers to provide API to higher level languages, whereas back then, assembly and C could interoperate, but not so much for enabling other languages.
Another is the C/assembly situation has flipped for most mainstream architectures. C compilers now generate much better assembly than 99% of developers, with all sorts of varying processor capabilities exploited in interesting ways. Ways that are massively more tedious to branch and execute on manually, even assuming you invest the effort to keep track of the processor features that are new and evolving.
While I have not made mistakes with pointers (so far), I will say that it is tedious to constantly be passing around the max size parameter to every little function because that's the only way for a C function to safely deal with pointer data.
Of course on the other hand, when I have reason to use C, it is refreshing and keeps me more aware of the limitations of the machine at all times. The coddling of other languages makes me forget and do slow algorithms out of laziness.
As a python developer, I'm totally there with you. I also see how it happens.
Currently all my projects I mandate to be compatible with python 2.6, 2.7 and 3.6 because I have a significant userbase still doing supported, but old enterise distros and I want them to be comfortable with the fact that it's mostly running from the OS provided runtime. *repeatedly* a developer comes along and say "why should we support old language runtimes? just make the users deal" Of course then I point to the large number of CVEs we'd suddenly be resposible for, in addition to how broken some of their suggestions would leave the customers python environments on top of how non-python developers view shenanigans like requiring your own python when a seemingly usable one is right there on the filesystem.
Then we get to pypi. We incur a lot of testing if a package *must* use PyPI content, and then package it as rpm and/or .deb if and only if distribution does not have it, and test with and without popular third party repoes (like epel, centosplus, etc. )Developers want to pull in a big pypi package over the most trivial of things. Suddenly we find a package in EPEL that isn't the same as the one in Ubunutu repoes and they have different API (because python developers tend to not give a crap about stable APIs either). So our code adapts to use the different API generations that may come about due to those sorts of differences.
Python is more accessible so you get more developers willing to work on it. The problem is that that large base of developers is not anywhere near as disciplined or caring about their userbase as would be ideal.
A case can be made for having canned functions that are performance sensitive in C, and then providing a pyhton API or similar to orchestrate. In scientific computing, there are a lot of folks who know htier science, but aren't that good at programming. For those the ability to describe their particular variant of a problem in a language like python, and have the complex computation execute according to those paramters inside a C library is valuable (see numpy).
Python is a mixed bag.
It takes much longer to write all but the most trivial stuff in C. Languages like Python let you be exceedingly lazy. However like pretty much all managed runtimes, it is slow and inefficient, and even within the realm of managed runtimes, CPython isn't a particulalry fast or robust one.
Also a language that lets the programmer be lazy is one that leads to poor performance decisions. In C, if it is hard for the computer, you are made to realize it is hard because it's more work to program. In C, if something is an operator (like +/-/[]/etc) it's a fairly deterministic handful of assembly instructions (C++ does not have that characteristic, what with operator overrides and such of course). In Python, that could be simple operators, or it could be some mallocs and several memcpys, who knows. You want to use a hash? In C you are going to use moderately tedious function calls because hashes are an expensive choice compared to when you can get away with an array or struct. In Python? Sure, go to town, hash everything. You want to mix and match integers and strings in an array? In C, yeah, you know that's a stupid idea because it's hard to do. In Python, not a single thought required so people do it. Such code cannot be optimized by any language implementation.
Of course, the above doesn't matter much of the time because the difference in good and bad CPU performance is orders of magnitude smaller than the network IO delays that many applications are contending with, so the "let the programmer be lazy and produce crappy code" doesn't matter since a developer can just crank though the code they want to do without a thought and that's sometime totally worth it,.
Also talking about a language where there is threading, but made utterly useless by the GIL. The answer of course was "well you don't need threads anyway, other methods give the appearance of similar concurrency when I/O bound and are harder to screw up" (which is frequently true for many applications, but no comfort to the subset for which that is not true.
I don't think they generally have 1,300 contirbutors on the payroll.
I suppose the question then becomes where do you find a more diverse, yet vaguely coherent collection of knowledge? I can't think of any knowledge base with more than 1,3000 contributors.
Here the raw number is a bit more informative than the percentage. In any very large open creative endeavor, there will be a massive number of people making a small handful of trivial edits to say they did and/or see if they can or because they notice one little thing in a very isolated incident. Such a large volume of trivial changes will bloat the total contributor list to unreasonable levels and distort percentages.
Similarly, take any big github hosted project. One I looked at had 3000 contributors, which seems incredible. But then look at the contributor graph, and it's clear there's a sharp dropoff after the first 6 or so and you get to moderately trivial volumes of commits and code well before you get up to 100. It does speak to popularity but it does not mean you have a 3,000 developer team suddenly working significantly on it. It also doesn't diminish the effort of the 1% of the developers that are still more numerous than most commercial software development teams working on the same sort of porject.
Look's like Belgium is being attacked by aliens when I looked.
They will just break out a battering ram. They won't bother going through all the trouble of going through Amazon once they have warrant in hand.
Besides the other things, I personally don't like the thought that I'm sitting at home and my door just opens when the delivery person gets there.
Delivery folks won't wait for a door knock or bell to be answered, they need to get through their route fast.
It is a very real phenomenon to use a fake door to door salesman to case the interior of a house. They'd much rather know for sure rather than guess based on outside appearances.
The deterrent value of the amazon camera should be low, since it is only *supposed* to turn on when a package delivery scan happens. They also don't look at all subtle, so a visual look to see where the cameras are would let you know pretty quickly where not to stand.
This is the solution that seems a lot better, and could even be totally offline and even electronic free.
A package drop that can take packages but not easily let people get at packages previously dropped without a key is a very well known mechanical design.
Not quite as good is still a fair assessment, though a bit complicated.
Intel has insisted on less scalable designs to avoid some dramatic latency penalties.
AMD has gotten bigger core count by going to a more scalable design, albeit with cross-complex latency penalties, which make things complicated.
Ignoring that, the AMD core isn't *quite* as good single threaded performance per watt or performance per clock, but has more cores to make up for it in the price point.
Things get more complex as you go to Epyc. Intel's offering starts to have offerings that have multiple memory controllers on a package, but still a very fast communication channel to use it. Epyc has more memory channels and PCIe lanes per socket, however they get divided up in somewhat limiting ways for memory performance and fast IO. This makes it of course very appealing for internet traffic (where the latency penalties of the design are a rounding error) and for bulk PCIe storage (where you are still *way* better than SATA or SAS). It is appealing for running many small VMs that don't mind single channel performance, but less so for big ones. Also Epyc is going up against Skylake-X, which has AVX-512 and as such has overwhelming floating point performance for workloads that can use it.
Basically, back in the Netburst days, it was a slam dunk for AMD technology. Intel did netburst and IA-64 when AMD stuck with a sane design, got hyper-transport and AMD64, basically advantaged in every single way except software ecosystem. Intel got smarter and then AMD went down Bulldozer path.
AMD versus Intel is now about the same as it was in the K6 generation, AMD good enough and as such much more cost effective, but Intel still edges them out per core and the pressure has thankfully made them move and deliver Coffee Lake.
Well also, financially the Macs are but a blip compared to the iPhone sales. Even iPads haven't seen consistent investment compared to their iPhones in recent history (a reasonable reaction to iPad sales trends).
In the wider market, Tablet form factor has in general tanked relative to the traditional laptop form factor. The 'two in one' form factor has a very vocal fanbase and logically would *seem* like the best of both worlds, but even there traditional laptops have higher sales (lower prices drive, though additionally the hinge of a normal laptop is hard to beat if you don't care about tablet usage so much).
If you are standing up some trivial web application and call it your 'software project', then maybe you are overthinking it to have a lot of people in different roles. Of course if your web application is more involved or more severe, then you need testing from a separate perspective.
If you are writing some particularly custom software for a particular market, then you should probably have a pool of testers that may not know how to program, but they are probably more in tune with your target userbase. I once worked in a copmany doing CAD/CAM software, and the software developers roughly knew what to do, but we hired mechanical engineers to do testing because they would call us on UI BS or make suggestions that are relevant to users.
Standard to identify devices and their vendors and automatically filter network access depending on vendor and vitality of vendor. If a vendor of your IoT device goes away, then no longer allow the device to reach out to the non-existant servers. If vendor is still around, limit connectivity based on addresses that would be relevant to said vendor.
This is of course a terrible sort of thing, but the IoT devices and vendors are themselves already terrible and limited, so in that context, it's a matter of picking the lesser of the evils, and these devices security problems can ruin the experience of everyone, not just those who opt into the silly things.
That would be frowned upon as it would be opening things up for supply chain attacks.
It really depends on how you measure 'productive'.
Certainly, some times it's nice to be a bit more out of reach to chase certain things.
However, when I get a better feeling for how my software is being used, it improves my work.
Also, helping others to succeed sometimes is more effective than succeeding yourself.
And finally, everyone feels more productive if they do what they want, but sometimes your view of your work and other's view of your work may disagree.
I know, you can leave a chat window open, I know you can have voice calls and screen sharing and video calls (though that last one has never added anything).
Ultimately, however, casual interaction in person is extremely valuable. A large percentage of things I address are things I overhear that folks wouldn't have thought to ask me about. Or else something that someone is comfortable bringing up face to face, but when I'm not there, they are more afraid of 'wasting my time' because they have no way to judge whether I'm available or not and they don't want to be rude by asking a 'silly question' when I could be overwhelmed with serious stuff.
We are just wired to communicate better face to face sometimes.
Actually the 180k is a Volt, and yes it has been driven *way* more than an average car of its age, and while yes it is technically a hybrid, for this person it spends most of it's life pure electric, and as such can illustrate the improved value compared to ICE vehicles.
Note that I know Volt and Leaf owners, all of them have a similarly positive experience (battery life strong after 180k miles, regenerative breaking making the brakes last a long time, and no mechanical issues with the motors to speak of).
So if it should come to pass that the financials tank Tesla, *hopefully* other vendors shall provide.
My biggest worry is so much of the world pinning all their electric vehicle viewpoint on Tesla, and if it fails at executing on the more mundane facets of running a large automotive company discouraging the rest of the market.
None of the explanations are 'good' for microsoft.
1) It's locked down and fails to notify the user. Means either edge is blocking it badly or their javascript is terrible at handling error codes. The problem is I have a hard time imagining what sort of group policy would lock edge down so much that it would fail what they were doing, and yet work on *other* parts of their application.
2) Their javascript has a problem with the edge runtime, which means either edge sucks, or their javascript sucks and/or they hate edge themselves
3) Their javascript/server struggles with a 'well-used' browser that accumulates stray session cookies and DOM storage. This is probably the most likely scenario, given a long lived browser and a domain like 'microsoft.com'. This happens all the time in web development land, and is probably the *least* specifically microsoft being bad scenario.