Apple offers as a service, that it will keep your device current for a while.
A good reason to never use Apple. Linux will keep your device current forever.
As much as I abhor the direction Microsoft has taken Windows and many of their software offerings to this subscription based bullshit, you can't ask a vendor to sell you a one time license and then keep everything up to date forever. People and companies have to make money to fund operations and their lives. Gouging is one thing, I will rail against that all day, but you're straight up insane if you think I am going to write you a piece of software, charge a reasonable license fee once and now I work for you for free until I die.
This is why long term, Linux is basically a charity case on a lot of distributions.
Of course, but that should be considered during the design/architecture phase of the program/algorithm anyway. If the data set could grow that large, absolutely that run time increase needs to be considered unacceptable (I actually berated a senior developer once for this exact issue...), but if that code is not going to be running on that large a set then it really isn't going to make a difference to anyone.
Code quality still needs to be considered, because if someone submits an algorithm for review that runs in O(n^3) when only a few changes could make it O(n) you damn right they will be told to rewrite it immediately. However, as I said in my post, the cases where this is important are not nearly as common, the risks and maintenance headaches are much greater in low level imperative style languages, and nothing precludes the developer from using the faster language when speed it is of such importance. Nothing is stopping me from writing performance critical code in C++ and creating a small interop to run it with C# in the controller. The overhead of such an implementation is negligible on most systems, and when it is then I would consider C/C++ to be the better option.
I complete cede that, again, the right tool should be used for the job, but I also subscribe to the thought that the right tool often times is not C/C++ regardless of who wants to argue that it is the end all be all tool.
Oh I agree there entirely. Like I said in my post, C/C++ still rule the embedded systems with an iron fist because those small differences are amplified 1000% when available resources are so restricted. I've seen it in practice far too many times to disagree and am much too familiar with the theoretical side to think otherwise. As I said, right tool for the job comes first. I may dislike the languages but that doesn't mean I won't use them where appropriate.
I actually agree with you on that point, but anyone looking to create long term viability has to fight that tide and typically attempts to (though the true leaders trying to do that are few and the successful ones are even fewer). Unfortunately, to do it the right way, a mix of good long term practices while creating short term profit has to be struck in order to retain the position long enough to really build that solid base. Hence why it is so difficult and why so many fall into the short term gains fallacy.
Over time though, I would completely agree that it will happen to almost any company simply because eventually enough shareholders get pissed that they buy the snake-oil salesman's pitch and install him to make their short term gains. It is the old adage that trying to defend against so many threats is difficult because they only have to win once, while you have to win a million times all in a row.
Actually, I would argue that their day of reckoning will come for the products they have taken this approach on. The main reason it hasn't for their overall business yet in my opinion is no one is directly targeting their main cash cow markets (business productivity software) in a meaningful way. Not only that, their product suite is so diverse it is difficult to knock them off because either it would take a MASSIVE capital investment, a strong consortium of companies, or one hell of a game of whack-a-mole to truly destroy them.
Internet Explorer is a perfect example of them being arrogant for a long time and thinking they could have a garbage product that people will still use. Now, they've shifted and Edge is a far better product because they knew that was the only way to win back any real market, but they played with fire for too long and lost too much of the market. Now the brand is tarnished in that space and there are way better companies putting out better options.
I would also cite IBM as a perfect example of short term blinders damaging the company in the long term. Big blue used to be THE tech company and now they are doing good just to keep making a decent profit. Hell, several of their former glory day markets they don't even have anymore because of exactly the issues I described.
While there is some truth to your statement (at least in the managers eye's), this is a very common fallacy. My previous industry saw many companies that had that exact mindset and while in the short term it can work, long term it will guarantee the failure of a company. For every bug, hack, and poor design choice the company is taking on technical debt. Up front, yes, the first and most important thing for new companies is securing jobs/contracts. Therefore one can afford and may even require a fair amount of corner cutting early on to accomplish that goal to establish initial footing (as said many times, no project has an infinite timeline and infinite budget).
If however that mindset is retained once a company is established the technical debt will accumulate and compounds exponentially over time. It also creates an entrenched mindset (that code has worked for years, no way it broke there!) that makes bug hunting and fixing much harder. Once that becomes the case said company gets a rep for having horrible buggy code that is difficult to fix. It then becomes trivial for the more expensive but higher quality products to take everything over. I know because I watched this exact scenario unfold. My previous employer definitely had their fair share of managers with the speed over quality mindset (I actually wrote a post about that yesterday...), but the overall company strategy was to put out higher quality products than competitors even though it was never going to be cheaper. It worked in spades. They were literally getting jobs to fix other companies' fucked up systems before the installs were even complete because the other companies' reputations got so bad. Keeping that code quality definitely required a lot of fighting between the architects/senior developers and management though (this actually contributed to me leaving that company).
There comes a break point of cost to profitability where that balance shifts to spending too much time/money on perfecting the software. Older game studios were guilty of that a lot I think (see 3D realms and Duke Nukem Forever), but from my point of view the balance has shifted to trying to put out too much stuff now without properly designing, testing, and fixing the underlying framework. It very much seems to be following economic modeling with supply/demand, but I think we are still in a highly volatile time because so much of the technology is new still (first to market is so valuable to businesses). So overall, I disagree that there is zero ROI to bug fixing and preventative measures, but both are undervalued and difficult to measure their ROI.
I hate this argument and always have. By straight raw number comparison yes C/C++ are faster than most managed languages. Problem is most of the zealots that parrot that don't bother to tell you it is typically only a few milliseconds, often nanoseconds, faster on the general operations (hell there are instances where is is actually slower, though admittedly not as many, Dictionaries are a great example). Even in compound highly abstracted layers of code you might see a 5 to 10 ms difference on the operation if you can manage an apples to apples comparison (which typically you can't unless it is a very trivial operation because the coding style between C/C++ is vastly different than even C#) for a very compute intensive algorithm. Even then, the main reason the execution speed is better at all is because the C++ optimizer is significantly better and more mature than a lot of other languages. As we have seen more improvements to the compilers and optimizers of other languages the gap has closed (even Java and C# are surprisingly fast these days with their respective JITs).
Even theoretically, the performance hit you're referring to is merely a constant added onto the performance calculations because they are able to perform checks based on memory allocation of the heap in managed languages. Hell, it isn't even a great comparison because C/C++ has to perform scope checks to ensure certain objects are even supposed to be accessing the memory in question that is already allocated to that process. Access violations can still occur in those languages.
At the end of the day very few users can tell much of a difference between a managed and unmanaged language's program, but error rates are way higher in the unmanaged languages (some of it is general unfamiliarity and learning curve of the language, but even experienced developers will still have higher rates from what I've seen). For general use, I dislike C/C++ for writing programs because of the maintenance factor and how many "roll my own" algorithms that can be required, but I will completely agree it does still have solid and semi-common use cases (embedded systems are ruled by those languages and probably will be for a long time). For me, it comes down to using the right tool for the job, and for a lot of business solutions, a managed language is just more suited to doing the work.
This is more the problem. I've known both flavors or software devs, code monkey or genuine talent, and while obviously you want the later they both face the same issues. The number one issue for code optimization is time constraints. Until the performance of the code actually becomes a problem and there is significant monetized benefit to improving the underlying architecture/design/implementation no one in management is really going to care if the dev got the algorithm to run in O(n) or O(logn). The questions they ask are simply does it work, is the customer ok with how it works, and how fast can you give it to us/them to buy/sell?
I remember one piece of code I managed to write on a project that I was actually extremely proud to have written. It was a completely proprietary need, so it had to be done in house with no libraries and was a very core piece of the service I was creating. I was able to do O(1) insertions, keep it self sorting for easy traversals, and perform O(1) lookups while it cleaned itself up. It even had a very minimal spatial complexity because I managed to do some wonderful pointer magic (in.NET at that) with a few different data structures. Once I completed the service I was actually satisfied with the implementation and that part of the code didn't have to be touched again (ever from what I was told by a few other project leads years later). You know what the project manager said? He didn't care at all and was actually upset that I didn't finish it early so I could work on the other developer's pieces because they were going slower than he wanted (I was even on time with the delivery and still got that response). Upper management sided with him and to avoid further friction moved me to a different project and threw a code monkey onto their team that spat out hot garbage...
I think if you talk to most good developers they probably have a similar story if they have been in the industry for more than 5 years or so. Scope creep and the insatiable desire for new tangible features are the biggest enemies to efficient and optimized code these days. We probably have just as many genuinely talented developers in the industry as ever imho.
Yeah he's just mad Apple's not a part of it. At the end of they day the data is where the money is and Apple's devices are just windows to data (Well, services. Services are just applied data).
I'm no fan of Apple for a lot of things, but this is just a dumb statement. Apple is literally the most valuable company on the planet as of this posting at over 925 billion dollars. That is 150 billion dollars more than the number 2 company Amazon and 175 billion over Alphabet which is arguably the largest data mining company of them all. I don't think he is mad that they are not getting much of a slice of that pie because if he were then they wouldn't be making these statements constantly and you would suddenly see lots more data collection going on from their side.
They are doing a lot of things that I dislike, but data privacy is not one of them. They could improve more for sure, but they are so far ahead of almost all the other companies it is pathetic.
Some tech economists crunched numbers and figured out that if you tried to self-host all of the services Google provides you for free, it would cost about 20K/yr
Google is pretty much giving you 20k in services in exchange for slurping data off of your online activities and showing you ads and that gives you an idea about the money at stake here.
In reply to this, I seriously scoff at that figure. Google provides a SHITLOAD of services and all, but only the most die-hard of Google fans come close to using all of them. Most of them also have alternatives available in the market that don't require you to give away your data too. That figure is highly suspect even if someone were using all their services. Maybe if you bought everything (servers, licenses to run them, etc.) and did all the work yourself it might come close, but no one is going to do that and it defeats the purpose specialist services in our economy anyway. Lets break down some of the major services Google offers, look at their costs, alternatives etc. to get a better picture:
Google's search business has made money off of straight up ads for a long time before they started monetizing the user information from search as well. DuckDuckGo is gaining market share wonderfully and is 100% privacy focused. Cost to user could be basically nothing still and wouldn't need to steal their data...
Android is the biggest data miner ever and honestly, and maybe this is just me but I would GLADLY pay for a license that isn't stealing all my fucking info. Seriously I hit disagree on their stupid enhanced location accuracy shit 5 to 10 times a day and it STILL kicks my GPS on and sends them my location... If I didn't loathe Apple's style I would have honestly switched already, but they manage to make money without stealing all their user's data. Modding is a pain in the ass too so non-starter for me and many others (I have enough shit to do). The smartphone market will hopefully face a reckoning someday, but who knows when... Point still stands that Apple is making money without selling their users privacy up the river and Google could too.
Gmail has a massive amount of alternatives like proton mail, self-hosting, even garbage yahoo. Cost? Shit and crap to migrate and use elsewhere, maybe $10 a month. Next.
Chrome. I really did enjoy the browser's feature set and speed since its release, but they are getting way out of hand with data collection there too. Personally, my home computer has already been migrated to a strict Firefox usage and my work computer will be soon (I care less about my work browsing habits). Again, shit for cost and you could use quite a few other browsers for the same cost of nothing without giving away data already.
Youtube, like search, could be supported off of ads alone. Alternatives that many are probably already paying for include Hulu, Netflix, Prime Tv, SlingTV, etc. I call bullshit that this would be that expensive. There are even other video
I think it would all be considered pro se representation since it isn't actually giving legal advice necessarily just providing the forms and scripts for one to do it themselves. Technically even if they did have an issue with that, if an attorney provided that initial information (which I would assume they did though TFA didn't mention it specifically) it would be perfectly fine I believe. As always, I am not an attorney, merely a surfer of the interwebs that half-assedly can parse legal jargon. I may be wrong, but I would think this is all fine as long as he doesn't try to add anything that would be disallowed from pro se representation such as class action lawsuits or arguing before the Supreme Court (not thinking that one is likely feasible anyway...).
If I remember correctly, they experimented with cross-platform support at MS many moons ago. From what I recall, as a viability experiment they got some of the top console gamers they could find and then grabbed some average PC gamers to try it out. The results were BRUTAL. The guy they interviewed wouldn't give specifics but he said (not word for word) it was like watching 5 year old pee wee players (console gamers) go against an NFL pro bowl team (PC players). They tried a couple more times and did a few variants (FPS, third-person, etc.) and most of them were the exact same result. The program was immediately shut down.
So true. I remember the glory days of Halo 2/3 on console and many of my more "bro-like" friends talking about how they could kick anyone's ass at the game (later it became whatever call of duty game was out) and that PC players were just elitist nerds. At the time, I played both console and PC (PC master race now) and tried to explain to them that playing with a controller SIGNIFICANTLY slowed down gameplay and was way inferior to KBM. They kept that opinion up for years until one day they actually saw me playing TF2 and could not believe how fast the game moved and that there was no aim assist in the game. I almost wish the Microsoft cross platform plans happened back in those days just to prove the point that it wasn't even a comparison, but it would have lost all novelty after a couple of hours.
Can the law of supply (his lab's production) and demand (price people are willing to pay) make this self-regulating?
This is the inherent flaw in that type of argument and the main reason that healthcare needs to be single-payer and pharma companies (and other medical type companies) need to be heavily regulated. Demand is not, "price people are willing to pay", demand in the healthcare world is how healthy do people want to be. Incidentally this is always as healthy as they can be (and fun fact, in many cases if a person decides they don't want to be healthy we consider that to be a disease, potentially even criminal!). This is why healthcare costs go up every year and don't actually ever go down.
Building on this, basic macro-ecnomoics tells us that the supply and demand of a free market is supposed to rise and fall against each other until a general state of price equilibrium is attained. Want to know what happens when demand literally will not (possibly cannot if we want the species to survive) fall? The price can be raised ad infinitum. The execs and many of their politician buddies know this, but they don't ever acknowledge it. Healthcare is literally a money pit if left in the current system and will far out pace wage earnings in all industries eventually. If you don't believe me look at the wage growth over the past several years vs healthcare costs for yourself.
Based on these simple facts (and yes I do mean facts), to me, there is really only one way to fix this appropriately. By changing the system and acknowledging that you cannot apply a free market model to healthcare in any sustainable way. Pricing and costs would be regulated and made equal across socio-economic areas/demographics and then we take all of that excess money that was a result of price gouging and reinvest that into medical research, hospitals, etc. Seriously if we switch to a single-payer system tomorrow we would actually SAVE money as a country.
Most sane people are not asking the business to operate for free or at a loss. They are allowed to make a profit, but not to gouge it simply because they recognized the flaw in the current system. The numbers have been stated over and over, we pay by far the most money per person into healthcare of any 1st world country. If we used that money to improve healthcare availability we would have an affordable system for everyone that you don't have to wait forever for anything to happen. Everyone loves citing Canada having long waits, but that is only for more difficult procedures or tests and even then they are not the only country with universal healthcare (and gasp! there are countries that don't have that same issue).
For me, the solution is sitting right in front of us, but because of the fervor like devotion many people have to "free-market" everything we can't actually implement it yet. This, just like with everything else, is a perfect example of there is no one-size fits all solution for all problems and we as a country need to stop acting like that.
No, he is quite right in pointing out how that statement is actually misleading. If we did an survey about the effects of economic disadvantage on inner city youth and asked a bunch of affluent suburbanites, that really isn't useful information for anything other then what do the affluent suburbanites think about this particular issue.
This is a common misunderstanding about statistics. You do NOT need a lot of samples for statistical significance, and the number of datapoints needed is usually far below what people intuitively expect.
If you want to improve predictions, it is generally far more important to improve the representativeness of the samples, and design the questions to elicit a proper response. Increasing the sample size does little.
Fair point, but I did mean with 10k they likely have a diverse enough reply to achieve the status (though I completely admit, without knowing more, its impossible to say for certain).
Its a bit misleading though on the numbers. They had a little over 10 thousand responses, which for their overall user base is probably statistically significant, but not for individual companies registered on there. They did a break down of the registered user-base's companies, but not a break down based on the respondents from those companies outside of a percentage. They have 6 thousand Apple employees and say at least 100 responded. They could have 44 out of those 100 say yes and they have their percentage right there even though that isn't significant for the company alone. Then, the one study they cited from 1978 only had 150 sample size too making the percentages seem extremely high, but not doing a proper breakdown or significant numbers.
I can agree it shows tech workers in general may have high rates of imposter syndrome, but the individual company rates may be misleading without additional information. Its also not controlling for a lot of factors. At best, I'd say you could claim a 40% rate, maybe 50% with more information on the study (maybe it is just cnet doing poor editorial work). Then finally, what is the rate of imposter syndrome among other profession? Could this be something that just runs high for white collar professionals or maybe people in general? It is interesting, but lot of holes in the stats.
Very true. I meant more that newer applications should be dark by default but everything somehow is now standardized to light colors with lots of light output when left on default settings. I'd have been completely fine to leave things in the old style.
I'm all for multiple themes and options. However, like many others that I'm sure have been asking for a dark theme, I suffer from a lot of eye strain and severe migraines often quickly worsened by light exposure. Now this probably is because I spend anywhere from 8 to 14 hours a day looking at screens since I write software at work and then do software/IT stuff at home a lot, but it is still nice to have things like dark themes that can help me reduce the impact and frequency of issues significantly. It also has always confused me why we need so much light directly beaming at our eyes with heavy white clad monitors. Typical working conditions not on a computer tell us to not look directly at bright light sources, so to me it only makes sense that we should have started with dark themes and then added light themes later.
Just my opinion though, as I'm sure others land on the other side.
The dark theme for file explorer is the most excited I think I've ever been for anything from Microsoft ever. I feel like on that basis alone the Halloween name would be appropriate.
I can see why you would come to that conclusion, but it would be a rather draconian practice that would likely just frustrate people. No real need to include string pattern validation in a compiler either or something similar, that really isn't the purpose of it. Seems if one wanted that type of enforcement it is better fit in an addon for your IDE of choice ala Resharper for VS. That way it allows for freedom of the organization to follow that and enforce strictly or if they have a need/desire to come up with their own. In my experience, even open projects enforce some type of style requirements for any new commits.
I can agree that I don't understand the python2 to python3 transition decisions. If they were going to break the backwards compatibility of a language then it should probably be a different language altogether.
Yes and no. Within an organization those problems can be solved with a style guide that is enforced properly. Now, in the open source community and development at large you have a solid point though. Still, I would argue some of it could be curved with generally accepted guidelines just like how camel case is the norm for lots of function/method naming, hungarian notation is still heavily used in dynamic type languages, and almost universally it seems everyone uses caps for constants. These are things that carry across languages and organizations (other than the first year programmers that still name everything x, y, and boobs because its funny to them or they're lazy...) and could probably be applied here as well.
Functional languages are great, but difficult for a lot of people to wrap their heads around. I still routinely see people completely misuse even the simple C# lambda expressions because they don't understand the paradigms of that type of programming. Granted the lambdas in C# are confusing to understand how they execute under the hood just due to the nature of how they implemented the feature (and people assuming just because a generic functions is defined it must be the best one for their particular need), but compared to writing in Haskell they are child's play.
While I definitely agree the fad driven additions cause a lot of headaches in languages, playing devil's advocate, some of the features are added because of a growing need from the user base and no one wants to rewrite their codebase just because a whole new language was designed for one feature (even a big feature). I mean, C++ was basically just C with class support tacked on originally so that code would easily port into it, and look how popular C++ remains.
To borrow your example, C# has had some very meaningful additions, though I admit they drive me crazy sometimes (.NET 4.5 with async processing is super useful but fucking crazy to try and implement in certain ways, especially if you need any real thread-safety...). I definitely will give you nullable types in general get really annoying though with just the compiler, much less doing run time reflection binding.
More on topic, I'm not sure where this Julia language will fit in yet (probably a niche one or at best popular in academia) given it doesn't sound too heavily focused on taking into account the business heavy languages and needs (C++ is included at least). In fairness I am not familiar with it though. TFA does bring up some interesting business use cases for heavy computing requirements, but it may depend on how well it can integrate into existing systems with different language bases. Doesn't really sound like it is designed for as much UI/UX work and potentially may have some draw backs in other necessary areas. Plus, as others have pointed out, I can see it really suffering from a jack-of-all-trades syndrome and being ok or good at a lot but not enough for people to want to adopt.
Slashdot Mirror
Apple offers as a service, that it will keep your device current for a while.
A good reason to never use Apple. Linux will keep your device current forever.
As much as I abhor the direction Microsoft has taken Windows and many of their software offerings to this subscription based bullshit, you can't ask a vendor to sell you a one time license and then keep everything up to date forever. People and companies have to make money to fund operations and their lives. Gouging is one thing, I will rail against that all day, but you're straight up insane if you think I am going to write you a piece of software, charge a reasonable license fee once and now I work for you for free until I die.
This is why long term, Linux is basically a charity case on a lot of distributions.
Of course, but that should be considered during the design/architecture phase of the program/algorithm anyway. If the data set could grow that large, absolutely that run time increase needs to be considered unacceptable (I actually berated a senior developer once for this exact issue...), but if that code is not going to be running on that large a set then it really isn't going to make a difference to anyone.
Code quality still needs to be considered, because if someone submits an algorithm for review that runs in O(n^3) when only a few changes could make it O(n) you damn right they will be told to rewrite it immediately. However, as I said in my post, the cases where this is important are not nearly as common, the risks and maintenance headaches are much greater in low level imperative style languages, and nothing precludes the developer from using the faster language when speed it is of such importance. Nothing is stopping me from writing performance critical code in C++ and creating a small interop to run it with C# in the controller. The overhead of such an implementation is negligible on most systems, and when it is then I would consider C/C++ to be the better option.
I complete cede that, again, the right tool should be used for the job, but I also subscribe to the thought that the right tool often times is not C/C++ regardless of who wants to argue that it is the end all be all tool.
Oh I agree there entirely. Like I said in my post, C/C++ still rule the embedded systems with an iron fist because those small differences are amplified 1000% when available resources are so restricted. I've seen it in practice far too many times to disagree and am much too familiar with the theoretical side to think otherwise. As I said, right tool for the job comes first. I may dislike the languages but that doesn't mean I won't use them where appropriate.
I actually agree with you on that point, but anyone looking to create long term viability has to fight that tide and typically attempts to (though the true leaders trying to do that are few and the successful ones are even fewer). Unfortunately, to do it the right way, a mix of good long term practices while creating short term profit has to be struck in order to retain the position long enough to really build that solid base. Hence why it is so difficult and why so many fall into the short term gains fallacy.
Over time though, I would completely agree that it will happen to almost any company simply because eventually enough shareholders get pissed that they buy the snake-oil salesman's pitch and install him to make their short term gains. It is the old adage that trying to defend against so many threats is difficult because they only have to win once, while you have to win a million times all in a row.
Actually, I would argue that their day of reckoning will come for the products they have taken this approach on. The main reason it hasn't for their overall business yet in my opinion is no one is directly targeting their main cash cow markets (business productivity software) in a meaningful way. Not only that, their product suite is so diverse it is difficult to knock them off because either it would take a MASSIVE capital investment, a strong consortium of companies, or one hell of a game of whack-a-mole to truly destroy them.
Internet Explorer is a perfect example of them being arrogant for a long time and thinking they could have a garbage product that people will still use. Now, they've shifted and Edge is a far better product because they knew that was the only way to win back any real market, but they played with fire for too long and lost too much of the market. Now the brand is tarnished in that space and there are way better companies putting out better options.
I would also cite IBM as a perfect example of short term blinders damaging the company in the long term. Big blue used to be THE tech company and now they are doing good just to keep making a decent profit. Hell, several of their former glory day markets they don't even have anymore because of exactly the issues I described.
While there is some truth to your statement (at least in the managers eye's), this is a very common fallacy. My previous industry saw many companies that had that exact mindset and while in the short term it can work, long term it will guarantee the failure of a company. For every bug, hack, and poor design choice the company is taking on technical debt. Up front, yes, the first and most important thing for new companies is securing jobs/contracts. Therefore one can afford and may even require a fair amount of corner cutting early on to accomplish that goal to establish initial footing (as said many times, no project has an infinite timeline and infinite budget).
If however that mindset is retained once a company is established the technical debt will accumulate and compounds exponentially over time. It also creates an entrenched mindset (that code has worked for years, no way it broke there!) that makes bug hunting and fixing much harder. Once that becomes the case said company gets a rep for having horrible buggy code that is difficult to fix. It then becomes trivial for the more expensive but higher quality products to take everything over. I know because I watched this exact scenario unfold. My previous employer definitely had their fair share of managers with the speed over quality mindset (I actually wrote a post about that yesterday...), but the overall company strategy was to put out higher quality products than competitors even though it was never going to be cheaper. It worked in spades. They were literally getting jobs to fix other companies' fucked up systems before the installs were even complete because the other companies' reputations got so bad. Keeping that code quality definitely required a lot of fighting between the architects/senior developers and management though (this actually contributed to me leaving that company).
There comes a break point of cost to profitability where that balance shifts to spending too much time/money on perfecting the software. Older game studios were guilty of that a lot I think (see 3D realms and Duke Nukem Forever), but from my point of view the balance has shifted to trying to put out too much stuff now without properly designing, testing, and fixing the underlying framework. It very much seems to be following economic modeling with supply/demand, but I think we are still in a highly volatile time because so much of the technology is new still (first to market is so valuable to businesses). So overall, I disagree that there is zero ROI to bug fixing and preventative measures, but both are undervalued and difficult to measure their ROI.
I hate this argument and always have. By straight raw number comparison yes C/C++ are faster than most managed languages. Problem is most of the zealots that parrot that don't bother to tell you it is typically only a few milliseconds, often nanoseconds, faster on the general operations (hell there are instances where is is actually slower, though admittedly not as many, Dictionaries are a great example). Even in compound highly abstracted layers of code you might see a 5 to 10 ms difference on the operation if you can manage an apples to apples comparison (which typically you can't unless it is a very trivial operation because the coding style between C/C++ is vastly different than even C#) for a very compute intensive algorithm. Even then, the main reason the execution speed is better at all is because the C++ optimizer is significantly better and more mature than a lot of other languages. As we have seen more improvements to the compilers and optimizers of other languages the gap has closed (even Java and C# are surprisingly fast these days with their respective JITs).
Even theoretically, the performance hit you're referring to is merely a constant added onto the performance calculations because they are able to perform checks based on memory allocation of the heap in managed languages. Hell, it isn't even a great comparison because C/C++ has to perform scope checks to ensure certain objects are even supposed to be accessing the memory in question that is already allocated to that process. Access violations can still occur in those languages.
At the end of the day very few users can tell much of a difference between a managed and unmanaged language's program, but error rates are way higher in the unmanaged languages (some of it is general unfamiliarity and learning curve of the language, but even experienced developers will still have higher rates from what I've seen). For general use, I dislike C/C++ for writing programs because of the maintenance factor and how many "roll my own" algorithms that can be required, but I will completely agree it does still have solid and semi-common use cases (embedded systems are ruled by those languages and probably will be for a long time). For me, it comes down to using the right tool for the job, and for a lot of business solutions, a managed language is just more suited to doing the work.
This is more the problem. I've known both flavors or software devs, code monkey or genuine talent, and while obviously you want the later they both face the same issues. The number one issue for code optimization is time constraints. Until the performance of the code actually becomes a problem and there is significant monetized benefit to improving the underlying architecture/design/implementation no one in management is really going to care if the dev got the algorithm to run in O(n) or O(logn). The questions they ask are simply does it work, is the customer ok with how it works, and how fast can you give it to us/them to buy/sell?
I remember one piece of code I managed to write on a project that I was actually extremely proud to have written. It was a completely proprietary need, so it had to be done in house with no libraries and was a very core piece of the service I was creating. I was able to do O(1) insertions, keep it self sorting for easy traversals, and perform O(1) lookups while it cleaned itself up. It even had a very minimal spatial complexity because I managed to do some wonderful pointer magic (in .NET at that) with a few different data structures. Once I completed the service I was actually satisfied with the implementation and that part of the code didn't have to be touched again (ever from what I was told by a few other project leads years later). You know what the project manager said? He didn't care at all and was actually upset that I didn't finish it early so I could work on the other developer's pieces because they were going slower than he wanted (I was even on time with the delivery and still got that response). Upper management sided with him and to avoid further friction moved me to a different project and threw a code monkey onto their team that spat out hot garbage...
I think if you talk to most good developers they probably have a similar story if they have been in the industry for more than 5 years or so. Scope creep and the insatiable desire for new tangible features are the biggest enemies to efficient and optimized code these days. We probably have just as many genuinely talented developers in the industry as ever imho.
Yeah he's just mad Apple's not a part of it. At the end of they day the data is where the money is and Apple's devices are just windows to data (Well, services. Services are just applied data).
I'm no fan of Apple for a lot of things, but this is just a dumb statement. Apple is literally the most valuable company on the planet as of this posting at over 925 billion dollars. That is 150 billion dollars more than the number 2 company Amazon and 175 billion over Alphabet which is arguably the largest data mining company of them all. I don't think he is mad that they are not getting much of a slice of that pie because if he were then they wouldn't be making these statements constantly and you would suddenly see lots more data collection going on from their side.
They are doing a lot of things that I dislike, but data privacy is not one of them. They could improve more for sure, but they are so far ahead of almost all the other companies it is pathetic.
Some tech economists crunched numbers and figured out that if you tried to self-host all of the services Google provides you for free, it would cost about 20K/yr
Google is pretty much giving you 20k in services in exchange for slurping data off of your online activities and showing you ads and that gives you an idea about the money at stake here.
In reply to this, I seriously scoff at that figure. Google provides a SHITLOAD of services and all, but only the most die-hard of Google fans come close to using all of them. Most of them also have alternatives available in the market that don't require you to give away your data too. That figure is highly suspect even if someone were using all their services. Maybe if you bought everything (servers, licenses to run them, etc.) and did all the work yourself it might come close, but no one is going to do that and it defeats the purpose specialist services in our economy anyway. Lets break down some of the major services Google offers, look at their costs, alternatives etc. to get a better picture:
I think it would all be considered pro se representation since it isn't actually giving legal advice necessarily just providing the forms and scripts for one to do it themselves. Technically even if they did have an issue with that, if an attorney provided that initial information (which I would assume they did though TFA didn't mention it specifically) it would be perfectly fine I believe. As always, I am not an attorney, merely a surfer of the interwebs that half-assedly can parse legal jargon. I may be wrong, but I would think this is all fine as long as he doesn't try to add anything that would be disallowed from pro se representation such as class action lawsuits or arguing before the Supreme Court (not thinking that one is likely feasible anyway...).
If I remember correctly, they experimented with cross-platform support at MS many moons ago. From what I recall, as a viability experiment they got some of the top console gamers they could find and then grabbed some average PC gamers to try it out. The results were BRUTAL. The guy they interviewed wouldn't give specifics but he said (not word for word) it was like watching 5 year old pee wee players (console gamers) go against an NFL pro bowl team (PC players). They tried a couple more times and did a few variants (FPS, third-person, etc.) and most of them were the exact same result. The program was immediately shut down.
So true. I remember the glory days of Halo 2/3 on console and many of my more "bro-like" friends talking about how they could kick anyone's ass at the game (later it became whatever call of duty game was out) and that PC players were just elitist nerds. At the time, I played both console and PC (PC master race now) and tried to explain to them that playing with a controller SIGNIFICANTLY slowed down gameplay and was way inferior to KBM. They kept that opinion up for years until one day they actually saw me playing TF2 and could not believe how fast the game moved and that there was no aim assist in the game. I almost wish the Microsoft cross platform plans happened back in those days just to prove the point that it wasn't even a comparison, but it would have lost all novelty after a couple of hours.
Can the law of supply (his lab's production) and demand (price people are willing to pay) make this self-regulating?
This is the inherent flaw in that type of argument and the main reason that healthcare needs to be single-payer and pharma companies (and other medical type companies) need to be heavily regulated. Demand is not, "price people are willing to pay", demand in the healthcare world is how healthy do people want to be. Incidentally this is always as healthy as they can be (and fun fact, in many cases if a person decides they don't want to be healthy we consider that to be a disease, potentially even criminal!). This is why healthcare costs go up every year and don't actually ever go down.
Building on this, basic macro-ecnomoics tells us that the supply and demand of a free market is supposed to rise and fall against each other until a general state of price equilibrium is attained. Want to know what happens when demand literally will not (possibly cannot if we want the species to survive) fall? The price can be raised ad infinitum. The execs and many of their politician buddies know this, but they don't ever acknowledge it. Healthcare is literally a money pit if left in the current system and will far out pace wage earnings in all industries eventually. If you don't believe me look at the wage growth over the past several years vs healthcare costs for yourself.
Based on these simple facts (and yes I do mean facts), to me, there is really only one way to fix this appropriately. By changing the system and acknowledging that you cannot apply a free market model to healthcare in any sustainable way. Pricing and costs would be regulated and made equal across socio-economic areas/demographics and then we take all of that excess money that was a result of price gouging and reinvest that into medical research, hospitals, etc. Seriously if we switch to a single-payer system tomorrow we would actually SAVE money as a country.
Most sane people are not asking the business to operate for free or at a loss. They are allowed to make a profit, but not to gouge it simply because they recognized the flaw in the current system. The numbers have been stated over and over, we pay by far the most money per person into healthcare of any 1st world country. If we used that money to improve healthcare availability we would have an affordable system for everyone that you don't have to wait forever for anything to happen. Everyone loves citing Canada having long waits, but that is only for more difficult procedures or tests and even then they are not the only country with universal healthcare (and gasp! there are countries that don't have that same issue).
For me, the solution is sitting right in front of us, but because of the fervor like devotion many people have to "free-market" everything we can't actually implement it yet. This, just like with everything else, is a perfect example of there is no one-size fits all solution for all problems and we as a country need to stop acting like that.
No, he is quite right in pointing out how that statement is actually misleading. If we did an survey about the effects of economic disadvantage on inner city youth and asked a bunch of affluent suburbanites, that really isn't useful information for anything other then what do the affluent suburbanites think about this particular issue.
This is a common misunderstanding about statistics. You do NOT need a lot of samples for statistical significance, and the number of datapoints needed is usually far below what people intuitively expect.
If you want to improve predictions, it is generally far more important to improve the representativeness of the samples, and design the questions to elicit a proper response. Increasing the sample size does little.
Fair point, but I did mean with 10k they likely have a diverse enough reply to achieve the status (though I completely admit, without knowing more, its impossible to say for certain).
Its a bit misleading though on the numbers. They had a little over 10 thousand responses, which for their overall user base is probably statistically significant, but not for individual companies registered on there. They did a break down of the registered user-base's companies, but not a break down based on the respondents from those companies outside of a percentage. They have 6 thousand Apple employees and say at least 100 responded. They could have 44 out of those 100 say yes and they have their percentage right there even though that isn't significant for the company alone. Then, the one study they cited from 1978 only had 150 sample size too making the percentages seem extremely high, but not doing a proper breakdown or significant numbers.
I can agree it shows tech workers in general may have high rates of imposter syndrome, but the individual company rates may be misleading without additional information. Its also not controlling for a lot of factors. At best, I'd say you could claim a 40% rate, maybe 50% with more information on the study (maybe it is just cnet doing poor editorial work). Then finally, what is the rate of imposter syndrome among other profession? Could this be something that just runs high for white collar professionals or maybe people in general? It is interesting, but lot of holes in the stats.
Very true. I meant more that newer applications should be dark by default but everything somehow is now standardized to light colors with lots of light output when left on default settings. I'd have been completely fine to leave things in the old style.
I'm all for multiple themes and options. However, like many others that I'm sure have been asking for a dark theme, I suffer from a lot of eye strain and severe migraines often quickly worsened by light exposure. Now this probably is because I spend anywhere from 8 to 14 hours a day looking at screens since I write software at work and then do software/IT stuff at home a lot, but it is still nice to have things like dark themes that can help me reduce the impact and frequency of issues significantly. It also has always confused me why we need so much light directly beaming at our eyes with heavy white clad monitors. Typical working conditions not on a computer tell us to not look directly at bright light sources, so to me it only makes sense that we should have started with dark themes and then added light themes later.
Just my opinion though, as I'm sure others land on the other side.
The dark theme for file explorer is the most excited I think I've ever been for anything from Microsoft ever. I feel like on that basis alone the Halloween name would be appropriate.
I can see why you would come to that conclusion, but it would be a rather draconian practice that would likely just frustrate people. No real need to include string pattern validation in a compiler either or something similar, that really isn't the purpose of it. Seems if one wanted that type of enforcement it is better fit in an addon for your IDE of choice ala Resharper for VS. That way it allows for freedom of the organization to follow that and enforce strictly or if they have a need/desire to come up with their own. In my experience, even open projects enforce some type of style requirements for any new commits.
I can agree that I don't understand the python2 to python3 transition decisions. If they were going to break the backwards compatibility of a language then it should probably be a different language altogether.
Yes and no. Within an organization those problems can be solved with a style guide that is enforced properly. Now, in the open source community and development at large you have a solid point though. Still, I would argue some of it could be curved with generally accepted guidelines just like how camel case is the norm for lots of function/method naming, hungarian notation is still heavily used in dynamic type languages, and almost universally it seems everyone uses caps for constants. These are things that carry across languages and organizations (other than the first year programmers that still name everything x, y, and boobs because its funny to them or they're lazy...) and could probably be applied here as well.
Functional languages are great, but difficult for a lot of people to wrap their heads around. I still routinely see people completely misuse even the simple C# lambda expressions because they don't understand the paradigms of that type of programming. Granted the lambdas in C# are confusing to understand how they execute under the hood just due to the nature of how they implemented the feature (and people assuming just because a generic functions is defined it must be the best one for their particular need), but compared to writing in Haskell they are child's play.
While I definitely agree the fad driven additions cause a lot of headaches in languages, playing devil's advocate, some of the features are added because of a growing need from the user base and no one wants to rewrite their codebase just because a whole new language was designed for one feature (even a big feature). I mean, C++ was basically just C with class support tacked on originally so that code would easily port into it, and look how popular C++ remains.
To borrow your example, C# has had some very meaningful additions, though I admit they drive me crazy sometimes (.NET 4.5 with async processing is super useful but fucking crazy to try and implement in certain ways, especially if you need any real thread-safety...). I definitely will give you nullable types in general get really annoying though with just the compiler, much less doing run time reflection binding.
More on topic, I'm not sure where this Julia language will fit in yet (probably a niche one or at best popular in academia) given it doesn't sound too heavily focused on taking into account the business heavy languages and needs (C++ is included at least). In fairness I am not familiar with it though. TFA does bring up some interesting business use cases for heavy computing requirements, but it may depend on how well it can integrate into existing systems with different language bases. Doesn't really sound like it is designed for as much UI/UX work and potentially may have some draw backs in other necessary areas. Plus, as others have pointed out, I can see it really suffering from a jack-of-all-trades syndrome and being ok or good at a lot but not enough for people to want to adopt.
Getting* phone typing is apparently hard for me...