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…
Show HN: Code Words, a quarterly publication about programming
71–78 of 78 posts
Re: Show HN: Code Words, a quarterly publication about programming
#72Earlier 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.
Re: Show HN: Code Words, a quarterly publication about programming
#73Earlier 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.
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
#74From 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.)
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
#75Earlier 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…
Re: Show HN: Code Words, a quarterly publication about programming
#76I 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.
Re: Show HN: Code Words, a quarterly publication about programming
#77Earlier 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…
Re: Show HN: Code Words, a quarterly publication about programming
#78Earlier 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…