zwegner

Seems like it might be an appropriate place for representative democracy. Every year or so, everyone votes on a new CEO, etc.

There's probably a lot of decisions that could still be left up to workers, but I agree that having some clear direction is important, and there's lots of questions that just need a "no". The BDFL model of open source is a good example of how this can work without excessive hierarchy.

I agree with most of the points of the article (finding a balance for testing, naming, writing readable code, etc.) I'm not a fan of the tone, though. I might consider myself a "rockstar" programmer, if not for the fact that it sounds incredibly douchey. At least I'm closer to that than a "workhorse". And yet I don't think I fall into the negative stereotypes he mentions... I guess that explains my reaction (not to mention the self-quoting of tweets).

My biggest problem with software development as a profession is that people don't think before they do it. I've found that a lot of people just hack away randomly with some code that approximates their idea of how it should work. It usually doesn't work, so they just change things aimlessly until it appears to. I can definitely understand this mentality, I've been there--it happens to me when I'm programming beyond my understanding. But I try very hard to recognize when this happens, and stop to think more. There's very little value in writing code that even the author doesn't understand. Accumulate enough of this code, and you get the typical horribly-designed patchwork mess that nobody can read, debug, or change.

To me, the ability to solve problems that you're not familiar with is paramount in importance for actual software engineering. If you're just building some CRUDdy business app that does nothing remotely complicated, OK. But bubble sorts and link shorteners? Come on, that stuff is simple. Maybe you never need to implement those specific examples, but as a placeholder for general problem-solving skill, it's a low bar.

Perhaps that's why the title refers to "software developer" rather than "software engineer". I don't really know. But I do wish there were more jobs that required real problem solving skills (and don't require a PhD...).

Consider me nerd-sniped. I typed the last post on my phone, but just had to bust out the laptop to check. Noticed a couple bugs I had: the for-loop initializers need to be set, and there needs to be an empty statement after the cont: label.

The goto version only has one unconditional branch outside of a loop, rather than three conditional branches inside loops. Anyways, the speed difference shouldn't be too big, as the branches are pretty predictable (pretty much always not taken).

Quick benchmark of the original and mine, up to the first 3000 triples:

  $ c++ -O3 pyth1.cpp  && time ./a.out | md5
  33aa33d6cad59951489757e06aeb5a15
  
  real    0m5.492s
  user    0m5.484s
  sys     0m0.007s
  $ c++ -O3 pyth2.cpp  && time ./a.out | md5
  33aa33d6cad59951489757e06aeb5a15
  
  real    0m4.248s
  user    0m4.238s
  sys     0m0.011s

All those if statements inside loops... would be a lot cleaner (and faster!) to just use a single goto statement:

  goto cont;

  for (; ; ++z)
    for (; x <= z; ++x)
      for (; y <= z; ++y) {
        if (x*x + y*y == z*z) return *this;
  cont:
      }

Speaking of "real autonomy", did you put any further thought into your idea of Autonomy Funds[0]?

I thought it was very intriguing, if perhaps hard to get off the ground. Definitely would be a good antidote to the kind of SV craziness you describe, but of course not really in line with the status quo. I'd like to see some more discussion on this, and maybe get involved (though my business knowledge is near nil).

[0] https://news.ycombinator.com/item?id=5578195

Awesome! I've been waiting for a long time for the HN guys to implement this (though dang notes in a sibling comment it's probably coming, sweet!), didn't even think about greasemonkey...

I've made a few tiny edits so that it works with https (the github repo has this, but not on userscripts.org), as well as the threads page. Also, I put slightly less space between the [-] and the commenter name, it looks a bit better/more reddity.

I didn't bother making it work for anything but the greasemonkey script, or trying to upload it to userscripts.org. But it might still be useful: https://github.com/zwegner/HN-Comment-Hider

That runs into the scalability problem that I mentioned--someone (say, a Mechanical Turk user) can solve that problem once, and put it in a database. To avoid this, there needs to be a way to generate them cheaply, so you pretty much need a computer that can solve the problem in the first place.

Basically, my point is that there's no such thing as "uniquely human intelligence". There's lots of problems that fall into that category now, but with the continuing rise of computational power, it's getting harder and harder to find new problems of this sort without excluding a lot of real people.

That's what I was referring to with services only allowing one (or N) accounts per person. A spammer could use the signature multiple times, but would need new email providers for every single account.

And as an uncle (?) comment points out, there could possibly be blacklists of signatures of spammers shared between providers. That definitely would cause some new problems, of course, but who knows what the future may hold...

Presumably a service would only allow one (or a few) accounts per actual person. The end user will still need some amount of security. I had in mind some challenge-response mechanism, like:

  Person signs government ID number with public key, presents it to authority
  Authority signs public key and asserts it belongs to a real human
  Service presents random number at signup time
  Person signs the random number with the same public key, and presents the key signed by the authority

Good point. I imagine that detecting such behavior will also be pretty difficult. It's one thing in a forum, where you'd maybe want to discriminate against idiots (but that would still leave you open to the problem of shills/sock puppets). But for big companies like Google, would they really want to open that can of worms?

Of course, there's a quite relevant xkcd: https://xkcd.com/810/

This particular issue (AI performance on captchas) is really quite fascinating. It's an arms race, but the problem is, only one side can win. Google is claiming they have improved their system in some (understandably) unspecified way, but there's only so far this can go. Captchas need to detect whether someone is human, but it has to work for everyone, ideally, even those with disabilities. Any simple task a human can do will eventually be able to be automated. Tasks that aren't currently feasible to be automated, say some natural language processing tasks, have another problem: scalability. To prevent simple databases of problems -> solutions, the problems need to be generated en masse, and for cheap, which means a computer needs to generate the solutions in the first place. And of course, paying people to just do captchas all day already happens.

The street address/book scan approach that Google uses is interesting in that the exact solution is not known, so they presumably have to be somewhat forgiving in accepting answers (as their machine learning might have gotten it wrong). Perhaps this is what their "risk analysis" refers to--whether their response seems "human" enough according to their data, not necessarily whether it's correct.

I don't see a way around this problem for free services that still preserves privacy (so directly using some government-issued ID is off the table). Maybe some Persona-like digital signature system, where a person can go to a physical location with a government ID, and get a signature that says "Trusted authority X affirms that person Y is in fact a person". Obviously this still has problems, as you need to trust X, and it's a big pain in the ass.

There are parallels to the realm of passwords, which are also becoming obsolete (not that there's a good replacement...). Anything that a human can feasibly remember for a bunch of sites is becoming easier and easier for computers to guess.

So basically, computers are taking over the world, and we can't do anything to stop it. God help us all.

Oops, just realized I mixed up dynamic/lexical scoping, and it's too late to edit. Python uses lexical scoping.

The "consuming generator" problem is a good point, but their workaround misses a better solution. In Python 3, range() returns a range object, which has a __contains__ method, so you can use "in" just fine without consuming any generators. It's also much faster (it would be constant time/memory except for the fact that integers can have arbitrary size).

    l = range(5)
    print('2 in l,', 2 in l)
    print('3 in l,', 3 in l)
    print('1 in l,', 1 in l)

prints...

    2 in l, True
    3 in l, True
    1 in l, True

Also, the lambda/closure example is something that really irritates me about Python. Both dynamic and lexical scoping have this problem: they always reevaluate the variable inside the closure whenever it's called, the only difference is which parent scope the value is pulled from (the parent scope or the calling scope). It's not that the "last lambda is being reused", as the article says, but rather, there are five different lambdas, but they each refer to the same variable, which is set to 4 after the list comprehension. This sucks for metaprogramming, where you'd like to create a bunch of copies of a function with different parameterizations. There's two workarounds that I know of for this for dynamic scoping: creating another nested scope, or using keyword arguments. I'm not sure what you'd do for lexical scoping (but who uses that anyways?).

    for x in [(lambda i: lambda: i)(i) for i in range(5)]:
        print(x())

...or...

    for x in [lambda i=i: i for i in range(5)]:
        print(x())

In my purely-functional Python-like programming language, Mutagen, closures are static, so that they capture the value of variables from the enclosing scope at the point that they're defined. So this works as you'd expect, printing 0 and 1 (no list comprehensions yet, and lambdas are full functions, and of course lists are immutable so no +=):

    lambdas = []
    for x in [0, 1]:
        lambdas = lambdas + [lambda: return x;]
    for l in lambdas:
        print(l())

Yep. One of my favorite examples: https://en.wikipedia.org/wiki/Ophiocordyceps_unilateralis

Part of a pretty cool Wikipedia category: https://en.wikipedia.org/wiki/Category:Mind-altering_parasit...

As it will be then.

Two big advantages are referential transparency and memory aliasing. The sort of reordering of loops/memory/whatever like described on the Halide page is just the beginning of the kind of optimizations that are possible. Perhaps static analysis could ameliorate this to some extent, but it will take far more computational power, and will always be subject to the halting problem. There's also current problems with the C standard that could change in a new standard, or maybe optionally ignored in the compiler, so it depends on your definition of "C". Examples of this are struct member ordering being fixed, or lack of tail call optimization (at least guaranteed TCO), and perhaps you might include calling conventions in that.

There's also the huge advantages you can get in programmer productivity. Metaprogramming, better type systems, better (and more) abstractions, automatic memory management, automatic parallelization, there's really tons of room for improvement in so many areas. And a lot of these provide lots of room for optimization, in the sense that they put more of the program semantics into the compiler's hands. Compilers will probably be "stupid" for a long time, but at the very least they are very accurate and very fast, so they can try out many possibilities and measure what works best. Chess is a good analog here--computers are far superior to humans these days, and they got there by just trying tons of permutations of simple algorithms and running lots of tests. Writing compilers turns out to be a similar problem, so moving away from C/C++ can have advantages at multiple levels (so meta!).

It's still in a very nascent stage, but the language I've been working on should eventually be the manifestation of lots of these ideas: https://github.com/zwegner/mutagen Most of the ideas are just in my head at this point, and still rather fuzzy, but there's some specifics in the README about possible future directions.

I'm not going to say it's trivial, but I will definitely claim that beating C is very doable, and will happen in less than ten years, if I have any say in the matter. Obviously this claim should be taken with a grain of salt, but in ten years we'll see who was right :)

That looks pretty sweet, thanks for the link.

This is where I feel functional languages will have a huge advantage in coming years. As side effects are reified and put in the compiler's control, they can be modified and optimized automatically.

While TFA is interesting, and a pretty good overview of designing programs with the cache in mind, it just shows me how far we have to go in language design. I don't want to manually make all of these modifications, let alone carefully profile each permutation of all the possible choices. We have fast, dumb computers, let them do that work.

Don't forget those rootkits...

(For the curious: https://en.wikipedia.org/wiki/Sony_BMG_copy_protection_rootk...)

The reason you're wrong is that I wasn't talking about C :)

Yes, for any current programming language, humans do have some advantage by being able to utilize both low- and high-level semantic information that simply cannot be communicated to the compiler. The trump card, I believe, is coming up with new languages where this is not the case.

Absolutely--I see this as a failure of current programming languages and compiler technology, though, and not a fundamental barrier. We should aim to take away all the impediments to the compiler's job, like the aliasing problem you point out. Then, we can just sit back and let the blinding speed and precision of computers take over, trying all the different possible compilations of a given program.

This is the main goal of the Mutagen language. See the link above for a bunch of hand-waving about compiler technology that might exist some day :)

> I'm pretty sure that generating perfectly efficient SSE from SSE intrinsics is an NP-complete problem. So a clever programmer will always be able to boost performance more than a compiler.

Being NP-complete doesn't really have anything to do with whether humans can solve a given problem better than computers or not. It just means that it (probably) takes exponential time to solve.

I believe there is no distinction whatsoever, in principle, between computers and humans (our brains are just big, complicated calculators). As such, it's only a matter of time before computers beat humans in compilation at every point, just like the situation in chess. People claimed for years that humans will always have some edge in chess, because they "understand" the game, or have "ingenuity", or something like that. Nobody claims that anymore, since computers absolutely massacre humans. And similarly to chess, computers have been getting better and better at a very fast rate, while humans have stagnated more-or-less.

As an aside, computer chess got quite boring for me, due to the homogeneity of current programs, but it did help to show me the limitations in current programming languages and compilers. So I'd like to do my part to put humans in their place in another field. My still very-much-not-even-close-to-finished contribution, that I haven't found much time to work on in a while, the Mutagen programming language: https://github.com/zwegner/mutagen

Well, I definitely prefer the rebasing route, but with the caveat that everyone's working on the same branch, so there's not much divergence. The only rebasing occurs when somebody commits before you do, and it's only your own local commits that need conflict resolution.

Ha, nice, there's two options that definitely would've simplified my code (--numstat and --no-merges).

Unfortunately I forgot to grab it off my work laptop when I got laid off. I would've liked to have stuck it up on github...

It wasn't really all that tricky though, it took me a few hours to write. git-log has options for only displaying the status line of diff-stat for each commit, and then displaying the parents of each commit, and the author. You look to see that there's only one parent (so it's not a merge), parse out the X added, Y deleted numbers, and stick them in a dictionary keyed by name.

A lot of the script was just getting statistics like average/min/max/stddev line counts, and printing them nicely.

At my last job I wrote a script to walk over git-log and add up all the line number differences (skipping merges). By the time I left, my net code contribution was something like -290kloc. I was the only person with a net negative, though it was a smallish team.

With the sheer amount of bad code people write, I expect to do a lot of deleting, refactoring, and rewriting, and I'd hope managers/fellow team members would be able to see the value in that. But sadly, they usually don't.

And where are the unit tests?!?!

The highest tile you can get is 2^17, 131072. Each doubling of the tile size requires another extra space, as you have to construct two of the previous tile, and once you construct one, it has to go somewhere. In the end, the final board will have a string of every power of two from 2^16 to 4, and then another 4 in the last empty space. The 4s then combine, then the 8s, and so on, rippling up like binary addition until you get 2^17. Hope that makes sense, I thought about this for a while but it's not the easiest concept to put to words.

It's good to be reminded of one's ignorance in C++ every once in a while. I'm really amazed that there are compilers for it that actually work.

As a side note, thanks for making a quiz site that works quite nicely without any javascript!

EDIT: this got deleted or flagged off the front page, what's the deal? Even though I'm not a fan of C++, it was still pretty interesting.

As far as a decentralized content-addressable network goes, the swift protocol[0] seems pretty close to what you're talking about. I heard about it here a while back, and was quite interested in it, but it doesn't look like it's moved much lately (the page has a copyright date of 2010).

[0] http://libswift.org/

Ugh, we have enough awful, unmaintainable code to deal with as it is. We really need less code now, not more.

I'd prefer it if he would call on Americans to learn to think first, or at least to meditate or something.