Custom Search

Sunday, December 30, 2012

3d printers and the thing store

A recent discussion about 3d printers led me to thinking about what they can do now, and what they might do in the future, and where it might go. I thought of something I hadn't seen mentioned before, and am now going to justify why I think it's the important part of how 3d printers are going to change the world.

Predicting the future is easy - it's going to be just like the past, except for what's different. The trick is figuring out what's going to be different.

The hardware

We're at the very start of the 3d printer revolution. Most home printers can only print in one material at a time, with low resolution, fixed color, and limited choices for materials. Commercial printers can print in three or more materials at a time, with much higher resolution, and in a wide variety of materials, ranging from the cheap plastics used by home printers, through stone and stone-like materials, to precious metals. Both are going to get better, but how much so?

The closest analogy I can think of to 3d printers is paper printers. My first paper printer was an Epson dot matrix printer, back in the mid '70s. It printed upper and lower case characters, using 9 lines of dots per character. Since then, they've added sufficient resolution to do graphics - the first generation of graphics printers being about a hundred dpi, the latest being well over a thousand, colors - going from a single cartridge that was either color (and unable to print a true black) or black that you swapped out by hand for black and white - to four or five or more inks. The printed material has gone from fan-fold perforated paper to multiple trays feeding in sheets that might can include photo paper in different grades. The quality has gone from being described as "unacceptable for a business letter" to photo-quality printing at home. Meanwhile the price has gone from the better part of a thousand dollars to practically giving them away in order to sell ink cartridges for it.

I can't see any reason that 3d printers shouldn't follow a similar path. So sometime in 20 to 40 years, I expect to be able to buy a 3d printer capable of printing in 3 to 5 different materials - and many common materials - at resolutions I can't distinguish, adding color to the material as it goes. And I expect to buy it for at most a few hundred dollars, depending on inflation - because the printer vendor is going to want to sell me the materials to print with.

And what we will do with it

That hardware evolution presumes that they are going to become nearly as common as paper printers, or computers. Which begs the question - what are all those people going to do with them?

Paper printers aren't a good thing to look at here, because when they first showed up, the potential market was minuscule, consisting of people geeky enough to buy one of those early, eight-bit computers that predated IBM entering the desktop computer market. Instead, let's look at media.

Computers and the internet have already made it possible to create things at home and then deliver them to mass audiences that used to require corporate-level assets to deliver to that audience, if not create in the first place. How have those affected us?

The first thing to note is that very few people actually create such works. Ok, there are hundreds of millions people posting status updates. There are probably a similar number writing blogs, a longer form. But how many are writing novels, or even short stories? Sure, it's more than it used to be - the ease of selling ebooks through amazon or similar markets makes self-publishing trivial and cheap. But I'd be surprised it it's a lot more - probably less than an order of magnitude total, especially if you count things that used to get published in fanzines or passed around by hand, set in a universe a professional author created. And most authors making money at it are still going through the traditional publishing houses, though some - most notably web comics - are experimenting with alternatives, and I fully expect that one or more of those will eventually displace the publishing houses. But the real difference is that the consumer can now purchase electronic copies online, to be delivered to their device instantly, and (if they are savvy shoppers) significantly cheaper than the hard copies. The online booksellers were already killing the brick and mortar bookstores, but ebooks are their death knell.

Music is similar. Yes, there are sites where you can find music produced by amateurs, but mostly it's still produced by people trying to make money at it. The number of people producing complete albums (which I admit are also threatened) is still relatively small. For most people, the difference that computers and the internet have brought to music is the ability to first, order cd's without having to go to a store, and more recently, download the music or just add it to a playlist for later streaming.

Video shows the same pattern: lots of people uploading short clips to sites like youtube, and another group creating vlogs (a contraction of "video blog", blog itself being a contraction of "web log") of some kind or another. A few are actually creating art, as opposed to commentaries or home videos - but they are few and far between. Even fewer are creating feature-length movies, though there are some leveraging the new technology to do that. Again, the real difference for the masses is the delivery mechanism. I can now purchase and download - or possibly stream - professionally produced video material over the network. Again, network based ordering was already killing the brick and mortar stores, but streaming is causing people to cut the cable that feeds their television.

Notice the pattern here? Early adopters were creators, because these technologies allowed them to do things they didn't otherwise have the resources to do. Sure, more people started creating as the tools get better and easier to use, but for most people it's the easier delivery system that's the important difference.

Again, I don't see anything that would make 3d printers different. The early adopters are creators, because these things make creating things much, much easier than it was before. But the mass market users are going to be consumers. People who will want to log into a thing store, click "buy" and have an object printed on their desk. Why pay extra for next day delivery when you can get it now? Not only that, it should cost less in total, because you won't have to pay shipping and handling through multiple intermediaries. Options to pick materials (or classes of materials) and color schemes may well be popular, but at this point I'm trying to predict details in a monetization scheme that doesn't exist yet, and the only accurate prediction I can make is that any predictions I make are almost certainly wrong.

But that's the future I see for 3d printers - online stores selling things to print on them. They will sound the death knell for any brick and mortar store competing on price. In other words, just like the past, except where it's different.

Saturday, December 22, 2012

Type checking for algorithmic errors

While listening to a recent podcast about Yesod - a web framework designed to be type safe - the host commented that he didn't buy into static type checking, because it was neither necessary nor sufficient, as it couldn't catch algorithmic bugs. While he's right that static typing isn't necessary - otherwise dynamic languages wouldn't work - or sufficient - it can't catch all bugs, he's wrong in that it can catch algorithmic bugs. At least some of them. The example he gave - that if you have a month and a day, the type system can't insure that the two are a valid date - is one such case. I threw together a quick example of that, which I'll present here.


The idea is to encode the algorithm state in the data type. So there's an input data type, call it Step0Type. Then the processing at each step will accept data of type Step(N-1)Type and produce data of type StepNType. This means that if you have an error where you skipped a step on some piece of data, you'll try passing type Step(N-1)Type to a function expecting StepNType, so the type checker will catch the error.

Most practical examples only need one step. If you're passing strings to an external command processor - a shell, an SQL server or whatever - that's suspectable to to data injection attacks, having a type that's been sanitized against such attacks that the function that actually handles the IO requires will allow the type checker to flag attempts to pass unsanitized commands to the external processor. Yesod uses this technique for HTML, CSS and JavaScript text, each having a type indicating it's been quoted, to insure that each winds up only where it belongs, and properly quoted.

For the date example, the input type is three values consisting of a year, month and day of the month. The output data type represents a date known to be valid. You then only allow users of the type to access the function that that creates valid dates. So, we're going to write a Date type that holds the year, month and day, and a date function that takes a year, month and day as arguments, verifies that they represent a valid date and returns the appropriate Date. The package doesn't export the primitive Date constructor, but does export the function that constructs only valid dates, so that any Date objects that appear in client code will be valid. Functions declared to accept Date parameters will never see an invalid date.


The data types:
type Year = Int
type Day = Int

data Month = Jan | Feb | Mar | Apr | May | Jun | Jul | Aug | Sep | Oct | Nov | Dec
           deriving (Show, Eq, Ord, Enum)

data Date = Date Year Month Day deriving (Show, Eq, Ord)
These are pretty generic declarations. The only typing information is that Year and Day are introduced as aliases for Int. Now the function that checks that a date is valid and returns the Date object, plus a couple of helpers:
date :: Year -> Month -> Day -> Date
date year month day | year == 1752 && month == Sep && day > 2 && day < 14 =
  error "Date not in US calendar."
                    | day < 1 = error "Month days start at 1."
                    | day > daysInMonth year month = error "Day not in month."
                    | otherwise = Date year month day

daysInMonth :: Year -> Month -> Day
daysInMonth year month | month `elem` [Jan, Mar, May, Jul, Aug, Oct, Dec] = 31
                       | month `elem` [Apr, Jun, Sep, Nov] = 30
                       | month == Feb = if isLeapYear year then 29 else 28

isLeapYear :: Year -> Bool
isLeapYear year | year > 1752 && year `mod` 400 == 0 = True
                | year > 1752 && year `mod` 100 == 0 = False
                | otherwise = year `mod` 4 == 0
The US converted to the Gregorian calendar in September of 1752. Before that, every fourth year was a leap year. IsLeapYear reflects that. The date was also adjusted, so that the day after 1752 Sep 2 is 1752 Sep 14. date checks for that first, then that the day is in the given month.

Finally, to control the export, the module starts with:
-- A date type that enforces the US calendar restrictions on dates.

module Date (Date, Month(..), date, year, month, day) where
This explicitly exports the Date and Month
types, along with the constructors for Month, the date function described above, and some getters that we haven't discussed. Most notably, it does not export the Date constructor, so that the only way client code can construct a Date is to use the date function.

While I wouldn't recommend this as a real, general-purpose date package, the error handling is simply to raise an exception, which is probably not the best choice, the entire file - including exporting the getters for the date type - can be found in the googlecode repository listed on the right, in the haskell directory.