Have you ever had someone tell you that liberalism is a mental disorder? Or that right-wingers vote for bad ideas just because they have an irrational world view? It’s a pretty common ad hominem in politics, and not a compelling one. The idea is a tautology: Find two people who have incompatible ways of looking at the world, and each will think the other’s way is somehow defective. But this silly tactic shows up in elite intellectual discourse way too often.

An early example is The Anti-Capitalistic Mentality by Ludwig von Mises, a book-length psychoanalysis of the author’s political opponents. The short version: people who resent their betters turn to communism since it means bringing everyone else down to their level. It’s not subtle.

More recently, academic examples skew leftward. To be clear, this is not a claim that left-wingers disproportionately rely on ad hominem. Nor is it a claim that there is some disproportionate weakness in the right-wing psyche. It’s probably because more psychologists are left-wing than ever before, and since the attack is based on psychoanalysis it shows up a lot in their literature.

Recent examples can be found with a quick internet search. Here are a couple:

Explaining the Appeal of Populist Right-Wing Parties in Times of Economic Prosperity

The traumatic basis for the resurgence of right-wing politics among working Americans

Although these papers are more nuanced and focused than some all-encompassing manifesto, they are still ad hominems. The authors can and will claim that their research is purely academic and not intended as any kind of attack, but let’s be honest, there is one big obvious way this kind of research will always be used. It will be served up on popular political websites and compiled in brightly colored books, ready to be used as Thanksgiving ammunition.

The literature often uses global warming as an example, and a few things are going on here. In many circles global warming is an indisputable fact, so if you want to deploy some political ad hominem against the people who tend to be skeptical, it’s a great starting point. Also, the global warming movement hasn’t succeeded. This approach serves both as a play to convince voters after all, and as something to offer environmentalists disappointed with and confused by a lack of success.

The classic example in the subgenre is Lewandowsky et al’s famous Recursive Fury, a paper psychoanalyzing those who reacted poorly to another paper psychoanalyzing global warming skeptics. How it got through more than five minutes of planning without being abandoned, we may never know. In any case it was eventually retracted.

Another interesting example is On the relation between ideology and motivated disbelief by Campbell & Kay. To its credit, the paper does attempt to strike a balanced tone, supporting an ad hominem attack against both political parties. Still, they put a whole lot more effort into the global warming part, and the fourth study is probably a strategic addition to give the impression of dispassionate science.

These psychology ad hominems have been around for a long time and aren’t going anywhere soon. But they are silly and don’t belong anywhere near academia. Even with the veneer of science, the tactic only convinces people who are inclined to accept the ad hominem anyway. It looks desperate and stupid to everyone else.

Version tags are a pretty simple technique I’ve used with ReactJS to optimize rendering larger apps. This optimization does not add any dependency on an immutable data library. Right away I have to say that this is not something you want to be choosing all of the time. If you want to be able to use shouldComponentUpdate optimizations easily by default, or if you have any reason to be saving and replaying undo history, then you should seriously consider using an immutable data structure. But there are a couple of common reasons to skip that piece of architecture. First, If you simply cannot afford to load any more JavaScript after ReactJS and the other libraries you might already be using, then the convenience of ImmutableJS or a similar library might not justify the overhead to load it. And second, if it would be too difficult to learn and/or integrate ImmutableJS with your existing architecture, this is one alternative. In some ways it is much simpler, but in one important way it is more difficult to use.

If you want to do a very clean implementation of a flux-type architecture, your data might propagate down from a top-level “controller-view” through a whole big tree of React components. Each component in the tree will potentially render on every state change, so to avoid this you want certain nodes to be implementing shouldComponentUpdate and checking if their particular data has changed. The simplest way to do this is to flatten all props and check them one by one. While this can give a performance boost, the boilerplate required to do so can get ridiculous. ImmutableJS and similar libraries eliminate this problem by making the state an immutable data structure. Basically this means that every time a node in the state updates, that node is copied and a new reference is made to hold the new node, along with every node directly above it in the state tree. Then any component which only needs a particular state node to render can check if that reference has changed, and superfluous rendering can be easily skipped. Having the old nodes around also makes undo features trivial to add.

Here’s how version tags work. Instead of copying the node(s) that you need to be updating, you just change a version tag on those nodes. Then instead of checking an immutable reference, the components check if the version has changed to see whether to render. That’s it.

This means you’ll have to add a version tag to the same scope as each node of data you want to be able to optimize for, and it means you will have to manually update the version tag every time something in that node changes. This approach is a sort of middle ground optimization between checking every individual value type at one extreme, and working with and checking an immutable data structure at the other. However in some situations it has the potential to perform better than both.

As a simple example you might have an application that displays a list of clients and a list of appointments. You could add a version tag to each object in your state:


var _state = {
  clients: [...],
  clientsVersion: 1,
  appointments: [...],
  appointmentsVersion: 1
};

And then if you ever update something in appointments you’d do appointmentsVersion++; as well. The component that renders the appointments implements shouldComponentUpdate which just has to compare appointmentsVersion. Versions can be added to as many nodes of the tree as you like, to get the degree of optimization you need at the time.

Will updating versions all the time be in several ways less advantageous than using ImmutableJS? Absolutely. But it is a useful technique.

Here’s a list of ideas and techniques I’ve used when working with ReactJS and Flux. There are two sections: general suggestions of how to get good results, and notes from optimizing for slower hardware. Hopefully they provide a little bit of insight for when you’re looking at all these new concepts and going:

Ah yes interesting, why not continue reading the web page?

It’s difficult to say which of these items if any would definitely be “best practices” but they are available here for reference. Use at your own discretion and happy coding. Several ideas are from [0]react primer draft and [1]tips and best practices, both good resources to introduce and guide learning on the subject.

General suggestions of how to get good results

  • This has been said elsewhere, but get as much state as possible into one place in your application. With Flux this is the store(s). The first diagram from [1] with one-way propagation of data through the tree of components is the ideal, meaning no this.state anywhere. However, there will inevitably be integrated components which have other state, and this should be as contained as possible using this.state and callbacks. Also, any state which is definitely only significant to the one component (such as the open/closed state of a dropdown menu in many cases) can be kept internally without a problem. With Flux this leads toward fewer or even no meaningful state updates happening outside the standard data flow, which is very nice.

  • Some action creators get data from AJAX and pass it along by dispatching an action. There is a way to do this with one REQUEST action and then one RECEIVE action, which is kinda nice because they can be tested and implemented separately, and the REQUEST action doesn’t have to have any callbacks. Another option could be for the action creators to attach promises with each asynchronous action. Then the stores or a service could unpack the data before updating the state. I haven’t actually used that method and there are cases where it doesn’t provide as much flexibility (simultaneous AJAX actions may cause a “cannot dispatch in the middle of a dispatch” error), so try at your own risk.

Notes from optimizing for slower hardware

  • Another point from [1], but definitely use the pureRenderMixin and/or implement the same kind of behavior with shouldComponentUpdate (more on that below).

  • I didn’t realize for a while that you shouldn’t just run the dev source through a minifier for production. With so much relying on pure JS interpreter speed, all those great log messages and debug exceptions make quite a difference. Make sure to build or copy the actual production script when using React in production.

  • There are two basic ways to show or hide sub-components based on UI state. One is to leave them out of the render (I’ve used a ternary expression that returns null if the sub-component is invisible). The other is to render them with a “visibility” prop and have the sub-component set a display:none style internally. The first method keeps the DOM small and clean, but it means more DOM manipulation each time you show or hide the sub-component. The second is more efficient if the sub-component visibility changes often, but it means more DOM elements in the page at any one time (although some are invisible). When optimizing, use the strategy that is more appropriate for the situation.

  • Don’t put complex literal props inline. These cannot be used with shouldComponentUpdate since === will return false every time. Maybe you shouldn’t use literal props at all, but that is if you want to set up constants for everything (usually not a bad idea).

  • Use shouldComponentUpdate. As far as I know there are four basic optimization strategies with shouldComponentUpdate:

    • One is to split up complex props into lots of flat value props, and just check through each one. I would think this can get verbose and maybe a little less efficient, but doing a bunch of === checks should get pretty good performance with little additional code complexity.

    • The second is to use a library like ImmutableJS or Mori to build an immutable state tree and update it through controlled methods. This adds a dependency and some not-very-serious overhead but enables pleasant management of an immutable state object that can be compared before re-rendering quickly and easily. The argument to use an immutable state object is much stronger if you have to implement some kind of undo/redo functionality, but either way it’s a great idea in many situations.

    • The third is to hand-roll some kind of version checking in each shouldComponentUpdate. I feel like this has the potential to be a very lean strategy CPU-wise but it is also a bit more complicated to maintain. Basically you add a UUID version tag to each node in the state tree you want to optimize, and whenever updating that node you also update the version tag. Then shouldComponentUpdate is just a matter of looking at the version tag for the node.

    • Finally there is the strategy of running shouldComponentUpdate fewer times. This is where you might use internal state in lower-level components, and refs to skip typing in a textbox. Another option is to set shouldComponentUpdate to always return false, and use componentDidMount and componentWillUnmount to set up and clean up DOM elements that are directly manipulated from componentWillReceiveProps. These are mentioned at the end of the list because for all but trivial cases moving state out of the standard flow will make code more complicated since synchronization between the two state repositories is now a requirement. Before using them take some time looking into alternative solutions.

Fun with Tailgaters

February 26, 2015

Commuting in the car means a lot of time spent accidentally thinking about how it could be improved. I’ve come up with several ideas for accessories, and this first one is useless but very fun. For some time I was planning a system where buttons on the dashboard displayed messages on the rear bumper. Stuff like “C’MON, REALLY?” to display to tailgaters, and maybe amusing stuff like “WHAT’S WRONG WITH THIS GUY?” when someone up ahead is driving poorly. It would be a pretty straightforward bank of switches plugged into an Arduino, and either a screen with pictures or (better) a train-schedule type letter sign, if those can still be found.

A few weeks back, however, I remembered that dog picture from the Internet that says “deal with it” when the sunglasses drop:

This one

I realized there couldn’t be a classier way to respond to tailgaters than with a live-action version, so I decided to make one. It would be a simple Arduino project, with a servo that lowers the sunglasses over the eyes of a stuffed dog. Then a relay would light up the “Deal with it” text on cue.

Setting up the Arduino code and wiring the components didn’t take more than a few hours:

Arduino wired to button and relay

Arduino wired to button and relay

Then there was the simple matter of printing out some sunglasses and attaching them to a servo (cardboard backing, super glue, and a zip tie for the arm):

The dog with its future sunglasses

The dog with its future sunglasses

Finally the sign had to be prepared. I decided to go all out and buy a real neon sign, since that is totally fantastic and you can get them custom-built. The sign arrived with this nice label:

Packaging for sign

I also opted to buy a pre-packaged relay to switch the sign, since I’m not a trained electrician and you don’t want to trifle with AC power from the wall outlet. The PowerSwitch Tail II is great, you just plug in 5V and ground wires to the side and it works like an extension cord with a switch. The rest of the wiring was just a couple of leads going to 5V and ground, and one pull-down resistor for the button. I also got a 300 watt inverter to provide power from the car battery, and a big red button to activate the sign. Wiring it all together for a test run, it looked pretty good:

Deal with it - Live ActionThe sign turned out to be bigger than I had figured, and it takes up the whole back window of the car. Luckily it has a clear backing so my view isn’t obstructed. There’s still some polishing to go, but it’s working very well.

Nobody has tailgated me anywhere near the threshold level for sign-activation yet (perhaps this is rarer than I thought) but it’s bound to happen eventually. You know when you’re waiting in a line of cars to pass a slow-moving truck, and some chucklehead decides to tailgate you, so that maybe you’ll do the same to the car in front and so on (I assume)? The next time that happens to me, I’ll press this button on the dashboard:

deal-with-it-project-4

And I’ll take my sweet time to finish the pass. Meanwhile the offending driver will see this:

Arduino code is on Github if you’re interested.

React: Why use it?

February 21, 2015

The latest JavaScript brand to hit critical mass is React. It’s a few years old, and still not at 1.0, but that hasn’t stopped it from making large waves in the community. If you’re just now getting proficient with Angular after switching from Knockout or Backbone, this might feel annoyingly familiar (and you might want to ignore React for a few years while the dust settles). But if you’re interested in where JavaScript at scale might be headed in the future, React deserves your attention for a few reasons.

The first is non-technical: teams at Facebook are using it internally to build very large systems like the chat application. The fact that the React brand of dog food makes up a large part of their diet means that it merits serious consideration. Other libraries like Knockout or Angular are not deployed at nearly the same scale within Microsoft or Google.

Of course, plenty of software tools see wide adoption because of fashion, so with React (and the proposed Flux architecture that goes along with it) we also have to look at the technical situation. Facebook has distributed some good media on this subject (see this video and the Flux documentation) but I get the sense that some of the ideas can be obscured by the vocabulary. I’ve seen “declarative” and “virtual DOM” and “immutable” too many times to count, but these might not communicate the relevant ideas to everyone. You might wonder: What makes React different if both Knockout and Angular use “declarative” markup too?

I think the central idea percolating through the community is stateless UI. React is designed to make it practical to move all state out of your UI components and into a separate, single place for each part of your problem domain (Flux calls these “Stores”). If you’ve ever encountered bugs with two-way view-model type stuff, eliminating these bugs while still delivering good performance is what differentiates this approach. For everyone else, let’s say you have UI components A and B that are bound to your application state (some view-model type stuff), and UI component A receives an update from the user. This propagates to the application state, and if component B is watching it will update as well. But what if component B also contains some state that component A is watching? Now A will update, and so on. In the real world more than two components are usually involved, and the potential for this behavior makes the program harder to reason about.

So then why do we need a special library? Can’t we just move the state out to a separate module and route every action through there (effectively making all bindings one-way)? The reason is that most libraries weren’t designed with that in mind, so throwing away the old state and fetching new state from an external source on every action means a lot of DOM operations, making for a slow application. This is where React’s virtual DOM comes in: you can go ahead and overwrite the state from your external source, and React will optimize what is sent to the real DOM.

More details will have to wait since I’m still learning the technology, but look into reactive programming for an extreme perspective on stateless UI, and check out the Windows message loop to learn about a precursor to the Flux architecture. Again, the technical reasons are important, but the easier argument to understand is that large teams at Facebook and elsewhere have had success with React (and Flux). Happy coding.

Review: Interstellar

December 23, 2014

Interstellar is a gorgeous, tightly crafted movie with a clever story, exactly what you might expect from Chris Nolan. While the plot eventually veers into mystical territory, there are some very cool elements built around theoretical physics, time dilation, and higher dimensions. The soundtrack is captivating but unfortunately a bit too loud and cluttered.

Mr. Nolan’s movies tend to be stupidly ambitious, and it could be argued that only Memento has had quite enough substance to validate its ambition. I can’t possibly suggest that this is a bad thing, though. Most blockbusters these days play it way too safe with superhero remakes and guaranteed-profitable book adaptations. When you go to one of Mr. Nolan’s films (other than Batman I guess) you are pretty much guaranteed a genuine effort at filming something enormous and new. That’s worth the ticket price.

As with Inception and the Batmans, the majority of it is wonderful. The acting is executed with great skill, and the cinematography is pure delightful hedonism. All the outer-space business works to tell an epic tale about human potential, love, sacrifice and stuff like that. As with most Nolan movies, there are carefree plot holes and hand-waving explanations (“Collect the quantum data!”) that might make you go all “whaaaat?” but there are also more than a few great sequences based on valid mathematical and scientific principles.

[HERE BE SPOILERS]

The futurist idealism of Interstellar has gotten a lot of press citing general Neil DeGrasse Tyson-ness and quantum woo-ology, which (while that might be an accurate assessment) merely serves to endorse the general can-do space exploration theme. It could be argued that Interstellar ends up preaching the reductionist humanist theologism of Stapelton’s Star Maker and other fiction in that lineage. I would argue that if there is anything approaching a “theory of everything” in Interstellar, it might use that kind of futurist and even pantheist mythology, but it doesn’t ruin the story.

The best sci-fi parts involve a wormhole with what I assume would be accurate topology, meaning perhaps the coolest visual outer-space sequence I’ve ever seen. At the other end is a system of planets orbiting a black hole, which has these like orthogonal rings for some reason. I’m told a lot of theory and work went into this visual, and it’s very neat. Also the time dilation caused by the black hole’s gravity is leveraged for one of the best sci-fi movie plots in recent memory.

Still, a strong dose of *ahem* gravitas leads the end of the movie a bit far from its strong points, which are the relationships and the goals of the characters. Additionally, the science-esque reveal linking the mystical elements to the hard sci-fi falls flat, since all available evidence suggests that gravity travels in waves at the speed of light, not magically backwards in time. Normally I wouldn’t have much of a problem with nonscience in a movie, but since it plays such a central role in the plot that has to be mentioned. A better cut might leave out the attempts at explicitness and leave it vague and suggestive or even ambiguous.

The other part which might have been overdone is the sound. I saw it in IMAX and it was absurdly loud much of the time. If I see it again in theaters I’ll have to bring earplugs, which makes me feel Officially Old. The IMAX version of Interstellar is like sitting in an enormous blender while automobiles and boulders are dropped in at intervals. You can actually feel the space debris hitting you in the face.

All in all, Interstellar is another successful story from the steadfastly interesting mind of Mr. Nolan, and it is worth seeing if you’re into cool far-out space stories like 2001. But bring earplugs.

Amateur Geopolitics, Part 1

November 21, 2014

Here’s something I think the fuzzy shirts in the news are getting wrong. Last week President Obama and President Xi met in Beijing, and then a ludicrous explosion of PR appeared in the American news media, proclaiming that America and China had reached an agreement to save the noble polar bears from drowning.

It’s all very silly stuff and of course it has none of the significance of, say, a treaty, but the propagandists ran with the ball anyway. I’m not surprised about that. I don’t think anybody is surprised about that.

The surprising part is that everyone on this side of the Pacific seems to have lost the pea, so to speak. For example Charles Krauthammer is occasionally relevant about political things, but in this case he has gotten most of it exactly wrong:

The only way forward on greenhouse gases is global reduction by global agreement. A pact with China would be a good start.

Unfortunately, the Obama-Xi agreement is nothing of the sort. It is a fraud of Gruberian (as in Jonathan) proportions. Its main plank commits China to begin cutting carbon emissions 16 years from now. On the other hand, the United States, having already cut more carbon emissions than any nation on earth since 2005, must now double its current rate of carbon cutting to meet a new, more restrictive goal by 2025. In return for which, China will keep increasing its carbon emissions year after year throughout that period — and for five years beyond.

If this sounds like the most one-sided deal since Manhattan sold for $24 in 1626, you heard right. It becomes even more absurd when you realize that, according to the Lawrence Berkeley National Laboratory, China was on track to plateau its carbon emissions around 2030 anyway because of a projected slowdown in urbanization, population growth and heavy industry production. We cut, they coast.

First of all, and this is not the point I’m getting at, but state-sponsored pacts have not come close to reducing anthropogenic carbon dioxide as much as hydrofracking and horizontal drilling in recent years. Even if the fatalist nonsense indicated a problem, Mr. Krauthammer would keep on milling around charity dinners while it was solved by engineers, as usual. The “political solution” is just another desperate pitch to set up another bloated federal agency and create more public-sector busywork. But you already knew that.

The real point begins with what the engineers have already accomplished. Without a bit of legislation forcing them to do so, and with the EPA folks still harassing every single nuclear power project for at least the next two years, the Americans are probably on track to meet the goal of whatever percent of carbon whatnot by whenever.

The immediate question, of course, is whether President Obama was unaware of this fact at the time. The answer is of course not! Mr. Krauthammer might like to say that these folks are incompetent, but the idea that they could be that incompetent confounds the imagination. There is nothing in this phony deal that puts the United States at a disadvantage.

This is quite a concession from President Xi, however. China still builds a coal plant about every week, and they are announcing to the rest of the world that they will match 20% of that output with “renewables” in some 20-odd years. This means that while their mandatory turbocharged baby-boom generation is collapsing, they will have to do one of the following: spend lots of money on energy R&D, spend lots of money importing foreign power plants, lie about it, or pretend all this never happened.

Even considering the fracking contraptions which allowed President Obama to make such an impressive pledge, it seems like it should have been much harder to get President Xi to promise not to walk out of next year’s stupid climate summit. At least until you leave the bubble and read about what else happened during that meeting. In summary:

US President Barack Obama reiterated on Wednesday that the United States does not support “independence” of Taiwan and Tibet.

Just another day of work for these jackasses.

P.S. This is mostly speculation from someone without any relevant qualifications. Please do stop by the comments, Mr. Krauthammer, or whoever, and point out where I’ve made an error. But don’t bother mentioning that I don’t have a PhD if it’s all you have to say.

UPDATE: It appears I might have been wrong about the latest trends in China. It looks like they’re already signing contracts to build a great number of fission plants in the coming years, which will (hopefully) mean a big reduction in coal development, and therefore cleaner air regardless of any of these geopolitics. Good for them.

Sometimes an architect has a wide-open space, a large budget, and unlimited freedom to design a structure. In these cases established best practices will lead to a technically impressive result. Looking at the Burj Dubai, the appearance is of a very tall structure which required engineering expertise and advanced materials to build. With this sort of tower superproject, genuinely new and unexpected patterns are comparatively rare. The technology and academic literature certainly progress as in other fields, but the result of one of these projects is pretty much what you would expect: a very tall structure on a flat foundation.

Now consider a heavily constrained project, like Frank Geary’s fallingwater house. In this case the client requested a house that fit on a unique piece of land, with forested hills and a waterfall going through the property. You might guess that limiting the possibilities available to the architect would produce limited results, but the reality is exactly the opposite. In those unique circumstances, Geary produced the famous cantilevered design and spectacular proportions which endure as iconic examples of the craft. I don’t want to suggest that one can design a skyscraper without any creativity, or build the fallingwater house without any engineering skill. In fact both projects require a great deal of both abilities. I will suggest that the skyscraper requires comparatively more of the engineering part, and the fallingwater house requires more of the creative part.

Here there is an analogy with other disciplines. Architectural concepts apply to any situation where complicated systems of interacting components have to be designed. Courses of education, business processes, and software systems are some examples.

Working programmers dream about having unlimited resources and freedom to build monumental skyscrapers of software design, but reality does not often accomodate these fantasies. Schedules and budgets are limited, often severely. Large systems usually include legacy infrastructure which was not intended to perform the task at hand. Instead of designing with a blank slate, working around these limitations makes up the bulk of a programmer’s day to day experience. I would argue that the reality makes professional programming a much more creative pursuit than it might seem after reading the textbooks and papers. This is good! It makes the job interesting and even fun at times.

The Ludum Dare competition is a great example of the same phenomenon. Each round the participants vote on a thematic constraint to impose on their game projects. Together with a deadline, this limitation acts as a catalyst for ideas. If I’m asked right now to come up with an arcade game, it probably won’t happen soon. Ask me for a game which has, say, a theme of “Escape” or “Tiny world” and the ideas come a lot faster.

The point is not just that constrained projects demand the creative side of architecture, but also that limiting the scope of a project can encourage creativity. The next time you find yourself at a loss for new ideas, try imposing some arbitrary constraints. It will probably help.

Space Frack!

April 29, 2014

Here’s a game I put together over the weekend for Ludum Dare 29. The theme for this weekend was “Beneath the Surface” and the idea was to make an outer space fracking game. 

You are controlling the latest in space fracking technology, a little rover with the task of retrieving space resources from a moon or asteroid or whatever. Use your shockwave (spacebar) to frack open the resources, and then drill (shift) to extract the resources for processing. But watch out for enemy rovers sent by rival corporations!

The enemy rovers are a less sophisticated model without cutting-edge fracking technology, but they have been extracting all the available resources for a while and will not hesitate to hit you with a shotgun blast and steal all your newly fracked resources. Avoid them carefully, or use your shockwave to blast them out of the way!

Watch out for the space fracking protesters, too. You don’t want to cause a PR disaster by accidentally running one of them over!

Play the current build here: http://guscost.github.io/spacefrack

Vote for Space Frack: http://www.ludumdare.com/compo/ludum-dare-29/?action=preview&uid=31734

Translation

January 18, 2014

Words are funny things. I think they function as little encodings of shared cultural experience, as I’m sure I’ve said before. This means that weird stuff happens when we try to translate certain words from one culture to another. In American English land we might enjoy total dominance of teh interwebs, but that doesn’t mean that other cultures haven’t embraced ideas which are much harder for us to understand.

As an example consider the German word “schadenfreude.” Transliterated it could be written as “harm joy” or “misfortune joy” or something like that. However for english speakers that doesn’t adequately convey its meaning. Does it describe some kind of catharsis which might accompany bad luck? In fact it does not. Rather it describes the enjoyment one might derive from witnessing another’s misfortune.

These words make interesting case studies especially when studying translation as a discipline. Germans might have adopted this phrase-word-whatever as a witty way to describe something that actually happens rather often, but it takes many more English words to describe the same phenomenon, because we haven’t absorbed the idea to the same extent. Interestingly, I would say that this means most people are wrong when they say a certain word “has no English translation.” It almost always does, though that translation will invariably require many English words!

There is a Portuguese word “saudade” which describes a certain longing or melancholy or nostalgia, usually for something or someone from the past, but also towards the transcendant and abstract. This word has no English equivalent, but the extended definition could be substituted in many cases. This awkwardness results in the phenomenon where meaning is “lost in translation” and it leads to the idea that certain translated works are never as good as the originals.

However we can also just steal these words from their respective languages and use them to denote the foreign concepts in our own language! The Oxford English Dictionary includes both “schadenfreude” and “saudade” and these days they are often used as valid English words in the appropriate context. This is one way that a language evolves to describe new concepts, and it means that there are no words which will never be “said” in some language. What is missing is often any mainstream understanding of the true definition, and the shared cultural experience which it conveys.

I don’t really have a simple point to make here, but the idea that any given language is “missing” certain words is very interesting. If you’d like to broaden your vocabulary in your native language, look to these interesting ideas from other cultures, and find some cool new words to steal!

Follow

Get every new post delivered to your Inbox.