Good point.

The kind of people who read my site include people who have never typed something on a computer before. Only clicked. (You can see someone in the comments asking if it will run Paintshop Pro and Microsoft Word.) So I had to scare them away.

But you’re right, I’m just an intermediate, no CS degree, never learned C or even Perl, and the OpenBSD man pages have taught me so much. And the basic base system turns out to be more useful than, say, Arch Linux (which I also used for years) that gives you nothing at all.

I’m in agreement here. In particular, I cringe when they recommend beginners to start with Ubuntu, or something else that very likely will break or require tweaking and has poor documentation. That’s setting them up for an exercise in frustration. This should be easy, they say, and the poor newbie runs into all sorts of issues and after desperate googling and digging of old and not-so-old forum posts, wikis, etcetra, he may or may not be led to a working copy-and-paste fix that doesn’t really teach anything. It’s a bitter experience, if you’re not among the lucky ones for whom everything Really Just Works and doesn’t break come next update.

Cool, huh? No need for curl or wget just for that. http://man.openbsd.org/OpenBSD-current/man1/ftp.1

I did it. It was fun. Applied then got my confirmation a few weeks later. Went to the Estonian embassy in Brussels (I was in Brussels anyway, so I chose that embassy at my pick-up location), and picked up my E-resident card, and they give you a little USB e-card reader, too.

There’s a URL to verify that it worked: you go to some website, and without logging in, stick your ID card into the USB reader, which sends it through the browser - (I think, from memory, this was a year ago) - and it confirms your identity.

The USB ID-card-reader turns out to be very standard. I hadn’t used one before, but I was also a regular legal resident of Belgium, which had this ID chip on my resident card. So when it was time to pay my Belgium taxes, I was able to use Estonia’s ID-card-reader on my Belgium ID and it worked great.

I haven’t used it for anything practical yet. I suggested to a landlord in Brussels that I sign our agreement with my ID instead of me needing to print-sign-scan-mail the contract. He just looked at me weird. It was worth a try.

I see it as a fun geeky “why not?” that might have a practical use for you some day, or might not. I’ve never been to Estonia, but have warm-n-fuzzies about it now because of this. There’s something kinda fun about having a legal connection to a place. Expands your sense of self a bit.

They’ve said in recent newsletters that that feature (opening a bank account without needing to be in Estonia) is coming soon.

http://www.openbsd.org/papers/hackfest2015-pledge/mgp00032.html

http://www.openbsd.org/papers/hackfest2015-pledge/mgp00033.html

and my personal favorite:

xterm pledged by a developer in one evening

I don’t have enough superlatives to describe how great this patch is, when you look at the bang/buck factor.

Off to buy another 5.8 CD set, I guess…

We should probably work harder to get more valid domains into this list; otherwise, the cost of adopting the list will be low, so more systems will adopt it than if it is full of valid domains.

For one example in Haskell of designing with and thinking in terms of types: http://bitemyapp.com/posts/2014-11-19-update-map-in-haskell.html

You can’t really model domains properly without a type system that is expressive. This stuff goes a long way to making ordinary code a lot more palatable and maintainable.

I have some very incomplete notes here: https://github.com/bitemyapp/presentations/blob/master/modeling_data_in_haskell/modeling_data.md

Here’s a fun example, never write an evaluator/fold for a datatype yourself ever again: http://hackage.haskell.org/package/catamorphism

The epiphany here is that functions that “consume” or break down structure can be generated from the definition of the structure. You define the domain - it generates the code. Wrap according to convenience.

For “make illegal states unrepresentable”, I have a series of examples here: http://bitemyapp.com/posts/2014-11-18-strong-types-and-testing.html

For a simpler'ish example of deferred definition of data (parameterizing), see: http://bitemyapp.com/posts/2014-04-11-aeson-and-user-created-types.html

Pulling out types so you can specify sub-components: http://bitemyapp.com/posts/2014-04-05-grokking-sums-and-constructors.html

Parsing JSON that can vary in structure: http://bitemyapp.com/posts/2014-04-17-parsing-nondeterministic-data-with-aeson-and-sum-types.html

If you don’t mind some humor, this is a post translating a mini-project example that was originally in Python: http://bitemyapp.com/posts/2014-12-03-why-are-types-useful.html

I also wrote a HowIStart article for setting up a small Cabal project to parse some CSV data in Haskell: https://howistart.org/posts/haskell/1

I’m working on a book to make Haskell approachable for working programmers and non-programmers (we test the book with people that have never programmed before) at: http://haskellbook.com/

Hoping the book will, if nothing else, dispel the idea that we need to use less powerful languages that seem more familiar because learning materials haven’t caught up.

I’ve been moving this direction with Ruby. It’s been partly inspired by learning Haskell and partly by trying to decompose and organize my objects. As the author says:

Many of the suggestions are also feasable in C# or Java, but the lightweight nature of F# types means that it is much more likely that we will do this kind of refactoring.

There’s also a resistance to it in what’s considered “idiomatic”. It sounds small and silly, but I think it may be the one-class-per-file rule. When I want a User’s email_address attribute to be an EmailAddress, even before I make it immutable and add validations, I have a file named email_address.rb I have to go look at. That inconveniences everyone a little and there’s not much code there.

And then, worse, to match the basic guarantees of the F# example in part 2 with immutability and validity, off the top of my head it’s going to look something like this:

class InvalidEmailAddress < ArgumentError ; end

class EmailAddress
  include Adamantium
  include Forwardable
  def_delegators :@address, :length, :to_s, :to_str, :<=>
  include Equalizer.new(:address)

  attr_reader :address

  def initialize a
    @address = a
    raise InvalidEmailAddress unless valid?
  end

  def valid?
    address =~ /\A\S+@\S+\.\S+\z/
  end
end

And that’s a simple type with one field. I could metaprogram away almost all of this (I’ve seen a lot of one-field types with this shape now), but it already looks unfamiliar to Ruby developers and depends on two gems. It’s teetering on the edge of idiomatic.

There’s a lot of value to be had, though. The pieces of the system are more reliable. There’s now one explicit place to say what it means for an email address to be valid or how to work with it - I really like email address as an example because in most apps I’ll see it on many models, that knowledge is just repeated and smeared across the system. It’s so common that devs have a hard time recognizing it until it grows out of control.

For a slightly larger example, check out AuthenticationResponse from my TwoFactorAuth gem. The gem authenticates users by sending a challenge AuthenticationRequest to the client and confirming that the AuthenticationResponse can be decomposed and its signature verified against the AuthenticationRequest. Most of the U2F libraries do this by passing around strings for the fixed-length records; TwoFactorAuth decomposes them into types (implemented as Ruby classes) that each know how to validate themselves.

I bottom out in the AuthenticationResponse by not making types for the fields (bitfield, user_presence, counter, signature), but those would’ve been too much of the above boilerplate for a very small benefit in the one or two places they’re used. This librarby has the benefit of being nearly feature-complete and “done” to the spec that app code will never have. There, the decision that it’s not worth it now usually means difficult-to-recognize pain as the app grows and changes and becomes “primitive obsessed”.

So to address your question of whether it’s pragmatically different: absolutely. It’s more up-front code + training up-front for a harder-to-express long-term benefit. In functional languages like F# and Haskell this is the default and enables a lot of compiler-assisted refactoring. I’m not just saying “well, it’s harder with OO classes”, it’s unidiomatic and I see those human considerations looming larger than technical considerations.

I’d say pragmatically it is far, far different from using OO classes as types. Theoretically, it’s possible to do it with OO classes, but there are a number of reasons why they are both too heavyweight semantically and syntactically to make it likely.

The core typed FP languages today have this concept in spades. Learn OCaml, Haskell, F#, the functional parts of Scala and you will see it literally everywhere.

I don’t have any experience with F#, but I know that this is a common pattern in C++/Java, make everything private, restrict access through Get/Set functions, the Set functions can do validation and fix or reject data too.
I only read the first 3 o 4 posts in the series and then got bored, so it is highly possible that something tricker and more interesting happens later.