skysight-inc/HackerNews huggingface dataset:
> You could argue that it should not be this way, but it is.

Indeed it is. State facts, back up what you say with evidence, get downvoted. As certain as sunrise.

> If the first table of numbers gets downvotes posting the same table again without more information is going to get the same downvotes.

The alternative is to adopt the standards of religion instead of science. In religion, if you start losing followers, you change the mythology. In science, evidence is evidence, and how people feel about it has no standing.

> When you get a downvote, ignore it. It's probably accidental or meaningless ...

Easily proven false. My downvotes inevitably accompany anything I post that has evidence and/or links to references. If I offer an uncorroborated opinion or philosophical remark, however irrelevant or baseless, it's treated neutrally. This is how science works -- you observe things dispassionately and don't let yourself to be swayed by what people think is true.
For me the division is mostly centered on quality.

The sales I'm working with want me to ship whatever, ship fast.

I want to ship quality.

Since money always wins, this usually ends with me giving in, feeling bad about it and .. blaming the sales people for being short-sighted/focused on the immediate return only.
I believe Microsoft's file extensions and the 8.3 naming scheme are descended from Digital's 6.3 naming in VMS, RT-11, etc. DEC even used a number of the same extensions: EXE, COM, OBJ. Not sure where they came from prior to that. I don't think IBM used file extensions like that in System/360, System/32, or anything prior to PC-DOS. From what I can tell, Burroughs and Univac didn't use them either.
There are ways to lose your trademarks if you use them or simply allow them to be used in the wrong contexts. I think their competitors would argue that this is one of those ways.
Is this maybe the modern version of Fermat’s Last Theorem?

“I have written a truly marvellous program to do this, but I have not yet had time to finish the documentation.”
A real number of repair attempts
What exactly is considered to be a real number of repair attempts will depend on the conditions including the seriousness of the defect of your vehicle. For instance, one or two repair attempts may be considered as reasonable for serious safety defects such as brake failure, depending on the given situation.
More information on calemonlawinfo.com
One of the cases the MatterNet folks are considering is the rapid movement of medical samples from, eg a mobile clinic to a central laboratory.

It has the added advantage of being high-importance but low-cash-value, reducing any incentive from (hypothetical) drone-nappers and making the experience a positive one for the general public in the area of operation.
I believe it's largely down to short term goals versus long term goals.

From the business perspective, the company should do things quickly because that means the jobs are more profitable, cashflow is stable, and the business team believe that they can always find more clients even if the product is horrible. This is the short term outlook.

From the programmers perspective the company should do things slowly because that leads to more maintainable software, less technical debt, and higher quality products with fewer faults. Less money comes in, but the clients stick around for the quality goods. This is the long term outlook.

The thing that leads a company to fail is when neither side recognises is that both outlooks are wrong. You can't run a company churning out bad code forever because your technical team get annoyed and leave, but equally you can't build things forever because clients don't have unlimited money.

There is a balance. If one or both sides don't understand that then the business is not going to work well - it'll churn through developers or it'll never make much money.

If you find a job at a company that recognises the problem and attempts to resolve it you will be happy as a developer.
Maybe it's my ugly mug or the particular type of content that I serve, but having authorship markup drove my traffic down 1/3rd. I'm happy to see it go.
The 29 is a temporary insane asylum
Israel becomes latest country to try to ban Secret bullying app
What helps me a lot is listening to audiobooks I have already listened to. I find for example the Harry Potter audiobooks narrated by Stephen Fry comforting and relaxing.
> Maybe there should be a way to summarise null findings, to stop people replicating unsuccessful or unfounded work.

But repeating failed experiments has the same scientific value as repeating successful ones -- it solidifies the result, increase our certainly about it.

In real science, null results, and their replication, are extremely important. My favorite example is the Michelson-Morley experiment that expected to find differences in the speed of light due to the motion of the earth through the hypothetical ether.

The failure of this experiment, its publication, and efforts to replicate the result, also dutifully published, finally created a revolution in physics when Einstein explained why there was a null result, and coincidentally gave birth to the modern world.
One of the worst infographics ever, but people don’t care?
The question is: is it really cheaper to run and maintain your own custom stack/server network, than getting these guys to do it, when you factor in the amount of time it takes/hiring staff, etc?
> The only reason for tilt-rotors is when you need to keep the main body of the aircraft level.

Actually, a tilt-rotor can be manipulated to make the aircraft go where you want it to. The same idea explains how helicopters make their way across the landscape.
bad code forever because your technical team get annoyed and leave

And the effects of technical debt and bad code will eventually result in slow iteration and poor product quality which will eventually become visible to customers.
I really don't mind about the packaging system, I think that the meteor team should put special emphasis in solving the scalability issues, cos right now (IMO) is the major barrier for adoption.

I find really useful all the features they're launching but there's no way I'm going to pay for a 8Gb and quadcore server just for supporting 100 concurrent visitors...

I started building a real-time webapp with meteor and had to switch to express + primus which was a much more efficient solution (orders of magnitude).

I really hope they do something about it ASAP... I really enjoyed working with meteor and still use for small projects, but for a medium/big app? not yet...
My village is in Muzaffarpur district of Bihar. We grow leeche nuts and mangoes :)
Call up a squadron of K-Max's with a suspended water bucket and that's a very interesting experiment.

Small electric stuff will be limited by charging infrastructure and plain availability; it'd be fun to see a future where various commercial swarms exist and they're taken over for disaster relief.

"Hey, where's my burrito?"

"Sorry sir, all our BurritoCopters[tm] are attending the San Bernardino Valley Fire at the moment, per civic ordinance K-34. Your burrito's right here if you want to collect."
IBM Announces Watson Discovery Advisor
For REST APIs, writing the database queries are easy enough; and, often less painful than trying to figure out an API. I don't know of any Rails app that hasn't required some amount of custom queries. When you consider that the most coupled endpoints just require a few joins/group by's/nested function queries, writing the rest of the queries takes only as long as it takes you to type a few sentences.

You could easily have a Database type which offers a few methods (e.g. Do(), Query(), &Result) and export a map of these for each resource. Keeping track and reasoning about these is easy if you clean up and break up your monolithic app into packages.
As a customer in Germany, I find them on almost every international order form.

As a recent example, see KanbanFlow for example https://sites.fastspring.com/kanbanflow/order/customer

The "Zip code" input field is simply hard coded for every country.
Translation: you didn't understand what he said, but still couldn't refrain from a snarky reply.

Sublime renders the sidebar itself, and doesn't rely on whatever UI toolkit the user has installed
Something to keep in mind about quality - sometimes programmers spend ages doing something in a way that seems like the right way, and the end result is either unimpressive, or a disaster. That destroys goodwill.

A project manager who had a history of working with unreliable developers may be drawn to a mindset of only trusting near wins, or even distrusting elegance-based arguments.
"Oh, East is East, and West is West, and never the twain shall meet."
Rudyard Kipling

Jokes aside, I think the OP is generalizing. Personally I get on fine with the vast majority of business people.

I don't get on with people that are incompetent. I also don't get on with people who have a lot to learn but pretend they don't. Some of those are business people. Some of them are fellow programmers.

Normally business people (sales) have features in mind that they know (or think) customers want. Customers often think they want something to deliver a business process that solves a particular problem, but might not be the most efficient process. Programmers are concerned with the management and control of their code-base. Often programmers cannot see the financial or business case for a new feature request. In many cases, it isn't really their job to do so, but it does help to understand the requirement.

As a result the two parties often have problems seeing eye to eye. However, this is a good thing. If we agreed with everything business people wanted then we'd have applications full of features, many of which nobody wanted. If programmers got their way then we'd have applications that no clients would want to use and buy.

In general each party has a niche of knowledge that the others don't. When each party can learn to appreciate the experience and knowledge of the others, then they can work together successfully.
Well, I think this illustrates the situation somewhat well (if you think the conspiracy theorists in the west are nuts...): http://thecolbertreport.cc.com/videos/1872w0/julia-ioffe

If you want a more official position, google site:rt.com mh17 and you'll find lots of articles. I'll leave it for the reader to judge their presentation of the situation.
That was my point. Natsu was worrying about the ability of a technological civilization to function near the heat death of the universe. Which is much further than 5-6 billion years away. A more "immediate" problem is the death of our own Sun.

Of course, what you say is even more immediate.
"Any effectively generated theory capable of expressing elementary arithmetic cannot be both consistent and complete. In particular, for any consistent, effectively generated formal theory that proves certain basic arithmetic truths, there is an arithmetical statement that is true, but not provable in the theory" - Gödel (Kleene)
> Funnily enough, a lot of Java code does what the Go code did: it mocks by defining interfaces and then attaching either production or mock code as required. See SpringMVC for an example.

I actually support this; I just think it's worth being explicit about the relationship between interface and implementation. The difference between Camera.shoot() and Gun.shoot() can be important, and when you want to upgrade a library you need to know what you're implementing. In Java you have extends and @Override to give you a straightforward compile error when a parent interface changes, which makes library upgrades relatively painless. I fear the Go approach gives you the worst of both worlds - the extra typing of a Java-style explicit interface declaration, but no more safety than a Rails upgrade.

> Why? Because Java mocking libraries aren't perfect either. If you're using an injection framework, it tends to be trickier to arrange the injection of the right object in the right place and when you don't, the breakages tend to be mysterious.

I don't think you're comparing like with like. If you're using an injection framework in Go, you'll have the same difficulty injecting and mysterious failures when you get it wrong. There's no need to throw the Java baby out with the Spring bathwater.

> Then you get into the exciting world of bytecode manipulation, which is necessary for some mocking libraries.
> And, most annoyingly, it's basically impossible to mock static methods.

On the contrary, the whole point of bytecode manipulation is that it lets you mock static methods (or undeclared interfaces) - you don't need it otherwise. Is mocking statics any easier in Go? If Go simply doesn't let you have statics, that's not really a Go advantage - you can (and I would argue should) program without statics in Java 99% of the time, but they're there for when you really need them.
Doing things right often sounds more complicated.

Business people who don't take the time to listen and understand what they're managing will pick what sounds like the path of least resistance.

If the buisness people cannot be reasoned with this will result in staff not telling them what they're really spending their time on.

At this point management either a) steps back or b) buckles down and micromanages.

Results:
a) Unless there is some internal leadership within the team or you have rather good and motivated people, this will result in the team doing what they want, which will mostly be CV-Driven-Development or playing with the new shiney.

b) Important steps will be skipped, likely the team will feel the decisions are made outwith the group, yet the group suffers from the results of said decisions. Moral of the team will go down.

This isn't specific to programmers, any time you get management that's willing to bury their head in the sand and not understand their subject matter, you've got this problem. Team performance will go down and if this results in rotating non-technical management who all end up going down this road, you'll breed programmers that simply think all managers are useless.

This is the with career managers. The problem with technical managers is they often simply don't know how to manage. You want someone who can do both and who actually cares about delivering value to whomever your customer might be.
Can't you just disable it? I thought it was opt-in.
Asperger's is gone, and not lamented.

http://www.nytimes.com/2009/11/03/health/03asperger.html?pag...
I can attest this. For the rest of the year documentaries make the trick as well.
But the solution you objected to is perfectly fair. How is yours more scientific?
JHades In a Nutshell - JHades is a tool that helps troubleshooting classpath problems. The main features are:

-Duplicate classes detection: a command line tool list duplicate classes in a WAR, and allows filtering 'harmless' duplicates
-Runtime classpath debugging: a utility class exists to query the classpath at runtime for details on the class loader chain, jars, hidden class files, etc.
-Server startup troubleshooting: jHades works works well in scenarios where the server does not even start
How about a "drone pony express" where carrier has a bunch of intermediate stations within range of each other based on the drone's capability; the package is handed off from the "tired" drone to the the "fresh" drone, and the "tired" drone is hooked up to a charging station.
Hack the p tag
Many can. And they're the ones who make a lot of money, especially if they're consultants who align with the goals of the business. I think patio11 has written on this topic several times.
In Defense of the Knee Defender
Haven't seen the talk, but that wasn't my experience after working for a VoIP provider. Being your own operator you publish whatever number you want and customers are in charge of putting their correct address for use by the emergency services. For services where you intend to keep all the right information, this call can be still tracked later on. But there are providers who don't care.

Basically at each hop they would have to rely on that hop playing nicely or you can't get more info.
It's a very complicated topic. I'd recommend spending some time on http://blackboxvoting.org/
Not quite free, includes in app purchases.
The other half of the answer to this problem is to favor small interfaces, ideally a single method. For example, a UserStore interface could be quite large, but if it's composed of UserCreator, UserUpdater, UserFinder, and UserDestroyer subinterfaces, then you can easily arrange to only use the small, task specific, interface.

Agreed that it's all quite a bit more of a pain than using a serious mocking toolkit, though changes in testing practices and API design help substantially.
I think you're being very optimistic about programmer motivations, to be honest.

> From the programmers perspective the company should do things slowly because that leads to more maintainable software, less technical debt, and higher quality products with fewer faults. Less money comes in, but the clients stick around for the quality goods. This is the long term outlook.

This is the good version. But as we all know, to some extent these factors play a role too :

1) programmers have lost the battle with the software's complexity, but are fighting to retain control of it. This can also be a manager.

2) programmers have invested in certain technical decisions (a programming language, framework, ... whatever) and are unwilling to consider swapping it out, even when it's obsolete

(We all have seen the database product used in large firms that started life as a windows application, and has "moved to the web". Instead of writing a web interface, these fine people have written something like a VNC server that runs the actual application, and a JavaScript client that just downloads the pixels, and sends mouse events to the server. Sigh)

3) Programmers are trying to solve an "interesting technical challenge" that they DO NOT HAVE. An example would be a datacenter management solution for a webhosting company. Automated failover, globally distributed RPC, horizontally scalable load balancers, nosql replicated datastores ... That's great if it takes 10% of their time (because every now and then, they do build a great system), it's a disaster if it takes 90% of their time. But since it is so much more interesting than solving customer 1538's problem with the current reporting system ...

4) programmers have formed a clique, and are "going for job security"

Given the organisations most programmers work in, I feel sympathy for people using factors like this. We all know how responsible banks' management is, so I do not think doing any of the above against them even approaches immoral actions.

But what I'd like to state is that as a young programmer, or project manager, approaching problems in large companies without looking for the above factors is likely to result in disaster.
Stephen Hawking: Philosophy is dead.

Lawrence Krauss: Philosophy used to be a field that had content, but then 'natural philosophy' became physics, and physics has only continued to make inroads. Every time there's a leap in physics, it encroaches on these areas that philosophers have carefully sequestered away to themselves, and so then you have this natural resentment on the part of philosophers.

Neil Tyson DeGrasse: Up until early 20th century philosophers had material contributions to make to the physical sciences. Pretty much after quantum mechanics, remember the philosopher is the would be scientist but without a laboratory, right? And so what happens is, the 1920s come in, we learn about the expanding universe in the same decade as we learn about quantum physics, each of which falls so far out of what you can deduce from your armchair that the whole community of philosophers that previously had added materially to the thinking of the physical scientists was rendered essentially obsolete, and that point, and I have yet to see a contribution — this will get me in trouble with all manner of philosophers — but call me later and correct me if you think I’ve missed somebody here. But, philosophy has basically parted ways from the frontier of the physical sciences, when there was a day when they were one and the same. Isaac Newton was a natural philosopher, the word physicist didn’t even exist in any important way back then. So, I’m disappointed because there is a lot of brainpower there, that might have otherwise contributed mightily, but today simply does not. It’s not that there can’t be other philosophical subjects, there is religious philosophy, and ethical philosophy, and political philosophy, plenty of stuff for the philosophers to do, but the frontier of the physical sciences does not appear to be among them.
kind of like payday loans?
Since my background is poker, I'll use an (overly simplified) example from there.

There are situations where you want to manipulate your range (set of hands) in a given spot so that your actions make up a certain distribution.

For example, if you want your range to be made up of 30% bluffs, you can figure out how often you get to that spot with a bluff and how often you get to that spot with a strong hand. Since you're always continuing with the strong hand, you can then know what percentage of the time you need to continue to bluff in order to accomplish this. Since it doesn't matter which of those hands you choose to bluff with, it generally makes sense to use randomness to decide in the moment.
Projeto E Implementação de Sistemas de Drenagem Sustentáveis Em Londres
> Translation: you didn't understand what he said ...

I understood him perfectly. He said, "Is anyone else seeing a strange issue on Linux where the sidebar doesn't toggle open/close folders correctly?" That's not Linux, and because there's more than one desktop environment in common use, the OP needed to identify what he was referring to. He speaks as though everyone who runs Linux uses the same desktop environment.

> and doesn't rely on whatever UI toolkit the user has installed

Locate my use of the word "toolkit". I said "desktop environment". Linux is not a desktop environment -- that's something that, among other properties, has sidebars.
you were not elegant or polite, but are in fact correct
Man I would hate to be the ST devs. Everyone keeps calling it stalled, dead, etc. Not sure what release speed would make the difference to commenters here.

Are there lots of unfixed bugs or something? I am just missing the source of this consensus.
Chartist – Simple responsive charts
Dont forgot that the java mocking you are proposing requires JMockit, which in turn requires Reflection, and requires you to understand how JMockIt actually works... There is a lot of bookkeeping.

In the go example, its just pure core go language, nothing more is needed todo the mocking. In my opinion the go example is a lot simpler than the java example that requires a big mocking framework.

Not to forget, that in go, you can implement interfaces around a simple type such as a int, yes a simple int can implement a whole interface. And there is no explicit bookkeeping needed
>While this is a noble goal, when someone is building a new API or project, it's often impractical to commit to building an entire, full featured data layer in the process

Thats why I mentioned this approach over an ORM for a high performance API / high value API. If you need something quick and dirty, do it the quick and dirty way after all. Although if you have written a lot of these, its not really so bad.
My comment about Android was all about market share and nothing about the quality.
I do not understand why is anyone buying machines with pods. Expensive machine, expensive coffee, and creating garbage for each cup.

Is it so hard to put teaspoon of coffee in cup and pour hot water?
VR Coaster
Well sublime text supports textmate snippets, and so does lime... It's a start.