skysight-inc/HackerNews huggingface dataset:
My parents bought a second hand Tandy 1000TX in the early 90s, largely for my use. I remember being excited playing with the Deskmate music software, but that did not last long. After about two days, the Deskmate disk became corrupted, and I was never able to get the disk working again.
> evolution isn't teleological. There isn't some ideal life form we're purposefully evolving toward

While the universe may be indifferent to the outcome of the human experiment, I'm not! I want my contributions and descendants to live on in a form that recognizes who I was and what I did. I want technological civilization to last for millennia. That can't happen if IQ we let average IQ decay by fifteen points century over century.
(1) isn't really something that's terribly arguable one way or another (In my experience Python is plenty fast for most tasks, but my tasks differ from your tasks).

I question (2) though. Why do you think that a Python program will become unmaintainable faster than a Java program? Is it type errors? Or maybe you think it's difficult to figure out what values are expected in a given variable? Or is it something else?
> XML is a ridiculously complex document format designed for editing text documents. It is not a suitable data interchange format. Fortunately we have JSON now.

XML is about as simple as it gets for structured text documents. HTML is more complicated. Plain text is not expressive enough. Markdown, Asciidoc, reStructuredText, Wiki Creole, etc. all have pretty severe shortcomings by comparison to XML, and text processing systems will sometimes just convert those formats to XML. XML is easy to parse, easy to edit, and easy to emit.

XML also gives us SVG, which is lovely.

Yeah, use JSON everywhere else. But XML is not ridiculously complicated. The 1.0 specification http://www.w3.org/TR/REC-xml/ is not very long.
The loss of vertical alignment in go fmt is something that bothers me a bit. I am an aggressive vertical aligner and proud of it! It reduces the amount of noise in the code (as I perceive noise).
This is the same story that was on the front page a couple of days ago:

https://news.ycombinator.com/item?id=8670544
"Looks good to me". It's a shorthand commonly seen in comments on pull requests.
Can someone more invested in the SPA/rich internet application JavaScript state-of-the-art explain to me what is unappealing with the Dojo toolkit[1]? Of all the frameworks I've seen, it's appeared to have the most consistent and sustained developing, documenting, and extending efforts, over the past six years or so.

But I'd rather be programming iOS any day, so maybe my tastes in client-side application programming are very out-of-step.

[1]: http://dojotoolkit.org
Just because a past fork was shitty doesn't mean all future forks will be shitty. There were other issues aside from lock-in.
I'd say the Angular 2.0 split actually fits your first point (A lot of JavaScript frameworks are being released) rather than your second as essentially, it is a new library that shares only the name. The way I see it, Google is deprecating Angular 1.0 and creating a new library which will also be called Angular (2.0) but might as well be called something else. This bungling is rather typical of Google open source projects and I agree with the author on being aware of corporate sponsorship. I'd add to that, especially of Google, whose track record in this space (front end) is abysmal and whose track record in general as far as developer technologies is mediocre at best.
Just seems a little nit-picky to me. I can't help thinking there are more important things to implement than little gaps around letter descenders and configurable line thickness in text underlines...
Printing the contents of a C macro
Where I work we decided to avoid using libraries and frameworks, because decisions taken at that level was do not give us the flexibility to deal with the problems that we face.
The main issues we found were:

1. Change of behaviour between versions, (e.g. the way a frameworks integrate with a page)

2. Reliance on functionality being supported into the future

3. Customer expectations

4. Browser support

That said, it is true that a frameworks gives you the ability to put together an app in a few weeks. However, when you know that what deal with with something that needs to be maintained for years than knowing what does each piece of your code is far more important.
I find complaining about downvoting motivates the indifferent to vote you up. I've had posts go down to -4, me edit the post to complain about downvoting, and then have it go up to 50+.

The problem with HN is that votes are like a reward, and people want the reward for posting. But, people use votes for both "good comment" and "I agree/disagree", so there is kind of a disparity between intentions and results.

I think.
I presume by 'understanding an area' you mean being familiar with established abstract models of that area? I think that often in practical conditions the abstract models are not the area under work. They are the mapping of the area to some formal system. And that the 'area' under question - whatever it may be - can be mapped to an infinite amount of formal systems. For lots of practical purposes, there is some 'obvious' algebra of a thing one wants to do - in these instances all that is needed is an individual who can map the problem to any logically coherent structure, even just a private one in their head, and a willingness to solve the problem - and great stuff can ne done without a literature review. Sometimes the establishes models are really, really good since they either simplify a messy looking problem and/or point out to some not so obvious aspects of a system at which point an expert in the field can have an advantage over the clever layman. I think sometimes the knowledge of existing formal models can make a person blind to certain facets of the system they are working with.

Also, if one approaches a thing by a burning desire just to implement one single thing on top of it they will probably have an internal model that is very much focused on the problem they are solving.This practical need can induce them to create a new formal model or just sidestep lots of non-issues that would be a burden to deal with.
The bug in this article. Economically speaking (in other words: in the real world, where you are not the only player), which is optimal :

1) optimizing resource usage

2) maximizing resource usage

(it's easy to see why some others are suboptimal, e.g. minimizing resource usage)

From a long term perspective (ie. which of these guarantees you'll survive and doesn't provide another player with an easy way to destroy you). Other way of putting this question, which is the Nash-equilibrium answer ?

The answer is : 2.

(Is it pareto-efficient ? yes !)

In other words, no matter how good it sounds to conserve resources, it's a mistake. If a civilization did that, either it would get run over by another civilization, or, if it came to that extreme, by evolution itself.

So this is not a bug, it's a feature.
There is no mention of all the benefits that encapsulation gives us - to take the blogs argument to the extreme imagine writing your own web server, caching layer, load balancer, JSON/HTTP parser, frontend logic for every platform, and a hundred other layers of abstraction I may not even know about every time you want to write a blog.

There is a real tradeoff between programmer productivity and resource usage, because every library that isn't tailored for your exact use case (i.e every library) is an inefficiency. Given programmers wages vs. cost of CPU/RAM/storage, and the long term trends (technology makes one cost lower, the other cost higher!), it is economically insane to reject encapsulation.

I definitely see the appeal viewing programming as craft. In that case, its no coincidence that "reinventing wheels" is good advice to learn how to program. Its just not how to run a business.
Added you, we are just getting our dl going: http://www.pixsso.com/
True! It requires some skill to write concise code that can be understood easily. I think that the required verboseness of Java makes things worse than the potential for excessively-short code does in Python, though.
It almost did. It on this quarter turned a profit, the first since 2010. And it is surviving by diversifying from books. It's also the last remaining national book retailer.
I would encourage you to read the book "Maverick" which examines a lot of this in detail. It's interesting the environments they've applied these types of structures to. Including line-manufacturing.

http://en.wikipedia.org/wiki/Maverick_%28book%29
This. A lot of the frameworks are doing things that can sort of be done with vanilla JS now — personally I’m waiting on Object.observe to become more widespread.
Or if you prefer, subscribe directly: http://www.pixsso.com/
I haven't built anything non-trivial with web components but I do like where they're going with them in principle. The biggest problem I see with WC is that they require native browser support to really function properly and I'm not sure it's really in Apple's or Microsoft's best interest to support them. AFAIK Apple hasn't made any indication so far that they will support the WC spec.
I actually do find this to be an improvement for underlining of text as a visual style, such as for emphasis or headings. (Which you should never do on the web, specifically because "underline" means "link" and nothing else; however, in non-hypertext, underlining can work as a visual style.)

However, as a style for links, it has a sufficiently different style that I find it distracting, both from . appearing far too faint to stand out, and from introducing breaks in the line. It isn't nearly as bad as sites that hide link underlines entirely, however.
It's possible to do the same with a framework - it is also likely that frameworks and various libraries will be more performant and account for cross-browser issues. For example, I am not going to handcode JS logic with generating SVG for a graph - I'm going to use d3.
> when you say it out loud it sounds absurd

Hey, what a funny coincidence. If only there were some well-known style of argument with such a feature.

It could be called something like http://en.wikipedia.org/wiki/Reduction_to_absurdity

You seem to have confused an argument against ISP liability for customer behavior with an argument in favor of the same.
That's among the reasons I generally ad an on-hover very slight background color shift to links. It allows me to see what the boundaries of a link are before clicking it. I also dispense with the underline on links by default.

The following is from what I call my "unstyled" CSS -- I'll apply it to bare-bones HTML websites.

a {
color: #1e6b8c;
text-decoration: none;
transition-property: color, background-color;
transition-duration: 0.3s;
transition-timing-function: linear;
transition-delay: 0.1s;
}

a:visited {
color: #6f32ad;

}

a:hover {
text-decoration: underline;
background: #f0f0ff;
}

a:active {
background-color: #427fed;
color: #fffff6;
}
Y'know, I spent half a day today thinking about it, and your post gave me a nice, fresh angle at the problem. Thanks for that. So here's what I came up with (still work-in-progress):

The most simple program is easily done in assembly- or basic-style program - straight sequence of control instructions. The program starts with a set of data, constructs an intermediate data structure, a state graph, iterates on that graph in a simple sequence of commands, mutating it, collects output from the graph and then terminates.

When a program gets more complicated, we break sequence of commands into subsequences (subroutines/functions/etc). Each subroutine can be understood in isolation from others, which is a great win, but it still interacts directly with various pieces of the state graph, which limits our ability to reason about its effects.

Next we carve out individual pieces of the application state graph, and proclaim that each such piece can only be directly accessed by a small amount of code married to that piece of data. Such code and data married together are called an "object", and the entire approach is "object-oriented". Thus to reason about a subroutine we only need to look at its code in terms of its interaction with the "object" abstractions, rather than with the raw state graph data. Since abstractions are simpler than their implementations, it gives us extra ability to understand and thus create larger programs.

Implicit in the last two approaches is mutability - as the graph state changes, the same pieces of code continue to have access to it, and thus are expected to accomodate the drifting state. That is, the same chunks of code are expected to operate with a number of different states of the graph, corresponding to different stages in the lifecycle of the data.

An alternative way to cut down on complexity is "pure functional". In this approach each piece of code operates directly on the entire data graph, but only at a single stage of the lifecycle - it would iterate over an input readonly graph, then produce a new output readonly graph as a result, to be fed into the next stage of the pipeline.

So we have two dimensions - data and time. If we narrow down the data dimension, we end up with object-oriented approach. If we squish the time dimensions to a single point, we end up with pure-functional approach. The third dimensions - sequence of commands, is split up into smaller chunks in either of the two approaches.
The point that this was published in 2004 is certainly well taken.
Right now, pretty much 100% of all browser code is "unsafe", because they can't (for a pragmatic definition of "can't") be written in C#/Go/Java and have to be written in either C++ (or something equally unsafe), or something else with more static analysis. That's why dogmatically going with safety drives those projects back to C++.

The implementations of C#/Go/Java are also 100% unsafe, as they're in the same boat.

Getting that 100% down to 10%, where the 10% is clearly marked and sequestered behind safe interfaces that are well-tested and well-audited, is a much better solution than giving up on one or the other of performance or safety entirely.
Yes. Object.observe, arrow functions, comprehensions, yield and yield* + promises, what more do you need? :)
Beautifully illustrated post! Thanks for sharing.
Having worked with web components over the past few months, yes this. I can mix and match polymer, x-* elements, brick components etc with ease. I don't have to care how a given component is written or what its dependencies are. It's definitely the future.
Do not just do what your sales team wants
ArTICam: Game Boy Camera Photos with a TI Calculator
“The Uber Effect” Preface and Table of Contents
Why is maintaining a Rails application a mess? Yes if everything gets stuffed into controllers/models then maybe. But you don't have to do that.
> The only thing "first-class" in Java is classes.

And lo and behold, they have decided that an anonymous class with only one method is equivalent to an anonymous function object, and given us syntactic sugar to invoke it without the class declaration boilerplate.

You're essentially doing the same as complaining that conditionals aren't a Smalltalk language feature.
The unspoken assumption here is that poor people , immigrants and other such economically backward groups are backward because of their low IQ and the reason for their low IQ is primarily genetic.

IQ is predominantly genetic but it's well known how poor nutrition and upbringing can stunt it. There's lots of potential problems with this argument.

There is some evidence that the higher than average IQ of Asheknazi Jews is because of inbreeding. I posted about it on HN but people are wary of discussing such a sensitive subject.

Even discounting the genetics argument , it can also be considered as some kind of an accidental breeding for IQ as wealthier jewish families tended to have more children.

More here :

https://en.wikipedia.org/wiki/Ashkenazi_Jewish_intelligence
ThumbzUp's new Pebble M-POS is a smartphone
That's fair. My project was a case where I had to build apparatus A to produce B in order to measure C. After spending a fair amount of time getting A working, I was able to observe B, barely above the noise, but could not sustain it at a level needed to even consider trying to measure C.

It was an ambitious experiment, i.e., it would have earned me genuine recognition within my specialty. I admit a high likelihood that the project was over my head.

Oddly enough a fellow student dreamed up a project for me that used much of my existing equipment and my equipment hacking skills. It produced one minor publication, but opened up a new experimental technique.
I'm surprised to see that HNers think that "strict discipline" and "hands-on management" are requirements for a company to succeed. The startup I work for is in a competitive area, and we aren't treated like children.
Author's argument against using C++ isn't true. New/delete can be easily redefined to use malloc/free [0]. You can compile (a bit limited) C++ code without any special C++ dependencies.

[0] http://ptspts.blogspot.com/2010/12/how-to-write-c-program-wi...
I was with you until the Lambda stuff. I find the anonymous class _far_ easier to read and code.
I was a C# and hence VS user for many years, so I mainly used that, but at the same time, also casually used Vim for editing csproj files, MSBuild scripts and the like. Then I moved away from C# and Windows to Linux and DevOps stuff. At that point, I started to use Vim fulltime. Getting into it, I saw you could keep your configuration in a dotfiles repository, so that you didn't need to remember how to setup a billion plugins on a new OS install (although admittedly, that's true for any editor) and that was when I seriously invested time in getting a good setup.

Now, I just can't imagine going back to anything else. No matter how good you seem to get, you just never stop learning stuff about it that makes it easier to do your work. Initially I was afraid of not having intellisense, as I'd developed what I consider to be a bit of a crutch on that, from years and years of using VS. But, it turns out, you can get very near IDE like intellisense with plugins like YouCompleteMe. For me, the approximation is acceptable, due to all the other power that comes with Vim.

I also love that I can use it in the terminal (I don't use gvim) and still have it look fantastic, meaning, using it along with tmux, I rarely need to leave the terminal for anything now. I like that, because it means I get to learn how to do everything really fast on the command line, without the aid of a mouse. I really just consider the whole command line environment to be my IDE now, and I love it!

I do have to admit though, if I was still doing Java or C#, I'd probably still keep the IDE around for doing big refactors and some code analysis. Now though, I'm mostly using dynamic languages and bash scripting, so the full IDE isn't as necessary (at least I haven't found it to be, so far).
Autism and war crimes: Turing's moral character in the Imitation Game
The stability will still be there - the first evidence of breaking changes was at ng-conf back in January, when Vojta presented about di.js. In addition, Angular 2.0 won't come out for over a year (I'd bet on 1.5 years from now given the tendency for timelines to slip - 1.3 was originally supposed to come out a year ago), and Angular 1.x will be supported for 1.5 years after that. That's at least 3 years of active development in 1.x. Meanwhile, the development ecosystem will probably have finally adopted Web Components and ES6 as the norm for development, and so it would give the perfect opportunity to evaluate options to migrate to then.

Web Components looks hugely promising as the path for independent components - essentially what Angular directives were meant to be in the absence of such browser technology.
However, they can easily be made asynchronous and address multiple recipients. See Higher Order Messaging[1][2], first implemented in Objective-C[3]. So for example:

[[myView onMainThread] setNeedsDisplay:YES];

result = [[someObject future] someMessage:arg];

combined = [[prefixes collect] stringByAppendingString:[suffixes each]];

The reason this is easy in Objective-C is because its brand of message passing is just (barely) powerful enough to qualify as message passing. In fact, if you squint just a little, you can see it as fully reified message passing with the common-case (a synchronous method is invoked) optimized.

[1] http://en.wikipedia.org/wiki/Higher_order_message

[2] http://www.metaobject.com/papers/Higher_Order_Messaging_OOPS...

[3] https://github.com/mpw/MPWFoundation
I wasn't responding to the entire article. I agree that he got a few things right.

The specific part I quoted, though, stands out to me as a rather old-fashioned management philosophy, one that is unlikely to attract and retain top talent in a competitive hiring market.
I may as well throw in my implementation in Go here: https://github.com/seri/goalgo/blob/master/st/llrb.go

LLRB definitely isn't as sweet as advertised, but saying it's a scam is a bit too much.
Maybe it has something to do with edX's Functional Programming 101 course[1].

1. https://courses.edx.org/courses/DelftX/FP101x/3T2014/5074063...
Well, sort of. It's possible if you're willing to take on maintenance of that library if/when they abandon it, and be able to dive into the guts to track down bugs or weird behaviour.

As a good example, we're on the verge of ditching JQuery.
Seems relatively accurate to me. I understand the lean towards tiny fragments, there is less upfront investment / easier learning curve; this reduces risk. Perhaps with time we will see intermediaries emerge between light libraries and heavy frameworks - eg combinations of the former into subsets of the latter, suited for less general development.
open source has won, we are innovating at faster and faster speeds than ever before, and the best innovations eventually bubble up to the top, bad ideas get peer reviewed out and thrown away before the whole world depends on them, this is amazing!

I for one am perfectly able to track all this innovation within my specialties (enterprise web dev) across multiple language ecosystems, and if I miss something, someone in my monkeysphere will make me aware of it, all of this fuss sounds like hot air to me.
> You probably shouldn't use this in production.

Yeah, that's probably an understatement.
Reminds me of HasciiCam from 2000: http://ascii.dyne.org/