skysight-inc/HackerNews huggingface dataset:
> So it's our duty as IT professionals to prevent people from using IT?

Yes, within reason. I advise people not to use Facebook, and I spend a fair amount of working hours on alternatives to Google's app infrastructure. For the grayer areas like improving search, you deal with complicated questions and push the industry to innovate on effective distributed designs. You're making a big assumption saying that collecting a centralized database on users is the only way make good search results. It's certainly one of the easiest ways...

> It's non-sensical to talk about risk without talking about the actual scenarios you're worried about. How bad are they? How probable are they?

If you don't have personal control over your information, detailed knowledge of how the information is used, or the ability to revoke access, you basically have to assume the probability is 100%. There's barely any legal framework in place on the issue, and so we're left with social pressure and business ethics.

Can you really not guess at a negative outcome for personal information collection and passive surveillance?
That's some random guy's Livejournal with no sources and amounts to "If the police tell you to hand over $20 because they want to order a pizza, the safest thing to do is comply and file a complaint later." Which is probably true, but I was talking about the legality of ignoring orders that the police don't have the authority to give. And I don't think I'm wrong.

Here's what the MD ACLU has to say [1]:

> The safest course of action is to obey the officer's directives. Not every order by a police officer is lawful, and police may not lawfully arrest you in Maryland for failing to obey an order unless the order is lawful, and aimed at averting some imminent illegal conduct. It is difficult to know at the scene whether the order is proper, and failing to obey may result in an arrest, even though the arrest may not be proper. You have the right to photograph and record police officers performing their job in public. Police may not order you to delete photographs or recordings on your camera or cell phone.

Assuming the system works properly, you could not be found guilty of refusing to give a police officer pizza money (to reuse my earlier example). It's not illegal. Photographing the police and observing a scene without interfering is in the same boat.

[1] http://www.aclu-md.org/your_rights/know_your_rights
That's a fair point. In my haste to reply I made too much of a personal attack. The phrasing I should have used is more like what ilaksh said [0], which really gets to the heart of the matter.

[0]: https://news.ycombinator.com/item?id=7497354
This is very nice. I wish GitHub had something like this built-in.
Having worked as a coder, I know what you mean. But those marathon sessions, however good the "flow" or "zone" is, are untenable in the long term and bad for productivity. The longer you work, whether you realize it or not, the more mistakes you'll make - which is lost productivity.
The article doesn't really answer the question of why U.S. dental insurance has such low yearly limits on coverage (compared to medical insurance). Or why dental procedures are insured separately from other medical procedures in the first place. After all, the teeth are as much a part of the body as the lungs or the appendix. How did this arbitrary division come to be?
The original discussion [1] to the original article [2]:

[1] https://news.ycombinator.com/item?id=7484053

[2] http://asherv.com/threes/threemails/
Pew Research pulls together eight key takeaways on news and social media
Doesn't scala suffer from the JVM constraints, like no tail call recursion, everything is an object, such that the compile times become enormous to work around them?

Haskell is indeed influencing, but it is not remaining stagnant.
It's outrageous because the argument is that it would be really cool to brand poor people with a big red letter because you couldn't get pets.com when you wanted it.

Most of the world can't seriously afford $100/year for a domain registration. Get out of your bubble.
That's interesting. I wonder if it would work on something like the Surface RT/2, which is locked down.
That's a stupid statement by Musk. It's akin to saying, if I start off a marathon at 3x the speed that the other runners start it at, Im going to be 3x the distance they are, so I will win the race. There are ridiculous nth order negative effects from working 100+ hours a week: health, personal relationships, intelligence. Fuck, you could crash into a telephone pole driving home after a 17-hour session of work. I've almost done it myself. That was a dumb comment by Elon, if read unqualified.
I have found flow-states very important for implementation, but disastrous for creativity.

I can do PCB routing, design and layout till 5am in the morning, but the day after I need to sleep well to do more conceptual work, or else I'll forget what I'm working at.
Telling a kid in college (I was a sophomore when I was writing Haskell) that he deserves to lose 10% over something like that is crazy. The obvious to us, many years into programming professionally, is not always obvious to newer folks.
Yeah, that's certainly possible. It's also largely frowned upon because it's usually over complex. For instance, in your example

[exists a . (a -> b, a)]

is literally completely equivalent to

[b]

as the types ensure there is no other thing that can be done with those pairs.

The convenience factor is thus almost never the case. There are some nice theoretical properties and a great embedding of OO in Haskell via existential typing [0], but it should rarely be used.

[0] http://www.cs.ox.ac.uk/jeremy.gibbons/publications/adt.pdf
Thanks for clarifying my point, since I was a bit brash.

The argument you make regarding learning a new language is solid, and I think it can also be applied to new libraries, design patterns or even just coding standards. Now that I think about it, the backwards judgement -> rationalization strategy is one of the more pressing problems facing society, and I was guilty of it just as much by judging the OP first and rationalizing second.
Not all "balanced" diets are created equal. You can read the labels on all food you buy and balance the amount of protein, fat, and carbs you get according to the latest science, but you'll likely do far better by eating food that doesn't come with labels.

This article highlights one of the many possible reasons why this is so. Refined fructose is absorbed by the body almost instantly and hits your liver like a freight train. The same amount of fructose eaten in the form of raw fruit takes longer to absorb and trickles into your liver, giving it time to cope. The same nutrients ingested in different forms have different health impacts. Never mind that it's also easier to eat far more sugar when it's refined! e.g. A 590 mL bottle of coke contains about the same amount of sugar as a half dozen apples.

What's the lesson learned? Try to let your body do some of the processing itself. That's what it has evolved to do. We will most probably continue finding ways in which highly processed foods are bad for us. Perhaps it's not a good idea to let industrial processes pre-digest your food for you. We are finding out that how we get our nutrients is as important as what those nutrients are.
Astute observation; I agree that I should not have used runtime errors. I quickly converted the code to a Monad based solution. That being said, I was in the middle of trying to understand both Haskell and my task at hand, so I was quite thankful to have it working at all. With no one that understood Haskell enough to explain Monads to me, I had to slowly come to the understanding of them on my own.
We're making a big mistake with an every big thing, that's the way we handle buzzwords.
Access any Tesla S with only a 6 character password over the net
the minutia of most efficiently optimizing your syntactic sugar to communicate DEEEEP meanings is the most annoying part of the open-source/language community & one of the biggest factors in why i've actually come to like corporate java.

i've been on so many RoR interviews where i am dismissed essentially for not knowing enough of cutesy syntax tricks and yet in the Java + plain ol' javascript projects i've worked on I've been exposed to a muuuuuch wider variety of programming design patterns than i ever was in Ruby-land, to the point where i could care less about the tiny semantics these hipsters spout on about

one of the few new languages i'm interested in working with now is Clojure simply because they cleanly define libs & then don't have all of this obsessive "syntactic sugar" nitpicking. to make a language / code library usable it shouldn't depend on developers going down a rabbit hole of brackets etc. I understand this is difficult to avoid in the "compile to js"/language pre-processor community but it's why I prefer Dart as a solution. It is an attempt at a clean, robust, simple language rather than a repeat of the annoying language evolution process where devs in the know just talk down to those who don't care to commune with punctuation all day
In Some Ways, It's Looking Like 1999 in the Stock Market
Personally I believe that software design is a highly subjective art. People that are meant to maintain a piece of code are different. Some may be more creative and less pragmatic, others may be more structured and clean in their design.

The truth is that there's no silver bullet. You can build software based on hierarchy of classes because your mind works better with that structure, but others may find it completely inappropriate. We're human and our mind works differently from one another.

In that sense I truly believe software is much closer to art than engineering.
Not the main problem by far.

I had backed hundreds of projects. Next year I would make a thousand or so.

How many scams I got into?
Zero.

It is pretty easy to spot who is serious and who is not, who will deliver and who wont. The great thing about capitalism is being left to carry the risk yourself.
Another battle in the 60 year language wars
based on criteria that are so obscure that
have battles just over the darned criteria.
I see. Sorry, I should have interpreted that more generously.
One issue that still has to be solved is for people like me to charge them without a garage. Swapping batteries is interesting, I wonder if it will become a cheap reality.
I think the takeaway is often that inheritance doesn't give you isa relationships; it gives you one tool for building isa relationships. So long as you use it judiciously and ensure that you're creating a genuine supertype then things are OK.
I don't think that's so. A NAT also prevents random hosts from directly opening connections to the machines that it's obfuscating (module port forwarding), which serves a nice security purpose.
That's not quite a silver bullet definition for all scenarios.

Having worked for large organizations, where "money is no object", the reality of your scenario becomes distorted by the fact that you have to pander to the almighty overlords who control the purse strings. Suddenly everything becomes purely political, and success solely relies on entertaining the favor of powerful people (powerful individuals, with respect to the scope of the organization, and their capacity for making broad, sweeping decisions).

In very big organizations, there might be three or four degrees of separation, between you and your actual masters, the ones that your direct boss is beholden to. Your boss might meet directly with these VEH-HEH-HERRRY important people maybe less than twice a year, but have direct orders handed down from them by their heralds on a weekly basis.

Such orders might come in the form of:

In addition to your usual work load, make X work by next
quarter with with Y people; We understand that you
already have Y people, but your job now depends on making
X work. Do not fail us.

I had a boss come back from a very short meeting like that, ashen and distraught. She left early for the day, and the next few months were a living hell for all of us. We did get X done successfully, and on time, but afterward I quickly drafted my resume, and took a hike.

With jobs at large companies and other forms of organizations and institutions, you might be completely disconnected from the cash flow situation. The reality may be that the organization, by most measures is actually nearly indestructible, and has existed since before you were born and is sure to exist long after you die, but as with any form of collective human effort, there is still a bottom line somewhere in the mix, and you might not have obvious clues as to how it expresses itself, other than the amount of stress your involvement inflicts upon you.
I'd be tempted to fork if it were me.

IE6? They insist on supporting IE6???

The jQuery guys finally figured out what a really amazingly horribly bad idea it was spend support and dev effort on old versions of IE. The Coffeescript guys will figure it out sooner or later.
Agreed, I couldn't concentrate enough to even read it because the font kept changing.
Haskell does allow you to define default implementations, though. In at least two different ways.
I'm well aware of how little I changed. If I were coding this in my style I'd also move the shorter key/value pair up above the function definition, or more likely simply define the function as a local variable elsewhere. It's very rare that I declare function literals within an object literal.

You're right that the comma was the real tragedy. I removed the braces to help illustrate how taking full advantage of the features of the language makes the code stronger. Strictly speaking removing the comma was all that was necessary.
I used CoffeeScript full-time for a year, both client-side and server-side (node.js). I completely agree with everything here -- it's a great summary, and it describes exactly while I never, ever want to use it again.

In CoffeeScript, ambiguous code is the rule, not the exception. On top of that, things like variable capture and everything-returns-a-value introduce new kinds of bugs. The author says "realistically, the issues I have raised with CoffeeScript don’t come up every day," but in my experience they pretty much did.

But the real kicker on top of it all is that none of the stuff is documented. When you're trying to guess if you should use parentheses or a comma or an indent or a newline or a backslash or what, there are no reference documents to help you. The CoffeeScript home page just has a bunch of tutorial examples which give you an overall idea, but there's nothing rigorous, and the devil is in the details when you start combining aspects of the syntax.

In the end, I'm much more productive programming in JavaScript because I know exactly how the language works, no surprises. JavaScript has its fair share of warts, but you take a day or two to learn them, and then you never need to worry about them again. CoffeeScript, on the other hand, is just endless surprises. And I still felt that way after a whole year of using it at work. It's basically unlearnable -- no matter how much experience you have, you constantly find yourself pasting different versions of a line into the "try" tab of http://coffeescript.org/ until you get one which, through trial and error, turns into the JavaScript code you want.
i would argue that clojure is very successful
i think (probably more like a statment of obvious) language success depends equally on the libraries available for it

clojure have a lot of libraries, and leiningen

and echo the "worse is better" slogan
i think that languages that offer a little more feature above the current mainstream languages, will success more than languages that offer a lot more

most programmers are doers, they prefer to spend more time doing rather than learning

languages that are too smart ... are less likely to succeed
not until the day ... they become only a little bit better than the mainstream

we move slowly from c to c++ to java to ruby ...
the next big language is one that is only a little bit better than ruby ... not a lot better

i think clojure fit the bill
It reconciles by coping.

It's better to deal with the harsh reality of peaceful commerce than it is to continually mold an economy with abysmal, suppressive, artificial constraints. Such laws are overwhelmingly wielded by large corporations: groups of protected people who afford patent war chests, suck up the relatively small patents "of the little guy," who gladly suffer constraints, and whose dominion grows parasitically with every law they bend in their direction.

The answer for "incentivizing" progress has no clear path. But I know it should lie elsewhere from this current one, if we're to ever set our courses ethically. It must consist of peace. Peace means not using violence and not caging people just to mold corporate will. Incentives exist on one side. Many people are naturally driven to learn, research, create, and discover.

On the other side, that doesn't solve the economic drivers that act as a backbone. Obviously, that's where your question is focused. Given less control by corporations, I imagine time-to-market, mover advantage, and trade recognition would still be enough to create a very fertile economy. It would hardly lack in the catalysts that dive manufacturing and profit-based prospects and motives. I'd argue that it would increase those conditions beyond just the net-health increase of market access. The major difference would be an economy that becomes more decentralized with fewer mega-corporations and more p2p trade. The pace of drug design would not necessarily slow. Motives and rewards behind drug design would nevertheless change and certain aspects of that would slow.

I'm more sympathetic to trademark IP. Trademarks were a helpful stopgap against fraud in the evolution of the US economy. Yet, trademarks as we know them today could be logically disbanded in the future if the means which which to prove identities and dates of creation become more solidified into everyday life. Certain aspects of enforcement would probably linger on for consumer protection (e.g. selling exact, branded replicas of a product would be prohibited in areas where true confusion is likely to occur). I believe most people want to reward people and businesses who take chances, act transparently, and serve quality products and services, the more that information becomes readily flowing. Likewise, I believe most people want to disfavor the people who act fraudulently (presenting the works of others as their own).

Ultimately, I'd rather society cope with the human potential that occurs without the limitations of patents, rather than society coping with the human potential that occurs with the limitations of patents. This philosophy may or may not lead to more net gains superficially. However, I think it leads to more gains rationally and ethically.
Class hierarchies are easily fragile, easily do not model things correctly over time.

The cruft, the lack of DRY as the mapping between what is being modeled and what is represented in the code -- accumulates with class hierarchies for sure.

But the idea of inheritance and tree structures has been around and strong for the past 50 years -- not because people are inherently lazy -- but because it models something very primitive about programming: the evolutionary nature of development and thinking.

This is extremely non-mathematical, but extremely non-trivial.

Tree structures (and by extension 'hierarchies') are perhaps the most fundamental way to organize data. There is nothing more sophisticated than a tree search -- it is the basis of all exponential / efficient access times and all knowledge and organization of memory. It's why evolution proceeds in tree structures. We organize data in our mind in tree structures. Life over millennia organizes itself in tree structures.

I'm sad to report that the world will not quickly become clear and abstract and orthogonal a la Haskell or other pure languages. Knowledge, life, everything proceeds via evolution, not something a priori. The sooner one really accepts that, the sooner one has new ways to interface with this reality more practically and effectively.

People sometimes make the point of use the right tool for the job - as a reason for still using OOP, etc. I'd not say that -- but that the right tool for the job where the job is an evolving code base is actually something object-oriented with inheritance. Except where the domain is very precise and known ahead of time. Otherwise, the manner in which it models evolution is actually quite useful (despite the fragility of inheritance and the quick ability to spin out of any orthogonal clarity).

People who program purely in Clojure or Haskell put the burden of this evolution in their own development as a programmer (there is no extension, there is just clarity and then rewrite). That's ok. People who use Java or whatever in the enterprise because it's easier for other people to get on board with it -- put the burden in the code. But the cost of modeling a problem that evolves goes somewhere.
What about something like Java's `AbstractList` and `AbstractSet`? These save you a lot of typing when implementing the huge `List` and `Set` interfaces.
It is not historically inaccurate, it's encoded in the name of the damn thing. The patent system predates the creation of the United States, and its spirit is more than the ambiguous summary of "to promote progress".

The history of patents is long, but Queen Anne's statute is where the the nature of disclosing trade secrets was formalised:

http://www.ipo.gov.uk/types/patent/p-about/p-whatis/p-histor...
Not really bashing Go, but I was was disappointed that for what is purportedly a 'systems programming language', performance was far behind C/C++/D/Mars/etc. I expect a little more from a statically ahead-of-time compiled language.

For 80% of apps, that's just fine, but would you write a mobile web browser in Go, or say, Call of Duty? Seems you'd be leaving 50% performance on the table in some scenarios.

I tend to give 'systems programming language' special status. They're how you achieve maximum system performance if not writing in assembly. You write kernels, device drivers, virtual machines, and games in them. If they are imposing severe performance or memory overhead, then they are application programming languages, not systems programming languages.
Response to Edit2: You are right here too. Just that not thinking through brings a risk of making wrong decisions, which I think could be the case in this case. I am not 100% convinced that software patents should be abolished without understanding the criteria on the basis of which they should be (which may then apply to other fields also, but may not).