Show HN: Code Words, a quarterly publication about programming • Hacker News Board

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

#51

Post by scarecrowbob » Sat, Dec 06, 2014, 4:40 PM UTC

bshimmin wrote: post #45

forrestthewoods wrote: post #32

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.

Since you asked, it's possible that terrible things can be both "good" in the sense of 'not evil' ("he's a terrific guy") and "good" in the sense of 'well done' ("Oz, the Great and Terrible").

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

#52

Post by jscn » Sat, Dec 06, 2014, 4:56 PM UTC

morninj wrote: post #9

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

Thirded.

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

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

#53

Post by noarchy » Sat, Dec 06, 2014, 5:35 PM UTC

bshimmin wrote: post #45

forrestthewoods wrote: post #32

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.

The HN Pedantry Patrol never misses a chance to strike.

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

#54

Post by jfarmer » Sat, Dec 06, 2014, 6:02 PM UTC

rntz wrote: post #42

rdc12 wrote: 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.)

Welcome to HN!

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

#55

Post by dkarapetyan » Sat, Dec 06, 2014, 6:04 PM UTC

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.

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

#56

Post by doktrin » Sat, Dec 06, 2014, 6:25 PM UTC

Blackthorn wrote: post #35

doktrin wrote: post #30

Earlier quoted context omitted.

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.

The parent's points were literally about his authority, so the response was perfectly fine.

No, while he did make assumptions about the author's experience he directly addressed multiple points from the piece.

It wasn't "just" about authority. Assumptions were made about authority based on bush league level mistakes in the writing.

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

#57

Post by owyn » Sat, Dec 06, 2014, 7:15 PM UTC

jscn wrote: post #52

morninj wrote: post #9

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

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

If you're actually missing RSS try "the old reader", it's pretty much what Reader was.

http://theoldreader.com

Although avoiding RSS is probably a good thing for productivity in general. :)

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

#58

Post by copx » Sat, Dec 06, 2014, 7:23 PM UTC

therealdrag0 wrote: post #4

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

Well I only noticed how much less efficient the "functional" code is, downright wasteful even. And nobody is going to tell me that this:

  def move_cars():
  for i, _ in enumerate(car_positions):
      if random() > 0.3:
          car_positions[i] += 1

..is not way more readable and clear than this:

  def move_cars(car_positions):
      return map(lambda x: x + 1 if random() > 0.3 else x,
                 car_positions)

If you ask me the article makes a good argument against functional programming.

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

#59

Post by splinterofchaos » Sat, Dec 06, 2014, 8:07 PM UTC

copx wrote: post #58

therealdrag0 wrote: post #4

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

Well I only noticed how much less efficient the "functional" code is, downright wasteful even. And nobody is going to tell me that this: def move_cars(): for i, _ in enumerate(car_positions): if random() > 0.3: car_positions[i] += 1 ..is not way more readable and clear than this: def move_cars(car_positions): return map(lambda x: x + 1 if random() > 0.3 else x, car_positions) If you ask me the article makes a good ar…

How about:

    def move_pos(x):
        if random() > 0.3:
            return x + 1
        return x

    def move_cars(positions):
        return map(move_pos, positions)

I do not believe that functional programming benefits from brevity, except at the top layer. Unfortunately, functional programmers often expand their equations which, having examined them thoroughly, they understand implicitly, but can give too much information to the reader all at once.

Though, I have to agree, the FP community really hasn't been able to demonstrate how to do it without losing efficiency, and yet many proponents claim we should abandon all other paradigms. All of these articles seem very biassed towards FP.

I enjoy functional programming, but I prefer to work in imperative languages where I have a choice between paradigms.

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

#60

Post by splinterofchaos » Sat, Dec 06, 2014, 8:25 PM UTC

Retra wrote: post #27

blubbi2 wrote: 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.…

> 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 might not cover the specific conditions that cause it. So, while you might consider C++ less expressive and concise than Python, at least you'll never try to take the square root of a string.

The ease of writing bug-free code and debugging depends on a lot of factors. How well designed is the interface/API? How structured is the code? How good are the available tools? It's not what language you use, but /how/ you use it.