skysight-inc/HackerNews huggingface dataset:
> Software is designed; you don't (or at least shouldn't), construct your programming abstractions by progressively mutating the different parts of your code.

Is this another ad for big design upfront, aka waterfall? It is a nice ideal, but when you get down into it, software really is evolved since requirements are constantly changing and your understanding becomes better.

> You get to build a bat by strapping wings onto a rat, and you know how to build wings because you already did it for birds.

Really you don't. The bat flies quite differently from the bird, with substantially different attributes. Strapping bird wings onto a rat often isn't going to work.

> This issue comes up enough in gaming that the no-hierarchy-lots-of-mixins approach has a name: the entity-component model.

This is actually much older than that (Common Lisp Flavors), and languages like Scala include mixin-like traits, not to mention the work of Bracha and Cook. Inheritance is still heavily involved in that though, it is not "mixins or inheritance" but "inheritance with mixins," it still very much is OOP, and you are still defining a DAG if not tree.

> Finally, how far would we really be willing to take biology's classification-by-implementation philosophy, even if classifying pieces of code were really our goal? We could end up with superclasses like UsesAStar and HashSet. Not really the point of all of this, right?

Why not? Why not classify all of our code at the finest grain we can? Of course, existing languages are poorly suited to that task, but we can always define new languages where this isn't a PITA. Or we could just use machine learning to figure out what the connections are automatically (this will happen eventually, just not for another 10 or 20 years I hope).
Yes! I most emphatically agree with this. I do a lot of OO programming in Java or C++ but I think its a horrible idiom for JS. Although I also think prototypical inheritance in Javascript is also pretty ugly :o) For me, JS seems to work best when treated like a poor man's functional language using libraries like underscore.
I just posted a link to the above paper in a comment here:

https://news.ycombinator.com/item?id=7496154

But it's such a good article, that I think it warrants reconsideration given the "Abstract Ideas Don’t Deserve Patents" article in the New York Times (linked in that above comment thread).

This paper really changed my mind on the notion of IP. And if you've got a view on the subject, it's worth reading.
Do you know of anything similar for amd64 Mac/Linux? Not PLT hooking but the sort of deal where the beginning of the function is overwritten with a jump to the hook. The overwritten instructions in the original function are copied to a mmap()ed area of memory that jumps back past the hook jump.

I found an old copy of MobileSubstrate that has partial support for i386 and x86_64 (which works fine on Linux since the ABI is the same as Mac). I found out that it doesn't support all the possible jumps in the overwritten area. I've been slowly patching and improving it[0] but I'd rather be spending my time hooking stuff than writing the hooker.

[0]: https://github.com/jevinskie/substrate
You completely missed the point. First the anecdote was merely a segue to the core thesis of the article - that is the dubious way certain counties levy and collect fines. Second the article didn't actually claim the woman was innocent because again, that wasn't the point. You seem to have stopped reading after the first paragraph.
There is a feedback loop at play: the entrepreneurs go where the capital is and the capital goes where the entrepreneurs are. The geographical distribution arises organically from that feedback + the initial seed of Stanford University.

It's not that VCs look down at Oakland per se, it's that there aren't many good investments to be found there.
Could you spell out your perceived contradiction? As far as I have seen, the perception of contradiction happens only with people who don't find them credible to begin with.

Personally, I don't see it as hypocrisy. In the case of those opposed to Prop 8, people aren't arguing for some generic tolerance, they're arguing for civil rights, including equality before the law. Most of the gay people I've talked to figure the prejudiced are going to keep on with their hating; they just don't want that bigotry enshrined in law.
Just being statically typed helps, there's nothing particularly special about Haskell that makes QuickCheck possible.
Seems like Facebook is having parallels to the IE6 support problems websites used to face. They could do some cool stuff with new HTML5 features, but the displays most of their users have are not up to snuff. Guess they had issues with getting the big picture newsfeed to degrade for those displays.
For regular debt owed the government you can't usually be jailed, if it's not as a result of fraud: the IRS can try various ways to coerce you into paying, but they cannot jail you for an outstanding debt that you really can't pay. Instead they resort to negotiating repayment plans, garnishing wages, etc.
I'm glad you've been having a good experience! It's been fun building it and I'm excited to to keep growing it and making a viable platform for the more privacy-conscious.
You're completely missing the point. Putting her in years of indentured servitude to the state and some third party contractor doesn't mitigate the chance that she'll hit you while driving uninsured at all.

In fact, while scrambling to get the money, she's going to be forced to make the decision often between driving and hoping she doesn't get caught, or not paying her fee and going to jail.

It's amazing that someone could read this horrible tale and can only see how it affects themselves. How much oppressive klepto-state will you support to prevent the slightest chance that the situation of the poor might affect you and yours?
I liked deVries' The First Modern Economy - the first volume is great. It's not a pop-econ book, but rather a good hard look at the Dutch economy circa 1500s. A Concise Economic History of The World is also not a bad book, if a bit dry.

There are too some other cliometric books that I really liked but can't for the life of me recall it. There was another that was along the lines of Money and Market of All Times or something or like that, which I recommend for a quick skim through (not really worth a deep read - I'd treat it as the others already mentioned in this thread)
Here's a handful of things I really appreciate about Haskell, although some of this apply to other ML family languages as well:

1.) Algebraic Data Types let you enforce a huge amount of correctness in your programs simply by how you define your types.

For example, say you have a data type that represents a player's state in a game. If the player is alive, he has a "HP" and "inventory" record. If the player is dead, he should just be dead—HP and inventory may or may not be set to 0 and None, respectively. In C or OOP languages, you just get a player object/struct and you have to enforce this state logic manually, and you can easily write a function that puts the player in an inconsistent state (player.alive = False, but player.HP = 15). In Haskell, you can define the player such that code that produces this kind of inconsistent state will not compile.

Of course, you should still write tests in Haskell, but it's amazing to me that the type system can catch the vast majority of programming errors before your program even compiles. It takes longer to get something up and running, but you make up for this up front cost with long term gains in maintainability.

2.) Functional purity enforces two very useful properties:

a.) Data is never mutated by accident. This ensures you never have to look beyond the scope of the function you're working on (or closing over, in some cases) to know what's going on. You can then compose these functions to create more complex programs.

b.) When you do need mutability and side effects to happen, Haskell forces you to be very explicit about this and enforces a strict separation between "pure" and "effectual" code. This seems arbitrary until you realize that almost all of your errors not caught by the compiler happen because of IO. Whereas you have complete control over the pure part of your program, IO is nondeterministic and full of exceptions and edge cases. Separating this part of your code makes it far easier to reason about what's happening, adding to maintainability.

As a side note on the last point: people make the argument that this separation makes Haskell impossible to do printf debugging. Not true—the standard library provides ways of circumventing the type system specifically for this reason.

3.) "Monads" and other fancy sounding abstractions can be hard, but with practice they become as intuitive as inheritance in OOP. The real barrier to entry is the awful, awful documentation everywhere. I make no apologies for that: it's just really shitty and the community needs to do a hundred times better.
$745 for a traffic ticket sounds a bit too much. Punishment for any crime should be proportional to the crime committed. I don't think anyone is asking for no punishment for violating traffic rules, but proportional punishment is hardly the intent of justice system in her town.

Punish her to make sure that she does not repeats the same mistake again, which is what a lot of places in America do daily, without anyone needing to write an article about it.
I'm a Java programmer and I think classes in JS would be awful. Tacking on the ES6 behaviour will not make JS a sane OO language, it'll make JS a bunch of new, inconsistent behaviours tacked onto the old, inconsistent behaviours.

FWIW I'm with you: I think that treating JS as a functional language is a cleaner fit that crowbar-ing OOP into it.
It takes no imagination to distinguish between "things users go to Facebook to see" and "things users do not go to Facebook to see".
Immutability is good but far from enough.
None of this means anything unless there is clear pricing. Am I not seeing it?
Potentially a combination of things. Education and reinforcement, discipline, opportunities, etc. All would surely help. On the last item, at a servo (what an Australian generally calls a "gas station") soft drinks and energy drinks are often cheaper than water or promoted in two-for-one deals. They're also always at eye level, leaving milk and water on lower shelves of the display fridges.

When you reach the counter (and the same thing happens near supermarket checkouts), there is literally shelving with hundreds of chocolate bars between you and the attendant.

And this is where you're filling the car that enables you to avoid walking a distance instead.

Another opportunity example is fast food. The 24-hour shops will be Hungry Jacks (Burger King in AU), McDonalds and so on, or servos. Supermarkets will generally have shut by 9pm.
I'm utterly shocked that this happened in a Southern state.
> arrow "keyword" a very sensitive choice

I think you meant 'sensible' there.

I actually find the cs arrows a lot more useful than the es6
short-hand function definition, because a lot of the time I want
to do be able to do composition, and the es6 one always binds the
scope to where it's defined.

I love named functions otherwise, which ease debugging and understandability.
I actually don't care for implicit returns, not just because i
prefer being explicit, but because it's the cause of some very weird bugs at times.
One aspect that doesn't get mentioned much is recruiting from both sides.

As an engineer, if you land a job coding haskell you're pretty much guaranteed to be an environment thats extremely engineering-centric, has minimal technical debt, and is staffed by lots of smart people. usedox.com, alpha heavy, jane street (ocaml but close enough), silk, tsuru, fobo are all exemplary examples of this. anyone of them is an amazing environment and you'll learn a ton. (the first one is my own company, so consider that one with a grain of salt)

As an employer of engineers, if you put out a call for haskellers, you'll get a far smaller applicant pool than say ruby, python, java, or c#. But the signal to noise ratio is incomparably higher. Very few mediocre engineers will claim haskell as a skill.
> laziness always seemed an important part of Haskell's elegance

It's part of it, but to a lesser extent than you would expect. The much more important part of Haskell is its no-corners-cut separation of effects, which happened chiefly because, without it, laziness meant that there was no way to know when fireTheMissiles() would actually happen.

> Is laziness now considered something of a failed experiment?

To some extent, yes. No one is saying laziness doesn't make the implementation of some algorithms and data structures extremely elegant, just that, most of the time, you don't actually gain much by leaving your function calls and data types lazy.

I enjoy being able to make infinite/self-referencing data structures, or leaving fields lazy and "performing" all of the function calls in the initialization of the "struct", but have only the functions producing results that will actually be needed matter performance-wise. However, if you don't use any strictness annotation, that benefit doesn't outweigh the problems that can be caused by space leaks.

If you do use strictness annotation, I don't think it matters too much whether the language is lazy or strict, you just have to write strictness annotation instead of laziness annotation.
Have you read the source to Haskell's QuickCheck?

It can automatically derive automatic randomized generation of your data-types FOR you. No other generative testing library (such as for Clojure or Erlang) can do this.

Further, the random data generation can be customized using the functional combinator API.

Haskell QuickCheck's source code is a compelling example of what can be done with static types and typeclasses in Haskell.
OJ Simpson Witness and Critical Evidence Withheld
npm depends on a javascript compiler such as g8 so how is that different than clojurescript depending on the JVM ?! It's no different at all you're just complaining that you don't like to have to install software before using it which is ridiculous if you want to use powerful software.
I'm not saying it's worth nothing. I'm saying it's not proof that there never will be any problems. I'm saying that gay employees, partners, and donors can have reasonable concerns about Eich.

Personally, I'd be happy if Eich said, "Boy, I was a jerk to support Prop 8. I've always believed in equality, but I supported Prop 8 for [mistaken reasons]. I now understand that helping to strip some of my employees of their civil rights was harmful action, and apologize unreservedly."

But instead, he's dodged the question with some vigor. Which makes it reasonable to think he still thinks some of his employees don't deserve the same rights as he does. Whether or not that actually leads to bigoted actions within Mozilla as it has outside of it, reasonable people could fear that it would.
A while back I was learning Haskell. I had a problem I wanted to poke at a bit, so I thought I'd give it a try. So I made various types in Haskell's nifty type system, which is NOT hard or tricky. I made some functions to work with the types. Easy. I worked all this stuff up and tried to compile, and being that I wrote a fair amount of code of course there were a couple of typos, etc. But then there was another part that wouldn't compile because I'd made an error, and the type system called me out on it. It's like getting the benefit of unit analysis (or dimensional analysis) from the compiler.

That's one thing to like. A lot. There are other things. Polymorphism/overloading through type classes is so easy and clean it's hard not to love. The list goes on and on.

For my part, I got hung up a bit on using monads. This was a few years ago, so maybe there are better articles/explanations now, but at the time there were a zillion monad tutorials, all of them written by people who almost but not quite "got it". I need to try Haskell again.
Why is this the top story on HN, let alone on the front page?
Yahoo isn't the only large company to instruct its employees to avoid mongodb due to it being AGPL. In my opinion, the only people using mongodb in a commercial setting are those who are paying 10gen for a commercial license or those that don't know they are violating the AGPL license.
> Short version: Most, if not all programming bugs are due to your code receiving something it did not expect. Haskell's type system helps eliminate this problem by forcing your code to declare exactly what it expects, and to handle all cases of said expectations.

No it doesn't (force). It's about as good as C++ on this front, with better error messages. What it does do is make it a lot easier to program in a style that handles all cases, but without forcing you to do so. You can pattern match on something instead of making a visitor. But you can still call head or tail.
http://objectrocket.com/pricing
Are you serious?

Did you read the article? Do you understand the difference between not being poor and able to pay your bills and then being poor and not able to pay the bills?
Then it's a shame that the author led with this particular woman.

My opinion on the "debtor's prison" subject is that non-payment of fines should never result in jail time. Other punishments perhaps (revocation of license, liens against property, etc), but never jail time. Nor should interest and penalties be permitted to eternally inflate those original fines. And the privatization angle ... these companies need to be heavily regulated. I could go on and on about that one...
Tax write offs do not work like you seem to imply. There is no net financial gain to any charitable donation . Consider a dollar of profit. If kept on the ledger as profit, a corporation pays around fifty cents of that dollar in tax. If donated that dollar of profit is not taxed, but the corporation now had lost a dollar instead of 50 cents.
The security model is broken. You can't securely do encryption in server side javascript.
Thanks! Updated.

Didn't know that about the new ES6 functions. I'll check it out.

Yes, named functions do improve debugging... But I guess it's worth the trade. I have come across very confusing code thanks to named functions.
The funny thing is that when someone is locked up for not paying their debt, the government very likely ends up having spent more money doing that than just leaving that debt alone.
Tax Breaks to Anchor Tech Growth in San Francisco
Rewriting Git History (or how to fake being a flawless committer)
Yeah sure, you didn't grow up boxing and wrestling with your friends?

Hell, we used to have stick fights and beat each other with sticks, or play full contact football without any gear.

We used to also climb all over parking structures, up and down trees, construction sites, ditches, rain water drains.

One thing you learn from punching around with your buddies is the unwritten agreement of fairness. You only punch or slap as hard as you want to get punched or slapped. The golden rule works both ways!

I thought I grew up in a pretty overly coddled time. Are things really this bad?
law evaluates intent. i'm not a lawyer, but i'm not an idiot either and it's pretty easy to read between the lines here.

if the intent is to illustrate security and encryption, there is no reason to invoke "copyrighted material" at all.
"Composition is the only proper way to reuse code because composition is explicitly stating you are using the composed code."

And every other pattern is not suggesting this very same thing?
The article made reference to a 1983 US Supreme Court case Bearden v. Georgia which held that states may not imprision a person if he is legitimately unable to pay a fine or restitution.

Ref: http://supreme.justia.com/cases/federal/us/461/660/case.html
Haskell encourages you to think upfront about the shape of your data, because you have to design the types upfront and your constraints are checked at compile time. You can build a level of reliability and quality into your software that's hard to achieve (not impossible, but rare without great programmers) with a dynamically typed language.

There's a certain imprecision that you see with mediocre programmers. They don't know how things work, and get used to fooling around with a certain squishiness that's tolerated on large object-oriented projects as long as there's one good programmer ("architect") in the batch to clean up messes. That's good enough to get by in the business world, but not if you really want to understand what you're doing and call yourself a true programmer.

Haskell forces you to build from the ground up, and a nice consequence of this is that, for any type, you can inspect its pieces and get down to the bottom. Functions will have easy-to-find type signatures and, sometimes, you can get a good sense of what the function does from its signature.

In fact, in Haskell, the type system can be used to make assertions about functions like "this function doesn't have any side effects" and it's trivial to do so.

In the long term, Haskell's heavy use of immutable data structures confers some major performance advantages as well.

Is it the right language for every purpose? No, but it's very good for many, and it's a source of great ideas that have percolated into other languages, like Clojure and Rust. Additionally, it will force you to think rigorously about your data and what is happening to it.
Whoa. I've had similar ideas on my own, and now it seems they weren't so unique after all. I'm founder of Wavesum which is focused on music analysis algorithms and their applications. Would be cool to compare our beat tracking algos. Lots of love and ramen was put into ours.
The thing that should scare you all, is that this article isn't wrong. If you argue that it is wrong, than I'm sorry, but you aren't seeing things clearly and this is going to hurt you most.

If you are making a good wage in this industry, put some away for when shit hits the fan. It's not a matter of if, it's a matter of when. Be prepared, friends, because shit is going to go down.
These sort of problems crop up a lot more the larger a codebase gets and the more people working on it. Being careful with your variable naming and global scope are necessary to working well with CS.
Yes, but does Human inherit Neanderthal? If we don't know this beforehand, how do we implement both classes?
Because it was voted there. If you want different sorts of stories checkout https://news.ycombinator.com/newest and vote for the ones that you want.
i would love to see a solid technical reason to choose mongodb over any of the other NoSQL db's (couchdb, riak, redis, etc..) other than "it's popular".

No, I'm not trolling. I really want to know : https://news.ycombinator.com/item?id=7446919
> It can automatically derive automatic randomized generation of your data-types FOR you.

There's nothing about Haskell (or some extension to Haskell, I presume) that makes this possible that wouldn't make this possible in other languages like C#, Java, or, with a bit more verbosity, C++. If I'm wrong, please say what it is, I'd love to know.
Some people really like meeting strangers and especially travelling strangers.
I was considering tokumx because it seems like scaled better than normal mongodb but to be honest I'd love to move of this database entirely. I'm somewhat unfamiliar with postgres but does it have a storage/querying system comparable to mongo?
> One wonders if every ISP customer were willing to pay the extra fees (if any) and requested a publicly reachable IP address, could the ISP's meet the demand?

Well no, that is why all ISPs are using DHCP. Most offer static IPs for extra fees, but like fractional reserve banking that only works if all possible subscribers aren't trying to claim unique IPs each.
TORTLE <<<<< Dropbox