The site uses cookies that you may not want. Continued use means acceptance. For more information see our privacy policy.

Immigration Demands Negotiation

The president set forth his demands in the immigration hostage crisis, and the legislators may capitulate. But we’re supposed to have debates on these topics and then some loud-mouth just issues demands and good-bye public discourse.

What should the US immigration system look like? Should we go all Canada and ignore their population size and general geographic differences? Should we do away with borders altogether?

The first problem with this four pillar approach is that immigration isn’t a single thing as the simple-minded would like to see it. There are various goals, some conflicting but just as often parallel. Diversity, for example, should not be competing with labor needs, because diversity is important in its own right.

Why do we need diversity? The US being a globally active nation, needs to stay well-linked to every corner of the earth. Whether for employers that are seeking to do business or for intelligence community needs, it’s incredibly useful to have people here that are connected and familiar with other places we don’t have deep roots in.

But to hear critics of immigration tell it, we should just forget about the rest of the world. It’s a lost cause.

Any immigration policy that does not account for topics like diversity, not just in humanitarian or pastoral terms, but in terms of development and practicalities, is a policy that hasn’t been studied by anybody with any serious care for the issue.

The other biggest flaw in these hard-liner EZ-Bake immigration policies is that they conflate the broken existing law with some immutable rule and use that as their jumping-off point to set the new policy. This sort of adherence to the past does not serve the current needs in exactly the same way that the new tax landscape was based on 1980s thinking.

We cannot afford to continue to look at issues off of yellowing newsprint when we have computers that provide real-time views of the world. The Republican policy on immigration used to make some sense, if it was a bit authoritarian. But the policy under Trump and the T-as-in-Trump Party is cruel and wasteful.

As with 99% of this administration’s policies, the damage done, they will be wiped off the map. But it is a shame that the damage must be done at all, particularly when they could see electoral benefit from adopting a rational policy instead. Stupid is as stupid does.


Another massacre. Still no action, not even on mental health, by the government.

What creates a slaughter? There are the instigator with some motive, the weapon, and the victims. If you remove any of these, there is no carnage. Leadership, particularly Republicans, from the president to the House and the Senate, have not acted to remove any of them, and they therefore cannot expect this violence to end. Their thoughts and prayers are welcome, but action is still required.

You can move forward on mental health, which might help. The main problem is that if a person is motivated to attack, the treatment ineffective, there is no recourse to stop them without better laws that could result in them not acquiring the weapon. And Republicans can’t have that. Indeed, they weakened such laws as soon as Trump took office.

That said, we should have better mental healthcare for its own sake, to obliterate the suffering in the minds across this country, for the same reasons we need universal healthcare: it’s the right thing to do.

You can remove the weapon. But you can’t with Republicans in charge.

Or you can remove the victims. Without innocent people to shoot, there can be no attack. They can be hidden, or protected, or made difficult to hit. Schools can be transformed into prison fortresses. Jill can learn her ABCs during count and Jack can learn to count by counting the number of gates he passes through on his way to class.

The obvious solution is to remove the weapon from the equation. Republicans suck at math and call the weapon an invariant. In November, we should vote out as many of them as it takes to break this stalemate and protect our nation from this bullshit.

The Less You Code, the Better

Post about reducing code complexity for the good of the web and its developers.

It’s a well-known fact that the less code one has to maintain independent of other projects, the better the project, all things being equal. In some fields, it’s even considered a liability to use your own code, such as cryptography. But on the web there is a major tendency for every site to have its own front-end, back-end, CSS, and so on.

Some of that goes away with new versions of the HTML specification, such as where new widgets like <input type="number"/> supplant the need for different platforms and libraries to create their own version. But a lot of it doesn’t, as the bigger picture isn’t tackled.

This creates problems, such as the well-documented use of CSS vendor prefixes breaking the mobile web. In this famous case, a ton of mobile sites use WebKit-specific CSS rules, and non-WebKit mobile browsers don’t render those sites as nicely.

There are varied proposals for how to fix that situation. My favorite is for Vendor Prefixes to have a built-in timestamp after which they do not function for any browser. But even the best proposals are working around the larger problem of websites having too much of their own code.

The more code, the more problems. The harder it is to create the web, the harder it is to maintain it, and the harder to evolve it.

The more code, the more duplication of effort by countless developers the world over to do the same things.

According to studies, the average page weighs in at about a Mibibyte (2^23 bits), with an average of nearly 100 objects (mostly graphics), and the growth continues.

It’s clear that this entire paradigm for creating programs and sites will have to change at some point. We’re still in an era where humans and raw data touch way too much, rather than having managed data objects that humans can handle more effectively.

Take, for example, writing a style sheet. Oops, you made a typographical error. Your page doesn’t work right, but is that because of a failure of understanding, a bug in the browser, or some unseen error in: your style sheet, your JavaScript, your markup? Maybe it’s a caching problem.

There are some IDE-type editors, that might give you suggestions as you type a selector, but they don’t know exactly what your intention is, so they invariably defer to your mistakes.

A similar problem occurs when you want to recreate one piece of a page in another project. You are digging out the markup, the JavaScript, and the styles separately. But you have to update them all to fit with your other project, and that requires an omniscience of the namespace and behavior of the other project.

This is ignoring the cargo-cult programming phenomena, which is another by-product of too much code. Too much code in that case means that a novice who might otherwise understand the code will stare at the screen, give up, search for code, copy, paste. It fails, so maybe they paste a bunch of other things. Finally it works, and they move on, leaving a horrible mess just waiting to fail in some new and interesting way.

The question is how to fix it. Syntactic sugar goes a long way. Python tends to be much better than other languages simply because of its focus on readability. But it can still be turned into a garbled mess with enough ignorance and/or effort and/or haste.

So, I say again, the real solution lies in making data into managed objects. Look at the filesystem abstraction. It’s very rare that someone corrupts their filesystem through normal interaction. Open a file. Copy a file. The user isn’t touching the data. They’re touching an interface that touches the data, just like nobody manipulates the voltages running into an arcade game directly. They touch the controls of the game, which handles the electrical signals to the game.

One good example of a tool that works toward this is Inkscape, the vector editor. You can manipulate the SVG (Scalable Vector Graphics) file directly as XML (eXtensible Markup Language), but you can also let a tool like Inkscape manage the data objects for you.

But in the long term we need to be more willing to say that certain behaviors aren’t available from the default interface. To create more lite versions of things that can predominate where the complexity isn’t needed and certainly isn’t adding anything.

My favorite example of that is for online banking. I really do not believe that online banking should happen in a browser or on the web. It makes much more sense to have a dedicated protocol with a dedicated client for that. Something that doesn’t expect to be loading all sorts of complex data in a complex manner.

That isn’t to say a bank shouldn’t have a website. Banks should have websites, but they shouldn’t be the means of account access. They can be used for informational and advertising/brand purposes, sure.