mntmoss

This can also be predicted in terms of realpolitik. If the power of nations tends to consolidate along predictable lines, then the political question at any moment is reduced to a left-right "rate of reform" along each axis, with the furthest right positions being near-zero rates of change, but all viable positions serving the purpose of ensuring power for the stakeholders. This makes the right tend to automatically converge onto a mythologized moment in the past where their power is greatest - rights of kings, supremacy myths, and so on, while the left goes in a spectrum of directions but must ultimately form a singular coalition in order to gain power. Thus the prevailing tendency of left-right politics is also one of leaps forward from the left and gradual slides back from the right as the coalition breaks down. The new consensus is different from the old, but it's also typically not the most ideologically left one, since it emerges to compromise with the present realities, and the more radical you go, the more it resembles blood-in-the-streets revolution, which is a huge roll of the dice.

The developed world as a whole seems to be approaching one of those "great leap" moments today as more and more issues have fallen into partisan extremism, motivating the search for a new consensus.

I myself can't tell if this feeling is just me getting older. I liked the shiny dynamic stuff when I was younger. Gradually I found myself ignoring more of it and developing more specific rules for what I wanted out of the UX. When a recent thread on "calm computing" mentioned Fraidycat I took to it immediately. It's nearly the antithesis of the news feed - there's no repetitive rhythm to it, although there is a bit of clicking around. There was a time when I actually wanted news feeds, I would cycle through a few sites and F5 constantly.

I know a few twenty-somethings who are still falling for shiny stuff. I don't think that's going away, but I do think the overall culture will come to realize that it's junk food computing.

Whether 100Mb usage is unacceptably large is mostly dependent on the precise features in play:

* 32-bit vs 64-bit application(64 bit will bloat all pointers)

* Methods of loading and editing documents(modern editing attempts a lot of introspection based on highlighting syntax or project environment)

* Character encoding support(Supporting current Unicode rendering would almost immediately take you beyond 4Mb)

Interactive editing is a pretty memory-hungry task compared to a simple viewer or batch processor. There's more reason to keep things cached. If you actually go back to old text editor versions from the days of 4Mb desktops, you'll find yourself missing stuff. Not so much that you can't get by, but enough to give pause and consider taking the hit.

The great lie that games tend to run with is that if they define a sufficiently large lookup table of results, they get a convincing effect without being accurate to any form of reality.

This is basically true with almost all character controller behaviors(perfect ability to jump high, sidestep, slide etc. without stumbling) and also with combat results(add enough animations and you have a melee combat system; turn granular physical reactions like bullet impacts into a state change making the target "hurt" or "stunned"). And it's even true of the earliest ball-and-bat games: reduce hitting a ball to a lookup table of trajectories and you get Pong without having any trigonometry in your algorithm. You can define a massive swathe of gameplay code as combinations of "lookup table, finite state, timers, resource counters".

This is also true of the physics solvers: define the solver in terms of eliminating all the visibly wrong results(which in the base case means filtering the set of results that contain penetration), and you have one sufficiently good for gameplay. For 2D games this has classically meant solving AABB-AABB movements along 1 axis at a time(i.e. if your raycast is diagonal it's reduced to two one dimensional on-axis movements, which is trivial to compute). Once you want realistic physics as a "special effect" you typically will switch towards using a physics library to provide both solver and colliders, and so as a gameplay programmer you may never have to learn the physics problem in much depth.

The video games that really work with physics instead of against them are kind of exceptional, and tend to be categorized as "simulators" - flight sim, racing sim, pool sim, pinball sim. Or they are joke games like QWOP, or at their most fantastic, space games. When we actually simulate anything, the scenario-and-story space tends to reduce dramatically as everything starts converging around the sim's chaos. As we eliminate the sim, more can exist in the designer-fiat space. That's how we can have games about wrestling and swordfighting and yet not really be able to convey the physics or controls of those activities.

Something tells me that it's related to the relative independence that school age kids experience in Japan when outside of school. Long solo commutes on transit are OK even for older grade schoolers. And the pop culture tends to put a lot of emphasis on the school age "best years of our lives" trope - witness the endless number of high school manga settings - because the working age world in Japan still offers comparatively longer hours and less freedom. If you take that thought to its cynical conclusion, that you cease to be a person with any kind of personality or agency after graduation - well, why respect the school system and the class popularity contests?

In the U.S. the helicopter parenting strategy mostly prevails since society has a tendency to call the cops on "negligent" parenting. There's a ton of focus on attendance numbers and graduation rates. Depending on where you are, school can be an academic pressure cooker or a pipeline into the prison system. There are more immigrant communities pushing for "first in the family" success stories. And so the attention of the student gets away from how bad school is and gets diverted towards "surviving the zombie apocalypse/battle royale and riding off into the sunset".

Many people entering adulthood here, at least since the recession and perhaps earlier, experience a crisis a short while after they graduate and enter the workforce because they have been so steadfastly committed to this kinds of script from an early age that they can't reflect properly until much later, and then it hits like a freight train that they might be wrong, their identity is incompletely constructed, and the story did not end with them riding off into the sunset.

As someone who frequently dabbled in but rarely contributed to the MZX scene, I can concur. There were a lot of formative experiences in it, even though the nature of the tools, unlike ZZT which has always been very productive for a certain kind of gameplay, often drove creators away from completion and into demoscene-esque hacking to break the limits and make their games more like "real" games. I was most engaged with it in its first years before going open-source, 1995-98 or so. The development since then has made it even more of a curiosity, with so many ways to customize your project in a way that will vastly expand its potential scope.

But it was a friendly environment to start in, and didn't try to push you towards professionalizing as tends to be the case with modern game engines - there were plenty of MZX games that I enjoyed and completed in test mode after getting softlocked by some bug and going out to the editor to fix it. There's a lesson in that, for sure - far different from the climate of Steam review comments.

So long as your data has well-defined interface boundaries on it, this is a good way to de-risk rewrites. It really depends on the current state of the codebase. If there's a tangle of dependencies, then they have to be cleared out or facaded away to a testable interface, or else that part of the port will be a shot in the dark.

And if you have the interfaces in hand, the language itself becomes considerably less important, since more of the code is subsequently dependent on your own system and not really the outer ecosystem. It's the projects that have coded "to the metal" on their existing platform that have the biggest issues with keeping up their flexibility.

Something I have gotten more attuned to over time is the importance of the message format - i.e. the medium - in defining the message.

That is, the way in which the message is specified changes the classes of errors and development challenges one might encounter. If function arguments are positional you get positional errors; if they are named you enter the business of defining many more types. Messages may return a different version of themselves(e.g. arithmetic) or a different category of message. The later in time the message is delivered, the more it has to carry around its own context. And when a message has unbounded scope it has unbounded complexity.

And like with a lot of things, there aren't silver bullets. Many things can be defined as a single enumerated value. Sometimes tuples are nice, sometimes records are nice. Sometimes the problem expands to the point where you have to have a message with a little computer inside it - but when that happens it's usually not for the purpose of any specific task, it's to add a layer of programmability into the system.

There's also a lot of sticky points at the bottom of the stack that lead towards native solutions, starting with memory management and basic I/O functionality. Nobody wants to code directly against the hardware for very long, so you end up with a driver, and then driver and resource management, and then an operating system of some kind. Even on the early microcomputers it was the case that you have a boot ROM of some sort and would code against that for most tasks.

With WASM you have the same kind of thing but the added wrinkle of the browser-based I/O being a different set of "basic abstractions" from what you get in libc, and every solution that bridges the gap being a bit of a hack. Being bytecode doesn't really change the fact that you still have to deal with the resulting dependencies at some level.

His point remains reasonable, though: If all you did was dump the resulting artifacts of a learning or self-edification exercise online, you didn't make a product like a Firefox or MySQL. And to the extent that people use your code, it's most likely as part of a similar journey to yours, and studying that code is not hugely different from studying books and whitepapers, even if the code is easier to leverage. But people were doing this before "open source" became a thing, and in a manner more befitting the role of such code: as part of a text file documenting the core concepts and posted on a BBS or Usenet, so that you could program the same thing. It's the kind of thing that would be a blogpost now. The actual code? Usually only the really deep, underlying algorithms need that spelled out.

It's only when you make a full system that the end user can get value out of that you get into the scenario he outlines. Somewhere in the middle in between the simple code dump and Firefox, open source tends to sink into a quagmire where it looks like a product but it's not supported like a product. And the only good answers then seem to be "go small" (impose LOC limits and hard constraints on features you ship so that maintenance drifts towards stability) or "commoditize" (become part of someone's product in a way that gets you paid).

The money going into SF is big enough these days(just look at the city budget, it's a multiple of similarly large cities elsewhere in the US) that the government has fallen into a default of over-regulating everything and then carving out shortcuts and excemptions, and this isn't a new trend, even - SF has always been expensive but the pay-to-play system really started picking up steam with Willie Brown's mayorship back in the 90's, amid the original dot-com boom.

When a city is "hot" and the working population is very transient, which is the case with SF's new tech workforce, nobody is really being a watchdog. The existing property owners will drift along, yelling about anything that might concievably affect their property values, and they get thrown bones to stay complacent since they're the most consistent voters. But they don't pay rent, and the majority of the workers still expect to be here as a career stepping stone and then move on to somewhere that doesn't suck, and so they put up with the rent and don't put down roots. People staying long-term under rent control hang onto their position for as long as they can. There's a lot of kicking cans down roads going on, hence the system trundles on.

The years around 1970 are one of those inflection points that is a lot like the causes of the Industrial Revolution: it can't be summed into a few easy factors.

For me the defining thing is the emergence of the USA from the postwar politics and policies and into more of an assumed administrator of the globalization project, a status that it retained until just recently.

Besides the information systems, international containerization standards were settled around this time and jet travel was becoming more affordable. A lot of pieces were in place to renegotiate trade and labor deals. And there was a break with numerous social policies; the calls from think-tanks to reinstate a stratified society started coming out at this time too. Big public infrastructure projects mostly died out in the 70's, and the narcotic drug trade from Mexico and the resulting "drug wars" picked up in the late 60's, conveniently just in time for amphetamenes to fall out of favor.

So, the move away from gold is just one of numerous things that changed in a surpisingly short time frame.

In Portland, OR, there is substantial transit infrastructure, but the results are a bit mixed. Everyone agrees that it is easy to get around most of the city, but its suburban areas tend to experience the same low-density/high-prices phenomenon that is seen in other coastal cities.

Why? Last I read on the topic, it's because the market is factoring in the potential value of each parcel when built out according to what infrastructure dictates, but without actually building it. So small garages built 50 years ago are getting priced like 8-story apartments.

Actually building to meet the demand is the thing that lowers the rent, and that comes down to raising the inflow of building permits each year. That's the part that has to be solved.

One of the things that Japan does besides having a lot of trains is a standardized national zoning code that makes planning and permitting much more straightforward. Building in Japan is much more of a commodity, and the prices reflect that. And an example of relaxed building rules in the USA is Houston, which has long had a cool yet expanding housing market, but a car-centric one.

The effect of the combination of the trains and low regulation in Japan is that you get dense/cheap cities - and with fast trains, all of Japan acts as a "suburb of Tokyo". Trains and regulation gives you PDX. Cars and low regulation and you get Houston. Cars and regulation and you get regional SF.

By comparing these different outcomes something like a coherent theory occurs: population in the industrial era always tends to urbanize. If we restrict the flow in some way, we get high priced urban areas; the specifics of infrastructure choices are just one factor, and not necessarily the biggest. But population growth itself is a national issue and comes from other demographic factors(immigration, childbearing rates, death rates). And although Tokyo still gets bigger, which is indicative that urbanization isn't "done", Japan as a whole is on the decline.

I basically agree. In my experience as a rider of one, the main downside of urban kick scooters is that they lack infrastructure. They're too slow to be bikes and play in traffic, but their existence tends to offend and frighten pedestrians, even though their control over acceleration is quite good, about as good as someone running. That quality makes them chimerical, one of the most unpredictable users of the road, and one of the factors in me hanging it up was having my day ruined by people getting upset at me.

The biggest real dangers come from grooves and potholes(I took a spill that needed stitches in my younger days, trying to ride inside a groove) and from using pedestrian infrastructure at speed(cross-traffic can lead to near-misses where the car doesn't expect you to jump out so fast, or the bike expects you to plow through and you stop instead).

The electrics are a nifty invention, but also one that makes their character more like bikes. They fit in a little better as all-purpose transports, but they also lack the simple convenience of a light kick scooter.

Lucasfilm? Pixar? EA? It's not exactly hard to spot the impact on pop culture.

The only parts of the Bay Area that don't match that description are Marin and Monterey.

I made the observation just a day or two ago to a friend, that when I decided I would invest in a lot of storage, I also had to invest in even more to be able to do backups...and then to perform those backups I have to be able to sync the data effectively, which has some natural scaling limits and introduces ergonomic concerns. After a certain point I threw up my hands and said, "okay, I guess the amount of data I can reasonably keep track of is roughly the amount I can keep synced across multiple devices". So, for the consumer equipment I am using regularly, a few terabytes at most.

And that solves the problem in the sense of "I have some form of redundancy", but not "I am confident that it's durable", and definitely not "I am actually curating the data at archival quality".

But when I investigated using PAR2 I had another thought, which is that, in a sense, this is a quality-of-service type of issue, and those are always subject to variable standards. And part of my problem is like what you allude to - I can't easily specify how important the data is. If only I could just say, "I only somewhat care about these commercial multi-gigabyte sample libraries, but I care deeply about my password database, so please do the right thing with each." And that's something that - whether it's surfaced to the app or to the user - it really needs a much greater degree of coordination to pull off. As it is, there's a lot of redundant guesswork taking place.

These kinds of questions have an essential unknowability to them, in that every phenomenon you try to model through computing is an inexact approximation - whether it's something like the precision of a mathematical computation or "what is this human being's real name".

What we have done to date is the low-hanging fruit: take known categories of application and juice them up by applying CPU power. And for that, the amount of power you need is "enough to have an effect". A lion's share of the benefits of putting computers in the loop were realized in the 70's or 80's, even though the measured amount of power that could be applied then was relatively miniscule. There were plenty of alternatives at various times that were "better" or "worse" in some technical sense, but succeeded or failed based on other market factors. The real story going forward from then has been changes in I/O interfaces, connectivity and portability - computing has merely "kept up with" the demands imposed by having higher definition display, networking, etc.

So then we have to ask, what are the remaining apps? If we can engineer a new piece of hardware that addresses those, it'll see some adoption. And that's the thrust of going parallel: It'll potentially hit more categories at once than trying to do custom fast silicon for single tasks.

But the long-term trend is likely to be one of consolidating the bottom end of the market with better domain solutions. These solutions can be software-first, hardware-later, because the software now has the breathing room to define the solution space and work with the problem domain abstractly, instead of being totally beholden to "worse-is-better" market forces.

I can think of plenty of tasks where a 2009 frontend will potentially be exposed to workloads in the 10k-100k elements range:

* Editing objects in a 3D scene(e.g. a AAA open-world game or a CGI film)

* Plotting events in a long-running log on a graph

* Scraping and presenting data from web sources

The common thread here is that you have most of your data in application memory but not necessarily in a formal database system, and so you shoulder the full burden of managing it properly. In most cases the solution is to define a real backend and filter it there, paginate or otherwise reduce the amount that gets presented because data at that scale won't be usable by humans to begin with. But sometimes you do have a reason to explicitly want a "big list of everything," and equally as often you end up with the big list of everything just by accident. It just comes with the territory of report generation tasks.

I think the appropriate way to view this is not just as that this domain needs "SAT" (which enforces standardized algorithms as "the solution") so much as it describes an urgent need to popularize the concept of constraint satisfaction and optimization problems as a domain of coding that programmers actually deal with regularly and informally. Being able to sort, search and rank is the first step to having a backtracking solver, a technique that is very powerful and generalizable(albeit slow). But how many CS programs teach you to write solvers?

Our education methods could do a lot more to draw this technique into its applications. For example, in game programming, satisfaction tends to come up rather abruptly when talking about physics solvers; not because it's only needed then, but because the jargon was appropriated from academic simulation papers, and it comes as part of a sudden bomb of math concepts, making it look more intimidating than it is. Non-realistic physics are just called "collision code", handwaved away and not given a great deal of formal attention, even though they are performing the work of solvers too, just usually with a mix of linear programming and local search. As such, a lot of new game programmers get stuck on collision problems and concurrency bugs that result from poorly constrained solutions, because they don't have the conceptual tools surfaced to reason about it with confidence.

Likewise there are plenty of CRUD-style apps where a solver is a helpful building block for creating views and filters, but it's not approached as one, so you just get a buggy feature.

Recently I decided that I was going to solve the problem of: I easily write inline TODO comments while I work on code, but then have difficulty keeping track of them and getting my head back into the state of things later. While there is IDE support for such things, it's usually not exactly the right interface I want.

So I made a tiny CLI app that scans the source for TODO and FIXME lines and presents a menu of files, containing the number of items to work on in each. Then I type in which file I want to work on and it instantly reports all relevant lines, plus successive comment lines. All I have to do is punch in the line number and start working.

I felt a kind of stress relief almost instantly after doing this. It's better than Trello for me.

If I need to add additional kinds of data sources, many syntaxes, etc. it might become a bit more complex, but still managable as long as there's an API to get some plaintext lines out. It's basically following up on the hypothesis of a lot of information tools today: it isn't the data generation that's the issue, but the filtering.

One of the things that makes me sigh is how we've gone and built up a huge slate of "required features" for apps that are very effective at professionalizing software and yet may not do much of anything for the end user.

In that respect I think we've hit some kind of endgame for software as it's historically been done - the bells-and-whistles show - because smaller, more targeted software so often hits the mark better.

For example, when people ask how to get into playing piano, I steer them away from a MIDI controller and software and towards the cheap home portable hardware. The hardware has nearly ideal software for the task: it starts instantly, never crashes or glitches, never needs to update, can only be hacked with physical access, has ideal latency, and does not require additional plugs or configuration. Put in batteries and flip the switch and you can practice. And past the very most inexpensive ones, they all have the connectivity needed to control software.

And yet many technically inclined people - my previous self, friends, etc. - will hear that recommendation and still opt for that MIDI controller and get a gadget with more knobs and wheels, instead of a perfect learning tool, just because of the temptations of software that could "do anything." There's a shopper's high in it. But guess what the last software purchase I made was? An emulation of old home portable keyboard sounds(Plogue PortaFM). What goes around, comes around.

He doesn't call the closed tools part of the problem, rather he asks why it is the case that these tools remain more successful at engaging newcomers than all the open source stuff, and draws a connection between the fully proprietary devices of yesteryear and these modern environments:

Whatever the causes, we have software and hardware systems that strive to be entirely open, yet time and again are closed ones that are more accessible in practice, that drive social revolutions. Linux didn't change the desktop, nor the way software is made.

And he suggests the answer that's been in the air lately: open software is now seen as a corporate business strategy, a cost-cutting measure. Which in turn means that proprietary software is now the stuff at the vanguard for the "little guy", creatively speaking, and many of the old hacker credos that correlate with "information wants to be free" are false, are in fact as elitist as you state.

In an actual scene, you also have an underlying set of game rules guiding it which the actors are negotiating through.

It is possible for the characters to disagree with each other if it's not blocking - it allows the scene to continue to develop instead of shutting it down. In this case, disagreement over the weather would become the focus of the action.

"It is snowing."

"Oh, what a kidder you are, Smith! Just look at the shorts I'm wearing, it's fun in the sun time."

"Jones, my breath is visible. You are clearly on a different planet from me."

"Well, as it so happens, I AM an alien!" pause for laughter

--

And yes, there's a limit to the method when in a business setting. Business machinery is set up to grind out ugly, practical compromises and can't inject fantasy into the equation like that very often in the lower branches of the org, but it often benefits from this creativity when we're talking about executive leadership figuring out what the org needs to look like to succeed in the future.

The thing I detest about discussions of code aesthetics is the idea that the quality metrics you speak of have such a direct relationship to the "product features" of the language, that we can simply know it's good by looking at it, and we are hapless simpletons unable to write this so-called "beautiful" or "clean" code if we do not have the feature available. That is all bullshit. Most of the features are shiny baubles for raccoons and magpies, I do NOT know what good code looks like(I can only state whether the coding style eliminates some class of errors), and what matters the most is the overall shape of the tooling.

Some languages have a big bag of tricks, other languages let you extend them to the moon, and still others make you work at it a little. In the end it's all just computation, and the tool choice can be reduced to a list of "must haves" and "cannots". If you need more expressive power -- make your build a little more complex and start generating code, give it a small notion of types or static invariants. It only has to generalize as much as your problem does, and that leads you to build the right abstraction instead of dumping an untried language feature on the problem in the hope that it is a solution.

You have ample room to define the hardware you want to see, though. [0] Setting bytes in a buffer isn't some ultimate graphics abstraction: it's just one way to express it at a low level, and only capable of drawing anything of interest in the sense that a Turing Machine can compute anything that can be expressed digitally. You're gonna crave higher level concepts really quickly. And going higher level does come with its own limits, but that's always been the case. Every sufficiently complex production graphics renderer will eventually develop some kind of hybrid approach to the data representation while achieving the necessary flexibility: Simply define line segment drawing, and boom, suddenly you have a vector-to-raster pipeline. Or, maybe you have a sprite all laid out perfectly for fast memory copies. But then you have to clip it against the screen bounds, add a mask so that it can overdraw, and so on...and so you end up carrying geometry and color data around too. And if you desire to do something fancy like scale and rotate it, you will probably define it not in terms of bytes but in terms of linear algebra, so now you have a requirement for some matrix math.

And the only way in which we're more limited is when we start talking about distributing the work, creating products. Then we start saying, "well, that API doesn't let me dip into the hardware to create the abstraction I need." But that's because we moved the goalposts from "it can run on a computer" to "it can run on many people's computers, in many different contexts." And back in the day that really was never a guaranteed thing. There were stark differences between platforms, and many ports amounted to remakes.

So, then, does it matter? Does "minimalism" in programming even functionally exist, given our unsatiable appetite for dependencies?

[0] https://prog21.dadgum.com/66.html

In my opinion, every great work needs its justifying myth. If you don't have that, you won't have the confidence to pursue it further.

That doesn't mean that the myth is necessarily a good, ethical or healthy one. A lot of myths are of the form of "worthy sacrifice." Others are of the "defending oneself" sort, or the "ascent to greatness". The myth is made to fit the times and the task.

Organizations, and teams in those organizations, often take on their myths without consciously thinking about it. But it's absolutely critical to have them there to set the tone and allow everyone to proceed on the same page.

I remember taking a phone screen with this company circa 2015. Mostly, I remember the recruiter on the other end doing an incredibly good job of selling me on the company being a great idea and a place I want to work at. I don't think I heard back from them again after that.

In retrospect it feels to me like one of those businesses that probably deserves a second wave of attempts when the landscape has shifted a little more.

Raku represents quite an advancement on Perl 5. Perl was a "kitchen sink" scripting language when it debuted, and Raku is a modern take on that, which means that it has lots of undiscovered corners still, places that will likely be major programming paradigms of tomorrow.

The thing I think the spaghetti visual graphs get wrong is a lack of adherence to the structured programming theorem. Most data flows are mostly linear/sequential, and DAGs - which also can be expressed linearly as "send/jump ahead but not backwards", cover most of the rest. Complex structures that need to describe comprehensive fanin/fanout/feedback functionality are exceptions, and as with uses of "goto" in structured languages, most can be reduced to an implementation detail of a single node. So presenting all the options on every node, every time, with cable wiring going everywhere, is a very cluttered syntax for something that could usually be a "Lego brick" expression.

The beauty of stack languages is shared with that of RPN calculators and their postfix syntax model: You can enter the expression very quickly and precisely. Parens and operators don't "get in the way". Names aren't needed for temporary values. Small modifications don't require a rewrite. They feel mostly linear when "in their wheelhouse."

Where postfix starts losing to prefix and infix is when you have something that requires a lot of scanning back and forth to determine state. Function arguments lack clarity. Stack underflow becomes a real failure case. The scaling in terms of readability isn't very good, so "don't write large words" becomes an imperative when it's a generalized programming syntax as in Forth.

The language I'm working on right now currently uses RPN for single-line, compile-time expressions, while runtime evaluation is vertical and operates entirely in terms of keyword prefix + memory addresses, like an assembler. This constrains the scope in two ways, giving it a "twice linear" feel since left-to-right is the compile-time world while top-to-bottom is the runtime world, and those worlds only really cross over in terms of referring to compile-time identifiers(e.g. label and variable declarations, type evaluation). Since left to right is all compile-time, the meaning of an expression can vary a lot depending on the keyword, and so to expand the language I also have the option of adding original single-line DSLs to target specific runtime expressions, if I can't get what I want by adding more types to the RPN system. This is intended for small inline programs called from scripting so the at-scale view of composability isn't the main priority. It's still early, though, so I'll see how that all works out in practice.