rapala

School choice fixes the wrong problem. Those children who have parents smart enough to select the right school are going to be better of in any case. It is those children that are left behind in the bad schools that need the systemic improvements.

That is, if every child getting a decent schooling is what you want.

I was under the impression that many Finns have a genetical risk of hypertension. Thus studies about the link between salt intake and hypertension have been conducted, for example http://www.ncbi.nlm.nih.gov/pubmed/17046432. I haven't actually read the paper, but the abstract has this claim:

"During the past 30 years, the one-third decrease in the average salt intake has been accompanied by a more than 10-mm Hg fall in the population average of both systolic and diastolic blood pressure, and a 75% to 80% decrease in both stroke and coronary heart disease mortality in Finland."

The percentage of households with a landline was quite shocking. Based on quick googling the percentage here in Finland is ~11%. Gives perspective to the pricing of internet services in the USA vs Europe.

Do note that lower university degrees are relatively new thing in Finland. It is still common to consider your studies "done" only after you have graduated with a master's degree. Teaching teachers in university is also relatively new, started in 1974.

By my observations, pedagogy is considered one of the most applied sciencies taught in university and I would say that it attracts the least academically mind of those applying in university.

> This is a ridiculous scenario. If you have some files on your laptop that are super important, you probably shouldn't `rm -rf` them 1.5 seconds after uploading to your NAS.

There is nothing ridiculous about a hard drive breaking between backups. There are situations where loosing all data after latest backup would be, if not unrecoverable, at least extremely irritating. Having redundant drives in a laptop might not be feasible, but dedicated workstations are still used in many places.

> If you really are going to immediately purge some critical data from its source location 1.5 seconds after fsyncing to your drive, you should be sending it to multiple locations and waiting for confirmation containing a valid checksum before considering the write a success.

Which is exactly what ZFS/btrfs in a mirrored RAID configuration does.

Does the off-site backup also contain the write that happened 1.5 seconds ago? What about the corruption that happened just before taking the backup?

That sounds exactly like encapsulation and message passing. The essence of OO according to Alan Kay.

If I remember correctly, raw lumber here in Finland is in inches and planed lumber in millimeters :)

Or you could do:

1. Insert new User instance 2. Unique constraint violation? Tell user that the username is already registered.

Standard Haskell has only single parameter type classes. With MultiParamTypeClasses you can define

  class Into a b where
    into :: a -> b

Note that From would be the exact same class. I guess the distinction in Rust is relevant because of ownership.

Sending money and transfer item are a create operation against one resource. The same resourse actually, called transfer. That records who transfers what to whom and how much. Thats exactly how it is done in banking.

One could write a macro that allows infix notation for arithmetics: (arithmetics 1 + 2 - 3) = (- (+ 1 2) 3) These kind of syntactic transformations are what macros enable.

So the learning happens where? While watching the multimedia presentation? Homeworks are a central part of schooling because doing them is where most of the learning happens. Notetaking has also shown to be highly beneficial to learning. This proposal downplays both of these and replaces them with testing and ipads.

But all that math, biology and stuff, that has nothing to do about beeing a "good employee". There's a lot of things that the school system genuinely tries to teach. To me it seems that those life skills are an added bonus. Some of them are also requirements to mass teaching. For example, every needs to be at the same place at the same time.

That beeing said, mass teaching like we do it might not be the best thing. We have tools to facilitate teaching that for example does not require everyone to be at the same physical location. Those same tools could also be better utilized in work to enable remote work. Which would then mean one less life skill to teach at school.

To me there is nothing major about a function returning. Every function does that. Implicit early returns on the other hand could be deceiving, but I don't know any languages that would support those.

The trick is that now the keyword return marks an early return. And as early returns are often exceptional, I find the added visibility nice. On the other hand, every function in Rust, except those that contain an infinite loop, returns something so the keyword at the end of the function body is redundant in my opinion.

Also, because function signatures are never infered in Rust, mistakenly adding or forgetting the last semicolon will always result in a type error.

Which can then be made to look exactly like the

  getLine >>= putStrLn

case by doing

  greet name = putStrLn ("Hello, " ++ name)
  main = getLine >>= greet

(Edited to include the definition of main)

I don't support mandatory helmet laws because we have evidence that it actually increases the risk of cycling. Not using a helmet also only affects the cyclists risk of injury. Still, I personally advocate using a helmet when you cycle.

No, because they severly restrict the field of view, something that is not as big a problem on a closed race track.

Because car or no car the head still goes crack when it hits the road. To me it seems obvious to reduce a risk of fatal injury with something as simple as a helmet.

My take has always been that Clojure encourages one to model state when doing so is pragmatic. The tools provided (refs, agents, atoms and vars) are in my opinion excellent. For example, using dynamic variables for error handling can be very nice. A namespace could define something like * on-network-error* which can be dynamically bind at call site. The advantage to exceptions? * on-network-error* can be a function that tries to recover from the error.

You could implement the persistent data structures even in C. Being persistent is a matter of API, not implementation. But actually, Clojure's deftype creates immutable fields by default, so you do get the Java like final semantics (that is, you can't set the fields even though they are public).

The main reason why protocols differ from interfaces in Java or type classes in Haskell is because Clojure is a dynamically typed language. Protocol inheritance would have very little value as knowing that a monad is a functor is quite useless if you don't even know if something is a monad.

Macros don't really need polymorphism. The macro can always expand to a polymorphic function call or it can pass the s-expression to a polymorphic function.

You can actually implement the sequence interface for your own types too. But it is unfortunate that it is an interface, not a protocol, and the documentation for implementing it is nowhere to be found. What is available are functor and monad abstractions, in the contrib library.

That's because it is limited. It's not meant to be a way to provide polymorphism. One of the things that it does provide is the knowledge of every possible case and a reminder from the compiler if you missed one. This is not possible in many OO language.

FP languages have different ways to inject new behavior. You could for example define a function a -> (a -> Int) -> Int. This function now works for any type for which you can also provide the "interface" a -> Int.

Oh come on. An armored vehicle loned to the local police in a case of a school shooting is going to undermine the goverment?

In a way an unencrypted email is like a postcard. Anyone who gets their hands on it can read it without "opening" anything.

Here's the same in Haskell:

  doDishes []            = done
  doDishes (dish:dishes) = clean dish >> doDishes dishes

Very much a recursion in my opinion.

Recursion can cause stack overflow in lazy language too. But lazy or strict, that's more of an implementation detail although a very visible one. An iteration that appends to a list will run out of memory just the same. I also don't see how a recursion that runs out of stack space is any more dangerouse than an iteration that goes to an infinite loop.

Recipes and other manuals are also extremely vague when compared to computer programs. Humans have such vast amounts of context and prior knowledge available to them that pedantic instructions are not needed. The only prior knowledge the computer has is the rest of the program. For this reason I don't like the comparison of natural language and programming languages very much.

I would argue that we use recursion quite a lot. For example, here's how clean a bunch of dishes. If the bunch is no more, your done. Otherwise, take a dish and clean it. Then clean the rest of the dishes like you did with the first one. We often leave out the end condition as it is often clear from the context.

I'm not advocating a deep knowledge of math as I know from experience that it has very few applications in software development. But to me a professional is someone who is not just skilled but knows the history and fundamentals of his trade. He knows not just that for (i = 10; i > 0; i--) terminates but also has an idea why that is so (and what it means that a program terminates).

Why would recursion be any more dangerous than iteration?

It's all about precision. To tell someone how to do the dishes seems easy. But give the same instructions to someone who has never done dishes and you quickly see the problem. It goes the other way too. I dare you to try and explain a simple repeating algorithm in prose. No lists or numberings allowed.

Simple recursions work exactly the same as the equivalent iterations. They branch on a condition, execute a step and repeat. How state is handled is the key difference. As Haskell has no concept of a variable, the only way to rebind a name is to recall a function.

I was going to say that a professional in our field who has problems with recursion and the basics of discrete math should take a look in the mirror. But maybe we have managed to raise the abstractions high enough so that one can be productive without knowing the fundamentals of computing. I probably need to broaden my concept of a professional in our field.

One way to look at function composition is that it is a function to which you pass two functions and out comes a function:

  compose :: (b -> c) -> (a -> b) -> a -> c
  compose f g x = f (g x)

I'm not sure about the math curriculum in USA but in linear algebra you have functions that operate on functions.

Yeah, and the repos have all the same tests that are used by Travis for grading. So you can run those locally too.

It's dead simple to tell apart a tail call. Does it look like

  return call(a, r, g, s)

It is also very simple to test if the compiler does TCO. Just write

  def f(a):
    return f(a + 1)

  f(0)

and wait for a stack overflow.