10 ms·

Show HN: Code Words, a quarterly publication about programming

181 points by nicholasjbs 12y ago

daviross 12y ago
This looks interesting. Is there an RSS/Atom feed available? (I didn't find one, but I could've missed it)
- davidbalbert 12y ago
  Not right now :(. I will add one later this evening.
  - beefsack 12y ago
    Great publication, will subscribe as soon as the feed's available.
    - kbenson 12y ago
      Seconded.
      - davidbalbert 12y ago
        Turns out I'm too tired to do this tonight. I will try to do this over the weekend or on Monday. I'll try to ping each of you when there is an RSS feed. In the mean time, we'll tweet about every issue on https://twitter.com/hackerschool https://twitter.com/hackerschool, but I know that Twitter isn't RSS and that subscribing to our Twitter feed in order to get the 4 tweets per year that you want to see might be silly.
- aethertap 12y ago
  https://codewords.hackerschool.com/feed.xml https://codewords.hackerschool.com/feed.xml seems to work for me in theoldreader.
therealdrag0 12y ago
I really like the approach taken in the introduction to functional programming article.
- mlangdon 12y ago
  As somebody who can still only grow a neck beard, I've been trying to get into functional for a while now. Maybe it's because the examples are in python (a non-crazy looking language I've written a lot of lines in), but this is the first time I've read an FP article and thought I might enjoy explicitly using this stuff. I've been low-side effect and anti global for a while, but filter() is sexy.
- thmcmahon 12y ago
  Yep great article. As a beginner programmer I find functional more intuitive than OOP, there just seems to be less abstract concepts and boilerplate.
  - splinterofchaos 12y ago
    There do exist object-oriented functional languages (Ocaml). Functional vs OOP is a false dichotomy, though a very common one. I prefer to use functional techniques in imperative languages with simple objects.
- copx 12y ago
  Well I only noticed how much less efficient the "functional" code is, downright wasteful even. And nobody is going to tell me that this: def move_cars(): for i, _ in enumerate(car_positions): if random() > 0.3: car_positions[i] += 1 ..is not way more readable and clear than this: def move_cars(car_positions): return map(lambda x: x + 1 if random() > 0.3 else x, car_positions) If you ask me the article makes a good argument against functional programming.
  - splinterofchaos 12y ago
    How about: def move_pos(x): if random() > 0.3: return x + 1 return x def move_cars(positions): return map(move_pos, positions) I do not believe that functional programming benefits from brevity, except at the top layer. Unfortunately, functional programmers often expand their equations which, having examined them thoroughly, they understand implicitly, but can give too much information to the reader all at once. Though, I have to agree, the FP community really hasn't been able to demonstrate how to do it without losing efficiency, and yet many proponents claim we should abandon all other paradigms. All of these articles seem very biassed towards FP. I enjoy functional programming, but I prefer to work in imperative languages where I have a choice between paradigms.
blubbi2 12y ago
(commenting on one of the articles) Wow. Just stumbled upon the following quote and read the corresponding article. > Programming language comparisons usually focus on the brevity and expressiveness of the language. If the solution to a programming problem has fewer lines and is “easier to understand” or “clearer” in one language than another, that is an argument for using the former over the latter. This comparison is useful if one supposes that the art of programming is primarily concerned with writing programs. It isn’t, of course. It is mostly concerned with debugging programs. - https://codewords.hackerschool.com/issues/one/why-are-objects-so-hard-to-debug https://codewords.hackerschool.com/issues/one/why-are-object... > In summary, then, every concept that object-orientation brings to the table makes debugging harder. > If you believe (as I do) that the majority of effort a programmer expends is devoted to finding and fixing bugs, then an imperative programming approach will be more efficient (in programmer time) than an object-oriented approach.
- seanmcdirmid 12y ago
  > - https://codewords.hackerschool.com/issues/one/why-are-object.. https://codewords.hackerschool.com/issues/one/why-are-object.... > In all seriousness, this is one of the best articles I've ever read. I couldn't agree more with the author. I'm not sure if you are being serious (you say you are, so Po's law), but this is a bad article written by someone who I guess must be a novice who thinks he knows something now but will look back on this 5 years later and cringe; examples... > From the perspective of debugging, an instance variable is not in the scope of any of the methods on the stack. He might as well be talking about heap allocated structs in C. > This threatens to increase the search space, and suggests that avoiding instance variables in favor of passing arguments might be a better strategy where possible. State should be stack allocated, except when it really is state (even if hidden in a monad). > if you make the mistake of defining public “setter” methods, then the instance variables with setter methods become effectively global variables: if the value of the instance variable is incorrect at some point, that incorrect value might have been set anywhere in your code. I'm trying really hard now to not be sarcastic. > So, to avoid making your object-oriented code harder to debug than imperative code, you need to not use any public instance variables, and also avoid defining setter methods. How does this guy define imperative code? Definitely not C where all members of a (heap allocated) struct are public? He then describes the fragile base class problem without really understanding what that means. > The technical term for a programming paradigm which uses neither inheritance nor instance variables is imperative (or functional) programming. Ok, I can't stop myself from laughing at this point; I can't really go any further. You know, we all go through this as programmers. We start knowing nothing, then we get a couple of years of experience and think we know everything....then we get 10 years of experience and realize we still don't know very much and what we thought we knew were just delusions of grandeur. I won't say much about the rest of the publication. The nice thing about the internet is that anyone can produce something and make it available to read.
beefsack 12y ago
Typo in the functional programming article (which was a great read): > Every time a person reads afor loop
- davidbalbert 12y ago
  Fixed. Thanks!
  - dorian-graph 12y ago
    Another typo in the same article: > race() recurses3 with the result of run_step_of_race(). Edit: Finished reading the article. Brilliant. Even the footnotes were better explanations than commonly found.
morninj 12y ago
Looks great! It would be nice if I could subscribe by email.
- hughstephens 12y ago
  +1 would love email subscription. Just bung up a Mailchimp account and you can even connect the RSS others have been asking :)
- melvinmt 12y ago
  I second this, I typically forget about these things (meaning I never bother to look for new issues) until I get the email.
- jscn 12y ago
  Thirded. Ever since Google Reader shut down, I've stopped using RSS. I much prefer to get newsletters in my inbox now.
  - owyn 12y ago
    If you're actually missing RSS try "the old reader", it's pretty much what Reader was. http://theoldreader.com http://theoldreader.com Although avoiding RSS is probably a good thing for productivity in general. :)
akanet 12y ago
Dan Luu's article about transitive equality and floating point numbers is pretty amusing. (https://codewords.hackerschool.com/issues/one/when-is-equality-transitive-and-other-floating-point-curiosities https://codewords.hackerschool.com/issues/one/when-is-equali...). Here's a little tidbit from the article (notice that he's shown an example in Haskell where A == B, B == C, but A != C): $ ghci Prelude> -- Hi! I'm a comment! Prelude> -- 2^53 == 2.0^53 Prelude> 9007199254740992 == 9007199254740992.0 True Prelude> -- 2.0^53 == 2^53 + 1 Prelude> 9007199254740992.0 == 9007199254740993 True Prelude> -- 2^53 == 2^53 + 1 Prelude> 9007199254740992 == 9007199254740993 False
- copascetic 12y ago
  This example is misleading, and I don't think the article addresses the subtleties. Basically, the third line is not like the other two. Because none of the numbers involved in #3 are Doubles, Haskell will actually use the Integer type, which is basically a bignum (like integers in Python). The first two are comparing values of type Double, so the instance of Eq for Double is used, which necessarily has some inaccuracies, as shown in the second line, while the last one is using the instance of Eq for Integer. Therefore, the statement that (==) is not transitive for these types is false, because we are talking about different versions of (==) in the first two examples vs. the last one. The trick is that bare numeric literals have type Num a => a, and have their type inferred by their use. The first two examples cause the 2^53 to take on type Double, otherwise it wouldn't type check (literals with decimals in them have type Fractional a => a, of which Double is the default). The last one doesn't have any expressions with decimals, so it uses the Integer type.
- copascetic 12y ago
  When you specify the types of the numbers used, so that you are testing the transitivity of a single instance of Eq, you will find that transitivity does hold in this case. a :: Double a = 2^53 b :: Double b = 2.0^53 c :: Double c = 2^53 + 1 main :: IO () main = do print $ a == b -- True print $ b == c -- True print $ a == c -- True
rdc12 12y ago
From the article Option and null in dynamic languages [1] "Languages and libraries are defined not by what they make possible (the Church-Turing thesis tells us that), but by what they make easy." The Church-Turing thesis tells us about what is fundamentally computable, what a library decides to implement is not the same thing. Libraries are not about what is fundamentally computable, but about abstracting away the mechanics of some problem. While no library can solve the halting problem, that in no way implies that two libraries expose the same things to the end user of the library, even in a related field. [1] https://codewords.hackerschool.com/issues/one/option-and-null-in-dynamic-languages https://codewords.hackerschool.com/issues/one/option-and-nul...
- rntz 12y ago
  I can't tell whether you intend to agree or disagree with the quote. Your tone suggests you are disagreeing, but your content to me seems to be in agreement. (I am the article author.)
  - jfarmer 12y ago
    Welcome to HN!
  - rdc12 12y ago
    Disagreeing, but it was late when I wrote it. I guess my counter argument would be that what is fundamentally computable and what someone choices to implement in a library are not the same thing. With languages that may be a bit closer to the truth, but I would also add things like what the language makes safe (type safety, memory safety etc). I did on the whole like your article thou, that small bit just got to me a bit
- LukeB42 12y ago
  It's almost as if you could say languages and libraries are defined by what they make easy..
dkarapetyan 12y ago
I like curated content. In fact a lot of my reading about programming now comes from things like ruby/python/html/javascript/open source/etc. weekly email lists. The internet has too much noise when it comes to programming stuff and the weekly emails cut through the cruft. This will be another set of articles I add to my reading list instead of trying to find gems on HN or r/programming.

181 points by nicholasjbs 12y ago

daviross 12y ago

This looks interesting. Is there an RSS/Atom feed available? (I didn't find one, but I could've missed it)

davidbalbert 12y ago
Not right now :(. I will add one later this evening.
- beefsack 12y ago
  Great publication, will subscribe as soon as the feed's available.
  - kbenson 12y ago
    Seconded.
    - davidbalbert 12y ago
      Turns out I'm too tired to do this tonight. I will try to do this over the weekend or on Monday. I'll try to ping each of you when there is an RSS feed. In the mean time, we'll tweet about every issue on https://twitter.com/hackerschool https://twitter.com/hackerschool, but I know that Twitter isn't RSS and that subscribing to our Twitter feed in order to get the 4 tweets per year that you want to see might be silly.
aethertap 12y ago
https://codewords.hackerschool.com/feed.xml https://codewords.hackerschool.com/feed.xml seems to work for me in theoldreader.

therealdrag0 12y ago

I really like the approach taken in the introduction to functional programming article.

mlangdon 12y ago
As somebody who can still only grow a neck beard, I've been trying to get into functional for a while now. Maybe it's because the examples are in python (a non-crazy looking language I've written a lot of lines in), but this is the first time I've read an FP article and thought I might enjoy explicitly using this stuff. I've been low-side effect and anti global for a while, but filter() is sexy.
thmcmahon 12y ago
Yep great article. As a beginner programmer I find functional more intuitive than OOP, there just seems to be less abstract concepts and boilerplate.
- splinterofchaos 12y ago
  There do exist object-oriented functional languages (Ocaml). Functional vs OOP is a false dichotomy, though a very common one. I prefer to use functional techniques in imperative languages with simple objects.
copx 12y ago
Well I only noticed how much less efficient the "functional" code is, downright wasteful even. And nobody is going to tell me that this: def move_cars(): for i, _ in enumerate(car_positions): if random() > 0.3: car_positions[i] += 1 ..is not way more readable and clear than this: def move_cars(car_positions): return map(lambda x: x + 1 if random() > 0.3 else x, car_positions) If you ask me the article makes a good argument against functional programming.
- splinterofchaos 12y ago
  How about: def move_pos(x): if random() > 0.3: return x + 1 return x def move_cars(positions): return map(move_pos, positions) I do not believe that functional programming benefits from brevity, except at the top layer. Unfortunately, functional programmers often expand their equations which, having examined them thoroughly, they understand implicitly, but can give too much information to the reader all at once. Though, I have to agree, the FP community really hasn't been able to demonstrate how to do it without losing efficiency, and yet many proponents claim we should abandon all other paradigms. All of these articles seem very biassed towards FP. I enjoy functional programming, but I prefer to work in imperative languages where I have a choice between paradigms.

blubbi2 12y ago

(commenting on one of the articles) Wow. Just stumbled upon the following quote and read the corresponding article. > Programming language comparisons usually focus on the brevity and expressiveness of the language. If the solution to a programming problem has fewer lines and is “easier to understand” or “clearer” in one language than another, that is an argument for using the former over the latter. This comparison is useful if one supposes that the art of programming is primarily concerned with writing programs. It isn’t, of course. It is mostly concerned with debugging programs. - https://codewords.hackerschool.com/issues/one/why-are-objects-so-hard-to-debug https://codewords.hackerschool.com/issues/one/why-are-object... > In summary, then, every concept that object-orientation brings to the table makes debugging harder. > If you believe (as I do) that the majority of effort a programmer expends is devoted to finding and fixing bugs, then an imperative programming approach will be more efficient (in programmer time) than an object-oriented approach.

seanmcdirmid 12y ago
> - https://codewords.hackerschool.com/issues/one/why-are-object.. https://codewords.hackerschool.com/issues/one/why-are-object.... > In all seriousness, this is one of the best articles I've ever read. I couldn't agree more with the author. I'm not sure if you are being serious (you say you are, so Po's law), but this is a bad article written by someone who I guess must be a novice who thinks he knows something now but will look back on this 5 years later and cringe; examples... > From the perspective of debugging, an instance variable is not in the scope of any of the methods on the stack. He might as well be talking about heap allocated structs in C. > This threatens to increase the search space, and suggests that avoiding instance variables in favor of passing arguments might be a better strategy where possible. State should be stack allocated, except when it really is state (even if hidden in a monad). > if you make the mistake of defining public “setter” methods, then the instance variables with setter methods become effectively global variables: if the value of the instance variable is incorrect at some point, that incorrect value might have been set anywhere in your code. I'm trying really hard now to not be sarcastic. > So, to avoid making your object-oriented code harder to debug than imperative code, you need to not use any public instance variables, and also avoid defining setter methods. How does this guy define imperative code? Definitely not C where all members of a (heap allocated) struct are public? He then describes the fragile base class problem without really understanding what that means. > The technical term for a programming paradigm which uses neither inheritance nor instance variables is imperative (or functional) programming. Ok, I can't stop myself from laughing at this point; I can't really go any further. You know, we all go through this as programmers. We start knowing nothing, then we get a couple of years of experience and think we know everything....then we get 10 years of experience and realize we still don't know very much and what we thought we knew were just delusions of grandeur. I won't say much about the rest of the publication. The nice thing about the internet is that anyone can produce something and make it available to read.

beefsack 12y ago

Typo in the functional programming article (which was a great read): > Every time a person reads afor loop

davidbalbert 12y ago
Fixed. Thanks!
- dorian-graph 12y ago
  Another typo in the same article: > race() recurses3 with the result of run_step_of_race(). Edit: Finished reading the article. Brilliant. Even the footnotes were better explanations than commonly found.

morninj 12y ago

Looks great! It would be nice if I could subscribe by email.

hughstephens 12y ago
+1 would love email subscription. Just bung up a Mailchimp account and you can even connect the RSS others have been asking :)
melvinmt 12y ago
I second this, I typically forget about these things (meaning I never bother to look for new issues) until I get the email.
jscn 12y ago
Thirded. Ever since Google Reader shut down, I've stopped using RSS. I much prefer to get newsletters in my inbox now.
- owyn 12y ago
  If you're actually missing RSS try "the old reader", it's pretty much what Reader was. http://theoldreader.com http://theoldreader.com Although avoiding RSS is probably a good thing for productivity in general. :)

akanet 12y ago

Dan Luu's article about transitive equality and floating point numbers is pretty amusing. (https://codewords.hackerschool.com/issues/one/when-is-equality-transitive-and-other-floating-point-curiosities https://codewords.hackerschool.com/issues/one/when-is-equali...). Here's a little tidbit from the article (notice that he's shown an example in Haskell where A == B, B == C, but A != C): $ ghci Prelude> -- Hi! I'm a comment! Prelude> -- 2^53 == 2.0^53 Prelude> 9007199254740992 == 9007199254740992.0 True Prelude> -- 2.0^53 == 2^53 + 1 Prelude> 9007199254740992.0 == 9007199254740993 True Prelude> -- 2^53 == 2^53 + 1 Prelude> 9007199254740992 == 9007199254740993 False

copascetic 12y ago
This example is misleading, and I don't think the article addresses the subtleties. Basically, the third line is not like the other two. Because none of the numbers involved in #3 are Doubles, Haskell will actually use the Integer type, which is basically a bignum (like integers in Python). The first two are comparing values of type Double, so the instance of Eq for Double is used, which necessarily has some inaccuracies, as shown in the second line, while the last one is using the instance of Eq for Integer. Therefore, the statement that (==) is not transitive for these types is false, because we are talking about different versions of (==) in the first two examples vs. the last one. The trick is that bare numeric literals have type Num a => a, and have their type inferred by their use. The first two examples cause the 2^53 to take on type Double, otherwise it wouldn't type check (literals with decimals in them have type Fractional a => a, of which Double is the default). The last one doesn't have any expressions with decimals, so it uses the Integer type.
copascetic 12y ago
When you specify the types of the numbers used, so that you are testing the transitivity of a single instance of Eq, you will find that transitivity does hold in this case. a :: Double a = 2^53 b :: Double b = 2.0^53 c :: Double c = 2^53 + 1 main :: IO () main = do print $ a == b -- True print $ b == c -- True print $ a == c -- True

rdc12 12y ago

From the article Option and null in dynamic languages [1] "Languages and libraries are defined not by what they make possible (the Church-Turing thesis tells us that), but by what they make easy." The Church-Turing thesis tells us about what is fundamentally computable, what a library decides to implement is not the same thing. Libraries are not about what is fundamentally computable, but about abstracting away the mechanics of some problem. While no library can solve the halting problem, that in no way implies that two libraries expose the same things to the end user of the library, even in a related field. [1] https://codewords.hackerschool.com/issues/one/option-and-null-in-dynamic-languages https://codewords.hackerschool.com/issues/one/option-and-nul...

rntz 12y ago
I can't tell whether you intend to agree or disagree with the quote. Your tone suggests you are disagreeing, but your content to me seems to be in agreement. (I am the article author.)
- jfarmer 12y ago
  Welcome to HN!
- rdc12 12y ago
  Disagreeing, but it was late when I wrote it. I guess my counter argument would be that what is fundamentally computable and what someone choices to implement in a library are not the same thing. With languages that may be a bit closer to the truth, but I would also add things like what the language makes safe (type safety, memory safety etc). I did on the whole like your article thou, that small bit just got to me a bit
LukeB42 12y ago
It's almost as if you could say languages and libraries are defined by what they make easy..

dkarapetyan 12y ago

I like curated content. In fact a lot of my reading about programming now comes from things like ruby/python/html/javascript/open source/etc. weekly email lists. The internet has too much noise when it comes to programming stuff and the weekly emails cut through the cruft. This will be another set of articles I add to my reading list instead of trying to find gems on HN or r/programming.