This Trump Thing

November 11, 2016

Many of my friends are really upset about the 2016 election. Rather than speaking off the cuff, I’d rather point them here to read some tactfully-prepared comments which I hope will help. Disclaimer: I didn’t vote in this election and wouldn’t have voted for any of the known candidates. There was so much anger, fear, and bitterness motivating support for these candidates, and it contrasted so drastically with my personal experience of 2016, that I felt it best to stay out of it all.

However I do read and think about culture and politics a lot (perhaps too much), so maybe my perspective isn’t worthless.

Based on what you’ve seen, you might decide that old bitter racists got mad at brown people and voted in a Nazi. If this is what you believe then yeah, there is reason to be scared for the future. But I don’t think it is accurate. Here are some of the actual reasons why half the country voted for Trump, all pretty much baseless and off the top of my head.

Reason 1: History and Demographics

The Industrial Revolution is long over, and now the next one is in full swing. Centuries ago, when machinery was invented to perform tasks that had required raw human strength, the displaced laborers caused a stir, burning down factories and I expect getting all up in the politics of the day. In part, this is the same effect on a much larger scale. These days the machines don’t only do the heavy lifting, they do the fine details too. And many industries that used to require physical manipulation simply don’t anymore, because pure information is easier to work with. This means there is a whole generation, the last industrial generation, with nothing left to do. It’s sad. While the young people were going to college and preparing for the new high-tech information service economy, these old people have had basically no prospects, and nobody in politics has been sympathetic to them in a long time. Whether or not he can do anything about this, Trump was speaking directly to them the whole time, and he flipped lots and lots of the industrial-generation folks who had voted for Democrats their whole lives. You can take issue with these people believing that protectionism is a viable solution to their problems, but nobody else was proposing anything new to them.

Reason 2: Racist (etc) White People

OK, yeah, some white people are bigots. Most of those people jumped right on board. You can find their writings online (…or maybe spray-painted on a wall in your neighborhood) if you know where to look, but keep in mind that trolls like to masquerade as those people too. More importantly, your garden-variety racist with a low opinion of Muslims has never had a Muslim friend. Their bigotry is usually born from fear, which is born from ignorance. The proper response is outreach and pity, not ostracism and smugness.

Reason 3: Smugness

On the flip side, many of you have never had an old working-class rust-belt friend. You don’t understand them, and neither do the media folks who have been trashing their culture for decades. For example, the media has played up the racism angle to an unfair degree. Factory workers, coal miners, and evangelicals are people too, many of them smart and interesting people, and while they might not know everything, neither do you. If you have the stomach for it, read this prophetic piece and try to imagine how these folks have seen the coastal elites behave for decades. A surprising number of young college-educated people voted for Trump too, and I’ll bet more than a few did so because they simply picked the side with less smug behavior.

Reason 4: Corruption

I mean come on, by 2016 the Bush-Clinton family was as incestuous and rotten as the last generations of the Holy Roman Empire. Most of the people I know who voted for Trump weren’t particularly fond of him, they just couldn’t stand another anointed Yale scion being paraded around in front of them by Turner Media and the National Broadcasting Corporation. Many of them would have voted for Bernie Sanders if he was on the ticket.

OK, that explains a lot, but we still have an impolite egomaniac with no political experience as president, we’re doomed!

Maybe, yeah, but probably not. America has been through a lot, and most people (yes even the Trump voters) are still basically good people.

What can you do to help? First, make friends outside your comfort zone. This situation is partly the result of years of people shutting out everyone and everything that makes them uncomfortable. We cannot function in the long term as a society where everyone does this. Understand that other people can arrive at other decisions that you don’t like or even hate, and you can still respect them as people. Also once you know them better, you will understand where they’re coming from, and you’ll even have a chance to sell them your ideas.

Second, don’t get disheartened. If you believe in something keep fighting for it. But again always respect your opponents as people, and remember how badly the “smug bullying” tactic just backfired. Play the long game. Be polite, but annoying, and keep it up for a long time. If you are on to a good idea and you can rally long-term support it will win out in the end.

Third, if you are still worried about the nightmare Nazi scenario, exercise your right to bear arms. Never incite violence, but remember that the very best insurance against fascism is a well-armed populace. Regardless of who might actually attempt a fascist coup, the gun-owning basically good Americans will be right there with you fighting shoulder to shoulder if necessary (which we all hope and pray it will never be).

Finally, read more books from the past. Civilization has been around a long time, and in most ways things are better than they have ever been. That won’t change. Your fears about a Republican Supreme Court making over-the-counter contraception illegal might be justified, but keep in mind that we aren’t talking about throwing people in jail for adultery. Maybe some immigrant families will be broken up, which is very sad, but the public is only going to tolerate this policy if they prioritize dangerous criminals like any old law-and-order administration. So if you’re here in America illegally, uh, you probably want to drive exactly the posted speed limit for the next few years.

Future progress for minorities and women and gays needs to be made overwhelmingly in the social sphere, where government will not be involved no matter who is president. Don’t take this political event as a sign that things can only get worse from here. And one day, probably in your lifetime, that last glass ceiling will indeed be cracked.

The arc of the moral universe is long, but it bends towards justice.

– Martin Luther King Jr.

How to do Programming

July 3, 2016

TL;DR: Identify assumptions and write them down.

There’s a common (I think) misconception that the programming trade is all about knowing obscure facts and doing hard math. From this it follows that a person has to get really good at math or know a huge number of things before doing programming.

Unfortunately people who have this misconception can be discouraged from trying in the first place. It might be unrealistic to think that every single person not only can but also will want to do it, but I think that lots of people with this misconception could do very well at programming, once they understand what it is actually like, and if they put some effort into learning it.

In reality, being good at the math or knowing all about compilers and language features does not help with a large percentage of the day-to-day work that most programmers do. Instead, their effort goes into writing down all the assumptions made by the high-level description of a feature. In other words, the requirements will say “display a count of the current total” and the programming work is about finding the assumptions implied by that description (“what does ‘current’ actually mean?” etc), then writing them down explicitly. Once you write down the assumptions in the right way, the explicit representation of the assumptions is your code and you are done. Getting everything written down correctly used to be much harder, but with modern programming tools it isn’t even possible to make some of the most problematic mistakes anymore, and the tools can catch lots of other mistakes automatically. For everything else you would want to get help from a more experienced colleague, or just ask strangers on Stack Overflow.

There are programmers who would take issue with this description. I’m using the terms “doing programming” and “day-to-day programming” strategically, really to mean commercial or hobbyist programming for which there are mature high-quality tools and well-understood best practices. On the cutting edge of academia, and within programming projects that have very demanding requirements, advanced math and knowing lots of obscure facts can be much more important.

Basically, what I’m saying is that people tend to confuse the larger industry with that super-difficult hacker nerd work they see in movies and TV shows. In fact, the vast majority of programming work going on right now is the other kind. There are huge numbers of those jobs to be done, because it is where all the theory and advanced knowledge finally can be applied to a real-world problem. Many large software teams have so much of this kind of work that they split out a whole department for “requirements engineering”, which is taking the really high-level descriptions with tons of assumptions, and breaking those out into statements with fewer or no assumptions left in each statement, so that the code writers can focus on making the final code work. The best requirements are harder to write than all the coding work that comes after!

Maybe someone has told you before that programming is all about breaking problems down into smaller problems. It’s another way of saying the same thing.

 

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 might be a strategic addition to give the impression of dispassionate science.

These ad hominems have been around for a long time and they 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.

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!