Threads for pashields

  1. 4

    Although I agree with the overall point of the piece, I have some issues with it:

    • If you pluralize the word code, my level of respect for your piece/talk/site/blog drops about 40% instantly. The only people I’ve seen do this are programmers in a satirical context and technologically illiterate people, of which the author is neither. The same goes for saying “a code”.

    • Some people find it difficult to code, believe it or not, and many projects aren’t easy even if you can. For example, I can code and have for several years, but if I wanted to develop a device with a microcontroller I’d hire a professional programmer that specializes in low-level languages because my specialty is CSS, and if I had to write in a very low-level language the code would be horrible.

    • 3 users marked this as spam, probably because there’s a giant advertisement for “outstanding” courses in Javascript that takes up half of my screen.

    • Bolding every other word makes you sound ridiculous.

    • So does underlining half of your text.

    1. 3

      Use of the word “codes” is more common in fields with programming that aren’t computer science (physics, chemistry, mathematics, etc.). You may find it particularly common amongst older programmers/scientists who came up through these alternate disciplines because computer science was not a codified major or department.

      Weirded me out too, but since it was mostly Yale faculty and research scientists who I noticed using it, I assumed it was more me than them.

      1. 2

        If you pluralize the word code, my level of respect for your piece/talk/site/blog drops about 40% instantly.

        I suspect in this case English is not his first language.

        3 users marked this as spam…

        It doesn’t help that @davidb583 only submits links to his blog.

      1. 2

        It doesn’t negate the basic point, but the chart on slide 6 is nonsense. It doesn’t appear to measure anything (it just presumes the time=# of records). Moreover it then uses a non-linear scale against a linear scale to create the illusion of exponential growth in the non-streaming case, despite the “data” not indicating anything of the sort.

        Bad charts are made to mislead people into decisions they wouldn’t otherwise make. The pitch here appears to be solid, so there isn’t any reason to water it down.

        I should note that the speaker may have covered all this in his talk, but it’d be nice to say that it is a silly chart in the slide notes.

        1. 1

          You’re right, that is a weak and misleading slide. I’ve updated the speaker notes to say so and will replace it if I do the talk again. I blame the Pecha Kucha format of the talk… I needed something to display while I finished my point about the previous slide.

          1. 1

            For what it’s worth, I did another (slightly longer) version of this talk and changed the offensive slide. The new slides are here: https://speakerdeck.com/stig/sbjson-4-dont-make-me-wait

          1. 5

            I’m not clear on what the real problems are with the author’s REST-ish example. He complains that he’s adding non-email fields to his email model, which is correct: there should be a model containing the email (or a reference to it) that is being modified. His other concern is that now the server has to detect state changes and respond to them, but that’s more or less the whole idea here. If responding to state change is bad a priori, then I’m not sure where one would go but to RPC ALL THE THINGS.

            I wouldn’t want to encourage a “one-size-fits-all” mentality, but there is a whole lot more half-assed internal custom APIs (or protocols) than there are ones where someone laid out a high quality alternative architecture that matched the domain. In fewer words, not using REST (or whatever) is fine, but swap it for another well thought out architecture (even your own), not something ad-hoc.

            1. 2

              My first real job after I graduated from college involved a lot of R. It’s a very strange language, though there are some very cool things about it. It’s still really impressive to see packages like codetools which allow you to identify the closure variables used by a function (which can be used to great effect to export them to other process or machines for distributed computation). Some of the techniques we used for moving functions and data between machines would be challenging in most other languages. The C/C++ interop is pretty legit as well.

              It is however, a very complicated language. It has two different non-interoperable object systems. Functions like read.table are like whole semantic pies by themselves. It’s been a while since I’ve written anything in R, but I suspect I would go a little nuts if I had to write a lot of it now.