1. 22

    This came up again in the context of the recent Dyn DDoS and comes up regularly in discussion of the Internet of Things and its general total lack of software or security.

    Link? I’m wondering why people think this. Do you mean people are arguing it would have made taking over the IoT devices impossible in the first place, or that a static type system would somehow make handling a DDoS possible? In any case, I think any reasonable person would see through these statements pretty quickly. You can find someone who has said just about anything.

    As static typing becomes more elaborate the scope of the bugs it can prevent becomes wider, but it comes with an additional cost: Build times.

    Ocaml has pretty reasonable build times. IMO, I would say Ocaml build times are close to Go given how much moe expressive the type system is than Go’s.

    My general experience of the correctness software written in fancy statically typed languages is not overwhelmingly positive compared to that of software written in dynamic languages. If anything it trends slightly negative. This suggests that for the scale of many projects the costs and benefits are close enough that this actually matters.

    Having written and inherited code in a dynamically typed language, I can say the big win, in my experience, is refactoring. IME, a lot of people (on both sides) talk about producing code the first time. IME, that is pretty easy no matter what language one is it. Coming back to code 6 months or 6 years later is a much different story.

    1. 14

      Coming back to code 6 months or 6 years later is a much different story.

      Oh gosh this so much.

      I’ve inherited various chunks of under-documented under-tested code over time. Type-y assistance where present has made all the difference in these situations!

      1. 11

        Maintaining nearly 80KLOC of OCaml over three years, I was able to use repeated edit-compile-error-scratch-head sessions as a means to re-acquaint myself with the system. But this is such a low bar; we need better. Maintaining more than 1MLOC of Smalltalk over the past twelve years, I found leaning on a type system–even OCaml’s–to be quite impoverished compared to a live, self-navigating system of uniform, recursively designed objects and messages.

        1. 4

          I’ve heard that refactoring smalltalk is a great experience. I don’t hear the same about erlang. Is this just a matter of the smalltalk folks focusing more on tooling? They’re such similar languages in a lot of ways, I would think you could achieve similar things, but I don’t hear people talking about refactoring erlang systems with such reverence.

          1. 4

            I can’t do it justice in a few lines, and I don’t want to clutter the discussion here. I will say that’s not just about Smalltalk but the mindset that Smalltalk fostered and, in turn, fed back into the evolution of Smalltalk. Go back, at least, to the writings of Ward Cunningham, Kent Beck, Ralph Johnson, and Brian Foote. As for Smalltalk itself, tooling almost emerges spontaneously from it because–I think–of the attributes I noted in the last line of my previous reply.

          2. 3

            to be quite impoverished compared to a live, self-navigating system of uniform, recursively designed objects and messages.

            Do you mean that the code bases are uniform in this way or that any program written in Smalltalk will have this quality? One reason I like a good type system is because most code is not uniform and the type system let’s me take messes and make them clean, pretty safely. But a type system is no panacea, of course.

            1. 5

              You can write bad code in Smalltalk, as in any other language. One thing that sets Smalltalk apart is that it’s as much a system as it is a language. Further, it’s a system represented solely in terms of objects sending messages to other objects. Further still, it’s a running, fully reflective, live system with that entire object graph readily introspected and manipulated. So, in Smalltalk–as Alan Kay said–architecture (uniform recursive object system) dominates materials (code). In Smalltalk, even bad code is easily navigated, understood, and refactored.

        2. 7

          “Ocaml build times are close to Go given how much moe expressive the type system is than Go’s.”

          Build time is measured the same, no matter the language. One could say a longer build time is justified because of certain benefits, but it’s still a longer build time.

          1. 4

            I’m not sure what I said you’re disagreeing or correcting me on. I am saying Ocaml builds fast, but slower than Go, but you get a lot of typing out of that extra time.

            1. 3

              That seems reasonable. The original statement might be more clear to me if it said “close enough to Go given…”

          2. 3

            Ocaml has pretty reasonable build times. IMO, I would say Ocaml build times are close to Go given how much moe expressive the type system is than Go’s.

            That’s a good example, thanks. I’ll add it in.

          1. 12

            It’s great to see a job posting on here. I’ve been trying to figure out how to find jobs without going through a recruiter for a while but I’ve more or less come up with nothing, so seeing this gives me a spark of hope.

            For this job specifically I’m sort of tempted to apply since I’m familiar with everything you mention, and I want to continue my current pattern of working remotely, but I’m put off a bit by the title ‘Infrastructure Engineer’. I don’t think you can effectively work on infrastructure without a good understanding of the application(s) using it, and vice versa, so for my whole career I’ve been involved in both, and my job titles have been correspondingly general. Perhaps you could expand a little on that…?

            1. 5

              TL;DR: Naming is hard - you should apply!

              It’s the end of the day here, but I’ll get back to this tomorrow with an expanded answer.

              1. 5

                Seconding this, it’d be nice to see more job postings on here. The tag can be filtered depending on if you’re in the market.

                1. 3

                  Definitely. Looking at history though, it seems the tag has not been used correctly for the most part. I guess we need to be more vigilant about flagging those that are tagged job but aren’t job postings?

                  1. 3

                    I guess we need to be more vigilant about flagging those that are tagged job but aren’t job postings?

                    Agreed! I’ve gone through and suggested removing the job tag from a few of the recent ones that are not actually job ads. If more do the same, I suppose they’ll be removed? It should help people who look at “prior art” to pick the right tag.

                    1. 6

                      I’ve gone through and suggested removing the job tag from a few of the recent ones that are not actually job ads. If more do the same, I suppose they’ll be removed?

                      Just did the same, most of the recent job stories are now properly tagged. We did it! :)

                2. 3

                  I don’t think you can effectively work on infrastructure without a good understanding of the application(s) using it, and vice versa, so for my whole career I’ve been involved in both,

                  I absolutely agree. And there’s a good deal of overlap here. We are a company of about 30 people. Because we’re so small, we don’t have room for hyper-specialists. We don’t have a group of people who develop the software, and another group that operates the software. We have a degree of freedom and responsibility to do what we feel is right for the company to succeed.

                  As an example I recently needed to do some maintenance on a small service called from our main app. I first spent time investigating what would happen to our main app in this case, by reading the code and looking at New Relic during running the maintenance operation in our test environment. I found that our main app was meant to handle this case, but due to a bug it did not do so properly. I identified & implemented a fix, and waited until the next release of the app to do the maintenance on the auxiliary app.

                  and my job titles have been correspondingly general.

                  Personally (and I don’t speak for my boss who wrote the ad I linked to here) I think a job title is just a hook to hang the job description off of. I don’t think one is terribly meaningful without the other, and I wouldn’t worry too much about that label. For most of my career I too have been involved in both development, deployment and live support of applications, although my job titles have been all over the place.

                  1. 2

                    Personally (and I don’t speak for my boss who wrote the ad I linked to here) I think a job title is just a hook to hang the job description off of.

                    I agree though!

                    1. 1

                      Oh hai! ;-)

                1. 2

                  I’m not sure Russia deserves to be on this list any more so than the United States, Mexico and Canada, which are all somehow absent. Sure, some remote regions in Russia did end up being held hostage due to the politics and the timezone cleanup from Moscow, but as far as Moscow Time is concerned (which affects most of the population of Russia), changes have been announced at least several months in advance, and, thankfully, now with the elimination of the yearly DST changes all together since 2011 (and across all of Russia), things should be rather calm and quiet, although, to be fair, the original lack of much thought of whether there is any difference between the permanent winter time or the permanent summer time could probably have been given more thought, indeed.


                  I think what we really need in the world is the elimination of this stupid DST in the first place. Then instead of having to switch the clocks twice a year throughout most of the West (sans Russia, Belarus, Arizona, Hawaii, Saskatchewan), and experience the associated seasonal loss of productivity for a few weeks as a result, clocks could be set to a permanent offset from the GMT, and we basically wouldn’t so much as need any TZ files to start with.

                  1. 1

                    I think what we really need in the world is the elimination of this stupid DST in the first place.

                    I think it’s very easy to forget the human aspects in favour of technical simplicity: http://www.americanthinker.com/blog/2013/03/in_defense_of_daylight_savings_time.html

                    clocks could be set to a permanent offset from the GMT

                    That feels very Anglocentric of you - given the ambiguities of “GMT”, UTC would seem a much better choice! ;)

                    1. 2

                      I think it’s very easy to forget the human aspects in favour of technical simplicity: http://www.americanthinker.com/blog/2013/03/in_defense_of_daylight_savings_time.html

                      This argument doesn’t hold up. Just move the whole timezone forward one hour and abolish DST, you’ll still have all the advantages of DST in summer while in winter (most) people will go to work and back home in the dark anyway.

                      1. 1

                        That’s actually what Russia did in 2011 – abolished the winter/summer time, and went into a permanent DST in March 2011. Then come November, people supposedly started hated going to school/work in complete darkness in most of Russia, only to be greeted with the same darkness when coming back home. Of course, the opposition and the foreign-sponsored media blamed everything on the ruling party. So, in October 2014, Russia once again changed all clocks in line with the DST in Europe, only now going into a permanent winter time. Pretty neat!

                        BTW, reading http://en.wikipedia.org/wiki/Daylight_saving_time_in_the_United_States, quite a few states did actually want to go into a permanent DST, but, apparently, the U.S. federal law, Uniform Time Act, prohibits states from extending daylight savings time, although I’m not exactly sure why they can’t just move into a neighbouring timezone on the winter time (which supposedly requires only a DoT authorisation, if even that), instead of remaining on their original timezone yet with a permanent DST.

                        For example, Nevada is now asking U.S. Congress to let it stay on permanent DST within its Pacific Time, which will result in Nevada having the exact same time as Arizona, only in Arizona the time is called Mountain Time (without DST). Why not just switch into Mountain Time, and abandon DST, just like Arizona did without needing any U.S. Congress approvals? After all, “Pacific” isn’t exactly what comes to mind when you’re thinking Nevada, now is it?

                      2. 2

                        It’s not at all about just the technological simplicity – there have been studies that have shown that the incidence of health and safety related incidents increases dramatically around the time that the clocks shift (heart attacks, doctor visits, auto accidents). So, the “human aspects” by far exceed the technological ones.

                        Of course, the real-estate brokers, as well as the golf and the brick-and-mortar retail industry, will always campaign against the abolishment of DST. I am not at all surprised that your article in defence of DST was authored by a real-estate broker in LA.