Live data from Hacker News

Show HN: Code Words, a quarterly publication about programming

codewords.hackerschool.com

71–78 of 78 posts

Re: Show HN: Code Words, a quarterly publication about programming

#71
post #65

Earlier quoted context omitted.

> One thing I think we could have done better with Code Words is added short bios I'm rather glad you didn't. Sean felt justified not reading it because he believed the writer was "a novice", and I think he have acted differently if he knew this was an experienced and successful commercial programmer. But because he didn't, the rest of us can learn something really interesting: That twenty years of research-experienc…

I totally read the article; I'm very surprised it was written by a professional but it wouldn't have changed my judgement of it. I thought it was poorly written and meandering, but I probably should have kept that to myself. I guess we all have different standards. > Maybe those guys writing software that does things have figured something out as well? At this point, I really think the article should speak for itself…

I don't think you should keep your opinions to yourself. However, when you present your opinions with sarcasm and ad hominem attacks, you are bringing down the conversation to a level that is not conducive to any meaningful discussions. I don't think that was your intention, but I do think it was the result.

Re: Show HN: Code Words, a quarterly publication about programming

#72

Earlier quoted context omitted.

Global variables are terribad (imo). Dependency injection is good (imo). I don't think the article is particular clear with everything it's trying to say, but those two points seem pretty reasonable, no?

I looked up "terribad", since it seemed an unlikely typo. The luminaries at Urban Dictionary told me it was "[t]he act of being terrible and bad at the same time"; I can't for the life of me see how something could be terrible and not also be bad.

Terribad = double-plus-ungood. As opposed to plus-ungood or merely ungood. Don't think about it too hard.

Re: Show HN: Code Words, a quarterly publication about programming

#73
post #30

Earlier quoted context omitted.

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

So, you can't really just appeal to the author's authority without addressing a single one of the parents points. Is he wrong? Do the statements from the article make sense to you? Because the stuff he quoted looked like a bunch of nonsense.

Sean wasn't making points. He was being obtuse and dismissive, and made repeated statements about the author and how much he was laughing at the idea that this was being read by anybody.

I read it: I enjoyed it. I didn't run into anything I didn't understand, but I did feel like the phraseology was chosen to offend rather than inform.

For example, "global variable" was used to describe any memory cell that could change from any point in the program, either directly or indirectly. Obviously any public function (setter or method) can change that value. If the instance variable is static or a member of a singleton, then it really is a global variable, but if the object is simply long-lived it might be equivalent with regards to the impact it has on debugging.

Given that this isn't the ordinary use of the term "global variable", one has to read the article to understand that this is what is intended, but at least the article isn't very long. However because the author chose to overload the term (rightly or wrongly), it makes extracting the essence from a few quotes very difficult.

However if you read the article: What part did you have trouble understanding?

Re: Show HN: Code Words, a quarterly publication about programming

#74
post #42
post #40

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 m…

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

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

Re: Show HN: Code Words, a quarterly publication about programming

#75
post #61

Earlier quoted context omitted.

> A language that is brief and concise gives you fewer opportunities to make mistakes I don't think that's necessarily true. Look at brainfuck! But in all seriousness, dynamically typed languages could be categorized as "more expressive" than statically typed languages, and generally allow for cleaner interfaces, but turns static-typing compile-time errors into dynamic run-time errors. What's worse is that your tests…

I'm not willing to say that dynamically typed languages are more expressive. It's hard to compare two languages and just say "A is more expressive than B." Usually they just express different things with different degrees of conciseness. (In particular, Brainfuck is not concise. It has a small grammar, but an equivalent print statement has much more room for error, since it takes a longer string of obfuscated code to…

I agree with your skepticism of the idea that that dynamically typed languages are more expressive. It is not as if we are writing poetry here; we are actually trying to specify, with great accuracy, a virtual machine. Fortunately, we can state for sure that there is no fundamental difference between the capabilities of Turing-equivalence languages; if this were not the case, the arguments over expressiveness would be interminable.

Re: Show HN: Code Words, a quarterly publication about programming

#76

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

Yep great article. As a beginner programmer I find functional more intuitive than OOP, there just seems to be less abstract concepts and boilerplate.

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.

Re: Show HN: Code Words, a quarterly publication about programming

#77

Earlier quoted context omitted.

I looked up "terribad", since it seemed an unlikely typo. The luminaries at Urban Dictionary told me it was "[t]he act of being terrible and bad at the same time"; I can't for the life of me see how something could be terrible and not also be bad.

> I can't for the life of me see how something could be terrible and not also be bad. Terrible doesn't necessarily imply bad, it can also imply fear or awe, in which case it's perfectly possible to be terrible and not bad. It's similar in that way to 'awful', which these days is used almost exclusively for something that is bad, but occasionally you'll still find the old usage (awe-filling) appearing. On the other ha…

"Television? The word is half Greek, half Latin. No good can come of it." - C.P. Scott

Re: Show HN: Code Words, a quarterly publication about programming

#78

Earlier quoted context omitted.

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…

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…

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.
Post reply on HN