skysight-inc/HackerNews huggingface dataset:
> Whether that was generally understood 70 years ago is neither here nor there.

That's some handwaving.

Again, your argument looks at it with present eyes.
To clarify: the $50 is a direct donation to Fight for the Future, the non-profit organization behind Bitcoin Black Friday (http://www.bitcoinblackfriday.com/), and the t-shirt is just a donation reward!
Some very interesting features of Nimrod which I would like to emphasize:

- clean Pythonic syntax (whitespace relevant but tabs are forbidden)

- native Perl syntax for regular expressions (slide 42)

- subrange types as in Ada

- set types as in Pascal

- strings as case (switch) selectors

- easy C interface with automatic type conversion (only functions as parameters need additional compiler pragmas)

- typed macros (templates)

- object code: native, C, Javascript (probably more to come)

I am working with Nimrod right now, and it is really one of the most productive languages that I ever encountered. It seems to mix the best features of other popular languages. Nimrod actually is where Python should be. I wonder if it is suitable for small embedded systems also.

By the way, one important difference to Perl regular expressions is that re"..." always parses the whole expression where Perl parses partially. Fortunately Perl's behavior can easily be simulated with a template.
Actually, in many countries it is really really hard to be allowed to do a study on a significant amount of animals due to animal rights groups, which have lobbied for committees who decide how many animals are allowed. Most times this number is way too low to do good science (numbers like 16 -- 8 main and 8 control mice, are not uncommon).
Same! And I'm sure the reason it didn't take that long with getting good at it, was it hurts like hell when you do the 33% thing on a couple large projects, when you're on your own.
Our experiences obviously differ. Usually it goes like this - the developer gives his best estimate (which is, by the way, hard by itself - a lot of things has to be taken into account), and that estimate is considered too high. So the developer is ordered - in one form or another - to, effectively, "do it faster". Often it's by cutting corners in places deemed least important - but then it also reduces probability of the correct estimate overall. One more thing - specifications are quite rarely are good enough - there are other reasons why that's the case - and the final result causes management to wonder, why it doesn't include this, of why that works this clumsy way. So nobody's happy - and developer pays the price. It may look as the developer isn't good at writing software... because "writing software" is a sort of encompassing figure.
I try to do my estimates (team size, man-days) in Big-O notation. Haven't nailed how to do that yet, but it helps people understand that estimates are non-linear functions.
How radioactive poison became the assassin’s weapon of choice
> Management giving estimates? No thanks.

This is actually achievable in a sane way.

I have done it using the XP planning practices. Basically, you make the suit break everything down into relatively small lumps and place them in priority order. Every week, the team completes a few lumps. Before you do them, engineers grade their relative complexity in arbitrary units. (The smallest substantial thing you do is 1 point; something twice as big is 2 points, and so on.) Every week, you count up the points completed. That's your "velocity".

From there, you let managers do all the estimating they want to. If they want the complexity of a unit of work measured, they ask the engineers. If they want to know when X will be done, they look at the team's recent velocity, what's in the queue before X, and do some basic math.

The nice part about this is the mental judo involved. Whenever they want to know when something will be done, it's their problem to trade features against time. Working like this, it's not geeks vs suits; the suits channel their schedule pressure into productive work: grooming the backlog.
I, too, would be interested in seeing these. Here are some guidelines from somebody else that I found helpful, though:

http://www.missionfamilybank.org/software-estimating/
You might want to read about Dynamo:

http://www.hpl.hp.com/techreports/1999/HPL-1999-78.pdf

"Contrary to intuition, we demonstrate that it is possible to use a piece of software to improve the performance of a native, statically optimized program binary, while it is executing. Dynamo not only speeds up real application programs, its performance improvement is often quite significant."
I can't believe you like money too! We should hang out.
The hiking analogy works pretty well, extended to traveling in general.

I spent a couple of years traveling around to visit friends and family all over the US, and regularly my estimates were off in when I'd arrive somewhere. My software delivery estimates are similarly not perfect, in the later direction like most people.
My conclusion was that my estimation of how long it takes to do anything is off a bit. For me, this is because I'm trying to say I'll do something sooner to meet the perceived needs and desires of others.
For embedded use it's probably ok, anywhere C is ok. It statically links the bits of the stdlib you use but dead code elimination seems to work pretty well.

A simple word counting script I just wrote compiles down to about 52k on 64bit OS X.

(Src: https://gist.github.com/tylereaves/7711302)
You must have good customers then that value quality software over meeting deadlines. Not government I take it?!
Doesn't matter.. Even if he would, most low level stuff would be almost equal (like the assembly generated) or at least very similar. Yes both are different compilers and do some things different (vtables/stack layout for instance if I remember correctly), but in the end if you know how the assembly generated from one works you'll have no problem understanding the other one. Besides, the screenshots from VS's mixed source/asm debugging do look nice and are really clear and helpfu for beginners.
It is morally justifiable to use nuclear weapons. If a country decides to be peaceful and not have an active army, airforce, and navy; but retains a stockpile of nuclear weapons, is it morally unjustifiable to strike an invading fleet with atomic bombs?

The whole point behind MAD is to show that you refuse to play the game of "I have the bigger army" and to literally level the playing field by making the game lose-lose.
I believe the JS target is considered a bit of a demo/toy - e.g. large swathes of the stdlib are unavailable.
What I think a lot of people are missing when comparing bitcoin to the dot-com bubble is that while it was followed by a spectacular crash, not only did the internet 'succeed' anyways, just later, a whole bunch of companies succeeded right along with it.

I think there's a big crash coming, but I think that won't say much about the long-term success of bitcoin. The most likely case I see for bitcoin failing is that it's replaced by another cryptocurrency, and that's still great in my book.

(I got my original investment back with btc to spare, so thankfully my finances will be unaffected either way)
Sounds an awful lot like this, which is probably what it would evolve into.

http://en.wikipedia.org/wiki/Guild#Medieval_guild
Alternate title: News From Nothing, Pageviews Please!
On a related note, Michael Drogalis has done great work developing Dire, which now works with Slingshot. Slingshot allows for a great deal of information to be passed along with what would be exception messages, and Dire brings something like Erlang style supervisor trees to Clojure:

https://github.com/MichaelDrogalis/dire

I do think the combination of Slingshot and Dire gives Clojure something similar to the condition handling system of Common Lisp. If you don't know about Common Lisp's condition system, you really should read this:

http://www.gigamonkeys.com/book/beyond-exception-handling-co...
Those cases are US cases. Given this thread concerns UK law, it might be better to find equivalent UK cases that establish this. (Indeed, the lack of previous UK cases is why the threads link is so notable)
D's scope statement in C++
That is completely incorrect. If a piece of software is licensed under the GPL or the MIT, you have the right to use it for any purpose. If it didn't, it wouldn't meet the free software definition, nor the open source definition.
The problem is that people try to eliminate uncertainty instead of trying to manage it effectively. If you're trying to make estimates with more than order-of-magnitude precision, then you're probably doing something wrong.

If we drove cars like we develop software, we would pre-calculate a list of instructions, set a timer, and then execute those instructions without regard to what's actually happening on the road. With practice, you could probably get better at making those lists of instructions, but why bother? The general approach is just ridiculous.

Decades of experience have shown that there is enough inherent uncertainty in software development that trying to plan everything from the start just doesn't have a high success rate. Even if you know everything that has to be done today to get the job done, your environment will change, and your stakeholders will change their minds. What good is software that perfectly solves the problem you had two years ago?

Once you dig through all of the buzzwords, "Agile software development" is simply about applying closed-loop control theory to software development: You structure your project to provide high visibility and to allow frequent changes in direction, then you iterate and make adjustments until the result is satisfactory.

Everything else generates unnecessary risks that somebody ends up paying for.
What do you mean by "Nimrod is where Python should be"? The two languages are aimed at very different use cases.
A GC with a deadline is what caught my attention, seemingly can specify a max pause time (in ms) and GC wont' take longer than that. That is very good for soft realtime stuff -- games, audio processing.

Also, Nimrod has a very nice library. Definitely has enough "batteries" in it to get started.

http://nimrod-lang.org/lib.html

Just a few impressive ones: http client, server, json parsing, actor support, redis db driver, zmq, cairo graphics, OpenGL wrappers, even Lua and Python support.

That looks very appealing, anyone using, what is your experience with it?
This is very true, and I can attest to it from personal experience.

I grew up in Redmond Washington, in the heart of Microsoft - land, surrounded by programming and programmers. I learned a lot of the mental meta-skills that go hand in hand with programming, but I didn't ever learn to program, even though I thought it interesting and I wanted to understand it.

It was a challenge to even know what I wanted to know, and there wasn't anyone around to answer my "but how, and why?" questions to begin learning. It took till I was in college for me to start learning to program, because I had excellent professors who would answer my questions for literally hours. As well, I finally had problems that needed solving (if for no other reason than I needed to turn them in).
First of all, don't overly aggrandize what we do. 99% of it is derivative in most ways. Although I've enjoyed doing the work on many of my projects, I'm not under any illusions that what I was doing was ground-breaking.

Besides, most of the things you mention can be accounted for. If part of your development process involves iterating through the design with the customer every couple of weeks then you build that into your estimates.

Likewise, I always build documentation and code handover support into any serious project rather than acting surprised that customers will want such a thing and expect it to be part of what I'm delivering.
I'm gently surprised that people aren't looking at all the other terrible privacy policies and laws in the US.

NSA spying is terrible, and must stop, but many companies slurp way too much data, and store it sloppily. Look at the number of password database leaks, and that's stuff that they want to keep secret.

The lack of sensible privacy regulation has already caused many companies to not send data to the US.
I don't know anything about the legal and contractual aspects here (that stuff is mostly secret anyhow), but I would be shocked if they did not use Google's code to do this. To not do so would mean reimplementing Dalvik and all the Android infrastructure libraries. That's a huge, huge amount of code, and it would need to be bug-for-bug compatible with actual Android code. Instead, forking it is far more practical (if still hard).
That's not bad estimating though. That's psychopathic management. The developer gives an estimate which is "too long" for the manager, who responds by essentially ignoring the estimate and laying down arbitrary deadlines. Surprise, surprise the arbitrary deadlines are missed, and the psychopathic manager blames the developer.

The developer's ability to estimate accurately is not an significant factor in this scenario.
European Parliament Culls Public Wi-Fi Access After Email Hack
> Our own Senator Feinstein regularly votes against the interests of Silicon Valley

So when are you (plural you) going to put your money and your time where your mouths are and find someone to challenge her, including in the primaries?
You're probably losing more business than you think - customers have no idea who is accurate or who is just faster, etc. They will generally go with the lowest quote regardless of other factors unless they've been burned before multiple times. Most people haven't.

I don't have a solution here though other than noticing that underbidding and then getting skilled at convincing clients to do paid extensions later actually appears to make the most money at the cost of your ethics. I'd avoid that approach, but it does seem to work for a lot of companies.

My personal approach is to quote for very bare projects with only the bare essentials (eg, poor UI design, minimum possible feature for the client to see what they're asking for, etc). This can usually be done a lot cheaper than most people think as 90% of the work is in the last 20% of the features. Then once the client has something, you can give them a quote to touch up the parts they need. Basically you split the project up into many small projects each with their own quote which helps you to estimate tasks as they appear and helps your client to minimize costs by leaving off features that are more expensive than they initially appear.
http://en.m.wikipedia.org/wiki/Planning_fallacy
This is not really open. Where are the ASIC design files?
Disable the legal apparatuses that these institutions derive the legitimacy of their actions from so we aren't enabling the next set of abusers after we take the current one out. That means stricter regulations of privacy and information security in both public and private sectors, along with transparency reforms.
> I can't use the Amazon cloud, can't use App engine, Cloudflare or anything that is connected to the US or companies with a US mother firm.

But is that because of NSA spying, or because of the lack of privacy laws in the US? Because I know people who've not sent any user data to the US for years, certainly before they found out about NSA spying.
The single biggest mistake in the example is giving an estimate for the whole project without knowing team velocity.

I'm inclined to agree. Often though a client will want an estimate (to a ridiculous accuracy) before agreeing to the work. Unless you churn out web page templates or something equally repetitive it's hard to have that relevant velocity.

I still come up against client managers that don't "believe" in Agile approaches too.
What do you think about emailing? How you email to your user?
Reviving an ancient university through corporate sponsored free education
It's deferred reference counting, so the 1-2ms claim is perfectly reasonable because all it has to scan is the stack (though if they want to break cycles they will have to do something costlier). The downsides are all of the downsides of reference counting, plus the fact that last I looked Nimrod's GC is not thread safe. That last one is a huge downside IMHO. I think DRC is interesting but I'm not much of a fan of it, honestly: it doesn't solve the big downsides of RC (cycles and thread safety being super expensive) while giving up RC's biggest advantage (prompt reclamation).
Well that's what I get for jumping to another book halfway through one.
I got decorators a couple of chapters into Vol 2, I have no idea how the contents slipped my mind!
Anywho, the quality remains top notch! :)
I find it strange people are willing to buy things with BitCoin in general. It's like purchasing something with stock options of company which is rocketing up in (speculated) value. Vendors are obviously VERY interested in accepting BitCoin right now because they keep on earning money after the goods are sold. Wouldn't vendors immediately stop accepting it if the BC charts showed even a small decline in the BC value over a period of time? How about if it flat-lined?
For those like me who didn't quite understand, STB stands for set - top box.

Also, that's a pretty cool story actually!
This is hyperbole. Yes, there is a small number of large corporations which have a lot of users. But the infrastructure of the Internet is still there, and is largely as unregulated as it ever was. It's just that it has become less visible in the enormous mass of people who use the internet in a "simpler" way.
Tupac Shakur’s song “Changes” is on the Vatican playlist
How we turned a world record in journalism crowd-funding into a publication
Encrypted social network vies for disgruntled WhatsApp, Facebook users
I wholly agree with this, and feel that all project plans should be constructed to mitigate the very high risk of initial estimates.

Too many project processes treat estimates as commitments with no backup plan when they (inevitably) go awry. I think a better approach would be to design your system around the idea that all estimates are suspect until proven otherwise, which of course leads to iterative approaches etc.

However, you can't run a business without any idea when anything will ship. Estimation is still, in my view, a very necessary step, so long as there is significant incentive to get it right rather than get it fast, AND the business is receptive to a little ambiguity through the project life cycle. This is a very difficult balance to strike.

In my experience you can have certainty in project scope or time, but not both.
This reminds me of this scene from the movie Spaceballs; http://www.youtube.com/watch?v=a6iW-8xPw3k

It's how I imagine the commanders get the code.
That's pretty dark. Sounds like you might want to talk to someone...
Just try reading it on an iPad. It's an absolutely miserable experience. It feels like they tried to reimplement scrolling, which, of course, they get totally wrong.

It baffles me that companies spend significant amounts of time and resources making a user experience that works great rather awful[1].

[1] See also: Flickr.
http://www.myriadgroup.com/Press/News-2013/Myriad%20Powers%2...

It's independent from Google code.
This may actually predate capitalism. I know it was quite popular at least in some communist countries. For that reason alone I tend to oppose it outright. Communism was awful, at least for individuals and individual liberty. Capitalism may be far from perfect, but I don't think I'd prefer anything close to communism. You think the excuse "to protect you from terrorists" is being abused right now? You should've seen how much the "in the name of the people" excuse was being abused during communism. The terrorism excuse pales in comparison.
Yes, we're certainly inspired by Kanso.

PgREST was originally designed for a large, in-production Postgres app (i.e. Socialtext), so we can get all the model, validation, view & trigger code in one place, getting the benefits of CouchApps while maintaining the underlying data layer.

For new projects, the main difference is likely familiarity with the toolchain (npm+Pg vs Kanso+CouchDB).
I guess they are on a backup or misremembered - but examples are really easy to find on the net if you want them:

http://th.informatik.uni-mannheim.de/people/lucks/HashCollis...

http://www.win.tue.nl/hashclash/ChosenPrefixCollisions/ has a multicollision: 12 PDF files with different content and the same MD5 hash.
Things I've learned about hiring people in a startup
Software-development estimates are regularly off by a large margin for two reasons. First, the problem is inherently hard. Second, social and business pressures bias the estimates downward.

Why is the problem inherently hard? To see why, let's imagine that the All-Knowing Fairy Godmother of Software Estimation descends from the heavens and lends to us her magic estimating function F that, applied to any software project S, will tell us exactly how much time and money our preferred software team will consume to implement S. Don't worry about how F works, just believe that it does. (Okay, okay. Let's just say that F peers into a parallel universe in which our team has already implemented a software system line-for-line identical to S, and it just observes how much time and money were actually consumed in that universe. Anyway...)

Now that we have the magic F, our problem is easy, right? Nope. The real problem is that we don't know what S is. All we actually know is that our S, whatever it ends up being, must satisfy some set of fuzzy constraints C (commonly called "software requirements").

In truth, there are a countless number of possible values for S. In other words, S is a random variable, a mapping that ascribes a probability to each of the possible software systems that we could build to satisfy C. Therefore, our best estimate, even with the perfect estimating function F, is itself a random variable. In other words, it's not an estimate but a distribution of estimates.

See how fun this is getting?

But, wait, it gets funner. That's because people in the business world don't want a distribution of possibilities. They want a budget, a date on the calendar. So we must squeeze point estimates out of the true distribution. (And, remember, we don't even know what the true distribution is!)

That's where the second reason kicks in. Let's just think about the distribution of possible budgets for our distribution of possible values of S. Because S can range from "the simplest thing that could possibly satisfy C" to "the most insanely complex thing that a frighteningly gifted salesperson for an enterprise consulting firm could get our CIO to throw money at," that distribution is going to be w-i-d-e. From X to 10X wide.

So if we're the folks tasked with coming up with those point estimates, we could plausibly estimate X on the low end, or 10X on the high end, or anything in between. Guess which estimates are going to get us the most push-back from the higher-ups?

Now, we're swell guys and all, and we want to do a good job with our estimates. No question. But, still... We're human. If we think that giving a higher-end estimate is going to make us unpopular with the higher-ups, maybe we'll estimate a little lower. And when we get push-back on that estimate, maybe we'll "take another look at the numbers" to see if we "missed any opportunities."

And that's the old one-two. We start with a hard, fuzzy problem and then add to it the pressure to deliver only feel-good solutions. The result: estimates that are often way low.
What's your problem??
What problem do you often face ? What could make your life easier ? What do you think should be improved, or resolved in your city/country/world, at work, or outside work ?

I am an experienced web developer ready to do amazing things ; improve people's life, solving problems... so tell me about yours, and we'll see what can be done!
It's a bubble... it's going to burst. Now is a great time to be spending it.