At 4 miles per kWh, a 50kW charger can put 100 miles of range on your vehicle in half an hour. Not great for long road trips when your vehicle has 300 miles of range. At 80kW, with a 45-minute stop, you're actually putting 240 miles of range on the vehicle--four hours of driving.
60kWh should come to $6. Charging at high voltages is more efficient, too, so a 600VDC charger gets you quite close to actually pulling in 60kWh in 45 minutes. Likewise, future charge circuits will allow for 100kW and 120kW charging, which lets you recharge every 4 hours with a 45-minute food break if you're going 90mph.
Cross-country driving is unusual, and even the ride from Baltimore to New York City isn't even 200 miles. A 300-mile battery will make that; and most people will take at least one brief rest stop in the 3-hour drive, getting an opportunity to add 60 miles or so with just a 50kW charger in 20 minutes. The round-trip would end you with 90 miles left on the battery even if you didn't charge at your destination.
A bigger problem with the tax break was it was a tax rebate. So, if you didn't pay more than $7500 in federal tax (excluding SS and MC), you won't get the full amount. So, essentially you could fully utilize the tax break if your income was about $100,000 or more (assuming you maximized all your other tax breaks).
The biggest problem is that the tax credit shifts the demand curve.
We're giving people a limited-time opportunity to cash in on their purchase of a shiny new EV. That urgency means they're more-willing to buy and that this willingness will shift away later: the incentive vanishes and the demand curve shifts back, demand falls.
EV manufacturers profit best by exploiting this: keep the supply curve the same and raise the price to meet the new price at which the greatest profit comes. The quantity demanded at any price is higher, so a higher price commands more profit. When the incentive goes away, prices can come back down and continue with the natural market.
Instead, we should have subsidized the manufacturer for the production of each vehicle. Basically, for each vehicle, pay up to $X and no more than Y% of the gross cost.
This doesn't change the consumer's incentive to buy at a given price; nor does it place more money in the consumer's hands. In short: the demand curve doesn't move. If EV makers keep the same price, they will have the same customers.
Instead, it acts as a technological advancement: the cost to produce a unit falls. A lower cost to produce results in a shift of the supply curve: the producers are more-willing to make a specific quantity of units at a lower price. This works best in a competitive market where resulting price competition lowers profits for those producers who keep prices high.
Without a change in consumer demand, the quantity demanded at an unchanging price remains unchanged. With the supply curve shift, the quantity supplied increases at a given price--but that's not how this works: quantity supplied won't exceed quantity demanded. To take advantage, the quantity supplied must be sold, and to get additional buyers then the price must fall so as to increase the quantity demanded. Because the quantity supplied at a lower price increases with lower costs, the equilibrium pint falls to a lower price.
Demand-side approaches--tax breaks, stimulus, welfare, job guarantees--work for your whole economy. They create consumer purchasing power and jobs. If you want to effectively manipulate how much of a product moves, however, you want to surgically target its supply curve: move its price downward to increase consumer demand. You want to use this one sparingly.
See United States v. Hubbel 530 US 27 (2010); Doe v. United States 487 US 201 (1988); and Fisher v. United States 425 US 391 (1976). The Court cannot compel a defendant to reveal a safe combination.
There are ANN hardware designs wherein computer memory cells are integrated with the circuitry of artificial neurons, such as an LSTM neuron. Rather than a bunch of RAM and some program code, there's a bunch of flip-flop circuitry (RAM) built right into the neuron circuitry to create a fully-functional neuron package, along with supporting circuitry to allow programming by wiring those neurons inputs and outputs to each other how you like and writing or reading their values.
Theoretically, once you've programmed the contents and the connections, feeding input into the system would execute on-clock: if you have 5 layers of ANN, it should take 5 clock cycles to turn an input into an output. On a conventional CPU, you have to run a bunch of mathematical instructions which might take one cycle each, or be SIMD, or take multiple cycles for something like a division, or whatnot.
I guess I "don't understand architecture" (despite building hundreds of successful applications.)
You can build successful applications organically. That doesn't mean they have good architecture; it just means they happen to function. Architecture affects things like how quickly large programs can be built, how readily they can be modified and extended with large and complex new features, and how likely defects are to arise. People used to talk about Microsoft rewriting nearly all of Windows every release (NT3 to NT4 to XP to Vista) because much of the core architecture was so broken as to be unusable.
So where do I go or what do I read to "get" GOF in an unambiguous way?
Now there's a question. The original GoF book was... I wouldn't read the original GoF book. Tony Bevis did a good job explaining these for Java, C#, and PHP; but it doesn't help if you're not a decent program architect. Nothing in the world will turn a non-programmer into a programmer in one sitting.
On the other hand, if you've actually built things, you should immediately recognize how to structure parts of your program into these patterns and take advantage of the benefits. This leads to one of two types of thinking: an immediate question of why when there is nothing different; or an immediate question of how to leverage this type of structure to get more out of your program with less.
I fell into that second camp. Things like decorators, proxies, and composites broke me away from lots of custom code to wire up monsters and player weapons in games. In about ten seconds, I went from, "Man, you could make a platformer where you can transform into different monsters, but you'd have to totally recode the control scheme and player movement for each one" to "holy crap, I can just replace the AI with a controller input, and use a decorator that interprets controller inputs based on weapon selected!" Suddenly programming became a game of Lego with an annoying amount of boilerplate code instead of piles of complex logic--and the boilerplate was shorter. Switch blocks in 20 places became one line of reflection in a factory.
Things I'd made work before seemed horribly-implemented, and I made them work again in much less code and much more readably and reliably.
To be fair, I also had a project management background at the time. Project management includes enormous amounts of procedure, forms, charts, and other tools; one of the most-important skills is selecting the tools you need. You don't pour the whole of project management on the smallest project, just like you don't do a whole lot of architecting for a small and temporary program designed to fill in for a permanent solution coming in two months (Risk-Based Architecture). It came naturally to me to understand that the GoF patterns weren't things you absolutely use in clearly-defined situations, but rather tools with clearly-defined functions to be used as you see fit.
The same is true of screws. Some screws have hex heads, square heads, bolt heads, philips heads, cross heads, torx heads, and other types. hex heads are recessed and require a larger area, while bolt heads stick out. Square heads self-align (they always go in straight). Philips heads strip under torque, while cross heads don't. Torx heads handle an amazing amount of torque without stripping. When do you use these? It depends on the requirements of the job at hand.
In programming, that's a much less straight-forward question. There are several ways to accomplish what I described above. Given any strategy, you would use different design patterns. It comes down to how you want to replace the boxes: what do you want to be able to do architecturally?
The best and brightest among us tend to scoff at such people, or more specifically at their stumbling and crutches, with all sorts of plausible-sounding but not actually helpful counters like "good people know what their code does", conveniently forgetting that most programmers aren't very good at all. So perhaps "patterns" are a useful crutch to keeping a lid on the damage from the inevitable Dunning-Kruger effects in business programming. I don't know, maybe.
Self-referential. You're taking the same approach, but softer: "some of us are smart enough to not need this."
Some of us are engineers and can build a house without adhering to national and international building and electrical standards and codes. That house will be structurally-sound. We'll understand how each part works and how to maintain it or build additions so it doesn't crumble.
That doesn't help every other professional who touches our stuff.
But it was only until very much later that I found this writeup
Essentially, yes. The thing he should also notice is all the complex garbage around the sensible stuff needs to be of a fixed form: it's no longer complex if it's recognizable.
Let me give you an example.
Walk over to your bookshelf, pick up a book, and open it to page 173. Read the third paragraph aloud.
Walking involves activating neurons, determining your spatial relationship with objects and the floor, tracking your velocity, checking your balance, and shifting the non-rigid form of your body (not just tilting back and forth) to redistribute your weight. It's one of the most bizarrely-complex things you can do.
Talking involves pulling multiple muscles in your throat in various ways in a pattern, while modulating your breathing and mucking about with several muscles in your mouth to change resonance cavity shape. It's ridiculous.
Picking up the book and opening to a page requires fine motor control. Reading is unbelievably-complex.
You've already internalized all of these things and do most of it based on expectations. When something unexpected happens, you respond quickly based on what you expect this new change to produce.
To be fair you have the same problem with encapsulation and output/results too
Only at the interface. People will write code that does things to things, and then reuse calls to that code to incrementally do things to things instead of extending the interface on an object to say you can now do a thing to a thing (or creating a filter, or whatever else they could do to achieve the same). Then, when you modify those innards, things break.
Sometimes, two pieces of those innards are glued together in such a way that they always work. For example: I could perform a boundary check before sending a call to a function which copies data into a pre-allocated buffer. A different body of code can then make an unchecked call that always works, until someone calls that body of code from a long chain of logic that ultimately didn't have the same boundary checking and gets an occasional buffer overflow in unlikely situations (because they called a function which allocates, did some transformations, then called a function which copies).
This is why you wrap things up into little boxes with buttons and switches on the outside. Nobody directly calls those things, and everything continues to work because you're forced to not do this goofy shit.
We've all hotwired the boxes, though, because we're all clever enough to stick our necks in places they don't belong despite the warning signs and barbed wire.
People made larger architectural patterns like MVC and declared them replacement, in the same way someone might declare "Victorian" a replacement for joist-and-subfloor floors. I've found the GoF patterns have served well where people used them, and people have found them unclear when they didn't understand architecture.
Can you provide examples of where, how, and why GoF patterns failed?
This is why some of us are insistent that the decades of experience which gave rise to design patterns actually means something. Folks often counter argue that good programmers "know what their code does" and so the mess of unstructured spaghetti code is fine "as long as it works"; they don't believe in engineering in containment of bugs and impact.
When you build your code to be a set of tools with defined behaviors and interfaces, you encapsulate bugs. An error in one piece of code creates a defect in the interface, which you correct in one place. This seems like something wholly-imaginary until you realize un-breaking a bug in many flat programs causes unexpected behavior due to other code relying on the defective logic's incorrect impact on some program state.
In an ideal world, none of this would matter. We do all this stuff because it matters in the real world.
Thanks, that helps. Not sure where I read that or if it's just been too long and my memory is distorted. There were all kinds of bizarre claims about this guy.
One theory claims D.B. Cooper must have died because he took a parachute that was a dummy parachute, and so would have had just a stuffed backpack when he jumped. People believe this despite obvious questions like "why would you have something like that on a commercial airplane?" and "where is the body?"
Interesting. That's actually a better estimate than prognosticating on land reserves, because you can actually go around and just measure seawater all over the place with all the research vessels already trafficking the planet.
It's not even mathematically-impossible: it's just sucking energy from ambient environment, and the capture from ambient source needs to be bigger than the loss to ambient source. Remember a heat pump can expend 1kW and move more than 1kW--many residential consumer units have a COP of 2.8, and some are over 3--and that 1kW of work energy has to go somewhere, so you take 3kW from the cold end and spit 4kW into the hot end (this is how your AC actually works, and why a 600W dehumidifier is a 600W space heater). If you force this into a heat storage medium, you've still got loss everywhere--your engine, your heat pump itself (which most likely is driving the extra heat where you want it to go anyway), etc. Insulation, piping, and fancy engineering can get you an adiabatic system; but if you have 40% loss and only 30% (i.e. 75%) recovery plus pull 8% more energy from ambient air, you're net-losing (40% energy lost, 38% energy recovered, 2% net loss).
We think, in practice, that our adiabatic storage tech can break 90% recuperation. In theory, it's 100%.
Yeah, all the known uranium only amounts to that much. We're pretty sure (based on scientific knowledge, not magical guesses or actual measurements) that there's more out there, in the same way we're pretty sure there are new and undiscovered oil fields with a huge amount of new oil (I've heard predictions that 1/3 to 2/3 of the oil in the world hasn't even been discovered yet).
Look, a heat pump can't feed itself from its own reservoir, right? Well, let's put you in front of an air conditioner. The air's cool, right? Go behind and it's hot. Notice it's the same atmospheric reservoir? Same is true in Canada: it's cold up there, but really hot in Florida.
The earth's single reservoir--the atmosphere--has non-uniform thermal energy. Essentially, it's being heated by the sun, and emits radiation to space at a faster rate if temperature is higher, given the same atmospheric and surface composition. That makes it a storage reservoir for solar energy.
By coupling a heat pump and a heat engine, you can pump heat into a pressure vessel, then dump the pressurized gas into a heat engine (compressed air engine). You can use this to drive a compressor to pressurize your pressure vessel.
Typically, you lose heat this way: although the heat engine will tend to cool air relative to intake, you're adding hot air and so it's coming out warm. You're going through the effort of heating that air, thus if the exhaust is hotter than the atmosphere, you're losing that differential to the air.
Theoretically, if you built an adiabatic system, you could recover much of this loss. A heat pump with the cold side coupled to (and insulated with) the exhaust output when above atmospheric temperature would do it. At the same time, your primary heat source is the atmospheric intake. You insulate your pressure vessel and couple the cold side of the heat pump into that.
The work done by the engine turns the heat pump as well: the working energy driving the compressor and the heat pump, generally lost as heat, are pressed into your pressure vessel.
In this way, you theoretically pull the heat out of the local atmosphere--reducing the room temperature--and store it in an insulated bottle. If you cogenerate electricity or liquefy atmospheric CO2 and H2O into non-aromatic hydrocarbon fuel oil, you remove some of the heat (which leaks even through insulation) and store it as stable chemical bond energy.
This all requires things like aerogel (which we have) and quantum tunneling junctions (which we have at too low yield to actually function) to become even theoretically-possible.
So, yeah. Adiabatic thermal concentrator. Radiating heat...seriously. Throwing away good energy you could be using.
It also however involves a "dictatorship of the proleteriat", i.e. one-party rule by a vanguard party of the ruling class which will establish first socialism, and then, via socialism, slowly transition to a classless society, thus achieving communism.
Politburo will never give up power. It will only transition to new hands as people learn to cheat the system. All economics is based around economy: people seek to expend the least means and gain the most ends. We call it financial sense, efficiency, productivity, greed, whatever; it's all the same thing.
Regulation ensures control over those behaviors so they produce the outcomes we call "efficiency" and "productivity" instead of the ones we call "greed". Likewise, proper social services, collective risk sharing, and other economic programs maximize efficiency.
Centralization attempts to eliminate market inefficiency: we get all these gains by uncoordinated economic actors wadding things together and exterminating each other (while trying to cheat); by focusing on societal outcomes instead of personal gain, we use that effort to improve efficiency instead of wasting it on competition. Unfortunately, we don't have any way to measure societal outcomes before implementation. We don't even have a way to define societal outcomes before implementation: your stupid selfie stick bullshit turned out to be something a bunch of people liked and wanted, and any reasonable central planner would have done something more-interesting...to politburo.
The eventual discrediting of socialism came from the recognition that a market is a huge, self-constructed (that is: efficiently-constructed) computer processing market data. That data grows exponentially with linear resource growth, so you can't get ahead of the curve unless resource usage is also the computation of optimal resource usage (= market). The free market model doesn't produce optimal results; the regulated free market produces more-optimal results; central planning does even worse than the unregulated free market. It's not perfect; it's just the best we have.
Note that this is different from "social democracy", which what you described in your first paragraph (Norway etc.), which means a mixed (state and private ownership) market economy that is extensively regulated and where there is a large state-funded social safety net.
Essentially, yes. I'm the current President of Nordic Model USA, a Social Democracy think tank and lobbying organization that seeks to bring this type of system to the United States. I'm the President because...I'm still working on the LLC filing (this organization is my back-up plan after this week's election). Part of the official policy is opposition of privatization (government service becomes private) and socialization (government takes over an industry) and support of nationalization (government fills the gap with a government-run service, as opposed to contracting with private services). That means privatization and socialization are okay if nationalization and regulation cannot achieve acceptable ends; whereas nationalization and regulation are okay if they aren't expected to produce specifically worse outcomes.
We can actually beat Norway's effectiveness with low taxes. I don't expect any tax increases in my short-term plans--which entirely eliminate homelessness and hunger, and probably recessions--and the long-term goal is something like 8% effective tax rate on the middle class and 25% on the highest income earners (although it might fall closer to 30%). Those tax rates are secondary: services first, efficiency first, fiscal responsibility first, and achieving this should create an enormous surplus which requires tax system rebalancing.
I have, as well, designed a tax strategy which allows us to essentially pick a structural progressive tax curve and set the rate. That means raising the rate by 25% (e.g. 40% to 50%) raises it by 25% on everyone: low-in
True. My point was that there isn't page protection for this.
Some high-criticality stuff, such as disk buffers, use hashing and error protection in software. ECC can get a one-bit-flip correction and two-bit-flip detection per byte (or expanded per word) at 6 bits per byte (75%) overhead. Hamming coding needs an extra two bits whenever the data size doubles, at the expense of taking longer to verify (slower), which means a 4096-bit page only needs 24 bits (3 bytes) of ECC to achieve one-bit repair, and a 4096-byte page needs 30 bits. BCH generalizes this to correct more bits, at cost of more overhead; RS does it with a slow and complex finite field algorithm that calculates every polynomial derivable from a general polynomial over a finite field describing the data.
It's possible to give up a quarter of your RAM to detect a large number of errors, although you'd probably go more like 2% and correct a handful of bit flips per page. Beyond that, just a hashing algorithm lets you eat 32 bytes and claim something rather large is probably not damaged.
Socialism is based around social ownership. Places like Norway and Iceland have strong privately-owned corporations, factor regulation, and product market deregulation. Basically, government. At the same time, they have strong government services and social insurances.
Democratic Socialism would be something like having all employees have equal voting share holding in all businesses, whereas private ownership requires you to buy shares. Credit unions are a democratic socialist type of institution, with each member owning a share in the union based on the money deposited, although that's sort of like private ownership where every member of the union is an equity partner instead of an equal partner.
Classical socialism, of course, involves the state owning everything. Single-payer healthcare with the Government owning and operating all medical practices and hospitals would be an example of a socialized healthcare system.
I favor state service covering the gap, such as by a private healthcare market, regulations around healthcare and around worker's rights (such as healthcare as a regulated benefit), and a Federal Health Insurer supplying health insurance to the uninsured. Obviously, a free market capitalism society tries to turn this socialist because employers would just try to not provide healthcare and shift the cost to the taxpayer, so you have regulation about what they need to supply and how they and the employee are taxed (e.g. payroll tax and wage tax at the same rate as the respective costs if the employee took the employer's basic healthcare) to remove the incentive.
Nationalization of a service by covering the gap from which the industry cannot profit at reasonable cost makes sense. Nationalization of an entire industry not so much. Socialization only makes sense when private industry, for technical reasons, cannot supply service efficiently (this only happens when you have a Prisoner's Dilemma issue: A and B can act independently, and the overall-optimal results are when A and B both take action X, but if A does X and B does Y then A incurs great cost and B incurs great profit, so both take action Y and achieve sub-optimal results). Usually, you can resolve that by regulation rather than socialization.
If you can deliver an average of one package per minute, that's $360,000/year.
Five trucks, five drivers at $50k, five package routes, and centralized accounting and logistics (divide your overhead by five, just about). Your accounting costs will probably be $5,000, and probably double with five trucks (probably won't nearly double tbh but what the hell?). Your per-truck cost adds onto your per-employee cost--fuel, maintenance, etc.
$250,000 for employees (including yourself if you drive), $10k for bookkeeping and accounting, $200,000 for fuel, call it half a million dollars in expenses. You need to deliver one package every 3.6 minutes for 8 hours each day, 5 days per week. That's about 16 packages per hour.
It's anti-business stuff. America's liberal arm has lost sight of liberalism and has moved to some kind of confused progressive ideology where businesses are bad, ostensibly because businesses prevent Americans from achieving the American dream of starting their own business and becoming rich and powerful and independent.
It's weird how much conservative ideology leaks into progressive rhetoric. I keep running into people so far off the deep end that they reject any aid for the poor as a stupid idea if it doesn't involve hefty taxes on the rich--and embrace taxes on the rich with zero help for the poor. Liberal ideology demands we aid those in need, not attack outsiders who don't share our social solidarity.
Slashdot Mirror
Jalopnik viciously despises Elon Musk.
At 4 miles per kWh, a 50kW charger can put 100 miles of range on your vehicle in half an hour. Not great for long road trips when your vehicle has 300 miles of range. At 80kW, with a 45-minute stop, you're actually putting 240 miles of range on the vehicle--four hours of driving.
60kWh should come to $6. Charging at high voltages is more efficient, too, so a 600VDC charger gets you quite close to actually pulling in 60kWh in 45 minutes. Likewise, future charge circuits will allow for 100kW and 120kW charging, which lets you recharge every 4 hours with a 45-minute food break if you're going 90mph.
Cross-country driving is unusual, and even the ride from Baltimore to New York City isn't even 200 miles. A 300-mile battery will make that; and most people will take at least one brief rest stop in the 3-hour drive, getting an opportunity to add 60 miles or so with just a 50kW charger in 20 minutes. The round-trip would end you with 90 miles left on the battery even if you didn't charge at your destination.
A bigger problem with the tax break was it was a tax rebate. So, if you didn't pay more than $7500 in federal tax (excluding SS and MC), you won't get the full amount. So, essentially you could fully utilize the tax break if your income was about $100,000 or more (assuming you maximized all your other tax breaks).
The biggest problem is that the tax credit shifts the demand curve.
We're giving people a limited-time opportunity to cash in on their purchase of a shiny new EV. That urgency means they're more-willing to buy and that this willingness will shift away later: the incentive vanishes and the demand curve shifts back, demand falls.
EV manufacturers profit best by exploiting this: keep the supply curve the same and raise the price to meet the new price at which the greatest profit comes. The quantity demanded at any price is higher, so a higher price commands more profit. When the incentive goes away, prices can come back down and continue with the natural market.
Instead, we should have subsidized the manufacturer for the production of each vehicle. Basically, for each vehicle, pay up to $X and no more than Y% of the gross cost.
This doesn't change the consumer's incentive to buy at a given price; nor does it place more money in the consumer's hands. In short: the demand curve doesn't move. If EV makers keep the same price, they will have the same customers.
Instead, it acts as a technological advancement: the cost to produce a unit falls. A lower cost to produce results in a shift of the supply curve: the producers are more-willing to make a specific quantity of units at a lower price. This works best in a competitive market where resulting price competition lowers profits for those producers who keep prices high.
Without a change in consumer demand, the quantity demanded at an unchanging price remains unchanged. With the supply curve shift, the quantity supplied increases at a given price--but that's not how this works: quantity supplied won't exceed quantity demanded. To take advantage, the quantity supplied must be sold, and to get additional buyers then the price must fall so as to increase the quantity demanded. Because the quantity supplied at a lower price increases with lower costs, the equilibrium pint falls to a lower price.
Demand-side approaches--tax breaks, stimulus, welfare, job guarantees--work for your whole economy. They create consumer purchasing power and jobs. If you want to effectively manipulate how much of a product moves, however, you want to surgically target its supply curve: move its price downward to increase consumer demand. You want to use this one sparingly.
See United States v. Hubbel 530 US 27 (2010); Doe v. United States 487 US 201 (1988); and Fisher v. United States 425 US 391 (1976). The Court cannot compel a defendant to reveal a safe combination.
There are ANN hardware designs wherein computer memory cells are integrated with the circuitry of artificial neurons, such as an LSTM neuron. Rather than a bunch of RAM and some program code, there's a bunch of flip-flop circuitry (RAM) built right into the neuron circuitry to create a fully-functional neuron package, along with supporting circuitry to allow programming by wiring those neurons inputs and outputs to each other how you like and writing or reading their values.
Theoretically, once you've programmed the contents and the connections, feeding input into the system would execute on-clock: if you have 5 layers of ANN, it should take 5 clock cycles to turn an input into an output. On a conventional CPU, you have to run a bunch of mathematical instructions which might take one cycle each, or be SIMD, or take multiple cycles for something like a division, or whatnot.
MIT did some interesting stuff with that.
I guess I "don't understand architecture" (despite building hundreds of successful applications.)
You can build successful applications organically. That doesn't mean they have good architecture; it just means they happen to function. Architecture affects things like how quickly large programs can be built, how readily they can be modified and extended with large and complex new features, and how likely defects are to arise. People used to talk about Microsoft rewriting nearly all of Windows every release (NT3 to NT4 to XP to Vista) because much of the core architecture was so broken as to be unusable.
So where do I go or what do I read to "get" GOF in an unambiguous way?
Now there's a question. The original GoF book was... I wouldn't read the original GoF book. Tony Bevis did a good job explaining these for Java, C#, and PHP; but it doesn't help if you're not a decent program architect. Nothing in the world will turn a non-programmer into a programmer in one sitting.
On the other hand, if you've actually built things, you should immediately recognize how to structure parts of your program into these patterns and take advantage of the benefits. This leads to one of two types of thinking: an immediate question of why when there is nothing different; or an immediate question of how to leverage this type of structure to get more out of your program with less.
I fell into that second camp. Things like decorators, proxies, and composites broke me away from lots of custom code to wire up monsters and player weapons in games. In about ten seconds, I went from, "Man, you could make a platformer where you can transform into different monsters, but you'd have to totally recode the control scheme and player movement for each one" to "holy crap, I can just replace the AI with a controller input, and use a decorator that interprets controller inputs based on weapon selected!" Suddenly programming became a game of Lego with an annoying amount of boilerplate code instead of piles of complex logic--and the boilerplate was shorter. Switch blocks in 20 places became one line of reflection in a factory.
Things I'd made work before seemed horribly-implemented, and I made them work again in much less code and much more readably and reliably.
To be fair, I also had a project management background at the time. Project management includes enormous amounts of procedure, forms, charts, and other tools; one of the most-important skills is selecting the tools you need. You don't pour the whole of project management on the smallest project, just like you don't do a whole lot of architecting for a small and temporary program designed to fill in for a permanent solution coming in two months (Risk-Based Architecture). It came naturally to me to understand that the GoF patterns weren't things you absolutely use in clearly-defined situations, but rather tools with clearly-defined functions to be used as you see fit.
The same is true of screws. Some screws have hex heads, square heads, bolt heads, philips heads, cross heads, torx heads, and other types. hex heads are recessed and require a larger area, while bolt heads stick out. Square heads self-align (they always go in straight). Philips heads strip under torque, while cross heads don't. Torx heads handle an amazing amount of torque without stripping. When do you use these? It depends on the requirements of the job at hand.
In programming, that's a much less straight-forward question. There are several ways to accomplish what I described above. Given any strategy, you would use different design patterns. It comes down to how you want to replace the boxes: what do you want to be able to do architecturally?
The best and brightest among us tend to scoff at such people, or more specifically at their stumbling and crutches, with all sorts of plausible-sounding but not actually helpful counters like "good people know what their code does", conveniently forgetting that most programmers aren't very good at all. So perhaps "patterns" are a useful crutch to keeping a lid on the damage from the inevitable Dunning-Kruger effects in business programming. I don't know, maybe.
Self-referential. You're taking the same approach, but softer: "some of us are smart enough to not need this."
Some of us are engineers and can build a house without adhering to national and international building and electrical standards and codes. That house will be structurally-sound. We'll understand how each part works and how to maintain it or build additions so it doesn't crumble.
That doesn't help every other professional who touches our stuff.
But it was only until very much later that I found this writeup
Essentially, yes. The thing he should also notice is all the complex garbage around the sensible stuff needs to be of a fixed form: it's no longer complex if it's recognizable.
Let me give you an example.
Walk over to your bookshelf, pick up a book, and open it to page 173. Read the third paragraph aloud.
Walking involves activating neurons, determining your spatial relationship with objects and the floor, tracking your velocity, checking your balance, and shifting the non-rigid form of your body (not just tilting back and forth) to redistribute your weight. It's one of the most bizarrely-complex things you can do.
Talking involves pulling multiple muscles in your throat in various ways in a pattern, while modulating your breathing and mucking about with several muscles in your mouth to change resonance cavity shape. It's ridiculous.
Picking up the book and opening to a page requires fine motor control. Reading is unbelievably-complex.
You've already internalized all of these things and do most of it based on expectations. When something unexpected happens, you respond quickly based on what you expect this new change to produce.
We could argue this all day; although I'd rather ask Peter Gutmann, who once made an observation about why we all use SSL instead of something much better we designed this morning over coffee. If you're really onto something, you should teach everybody else this new methodology so we can all benefit.
The guy who got the letter says it's all good and he'll work on making Paypal handle this better so they don't upset other people.
To be fair you have the same problem with encapsulation and output/results too
Only at the interface. People will write code that does things to things, and then reuse calls to that code to incrementally do things to things instead of extending the interface on an object to say you can now do a thing to a thing (or creating a filter, or whatever else they could do to achieve the same). Then, when you modify those innards, things break.
Sometimes, two pieces of those innards are glued together in such a way that they always work. For example: I could perform a boundary check before sending a call to a function which copies data into a pre-allocated buffer. A different body of code can then make an unchecked call that always works, until someone calls that body of code from a long chain of logic that ultimately didn't have the same boundary checking and gets an occasional buffer overflow in unlikely situations (because they called a function which allocates, did some transformations, then called a function which copies).
This is why you wrap things up into little boxes with buttons and switches on the outside. Nobody directly calls those things, and everything continues to work because you're forced to not do this goofy shit.
We've all hotwired the boxes, though, because we're all clever enough to stick our necks in places they don't belong despite the warning signs and barbed wire.
People made larger architectural patterns like MVC and declared them replacement, in the same way someone might declare "Victorian" a replacement for joist-and-subfloor floors. I've found the GoF patterns have served well where people used them, and people have found them unclear when they didn't understand architecture.
Can you provide examples of where, how, and why GoF patterns failed?
This is why some of us are insistent that the decades of experience which gave rise to design patterns actually means something. Folks often counter argue that good programmers "know what their code does" and so the mess of unstructured spaghetti code is fine "as long as it works"; they don't believe in engineering in containment of bugs and impact.
When you build your code to be a set of tools with defined behaviors and interfaces, you encapsulate bugs. An error in one piece of code creates a defect in the interface, which you correct in one place. This seems like something wholly-imaginary until you realize un-breaking a bug in many flat programs causes unexpected behavior due to other code relying on the defective logic's incorrect impact on some program state.
In an ideal world, none of this would matter. We do all this stuff because it matters in the real world.
Thanks, that helps. Not sure where I read that or if it's just been too long and my memory is distorted. There were all kinds of bizarre claims about this guy.
One theory claims D.B. Cooper must have died because he took a parachute that was a dummy parachute, and so would have had just a stuffed backpack when he jumped. People believe this despite obvious questions like "why would you have something like that on a commercial airplane?" and "where is the body?"
Interesting. That's actually a better estimate than prognosticating on land reserves, because you can actually go around and just measure seawater all over the place with all the research vessels already trafficking the planet.
Once in a while, when renewable energy comes up, I make some bizarre statements about the implications of heat pumps having a greater-than-unity COP and recouperative and adiabatic processes being a real thing. If anyone ever actually builds a working model of that kind of process, the energy economy will immediately become lulzy.
It's not even mathematically-impossible: it's just sucking energy from ambient environment, and the capture from ambient source needs to be bigger than the loss to ambient source. Remember a heat pump can expend 1kW and move more than 1kW--many residential consumer units have a COP of 2.8, and some are over 3--and that 1kW of work energy has to go somewhere, so you take 3kW from the cold end and spit 4kW into the hot end (this is how your AC actually works, and why a 600W dehumidifier is a 600W space heater). If you force this into a heat storage medium, you've still got loss everywhere--your engine, your heat pump itself (which most likely is driving the extra heat where you want it to go anyway), etc. Insulation, piping, and fancy engineering can get you an adiabatic system; but if you have 40% loss and only 30% (i.e. 75%) recovery plus pull 8% more energy from ambient air, you're net-losing (40% energy lost, 38% energy recovered, 2% net loss).
We think, in practice, that our adiabatic storage tech can break 90% recuperation. In theory, it's 100%.
inb4 trolling engineers.
Yeah, all the known uranium only amounts to that much. We're pretty sure (based on scientific knowledge, not magical guesses or actual measurements) that there's more out there, in the same way we're pretty sure there are new and undiscovered oil fields with a huge amount of new oil (I've heard predictions that 1/3 to 2/3 of the oil in the world hasn't even been discovered yet).
Sigh...external heat rejection. Really?
Look, a heat pump can't feed itself from its own reservoir, right? Well, let's put you in front of an air conditioner. The air's cool, right? Go behind and it's hot. Notice it's the same atmospheric reservoir? Same is true in Canada: it's cold up there, but really hot in Florida.
The earth's single reservoir--the atmosphere--has non-uniform thermal energy. Essentially, it's being heated by the sun, and emits radiation to space at a faster rate if temperature is higher, given the same atmospheric and surface composition. That makes it a storage reservoir for solar energy.
By coupling a heat pump and a heat engine, you can pump heat into a pressure vessel, then dump the pressurized gas into a heat engine (compressed air engine). You can use this to drive a compressor to pressurize your pressure vessel.
Typically, you lose heat this way: although the heat engine will tend to cool air relative to intake, you're adding hot air and so it's coming out warm. You're going through the effort of heating that air, thus if the exhaust is hotter than the atmosphere, you're losing that differential to the air.
Theoretically, if you built an adiabatic system, you could recover much of this loss. A heat pump with the cold side coupled to (and insulated with) the exhaust output when above atmospheric temperature would do it. At the same time, your primary heat source is the atmospheric intake. You insulate your pressure vessel and couple the cold side of the heat pump into that.
The work done by the engine turns the heat pump as well: the working energy driving the compressor and the heat pump, generally lost as heat, are pressed into your pressure vessel.
In this way, you theoretically pull the heat out of the local atmosphere--reducing the room temperature--and store it in an insulated bottle. If you cogenerate electricity or liquefy atmospheric CO2 and H2O into non-aromatic hydrocarbon fuel oil, you remove some of the heat (which leaks even through insulation) and store it as stable chemical bond energy.
This all requires things like aerogel (which we have) and quantum tunneling junctions (which we have at too low yield to actually function) to become even theoretically-possible.
So, yeah. Adiabatic thermal concentrator. Radiating heat...seriously. Throwing away good energy you could be using.
At current consumption, we have 90 years's worth of uranium ore around. We expect to find more, because there's got to be more.
Imagine ramping up from 20GW to 200GW of electricity production by nuclear in the US, and similarly around the world. 9 years's worth of uranium ore.
I'm not certain the known uranium resource is enough to power our current electricity consumption for one full year.
I don't see how coating with copper is impressive, tbh. I'd rather see a polymer that is itself antibacterial.
It also however involves a "dictatorship of the proleteriat", i.e. one-party rule by a vanguard party of the ruling class which will establish first socialism, and then, via socialism, slowly transition to a classless society, thus achieving communism.
Politburo will never give up power. It will only transition to new hands as people learn to cheat the system. All economics is based around economy: people seek to expend the least means and gain the most ends. We call it financial sense, efficiency, productivity, greed, whatever; it's all the same thing.
Regulation ensures control over those behaviors so they produce the outcomes we call "efficiency" and "productivity" instead of the ones we call "greed". Likewise, proper social services, collective risk sharing, and other economic programs maximize efficiency.
Centralization attempts to eliminate market inefficiency: we get all these gains by uncoordinated economic actors wadding things together and exterminating each other (while trying to cheat); by focusing on societal outcomes instead of personal gain, we use that effort to improve efficiency instead of wasting it on competition. Unfortunately, we don't have any way to measure societal outcomes before implementation. We don't even have a way to define societal outcomes before implementation: your stupid selfie stick bullshit turned out to be something a bunch of people liked and wanted, and any reasonable central planner would have done something more-interesting...to politburo.
The eventual discrediting of socialism came from the recognition that a market is a huge, self-constructed (that is: efficiently-constructed) computer processing market data. That data grows exponentially with linear resource growth, so you can't get ahead of the curve unless resource usage is also the computation of optimal resource usage (= market). The free market model doesn't produce optimal results; the regulated free market produces more-optimal results; central planning does even worse than the unregulated free market. It's not perfect; it's just the best we have.
Note that this is different from "social democracy", which what you described in your first paragraph (Norway etc.), which means a mixed (state and private ownership) market economy that is extensively regulated and where there is a large state-funded social safety net.
Essentially, yes. I'm the current President of Nordic Model USA, a Social Democracy think tank and lobbying organization that seeks to bring this type of system to the United States. I'm the President because...I'm still working on the LLC filing (this organization is my back-up plan after this week's election). Part of the official policy is opposition of privatization (government service becomes private) and socialization (government takes over an industry) and support of nationalization (government fills the gap with a government-run service, as opposed to contracting with private services). That means privatization and socialization are okay if nationalization and regulation cannot achieve acceptable ends; whereas nationalization and regulation are okay if they aren't expected to produce specifically worse outcomes.
We can actually beat Norway's effectiveness with low taxes. I don't expect any tax increases in my short-term plans--which entirely eliminate homelessness and hunger, and probably recessions--and the long-term goal is something like 8% effective tax rate on the middle class and 25% on the highest income earners (although it might fall closer to 30%). Those tax rates are secondary: services first, efficiency first, fiscal responsibility first, and achieving this should create an enormous surplus which requires tax system rebalancing.
I have, as well, designed a tax strategy which allows us to essentially pick a structural progressive tax curve and set the rate. That means raising the rate by 25% (e.g. 40% to 50%) raises it by 25% on everyone: low-in
True. My point was that there isn't page protection for this.
Some high-criticality stuff, such as disk buffers, use hashing and error protection in software. ECC can get a one-bit-flip correction and two-bit-flip detection per byte (or expanded per word) at 6 bits per byte (75%) overhead. Hamming coding needs an extra two bits whenever the data size doubles, at the expense of taking longer to verify (slower), which means a 4096-bit page only needs 24 bits (3 bytes) of ECC to achieve one-bit repair, and a 4096-byte page needs 30 bits. BCH generalizes this to correct more bits, at cost of more overhead; RS does it with a slow and complex finite field algorithm that calculates every polynomial derivable from a general polynomial over a finite field describing the data.
It's possible to give up a quarter of your RAM to detect a large number of errors, although you'd probably go more like 2% and correct a handful of bit flips per page. Beyond that, just a hashing algorithm lets you eat 32 bytes and claim something rather large is probably not damaged.
Socialism is based around social ownership. Places like Norway and Iceland have strong privately-owned corporations, factor regulation, and product market deregulation. Basically, government. At the same time, they have strong government services and social insurances.
Democratic Socialism would be something like having all employees have equal voting share holding in all businesses, whereas private ownership requires you to buy shares. Credit unions are a democratic socialist type of institution, with each member owning a share in the union based on the money deposited, although that's sort of like private ownership where every member of the union is an equity partner instead of an equal partner.
Classical socialism, of course, involves the state owning everything. Single-payer healthcare with the Government owning and operating all medical practices and hospitals would be an example of a socialized healthcare system.
I favor state service covering the gap, such as by a private healthcare market, regulations around healthcare and around worker's rights (such as healthcare as a regulated benefit), and a Federal Health Insurer supplying health insurance to the uninsured. Obviously, a free market capitalism society tries to turn this socialist because employers would just try to not provide healthcare and shift the cost to the taxpayer, so you have regulation about what they need to supply and how they and the employee are taxed (e.g. payroll tax and wage tax at the same rate as the respective costs if the employee took the employer's basic healthcare) to remove the incentive.
Nationalization of a service by covering the gap from which the industry cannot profit at reasonable cost makes sense. Nationalization of an entire industry not so much. Socialization only makes sense when private industry, for technical reasons, cannot supply service efficiently (this only happens when you have a Prisoner's Dilemma issue: A and B can act independently, and the overall-optimal results are when A and B both take action X, but if A does X and B does Y then A incurs great cost and B incurs great profit, so both take action Y and achieve sub-optimal results). Usually, you can resolve that by regulation rather than socialization.
True. My rooms are usually not ambient due to air circulation, electronic gyzmos, and coupled walls.
If you can deliver an average of one package per minute, that's $360,000/year.
Five trucks, five drivers at $50k, five package routes, and centralized accounting and logistics (divide your overhead by five, just about). Your accounting costs will probably be $5,000, and probably double with five trucks (probably won't nearly double tbh but what the hell?). Your per-truck cost adds onto your per-employee cost--fuel, maintenance, etc.
$250,000 for employees (including yourself if you drive), $10k for bookkeeping and accounting, $200,000 for fuel, call it half a million dollars in expenses. You need to deliver one package every 3.6 minutes for 8 hours each day, 5 days per week. That's about 16 packages per hour.
It's anti-business stuff. America's liberal arm has lost sight of liberalism and has moved to some kind of confused progressive ideology where businesses are bad, ostensibly because businesses prevent Americans from achieving the American dream of starting their own business and becoming rich and powerful and independent.
It's weird how much conservative ideology leaks into progressive rhetoric. I keep running into people so far off the deep end that they reject any aid for the poor as a stupid idea if it doesn't involve hefty taxes on the rich--and embrace taxes on the rich with zero help for the poor. Liberal ideology demands we aid those in need, not attack outsiders who don't share our social solidarity.
Nah, you organize your business behind an LLC and indemnify all officers and directors and members.