Actually, the article made me think Elmo is Nermal, The World's Cutest Kittycat from Garfield.
We just need Oscar the Grouch to start mailing Elmo to Abu Dhabi all the time. Problem solved.
552 karma · joined August 18, 2015
We just need Oscar the Grouch to start mailing Elmo to Abu Dhabi all the time. Problem solved.
That MV police blog post says the traffic officer stopped the car to "educate the operators about impeding traffic per 22400(a) of the California Vehicle Code."
- Getting the permits to sell food (in Chicago of all places)
- Getting a one day location
- Figuring out legal liability (who gets sued if somebody gets hurt/sick)?
- How are those custom design bags, wrappers, uniforms going to be produced? A McDonalds or Burger King supplier or 3rd party?
- How are you going to get workers for that one day for that one location? Do you have to hire temporary workers or do you divert existing workers? How will that impact overtime and other local labor laws (in Chicago)?
- How is the actual burger constructed? Do patties come from McDonalds or Burger King suppliers? What about the buns? What about everything else? Are side orders like fries and drinks going to be available.
- If McDonalds and Burger King cross-promote different specific brands like Coke or Pepsi or Heinz or Del Monte, who do they use?
I'd really like to know how this would work out.
He states D isn't different enough to encourage most devs to go through the pain of switching. If they are going to switch, they would like that language to be much better targeted at solving game dev specific needs.
- Software bloat leads to slow download times and slow launch times and more RAM usage
- Abstraction layers often get out of control and sacrifice lots of performance and lead to software bloat
- Often you start with and SDK thinking it will solve your problem, but it turns out it doesn't solve your exact casem which means you end up spending lots of time fighting the SDK which leads to a mess+abstrction+bloat. Many times you might have been better off writing it from scratch.
- Dependency hell which brings in the bloat+abstraction problems. Plus now you now have extra environment and deployment headaches to make sure everybody involved has the correct dependency chain and correct versions of everything.
- Build system hell: Once you have dependency hell, you often bring in build system hell to manage everything
- SDKs (Frameworks) take control of everything: Often frameworks impose lots of rules and conventions that leak into everything else you do. This means following their design patterns, subclassing from their classes, etc. Their stuff may not fit well with your own stuff. Also, this often deeply entangles your stuff with their stuff so it is hard to remove later.
- Fighting between SDKs: Lots of SDKs try take over the world. If you use multiple SDKs, they may fight.
- Lack of understanding: People too eager to use SDKs often lack the understanding of how it works. To fix bugs, to fix performance problems, to extend features, means you must ultimately understand it, but often this comes too late in the process. And you discover that for all these things will require massive changes to the framework or a complete rewrite. You would have been better off writing it yourself in the first place or picking some other SDK that you understood better.
As for actual zero-cost optimization, Chandler Carruth who works on Clang at Google gave a talk at the 2012 LLVM Developers' Meeting warning people that C++ zero-cost abstractions are more myth than reality, and things developers expect to be zero-cost are often in-fact not. He goes into detail about how the optimizers work and what the challenges are.
http://llvm.org/devmtg/2012-11/videos/Carruth-OptimizingAbst...