Ask HN: How does a non-tech person interview a developer? - <AUTHOR>

I was curious as to what you guys think are some good ways to gauge a developer's web programming capabilities from the point of view of a non-technical founder. <comment><USER2> You really want them to be able to show you some reference sites and get them to talk you through how those sites operate at a high level. If what they saying doesn't make sense then they either don't know what they are talking about or do but aren't good communicators. If what they are saying does make sense then they are more likely to be a good developer.

If I was you I'd also further filter the potential good developers by asking for some sample code either from an open source project or some other means and get a trusted developer you know to give you an opinion on it.

<comment><USER3> "... get a trusted developer you know to give you an opinion on it"

That's the only way I can see it working. I also suggest in looking around for a test you can hand them, i.e. the FizzBuzz test. If their answer looks the same as your answer they're competent.

</comment></comment><comment><USER4> Check out Behavioral Based Interviewing [1]

The idea is you identify the core competencies required to excel in the role. For a developer these might include problem solving, verbal communication, written communication, team work/altruism, attention to detail.

Before the interview, research some questions for each of the competencies. The questions are always about past behavior, as opposed to hypothetical, "what would you do if".

During the interview, just ask the candidate to tell you about a project that they have worked on recently that they would like to tell you about.

Generally, most of these questions will be answered without you having to explicitly ask these questions, but if not - make sure you cover them all off. It is really important to find someone that meets ALL of the core competencies you identified.

Google will help you find example questions.

I've hired dozens of developers over the years, and knowing this technique helps much more than being a developer myself.

[1] <http://en.wikipedia.org/wiki/Job_interview#Behavioral>

<comment><AUTHOR> In my personal experience behavioral interviews are very hit or miss. Take I-banking interviews. A ton of potential bankers are amazing at responding to behavioral questions, but when asked to do relatively simple things like discounted cash flow, they fail pretty miserably.

Which makes me wonder whether it's OK if they don't know something they can easily learn or if their responses to the behavioral questions are premeditated.

That isn't to say I don't use behavioral questions; I'm just worried that because behavioral questions are the standard in interviews these days, many people come prepared with the fluffy answers you want to hear.

Which brings me to my next question:

What are some cool, novel behavioral questions?

</comment></comment><comment><USER5> I think it's a trial-and-error thing.

Work with some. Some won't be able to get things done. Others will.

And every now and then you'll find somebody that works out really good.

Do everything you can to keep those people.</comment>


Endeavour: YC like startup incubator of Ireland. - <AUTHOR> http://www.endeavour.biz/ <comment><AUTHOR> Also, they have awesome mentors; e.g. Founders of YC funded company Auctomatic: Patrick and John.</comment>


Hgraph – Your health in one picture - <AUTHOR> http://hgraph.org/

<comment><USER2> I'm speechless. I'm going to read the publications in the about page to see what went into this because, at first glance, it appears to be very poor information design:

\- The use of a circular arrangement is questionable. Judging the distance of items from the center along radial axes is not something humans are good at. And drawing lines between the points adds uninformative visual noise. Better to just have a little bar chart with consistent axes.

\- All the 'data' is presented without scales, numeric values, or trends over time. The one overall numeric value is presented without any context. We need a scale, a min and max, and a population average for this to be remotely meaningful. My first assumption is that this is like school grades in the US, where 85 is perhaps normal and 60 is abysmal. Is that right? Will that make sense to those from countries without grade inflation?

\- The directionality is all messed up. Sleep is bad when it's low, that makes sense. Nutrition is bad when it's too high? But 'nutrition' is good, right? It's not clear what 'conditions' and 'environment' are, or how they could be too low.

\- I would guess that the relative importance of these pieces of information differs by individual, gender, race, etc. Someone with diagnosed cancer should be marked as such rather than just being high on 'conditions.' And individuals with specific diagnosed ailments or family histories should have specific measures listed more prominently as important predictors.

\- Some information that isn't good or bad but just descriptive belongs on here, like age, occupation, and, for women, period/pregnancy/menopause status.

<comment><USER3> Maybe this takes a second glance to understand, I agree.

There are a few dozen ways to present and graph data, that humans can quickly lock onto. The circular arrangement may or may not be the penultimate method to visualize health data, but it does afford a few good byproducts like seeing outliers quickly, identifying potential patterns (if you're looking across people), etc.

The high-level hGraph with ~18 metrics (we're pretty sure this isn't The Set) is the galactic view, just to give you an instant sense of your health. Once you dive into the data, the level of fidelity increases. Think of the Eames 10x10 flick of seeing the universe and then zooming in to get to the atomic levels that reveal trends, history, etc.

Directionality is how you construct the model (and then interpret it). You can eat too much. You can live in a hazardous environment (with too little X and too much Y). You're right that demographics will have a severe impact on metrics. That bias should be represented in the viz/algorithm.

hGraph needs some TLC from clinicians, policy-makers, and we the patients in order to get it to the next level.

Check out the screenshots of the health detail displays. If you have questions, fire away.

-Juhan, email@example.com, hGraph co-author

<comment><USER2> First let me back up and say, if you have read the research available on the items below and come to the current design after very careful thought, then I am just a jerk giving immediate negative feedback on your hard work and I hope you will forgive me. But if, as I suspect, you have given a lot of thought to the medical, statistical, and visual side of this, but are not well-read in the research on information display, I hope my suggestions will be helpful.

\- I would recommend being very careful with the wording. One can have too much "food" but "nutrition" has positive connotations and no lay person would speak of "too much nutrition" or "too much environment".

\- Please read the experimental material on information display. People study these things and polar display is very poor for picking outliers and recognizing patterns relative to almost any other option, including just printing numbers next to labels with no graph.

\- For building "interactive" data displays, please read Bret Victor's "Magic Ink", specifically the section on the evil of requiring interaction to display information. [1] One of the problems of the circular layout is that 18 is about as many items as can fit, thus you need interactions to see more data. With most other displays of this data, you could easily fit far more information into one, interaction-free display, which could even be printed out for use in a wider variety of contexts.

\- You could also use the clearer display to show actual numerical labels or trends over time. (Surely someone with high but declining blood pressure should appear different than someone with high and increasing blood pressure.)

\- Finally, I am very curious about the decision to include the same set of metrics for everyone and to display them as a single graph. Some of these metrics belong together on one scale, some belong on separate scales, some belong only on people with specific conditions, etc.

\- Are you planning to do a controlled test of this against other high-level patient summaries? Obviously my guess is that this graph and its interactions would fare worse than a one-sentence textual description provided by a past doctor. "Patient is a well-dressed and intelligent elderly man, with a successful history of controlling his diabetes through diet and exercise, but still showing signs of hypertension" seems to me much better than a graph with conditions: red that requires zooming in to see the word "diabetes" and LDL right on the edge that requires zooming in to see a declining trend over time.

[1] [http://worrydream.com/MagicInk/#interactivity_considered_har...](http://worrydream.com/MagicInk/#interactivity_considered_harmful)

<comment><USER3> Thanks. I'm familiar with the material. We have run several micro-studies with real clinicians and real patients with excellent results. Could it be better? Hell yes. Give it a whirl asolove, give it a whirl.

<comment><USER2> Well then awesome. Thanks for making things better!

(And yes, I did try it. Didn't turn out great for me, but I have a variety of fun medical problems I wouldn't expect to see covered here.)

</comment></comment></comment></comment></comment><comment><USER4> That graph isn't one picture. It's a lot of pictures that they fit together. When you zoom in you get different pictures.

I see these circle/star plots sometimes but don't see the advantage over bar charts in conveying information or meaning. Am I missing something that a circle of dots adds that a line of bars or dots doesn't?

</comment><comment><USER5> [http://hgraph.org/images/hgraph_manualinput_v02.jpg](http://hgraph.org/images/hgraph_manualinput_v02.jpg)

This looks awful. Why would want to do a polar plot for a time series?

Just so you can rotate it with your finger to go back in Time?

<comment><USER6> This doesn't look _awful_ and by a very large margin. Unconventional - maybe, awful - heck, no. This is as easy to interpret as linear version.

<comment><USER5> I find it a lot harder to interpret.

You can't really make out the rate of change if it's not linear.

</comment></comment></comment><comment><USER7> I find it disturbing that everyone in the demo has a shortage on sleep. Which is the same for most (if not all) of my colleagues. They all sleep (much) too little for it to be healthy.

Sleep and excercise are easily forgotten or given up when 'free time' gets harder to achieve, while both have so many benefits (or rather, none of the disadvantages that too little of both have).

<comment><USER8> >> I find it disturbing that everyone in the demo has a shortage on sleep

Looks like it's a family with a baby in the household?

</comment></comment><comment><USER9> Neat interface design, but probably its more useful to have this information in a spreadsheet. The visuals actually obscure the data, IMO.

<comment><USER10> True, but I wouldn't doubt most facilities already have this information in a spreadsheet.

I believe hGraph is just taking a stab at presenting this data in a different way, one that could be more useful to patients that shudder at the thought of having to look at a spreadsheet.

If good explanations are shown along with the factors and questionable factors – such as weight – have enough context, this could be more than just a neat way to show the health of someone.

</comment></comment><comment><USER6> What the hell is wrong with everyone? This is (a) interesting (b) unusual (c) clearly has a lot of thought and effort put into it. And all you can muster is "It's so shitty, I'm speechless"? Not a sliver appreciation and empathy. The hell, guys?

<comment><USER11> Yeah, why can't people just use diplomatic platitudes instead of giving their real opinion. /s

</comment></comment><comment><USER12> I'm a little confused by the standard values they've chosen for exercise and weight. It looks like even the guy with three hours a week spent exercising got knocked into the red, and the lady weighing in at 112 lost points as well. Both of these can be perfectly acceptable/good values, depending on the nature and intensity of the exercise and the body type/build for the weight.

How is this thing making a determination on healthy weight without taking into account other factors like height, age, build, etc?

<comment><USER13> Right now we are only doing a split on adult female/male but we realize that is not perfect. The next incarnation needs to include what you list because "healthy" varies.

Thanks for your feedback!

</comment></comment><comment><USER14> "Sir, you're a bit low on drugs and alcohol" :)

</comment><comment><USER15> who created the scoring metric and what is the basis for that?

when i go to [0] and change the default 3 drinks a week to 0 drinks a week my score drops from 100 to 90, that is a full 10%. Why? Acetaldehyde and acetic acid, both metabolites of ethanol are rather potent toxins. I would expect a better rating from keeping toxins out of my body, not a worse one. Then i changed the number of cigarettes from 0.5 a day to 0 a day. Nothing changed. Not smoking surely is much better from a health perspective than smoking 3-4 cigarettes each week.

I simply don't get it.

[0] [http://www.hscoremixer.org/](http://www.hscoremixer.org/)

<comment><USER16> There are some large studies that suggest, counter-intuitive as it may seem, that not drinking alcohol at all seems to have negative side effects on health. It _could_ be down to badly chosen sample populations or ineffective weighting for existing conditions, socioeconomic groups or race, but there is some support for a theory that some units of some forms of alcohol might have positive effects on some groups of humans. And the 0.5 cigarettes a day seems to be a threshold, albeit perhaps too high.

I'm more alarmed by the way the score drops if you weigh less than 258 lbs... especially with a 32.5 inch waistline.

Edit: there are some neat sliders on that page you can move the "optimum" values and green ranges for acceptable scores on the graphs on the left hand side to develop a saner scoring system.

</comment></comment><comment><USER17> In the demo, is all the bounciness necessary? Does it have to zoom when I click on any of the dots? Why not just show me the data when I mouse over? The zoom does not give me anything new. May be you have good reasons, just my 2 cents.

</comment><comment><USER18> Neat design indeed. I believe there's a room for design in health reporting for patients so they can understand the situation better. Did you submit this design to Dribbble? I think designers can learn from your work.

</comment><comment><USER19> I tried the online link version. Apparently it's not good that I don't drink any alcohol and I'm not in any pain. Those are considered to be outside the range of "healthy".

</comment><comment><USER20> For some reason it is saying that my ideal weight is 265, which is about 100 pounds to many. Also, it says I should be exercising 27 hrs/wk. 4 hours of exercise per day seems unreasonable.

<comment><USER13> Right.

You can manipulate what is "healthy" (min/max) in the chart by editing the end points of the green zone on the left hand side.

On the right hand side you can input your values for each metric to see it plotted on the hGraph circle + get a score.

Feel free to submit what you think is healthy in the bottom right.

Thanks for the feedback!

Eric

</comment></comment><comment><USER21> "Steal" is probably not a word you want associated with a health information product, no?

<comment><USER22> Yeah you should use the word "reuse" or "share". Steal is counter to the idea of open source.

</comment></comment><comment><USER23> When I click on participate, nothing happens...

<comment><USER24> For me, it popped open an email to them in outlook. Not exactly what I was expecting or what I wanted.. I couldn't figure out how to make my own graph...

<comment><USER13> Howdy,

If you'd like to play with hGraph check out a tool we made during development.

[http://hscoremixer.org/](http://hscoremixer.org/)

We created this tool for physicians to give us feedback on the engine that drives hGraph. You can define what is considered "healthy" and rank each metric's importance in your overall health.

Put in your numbers and see how healthy you are.

Eric

<comment><USER25> What's the logic behind the alcohol part in this? Mine goes red when I change it from 4 drinks a week to 1... surely the latter is healthier? :)

Great design by the way!

<comment><USER13> Yes, some of these are a bit unreasonable in the tool. ... but we really want you to drink! ;)

</comment></comment></comment></comment></comment><comment><USER26> Very interesting!

</comment><comment><USER27> Looks amazing!</comment>


Conditional Move for Shell Script Acceleration [pdf] - <AUTHOR> http://tom7.org/papers/sigbovik75csh.pdf <comment><USER2> tom7 on HN!

If you enjoyed this I can also recommend checking out his YouTube channel: [https://www.youtube.com/user/suckerpinch](https://www.youtube.com/user/suckerpinch)

He makes a lot of these CS joke-things (and also a lot of genuinely interesting stuff!)

</comment><comment><USER3> It seems that this whole thing is some inside joke that we do not have the context for.

<comment><USER4> it's SIGBOVIK season.

[http://www.sigbovik.org/](http://www.sigbovik.org/)

</comment></comment><comment><USER5> I enjoy reading proceedings from SIGBOVIK :)

[http://sigbovik.org/2020/proceedings.pdf](http://sigbovik.org/2020/proceedings.pdf)

</comment><comment><USER6> this is actually really interesting.

The paper came from 1975, when programmers generally knew assembly language and unix was starting to flourish.

The apple II for instance didn't have an ADD instruction. I believe you had to do Clear Carry then add with carry.

You can kind of see how the two universes of thinking collide in this paper.

related, you can do things like this:

      [ "$A" = "$B" ] || exit 1
      [ "$A" = "$B" ] && echo "a equals b"

<comment><USER3> > _The paper came from 1975_

Did it? Then how come it has references to "diff --git", "[https://git.kernel.org](https://git.kernel.org) ", and "[https://github.com/"](https://github.com/")?

<comment><USER7> Also, don't miss the reference to the "Shpectre vulnerability" :)

</comment></comment></comment><comment><USER8> Nicely done! I'm thinking I'll have some onion rings for dinner.</comment>


Classes are Expressions - <AUTHOR> http://raganwald.com/2015/06/04/classes-are-expressions.html

<comment><USER2> Just looks like more JavaScript antipatterns, this time with some ES6 flavour.

We know how to "solve" the problem of encapsulation with JavaScript. It's not with closures, Symbols, or some other arbitrary hack. We do it by enforcing specific idioms that only require a developer to recognize _intent_ instead of learning 80 different ways to do the same thing. You simply _put a single or double underscore_ in front of the property name.

I read what I thought was a clever anecdote by another developer the other day, that the underscore in "obj._varname" indicates "here be dragons." It's an extremely simple idiom to teach new JavaScript developers.

I get it, JavaScript is robust. So you can do fun things like this! These are great experiments. But really, what are you accomplishing? You've now just thrown in a closure and a bunch of lines of code (defining your symbols, etc.) that any developer new to your codebase is going to look at like "... what the... what is going on here?" You can solve the problem easily with _one character_.

Consistency. Convention. Creating useful, easy-to-understand, repeatable idioms. That's what we should be focusing on.

<comment><USER3> You can't check that the convention is being broken which makes refactoring more difficult. There will always be a temptation for some developers in some situations to mess with the internal state of objects.

<comment><USER4> In general, js is more about good practices and craftsmanship, and less about finding ways for the language to force people to do things.

<comment><USER3> I find this argument to be lacking; if you're using good practices and craftsmanship then nothing is being forced on you as you would not encounter an error for doing something improper.

I prefer to mark up my code as private/protected/public for my own purposes both as built-in documentation and to have one less thing to think about after it's done. Plus underscores are ugly.

<comment><USER4> Yes, but you have to do a lot more typing, plus you have to do a lot of things to satisfy a stricter language. There are a lot of abstractions like interfaces, delegates, etc, that exist to get certain logical patterns past the language's strictness. In loose languages you can just write the patterns you want without the overhead.

<comment><USER3> In other words, with less strict languages you can be sloppier. Once projects get to a certain size, language strictness is a huge benefit.

And, in some extent, it's actually freeing. I can reach in and change something big in a strict/compiled language and the compiler/IDE will tell me where I have to make other changes throughout the whole project. In a dynamic language, I either have to rely on unit testing, grep, or just having it break at runtime. But the real truth is, you just don't make those kind of changes when your language isn't strict. The pain isn't worth the payoff.

</comment></comment></comment></comment></comment></comment><comment><USER5> I guess I need to be schooled by why not just use closures?

        var Person = function(first last) {
          this.fullName = function() {
            return first + " " + last;
          };
          this.rename = function(newFirst, newLast) {
            first = newFirst;
            last = newLast;
          };
        };

Problem solved, you can't access `first` and `last` outside the class. You might retort "they're bigger" or something but just like everything else in JS they just need the right people to concentrate on them and they'll likely get optimized.

I don't get the relucatance to use the language's features rather than hacks (using naming standards and compilers to obfusticate names and then cross fingers) or other hacks (Symbol). Really? You Really want me to write code using Symbol? That's going to be awesome in the debugger. Let's add a watch to "weke30o304_first". Refresh, of shit it's now "gtgrf40r3fe_first", my watches all broke (T_T)

It also makes me sad the `class` spec didn't take that into account so you could use a closure with a `class`.

<comment><USER6> Closures give you _object_ privacy. Symbols give you _class_ (or whatever other scope you want) privacy. Take a look at this symbol example:

        let Person = (() = > {
          let firstNameProperty = Symbol('firstName'),
              lastNameProperty  = Symbol('lastName');

          return class Person {
            constructor (first, last) {
              this[firstNameProperty] = first;
              this[lastNameProperty] = last;
            }

            sameFirstName (otherPerson) {
              return this[firstNameProperty] == otherPerson[firstNameProperty];
            }
          };
        )();

Now try implementing sameFirstName() using closures. Good luck! :)

<comment><USER7> Er, to be clear, your example uses a closure. Your real question is, can this be done without `Symbol`?

And it can, since the symbol is just a secret stored in a closure and there are other sorts of secrets. Aside from the "Math.random() + {enumerable: false}" suggestion found elsewhere, you can reproduce the precise[0] semantics of your example using something like:

        // Please do not actually write code like this
        var Person = (function() {
          var names = [];
          function Person(name) {
            this.key = names.length;
            names[this.key] = name;
          }
          Person.prototype.sameName = function(other) {
            return names[other.key] === names[this.key];
          };
          return Person;
        })();

Which is the ES3 generated by this CoffeeScript:

        class Person
          names = []
          constructor: (name)->
            @key = names.length
            names[@key] = name
          sameName: (other)->
            names[other.key] is names[@key]

Of course these implementations do something dramatically different behind the scenes, and I emphatically don't think people should follow this example, but the interface is the same. Edit: Except that I left `.key` as an editable property, which is problematic. We'll leave that bit as an exercise, though.

Whether `names[this.key]` is as "nice" to work with as `this[nameKey]` is, uh, left up to the reader; personally, count me in the camp that doing either of those things is nuttypants compared to `this._name`.

[0]: Assuming that `otherPerson` in your constructor is a typo, of course ;P

<comment><USER6> > [0]: Assuming that `otherPerson` in your constructor is a typo, of course ;P

Oops, yup. Fixed.

Your solution is pretty clever, though it leaks memory like a sieve. To get around that, you end up needing something like weak maps.

Once you have those, when you do the pattern you suggest, you are basically doing metaprogramming and reinventing the very idea of an "object" yourself from scratch.

That can be fun to do, but to me it starts to feel less like expressing "the same thing" and more like implementing a new language that lets you express the same thing. Just because I can implement a GC in C, that doesn't mean C has a GC. :)

<comment><USER7> In ES3 you'd need destructors, I think. But yes, agreed on all points :)

And yet-- is the Symbol approach not metaprogramming? It's clearly a much saner way to shoehorn this feature in, but it's still a shoehorn. And the underlying magic in both cases is in fact simple closure scope, which is really what I wanted to demonstrate.

Edit: And I guess my broader point, to make this more constructive, is that in JS these kinds of idioms live on a continuum of metaprogramming, and for the sanity of your co-contributors you usually want to be doing as little of that as necessary. Like others, I'm wary of presenting something like your example as a "design pattern" without that context.

Edit 2: To illustrate what I mean, I _swear to you_ that if this pattern is adopted widely you will find code like this in the wild:

        ... = > {
        let accountNumberKey = Symbol('accountNumber');
        return class Account {
          constructor (accountNumber) {
              this[accountNumberKey] = accountNumber;
              this.accountNumberKey = accountNumberKey; // ??? but transaction log works now

        ...

</comment></comment></comment></comment></comment><comment><USER8> I know this might be an unpopular view here, but declarative(ish) constructs like class give a little hope that programs will be more statically analyzable so that we can get nice things like static type checking and warnings, code completion, optimizing compilers, etc.

These types of imperative patterns make life extremely hard on tools, which now need to add in unreliable things like escape analysis to be able determine which classes are visible. Modules will help a little with explicit exports, so that the importing modules have some hope of tooling, but analysis within a module would suffer.

</comment><comment><USER9> What about private functions? For now I just add `_` in front of their names, but the code would look so much cleaner if I had some kind of a `private` keyword.

<comment><USER10> I don't see why this technique wouldn't also work for methods, especially with the addition of computed property names [1].

[1] [https://developer.mozilla.org/en- US/docs/Web/JavaScript/Refe...](https://developer.mozilla.org/en- US/docs/Web/JavaScript/Reference/Operators/Object_initializer#Computed_property_names)

<comment><USER11> This technique absolutely works for methods. And again, this shows the elegance of having simple features that compose, rather than building a monolithic OO system.

<comment><USER12> In practice, that turns into far too many ways of defining classes in Javascript. There are at least four major approaches, and that was last year.

<comment><USER11> If you want something that isn't in the language, you build it yourself. If what you build becomes popular, in the fullness of time it gets built into the language as a full feature or as syntactic sugar. That's exactly how we got the class keyword, modules, everything.

But if you choose the wrong thing, one day your choice is obsolete. That is a risk, and it's prudent consider the consequences carefully.

If that troubles you, by all means write your code without any encapsulation, and wait for the language to acquire the feature in a few years. In the mean time, your code base will grow without that kind of encapsulation. Only you can determine whether this is a bad thing or not. YMMV, and all that.

This is a very common problem to ponder, we end up arguing about whether you should be an early adopter, a main streeter, or a laggard.

But really, the post isn't a screed in favour of using private properties, it's a suggestion that making classes out of first-class values in the language gives us the flexibility to build whatever we think we need.

Private properties is a particularly simple example. Traits and mixins are also useful, but would take even more space to articulate. But the general point is still that making new things ("classes") out of the existing materials ("functions and prototypes") is a win in general.

</comment></comment></comment></comment></comment><comment><USER13> This is cool, could this behavior be mimicked by doing:

        var name = 'name_' + Math.random() ; //assumed uniqueness

<comment><USER11> Yes, but you'll also want to use Object.defineProperty to ensure that the property is not enumerable.

[https://developer.mozilla.org/en- US/docs/Web/JavaScript/Refe...](https://developer.mozilla.org/en- US/docs/Web/JavaScript/Reference/Global_Objects/Object/defineProperty)

Symbol tosses that in "for free."</comment></comment>


Why developers don't make millions of dollars - <AUTHOR> http://www.ruurdkeizer.com/why-developers-dont-make-millions-of-dollars/

<comment><USER2> Encouraging everybody to learn to program is like teaching music or sport in school. Everybody gets to do a bit, but it doesn't mean that they'll be good enough to do it at a professional level. Few will become top billed rock stars or pro athletes.</comment>


Internet Explorer falls below 50% market share - <AUTHOR> http://gs.statcounter.com/press/microsoft-internet-explorer-browser-falls-below-50-perc-of-worldwide-market-for-first-time <comment><USER2> Unfortunately, I have to deal with a much different picture in my case. The web application is often used by either complete computer illiterates or users in large corporate installations (or both).

My IE numbers (looking at the three biggest installations):

IE percentage: 80, 90, 98 - IE6 percentage: 30, 50, 40

No Chrome. No Safari. Rest is Firefox (2.0, 3.0, 3.5 and 3.6).

I weep when I consider the amount of development time we waste catering for these IE users refusing to (or unable to) update.

<comment><USER3> I nearly fell off my chair when one of our new enterprise customers asked me if we could provide them the app... but with Firefox support because that was all they used.

Heaven :)

<comment><USER4> I worked for this large company, who had just bought another smaller company. Wisely, the smaller companies IT department had moved everyone onto Firefox, but since they had to have access to our new system, which was IE, we had to tell them to move back to painsville.

It broke our hearts, the IT people, and the users. The new system will work on all browsers (except IE6), whenever that will be out.

<comment><USER5> Out of curiosity, did you look into using something like IETab? You can configure it to render specific sites in IE's Trident engine, and all other sites using the usual Gecko engine.

However, I'm not certain how easy it is to push a Firefox extension + configuration to a large number of Windows machines.

</comment></comment></comment></comment><comment><USER6> Woobius traffic specs (quite representative of the enterprise space, so more realistic if you're doing an SaaS that also targets enterprise users/customers), are not too far off, but not 50% yet.

IE: 56% Chrome: 20% Firefox: 16% Safari: 5%

IE versions are broken up as: IE6: 10% (= 5.6% absolute) IE7: 25% (= 14% absolute) IE8: 65% (= 36% absolute)

In other words, dropping IE6 support is not yet plausible. But we've already opted to provide only functional support for IE6 - i.e., things need to work in IE6, and not look totally broken, but they don't have to look great.

<comment><USER7>
        In other words, dropping IE6 support is not yet plausible.

Why? 5.6% does really justify the costs of supporting IE6?

<comment><USER8> It all depends on how much work goes into supporting IE6. If the amount of time is substantial, personally I would consider dropping it. But even until the bitter end, that decision depends on your target audience and how much you want that group to be forced to make a choice: upgrade or leave your site.

That's for functionality. I think we're long past the stage where you should care whether or not IE6 gets the same exact _visual_ experience.

</comment></comment></comment><comment><USER9> At deviantART we're dropping IE6 support shortly... it wound up representing a tiny percentage of our traffic, and we like the idea of being able to use the crazy innovations of IE7.

It's slightly painful, because we've been forcing IE into quirks mode for ages (with a comment before the doctype) so that all IEs behave like IE6, and thus we only had to test one IE.

</comment><comment><USER10> For <http://www.zootoo.com>, which is representative of a non-computer savvy audience, our IE traffic is now below 50%.

IE : 45% (IE8 - 65% IE7 - 23% IE6 - 12%)

Firefox : 35% (3.6.x - 85% 3.5.x - 10.5% 3.0.x - 5%)

Chrome: 9%

Safari: 7.5%

Opera: 1.6%

We were also able to reduce the IE 6 traffic on our site by 50% by implementing a friendly 'please switch to a newer browser' campaign.

</comment><comment><USER11> I noticed IE drop below 50% last spring on <http://flashcarddb.com>

It dropped from 50.17% in March to 49.05% in April, continuing to steadily decrease since then.

My traffic is about 70% North American. I have many students. Macintosh is a 20% slice of my OS pie and Safari isn't too far behind Firefox in browser share.

September => IE: 48%, Firefox: 24%, Safari: 16%, Chrome: 10%

<comment><USER11> Interesting stat tidbit:

Browser stats for Mac users only:

Safari: 75%, Firefox: 20.2%, Chrome: 4.5%

<comment><USER12> That makes sense seeing as Safari is the default browser on ever brand new Mac and Google Chrome has only been available on the Mac for a year.

<comment><USER13> On top of that, Mac users have less need to even think about what browser they use because IE isn't the default, which weights things disproportionately in Safari's favor. Safari is "good enough."

</comment></comment></comment></comment><comment><USER14> The biggest problem with IE6 that I see with my company, is that a lot of corporate clients still have IE6 on their machines because of their lazy IT departments. So they don't care if only 0.0000000000001% of the traffic is from IE6 because it happens to be them.

<comment><USER15> Yep! Started a new job on Monday with a fresh install of IE 6. I couldn't believe it, I'm now working at one of the companies where ie6 is forced upon all staff, even the web dev team. I complained that the majority of users are using a newer browser, and I was told that IE7 is currently being beta tested. I'm not holding my breath.

<comment><USER16> Seriously? I wouldn't have taken the job in the first place. Nightmare.

</comment></comment></comment><comment><USER17> Another obvious but often overlooked factor that contributed to the decline of IE is the increased number people converting to Mac (anybody have a figure for this?). Because MS discontinued supporting IE on Mac years ago, there's not way to recover users lost to Safari and other browsers on the Mac front.

</comment><comment><USER18> I just checked Learnhub's numbers (<http://learnhub.com>) and IE is now at 40%, it was 54% a year ago. Most of the traffic comes from India.

Chrome went from 7.5% to 20% in the same time frame.

</comment><comment><USER19> In my small subset of the enterprise market, amongst my clients (large financial services firms) IE usage is 100%. Unfortunately I don't see this changing any time soon.

<comment><USER20> It is not completely impossible but there are 3 big reasons they stay with IE that I heard of.

Transparent Identification/Authentication, its is possible to support the protocols with Firefox but it is not as transparent.

ActiveX like stuff... sadly several enterprise applications use that.

Justifying the tests and rework of switching to a different browser.

</comment></comment><comment><USER21> Does anyone know what the browser market share of HN is?

<comment><USER11> My recent traffic from HN (a few hundred hits):

Chrome: 55% Firefox: 30% Safari: 9% IE: 4% Other: 2%

</comment></comment><comment><USER22> Anyone have good stats for the browser-vs-non-browser (i.e. dedicated FB/twitter client, Instapaper, etc.) use of HTTP to consume HTML. I bet you'd find that c. 2002 IE had 90% of the browser and browsers had 99.9% of HTTP+HTML, but that now browsers have more like 90% of HTTP+HTML. Then there's the desktop browser vs mobile browser issue, and RSS ...

</comment><comment><USER23> <http://www.w3schools.com/browsers/browsers_stats.asp> W3Schools sees IE below 50% since September 2008. However, it's not representative.

But as they say on their page: _"Anyway, our data [...] clearly shows the long and medium-term trends."_

<comment><USER24> Also, W3Schools is most visited by web developers, who by nature want to burn IE at the stake.

The most objective measure we could get is if someone from Google released their Browser/OS data.

</comment></comment><comment><USER25> The site I work for has been running at under 40% IE for over a year and a half. We're at about 15% Safari, 40% Firefox, 38% IE, and 7% Chrome. IE6 is under 4%, thanks goodness!

</comment><comment><USER26> I always find announcements like this ridiculous. It's like saying 50% of people wear blue jumpers - because it's so dependent on the sample group.

</comment><comment><USER27> We develop our products for the latest version of popular browsers: IE, Chrome, Firefox, Safari, Opera. If a customer has a problem and is using a older browser, we simply ask them to upgrade.

In order to stay modern and write good code with as few hacks as possible, you have to let older browsers go.

</comment><comment><USER28> It was unexpected to see that StatCounter is headquartered in Ireland.

</comment><comment><USER29> This means nothing to those who develop for the Enterprise world :-(. We still have clients who are on Windows 2000+IE6.

In a way, I can't wait to go back to consumer development.

<comment><USER30> The end of life of Windows 2k in July hopefully will mean this will change soon. Thankfully many companies will upgrade once there is no support whatsoever for their current OS.

</comment></comment><comment><USER31> a blog I run had 125,266 visits from 10/4 - 11/4. The browser usage percentages are as follows: firefox: 41%, chrome: 22%, internet explorer: 19%. Most of our traffic is referred from tech inclined sources. Personally, I have heard a ton of complaints about the amount of memory firefox uses while running compared to chrome...

</comment><comment><USER32> Breakdown for <http://www.jasondavies.com/> over the past month:

Safari: 4%

Internet Explorer: 5% (!)

Mozilla-compatible agent: 6%

Chrome: 20%

Firefox: 65%

</comment><comment><USER33> I'd like to see a well researched, estimated total national/international cost to the industry for support of IE.

<comment><USER34> Shhhhhh, keep that on the low. IE6 is paying my bills right now

</comment></comment><comment><USER35> I'm seeing around 30% IE (all versions) usage on tech centric blogs I run. Chrome's inching up on 20%.

</comment><comment><USER36> I bet a good percentage of that 50% are bots using the IE user-agent.

<comment><USER37> Bots that execute analytics javascript? Sure they're out there, but that's a very, very small percentage.

</comment></comment><comment><USER38> IE in North America it is still at 52.3%, so close.

</comment><comment><USER39> Surely this must be a sign from the gods of Silicon Heaven.

</comment><comment><USER40> Am I the only one who would love to see Partio11s numbers? They are properly biased in the other direction, but still.</comment>


The Top iOS Blogs for Any Developer - <AUTHOR> https://bugfender.com/blog/the-top-ios-blogs-for-any-developer/ <comment><AUTHOR> If you find any blog that's missing, leave your comment here</comment>


Jack Poulson Letter to Senate Commerce Committee - <AUTHOR> https://www.documentcloud.org/documents/4941446-Jack-Poulson-Letter-to-Senate-Commerce-Committee.html <comment><AUTHOR> I missed a similar submission: [https://news.ycombinator.com/item?id=18076048](https://news.ycombinator.com/item?id=18076048)</comment>


What killed Haskell, could kill Rust, too - <AUTHOR> https://gist.github.com/graninas/22ab535d2913311e47a742c70f1d2f2b/c4e1b25cefe673a0c1d1bec4c24690121f31fa21 <comment><USER3> this article was just posted 4 days ago:

[https://news.ycombinator.com/item?id=24401748](https://news.ycombinator.com/item?id=24401748)

see my comment there:

[https://news.ycombinator.com/item?id=24404593](https://news.ycombinator.com/item?id=24404593)

in summary: The reason why Haskell still doesn't really break through in the corporate world is not a failure of arrogance, but a marketing failure in the strictest sense of the word 'marketing'—which means prioritizing the right features to target the right market.

<comment><USER4> It's not targeted towards that. It's a 30 year old research language that is still ahead, and I don't really see a reason why it should change in any way towards businesses. If anything, it should lean more into research to keep ahead. I do not believe catering to anything in the corporate area will result in anything equivalent to the decades of research.

</comment></comment><comment><USER5> > As one might have guessed, this is not an essay. It's a transcript of the > following talk by R. Martin with some substitutions made (SmallTalk -> > Haskell, Ruby -> Rust, and others). You are free to make any conclusions > from this.

I don't find this particularly interesting. Starting from the first questionable statement,

> Not because Rust is Haskell without HKTs

I was wondering why the article had so many inaccuracies.

Fundamentally, Haskell did not clearly solve any particular problem with other languages. There are a lot of cool things you can do in Haskell, and arguably, there are problems in other languages that aren't issues in Haskell. But the advantages of Haskell were never as clear cut as Rust.

In addition, Rust has already seen uptake on a level that Haskell never has. What's the most important Haskell project? Pandoc? Haxl? On the other hand, many companies have already started building core infra in Rust. Facebook with Mononoke, Libra, Eden, and Hack. Dropbox for storage servers. Mozilla with Firefox.

I think Rust has a bright future, and I don't think the analogy with Haskell is right at all.

EDIT: Judging from some of the other comments, I'm perhaps not surprised that GPT-3 achieved some success on HN.

<comment><USER6> > many companies have already started building core infra in Rust. Facebook > with Mononoke, Libra, Eden, and Hack. Dropbox for storage servers. Mozilla > with Firefox.

You missed Amazon, Google, the Linux kernel, Microsoft, Apple, ... which big company isn't using Rust at this point in production?

The main difference between Rust as Haskell is that, while I really like doing competitive programming with Haskell, what I really like doing with Rust is shipping products to customers.

In my free time, I don't use Rust, right now I mostly use Idris2. But the main reason I can do that is that since we moved from C++ to Rust, nobody really call us on the weekend anymore to fix something that can't wait till monday.

<comment><USER7> The Linux kernel isn't using Rust in production. They've said they're open to the possibility, but that isn't even a start.

<comment><USER6> All our linux kernel module and driver development have been using Rust for a while. I've written a Linux kernel module in Rust that we use in production, and so have many others.

What the Linux kernel is discussing is how to integrate these kernel modules and drivers into the Linux tree. They are not discussing whether this is worth doing, but how to do it. Linux is quite stable if you stick to the right APIs, and maintaining these out-of-tree is not too bad, but the current situation is not sustainable in general.

For us it doesn't matter, because our code is not open source. But it matters to quite a bit of people.

<comment><USER7> Sure, but out-of-tree third party modules and drivers is not what the comment I replied to said.

</comment></comment></comment></comment></comment><comment><USER8> > " _It 's a transcript of the following talk by R. Martin with some > substitutions made (SmallTalk -> Haskell, Ruby -> Rust, and others)_"

I kept wondering why I'm wasting my time reading this, until the end, only to find that this is the style of Uncle Bob.

</comment><comment><USER9> I agree with this story, but I would add one more thing (which so far, Rust doesn't suffer from, but is starting to sneak in with const functions).

Haskell suffered from people showing some great idea could be implemented in Haskell, without actually producing working finished code people could see.

For me the classic example is ripgrep. I remember seeing tutorials about how regexes could be nearly and efficently done in Haskell, but it was Rust and ripgrep which made a day-to-day useful tool, which gives me confidence I can also use Rust to do useful things.

Of course, I'm not saying everything has to be useful code, but having some commonly used programs in your language does help it seem practical. Haskell does have some great stuff (pandoc comes to mind), but very little considering its age, and compared to Rust.

</comment><comment><USER10> Ahm, last time I checked Haskell was alive and well. Nothing killed Haskell because Haskell isn't dead at all.

I guess what commercial-driven people don't understand is that something isn't a failure if it simply doesn't play their "market domination" success game and doesn't win by its metrics.

Go look at the photos of the first Haskell working groups; it's an academic tool. It can be used for commercial workloads but it was never developed with that sole purpose in mind.

Haskellers play another game.

<comment><USER11> Read the article. It's a fictionalized dispatch from the 2030s.

</comment></comment><comment><USER12> I feel like this is overstating the popularity of Haskell greatly. I don't think Haskell was ever as popular as the article implies.

//edit: i just now realized that this post was not originally about Haskell but Smalltalk. That makes more sense to me.

</comment><comment><USER13> As a person who occasionally teaches programming languages, including Haskell, I have found the PHP community to be exceptionally supportive when it comes to documentation and examples. It has a very respectful attitude towards comments on the documentation website as well, where good examples contributed by users are eventually absorbed into the official documentation.

One of the least rigorous language in wide deployment has the best attitude towards its users.

If other languages also adopt a friendly and approachable attitude towards helping beginning, intermediate and advanced programmers, then I think that the ecosystems of languages would be much healthier.

</comment><comment><USER14> Realistically the biggest problem with Rust today is the biggest problem it has always had - it is too hard to write useful programs. Rust has seen some success in very targeted use cases, but that isn't enough. I am 100% confident that introducing Rust to my company would be a huge mistake.

<comment> Ar-Curunir I mean, given that Amazon, Google, Facebook, Apple, Dropbox, Mozilla, etc are all using Rust for important parts of their infrastructure, I think "making it easy to write useful programs" is not one of Rust's weaknesses.

Yes, it's not as "easy" to pick up as C or Python, but it also prevents footguns introduced by those languages.

<comment><USER15> No, the companies you listed wrote a PR blog posts or two saying they use Rust for a component or two, for a minor or internal product. Saying they are using it for "important parts of their infrastructure" is quite a stretch...

<comment><USER16> Is Dropbox's sync engine a minor product? The entire reason why Firefox has gotten much faster over the past few years? Linkerd? What about Amazon's Firecracker, powering Lambda and Fargate?

</comment></comment></comment></comment><comment><USER17> Can people tell me what useful program were produced in Haskell ? I know a few for Ocaml but I dont know much Haskell, so dont know yet any useful program written in Haskell. The program I know for Ocaml are: \- coccinelle (semantic patching used by linux kernel devs) \- FramaC (formal verification) \- Coq (proof assistant) \- Rust compiler (I think they bootstraped the language by writting a compiler in ocaml first, now the compiler is written in rust itself)

I just saw pandoc. It seems nice. I know parsec. But I would like to know what kind of haskell programs are actually used in real life ? I know Jane Street does all their dev in Ocaml. Is there similar company for Haskell ?

<comment><USER18> One that I use all the time is shellcheck, and git-annex. Others in the mainly-used-by-programmers-category include xmonad and hledger. [https://github.com/owickstrom](https://github.com/owickstrom) has some GUI Haskell apps.

Facebook's Sigma and [https://github.com/wireapp/wire- server](https://github.com/wireapp/wire-server) may be the ones with the most non-programmer users?

[http://postgrest.org/](http://postgrest.org/) and [https://hasura.io/](https://hasura.io/) seem interesting.

[https://www.quora.com/What-is-the-largest-commercial- program...](https://www.quora.com/What-is-the-largest-commercial-program- written-in-Haskell?share=1) says the largest Haskell code-base is probably Standard Chartered trading system.

more at [https://github.com/topics/haskell](https://github.com/topics/haskell) and [https://serokell.io/blog/top-software-written-in- haskell](https://serokell.io/blog/top-software-written-in-haskell)

</comment></comment><comment><USER19> Uncle bob's original essay is largely worthless, and I'm genuinely struggling to understand what value is to be extracted by transplanting a terrible argument, onto an even less applicable programming language situation.

If anyone reading this has published anything resembling this tripe, please stop programming and start crocheting, or some other, more useful hobby.

</comment><comment><USER20> I can see the use for Rust in writing an operating system or device driver...but manual memory management for application software? That's a huge step backwards. I really don't get why anyone uses Rust outside of low-level or very performance-driven problem domains. Seems like a cargo cult or hype machine, though certainly an improvement over C, it should be replacing C. It might be better than Java, but what replaces Java should look more Haskelly.

I don't get it.

<comment><USER21> You manage memory in Rust about as manually as you manage memory in Python, at least in normal application code.

If you do very low level stuff, you might think about that a bit more but then you have to in any case.

<comment><USER22> > You manage memory in Rust about as manually as you manage memory in Python,

That's not true in my experience. Every single error the borrow checker throws at you is in a sense "memory management". Rust forces me to think very hard about memory, in all but the simplest toy programs.

You want anything to do with threads? Gear up for a long afternoon of fighting the compiler before you fully understand your memory model and use it properly. You want anything to do with linked lists? Same deal. You want anything to do with async. Plan to spend 3 hours just to figure out what you want to really do.

All this is memory management. Just in a different form compared to C/C++. Python OTOH simply lets you forget that the computer exists. It's just you and the problem you're solving. You pay for that with lack of speed and bloated memory usage.

<comment><USER23> I haven't written a huge amount of Rust, but I feel like I understand it well enough to not have much of an issue with this. It seems like what Rust really want you to think about is not so much memory management directly, but ownership.

Linked lists? Rust just really doesn't like them. Better to use something else instead. I can't remember ever wanting to use a linked list in a program I've written though. I think you could argue that it's tough to write a linked list implementation that really never leaks memory without a GC.

Threads? I'd argue that the stuff that Rust prevents are usually real bugs. You might not hit those bugs right away, especially in a language with a GIL, but they're there. Better to know they'll just never happen, no matter how hard you push your threads.

For async, I guess I've had good luck with it so far. I still feel like I don't really understand what's going on with Rust async and runtimes, but most of the code I've written with it just works.

</comment></comment></comment></comment><comment><USER24> What's the weak points (except not-very-easy-to-learn and complication speed) of Rust? It listens perfect in every other aspect from the Rust promotion articles.

<comment><USER25> You have to think about memory management. No matter what rust evangelists say, you have to think about it. Well you don't have to worry about it like in C. Of course rust is intended for safe performance-critical programming. GC is fine for a significant portion of software.

The ruby / javascript webshit culture creeping in - lot of microdependencies which can often be hard to audit. Projects like cargo-crev aren't getting any traction.

Crates.io - the package registry lacks namespacing. That means package names have to be choosen carefully and you might here phrases like "import data from cabbage to rabbit using chickenshit crate" etc..

Async runtime fragmentation because stdlib doesn't provide one.

Very small standard library. Many things need you install a crate which might come with 40 other dependencies. This kind of dependency counts are fine for creating webshit but sometimes you need to audit your dependencies, especially rust is intended for low level programming.

Horrible compile times. You might think rust has better compile times than C++ because it has a module system. But compile times are similar. Rustc emits large chunks of LLVM IR. Not faulting people working on rust for this - <USER2> they have a shortage of talent. And rust community's zealotry makes lot of people sceptical.

A very zealot community which also happens to be very active on programming link aggregators. You might get downvoted irrationally for simply critisizing some flaw of rust. You keep on hearing zero-information / out of context statements heralding rust. This is partly a consequence of influx of people from blogging-heavy ruby and javascript communities. Especially the javascript crowd has an Instagram feel to it. Some people among these have marginal knowledge of computer science concepts and still show up everywhere heralding rust.

No structural typing. This may be flaw or virtue - people from dynamic typed languages may like structural typing as in Go or OCaml than nominal typing.

<comment><USER26> I cannot wrap my head around the uses of structural typing. Unless I tell something to be a certain type I expect it not to be.

<comment><USER25> Well it is subjective. That's why I wrote it may be good or bad. But those from dynamic typing backgrounds may find structural typing more natural. I don't bother as long as there is a way to implement an interface without lot of subclassing boilerplate.

</comment></comment></comment></comment><comment><USER27> Is Rust a "times 5" language? Is it that good?

I can't imagine any language being 5 times as productive as current mainstream projects.

<comment><USER28> Rust is approximately a 0.5 language. It takes longer to write but results in more reliable code.

<comment><USER29> Compared to what?

Java with its verbosity and relative lack of language features, partly hidden by powerful but complex libraries? (Partly shared by more potent C#.)

C++ which is only slightly faster to write safely than Rust, you have to be careful to not use unsafe subset, and generic code is more verbose?

C which has even fewer language features than Java and is harder to make safe than C++?

Javascript where it is easy to write bugs, mostly of the null object kind, and hard to handle exceptional situations? With mediocre debuggers? (Also thus used with complex frameworks and libraries.)

Python or Ruby, where instead performance may require dirty tricks using extra time?

Perl? PHP? (Do these even have well working debuggers?)

(Last 5 require additional code for tests due to dynamic nature to ensure correctness too.)

Lisp, Haskell, SML or OCaml where there are fewer quality resources and libraries available to programmers?

Perhaps the less used JVM/CLR or JS languages? (Groovy, Kotlin, CoffeeScript, F# come to mind.)

<comment><USER22> I find this sort of comparisons dubious. For me, who's a total rust noob, C is 10x faster than rust, because I need to keep looking up rust syntax for basic things like for loop.

If I ever learn rust as well as I know C, I'm sure my speed won't be any faster or slower. For me, the time to think up a solution is the major chunk, writing it out seems to be nothing in comparison. So why would the language affect that in a meaningful way?

Now, the one way rust can really give you time savings is the lack of entire classes of bugs. I spend 90% of my time fixing bugs in the code my coworkers and I have written over the past year. And most of them are really subtle memory and thread safety problems that are difficult to track down. If rust can eliminate that, I am willing to spend a year getting comfortable with the language.

<comment><USER29> I agree, if you're learning a language you will be slower with it. I wrote this from a perspective of having used them for a reasonable time, and I used most of the above fluently, except C#, Ruby, Perl, functional bunch, which I've only used for small side projects. (And I have not mentioned Fortran which we also used a bit, Borland Pascal, Object Pascal AKA Delphi, Visual Basic, C64 Basic, QBasic, x86 and ARM assembly.)

I also know and are fluent in much weirder, atypical languages, almost esolang, of CRM114 and Faust, and rare ones like Nemerle and Vala.

Rust is pretty pedestrian compared to some of these, rather powerful and generally nice. Writing in Rust feels like writing in a cross of C# and C++20 (less verbose) with a sprinkling of SML/OCaml inspired syntax.

Main slowdown I got was having to write some foreign function interfaces, but it was as nice at it as Python with Cython, nicer than say Vala or Haskell. Much nicer than Java FFI - JNI. Also the common build and package system Cargo was a bit different from what I'm used to, but not altogether bad.

</comment></comment></comment></comment></comment><comment><USER30> Rust is already greater than Haskell. Not in programming terms, but in social terms. Rust won't die, or at least won't die the same death as Haskell. Rust, compared to Haskell, has already won.

<comment><USER31> Nope. With the success of Rust, Haskell has won. Finally.

The thing is, designing programming languages is a _science_ , but practitioners often considered a _craft_. Things like the syntax of C++, the undefined behavior of C, the erasure semantics in Java, the weird semantics of Scala, or the minimal type system of Go all stem from that misconception.

Haskell took the science part serious. It is an academic language, but it tought people what can be done with a thorough design. Rust is the first language, as far as I can tell, that takes that mindset and _improves practical programming_. Rust is just objectively better than C++ in so many aspects. But it would not exist if it were not for Haskell and a plethora of PL research done in that language.

<comment><USER32> And the work done in Ada/SPARK, Cyclone, ATS.

Most likely Rust wouldn't exist had Java and .NET had been properly AOT native compiled since the first version like Delphi, Oberon, Modula-3, which would have taken away many use cases that people kept choosing C or C++ instead.

Or had AT&T not given up on Cyclone and eventually making into a common UNIX language, like it happened with C++.

<comment><USER33> > Most likely Rust wouldn't exist had Java and .NET had been properly AOT > native compiled since the first version

It's Go who wouldn't then exist, not Rust.

<comment><USER32> Only in the minds of GC haters that cannot grasp the concept of system enabled system programming languages.

Both of them wouldn't exist.

Go because it is basically Java 1.0 with AOT compilation.

Rust because C++ wouldn't have become as widespread as it currently is.

Stil trying to catch up with Xerox PARC,

[http://toastytech.com/guis/cedar.html](http://toastytech.com/guis/cedar.html)

<comment><USER25> Not to mention C/C++ literally killed compiler optimizations research. C++ committee's ignorance towards practical concerns such as debug build performance, error messages, build times and ignorance towards prior art has kept programming world 20 years behind.

<comment><USER34> > _Not to mention C /C++ literally killed compiler optimizations research_

They did what now?! I guess that famous 4-letter compilation/optimization library [1], which had its origins in academia, and which is extensively used by computer scientists as a base for their compiler optimization research, and which is written in C++, and which was originally targeted at compiling and optimizing C and C++ code, is just a figment of my imagination.

[1] It's LLVM.

<comment><USER25> You are conflating two different things. LLVM and GCC are __written__ in C++, that doesn't mean C++ is best language for optimizing i.e code written in C++ provides best opportunities for optimization.

The highest gains in optimization come not from bit twiddling transformations on integer arithmetic. They come from interprocedural analysis, especially since cache locality is so important these days. Optimizing compilers being written in X is not same as code in X being well optimizable.

C was considered slower in some cases than Fortran because aliasing information. __restrict flag in C fixed that. But C const is not transitive, and const-ness is convention rather than strictly enforced by compiler. This makes optimization hard across API / ABI boundaries. __restrict is also not transitive. If you analyse asm generated by sufficiently large program, you will sure find missed optimizations. C standard even permits any data to be accessed via a char *.

C++, while is C-speed because of direct compilation, value types and manual memory management, has too much of non-obvious performance traps in form of copy constructors, iterators etc.. std::vector can't use efficient realloc implementations, maps have to keep iterators valid, and you don't know when some copy constructor is going to be invoked and allocate memory. C++ is known as fast because its competitors in enterprise space were Java (which is often written with too many layers of indirection, has a memory hungry VM as most popular implementation and lacks value types) and unscientific [0] languages like python. Any sufficiently large C++ project that involves junior engineers will have undesired performance bottlenecks due to the idiosyncrasies of language and its ecosystem.

The massive layers of template implementations also cause performance bugs deep down, like those found in Microsoft's std::vector::insert implementation. Not to mention API practicess that encourage hidden object initialization / copying.

While I don't like the zealot instagram-ish community surrounding rust, I think the language is well designed and it has strong points in these areas. Any reference being immutable xor writeable provides ample opportunities for optimization[1]. Clone operations are explicit. And iterators are well designed. While there are small things like TrustedLen on iterators being introduced only recently, I think rust is much better optimizable than C++ is.

[1] These optimizations are held back by LLVM bug. No LLVM is not the best compiler possible as some people will make you believe. What it gets you in some more optimization passes, you lose in horrible compile times, and mediocre codebase. LLVM is mostly a proprietary-able version of GCC, while its existence has led to some good clang-based tooling in ecosystem, the monoculture is harming advances in compilers.

<comment><USER34> > _You are conflating two different things._

No, I'm not conflating anything. Your claim was hyperbolic and completely false, and I refuted it.

> _[...] that doesn 't mean C++ is best language for optimizing i.e code > written in C++ provides best opportunities for optimization._

You're moving the goalpost.

<comment><USER25> You didn't understand what I meant. I didn't move the goalpost. You understood what I meant only after reading that sentence.

It is hard for one to claim compiler research is affected because of most common implementation language. I don't know why you got that interpretation.

> Your claim was hyperbolic and completely false, and I refuted it.

Even GPT3 writes this after getting trained on some HN pages.

<comment><USER34> > _I didn 't move the goalpost._

Your original claim was: " _C /C++ literally killed compiler optimizations research._" Your updated claim is: " _C++ is [not the] best language for optimizing._ "

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER35> IMHO

The only problem with Haskell is that it's on a journey to dependent types and they haven't released new standard yet.

It's future will depend on how good that future standard will be.

Rust is becoming more popular than Haskell because It's in a different niche (no gc). Not because it's more productive to write Rust code.

Haskell is still much easier and faster to write than any other production language.

Try to compare merge function for merge sort in Haskell and in other languages.

<comment><USER36> As much as I love Haskell, once you start caring about performance, laziness and GC gets in the way. Records are still a pain to deal with. Prelude is not safe. Async exceptions bit you like in most other languages. String, bytestring, text exist. There's also tons of extensions which I hope were a default in a production language. The language is huge. I doubt having dependent types is a factor.

Haskell is definitely my favourite language but I don't think it's the easiest language to write. It could be, with the right set of defaults but it's not - and it's by choice: Haskell wants to be a language to explore language design.

Rust is a production language and solves an interesting set of problems (safety, gc spikes). I don't like the language particularly, but it's concise and it has modern features. It gets stuff done and that's why it's getting popular.

</comment></comment><comment><USER37> Rust is the language that everyone loves to talk about but no one really uses.

<comment><USER38> Except Google, Microsoft, Apple, Amazon, Facebook, Mozilla, Dropbox, npm, Discord and a whole bunch of other companies.

<comment><USER39> You mean the Silicon Valley bubble of reality distortion. It's become so far disconnected from the information technology industry that it's rapidly becoming irrelevant. Outside, in the trenches, one won't find much Rust. Or Haskell.

<comment><USER40> Every one of those companies have extremely robust business models (ok npm I have no idea about), high profits and are not going anywhere. You are mistaking them for loss leader unicorn startups.

Rust is present in quite a lot of spaces. But companies outside sillicon valley or even the US do not advertise what they are doing as much.

I am as far from SV as possible and a fulltime Rust dev.

<comment><USER41> You need to consider most of those companies are so big they probably use every one of the top 20 languages. You argue as if they were ONLY using Rust.

<comment> Ar-Curunir No, but they are using it in critical parts of some key products, and in those parts, Rust is enabling them to write better code that requires less maintenance.

</comment></comment></comment></comment></comment></comment><comment><USER42> I don't think Haskell was ever successful other than as an inspiration for parts of other programming languages like Rust.

They chose an unfamiliar syntax for no reason (and one that makes it hard to learn abstractions, e.g. the practice to not distinguish between a -> (b -> c) and (a x b) -> c), and non-strictness/space-leaks makes it unusable for anything serious; plus, it doesn't support dependent types, so it's not even good as a "theoretically perfect" language.

The only thing that can kill Rust is a better Rust, which means either a Rust with dependent types, or a Rust that is somehow much easier to learn while not sacrificing power and zero-cost abstraction (I believe the latter is likely impossible, but maybe I'm wrong).

There is also the possibility of limited success for Rust, i.e. the fact that it will kill C/C++ (which is inevitable), but fail to kill JavaScript and Java/Go/C#.

<comment><USER15> > There is also the possibility of limited success for Rust, i.e. the fact > that it will kill C/C++ (which is inevitable), but fail to kill JavaScript > and Java/Go/C#.

This is the most probable issue. Rust doesn't offer anything new or useful for a C# developer, yet have quite a number of drawbacks. Memory safety? Heck, this is exactly what the CLR is about, hence the usual name of "managed code".

<comment><USER42> Rust offers data-race freedom and in general correct concurrency (e.g. it's impossible to access mutex-protected data if you don't hold the mutex), correct handling of objects and invariant preservation due to shared xor mutable (e.g. can't pass an array to a constructor that stores it in a field, and then modify the array in unrelated code that kept a reference, breaking the class invariants), better exception safety since exception propagation is explicit, a macro system, deterministic finalization, no GC latency, reduced memory utilization, better code generation, better cross-platform support, ability to produce lighter C ABI dynamic libraries.

Rust doesn't really have fundamental drawbacks other than the fact that there are more ways to store and refer to data (e.g. owned, borrowed, boxed, reference-counted, etc.) and thus you need additional code where you want to support more than one of them.

Of course there are ecosystem differences and learning curves.

</comment></comment></comment><comment><USER43> IMO what killed Haskell was weird syntax, and the lack of examples of practical problems that are solved in Haskell. No matter which tutorial you look at, it'd be this impenetrable high brow solution to some really trivial problems that do not exist in the real world. Spherical cow in a vacuum, if you will. If you wanted to learn by example, there, by and large, wasn't an example to learn from. There still isn't. Epic fail.

Rust is in no danger of that. Lots of practical problems are being solved in Rust. Lots of great examples are available. And while syntax around borrow/reference annotations can be difficult to grasp, the rest of the syntax is not too bizarre and is largely conformant to what people are used to.

</comment><comment><USER44> Unnecessary, redundant abstractions to impress other people is what plagued Haskell libraries and therefore the whole ecosystem.

Language itself is a miracle of software engineering, and GHC and cabal are decent.

<comment><USER45> The same thing is happening with Rust.

Many Rust crates are very difficult to understand and use, due to them using tons of abstractions. Macros don't help either.

As people get more and more familiar with Rust, they write more and more code that only them can understand.

Languages such as Zig and Go are way more limited, and may require typing more characters to achieve the same thing as in Rust, but they force people to write simple, readable, maintainable code.

<comment><USER46> The same thing is happening in C++. Just have a look at certain Boost libraries. The thing is, usually you can use something else instead.

</comment></comment></comment><comment><USER47> _" Haskell in its time was at the forefront of functional programming. It was the language that kind of characterized or epitomized what FP was really about. There were other languages that were functional, but they were only sort of functional. And of course, I'm talking about languages like Scala, or JavaScript. Those were the two major competitors during the same mid 2000s."_

I guess this guy has never heard of OCaml or SML.

Though Haskell was a leader in the FP field, it was never the only language to epitomize FP.

</comment><comment><USER48> > Not because Rust is Haskell without HKTs. (Some of you know what that means, > and the rest of you will wonder for a very long time)

It would make the paper more readable to newcomers to explain this. The author was too smug and as a newer person in the Rust community I wish people who cared enough about writing papers also cared about making them accessible :/

<comment><USER49> They're not trying to make a real argument, see the very last bit. It's a completely different talk with some words substituted.

(It stands for "higher kinded types", which is a feature Haskell is well-known for that Rust lacks.)

</comment></comment><comment><USER50> Actually what kills it is Yet Another F... Language. Most new languages are barely better then anything that already exists. After the initial cheerleaders that started the project moved on, the company realizes it's hard to find coders for the niche fad language of the period.

<comment><USER50> I must have angered fad language of the year fans :)

</comment></comment><comment> ur-whale :%s/Haskell/Lisp/g

and get a valid story

</comment><comment><USER51> Haskell didn't solve a real problem.

<comment><USER51> Hahahahaha - sure this got karma-killed on HN where people love Haskell without having written one line of code. I've been paid for writing code in 10+ languages over 35 years, I have written Haskell code and Haskell does not solve any real problem. Same goes for F# so no one uses it.

<comment><USER52> > I have written Haskell code and Haskell does not solve any real problem. > Same goes for F# so no one uses

You are being down-voted for either lying or using such a ridiculous definition of "no one" to push your agenda while disregarding facts.

<comment><USER53> I don't think this kind of thing really needs to be engaged with. Let such commenters stew in their own juice. Pushing back only adds flames to the fire.

<comment><USER51> Thanks though for helping my point. No argument that counters my post but an ad hominem attack [1]. The state of our industry in 2020.

If you disagree with my point of

"Haskell didn't solve a real problem."

you could have a counter argument. Like "From my experience many companies struggle with X, which is essential to their development effort. Haskell does solve X nicely, a magnitude better than competing efforts like A, B and C from working with Haskell in a larger company and B in a startup. My opinion that companies do not use Haskell though is not that it doesn't solve a real problem - as shown above - but because of S and T".

Or you could downvote

"Haskell didn't solve a real problem."

[1] I like to be labeled "such commenters" \- though I would prefer "such people", it's meaner and has more punch. So if you go ad hominem, go right for it.

</comment></comment></comment></comment></comment><comment><USER54> c++ advances fast there days and it has no problem to fend off rust to me. for C, there is no way, it is the root of so many systems, imperfect, but worked well so far.

plus rust is not as safe as expected in practice, the unsafe mode is underrated.</comment>


A list of practical projects that anyone can solve in any programming language - <AUTHOR> https://github.com/karan/Projects <comment><USER3> Not only do I doubt that "anyone" can write these programs, most of them do not look particularly interesting or fun. Many if not all of the non- mathematical ones are simply replicating off-the-shelf utilities or tools; what is the point of reinventing the wheel?

Even if you are looking to hone your skills in a new language, creating something genuinely new seems like it would be more useful and motivational.

<comment><USER4> > what is the point of reinventing the wheel?

For many of us (me included), it's not REinventing the wheel, it's inventing it. I've taken a quick look through here, and some of these are in the 'yeah, I can do that straight off' category, some are in the 'I -think- I could do that' and some are in the '...right.... I'm not sure how I'd approach that' category. Remember that not everyone is in the same boat as you, and at the same level. I'm sure I'm way behind 99% of the people on HN, so maybe this is the wrong audience.

In addition, there's also the element of the development of the wheel - <USER2> all, they used to be wooden, and then gained a steel tyre, a proper bearing, etc... The code you create today may well be completely different (and hopefully better in every respect) than the code from yesteryear.

>Even if you are looking to hone your skills in a new language, creating something genuinely new seems like it would be more useful and motivational.

Maybe, but sometimes having the limitation of producing a specific thing can be useful - certainly when teaching music in the past, there has been room for both approaches, and I think that carries across into coding. There are also plenty of people who don't know -what- to create, and anything they look at is such a massive, difficult project combining multiple skills they may not have 100% down that it's probably better to do some simple 'test pieces' like I had to do when I was an engineering apprentice.

<comment><USER5> > I'm sure I'm way behind 99% of the people on HN

Two things about this:

First, I seriously doubt you're in the bottom 1% of HN users when it comes to programming ability. Not only is it statistically very unlikely, but there are many people who read and participate here who aren't programmers at all. While I realize you probably didn't mean that statement literally, in my experience being self-deprecating is something of a self-fulfilling prophesy. You're almost certainly more skilled than you believe yourself to be.

Second, speaking of skills as "ahead" or "behind" without context isn't very precise. I'm mostly a back-end web dev, but I have a little over a decade of experience. A brand new developer fresh out of a bootcamp that teaches modern React would be "ahead of me" if the task were to build a SPA front-end for an existent API. On the other hand, I would be far "ahead of them" if implementing the API itself was part of the task.

</comment></comment></comment><comment><USER6> Writing a game should be on the list as well. You touch many of the listed topics, and some more, have to combine them in an efficient way, and also it's fun. And your can write games of any complexity level.

<comment><USER7> I started a game clone challenges[1] list, but haven't had much time to work on it.

Some more project related resources are awesome-for-beginners[2], The UChicago X-Projects[3], and Beginner Projects[4].

1\. [https://github.com/rby90/Game-Clone- Challenges](https://github.com/rby90/Game-Clone-Challenges)

2\. [https://github.com/MunGell/awesome-for- beginners](https://github.com/MunGell/awesome-for-beginners)

3\. [http://chi.cs.uchicago.edu/index.html](http://chi.cs.uchicago.edu/index.html)

4\. [https://github.com/jorgegonzalez/beginner- projects](https://github.com/jorgegonzalez/beginner-projects)

</comment></comment><comment><USER8> Fun enough list. I'm not sure the "any programming language" part holds up. Some of these programs require a GUI element. Others, you have to squint at to see how you would put into some languages due to the wording (cough, class and abstract class, cough). The web ones, it will be hard to avoid JavaScript.

<comment><USER9> > The web ones, it will be hard to avoid JavaScript.

I don't think any of the projects mentioned are incompatible with a server- side implementation. You could even use something like HTML's image ismap attribute to implement an online white board.

</comment></comment><comment><USER10> I would add a bunch of cellular automata to that list, Conway's Game of Life, Wolfram and Wireworld are easy to make something very rewarding, cover many bases, and are absolutely open ended.

<comment><USER11> I've been working on trying to make a (relatively) performant and easy to extend strict cellular automaton in C#, as a project to learn more about .NET core and making stuff for multiple environments. It's been fun and rewarding, but as you try to generalize and expand, you can run into some annoying situations.

</comment></comment><comment> a-saleh Looks really good :-)

I would just change _Classes_ sot something more generic like _Domain modeling_?

I.e. I am thinking of using this as a list to help me learn some languages I find interesting, currently Purescript/Haskell and ReasonML/Ocaml. I don't think you would model any of the solutions to the projects in the list by creating class-hierarchies (and Ocaml even is capable of creating class- hierarchies.)

Even in more mainstream languages, such as Golang or Javascript, you wouldn't go with classes/inheritance.

<comment><USER12> Agreed. The tagline talks about any programming language, and then the classes section goes on to talk aout classes, abstract classes, class hierarchies, etc. To me it seems like "any language" in that chapter at least would refer to what people traditionally call object oriented languages.

Lisps, some low level c-style languages (go and rust among the newer ones), and some ML languages with algebraic data types don't really have the same object orientation abstractions as Java, C#, and Python. Further more the class system in Javascript ES6 are a bit special.

It would be better to talk about domain modelling, suggest interesting domains to model, without actually specifying any particular way to do it.

Edit: I must add that the author have done a great job of collecting these suggestions for tasks though!

<comment><USER13> To nitpick your nitpick, Common Lisp has one of the strongest object oriented abstractions around (The MOP). It would be quite fun to see how far you could abuse the metaobject protocol to implement some of these..

</comment></comment></comment><comment><USER14> My personal favorite to implement in order to learn a new framework (mostly GUI oriented): A RPN calculator.

Learn about stacks, state, GUI... Small enough in scope, lots of additional features imaginable.

</comment><comment><USER15> Personally (but most likely majority of the people) motivation is so much higher when new knowledge can be applied in the short-term, and a pool of ideas like this comes very useful after e.g. reading the basics of a language.

<comment><USER16> Yes. I find it very hard to _really_ learn a new language without a project to use it for, but most projects I want to work on are too large to do in a language I don't yet know, or I want to actually finish so it doesn't make sense to use a new language, but a list of smaller problems like this is really useful.

</comment></comment><comment><USER17> Nice list, but 'anyone'? The first on the list is _"Find PI to the Nth Digit - Enter a number and have the program generate PI up to that many decimal places. Keep a limit to how far the program will go"_

Easily solvable if you set that limit low and cheat. Just put a string representation of pi in the program, and chop it off at the requested length:

        n = Input "num digits?"
        if n between 0 and 8 inclusive
          print left("3.1415927", n+1)
        else
          print "number out of supported range"

If you don't cheat or if _"Keep a limit to how far the program will go"_ doesn't mean what I read in it, I have my doubts _anyone_ can write that program, even with support from Google.

<comment><USER18> There are simple math formulas that approximate pi. You can look one up and run it to the right number of digits. It would be hard _without_ Google, but most programmers should be able to do it _with_ Google so that they don't need to figure out any of the math.

<comment><USER19> You need to use an arbitrary precision math library, I don't know how hard to use those. Those formulas have a hard limit in precision for standard floating point types.

<comment><USER20> You don't need arbitrary precision, use a _spigot_ [https://en.wikipedia.org/wiki/Pi#Spigot_algorithms](https://en.wikipedia.org/wiki/Pi#Spigot_algorithms)

<comment><USER19> I took a look at a spigot algorithm[1]. I still think it needs arbitrary precision arithmetics but maybe I miss something obvious.

[1] [https://en.wikipedia.org/wiki/Bailey%E2%80%93Borwein%E2%80%9...](https://en.wikipedia.org/wiki/Bailey%E2%80%93Borwein%E2%80%93Plouffe_formula#BBP_digit- extraction_algorithm_for_%CF%80)

<comment><USER20> Here's an example if you want to try [http://www.benzedrine.ch/pi- spigot.c](http://www.benzedrine.ch/pi-spigot.c)

<comment><USER19> This doesn't look like a spigot algorithm. It has a link in the comments[1], it calculates the digits of PI from the beginning. The code you linked seems to implement the exact same algorithm.

I don't fully comprehend the code still, but the SCALE parameter suggest that it handles the elements of the array as a fixed point representation of real numbers. I wonder if it's correct for large number of digits.

[1] [http://www.codecodex.com/wiki/Calculate_digits_of_pi#C](http://www.codecodex.com/wiki/Calculate_digits_of_pi#C)

</comment></comment></comment></comment></comment></comment></comment><comment><USER21> It's sad that there isn't a single item related to implementing a compiler or an interpreter here.

That is how I got interested in computer science, and I can bet, a significant fraction of the others here had that experience too.

<comment><USER22> Someone already suggested that ([https://github.com/karan/Projects/issues/87](https://github.com/karan/Projects/issues/87)), but it doesn't seem to be incorporated.

</comment></comment><comment><USER11> Additional one which I found very fun to dick around with: a symbolic calculator capable of doing simple differentiation and integration.

<comment><USER19> I have also played around with differentiation. I even wrote a template metaprogram in C++ that could differentiate formulas in compile time. However integration is tough, I have never attempted to do it.

</comment></comment><comment><USER23> There's a whole set specifically about class-based OO, which is pretty hard for "anybody" to solve in a non-class-based or non-OO language; any solution involves developing a class-based OO extension to the language, which is kind of big deal.

That could probably be addressed in part by focussing on _types_ or _data structures_ rather than classes per se.

Similarly, there are problems which mandate threading rather than either concurrency or parallelism, whichever is intended; there are languages in which threads _as such_ are not directly supported, but with one or more structures for concurrency/parallelism that could solve the problem (and languages where threads are supported but directly using them may not be the idiomatic approach depending on the actual concurrency/parallelism requirements.)

So, for a language-neutral set of tasks, it focuses in some places too much on specific languages solutions rather than the problem to be solved.

</comment><comment><USER24> How about this?

Write an autopilot module to take inputs from altimeters, airspeed instruments, compasses, gyros, GPS, and user input. Give outputs suitable for controlling ailerons, elevator, rudder, and throttles. Extra credit: deploy it in an airliner. :-) :-)

</comment><comment><USER25> Recently implemented A* Path finding algo using Go as a way to learn Go. Couldn't help myself and went ahead and added a UI layer on top of it using a 2d game library called Ebiten.

Very fun little project! Got a hairy bug, which took me about 1-2 hours to figure out, which involved not realising that when I created a struct and added it to a slice, it was not the same struct as I had just created, in terms of memory address!

So in pseudo code:

myThing := struct{attributes...} mySlice[0] := myThing sameThing := mySlice[0] &sameThing == &myThing False

Definitely know Go a lot better now. Looking forward to doing some others on this list.

</comment><comment><USER26> If you're talking German, I can wholeheartedly recommend _Taschenbuch der Algorithmen_ by Vöcking et al., Springer 2008. Unlike the name suggests, it is a highly entertaining, but more or less unsystematic collection of common and also less common algorithms. The descriptions are informal and just detailed enough so you can implement them on your own.

It's a great little book that is unfortunately only available in German.

</comment><comment> em-bee i would love to see these projects and solutions be contributed to [https://rosettacode.org/](https://rosettacode.org/)

the readme mentions rosettacode as inspiration, which is great. i live the idea of working on tasks through git, but i'd love it even more if i could work on rosettacode tasks directly this way.

greetings, eMBee.

</comment><comment><USER27> The Web list is a good one for beginners

</comment><comment><USER28> This is seriously awesome</comment>


Hong Kong Voters Show Strong Support for Pro-Democracy Forces - <AUTHOR> https://www.wsj.com/articles/hong-kong-takes-a-pause-from-protests-to-vote-in-record-numbers-11574585756?mod=rsswn <comment><USER2> My understanding is that this doesn't _technically_ do anything other than send a message.

> Although the district councils handle local matters and have no direct say > over the chief executive's programme, the elections were seen as a barometer > of support either for the anti-government protest movement or for the > embattled leader Carrie Lam Cheng Yuet-ngor and her handling of the roiling > unrest. [1] is the source and seems surprisingly balanced on the mechanics > of this election, but I'm no expert on HK politics.

[1] [https://www.scmp.com/news/hong- kong/politics/article/3039151...](https://www.scmp.com/news/hong- kong/politics/article/3039151/hong-kong-elections-tsunami-disaffection-washes- over-city)

</comment><comment><USER3> > The election for 452 district council seats was widely seen as a referendum > on public attitudes after nearly six months of social unrest. Antigovernment > sentiment on the streets translated to the ballot box, as a record 2.9 > million voters made their choices—more than 70% of those eligible. The > election proceeded without unrest on Sunday.

> By 7 a.m. on Monday in Hong Kong, pro-democracy candidates had won 278 > seats, the South China Morning Post newspaper reported, compared with only > about a quarter of the seats in 2015.

> While district councilors typically only handle neighborhood matters and > lack legislative power, they hold close to 10% of the seats on the > 1,200-member election committee that chooses Hong Kong's chief executive, > its highest office. District councilors also have six seats on the city's > 70-strong legislature, which is only partially elected.

> Protesters have made universal suffrage for chief executive and the > Legislative Council a main demand, propelling the opposition movement.

> Many of the winners of the evening were young candidates entering political > life for the first time.

</comment><comment><USER4> For the record this post was flagged for a while, at least an hour. I had to email the admins to unflag it. I went to bed before seeing how long it took to be unflagged. At the time it was on the top 10 of the front page. Haven't seen too many articles on the front page about HK since.

</comment><comment><USER5> I Wonder what the headlines in China are?

<comment><USER6> [http://www.globaltimes.cn/content/1171062.shtml](http://www.globaltimes.cn/content/1171062.shtml)

Basically the HK people have elected pan democrats irrationally.

<comment><USER7> This was an excellent example of a well-written spin. Thank you for linking.</comment></comment></comment>


A Job Prize Inspired by the MIT Darpa Network (Balloon) Challenge Solution - <AUTHOR> http://jobprize.heroku.com/ This is a prize that I put together over the past couple of days. It is inspired by the Network Challenge that DARPA hosted, and that MIT won in such a cool fashion. I am very poor at pursuing jobs in traditional ways, and often times get discouraged scouring Craigslist and other sites. So after seeing the success of the MIT solution, I thought a similar solution might work to find me a job.
The site was written in about three days in Ruby on Rails. I'd like to make it look better to reflect my design talent, but I realized that if I wasn't embarrassed by my first release, then I would have waited too long.
Even if this doesn't find me a job, it will have at least been an interesting experiment. Thank you. <comment><AUTHOR> This is a prize that I put together over the past couple of days. It is inspired by the Network Challenge that DARPA hosted, and that MIT won in such a cool fashion. I am very poor at pursuing jobs in traditional ways, and often times get discouraged scouring Craigslist and other sites. So after seeing the success of the MIT solution, I thought a similar solution might work to find me a job.

The site was written in about three days in Ruby on Rails. I'd like to make it look better to reflect my design talent, but I realized that if I wasn't embarrassed by my first release, then I would have waited too long.

Even if this doesn't find me a job, it will have at least been an interesting experiment. Thank you.

<comment><USER2> It's clever but your job search may be difficult given your ideal job description...

[http://www.scientificblogging.com/rogue_neuron/creativity_cr...](http://www.scientificblogging.com/rogue_neuron/creativity_crime_passion)

<comment><AUTHOR> That's a great article. Thank you.

Even if as your link says, that there are adverse responses by some people to creativity, there will be others who are receptive.

Along that path of creativity-inclined people is where I think my prize money will ultimately go.

The DARPA Network Prize, which inspired my job prize, is itself a testament to a desire for creativity.</comment></comment></comment>


Ask HN: Why aren't databases 0-indexed(ie IDs start at 1)? - <AUTHOR>

It seems like most everything else in computer science is based on counting from zero. <comment><USER2> It could be problematic to have an identity column with a 0 value because you could pass in a value that evaluates to 0 (e.g. an empty string or single space). An error in your code or some other condition that doesn't pass a proper id, but that evaluates to 0, would wipe out the first entry in the table.

Identity columns are more closely tied with the data in the row than array indices are, so wiping out array index 0 is not as bad as wiping out a database row with id 0.

EDIT: Here's an example: [http://sqlfiddle.com/#!2/dd3ed/6](http://sqlfiddle.com/#!2/dd3ed/6)

</comment><comment><USER3> Arrays start at 0. Databases are databases and IDs are not always numbers, just unique values.

</comment><comment><USER4> When things begin at 0, it's often because they're abstracting an offset baked into the data structure - array[0] is 0 steps from the start of the array, array[4] is 4, etc.

Databases aren't storing things based on offsets, they're mystical and strange under the hood (by design - we worry about the schema, the database engine worries about the implementation). IDs are meant to be unique and that's about it. As mentioned by someone else, it's probably best if we don't use a value like 0 that can be misinterpreted.

</comment><comment><USER5> [http://xkcd.com/163/](http://xkcd.com/163/)

I think for most lay persons starting with one makes sense, but more technical folk learn to start with 0, so depending on who wrote it or who it was written for that usually determines the start index.

</comment><comment><USER6> They are, if the column being indexed is an attribute of the entity represented that itself is 0-based.

Otherwise they generally aren't, because of what a database is.

</comment><comment><USER7> In MSSQL it's arbitrary - you set the start number and the step size, but (1, 1) is the default.

</comment><comment><USER8> IDs are not indices.</comment>


EPA Climate Info Site "Being Updated" - <AUTHOR> https://www.epa.gov/climate <comment><USER2> The site was preserved at

[https://rescuedscience.org/](https://rescuedscience.org/)

and probably other places as well, by scientists who expected Trump's move and took preemptive action.</comment>