Supersonic Man

March 27, 2019

what makes one programming language better than another?

Filed under: Hobbyism and Nerdry,technology — Supersonic Man @ 3:26 pm

Every programmer who knows more than one language has opinions about which languages are better than which other languages. I’m no different from anyone in that aspect, but I realize now that I’ve never taken the time to clearly think through what criteria to use in such a comparison. Of course there are times when different language features and styles are suitable for different tasks, but some generalities are pretty universal, and I think different situations mostly just change the emphasis and priority between them.

What got me to take a closer look was hearing someone state the opinion that the measure of the better language is simply the one which forces you to write less repetitive boilerplate. That turns out to be a surprisingly valid and comprehensive metric, despite how plodding and un-abstract it sounds, and I had never thought in those specific terms before.

So, what are some useful criteria for distinguishing a good language from a bad language? Here’s what comes to mind for me:

1. Efficiency. In general, the language should not penalize you for using it by producing a slow-running program, nor should it waste your time during the writing process. Typing a lot of boilerplate is definitely a loss of efficiency.

Supporting good execution performance implies that the language should include some capability to manually optimize the most performance-sensitive parts of the code — the little inner loops in which nanoseconds count because they might go through billions of repetitions. This in turn also implies that there needs to be some access to low-level primitive data types such as bytes. The performance criterion generally favors strongly typed compiled languages over loosely typed scripted ones.

2. Clarity. Simple and commonplace actions should be expressed simply, and complex innovative actions should be expressible as clearly and elegantly as possible, without being forced to translate the basic idea into some other idiom which doesn’t fit it. The language should support writing for ease of reading, as well as for effectiveness of execution.

Sometimes clarity comes a bit into conflict with writing efficiency: a more verbose language can be more readable than a terse one. And sometimes having to type more boilerplate makes the resulting code easier to follow, because the structure is easier to see. There are exceptions to this correlation, but languages that are famed for their brevity are often the same ones with a reputation for unreadability.

For clarity, language features which some consider overkill, or ripe for abuse, can be quite beneficial overall. Capabilities such as redefining what the “+” operator means, or using a novel definition of how iteration works in some new context, are beneficial in that they allow what may be complex inner behaviors to be used and combined in a very readable way.

3. Expressive power and convenience. If a language helps the writer express in one statement what might otherwise have to be broken down into several, that’s beneficial. This aids both writing and reading, and also improves code quality: research shows that the number of bugs introduced is proportional to the number of distinct statements written by the coder, not to the total complexity of the resulting program. When the language empowers the coder to use complex tools in a simple way, the software they produce can be more advanced and powerful for the same effort, and with the same quality.

It is beneficial to support templates with type parameters, so that it’s possible to support a substantial library of collection and iterable types which can be used flexibly and easily. To include features that ease common operations such as “for each distinct” or “first matching” or “all for which” on such collections is also of value — perhaps more value than is commonly appreciated. This is one of the most important factors for avoiding boilerplate: not just avoiding empty verbiage, but making sure the coder does not have to write their own version of a well-known standard operation.

Property getters and setters also help here. They were ideologically controversial at first because of the potential for misuse, but are popular for good reason. So is the fluent pattern — chaining consecutive method calls.

4. Nonrepetitiveness. DRY — don’t repeat yourself — is a rule to help coders produce quality work, and the language should follow it too. The code should let you express a fact once, rather than making you say the same thing twice. Repetition counts as boilerplate, but beyond that, there should be a single authoritative source for each piece of information, with no ambiguity.

This can be a surprisingly challenging goal once you start bringing in “glue” for APIs and data that exist outside of the language. Even within a language, mirroring the same data in different formats can lead to confusion over which version is the one that matters. When this occurs, the development environment needs to be very clear about which one is the original and which one is a conversion byproduct — a rule that is frustratingly ignored by popular systems such as Microsoft Visual Stupido.

“Glue” should be simplified as much as possible; if interfacing with something external which needs wrappers or something, try to either find a way to express the interface compactly without requiring manual coding of a translation, or provide a tool to completely automate the translation process. This particularly applies to ORM classes which wrap database tables. Expressing all this with fewer and more general language features is better than having to memorize a larger number of specific features or idioms of narrower use.

Another aspect of nonprepetitiveness is that arbitrary restrictions which make the coder jump through hoops, in the name of enforcing safety and best practices, should be kept relatively minimal, or offer only a low hurdle if some inconvenience is necessary. This favors weak, dynamic, or “duck” typing over strong static typing, but there is also a solid argument the other way, as such approaches can sometimes make mistakes more difficult to find, thereby wasting coders’ time.

Some commonplace language features to be avoided if possible because they are repetitive include:

  • forward or import declarations, especially in separate header files, or anything similar which requires you to re-specify an interface that’s already declared elsewhere
  • writing multiple overloads of a function just to give it optional parameters
  • having to spell out something’s type both when declaring it and when initializing it, particularly when generic parameters are involved
  • having to put the same modifiers onto many consecutive similar declarations
  • glue which has to be manually updated to be kept in sync with outside changes

5. Locality. All of the material which describes a given code or data entity should be readable in one place, not divided up into different sections or different files. For instance, if a piece of code represents a component of a web page, you should ideally have the markup, the styles used by it, the clientside script, and the serverside logic all packaged together. This is a goal of web framework systems such as Angular.

ORM in particular should strive to come as close as possible to seeing the database definition and the business logic spelled out in very nearby locations, even if normally they would have to be expressed in completely separate unrelated languages.

Exception handlers reduce locality; inline error handling may be better, though it has its own downsides in terms of clarity, as exception handlers let you express clearly how the algorithm is supposed to work when everything is as expected. I guess which is better depends on whether the errors in question are considered part of the normal flow (such as validating user input), or something rare and unexpected (like a disk failure).

Note that locality conflicts with the traditional teaching that code and classes should be broken up into many small units. Breaking things up adds clarity if the behavior that’s extracted can be fully described in a short phrase — otherwise, it impedes clarity.

6. Separation of concerns, and scalability in general. The language should aid teams of coders in dividing work, and minimize the need for people working in different areas to have to communicate and coordinate details. This sometimes makes locality more difficult, but there are major productivity costs when coders start working in large cooperative teams, and clear separations keep those costs to a minimum. The best thing you can do for one coder in a group, or one group in a larger team, is minimize the amount that they have to pay attention to what everyone else is doing.

Conflicts with the goal of locality can be mitigated by having exports and glues and such be automatically generated quietly and behind the scenes, so that depending on your context, you either never have to look at the glue file or never have to look at the original. Language features that are good by this metric include namespaces, packages, automatic dependencies, and automatically generated documentation. Also important here is the clear separation of public from private knowledge; you should be able to present your code, even if it has high locality, as an exported API that the reader doesn’t need to ask about the internals of.

* * * * * * * * * * * * * * * * *

So having set out some criteria, how do I feel some languages stack up by these metrics?

Javascript — the most widely used language in the world:
Efficiency is rather low, as it’s interpreted and lacks primitive type access, but this mitigated by aggressive optimizations that competing interpreters one-up each other with. Clarity and convenience of expression are medium, but suffer from strange workarounds and unwieldy syntax for common cases, such as using closures as class constructors (pre-ES6). Locality and nonrepetitiveness are good. Scalability and separation are a struggle, but improving as the ECMAScript 6 standard gains support. Overall avoidance of boilerplate is decent, given the necessarily rather small size of the language. Given its mandatory ubiquity, we could do a lot worse. (The TypeScript dialect improves expressive convenience and scalability, but is much more limited in where you can use it, and may raise the boilerplate level.)

Java — the inspiration of both JavaScript and .Net:
Efficiency is nothing special. Clarity and expressive convenience are definitely lacking compared to its contemporary competitors. Locality is fairly good, and so is scalability. But the boilerplate factor is frustratingly high, even before something like ORM gets involved.

C — the classic that many of today’s popular choices are descended from:
Efficiency is exceptionally high, but clarity and convenience are way behind the times. Locality is not very good, and scalability is not either. The boilerplate factor is pretty bad when it comes to the actual algorithms you’re coding, unless you have an extensively updated library to mitigate this, but then readability suffers.

C++, a halfway modernized version of C:
Efficiency is not as high as C but is certainly competitive. Clarity and convenience are greatly improved in some areas but backward in others. Locality is possibly worse than C, despite extensive updating. Scalability is pretty good. Overall boilerplate factor is still not very good. This language is the last strong survivor from premodern times and is widely seen as the default for heavy-duty development.

C# and related .Net languages:
Efficiency is pretty fair. Clarity and convenience are dramatically further improved over C++, but at a cost in complexity and feature-creep. Locality is pretty good — of course it falls down if you get ORM and glue involved, but that’s no different from its predecessors. Scalability is a strong point. Overall boilerplate factor is low-medium and has improved with language revisions.

PHP — the new default first language for noob web developers:
Efficiency sucks, clarity sucks, expressive convenience sucks, and scalability sucks. The only bright spot is locality. Boilerplate factor is moderate. This language fully deserves its bad reputation.

SQL dialects with coding extensions, such as PL/SQL and Transact-SQL:
Efficiency can’t be measured like other languages. Clarity and expressive convenience are a struggle, even in the specialized niche uses for which these languages primarily exist, which is where they’re at their strongest. Locality and repetitiveness are poor. Scalability is an area which remains awkward despite a lot of effort. Boilerplate factor is on the high side.

. . .

And now, let’s try forming some baseless opinions about some additional languages which I have not actually learned, going just by what I’ve picked up about them through idle curiosity:

Python — a popular scripting language which supersedes the likes of Perl:
Efficiency is not going to be a strong suit. Clarity is probably pretty good, but it sounds like expressive convenience is nothing to brag about. I’m not aware of any bad issues with locality or avoiding repetitiveness. Scalability sounds like it’s not too bad. Boilerplate factor is… I don’t know, kind of medium?

Ruby — a competitor to Python:
Efficiency is again probably nothing to brag about. Clarity is, I suspect, frequently on the challenging side, depending very much on the coder. Expressive convenience is apparently a strong suit; this is its selling point against Python. Again, I’m not aware of any bad issues with locality or avoiding repetitiveness. Scalability sounds like it’s probably not bad. Boilerplate factor might be pretty low, but I don’t know. This language is now dropping in popularity.

Go — the Google language:
Efficiency is said to be fairly poor. Clarity may be decent, but expressive convenience is not a strong suit. Again, I’m not aware of any bad issues with locality or avoiding repetitiveness. Scalability is… I have no idea, but it can’t be too bad. Boilerplate factor appears to be mild, as far as I can tell.

Rust — the competitor to Go from the Mozilla Foundation:
Efficiency is said to be much better than Go. Clarity looks decent. Expressive convenience is by all accounts higher than that of Go, at the cost of a tougher learning curve, but it’s still more of a detail-oriented language than Python or Ruby, being meant for systems work. It makes much heavier demands on the coder to adopt a novel idiom and jump through hoops in the name of safety. I’m not aware of any bad issues with locality, but there may be more repetitiveness than in Go. Boilerplate factor might be higher than in Go — maybe the difference is minor, but I suspect it might be substantial. This language is aggressively innovative in some areas, and we’ll need time to see whether its concepts move us forward or lead to a dead end. It’s starting to look trendy, but if it catches on I bet someone else will find an easier way to express similar ideas.

Swift — Apple’s language:
I really don’t know enough about this one to have any idea. What little I’ve glimpsed of it make it seem quite middle-of-the-road, with nothing exceptional about it.

Some other languages I know too little about but are probably worth mentioning include R, Haskell, Clojure, Erlang, OCaml, and Scala. Some of these languages are of interest because they are outside of the mainstream and have intriguingly unusual approaches such as functional programming, not because they are widely used. (Actually, Erlang just made’s list of the top five languages to not bother learning.) I will say in general that the paradigm of functional programming, to me, is not ideal for clarity unless the problem being solved is of a mathematical nature, as it forces commonplace concepts into a new idiom — one which doesn’t fit well with interacting with live users.

* * * * * * * * * * * * * * * * *

My overall takeaways:

First: modern languages good, old languages bad. There are lots of languages people used to use thirty years ago which I have experience in and could elucidate above, but which I don’t consider to be worth listing because there are so few bright spots. For instance, many people are nostalgic about BASIC, but I consign it to the same trashcan as PHP. Just take it as read that even the ones I liked at the time, such as Pascal, generally suck.

Second, I feel pretty okay about sticking with C# and JavaScript as my default languages. Nothing else out there is giving me all that much grounds for envy. Been thinking about looking deeper at Python or Ruby or Rust, but both have aspects that make me doubt whether the effort is worthwhile. Rust might be the most important one to look at.

Third, if someone can come up with a really practical way to move beyond SQL, they’ll get free drinks for life.


September 6, 2018

the last SLR holdout

Filed under: Hobbyism and Nerdry,Photo,technology,the future! — Supersonic Man @ 10:41 am

Mirrorless cameras are officially taking over; everybody wants the slim camera bodies and short lens registry distances that are made possible by electronic viewfinders.  Nikon has come out with a new Z mount and almost simultaneously, Canon has come out with a new RF mount (which looks to me like it will be a real “RF” of people who bought into their smaller and older EOS-M system, as it is not at all compatible, and it might not even be possible to make an adapter to mate them).  Meanwhile, in the medium-format world, Hasselblad also came out with a mirrorless camera sporting a new short-flange lens mount a while ago — I think they call it XCD — and Phase One put together a mirrorless bodge setup branded as Alpa, which must have something that counts as a lens mount.  This means that almost every camera company that didn’t already have a short mirrorless lens mount (Sony, Fujifilm, Olympus, Panasonic, Leica, and formerly Samsung) has now added one to their product line.  As far as I can see, there is only one holdout which still offers only a long-flange lens mount and traditional SLR cameras: Pentax.  As it happens, I’ve got Pentax.

Does this mean that Pentax needs to do a me-too and come up with their own short mount, to keep up?  It does not.  There are lots of reasons why it might make perfect sense to offer a mirrorless camera without changing the mount.  They’ve already updated their existing mount so it can operate in a fully electronic fashion with no legacy mechanical linkages.  Lenses made for mirrorless use can still have their back end close to the sensor; they’ll just have the mounting flange further forward, with some of the glass hiding inside the body of the camera.  This will create a pancake-like appearance for lenses that are not actually thin.  Another possibility is that filters can be placed into the gap.  Or the protruding barrel can be a place to mount a control ring.  I think it’s a perfectly viable way to do mirrorless, though for some it won’t win aesthetic points.


June 21, 2018

hydrogen economy? how about methane instead?

Filed under: Hobbyism and Nerdry,science!,technology,the future! — Supersonic Man @ 4:52 pm

Ever since the seventies, there’s been an idea floating around that someday, in order to replace fossil fuels, we’d start using hydrogen as our main chemical fuel.  We’d have hydrogen tanks instead of gasoline tanks, and hydrogen pipelines instead of natural gas pipes.  The hydrogen would be produced from water with either renewable or nuclear energy sources, and then whenever we needed a chemical fuel, we’d use hydrogen.  And wherever we needed a portable source of electric power, we’d use hydrogen fuel cells.  Our cars might be fuel cell powered, for instance.

Since then, fuel cell cars have advanced pretty well, and building a fleet of electric cars which get their power from hydrogen fuel cells looks fairly doable.  There are even some demo filling stations which allow you to fill up a fuel cell car with hydrogen, if you have one of the test vehicles.

So that part is doable, though nobody’s sure if there’ll be any need for it.  Cars might do just as well by simply using batteries, and plugging in to charge, as many people do today.  Making a new network for delivering hydrogen to cars might be an unnecessary expense.

But what about all the other things we use fossil fuel for, besides transportation?  What about heating our houses, and fueling our stoves and ovens?  Could we, for instance, substitute hydrogen for natural gas?

I think the answer is that we could, but maybe we shouldn’t, because there’s a better idea.  An approach which lets us keep using the natural gas infrastructure that we already have.  Switching to hydrogen would entail replacing most of it, because a pipe or a valve that safely contains natural gas can easily fail at containing hydrogen.  Since it is the lightest of all gases, one of its properties is that it can find its way through leaks which, to any ordinary gas, aren’t leaks at all.  Every piece of every pipe, and every valve in every appliance, would have to be either carefully tested, or replaced.  Also, the pipes would either have to be expanded for a larger volume, or operated at higher pressure.

We can avoid all that with one simple step: taking the hydrogen we produce and converting it into methane.  Natural gas is 95% methane, and if we make it artificially, it could be used as a direct replacement for gas.  And the way we’d do that is with a process called the Sabatier reaction.  In this process, hydrogen is combined with carbon dioxide by means of a metallic catalyst.  The oxygen is stripped off of the carbon atoms and hydrogen takes its place.  The result is methane, plus leftover oxygen.

The best part is where we get the carbon dioxide: out of the atmosphere.  At first, we could take it directly from the smokestacks of industries which still burn fossil fuel.  (Steelmaking, for instance, might have a hard time using anything but coal.)  Later, as the scale increases, we could just separate it out of regular air.  This makes your home’s existing stove and furnace and water heater carbon neutral.  And even your car, because existing piston engines can be modified to run on methane, which might help ease the transition to the time when we all go electric.

With some further chemical processes we could probably convert the methane into longer chain hydrocarbons, producing oils and so on — substitutes for things like butane or kerosene or diesel or gear oil or candle wax… or even gasoline for classic car enthusiasts.

Between battery cars and methane conversion, maybe there wouldn’t be all that big a market for straight pure hydrogen.  It would definitely have some uses, but I don’t think all that big a part of our energy supply would be used in hydrogen form.  We might, however, use hydrogen to store solar energy from midday for use at night.  Such hydrogen might be produced directly by vats of algae, then fed to stationary fuel cells as the sun sets.

If a big methane convertor works, we should of course encourage its use.  We’ll have tax credits for making carbon-neutral methane, and penalties for fossil fuels.  The rival approach of getting gas by fracking might even be banned outright, because of its harmful side effects.  This assumes, of course, that at some point we overcome the reactionary political forces who want to prop up the oil and coal industries, and would let all the profitable advances in renewables be done overseas.

One cool thing is that methane making machines are being developed right now, as part of the space program.  Not NASA’s space program, but SpaceX’s private program.  They’re building it for future Martian explorers and colonists, so they’ll be able to make their own rocket fuel for flights back to Earth.  Who knows, maybe at some point they’ll use the machine to fuel rockets here as well, so they can say they have carbon neutral satellite launchers.  Both of the major reusable rocket companies, plus several small up-and-comers, say methane is the fuel they want to use.  There’s no denying that a lot of older rockets are terrible polluters… compared to some of the chemicals that get used in the rocket business, even kerosene looks very green.

Of course, some other rockets will keep on using hydrogen, which when practical is still the cleanest option.  But liquid methane is the second cleanest, and it has nine times the density of liquid hydrogen and therefore requires a far smaller tank to hold it, and less insulation as well, which may save more weight than is lost by using a heavier fuel.

Perhaps the most ideal would be some kind of blend of the two… but then again, one of the big advantages of hydrogen is its very high specific impulse, which is achieved in part by burning a very fuel-rich mixture so that a substantial portion of the exhaust is unburned hydrogen gas.  Densifying the fuel by dissolving some methane into it might save weight by making it require a far smaller tank, but it would lose some of that very high exhaust velocity.

June 3, 2018

Trends in rocketry

Filed under: Hobbyism and Nerdry,technology — Supersonic Man @ 11:07 am

I’ve been taking an interest in the space industry and orbital rockets — a field which is evolving very rapidly nowadays.  So far this year we’ve seen the debut orbital flights of the Electron, the Falcon Heavy and Falcon 9 Block 5, and seen a new record set for the smallest rocket to put up a working satellite.  In the remaining months, we’re expecting the maiden flights of the LauncherOne, the Kuaizhou 11, the Vector R, and the Starliner and Dragon 2 crew capsules.  We just might see one of those capsules take live astronauts to the Space Station by the end of the year.  And the next couple of years will have plenty of action too, with several lunar landers being sent up by different countries, and more new vehicles making their debut: the SLS, the Vulcan, the New Glenn, the Dream Chaser, and more.

With so much short-term activity, it may be hard to spot the longer term trends, but I think I can lay out a few here: (more…)

May 10, 2017

no Apollo

Filed under: Hobbyism and Nerdry,technology,thoughtful handwaving — Supersonic Man @ 9:21 am

If NASA had not been hurried into building the Apollo mission by the “space race” against the USSR, how might we have arrived at the Moon? Space development might have proceeded a good deal more slowly and less expensively, building on the X-15 rocket plane experiments. I think that program would eventually have arrived at something fairly close to the Space Shuttle. If you solve all the problems of the X-15 one by one to make it orbit-worthy, it would have had to be much larger and blunter, because any adequate heat shield is going to be around four inches thick, and that doesn’t scale down for something skinny or pointy. That sounds a lot like the shuttle to me.

So let’s say we were trying to send a mission to the moon using space shuttles. The shuttle itself can’t go there even in you fill the cargo bay with fuel, and that would be wasteful anyway, as you don’t need most of its bulk. So I think the bits that actually go to the moon would be much as they historically were in Apollo: a lunar module, command module, and service module. Why not just stick those into a shuttle bay?

The shuttle’s cargo bay is 60 feet long and 15 feet across, though for a cylindrical cargo the cross section needs to be a bit smaller, as the space isn’t fully round. The mass limit for a flight to low orbit is a hair over 30 English tons, or 27.5 metric tons. (I don’t think any real flight ever exceeded 83% of that capacity.) What can we work out based on these limits?

You can’t fit all three modules into one shuttle-load, but they’ll go in two loads, if you make the lander a bit less broad and gangly. One would be the command module and lunar module, and the service module would be the other. And we might have to trim a bit of weight from the service module, like maybe take out the heavy batteries and put them in the other load. This means the service module would have to be mounted to the command module by shuttle astronauts in space suits, which would be inconvenient, but doable. Alternately, you might cram the three modules into one flight all preassembled, if their fuel were in another. This would mean at least six operations of astronauts pumping dangerous fluids into various tanks spread throughout the modules. It might also mean assembling the lander’s legs from some inconveniently compact from.

Now you need a rocket to send the set toward the moon — one rather like the S-IVB third stage of Apollo, which used the majority of its fuel to lift the three modules out of low orbit and fling them toward the moon. This rocket was a bit too large to fit into a shuttle bay, but we can reduce its size by at least 25%. Its weight is no problem, if it’s empty. But the fuel would take three additional shuttle loads. Historically this rocket weighed 10 metric tons empty, and pushed a 45 ton payload. The required delta-V is 3.1 km/s. It burned around 75 tons of hydrogen and oxygen to accomplish this. It used about 30 tons more to finish lifting Apollo into low orbit around Earth during launch, which would not be needed in this case.

So the mission would require six shuttle launches, starting with one to put up the booster with maybe the first splash of fuel in it, and three more to fill it up. Then the service module would be brought up, and attached to the booster. The command and lunar modules would come up last, along with the astronauts who will ride in them. That last shuttle could stay in orbit for a couple of weeks to await their return.

It might be better to bring the fuel up in the tanks that will be used instead of needing to pump it from one tank to another, so maybe the booster would just be a framework that fuel tanks would be bolted into. Such a framework might be folded smaller for transport. This would require additional assembly in space, possibly employing double digit numbers of shuttle astronauts over several flights. But if everything were prepared well on the ground, the task should not be difficult or dangerous. And if the orbits were well planned, the booster stage could be recovered into Earth orbit, and either refueled for another mission, or if necessary flown back down for refurbishment. As SpaceX has demonstrated with their Falcon landings, once a booster is detached from its payload and has mostly empty tanks, a small amount of remaining fuel can accomplish quite a lot of maneuvering, so I don’t think it’s implausible that its engine could return it to low orbit with the last of its fuel, especially if it discards some dead weight such as empty tanks.

The command module might not need to splash down into the ocean. But it might still need a heat shield, just to brake in Earth’s atmosphere enough to slow down into an Earth orbit, so a shuttle can pick it up. Or, this somewhat risky air-braking might be avoidable by making the service module larger and giving it more fuel. (Perhaps it also could use bolt-in tanks. Add at least one more fuel-hauling flight to the schedule in this case.) An ocean splashdown might be the emergency backup option if the rendezvous fails.

I’m sure this sounds a lot more awkward and inconvenient than the Apollo’s comparatively simple process of just launching one big rocket, but it would have been vastly less expensive. Most of the parts would be reusable instead of disposable. The only part that absolutely could not be reused is the bottom stage of the lunar module. Apollo cost us at least $20 billion per landing, in today’s money; this would cost perhaps a quarter of that — and I’m sure if we made this a continuing operation, we would have found ways to lower the costs further. Instead of just six trips to the moon, we might have continued doing dozens. We might never have stopped.

However, I do worry that this process might have exposed astronauts to greater risks. Lots of opportunities for something to go wrong up in orbit, and lots more shuttle flights. As we have seen, those shuttles were not the safest things to fly in.

Anyway, the shuttle is now long gone. What modern alternative could you use instead? The obvious answer is the Falcon Heavy, which with full reuse of boosters has a lift capacity quite close to that of the shuttle in both mass and volume. The mission plan outlined above would be quite doable with it, though the third stage would need a custom fairing. And this option would further lower the costs. You might get away with five launches instead of six.

Once the New Glenn comes online, you would need at most four launches and might get it down to three. This would probably leave the overall cost roughly similar to what it would be with the Falcon.

But if they get the BFR / Starship to work, it would only need two launches, and would not need any separate modules: with an orbital refueling, the entire ship could land on the lunar surface. SpaceX has stated that they have plans to perform such a mission within the coming decade.

April 8, 2017

eight-bit nostalgia

Filed under: fun,Hobbyism and Nerdry,technology — Supersonic Man @ 1:03 pm

There’s a lot of nostalgia out there for the era of eight-bit computers — especially the home-oriented ones from the likes of Commodore and Sinclair and Atari.  And I get why: they were tremendously liberating and empowering to those who had never had access to computing before.  And the BASIC interpreters they all came with were likewise quite empowering to those who hadn’t previously realized that they could write their own programs.

But as someone who was already empowered, I couldn’t stand those crappy toy computers.  They’d run out of bits just when you were at the point where a program was starting to get interesting.  I never owned one.  I didn’t start wanting my own computer until the sixteen bit era.  The first personal computer that actually made me want it was the Apple Lisa, which of course was prohibitively expensive.  The first one I wanted enough to pay hard-earned money for it, at a time when I didn’t have much, was the Amiga 1000.

(Last I checked, my Amiga 1000 still runs.  But one of these days the disk drives are going to fail, and any available replacements will be just as old and worn.  Turns out that what a lot of retrocomputing hobbyists do is to use hardware adapters to connect their old disk cables to modern flash-memory drives.  It may be kind of cheating but at least you won’t have range anxiety about how much you dare use it before it breaks.)

To me, the sixteen bit era, and the 32-bit transition following, was the most fun time, when the computers were capable enough to do plenty of cool stuff, but also still innovative and diverse enough to not be all boring and businesslike.

If I were of a mind to recapture any of that fun with modern hardware, it sure doesn’t cost money like it used to: I’d look at, for instance, getting a Pi 3 with Raspbian on it.  You could have a complete Linux system just by velcroing it to the back of a monitor or TV.  But there are even cheaper alternatives: there’s a quite good hacking environment available across all modern platforms, more empowering and ubiquitous than BASIC ever was… in your browser’s javascript.

November 18, 2016

future cars

Filed under: Hobbyism and Nerdry,technology,the future!,thoughtful handwaving — Supersonic Man @ 8:05 pm

A lot of people who talk about the coming future of post-petroleum vehicles like to pooh-pooh the battery electric car, even though it’s the most successful type so far.  They keep insisting that the real future will belong to hydrogen fuel cells or ethanol or something else exotic.

But consider the following vision for a future car:

It’s an affordable compact or midsize, nothing fancy.  The base model comes with an electric motor for each front wheel, and 25 or 30 kilowatt-hours of batteries layered under the floor.  This arrangement keeps the powertrain out of the way, so it can have a trunk at both ends, like a Tesla.  Its range is at most a hundred miles, so it’s fine for commuting and shopping and local excursions, but very inconvenient for a road trip.

Most people accustomed to gasoline cars would find this disappointing.  But consider the upgrades you could buy for it.  If you want sure-footedness in snow, or more performance, add a pair of rear motors.  (They would be smaller than the front ones, unless you’re doing some aggressive hot-rodding.)  If you want longer range, you could have a second battery pack in place of your front trunk.  And… if you want to drive everywhere and refuel with gasoline, you could replace that front trunk or second battery with a small gasoline engine and a generator.  It would be no bigger than a motorcycle engine, because it would only need to produce twenty to thirty horsepower to keep your batteries from draining while cruising down a highway.  Ideally it would be a turbine rather than a piston engine, as it would only run at one speed.

Or if gasoline goes out of fashion, you could use that space for a fuel cell and a hydrogen tank.  Again, it would produce only a steady twenty or thirty horsepower.  Or there could eventually be other alternatives not well known today, such as liquid-fueled batteries which you refill with exotic ion solutions, or metal-air cells fueled with pellets of zinc or aluminum.

These would not have to be options you choose when buying the car, but could just as easily be aftermarket modifications.  They simply bolt in!  Anyone with a hoist could swap them in minutes, because the only connections needed are electrical, not mechanical.  Even the front trunk would just be a bolted-in tub.  With a good design, these power options might be interchangeable easily enough that people could just rent such an add-on as needed, rather than buying it.  It might be cheaper than, say, renting another car for a vacation trip.

Another option might be to install stuff from below.  There have been plans to make a network of stations where a machine just unclips your empty battery and slots in a full one, from underneath.  With forethought, this car could be made compatible with such a system.

The point is, once you have the basic platform of a battery-electric car, it can be cheaply adapted to run on any power source.  You could run it with coal, or with thorium, if you’re crazy enough.  Whatever becomes the most economical and abundant power storage medium of the future, your existing car can take it onboard.  All you need is to make sure it has some unused room under the hood.

And the best part?  Even if you don’t add anything, you still have a plug-in car that’s perfectly okay for most everyday uses.  In fact, I suspect a lot of people might come to prefer the car with no add-on, because it’s lighter and quicker and more efficient and cheaper that way, and it has two trunks.

October 3, 2016

a tribute to the HTC One M7

Filed under: Hobbyism and Nerdry,life,technology — Supersonic Man @ 11:09 pm

My current phone, on which I am typing this post, is an HTC One — the iconic model known, but not advertised, as the M7.  It’s old and I’m now only days away from replacing it.  The battery can barely hold a charge anymore, the main camera is busted, and the proximity sensor ain’t what it used to be.  Besides that, of course the CPU isn’t much by today’s standards and 32 GB of storage is rather limiting with no SD slot… but if it weren’t for the wear&tear issues, I’d feel pretty darn okay with continuing to use this phone for quite a while longer.  It’s an excellent phone, and I definitely wish there were more phones out there which embraced front stereo speakers.

The M7 was quite an important and influential model.  Its design and build set a new standard for the kinds of materials and aesthetics that a high-end phone should aspire to.  Samsung took a couple of years to catch up, and I’m not quite certain Apple ever did.  It’s because of HTC’s chamfered aluminum back that nowadays every midrange Chinese wannabe model has a “premium” metallic build, and plastic became intolerable on a high-end model.  And though the stereo speakers may not have been imitated nearly as often as they ought to have been, their presence did manage to embarrass all but the cheapo models into at least putting a speaker on the edge, like Apple, instead of on the back.

Even its camera, which was often regarded as the most disappointing piece of the phone, was influential.  The “ultrapixel” approach forced makers and buyers to realize that pixel size matters as much as pixel count, and this is why today’s camera spec comparisons include that metric, along with numbers for megapixels and lens aperture.  And yes, this was also among the first cameras to make an issue of its aperture, with f/2.0 when competitors were f/2.4 or slower.  The “zoe” feature also helped popularize sharing brief video snippets as if they were still pictures.

Another imitated feature was the IR blaster, though that is now falling out of favor again.  Don’t blame HTC for the trend to nonremovable batteries, though — that was well under way a year earlier.

Aside from innovative aspects, it was just a solidly good phone.  Its software, for instance (initially a skin on Jellybean, eventually updated to Lollipop), was dramatically smoother and more pleasant than that of the competing Galaxy S4, which tended to be jerky even when fresh out of the box.  It also had a stronger headphone amp than the Galaxy.  Its audio features even included FM radio, while other phones were giving that up.  The display was pretty good for a non-amoled, with nice color and 1080p resolution, which is actually better than 1440p for those who watch movies and TV on their phones.  Also, the size of the display was about what I still consider ideal for a compromise between ergonomic convenience and viewing area.  The whole industry has pursued the trend to phablet-sized enormity too far, in my opinion, and I’m glad to see a sign of reversal coming now, with Google’s new Pixel phones (made by HTC) each being a size smaller than their Nexus predecessors, and with no performance penalty for the smaller model relative to the larger.

What are the important and influential models in the history of Android phones?  The HTC Dream, a.k.a. the T-Mobile G1, was the first.  The Moto Droid was the first to popularize the platform with massive advertising, pointing out that there were areas where it could outdo iOS.  The Galaxy Nexus showed off the alternative of a “pure Google” unlocked phone, and a high definition screen without a high price.  The Galaxy Note put phablets on the map, and the Galaxy S III was, for many, the first phone to show that Android might actually be superior to iOS, depending on one’s personal priorities.  The M7 was the first phone to outdo Apple at physical design and construction, and to demonstrate the importance of good speakers.  And maybe we can make a spot for the S6 Edge for being the first to put curved glass to good use, eliminating the side bezel and taking another definite step beyond Apple in physical design.  Historically, the M7 stands in distinguished company.

We shall see what becomes influential next — perhaps modularity, though judging by current sales, probably not.

The M7’s physical design is definitely iconic, and it’s unsurprising that HTC kept changes to a minimum for the M8 and M9, comparing them to a Porsche 911 which still looks like it did 40 years ago.  Unfortunately they kept too much else the same, and lost popularity.  To me it’s sad that HTC has regained customers by losing its definitive feature, the stereo speakers… though the HTC 10’s mix of front sound at one end and edge sound at the other is still influential, having been copied by Apple.

So as I say goodbye to my hard-working HTC One, it’s mostly just with regret that it’s getting physically worn out, not that it’s fallen too far behind.  I will definitely keep it around — if my new phone ever has an issue and I need a backup, I know that the old phone will still be able to perform well, as long as I can keep juice in it.

June 5, 2016

solar panels on electric cars?

Filed under: fun,Hobbyism and Nerdry,technology — Supersonic Man @ 12:39 am

So if you had an electric car, would it be worthwhile to put a solar panel on the roof?

At first blush, it wouldn’t seem so.  A decent electric car ought to have something like 100 kilowatt-hours in its battery pack, and it sure would be nice if it could hold 200 or more.  (The total energy in a moderately sized tank of gasoline is about 500 kwh, but at least two thirds of that just goes into waste heat.)  The biggest solar panel area you could fit on top of a car, disregarding all competing design criteria, would be about two square meters, and a more typical car would probably make room for about one square meter.  Over a whole day in blazing sun, that’s only going to produce about one kwh, and in most circumstances you’ll get quite a bit less.  So it’ll probably only extend your daily driving range by three miles at most, and if you park it under a roof you’ll never get even one mile out of it.

But range extension isn’t the only benefit of having a bit of free power available when not driving.  You’d never have to worry about running things down with the fan or the stereo or mobile-device chargers.  On a hot day you could even use the air conditioner.  The car could even cool itself automatically while left in a parking lot, with no fear that this would affect your ability to get home.  Cars left unattended for months might still be fully ready to drive away in.  And if you run out of juice in a lonely desert, the next day you might be able to drive a couple of crucial miles to get to a spot where help is reachable.

I think this is starting to sound like a good idea even on gasoline cars.  Or on hybrids, at the very least.

June 2, 2016

a small attempt to emulate the gadget press

Filed under: Hobbyism and Nerdry,technology — Supersonic Man @ 9:08 am

Nowadays the popular media report on the latest gadgets almost as eagerly as they report on celebrity gossip.  Since my smartphone is now three models out of date, I’ve been reading more than my share of this stuff.  And this is inspiring me to try adding a little noise of my own to that topic.  So:

Five Things Premium Phones Will Need in Order to Stay Premium


Next Page »

Blog at