This is a link to only one chapter of the proceedings. Some of the other chapters can also be found individually, but I suspect the whole is out of print and not easily available. (I have Okasaki's chapter, but I don't remember where from.)
I have the book, ordered some years ago from Amazon, but I have to admit that I opened it perhaps twice... The German Amazon still has on in stock (overpriced):
As jerf said, amortized complexity is discussed in a CS2-style course (in the second semester) when implementing array lists, but invariants are also discussed in the same course when implementing binary heaps or balanced trees (typically AVL or red-black).
It's also plausible that loop or class invariants are discussed in a CS1 course to ensure that your objects don't end up in invalid states after the execution of a loop/method. But maybe the exact word "invariant" is not used as such here.
A length n vector of a's, appended to by a length m vector of a's, results in a length (n + m) vector of a's. This is a safety guarantee that is statically checked at compile time rather than dynamically checked at run time.
I watched a few of the rescues, and they were all of kids falling out of their floaties and seemingly unable to swim at all. What does it look like when an able swimmer encounters trouble? Would it look the same as the drowning response kicks in?
Also, how do you differentiate the drowning response from someone that's just bad at treading water and floats low in the water? They might both be bobbing just in and out of the water, but one of them can just transition to floating on their back and the other is trying to not drown. (I haven't swam in forever and don't know if I can even swim anymore, but I was reminded of childhood swimming lesson tests.)
I spent three summers life guarding at a US state park and would like to give my personal experiences, even if it doesn't give a definitive answer to your question.
Always trust yourself. Any suspicion on your part is more than enough reason to go help. These guards have excellent reactions and don't try to make a judgement call between distress and drowning. While new to the job, I hesitated trying to verify patrons needed a rescue instead of going in immediately.
While this is anecdotal, I also found that poor treaders often made attempts to move to more secure depths. Struggling is no fun, and most people swim to have fun. The dangerous cases were people who did not know their swimming ability chasing family into the deep end.
Lastly we didn't allow floaties in the water, and I think everyone who sees this video should notice the trend and think twice about them.
> Also, how do you differentiate the drowning response from someone that's just bad at treading water and floats low in the water?
Watch the face, arms and legs, and water surface. A swimmer in distress has his mouth as high as possible, may be flailing a little with his arms, barely kicks (if at all), barely disturbs the surface of the water, and goes under repeatedly.
But as a lifeguard, I helped weak swimmers, and then requested very firmly that they stay in shallow water. I also took their names so I could get their attention quickly if they wandered too close to the deep end.
If you can find a video of this scenario on youtube please let me know. I found this series of wavepool videos on the HN thread posted a few days ago (thanks oska!)
The one I saw was a kid who had some swimming ability that fell out of a tube. He swam a poor crawl, without putting his head in the water for about 4-5s before going under.
When an adult or adolescent drowns, it looks exactly the same, they're much more dangerous to would-be helpers, and half the time they're drunk and surrounded by drunk people.
I wonder what factors into the differences. I'm sure things like number of guarded facilities, number of swimmers and amount of swim classes are important, it's the specific differences that would be interesting.
If you go year by year it looks like the rate goes up from 17-20, then after 21 starts to decrease. Somewhere else on the CDC's website they say that "alcohol use is involved in up to 70% of deaths associated with water recreation", which seems pretty consistent with that.
I've played water polo for several years. When participating in an activity where it's mandatory to wear a life jacket, I do, but is there really a point?
But first: another water poloist! Awesome! Water polo was pretty small in my area, so we didn't have a lot of talent in the pool. (Pun intended.) I swam distance on the swim team and was a decent sprinter, so my coach had me play both offensive and defensive hole. My best friend could keep his navel above the water for minutes, so he played keeper behind me. I still love to get my hands on a ball and demo the backwards corner shot. Fun times.
Conscious able swimmers have usually been taught how to lie still and float on their backs, or will figure it out quickly if in calm water. They can often call for help, and will do so, interspersed with periods of rest. (Shouting takes a lot of energy.) If the water is warm, they might have hours to get rescued. If the water is cold or even just lukewarm, how long they have depends on a lot of factors, especially the temperature and whether hypothermia is setting in - but in any case they have a lot less time.
Able swimmers, especially those who are good enough to swim a mile, often underestimate the effects of cold water on the body.
They also tend to underestimate the tremendous strength of moving water. Anybody in moving water who is in distress should be helped ASAP, no matter how good they are at swimming. Moving water is a destroyer and an equalizer.
That leaves us with unconscious swimmers. Nobody swims well while unconscious. :) If there's a chance something could knock you out, whether a boat, an overhanging branch, exposure to cold water, or (for those of extended age) a heart attack, put on a well-fitting life jacket.
When I've been required to wear a life jacket in the past (as an adult) it's typically been in a situation where there was a chance of some other sort of injury occurring that would render you unconscious or unable to swim normally.
Depends on the distance. As soon as you are out in a small boat there may be too far to the shore, especially if the water is really cold.
But at least keep the life jacket near you (ie on the boat), that way you can put it on if necessary - and never ever go out unless there is a suitable life jacket for every person on the boat.
Also never wear an inflated life jacket inside a ship (if it sinks and you become trapped you can't escape).
>Many passengers died because they inflated their life jackets in the cabin, causing them to be trapped inside by the rising water. This led to future notices about not inflating the vests before exiting the plane.
What's wrong with Red Delicious? I usually peel them (thick skin), but otherwise they are crispy and sweet (rather than tart), pretty much exactly how I expect my apples.
What I've noticed with different specialized lines of fruit is that early-on, varieties tend to show up in small niches where they succeed because they taste great. As their popularity increases, more growers and larger buyers start to become involved at which point the exceptional taste of the fruit variety often gets diluted. I'm sure this is partially because of the harvesting process for larger tonnage buy volumes. But, I'm also guessing that 'tweaks' to that fruit also start getting applied for yield/producability etc. In my area, Red Delicious was mostly a bad mealy/bland texture, Fuji's started out great but are now are sometimes good/bad.
It will be interesting to see if a controlling interest in the 'brand name' of a fruit variety ends up managing the quality of a fruit.
>recursion and restricting all their programs to be a singular composite of expressions
Simple effect-free loops in an imperative language translate directly to a recursive function, which is just a labeled loop that makes explicit what/how state is manipulated each loop iteration.
(Edit: For effectful loops, it's common practice in imperative languages to interleave the effects with the program logic. (Un?)fortunately, Haskell discourages this practice and encourages you to refactor the pure parts of your program from the effectful parts. This might make your program more reusable and testable, but it's an obstacle if you are just writing a fancy Hello World and want to get stuff done.)
The singular composite of expressions is not a necessity, but to avoid it you have to give names to all your intermediate states, whereas a typical imperative language reuses the same name repeatedly.
>Haskell discourages this practice and encourages you to refactor the pure parts of your program from the effectful parts.
No more than imperative languages do. Speaking from experience, if you wanna slap IO on the arse of all your types, no one can stop you. Our friggin' project/dependency management tool is written like this. Yes, Haskellers usually prefer something nicer but nobody's going to steal your compiler if you don't.
We should avoid mistaking our discomfort with a language or idiom with what it does or does not encourage, can or cannot do. Chopin's nocturne op 48 1 is not difficult because pianos discourage it, it's difficult because it's difficult. In fact, it would be extremely hard to translate to a less expressive instrument. Similarly, writing programs in a well-factored design that separate actions from the computations that decide what happens from the datatypes that model them takes effort and practice, whether you use Haskell or not. I would submit that using a less expressive language will not make the task itself easier any more than trying to capture all the notes of Chopin's 48/1 on something less expressive than a piano would be easier.
My coauthor has her 10 year old learning Haskell from our book. This stuff does not have to be hard.
I've got more news for you, since we have composition for things with more structure, it's still composable. (>=>) is like function composition, but for when we have monadic structure flying around.
Prelude> let x num = print num >> return (num + 1)
Prelude> :t x
x :: (Show b, Num b) => b -> IO b
Prelude> mapM (x >=> x >=> x) [1..5]
1
2
3
2
3
4
3
4
5
4
5
6
5
6
7
[4,5,6,7,8]
You can write all the loopy-woopy side-effecty whatevers you want. Haskell's just better at it and offers alternatives. The actual recursive loops are less spooky than the name "mapM_", but I didn't want to make it verbose.
One of the nice things about Haskell is you can always replace a function with its contents, or factor something out into a function and call that function by name and the result never changes.
-- You could inline the definition of foldr
-- and make mapM_ loopy-woopy, but why would
-- you want to repeat yourself?
mapM_ = foldr ((>>) . f) (return ())
If they already learned imperative language concepts, sure it's discouraging because people who know things don't like to go back to being beginners again.
But if they're completely starting from scratch, I'm not convinced it's really harder.
The singular composite of expressions is not a necessity, but to avoid it you have to give names to all your intermediate states, whereas a typical imperative language reuses the same name repeatedly.
Interesting way to put it.
I like to tell people that they program in languages where every type signature is "Any -> IO Any". It's technically true, but it gets some weird looks.
Last weekend at LambdaConf (functional programming conference in Boulder) we were joking that all programming is fundamentally just a function of String -> Any.
Fewer weird looks when you make that joke surrounded by Haskellites and Scalaistas.
Along the same line of this post is sigfpe's "You could have invented monads" http://blog.sigfpe.com/2006/08/you-could-have-invented-monad..., which has convinced me at least a few times over the years that I could have invented monads (until I promptly forget all about it the next day).
I just need someone to convince me that I could have invented monad transformers too, because while I now think I can use most of the common monads by themselves, trying to do multiple things at once just ends in (metaphorical) tears.
Multiple things at once are still ordinary monads, and you can implement them without using transformers. Transformers are merely the realization that one can put (certain) monads together in a compositional way.
An example of a monad in Haskell that is not put together via transformers, yet provides all their functionality, is RWS, being a combination of Reader, Writer and State in one hard-coded type/instance.
The title is somewhat misleading. It is the Chinese writing system that's hard (in general). Standard Chinese, the spoken language, is only hard for native speakers of unrelated language, which is hardly surprising.
Does anyone know what the obstacles are to an official 64-bit Windows build? There are multiple unofficial builds in the wild and at least one (linked in the parent comment) builds without patches.
I've done some emacs building on Windows before, and I think it's more to do with all the dependencies.
There are so many of precompiled dependencies available for 32-bit, but last time I checked, it's not the case for 64-bit, so you have to resort to compiling those dependencies as well. Though this situation may now be better, but that was major issues when I looked into 64-bit before.
It's just poor wording. The "approximately" isn't "yes, it's approximately faster" but "here are the numbers -- approximately". Notice that it says the same thing when you reverse the Python vs Java comparison.
