Live data from Hacker News

Show HN: Code Words, a quarterly publication about programming

codewords.hackerschool.com

61–70 of 78 posts

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

#61
post #27

Earlier quoted context omitted.

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

My point is that the _goal_ of expressiveness is still there and still valuable. We need languages that express our intent safely, clearly, and quickly. The better this is achieved, the less debugging you have to do -- because, by definition, the code will express what you want more clearly and with less room for error.

>It's not what language you use, but /how/ you use it.

How you use a language is determined by the grammar of that language. So I don't see any value in your point here, save for trying to dodge specificity and feign wisdom.

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

#62

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.

> 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 hand, 'terribad' is the kind of word that fills me with dread (combining latin and old english roots like that? The outrage!). I know language is arrived at by consensus but even if there were consensus on 'terribad', I'd not be joining it.

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

#63

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…

The expressive power of a language is definitely based on what's in the standard library. If the C standard library came with default dictionaries and other common data structures (while still allowing you to build your own) it would be a much more expressive language.

I love C, I love that I can keep most of the standard library in my head, but a greater built in eco-system would make portable code a lot easier, provide a standard reference to beat, and make the language more useful from the get go.

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

#64
post #5

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

This is an interesting perspective, but I think the author has made too much of it. OO is one of several developments that have added ways to put abstraction to work, and they are all double-edged swords, providing additional ways for a confused coder to express his confusion and work around his initial misconceptions of the problem he is attempting to solve.

The problem is not in the programming language features, any more than they are panaceas: the problem is in how we approach problem-solving. Guessing at the solution and then debugging it into acceptability, or 'guard-rail programming', as Rich Hickey has described it, is not the optimal approach in any language.

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

#65

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…

> 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-experience cannot immediately recognise itself blub to twenty years of commercial-experience.

Maybe those guys writing software that does things have figured something out as well?

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

#66
post #27
post #5

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

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

    1"hello"
http://code.kx.com/wiki/Reference/One

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

#67

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

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?

But they aren't universally accepted; e.g. Singletons and static members of objects (private or not!) are "global variables".

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

#68
post #65

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…

> 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. If you think it says something important or even coherent, then you know, it was for you, not for me.

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

#69
post #5

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

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

> imperative (or functional)

I don't think he's saying those styles are the same.

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

#70

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…

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.

Post reply on HN