At least the outcome will be far more useful to the average person.
And less damaging, too.
At least the outcome will be far more useful to the average person.
And less damaging, too.
Should've gone into finance, embezzle some millions and pay a few thousands as a fine instead. Far more profitable.
In the long run, I'd expect the tools to adapt to solve those problems more transparently, e.g. through the use of standardized libraries that hide the parallelization behind procedural wrappers so that developers can write seemingly procedural code, but gain the benefits of massively parallelized code for the pieces that matter.
Or not; hard to say.
For that to be even ostensibly correct, you're missing one single quote mark and some double quotes, e.g.
"There are to many 'it's, don't you think?" he said.
And even that is arguable, because those aren't really apostrophes; they just happen to use the same key on the keyboard, typically.
With only two exceptions, the plural of any word is always spelled with an 's', not an apostrophe followed by an s. The exceptions are:
And even then, those exceptions might depend on what style guide you go by.
Functional programming and unit testing are things you don't see widely used in the videogame development world, at least that I've seen.
I'd expect functional programming to be used quite a bit in that space, but only for very small chunks of performance-critical code, such as massively parallel bits down in the guts of raytracing engines. Now whether they actually use functional programming languages or not is another question.
Unit testing is something you don't see widely used in software development, period, unfortunately. But the industry is getting better. Slowly. Very slowly. Very, very slowly. Glacially, really.
It needs to be done and done well. Very tempting. But alas, just like drug use, there's only so much any sane person can write about the subject, because anyone who knows functional programming well enough to fully explain why it is harmful is probably mentally damaged beyond the point of being able to understand why it is harmful.
The thing is, functional programming is a good paradigm for students to be exposed to in school. Briefly. It forces you to think about data flow through your program, and forces you to think about your software as a giant state machine and visualize how the states change as your software does work. It is not the only way to teach that concept, but it is a halfway decent way. And once you pick up those concepts, you'll start to understand why singletons are so useful (approximately the polar opposite of functional programming, but often the software equivalent of the data you'd be passing around in a functional world).
So basically, there's a time and a place for everything, and it's called college. But just like with drugs, if you continue to do significant amounts of functional programming after that, don't be surprised if the rest of us ask what you're smoking. Functional programming as a real-world paradigm tends to be almost invariably a disaster, because it neither fits the way we think about problems (human thinking is almost entirely procedural) nor the way machines do work (computers are inherently procedural). It can provide useful extensions to procedural programming languages that serve specific purposes (e.g. closures), but calling functional programming useful for that reason is akin to calling a diesel-electric freight train a perfect commuter car that saves fuel because a Prius is also hybrid hydrocarbon-electric.
About the only space where functional programming techniques might really make sense is when working in a massively multithreaded environment, e.g. creating really efficient implementations of certain massively parallelizable functions (such as FFTs). But for the most part, that functional programming is limited to creating components that are then utilized as small (but performance-critical) parts in what is otherwise on the whole still procedural (or OO) software.
Outside of those very limited scopes, though, the theoretically ivory-tower-pure, zero-side-effect functional programming model is pure garbage. Real world systems don't just have side effects; they are side effects, whether you're talking about storing data on disk, sending it over a wire, drawing it on the screen, reading data from a keyboard, or whatever. The notion of treating all of those "side effects" as some giant state object that mutates as it gets passed around is fundamentally antithetical to real-world use of the data, because state must be stored to be useful. And the entire notion of passing around the complete state of real-world software is so far beyond infeasible that the concept is utterly laughable. Cell phones have a gigabyte of RAM, not a petabyte. There's simply no way to write something like MS Word in a pure functional language, because it would take all the computing resources on the planet to barely run a single instance of it.
Using functional programming in most real-world environments, then, cannot possibly do anything but cause brain damage, because the whole functional paradigm is wrong for the problem space. It is like cutting the grass on a football field using only a single pair of nail clippers—theoretically possible, but completely infeasible. To that end, although I wouldn't say that functional programming is inherently considered harmful, it should be approached with approximately the same level of skepticism as goto statements, and for approximately the same reason. When used correctly, in a very limited way, it is a powerful tool to have in your toolbox that can seriously improve your software. When overused or misused, it is a black hole that consumes infinite amounts of programmer time while emitting very little.
Where I used to work, we called this the "Stack Overflow Effect" because so much bad code written by well-meaning people was floating around Stack Overflow that did things in dangerous, security-risky ways, such as telling people to disable TLS chain validation so they could use a self-signed cert for their test environment, then wondering why so many apps shipped with chain validation turned off in the production versions of the app.
I've actually written security documentation whose primary purpose was to provide a single set of code snippets that were known to do things in the right way so that we could plaster Stack Overflow with links to the doc. Then, when people say, "but can't I just...", we can say, "No", and point them atdocumentation explaining why so that at least when they do something stupid anyway, we can say, "Dude, what part of 'no, that is incredibly dangerous' didn't you understand?"
First of all, never call your product a "competitive product". You know what this means? Essentially what you're saying is "the others are just as shitty, so why try harder?" Another thing is that the message is not what you say but what your audience hears. It's nice that you feel like your customer has a seat at your table, but this does not arrive at your customers. They do not feel that way. And if you care about how your customers think about you, this is what matters.
One thing is certain: Goodwill goes a long way, and it takes a long, long time to rebuild from ruins. And let's be honest here, Comcast's goodwill is in the gutter. You have a long uphill battle in front of you if you really care.
So the lack of complaints is simply due to people noticing that complaining only wastes their time without resulting in any measurable improvement?
Guess why most people don't vote anymore...
So instead of telling you to "go to hell" they inform you that they "want you to have a warm, fuzzy feeling"?
Comcast offering a better product cheaper?
What hellhole would you have to live in for this to be even possible?
Complaints are down by 25% in areas where a competitor opened shop and claims they took a market share of about 30ish percent from Comcast...
Nobody was forcing them to be parents. They were prepared to be parents and take the financial and emotional responsibility... that was the whole point of the procedure.
Yes, for a child born of their own genes. There are numerous disadvantages to raising a child who is not of your own genes. Such offspring is much less likely to be successful in every way due to a number of factors. Your offspring literally inherits traits you gained during your lifetime. This is important for creating rapport between parent and offspring. Keep in mind that it's a typical instinct for an ape to kill all the offspring of other males when he takes over a female.
Wow that is hugely offensive to folks living in the mid-west. Good job.
The voters in the flyover states who think they should be ten times more important than me even though they are still stuck in the puritan past are far more offensive.
Your comment at least prompted me to go look at Android-x86, they say they are working on 3d acceleration now. If they can get that together then they'll finally really have something.
"Gotcha, you snot-necked weenies!" -- Post Bros. Comics