A couple weeks ago, Dustin got a whole bunch of people to each contribute a few dollars, and we bought a four foot by three foot fresnel lens. It arrived earlier this week, and we’ve been spending our lunch hours out in the sun playing with it.
Explanation of the lens and safety note, followed by more pictures →
My father is a chemical engineer at a large company. He volunteers in an outreach program where the company gives him science demonstrations aimed at precocious elementary schoolers, and he periodically goes to schools and birthday parties and stuff to show how neat science is. One of the kits he does is all about cryogenics, where he gets about a gallon of liquid nitrogen (LN2), and demonstrates what happens to things when you freeze them really cold. He talks about how matter can be a gas, a liquid, or a solid, and how its properties change as it goes from one state to another and changes temperature (racquetballs become brittle, flowers become crumbly, small amounts of LN2 boil into large amounts of nitrogen gas, etc).
He did a demonstration a couple days ago, and still had some LN2 left over from it. Ordinarily he just pours the rest out on the street (it boils away quickly, and no one notices since air is already about 78% nitrogen). However, this time we convinced him to keep it around for a few days so we can try freezing other things. Some stuff about LN2, and some safety tips, followed by a bunch of pictures →
Allen Holub, author of Holub On Patterns, has an interesting article on how if you use getters and setters, you’re probably doing it wrong.
His main claim is that getters and setters are a way of shoehorning procedural design into an object-oriented language, done by people who don’t really understand the difference between a C-style struct and a class. He mentions a course taught in the ’80s by Beck and Cunningham, in which they lament, “the most difficult problem in teaching object-oriented programming is getting the learner to give up the global knowledge of control that is possible with procedural programs, and rely on the local knowledge of objects to accomplish their tasks. Novice designs are littered with regressions to global thinking: gratuitous global variables, unnecessary pointers, and inappropriate reliance on the implementation of other objects.” Holub talks about the CRC design model, in which Classes have Responsibilities and Collaborators. The idea is that the interface to a class should be a list of actions the class can do (its responsibilities) for the other classes it works with (its collaborators). In particular, the interface should not be a list of what data the class can store/retrieve for strangers (which is what getters/setters really are). Under this model, he claims that nearly all getters/setters can be removed in favor of functions that do the work you wanted for you, rather than giving you the info you need to do the work yourself.
Has anyone coded in F# before? It looks fantastic, but since it was created by Microsoft I don’t expect a version I can use any time soon. but I like the way it describes and separates mutable and immutable data. I like the way it blends functional programming with object oriented stuff, and the way it is compatible with preexisting libraries written in other languages. I like the static type system and the type inference on top of it. It’s got a lot of cool things reminiscent of SML (or OCaml, presumably, if I knew it better) while at the same time keeping an imperative, object-oriented spirit about it.
I’m not wild about some of the syntax, particularly the way it’s hard to tell where the definition of a type ends. and that weird <- operator for storing mutable data. and the bizarre [|...|] delimiters of arrays. and the whole #light declaration and how that totally changes syntax (just pick one way or the other and stick with the decision). But so far my biggest complaint is the syntax, while everything else about F# seems pretty cool. Has anyone actually played around with F#? I'd be interested in hearing how it works in practice.
Automation is an awesome process. If you’ve ever taken a tour of a car factory, you know what I’m talking about. It’s totally cool that we can build things that do our work for us. but if we keep this up, the entire economy will need to change. Those supercool robots you saw at the car assembly line? Each one replaced a person and destroyed a job. The self-checkout systems creeping into grocery stores are doing a similar thing by taking away jobs from checkout clerks. Now imagine someone makes an RFID-like checkout system that actually works (i.e. it doesn’t have huge gaping security holes in it), and allows stores to replace all checkout people entirely. A similar system is already in place at my local library (complete with RFID security problems, but who’s going to steal books that are loaned out for free anyway?), and as a result there are about half as many librarians who work there as there were 5 years ago.
Suppose self-driving cars improve and become commonplace: there goes the job of every trucker, taxi driver, and garbageman. Taking that closer to the present, there already exist autonomous aircraft that can take off, fly, and land on their own with no human intervention. If that wasn’t tied up in patent nightmares, I wonder if pilots would still have jobs. I’m surprised that trains/subways are still operated by people at all; I would have expected them to be completely automated years ago. and looking to the more distant future (though still probably within my lifetime), suppose a human-level AI is created. There go the jobs of everyone who thinks for their living (software engineers, accountants, actuaries, etc). and if we ever put such an AI in a mobile body, there goes everyone’s jobs.
Even without a human-level AI, things will change in major ways. Once automation starts being applied in all the places it can be, the world’s job market will change drastically. Lots of occupations will no longer exist because they can be done more efficiently by machines than by people. and if nothing else changes before that happens, a lot of people will be out of jobs and in financial trouble. I hope we can find some way to head this crisis off before it happens, and either find new jobs for people or restructure the economy in such a way that all the out-of-work people aren’t destitute. I’ve been kicking around some ideas on these topics, but I haven’t come up with anything realistic yet. In particular, when a human-level AI is created, all of us will be out of work and all jobs will cease to exist. At that point, we really need to do something about the economy.
I know Mikasaur2000 already posted this, but it’s so fantastic I need to post it again.
I’ve been reading about the history of musical tuning (which is way more interesting than it sounds; no pun intended, but please bear with me), and it recently occurred to me that these days, you can actually get all your notes in tune (which has not truly been possible at any point in history more than about 50 years ago). I can’t tell if this will make a significant difference in most music, but I think it would be interesting to try. Before I explain my idea in more detail, let me summarize the various tuning systems over the years, to give you the background of where this came from. Wikipedia, while not necessarily wrong here, is too incomprehensible to really read; I got a lot of information from this old temperament overview.
A goods peach recognition system cannot beer oh bust without await tour eel eyes the wholesome antics thing.
In our latest installment of “why not to program in C++,” let’s take a look at a simple class hierarchy:
class Duck {
public:
Duck() {
InitializeMigratoryRoute();
}
// Default behavior is nonmigratory; this is
// overridden in the Mallard class.
virtual void InitializeMigratoryRoute();
}
class Mallard : public Duck {
public:
Mallard();
// Migrate south in the fall and north in the spring
virtual void InitializeMigratoryRoute();
}
class DonaldDuck : public Duck {
public:
DonaldDuck() {
outfit_.AddShirt(Outfit::Shirts::SAILOR);
outfit_.AddHat(Outfit::Hats::SAILOR);
}
private:
Outfit outfit_;
}
You can assume this code compiles and runs (i.e., the Outfit class is defined, it implements AddShirt(), both versions of InitializeMigratoryRoute() are defined, etc). I would say this looks like perfectly reasonable code: its intention is clear and straightforward, and any sane language should have no trouble implementing this. [1] However, we’re dealing with C++, which means there are always more problems, and in fact this code is not in the least alright. In particular, there are two major things wrong with it. Do you see what they are?