21–30 of 78 posts
I really like the approach taken in the introduction to functional programming article.
Earlier quoted context omitted.
> - 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.…
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…
Earlier quoted context omitted.
[deleted]
You don't get to be a good writer via ad hominem attacks either. Having had several interactions with the author, I'd say he has a knack for putting forth controversial theses like the one in the article. I've disagreed with lots of them--but I've always gotten smarter thinking about why I've disagreed with them (and have often been left with the suspicion that he really might be right). When I was younger I used to…
Typo in the functional programming article (which was a great read): > Every time a person reads afor loop
Earlier quoted context omitted.
Great publication, will subscribe as soon as the feed's available.
Seconded.
In the mean time, we'll tweet about every issue on 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.
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(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…
I don't really get this. If you can write programs that have fewer bugs because your language is expressive and prevents them, then naturally there is a lot to gain from valuing a language primarily by how it works when writing code.
A language that is brief and concise gives you fewer opportunities to make mistakes:
print "hello"
console.out.sprintf("%1$s", "hello");
Dan Luu's article about transitive equality and floating point numbers is pretty amusing. ( 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 ==…
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.
Dan Luu's article about transitive equality and floating point numbers is pretty amusing. ( 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 ==…
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 -- TrueEarlier quoted context omitted.
> - 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.…
> 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 The article's author appears to be Robert Lefkowitz. If it is, then the author transitioned from nuclear physics to programming in the 1970s, has been a speaker at PyCon, currently seems to be writing software in Haskell, Ruby, and Java, gave several talks at OSCon in 2…
Is he wrong? Do the statements from the article make sense to you? Because the stuff he quoted looked like a bunch of nonsense.