

Show HN: Code Words, a quarterly publication about programming - nicholasjbs
https://codewords.hackerschool.com/

======
blubbi2
(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-
object...](https://codewords.hackerschool.com/issues/one/why-are-objects-so-
hard-to-debug)

> 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
> \- [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.

~~~
davidbalbert
One thing I think we could have done better with Code Words is added short
bios. Bios add context, which is lacking here. Here's R0ml's bio from
2006[^1]:

 _r0ml is an software architect and systems designer with over thirty years of
experience. For two decades, r0ml worked on Wall Street, developing market
data, trading, risk management, and quantitative analysis systems. More
recently, as chief technical architect at AT &T Wireless, he drove the
improvement of their CRM, ERP, commission, and data warehousing systems. Over
the last several years, r0ml has become increasingly interested in open source
software strategy at large enterprises, and is a frequent speaker on the
topic._

This is the same R0ml that thaumaturgy mentions in a sibling comment.

I've been lucky to meet a lot of very smart programmers over the past 3.5
years working at Hacker School, and R0ml is one of the people I respect the
most. He has a lot of opinions about programming, many of them contrarian. I
think this comes from his background. His career began in the '70s. He spent
the first third of it working in APL, the next third in Smalltalk, and the
most recent third in Java. Over the year or so that I've known R0ml, he's
planted the seeds of a number of unconventional ideas in my head (program in
the database, don't use libraries, write things from scratch, the expressive
power of a language is partially derived from what's in its standard library).
I'm sure these aren't all good ideas—maybe some of them are terrible—but
they've profoundly affected the way I go about my programming. R0ml is on the
short list of people I would want to work for if I was not running Hacker
School.

I don't bring this all up to refute your opinions–R0ml may be wrong in this
case or even in all cases–I mostly wanted to give some context explaining why
the tone of your response made me sad and frustrated. The onus is on us to
give readers context for what they're reading, and I don't think we did a
great job of that, but if you're going to write such a mean spirited response,
I think some of the onus is on you to do some research before accusing someone
of being a novice and responding in a way that feels at least partially ad
hominem.

Around a month ago, I read _Programming with Managed Time_ [^2], the paper
that you wrote with Jonathan Edwards for Onward! '14\. I thought it was
insightful, well written, and contrarian in the best of ways. The first things
I thought when I finished it was "I bet R0ml would enjoy that."

I don't mean to compare Code Words to an academic journal (it's absolutely
not), nor do I mean to compare R0ml's article to your paper in terms of scope,
research, or time put into it (yours obviously took more time and has much
greater insight than R0ml's short article). I'm just bummed that one person
who's counterintuitive opinions and experience I respect would be so quick to
dismiss the opinions of someone else who I respect for the same reasons.

I know that complaining about tone is often used to distract from more
substantive issues, but I'm going to risk doing that anyway: Please be nice!

Thanks.

[^1]:
[http://conferences.oreillynet.com/cs/os2006/view/e_spkr/1551](http://conferences.oreillynet.com/cs/os2006/view/e_spkr/1551)

[^2]:
[http://research.microsoft.com/pubs/211297/onward14.pdf](http://research.microsoft.com/pubs/211297/onward14.pdf)

~~~
seanmcdirmid
I've given it a whole day to ponder and I apologize for calling this article
out. The article was really bad in my opinion (not just disagreeable, but
poorly argued), but it should have just remained my opinion. I don't care who
wrote this, frankly, I never read bios anyways. It would however, prevented me
from blathering on about why I thought this article was written.

I would suggest more editing in the future, not to change messages, but in the
way that we always need other people to read our work to provide some external
perspective.

~~~
davidbalbert
Thanks for the considered response. I do think we could have done a better job
editing Code Words. We'll try to do better next issue.

------
akanet
Dan Luu's article about transitive equality and floating point numbers is
pretty amusing. ([https://codewords.hackerschool.com/issues/one/when-is-
equali...](https://codewords.hackerschool.com/issues/one/when-is-equality-
transitive-and-other-floating-point-curiosities)).

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
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.

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

~~~
davidbalbert
Not right now :(. I will add one later this evening.

~~~
beefsack
Great publication, will subscribe as soon as the feed's available.

~~~
kbenson
Seconded.

~~~
davidbalbert
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.

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

~~~
thmcmahon
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
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.

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

~~~
jscn
Thirded.

Ever since Google Reader shut down, I've stopped using RSS. I much prefer to
get newsletters in my inbox now.

~~~
owyn
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. :)

------
rdc12
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-
nul...](https://codewords.hackerschool.com/issues/one/option-and-null-in-
dynamic-languages)

~~~
rntz
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.)

~~~
rdc12
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

------
dkarapetyan
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.

------
beefsack
Typo in the functional programming article (which was a great read):

> Every time a person reads _afor_ loop

~~~
davidbalbert
Fixed. Thanks!

~~~
dorian-graph
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.

