The Programmers Before Us Were Better - <AUTHOR> http://www.jeremymorgan.com/blog/programming/the-programmers-before-us-were-better/ <comment><USER2> That's complete crap and merely a manifestation of "Rosy Retrospection" (<http://en.wikipedia.org/wiki/Rosy_retrospection>).

Monty Python made fun of this "in my time, you see" bullshit with the Four Yorkshiremen skit (<http://www.youtube.com/watch?v=Xe1a1wHxTyo>). Woody Allen's movie Midnight in Paris did the same (<http://en.wikipedia.org/wiki/Midnight_in_Paris>).

The programmers before us were the exact same as the programmers of today and they will be the exact same as the one's that come after us. The only difference between them is whose shoulders they stood upon and what they were be able to do using the tools at hand.

Programmers of the 60s were happy just to get things to add up. The guys in the 80s squealed with glee at GUIs. The guys in the 90s made the internet what it is today. And the guys of the 2010s will bring AI and robotics into the main stream.

Everyone glues things together - it's how creation works ([http://en.wikipedia.org/wiki/Steven_Johnson_(author)#Where_G...](http://en.wikipedia.org/wiki/Steven_Johnson_\(author\)#Where_Good_Ideas_Come_From)). The only difference between generations is the things you have available to glue together. Sometimes you glue together a stick and a rock to make a spear, and other times you glue together a machine gun, a camera, and a computer.

Either way - same people, different situations.

<comment><USER3> I do agree with you that people tend to glorify the past. I also agree with the author that it was way, way more difficult not even that long ago when you couldn't get answers by just typing into google. I think that did weed out most people from the occupation because you had to do a ton of reading (not to mention buying those expensive programming books!)

On the other hand you could say that I wasted a lot of time thinking about things that were inconsequential. Now I'm able to focus my attention on the true work rather than getting hung up on the minor details.

There are still problems to solve, they're just on a different layer for a lot of us. You might even say that because of all of our frameworks and libraries that our problems are even more complicated.

</comment></comment><comment><USER4> I'm not sure what I think of this. (I started programming around 1985.)

I don't think the older generation of programmers were any better than the younger generation in terms of skill. I think they were, generally, more _practical_ \-- they don't generally engage in language wars or programming evangelism, but when they do, they speak directly from a massive body of experience that's hard to argue with.

I think that the problems that they spent most of their time on were generally simpler. The most challenging bit of magic I ever worked on a mainframe was convincing COBOL to do variable interpolation on what was essentially punchcard-data-on-disk. (COBOL has no string operators or variable types, for those that are unfamiliar.) That was challenging, but it was a tiny problem in terms of scope compared to, say, building a scalable web application with a database backend.

I've worked with and hung out with greybeards, and generally prefer their company to that of hyperactive younger programmers. (For one thing, they don't talk about programming much!) They built things the same way we do -- by thinking about it and then banging it out one line at a time. They just used different tools.

Documentation was better back when. That's one thing I really don't appreciate about the Google Era; now, if I need information on some function or language feature, I usually end up reading some incomplete community-submitted documentation and a stack of opinions from people who may or may not know what they're talking about. For anybody that got to use those lovely old massive 3-ring binders (they came in sets!) with professionally-written and compiled in-depth documentation covering every single aspect of whatever you were using, there's just no modern replacement.

Otherwise, I don't really think the field of computer programming has fundamentally changed in all these years. The people are about the same. (Greenblatt was a pretty annoying, hyperactive young programmer once.) Some things are different. Some things aren't.

<comment><USER5> 1979 calling.

> Documentation was better back when.

When I started programming properly ('84, '85?) it began with being issued the full shelf of IBM 3060 manuals - and when I mean shelf, I mean 3 feet. All my reference material was for the version I was using - relevant, complete, practival. We used to say RTFM and we meant it, you had an M to RTF.

Lots of people hate on the Erlang documentation <http://www.erlang.org/doc/> but I love 'em, proper shelf, proper docos.

I am trying to write some HTML5/Javascript sound stuff and help is picking overcooked vegetables out of Google Soup - ech!

<comment><USER6> This times a million. Microsoft, OpenBSD and Golang are the only things I've found that produce good quality extensive reference documentation these days that I can take offline.

Python documentation, while extensive, is crappy.

I still miss my Sun Ultra enterprise 2. That was documented to bits.

<comment><USER7> To add to your list I like the PostgreSQL manuals. They always seem detailed and clear.

I find the Rails documentation awful lacking a lot of detail with an expectation that you read the source which in places is fairly hard to follow through several layers and even if you find the relevant part without good documentation you can't tell if it is a bug or intended behaviour in some cases.

<comment><USER6> Yes I probably should have added postgres. I like the fact that they keep the documentation nicely versioned as well. The quality is fantastic too.

</comment></comment></comment></comment></comment><comment><USER8> _There are a lot of mediocre and flat bad programmers out there because we're knocking down the barriers and letting everyone in, plus they have all sorts of crutches they can lean on now._

This is an incredibly good sign. Jeremy's statement translates to two things.

1\. Factor productivity in programming is so high that even "mediocre and bad programmers" can make a net positive contribution to the economy.

2\. Barriers to entry are low.

Would we want to change either of these things? Surely no one is going to argue that we should prefer lower factor productivity.

So, what about barriers to entry? If you look at industries that have '1' but not '2', you have a small set of very rich people keeping people out of the industry in order to protect their riches. This makes everyone else in the world poorer, because the service is artificially expensive, and it's especially bad for the "bad and mediocre" people who could have otherwise made it in the industry. The main benefit of creating high barriers to entry would be to make people who are already rich by the standard of the one of the richest countries in the world, in the most prosperous time in human history, even richer. Why should we want that?

It's great that some people think of programming as a craft and continually do everything they can to improve their skills; I can completely understand the attitude, since it's one I have myself. But, not everyone is like that. Some people would rather spend time doing other things. What's really amazing is that we're so rich and productive that someone can put almost no effort into learning how to program and still be a productive member of society. I love it that we live in a country where people can work 1/100th as hard as an employee in a Foxconn factory and produce more value. I hope that my kids will be able to be ten times richer than me while working one-tenth as hard. I pray that they'll choose to work harder than that, but I want it to be a choice.

It is a wondrous and amazing thing that total factor productivity[1] is so high in the U.S. that unskilled Mexican laborers become three times more productive when they cross the border; keep in mind that Mexico is, on a global scale, one of the more productive nations in the world.

[1] <http://en.wikipedia.org/wiki/Total_factor_productivity>

<comment><USER9> > Would we want to change either of these things? Surely no one is going to > argue that we should prefer lower factor productivity.

Try imagining these things happening for, say, doctors, civil engineers or something else that matters. I'm sure many are going to argue that we should prefer lower factor productivity.

<comment><USER10> That's already true of doctors. The barriers to entry to being a GP are lower than those to being a neurosurgeon. Like building rails websites has lower barriers to entry than writing code for the Mars rovers. In fact, if you so much desire, you can set up a homoeopathy practise without a degree in medicine.

<comment><USER11> JPL doesn't have particularly brilliant programmers, but they do have methodical, conservative, reliable programmers who test even the simplest systems extensively.

<comment><USER12> So what would the brilliant programmers do?

<comment><USER11> In my mind, brilliance is associated with (successful) innovation. One can innovate in two basic ways, in methods or products. For example, Rails is an innovation in method. The webapp itself (however it was written) is an innovation in product. Both kinds of innovation do occur at JPL (they've created a substantial toolset around Eclipse, actually, and are pushing into Cloud computing in a serious way), but the nature of the space-based/rover projects ( _years_ between "qa" and "production") means that those programmers are prized for their high skill and low tolerance for risk.

</comment></comment></comment></comment></comment></comment><comment><USER13> "Do you really need to use a whole giant framework for some simple site with a few CRUD operations? Probably not."

I'd rephrase this as "should you really spend any more time than necessary on a simple site with a few CRUD operations?" The answer is still "probably not" but now implies something completely different.

I also think that the fact that "just in it for the money" programmers can continue to exist shows that there's more demand for programming work than could be done by only the best and brightest programmers. So if there's work to be done, and work that doesn't need the best and brightest, why dwell on it? I agree with this part of the conclusion: "we should have some appreciation for what we have these days, because whether we want to admit it or not development is pretty easy" but disagree with much of the tone of most of the article leading up to that. And I disagree that we can turn the trend around (or that we'd even want to).

<comment><USER14> Sorry, mis-clicked and downvoted.

"Do you really need to use a whole giant framework for some simple site with a few CRUD operations? Probably not."

A simple site with a few CRUD operations can be created in about 5 minutes using a giant framework. (<http://hobocentral.net/>)

Spending days to do 5 minutes of work sounds like a bad thing, not a good one.

</comment></comment><comment><USER15> One thing I think is important to keep in mind is that standards were also a lot lower back then. Seeing a Lisp Machine in person, when you hit the bottom of the interactive terminal it would just start overwriting the top of the screen. For me, it was a surprising reminder that a lot of things we _really_ take for granted today were considered superfluous in the past.

For as much as things are easier today, what non-programmers consider acceptable ("the bar," if you will) has been raised more. The idea of full- time user experience people in the 1980s would have been ridiculous. Today we have "front end engineers" who are mainly there to inform and realize the interactions designed by full-time user experience people. For a significant amount of time, networking meant network filesystems and email. Today it means multi-million lines of code browsers running thousands to hundreds of thousands of lines of front-end code with just as much or more in the backend.

Programmers before us did more with less, true. But they also were more willing to accept compromises. I think things would probably be a lot better today if people's expectations were lower. But Plan 9 and Haiku are evidence that people actually care quite a bit more about usability than stability. It's a bummer. But I'm glad we enthusiasts can at least continue these traditions outside the mainstream.

<comment><USER16> > Today it means multi-million lines of code browsers running thousands to > hundreds of thousands of lines of front-end code with just as much or more > in the backend.

And people using all of that to call everything beyond email 'bloated' because...

Actually, I don't know why. One wonders if they also call a Ferrari bloated because of the Model-T.

<comment><USER15> I'm not exactly making a value judgement here. I like Plan 9, but not enough to use it daily, in part because I like to do things like leave comments on HN and do flashcards on memrise. I'm just pointing out that the capacity of computers isn't the only thing that changed since this golden era. Standards have too, and not really in the direction people were predicting. Dijkstra did a lot of hand-wringing over the Software Crisis, which amounted to "our software is still shit." Well, it's 2012, and it's still shit unless it's touching something nuclear, but nobody seems to be willing to make the tradeoff under normal circumstances.

On the one hand, both a Ferrari and a Model-T are really fundamentally about getting you from point A to point B. The majority of the progress between the Model-T and the Ferrari have to do with unnecessary optimization (going bazillion miles per hour) and tangental/incidental value-adds (being red, having air conditioning, etc.)

On the other hand, an inablity to discern qualitative differences is exactly why every discussion about Apple on Slashdot turns into "My Rio did everything the iPod did and more! It isn't fair! Wake up sheeple!" Maybe everything we do with Google Plus we could have done with email in the 80s, but does it matter if all the end user wanted to be able to do is put their signature in lilac Comic Sans?

Where we are today (in any field, on any topic) is a mixture of good decisions, practical solutions and random selections. Every pundit (and everyone on HN is a pundit) thinks they know which things arose intentionally and which things were just noise. I hesitatingly suggest that a large portion of the intentional arose from the desire for good looking stuff. I double-plus hesitatingly suggest that an alternate world in which Plan 9's view (everything is a filesystem, every user is command-line fluent) or in which Smalltalk's view (every user is a programmer, everything is live and can be live-debugged) would be interesting and offer certain benefits. Nobody will ever really know what that alternate world would be like—besides that it would probably look like absolute _shit_ —and I think it's unfortunate, in the bittersweet way that unrealized potentials always are.

But I take heart knowing that at least in this world, with very few exceptions, technologies can become _marginalized_ but they can't really be _killed_ anymore.

</comment></comment></comment><comment><USER17> I am going to characterize the situation a little differently.

20 years ago you had to be fluent in the deep arcana of low-level details to be a good programmer. You also could not lean on deep, rich libraries to get the job done because such libraries were far and few between. There was nothing good about this per se, it was a fact of reality. It also made it difficult and slow to get work done.

Today, development environments are rich in both tools and libraries beyond the wildest dreams of programmers two decades ago. You can implement incredibly complex applications without touching any of the low-level supporting code and expect reasonable results. That is the banner of progress.

However, this characterization of current software development is only true at the median. At the high-end, you still require a deep understanding of low- level systems, have to build your own libraries, and be able to wrangle esoteric computer science to be a good programmer. Many years ago, there were a great many programmers with these skills because you needed them to get the most rudimentary jobs done. Today, I see many more software engineers that completely lack these skills because they never needed to learn them to become a good, marketable programmer.

That is an important distinction. It is not to say that earlier generations of programmers had more intrinsic ability, but they did have skills that are relevant today to designing software on the very high-end that are much less frequently learned now. To a significant extent it was a product of environment. Ironically, many of the primitive skills that were relevant many years ago have become cornerstones of writing high-performance and scalable software systems today.

</comment><comment><USER18> Looks like rose-tinted glasses to me.

> Bad programmers will still build bad software tomorrow too, but I think > there are more of them now than there were then and that's the real problem.

Of course there are more bad programmers now - because there are many more programmers now. But this doesn't make the great programmers any less great than their predecessors.

And things like higher barriers and lack of powerful search engines may have been true, but do they really improve a programmer's ability? I'd argue they simply affect a programmer's productivity, whether the programmer's skilled or not.

Human greatness (or lack of) in a particular industry doesn't vary over time in my opinion, especially over just a few decades. I don't think the achievements of the past are any better or worse than the achievements of today. It's just much easier to recognise great achievements (and achievers) in retrospect - as time passes, the signal-to-noise ratio improves.

</comment><comment><USER19> I work in Ruby on Rails, and have a developer on my team who started way back in the punch card days.

His take is that it's harder now. We have better tools, but the things we're building are more complex. We're programming at higher levels of abstraction for broader code re-use.

We're also making lots of code libraries work together, coordinating application code and cacheing layers and multiple kinds of databases. We're writing client-side code that talks to our server-side APIs. And we've got a whole system of tests and a system of version control which, though they make our lives overall easier, are also part of the learning curve.

New day, different challenges.

<comment><USER20> I agree with this. Even though I started writing code in the 90's, 15 years has changed the landscape tremendously. I think there is a disparity between the fundamentals of programming and the fundamentals of being a modern programmer in the work place. Fundamentals are often not needed everyday, because the scope is much larger.

Still, it is a craft, and like any craft you should strive to always be a better craftsman.

Like a story a friend of mine once told me. When he was in culinary school he was asked "If a cook and a chef can produce the same meal, what is the difference?". The answer: a chef knows why he does what he does (or she).

</comment></comment><comment><USER21> As a CompE in his final semester of undergrad, I resent this characterization. I've seen what the tests and MPs from ten years ago looked like, and they're a joke compared to what we see nowadays. Even when you consider the number of cheaters and copy-pasta-ers (which was much more difficult to catch a few years ago), I think the standards for LEGITIMATE programmers are constantly improving.

There will always people that skirt by on the bare minimum level of work, and due to the increasing number of people in this industry, the number of slackers is increasing as well.

Or perhaps I'm overly optimistic about our current generation.

</comment><comment><USER22> How difficult is it to understand the concept of building on past human achievements? Standing on the shoulder of giants?

If people don't use slide rule as much today, is that a bad thing? Are those problems no longer getting solved?

Do you still need/want to learn how to build wheels if you want a car?

As you develop better tools, you go on solving increasingly difficult problems.

</comment><comment><USER23> In the past few weeks, I don't know why, but I took a prominent note of how easy application development has become. The fact is that someone probably could learn how to write a web application in Ruby on Rails in three months without much hinderance. Production quality, probably not, but a REST API persisting to a database and implementing some business logic, absolutely.

It scares me a little (a really little) in that this trend is ostensibly a precursor, or leading indicator if you will, to the increasing commoditization of our profession. But here is the thing. There are steps that we can actively take to mitigate the complacency that recent technology has afforded to us. This is likely where I agree with the author the most. If your skill set is narrower than you wish it to be, engage problems in a different domain, and acquire the knowledge to do so beforehand. Meanwhile, if you're one of the people, like me, who feel beyond fortunate to wake up everyday doing something that you love, then continue to do that, stay hungry to learn new things all the time, and hope that that will be enough. That's pretty much all you can do.

<comment><USER24> Am I the only one that sees commoditization of programming as a _good thing_? I long for a world where everybody could define simple-to-moderately-complex automated behaviors, without needing to pursue a career in programming.

Tools like Apple's Automator or Android's Locale provide low barriers to scripting for the masses, but they fall short of providing a good, easy to use abstraction mechanism; in the end they amount to classic imperative languages, which are difficult to master.

On the other hand we have the Spreadsheet, the only widely successful End- User-Development tool, ever. This one provides a really good for building abstract data models and workflows - I've seen it used by people without any programming understanding to develop complete form-like applications, collaboration tools and storage repositories. Unfortunately, using those required a lot of repetitive actions. The spreadsheet model does provide a good abstraction mechanism but does not support automation capabilities; you still need a classic scripting language to automate behaviors.

I hope the recent _live programming_ fad initiated by Bret Victor's "Inventing on Principle" will finally produce widely used reactive environments; those are a good basis for non-programmers to begin programming without a steep learning curve and only up to the point that they really need.

</comment></comment><comment><USER25> I like this piece because I agree with a lot of what was said, but I don't necessarily think that this is a bad thing. There's always going to be people who are hardcore computer scientists, the ones who started programming in their bedroom at a very young age. But I'm glad that there's room in this industry for those who have lives outside of computer science as well.

As the world progressively becomes more automated (which I undoubtedly believe will happen)and personal computers become even more integrated into our lives (Smartphones are perfect examples) we'll need more average programmers to do the "gruntwork" so to speak, as you all well know computers are only good at following instructions line by line, computers will always need those instructions to be written whether that takes a master CS guru who's been doing it for 20+ years or someone who's fresh out of college and kind of drifted through. There will always be room for innovation for those of us whom are dedicated to our craft, and i'm glad to see that there will be room for those who aren't as dedicated.

</comment><comment><USER26> Writing code today is easier because of better tools and more powerful hardware, but the requirements and scope of projects have gone up by an absurd factor.

A good programmer today is more knowledgeable and more versatile than ever before. Problems are more complicated, systems are much grander in scope and there's simply more technology to deal with and learn from. Google is a plus, not a minus. All this code sharing makes you learn new stuff all the time.

Seeing new approaches and methods makes me a better programmer than someone who's ultra focused on their niche, like back in the day.

And if you look outside the HN web-centric scope, at low level programming, consider this: a reference manual for a simple 8-bit microprocessor (lets say 8051 core, very popular) was 300-400 pages long. Many products were designed around it in the 80's and 90's, but as demands from products skyrocketed, this hardware was no longer enough. For comparison, the reference manual of a TI OMAP4460 processor, like the one in the Galaxy Nexus phone and Pandaboard dev kit, is around 5200 pages long with the most complicated parts (e.g. 3D) blanked out for confidentiality reasons.

Or look at it another way: a $3 microcontroller today has most of the capabilities of a Pentium PC from 15 years ago (it has audio codecs, USB, Flash storage and a lot of other stuff not found on the PC, and pretty close computational power too). Someone has to write software to use all that. This software is complicated. Your car has dozens of processors and there was an article around here estimating the new luxury car code at several million lines. Someone has to write that, too. This someone is very likely (or so I hope) more knowledgeable and adept at doing their work than his predecessor that only had to deal with one or two simple ECU chips.

Sure the barriers were higher back then, but someone who's truly good today is magnitudes better and more versatile than in the past - there's no contest really.

</comment><comment><USER27> Three words: "Shoulders of Giants." I'm sorry you had to forge the way, but the present is still the frontier. We would do well to learn from the past as always.

</comment><comment><USER28> Similar claim was made by Alan Kay in his lecture _Normal Considered Harmful_ [1]. However he didn't complain about lower barriers to entry. Instead he pointed out that the people in the 90s ignored the work and experience of the past generations of programmers. He especially criticized the Web.

[1] <http://www.youtube.com/watch?v=FvmTSpJU-Xc>

</comment><comment><USER29> The point he makes is kind of obvious, IMO. Anytime you lower the barriers to entry, less skilled persons can take part. He also seems to think of a programmers ability as relatively static in nature. People can learn, grow and get better. Low barriers to entry mean that you can have poor developers writ and release code into the wild. Eventually, these people will either dig in and learn, or whither and die on the vine. Even if they stay around, who are they really hurting? Bad code needs to be maintained or replaced so it keeps good devs employed :)

This just struck me as a curmudgeony rant akin to "Back in my day, we had to walk up hill both ways through the snow and fight mountain lions just to get to our unheated one room school house"

That said, certainly the first couple generations of developers solved some very hard problems for those of us here, and that should not be taken lightly. But we live in a great time right now, there is still much work to do and there is a pretty danged nice environment to do it in.

</comment><comment><USER30> We just had a post on how to build your own private google to facilitate looking shit up <http://news.ycombinator.com/item?id=4580537>

Machines are more powerful these days! The unix kernel used to fit in a book. How many books would it take to fit the linux kernel?

These days we happen to have in place an efficient communications system, built by these very giants of the past, that actually facilitates getting advice from your peers.

Why do you want to use a framework? Well it's not just about not writing the code, it's about having code that has been well tried in action and honed. Any eventual problem is probably documented somewhere on the net. Write your own core stuff and you'll need do manage the cost of stabilizing the software.

<comment><USER31> The Linux kernel has about as many chars as one to two Encyclopedia Britannicae. C does not have as many chars per line as English, so printing the kernel would require three or four Britannicae.

</comment></comment><comment><USER32> I find the title to be a little misleading, given what he goes on to explain in his article:

" _Don't get me wrong here, the class of 2012 CS grads are full of brains and talent, they're just mixed in with more mediocre people than the class of 1972 was. We aren't getting less talented or smart folks, its our signal to noise ratio that's suffering._ "

More clearly stated as above, I quite agree with the point that we now have a whole lot of "fake programmers" coasting through school with the help of "copypasta," as the author likes to put it. But then again this is just the diffusion of innovation in action [1], applied to careers instead of technology.

[1] <http://en.wikipedia.org/wiki/Diffusion_of_innovations>

</comment><comment><USER33> The copypasta crowd was alive and well back in the old days. I got my junior college programming degree in 1985. Grading of programs was based on correct output (still relevant today) and number of compiles. Yes, you could get it 100% right but fail anyway if you took more than 5 compiles. No penalty for printing, though, so desk-checking of listings was our main activity. Once you marked up a listing and made your changes (sometimes via terminal, sometimes via punched card) you tossed the old listing. The folks who couldn't grasp the concepts would grab listings out of the trash and pirate code from them. Good programmers kept close track of their punched card decks too--the pirates would happily swipe an unguarded deck.

</comment><comment><USER34> I've been a professional programmer since 1978 and the article seems 'off- beam' to me. He thinks that because programmer was harder 30 years ago, that would be there was a higher barrier to entry and therefore only really good programmers would get programming jobs. That idea is just completely wrong. There were the same number of people who could program as opposed to those who weren't very good as there are today.

Most programming goes on in your head in my opinion, and it is very much the same today as it was in the 1970s. You need to be able to run programs in your head if you are writing a COBOL program on coding sheets, that are sent away to be turned into a deck of punched cards, and once the cards are punched you can get them compiled into a program at most twice a day. If you want to be a really good programmer today, you need to be able to visualize what you are working on in your head. To me that is the ability that separates average programmers from really good ones - a good programmer doesn't need a computer to program, although having one is obviously handy..

For me there have been two big changes in how you conduct a programming career. The first was the introduction of personal computers that were cheap enough for a programmer to buy and use them to learn new programming skills in their spare time. The second big change was Free Software where you could publish your own code, and collaborate with people over the internet. I bought a Macintosh in 1984 and used it to learn Pascal with MacPascal. Then I got a programming job using Pascal. More recently I did a Ruby/C++ Free Software project and got jobs as a Ruby programmer and as a C++ programmer as a result.

Only really good programmers can write Free Software and handle open reviews of their work, and so if the article was about 'better self selection of programmers', then people who write software in public today are way better than the average programmer of 30 years ago. The very best programmers of today are much the same as the very best programmers in the 1970s, it is just that they are easier to find today. That is assuming you think people like Linus Torvalds or Rails DHH are examples of the best programmers in the 21st century.

</comment><comment><USER35> I could spin that the other way: Sure we're not as good, but who cares, the tooling and the methodology are much better, so as a whole, we're probably producing better quality on average.

I'm sure you can cherry-pick a few great names from the past and tell us how massive their shadows still are in nowadays' programming, but the average back in the day was probably not very good, especially since everyone was using tools and languages that were by nature very unforgiving.

</comment><comment><USER36> Are the musicians before us better? Are the artists before us better? Who's to say?

Better questions are..has the best song already been written? the best painting already created?

Sure, now we have more tools and low barrier to entry, that should only increase the likelihood of the best talent coming in to this field. I'm excited to see what can be created as a result.

<comment><USER37> A lot of people do say the musicians of years before were better. I think it's more likely that the ones we still remember today were the best of their time, and that the best of our time will be remembered the same way by future generations.

</comment></comment><comment><USER38> Well, the expectations in terms of delay and scope grow to match the ease you gain by having better tools.

Sure 30 years ago you could waste hours on a trivial problem because you didn't have Google and Stackoverflow, but your boss was happy when you spent a month on something you would have a week to do nowadays.

</comment><comment><USER39> The good programmers today are just as good as the good programmers of yesterday. The challenges they face are just different as the tasks they tackle are different.

The other difference is that there are enough computers about that the bad programmers can get jobs as well!

</comment><comment><USER40> tl;dr: I would argue, based on experience, that today's programming languages make it much easier to get the job done than used to be the case back then. As a result, programmers today don't have to be as good (i.e. lower barrier of entry) to write programs as programmers of the past had to be. So, it is less of an elite profession ... and it is not necessarily a bad thing.

</comment><comment>====

I first encountered programming in the late 70s, when I learned Fortran in a college level course. I did not have much opportunity to use it then, but I found it fairly straightforward to use. I hardly used it, nor did any other programming until the late 80s.

In the late 80s, I had to relearn Fortran to do numerical work, which I did for a couple of years. Again, I found it very straightforward.

After I moved to a new job (solitary university prof with no research budget) I needed to do some numerical work and could not get a (free) Fortran compiler. I learned C and could easily translate (in my brain) algorithms that I knew how to program in Fortran; it was not quite as straightforward ... but it was fairly easy. (In other words: C was not the best tool for the job.) Then, I got a copy of Numerical Recipes in C ... and it was (at the time) as though it was written in a completely different language, one that was definitely not suited for its purpose. Thankfully, I got the results I needed and could put that behind.

In the mid 90s, I learned Java to write applets for teaching concepts to students. Using Java was not pleasant, as I found it rather verbose and a bit like having a straightjacket on.

I did not program for 10 years. Then, around 2004 I stumbled upon this language called Python ... and found that programming in it was incredibly straightforward. Fortran made numerical code easy to write (by design); Python made everything easy to write. It was so much fun, that I picked up programming as a hobby.

Since then, I've learned a few other programming languages and found that having the right tool for the job makes the job easier (duh!) ... and that there are a lot more useful tools (read: programming languages) today than back then. So, you don't have to be as good today as you had to be back then to write programs that actually do stuff.

</comment><comment><USER41> Falls under the "no shit" category.

</comment><comment><USER42> All I heard was: "Kids these days!" - a phrase that is doomed to repeat itself for ever.

</comment><comment><USER43> I was the programmer before "us" and I was not better but I'm better now.

</comment><comment><USER16> Compiler design has an interesting example of how you don't need to be wizardly to do interesting things anymore.

Jack Crenshaw's series of articles is an interesting example of this from an era that's already bygone (his example was a compiler written in Turbo Pascal directly generating Motorola 68000 assembly) but is close to our own time in many ways that count. For example, he emphasizes the fast turnaround time you get when your compiler is running on a PC instead of a mainframe across campus.

Specifically, his little digression in the eighth part is on-topic here:

<http://compilers.iecc.com/crenshaw/tutor8.txt>

He specifically mentions the multi-pass design common to early compilers (63 passes for a compiler written for the IBM 1401!) as being down to having to fit the compiler into limited RAM. Similarly, Crenshaw's compiler relies on the existence of a fairly capacious stack to allow the parser to be recursive; on a 1950s-era mainframe without a stack, or a 1960s-era minicomputer where procedure calls were not re-entrant, you'd be left to do a lot more bookkeeping by hand.

Then you have the massive emphasis on error detection and reporting forced on programmers by the slow turnaround inherent in batch systems: You can't just die at the first error with a one-line message if it'll take two weeks to run the program again; soldiering on and verbosely reporting every step was the only way to get the most out of your precious computer time.

And, of course, less-optimized code is easier (and faster!) to generate, but can only be justified if your machine is fast enough the optimizations aren't actually needed. tcc, the tiny C compiler, is a modern incarnation of this idea; it compiles fast enough you can throw the result of the compilation away and run the compiler every time, like you do in Perl or Ruby.

And he mentions standardization: His compiler can only handle grammars you can express cleanly in BNF, which is okay because those kinds of grammars are dominant now anyway. Kinda hard to predict that ahead of time, though.

<http://compilers.iecc.com/crenshaw/></comment>


Ask PG: Why is Hacker News not Open Source?  - <AUTHOR>

<comment><USER2> See previous discussions of this issue, which are easily revealed by Google if the fitting keywords are used in the search:

<http://news.ycombinator.com/item?id=494421>

<http://news.ycombinator.com/item?id=711613>

[http://stackoverflow.com/questions/4285617/how-do-i- install-...](http://stackoverflow.com/questions/4285617/how-do-i-install-arc- to-get-a-hacker-news-clone-website)

</comment><comment><USER3> Unrelated, but there are good open source clones like <https://github.com/antirez/lamernews>

</comment><comment><USER4> Ask OP: Why SHOULD it be open source?

1\. Asking "Why isn't it this" without a "this is why it should be this" is such an easy argument it must always be ignored

2\. Hacker News is a Y Combinator entity. If it were to be open source, it would be open source to YC people only I can only assume.

<comment><USER5> 1) because we could then help make it better (or make a couple HNs)

I believe there is an old version available.

2) open source for some people but not for others is an interesting concept.

<comment><USER6> Open source for some people but not others? Thats not open source...

<comment><USER4> I know we're considering a new model for open source. I'd say that's a semantic argument but it's more of a semantic observation

</comment></comment></comment></comment><comment><USER7> also, if e.g. the algos for the rank of the articles would be known exactly, it would make it substentially easier to game them...</comment>


Ask HN: Dropbox passowrd resets this morning? - <AUTHOR> I and more friends than normal got password reset emails from Dropbox this morning. Something related to the Dropbox hack a couple months ago maybe? <comment><USER2> I didn't get a password reset, but my password no longer worked, and 100% did not change it.

</comment><comment><USER3> Here too.</comment>


About the security content of macOS High Sierra 10.13.5 - <AUTHOR> https://support.apple.com/en-us/HT208849 <comment><USER2> Release notes for iOS 11.4, tvOS, watchOS, Safari, iCloud for Windows haven't been posted on the main web site but they were already posted to the mailing list: [https://lists.apple.com/archives/security- announce/2018/Jun/...](https://lists.apple.com/archives/security- announce/2018/Jun/index.html)

<comment><AUTHOR> Yeah, 10.13.5 is the accompanying update in many ways (kind of odd they didn't just release them in total sync), Messages in iCloud needs it for example.

Also, looks like this update contains some mitigation efforts by Apple towards S/MIME exfiltration out of Mail.app, though the CVE they cite doesn't match what I remember Efail's being [1] so I'd be curious if it has any effect on that one, even if the existing S/MIME has fundamental flaws that can't really be patched. This also prompted me to go take a look on the GPG side of things, there is no native support of course so most people are probably using GPGMail if they aren't using an alternative mail application. They still haven't released GPG Suite 2018.2 however, so the only mitigation remains no loading of remote content.

This article also covers security patches for 10.11/10.12 and there are some important ones there. Noteworthy is some more Spectre fallout with Apple getting out patches for both 10.11 and 10.12 covering CVE-2018-8897. I think most OS got that patched earlier in May (I know DragonFly BSD had that dealt with on the 9th), but it's better then nothing that Apple is continuing its informal couple of years of security patches for macOS. There are plenty of people who've avoided High Sierra too so it matters even more.

\----

1) CVE-2017-17688 and CVE-2017-17689, discussed on HN: [https://news.ycombinator.com/item?id=17064129](https://news.ycombinator.com/item?id=17064129)</comment></comment>


It's 'bacteria', not 'bacterium' - <AUTHOR> http://arstechnica.com/science/2010/10/giant-virus-found-in-tiny-predator/?comments=1&post=20945281#comment-20945281

<comment><USER2> There is a little problem with the pedantic poster (the commenter at ars)...

Bacteria comes from 'bacteria' in greek, which means 'rod' or 'stick' (walking stick). The fact that some people neolatinized and fabricated a 'bacterium' means absolutely nothing.

If you want to be pedantic, say 'bacterion' and 'bacteria', but then again you would probably write it 'bakterion'.

Wikipedia is not the definitive source for a lot of things, least of all this.

</comment><comment><USER3> Came in expecting a prescriptivist ranting about the roots of our language and got a fairly level-headed rant at language loons prescribing things wrongly. I enjoyed it.

All living languages are subject to continual change anyhow, that's the rule that should stop people from dictating how we use the language. Language is just there for us to pass on information, in most cases of nitpicking that gets overlooked.

</comment><comment><USER4> _Because of the physical size of bacteria, the word became a mass noun and functions as both plural and singular. Same reason for taking "data": it is collective._

I had to look this up and it's far from authoritative but Wikipedia doesn't seem to think that's _entirely_ true for data, at least (that is, you may say "a bacteria" but you do not say "a data"): <http://en.wikipedia.org/wiki/Data>

_In English, the word datum is still used in the general sense of "an item given". [..] Any measurement or result is a datum, but data point is more usual [..] Even when a very small quantity of data is referenced (one number, for example) the phrase piece of data is often used, as opposed to datum. The debate over appropriate usage is ongoing._

</comment><comment><USER5> I am glad that someone who knows more about language than I do can make a sophisticated sounding arguement that I can regurgitate to make myself sound smart. Who cares if it's correct or not, I can belittle a lot of people with words like these.

</comment><comment><USER6> I just had to check which rules apply to some other words, like 'stadium' and 'forum'. Turns out that both 'stadiums' and 'stadia' are valid plurals of 'stadium' while 'forums' is the preferred plural of 'forum', although 'fora' is not incorrect.

[1]<http://en.wiktionary.org/wiki/stadium#Noun> [2]<http://en.wiktionary.org/wiki/forum#Noun>

<comment><USER7> Speaking of "stadium", that's another one of those Greek words where we go around repeating the Latinized version. It might be more properly "stadion".</comment></comment>


NSA: Linux Journal "extremist forum", readers flagged for surveillance (2014) - <AUTHOR> http://www.linuxjournal.com/content/nsa-linux-journal-extremist-forum-and-its-readers-get-flagged-extra-surveillance <comment><USER2> Rob Graham doubts this is production code.

[http://blog.erratasec.com/2014/07/validating-xkeyscore- code....](http://blog.erratasec.com/2014/07/validating-xkeyscore-code.html)

</comment><comment><USER3> Everyone is an enemy until we say otherwise.

</comment><comment><USER4> Please add the 2014 tag

<comment><AUTHOR> The title was already at the limit of the # of chars. I had to strip out quite a bit to get it to fit as it is (including one space that really ought to be there).

<comment><USER5> > NSA: Linux Journal is extremist forum - readers flagged for surveillance > (2014)

or is that not close enough?

<comment><AUTHOR> Works for me.</comment></comment></comment></comment>


Unconscious brain activity predicts decisions 11 seconds before action - <AUTHOR> https://qz.com/1569158/neuroscientists-read-unconscious-brain-activity-to-predict-decisions/ <comment><USER2> Michael Graziano's Attention Schema Theory of consciousness (AST) provides an interesting perspective on this study. Although the study is limited and predicting a decision only implies a correlation rather than a causation, it is worth thinking about how brain activity and conscious action are related.

AST distinguishes between neuronal activity (attention) versus conscious experience (awareness), and postulates that awareness is both a model of attention and a director of attention. Essentially, consciousness as a simulation that has the startling ability to influence the simulator itself. Example: we experience seeing an apple (awareness) and consciously focus upon it, which amplifies the neuronal activity for sensing and processing vision (attention). Due to this amplification, we then gain a sharper experience of noticing more details about the apple. Awareness both models attention and directs it.

In terms of predicting decisions based on brain scanning, it would be easy to see how as a person's awareness focuses attention on a particular image, even without quite realizing it, that the brain patterns of such attention would be clearly amplified.

This study seems to suggest that our conscious feeling of making a decision is a false experience. That we are simply watching a pre-ordained movie and are being given a false sense of agency. In AST, even though our consciousness is a synthesized model of our brain activity, and even though decisions may be made in neurons not part of that modeling, there is little meaningful difference between the model we experience of making a decision and the brain activity of the decision itself. Although there will always be a lag between a model of activity and the activity itself, we generally experience no lag.

it would be interesting to see in what edge-cases lag would really matter. I believe there are some odd experiments with buttons and blinking lights where the decision to press a button is experienced after the experience of seeing the light from pressing the button.

All the same, if AST is on target, then conscious agency is real, and this paper doesn't have anything to say on the matter, even if the headline is highly suggestive that it does.

<comment><USER3> Where can I learn more about this?

<comment><USER2> "Consciousness and the Social Brain," by Graziano is a great place to start.

</comment></comment></comment><comment><USER4> I would want a study that focuses on the opposite: what is the lowest bar a person trying to deliberaty foil such a system can reach. My bet: around 50-150ms.

</comment><comment><USER5> Hasn't this been known since Benjamin Libet's experiments in the 1970's?

[https://en.wikipedia.org/wiki/Benjamin_Libet](https://en.wikipedia.org/wiki/Benjamin_Libet)

Or am I missing something here?

<comment><USER6> It's primarily the significance of the amount of time before the action (or whatever). Prior to this new study, arguments purporting to show that the relevant notion of free will was undermined by experiments such as Libet's were unsuccessful. Al Mele (FSU) wrote the definitive work on this issue in "Effective Intentions" (2010, Oxford University Press). Mele convincingly showed that the ~500ms time delay in Libet style experiments was not long enough for the skeptical argument to go through successfully. In the last part of the book Mele commented on the implications of any studies of this type (perhaps heading off arguments based on future experiments such as this one). For sake of length I won't quote the semi-formalized version of Mele's argument in the last part of the book, but rather the analogy he uses to elucidate it:

"Consider an analogy. Max struck a log with his red ax, thereby causing the log to split. If Max's ax had been green, it would have split the log just as well. But he was under strict instructions to split wood only with red axes, and he was committed to following the instructions. If his ax had been green, he would not have used it; in fact, he would have looked for a red ax and split the log later, after he found one. In this scenario, the fact that the ax is red is causally relevant to Max's splitting the log when he does and therefore to the actual log splitting action he performed, an action that has a specific location in time. Similarly, in the imagined experiment, the fact that at t, Sam made a conscious proximal decision to press seems to be causally relevant to his pressing when he does and therefore to the actual pressing action he performs. I should add that although we do know that, other things equal, red and green axes split wood equally well, we do not know how effective unconscious decisions are. Nor do we know whether unconscious deciding (as distinct from unconscious nonactional intention acquisition) is something that actually happens. Also, for all we know, if there are instances of unconscious deciding, they are far too rare for there to be more than a glimmer of a chance that if Sam had not made a conscious proximal decision to press at t, he would have made an unconscious one."

\----

It is worth pointing out that Mele is famous for remaining agnostic about free will (and certain fundamental questions surrounding it).

</comment></comment><comment><USER7> Thought I'd share one of my favorite short stories (written by Ted Chiang, most recently of Arrival fame) that bears on this: [https://www.nature.com/articles/436150a](https://www.nature.com/articles/436150a)

<comment><USER8> Wait. This device can be fooled easily: At any point in time, I can look at the LED. If it's off, I press the button exactly 1 second later. If it's on, I do nothing.

What am I missing?

<comment><USER9> You're simply missing the fact that _by definition_ there won't be any case where you see the LED being turned off 1 second before you push the button. If you see the LED being turned off, you won't be pushing it the second later.

</comment></comment></comment><comment><USER10> It's interesting how many comments immediately defend the evidence of "free will". I'm not saying this article comes close at all to invalidating "free will" but it begs the question how will humanity react if we do invalidate it one day? Seems on the same scale as "the world is round" or "Earth revolves around the sun".

<comment><USER11> Why would you assume that "Free Will" is something that can be proven/disproven? Something that is in the domain of science?

To clarify the question, what kind of scientific experiment would you even imagine that would even resemble something producing evidence for or against free will?

(These experiments talked about in this topic do not at all fit it: they just show that there are conscious and subconscious parts of our experience of life and our experience of the process of choice. In what world would that be related to the degree of "free-ness" of that choice is beyond me. I thought we all knew already that there are conscious and subconscious parts of the brain and that many of activities of "I" are subconscious.)

<comment><USER12> One way is to show that, given a state of the universe, it is possible to determine the next state. From what I understand, this does not seem to be the case.

<comment><USER13> I think it can't be the case because the brain is a chaotic system. But hiding behind chaotic behavior to preserve "free will" is farcical, isn't it? We can't know how the pendulum[0] will swing next, so we can say that it's got free will?

0: [https://upload.wikimedia.org/wikipedia/commons/4/45/Double-c...](https://upload.wikimedia.org/wikipedia/commons/4/45/Double- compound-pendulum.gif)

<comment><USER14> It's not "farcical". If you could prove that physical states are deterministic, you could prove that there is no free will. That statement makes no claims whatsoever about what it means that physical states are not known to be deterministic. In other words, it could have been useful as proof negative of free will, but not as proof positive. And that's okay.

<comment><USER15> Wheter "free will" exists or not seems like a technicality, tied to whether the Universe is deterministic or not. Whether or not it's deterministic, a brain must still go through its thought processes to come up with any decision. The only difference that non-determinism makes is that the decision may randomly go one way or the other based on low-level fluctuations. Thinking and decision making still occurs even if the Universe is deterministic.

<comment><USER14> It sounds like we agree.

To be clear, I think that free will--by definition--cannot exist in a purely deterministic universe. Any semblance of free will in such a universe would be purely illusory. It also cannot exist in a universe where events can only ever be some combination of random events and determined events. Randomness is also _not_ free will.

Free Will would have to be some other special category of events that is neither determined not random. We don't have a word or phrase to describe what these events would be like other than "Free Will." However, lacking the vocabulary and math to describe it does not make it non-existent.

<comment><USER15> I think this is some kind of supernatural "free will", and no mechanism has been found for such a thing in science. It's associated with mind–body duality, souls, homunculi inside the body, that kind of thing.

<comment><USER14> It doesn't have to be super natural either, though. By the nature of it's existence, the universe proves that there can be chains of events spawned that completely undermine our current treatment of causality. A realistic model must include at least one of the following:

1) Events with no cause such as the beginning of the universe or broader multiverse, depending on your beliefs or 2) Infinite regressions of causal chains if you believe that the universe or God (or a god) has always existed or 3) Some combination of the above.

In all of these, somehow there can be uncaused effects, but in 1) and 3) some causal chains can just begin existing, like free will would require.

<comment><USER15> If uncausal events were so common, wouldn't they have been discovered in laboratory conditions by now? They'd be messing up experiments everywhere.

<comment><USER14> You might even say that such events would be experimentally indistinguishable from random events. Or practically identical.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER16> If I were to make a decision such as this, I would make a snap preliminary decision, then review it to see if there were glaring errors. That seems to fit with the results.

The results don't seem to be stating anything new or non obvious to me. Am I missing something?

<comment><USER17> The key thing is this "the researchers were able to predict which pattern participants would choose up to 11 seconds before they consciously made the decision"

So this goes into the question of "free will". Is your conscious mind making the decisions or is just trying to justify the decisions made by the unconscious mind.

<comment><USER18> It doesn't tell us anything about free will other than the fact that the process of decision making happens prior to our conscious awareness, which we already knew.

<comment><USER19> Ye, it's is kinda obvious that the decision is made before you "know it". How would it otherwise work.

</comment></comment></comment></comment><comment><USER20> It seems pretty obvious that when confronted with a choice you generally take an immediate biased opinion and then spend some time reviewing the alternatives just in case. It wasn't 11 seconds until they made the decision, it was 11 seconds until the decision was confirmed and vocalized. It sounds like 'basic' image focus detection.

</comment><comment><USER21> The researchers don't know if the choice was made in the first second or in the final second: it doesn't make sense to say that the brain activity predicted the choice 11 seconds beforehand.

</comment><comment><USER22> Maybe we just experience our brain making decisions. Everything else might be 'unconscious'.

Implying that our conscious experience of the world has no control over our brains.

Otherwise conscious/unconscious implies some sort of duality in your head. Like the homunculus..

<comment><USER23> More like experience a "subset of the environment". We can barely handle more than a few digits at a time, a particularly small square of vision, or a particular song. We can focus our mental effort at really only one thing (the other has to be learned/unconscious so that it can go parallel).

I think the question becomes: Why are we conscious in the first place?

<comment><USER22> Unless there is something special going on.. experience seems to be a property of matter itself.

Which could mean everything is aware to some extent. People, dogs, rocks, etc.. But because of our big complicated brains that can hold memories and all that - we are aware of being aware.

</comment></comment></comment><comment><USER24> If feels pretty obvious to me to think that internal mood has something to do with decision making. It could take a couple of seconds for a reaction to cook up in order to become a decision.

</comment><comment><USER25> Sure, and seeing some elecrical patterns in DRAM circuitry will predict changes before they show up on your monitor too. That's just how computers work.

Similarly, unconscious activity is just how consciousness and choice work. That doesn't mean that free will doesn't exist. It's a complete misunderstanding of the concept.

<comment><USER26> No one thinks that computers have free will. Not yet anyway. The idea that the conscious mind isn't the one making decisions seems to have implications for free will. Can you explain why it's misunderstanding of the concept?

<comment><USER27> I find that the intuitive idea of free will doesn't make all that much sense anyway. Leave aside the discussion of whether people have free will in this universe, how would a universe in which people actually have what most people call free free will even work?

<comment><USER28> Assuming that "free will" doesn't include manipulating the laws of physics, pretty much like the one we live in? I can see where people are coming from when they say there is no such thing as free will, but it sounds like they are saying the no one has the ability to consciously override their impulses. I don't smash the skull of everyone that makes me angry, for example.

<comment><USER29> but why is bifurcation required? is the one stopping the impulses any different than the impulses engine?

the reason you don't smash all of the skulls is as causal and determined as the impulses afaict.

to me it seems that life is just sufficiently complex self contained units that are completely bound by deterministic laws. we have a sense of self referential capalbility which may give the illusion of free will but I'd say that it's not your decision to stop the impulses of smashing skulls rather it is the inescapable result of your unique determined state or rather process that your brain has been configure d for based on life experience and genes.

<comment><USER25> You're assuming free will is mutually exclusive with determinism. This is probably not the case. See Compatibilism, which enjoys majority support among philosophers and studies of lay people.

<comment><USER30> This works as an assumption, and is rather useless in practice, because we cannot determine the deterministic state to its full extent, even in thought experiment, without limiting the degrees of freedom converging to zero, to then say, well I had free will after all, when I didn't know any better. I really don't get it.

I mean, support for Compatibalism is in effect not the support of determinism that it claims to be. It's just an effort of philosophers to safe free will, out of free will, which means, to me, out of ignorance. So the only real insight is that we are sufficiently ignorant. How is that still sold as a positive thing?

That still didn't come out right.

I was trying to say, that Compatibilism is a meta argument. If it isn't then because it _determined_ free will as a deterministic fact. I understand that philosophy is rather complicated, and at the very least I doubt that, if Compatibilism is true, that many people understand it sufficiently to be in the position to support it, other than as an educated guess.

<comment><USER25> I think the problem is that most people misunderstand philosophical inquiry. The free will debate is about _defining what free will_ means such that it can serve as one factor to ground moral responsibility and how we employ our moral reasoning.

Long ago, some philosophers suggested that we cannot be held morally responsible for factors that our outside of our control, and further, that any effects that follow from factors outside of our control, are thus also outside of our control. Determinism is the quintessential example. Numerous arguments have since been presented that debunk this need for control, the ability to do otherwise, etc. These properties simply aren't necessary for moral responsibility.

Furthermore, studies in experimental philosophy have shown that lay people actually employ Compatibilist moral reasoning, debunking the long held assumption that people are incompatibilists because of religious upbringing.

So I disagree that Compatibilism is some sort of meta-argument, as it fits squarely in the expected domain of discourse for free will. It is precisely fulfilling the philosophical research program of identifying that which is necessary to make sense of choice in our moral language.

<comment><USER28> Now I know what other people feel like when they listen to programmers talk. :D

Do you know of any materials that present the debate in a form that a ten year old could understand?

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER31> Are the action potentials spinning up like a turbo in a car engine?

</comment><comment><USER32> 11 entire seconds is a life for brain activity. Superslow.

</comment><comment><USER33> I don't think this paper is related to free will, or if they even claimed it is. It's just sensational title.

The choice is completely non-consequential, it's picking between 2 patterns. The brain choose based on it's initial biases. It's like when you are turning off your brain watching youtube videos, it's likely that you will open another video after that instead of going back to your work because there is a strong pre-existing brain activity related to whatever you're watching.

What I'm saying is it isn't like some directive from the subconscious that you cannot go against, it's more like one room is filled with sweets and the other is filled with nothing. The choice is still taken at the moment.

<comment><USER34> This is just one of the many studies. You can detect the choice from the brain up to seven seconds before when people are asked to push a button any time they feel the urge. [https://www.nature.com/news/2008/080411/full/news.2008.751.h...](https://www.nature.com/news/2008/080411/full/news.2008.751.html)

> The choice is still taken at the moment.

There is no reason to expect that 'the moment' is the same as when we become aware of it. It's questionable if we can make make any choices within two or three seconds. We just have behaviour that feels like it's our own volition.

<comment><USER35> > _You can detect the choice from the brain up to seven seconds before when > people are asked to push a button any time they feel the urge. (...) There > is no reason to expect that 'the moment' is the same as when we become aware > of it. It's questionable if we can make make any choices within two or three > seconds. We just have behaviour that feels like it's our own volition._

Of course it's our own volition.

Do you see anybody else there telling the person what to do? Is there some "eternal soul" that should have been informed to make the final decision?

The misleading dichotomy here is that the conscious urge is something different from the "choice from the brain up".

Whereas the conscious urge is just a later manifestation of the "brain up" process. It's just a nicer UI output we give ourselves of the choice process.

It's still our brains, that is us (there's no third party involved), that makes the decision, based on our past experience, knowledge, preferences, memories, etc as wired in our brains.

Whether we do it at the conscious layer or we do it at the lower level and then project it at the conscious layer doesn't make it any less of "our own volition".

To me it's like saying "the computer didn't make this picture, because the picture was already created in the memory as a structure before it was send to the screen".

<comment><USER36> >Do you see anybody else there telling the person what to do? Is there some "eternal soul" that should have been informed to make the final decision?

Obviously not, but commonly when people refer to so called 'free will', they don't just mean to imply that you, as a physical entity carry out things by your own volition, it is taken to mean that you consciously deliberate on your choices and have some insight into your own decision making.

These experiments suggests that the actual decision making happens at a much more secluded, black box like level.

Free will, in a meaningful sense, is taken to mean 'rational control', not just 'that guy over there acts in some way because his brain commands him to', because that's true almost by definition if you exclude religious explanations.

<comment><USER37> I don't see how any of that negates the idea of rational control in the sense that we commonly understand it. The series of physical events in the brain that lead to a decision are not subject to an out of band process that can override the final conclusion; it doesn't seem surprising that there is a delay between the unconscious processes that underpin our rational thoughts and the eventual culmination of a decision, IMO the _opposite_ would actually be the surprising result (i.e. our conscious mind is not a supervenient product of our unconscious brain and supporting biological processes)

</comment></comment></comment></comment></comment><comment> your-nanny choice can be predicted with eye tracking. so what.

</comment><comment><USER38> N=14. This is a preliminary study, not something you should change behaviour or beliefs nor cast policy based on.

<comment><USER39> Even N=1 would be interesting. Not everything has to use a cohort of thousands - when you're demonstrating the existence of a phenomenon, a single case will suffice.

<comment><USER40> Oh thats not like this, if you give me N=1000, i can probably prove anything for N=10 (considering bad intentions)

So basically for big N's, study is much trustworthy.

<comment><USER41> Give N=7.5 billion find me N=1 person that is 300 years old, or one that can fly.

</comment></comment></comment></comment><comment><USER42> > "In, other words, if any pre-existing brain activity matches one of your > choices, then your brain will be more likely to pick that option as it gets > boosted by the pre-existing brain activity.""

We have biases. Sometime we are aware of them. Sometimes, evidently, in trivial situations, we don't notice such patterns.

"Be mindful of your biases" just took on a wider scope.

</comment><comment><USER40> \- They are showing 2 images.

\- maximum duration to choose is 20 seconds.

So basically if you look one of them 10 seconds, seconds one 10 seconds. And make your choice. They can see your choice when they go back in your brain activity 11 seconds before.

(If they can with MRI can see how much you like something while you are looking)

So basically nothing much value here.

(PS: when i see 'upto 11 seconds', this sounds like marketing talk)

<comment><USER43> I understood that they show both images simultaneously. Can someone look at the research paper?

(I also don't like the "up to 11 seconds".)</comment></comment>


Show HN: Given an API, Generate client libraries in Node, Python, PHP, Ruby - <AUTHOR> https://github.com/pksunkara/alpaca PS: Assuming a REST architecture. <comment><USER2> Wouldn't it be wiser to choose a hypermedia format for the API, and then use a generic hypermedia client on whichever platform you like? Then you write just as many client libraries (zero), but the problem of pushing updates to your clients is solved as well.

Full disclosure: I wrote such a library for Ruby, called HyperResource. [https://github.com/gamache/hyperresource](https://github.com/gamache/hyperresource)

<comment><USER3> I've read most of the book _RESTful Web APIs_ , which advocates Hypermedia as a way to stop having to create client-specific libraries for each and every Web API. But the book doesn't say much about creating such clients.

Is there such a generic Hypermedia client for Python?

How does this affects performance? Navigating through the _maze_ of a Hypermedia API requires many more requests than just hitting a known endpoint, doesn't it? Do hypermedia clients provide client-side caching?

My other concern is that those APIs might be harder to learn than ad hoc _fiat_ standard. The reason why RESTful-ish APIs have been successful is because they don't add any overhead on top of the things they're representing. At first glance, stuff like JSON-LD, Siren, HAL, etc. seem to be bringing back the complexity of things like SOAP that people have fled from.

<comment><USER2> The client space is slowly filling in. There are a bunch of clients which still leave the plumbing exposed (a couple good ones are HyperClient.rb[1] and HyperAgent.js[2]) -- it still feels like you're making HTTP requests.

One of the things I like most about hypermedia is that the hyperlinks can represent a complete set of functions which can be applied to an object. In other words, each object contains its own method list. This fits well in languages which get to implement catch-all methods, like Ruby, and I couldn't resist coding up a client that worked that way.

(There's room for this sort of trickery in near-future ECMAScript too, with Proxy[3]. I would really like someone to do this and I would kind of like it to not be me.)

When you lay out your API according to that philosophy, and cache a few "stepping-stone" objects you'll be traversing often, hypermedia APIs don't seem so inefficient at all.

As to your last point: take a look at HAL[4]. It sits alongside a "traditional" API layout very nicely, essentially adding "_links" and "_embedded" which can be safely ignored by non-hypermedia clients. The HAL spec is extremely sane.

[1] [https://github.com/codegram/hyperclient](https://github.com/codegram/hyperclient)

[2] [http://weluse.github.io/hyperagent/](http://weluse.github.io/hyperagent/)

[3] [https://developer.mozilla.org/en- US/docs/Web/JavaScript/Refe...](https://developer.mozilla.org/en- US/docs/Web/JavaScript/Reference/Global_Objects/Proxy)

[4] [http://stateless.co/hal_specification.html](http://stateless.co/hal_specification.html)

<comment><USER3> Thank you and Steve for your replies.

You both seem to recommend HAL over other Hypermedia formats. In their book, Richardson & Amundsen mention that HAL doesn't allow to tell the client which HTTP methods to use when doing state transitions. They say that HAL is therefore only suited for read-only APIs. What do you think of that?

<comment><USER4> Link relations can be designed that indicate which HTTP methods are allowed. HAL is heavily dependent on conveying semantics via link relations, which is something that some people don't like doing.

Consider the oauth2-token link relation defined here[1]. The definition of this link relation refers to RFC 6749 [2] which states that it is necessary to pass a application/x-www-form-urlencoded body using POST.

[1] [https://tools.ietf.org/html/draft-wmills-oauth- lrdd-07#secti...](https://tools.ietf.org/html/draft-wmills-oauth- lrdd-07#section-3.2) [2] [https://tools.ietf.org/html/rfc6749#section-4.1.3](https://tools.ietf.org/html/rfc6749#section-4.1.3)

</comment></comment></comment></comment></comment><comment><AUTHOR> Author here. I covered almost everything in the documentation. And there is also a small example which is hosted at [https://github.com/alpaca- api](https://github.com/alpaca-api).

Please ask if you have any questions. Thanks

<comment><USER5> How do you differ from Swagger, Blueprint, I/O Docs, RAML and all these API endpoint descriptions?

<comment><AUTHOR> I tried searching for a program which generates client libraries in different programming languages and failed.

Could you please link if something does it? From what I gather, the above mentioned sites only provide methods of describing the API and/or Automating the API on the server side. Nothing is said about client libraries.

Thanks

<comment><USER6> [http://thrift.apache.org/](http://thrift.apache.org/)

<comment><USER7> I think that _creates_ an API, then exposes it in numerous languages. This writes wrappers to _existing_ APIs. Not the same thing. (Lots of code similarity under the hood, though.)

<comment><USER6> No, it actually does both - which is why I was so interested in it initially.

from the above link: "generates code to be used to easily build RPC clients _and_ servers"

TBF, I haven't used it as a developer, but I did contract work with a company that had invested in it heavily. From what I saw of their workflow, it ended up being a pretty nice bootstrap tool and little more.

edit: Oh, I see what you're saying. Yes, you're correct - thrift does _not_ wrap existing APIs.

</comment></comment></comment></comment></comment></comment><comment><USER8> Just tried this out and Alpaca is an awesome tool. However, I'd never want to release this in production without tests. Alpaca doesn't generate tests, so you're back to maintaining the tests for your N different platforms/languages. But you'd have the same problem with its competitors, too; Thrift [0], for instance, doesn't generate tests either.

Overall, I'm not sure that the time savings is as big as it first appears, but I think it's great for quick projects.

[0] [http://thrift.apache.org/](http://thrift.apache.org/)

<comment><AUTHOR> Tests is one of the main priority and I am planning to do them soon.

This current program just a small step in the right direction. :)

EDIT: Currently, I have a test suite at [https://github.com/pksunkara/alpaca/tree/testing](https://github.com/pksunkara/alpaca/tree/testing) which tests the generated client libraries of an example API with the respective server.

<comment><USER9> That sounds cool! Is there a way to automatically generate BDD style Tests? Have a look at [http://funkload.nuxeo.org/intro.html](http://funkload.nuxeo.org/intro.html)

</comment></comment></comment><comment><USER10> I like the SPORE (Specification to a POrtable Rest Environment) approach better. You create a description file in JSON and each native language client can use that file to access the HTTP API. [https://github.com/SPORE/specifications](https://github.com/SPORE/specifications)

SPORE already has clients for Clojure, Javascript, Lua, NodeJS, Perl, Python, and Ruby. I have used SPORE in a few projects and I was not disappointed. Another approach to solving the cross language library problem.

<comment><USER11> Looks promising.

Too bad the last commit was 2 years ago...

<comment><USER12> Maybe it is finished?

</comment></comment></comment><comment><USER13> This is cool. I would suggest that it would be very useful to have this kind of thing for JSON Schema [1], which is what I use with Python code to validate incoming JSON. (I was originally hesitant to using that, but since getting into it, I have yet to run into a use case which it cannot handle.)

There is also an RFC for "JSON Hyper Schema" which is intended to describe REST APIs. It doesn't have much library support in much of everything, but I am surprised that it hasn't taken off!

I like that this library is fairly opinionated (options for how to authenticate, supported formats, etc.) Though I worry that that creates a bit of inflexibility - for what exactly does "oauth" actually mean, there are always vagaries.

Neato!

[1] [http://json-schema.org/](http://json-schema.org/)

</comment><comment><USER14> Am I right in thinking about this like a WSDL, but based on JSON?

<comment><AUTHOR> Being a WSDL is not the aim here. Generating client libraries in multiple programming languages is.

But, to do that I need a format using which people can define their API. I used JSON and only supported the elements that I needed to generate the client libraries.

<comment><USER14> Right, the format affords generic description documents from which to generate client code. This seems very similar in spirit to WSDL. No?

<comment><USER15> WSDL is not a method in itself for actually generating the client code, though. It's simply a (barely) machine readable description of the API from which clients decide how to deal with it.

EDIT: Since I was down-voted for whatever reason, I'd like to rephrase. WSDL is a standardized language for defining web services. It's not a tool in itself for generating client code, and what I said was meant to point out that that's the obvious difference between this and WSDL. A description written in WSDL can both be used to generate client APIs and skeleton code for the server itself, but isn't the generator itself, just like C isn't gcc.

<comment><USER16> You're being downvoted because this project is a generator program which, as input, takes a specification of the API in JSON format. This JSON specification is what is being compared to WSDL because they serve the same purpose: to define the endpoints, arguments, and return values for a given API.

<comment><USER15> I agree with that, but I am correct in pointing out that the scope of this project covers things that WSDL does not, and in that sense it isn't like WSDL. When someone asks a question that can easily be answered in terms of differences I think it's completely reasonable to point those out.

Perhaps my parent intended for the question to be rhetorical, with the implied answer being "Yes, I'm silly for reinventing the wheel" in which case the differences between this project and WSDL are an also an obvious defense of it.

<comment><USER16> The comment you replied to said:

      > Right, the format affords generic description documents
      > from which to generate client code. This seems very
      > similar in spirit to WSDL. No?

The word "this" in the second sentence clearly refers to "the format". To reword the parent:

      > The JSON format used by this project seems very similar
      > in spirit to WSDL. No?

So while you're correct that the entirety of the project (JSON format + code generation) is greater in scope than just WSDL, you took exception to a claim the parent did not make. You could equally have said:

      > The JSON format used by this project is not a method in
      > itself for actually generating the client code, though.
      > It's simply a (barely) machine readable description of
      > the API from which [the project's code-generating client]
      > decides how to deal with it.

I don't think anyone thought otherwise.

</comment></comment></comment></comment></comment></comment></comment><comment><USER17> I think this is fantastic. @sunkarapk, great job. That it's written in Go makes using it so much easier. Wonderful.

</comment><comment><USER18> I have to admit, this is very reminiscent of "Add Service Reference" in Visual Studio, a capability to which I have grown to despise over the years. The code was almost always incomprehensible. I cannot tell you how much I loath seeing the comment at the top of a file "This was generated by a tool".

Having said that, this tool does look interesting. I hope that a goal is to always make sure that the generated code is as readable, and maintainable, as possible. Also, as mentioned by others, adding generated tests to the generated client libraries is extremely important.

<comment><AUTHOR> You can go through the generated code examples at [https://github.com/alpaca- api](https://github.com/alpaca-api).

I tried to make them a lot more readable. :)

</comment></comment><comment><USER19> Describing an API is not hard, but the API authentication method is. How do you think you will do it?

Edit : If you don't make oauth consumption simpler, you don't really solve the problem

<comment><AUTHOR> Currently, I am supporting 3 authentication strategies. Basic, Token in header and OAUTH.

These will cover most of the APIs. And I am open to include other kind of authentication strategies too.

[https://github.com/pksunkara/alpaca#authorization- strategies](https://github.com/pksunkara/alpaca#authorization-strategies)

EDIT: OAUTH Consumption is not the main priority here. The problem I intended to solve is automating the development and maintaing of API client libraries in several different languages.

That said, I intend to add support for OAUTH consumption too.

</comment></comment><comment><USER20> Very cool, but why come up with a new API schema rather than use an open standard like OData ([http://www.odata.org/](http://www.odata.org/))? Then Alpaca would be compatible with a bunch of APIs that already exist today. In fact, something like this (generating client libraries from APIs) may exist for OData already, but if it does, I've only seen it for .NET and OData (Visual Studio 'Add Service Reference').

This is actually pretty similar to a side project I've been working on called Gargl (Generic API Recorder and Generator Lite) ([https://github.com/jodoglevy/gargl](https://github.com/jodoglevy/gargl)). Haven't gotten around to doing a Show HN post yet, but would love any feedback or to combine efforts. Basically it lets you generate an API for websites that don't have APIs publically available, by looking at how a web page / form submission of that web site interacts with the web server. You record web requests you make while normally browsing a website via a chrome extension, parameterize them as needed, and then output your "API" to a template file. Then this template file can be converted to a client library in a programming language of your choosing.

</comment><comment><USER21> So, this is markedly similar to the project I've been working on in grad school, only without static typing. [http://research.cs.vt.edu/vtspaces/realtimeweb/](http://research.cs.vt.edu/vtspaces/realtimeweb/) Also, mine is explicitly geared towards education purposes. I'm about one third of the way thru version two, but I wonder if we can cross pollinate our code bases to get something even better.

</comment><comment><USER22> Can we please stop calling Web Services APIs?

<comment><USER23> Why? what else do you call APIs?

<comment><USER24> Libraries have APIs too.

</comment></comment></comment><comment><USER25> Does this use the Json Schema spec or have you reinvented the wheel?

<comment><AUTHOR> JSON Schema is too complex for this project. I just chose the fields which needs to be populated so that I can generate the code.

<comment><USER26> Not that I would defend JSON Schema, but yes, you did just reinvent the wheel, and it was also not a new idea. I thought that despite the verbosity of XML, WSDL and associated technologies solved this problem rather better. I have the misfortune to develop in PHP, so pardon the example, but the client-side code went something like this:

$PayPal = new SoapClient($WSDLLocation); $PayPal->SomeMethod();

Yes, you can get away with having a less verbose description language if your needs are simpler, but that to me just ends up moving the problem _when_ your needs become less simple. It's not like you can avoid validating your requests in some way, and required/not required is where that starts -- but, I maintain, not sufficient. I most definitely fail to see client code generation as being a necessary step.

You could say I've made this mistake myself; the thought process that leads to code like this must not be unique. Web services need documentation if they are to be used, and since that code will only ever talk to other code, it makes sense to have a machine-parseable description. Language agnosticism follows as a matter of course. I'm willing to entertain that XML was a bad idea and JSON Schema is not an improvement, but I still feel that if one must reinvent the concept of a language-agnostic machine-parseable web services description language, one should thoroughly understand the prior art. It may be complex for a reason, and like it or not all that SOAP stuff actually tends to work pretty well. I'm sure I have every reason for wanting to see a better technology suite which is JSON based, and I wish this were it. At the moment I don't think you're headed in quite the right direction.

</comment></comment></comment><comment><USER27> Regarding bug reports:

> Guaranteed reply within a day.

That seems difficult to achieve--wonder how they're doing that? (Also, why??)

<comment><AUTHOR> I am just a single guy. I always make a point to reply back to issues/pull- requests on my open source projects within 24hrs.

Yes, sometimes I fail to make it. But it's a rule I want to live by.

<comment><USER28> Good luck. I found a six month old PR on one of my projects the other day....

</comment></comment></comment><comment><USER29> That looks fantastic, and seems to be in alignment with some things I have been doing lately (generating the server side controller of the API in Clojure + a set of documentation, from a set of definitions of API methods). Good job!

</comment><comment><USER30> Well done!

Know what I think would be really neat? If it could be pointed at an instance of Swagger-UI, or use the same discoverUrl that Swagger-UI would use, and spit out the libraries from that.

If you're not familiar.. [https://github.com/wordnik/swagger- ui](https://github.com/wordnik/swagger-ui)

</comment><comment><USER31> I did something similar for Go and Java. It's simpler if you don't need the whole API, but of course not as powerful. [https://github.com/bashtian/jsonutils](https://github.com/bashtian/jsonutils)

</comment><comment><USER32> fwiw, I experimented along this line, dynamically generating python wrappers from yaml: [https://github.com/reklaklislaw/rest_easy](https://github.com/reklaklislaw/rest_easy)

It lacks documentation, a bunch of features, and parts smell pretty bad, but since the topic came up I thought maybe someone would find it interesting, if only vaguely.

</comment><comment><USER33> Useful, well-documented, TODOs right in the readme, and fast response for pull requests. I wish every open source project was like this.

</comment><comment><USER34> Great idea! Including Obj-C would be very helpful.

</comment><comment><USER35> I've been enjoying [http://apiblueprint.org](http://apiblueprint.org)

<comment><USER36> The web page was very pretty, but I still have no idea what this is/does. Help?

</comment></comment><comment><USER37> oh man you just killed a major feature of mashape.com

<comment><USER38> Client library generation is something that mashape supports, but currently they generate libraries for:

Java, Node, PHP, Python, Objective-C, Ruby, and .NET

It looks like alpaca supports:

Java, Go, Perl, Clojure, Scala, Obj-C</comment></comment>


Chilly cages may skew disease studies in lab mice - <AUTHOR> https://www.sciencenews.org/article/chilly-cages-may-skew-disease-studies-lab-mice?tgt=nr <comment><USER2> I've never understood why we use mice for diet studies, when the diet they've adapted to would appear to be so different from the diet humans have adapted to.

<comment><USER3> It's because mice weren't included in the Animal Welfare Act of 1966, while other major model organisms were. This made mice much easier to use, and then the widespread use of mice caused infrastructure to build up around supporting studies of them. It led the whole field into a deeply confused quagmire.

</comment></comment><comment><AUTHOR> Supposedly, murine models are the closest analog to many human processes with manageable size and price. Plus, they fit easily into any microwave at snack time.

They don't correlate well at all in some areas, like brown fat (humans don't have a significant amount)

</comment><comment><USER4> The more interesting result is that cold temperatures apparently are very beneficial!

It should be interesting to try to replicate this to humans.

<comment><AUTHOR> Cold also is generally beneficial at making you burn energy and helps HGH release, so I finish showers with cold-ish water.

Most Americans overheat their homes, IMHO -- certainly in my family.</comment></comment>


Men write code from Mars, women write more helpful code from Venus - <AUTHOR> http://blogs.wsj.com/biztech/2008/06/06/men-write-code-from-mars-women-write-more-helpful-code-from-venus/

<comment><USER2> Love the comments at the bottom. Especially:

      We don't "all know that men hate to ask for directions,"
      Rebecca. This is a stereotype created to protect women
      from the embarrassment that they are poor map readers. A
      man reads a map, if he can, and asks directions if he
      must. A woman asks directons only, because a map is not
      helpful to her.

</comment><comment><USER3> Sounds like someone has a chip on their shoulder.

> "McGrattan boasts that 70% to 80% of the time, she can look at a chunk of > computer code and tell if it was written by a man or a woman."

...

> "because only about 20% of the engineers are women, McGrattan says"

Holy crap, she can tell whether code is written by a man or a woman at a slightly worse rate than random chance.

I have a picture in my head of how these standards work out:

int a = 0; //create an integer variable and initialize it to zero.

<comment><USER4> That's the first thing that popped into my head when I read that sentence. Hey, me too! Male, male, male, male, male. 4/5 correct. I'm a genius.

70% to 80% of the time I can also guess whether a date in history was a weekday, whether the stock market will rise or fall for a calendar year, and whether your last bathroom visit was a #1 or #2.

Ok, back to writing my cryptic non-commented strings of computer instructions.

Also, your code should read like this for _extra_ safeness:

int a; // create an integer variable

a = 0; // initialize it to zero

</comment></comment><comment><USER5> First I read about the code men write to send TO Mars (Phoenix rover) and now I find out that its actually FROM Mars.

It seems as though one of these stories is factual and the other . . .

</comment><comment><AUTHOR> I posted this here so it would get the ridicule it deserves.</comment>


UK juror jailed after researching case on internet - <AUTHOR> http://www.computerworlduk.com/news/it-business/3331921/juror-jailed-after-researching-case-on-internet/

<comment><USER2> > _Dallas, a psychology lecturer at the University of Bedfordshire, is Greek > and has said her grasp of some technical English is not good. [...]_

> _"I did not understand that I could make no search on the internet," she > said. "I really apologise. I never thought it would cause such disruption."_

Was she competent to be a juror?

(see also (<http://news.ycombinator.com/item?id=3500267)>)

</comment><comment><USER3> Stupid: not for researching the case on the internet, but for blabbing about it.

Many jurors, including myself, will look something up themselves on a multi- day trial, that's common. The point is to see whether or not a defendant is a habitual offender or someone who can deservedly be given the benefit of a doubt.

<comment><USER4> You're supposed to consider only what's presented in court. Your behavior could lead to someone being unjustly convicted. The cops could pick up someone who is innocent of the specific crime, but who they know has a record.

<comment><USER3> I don't care (sort of). Where I live criminals literally get away with murder before receiving any significant time in jail and probation is considered a joke.

Jurors DO CHECK PUBLIC RECORDS of defendants. It happens and it is perhaps time for the courts to accept this reality. Don't worry though, there's also plenty of jurors who dis-regard testimony of police and will gladly let a criminal off regardless of evidence.</comment></comment></comment>


Back end-less client notifications - <AUTHOR> http://ultrapush.ws/ <comment><USER2> Like so many other things, this isn't "back end less" or "server less" \- it's just running on someone else's servers.. So you have zero control, are dependent on them, and potentially expose sensitive information about your users to them.</comment>


Avro: A Format for Big Data - <AUTHOR> http://www.cloudera.com/blog/2009/11/02/avro-a-format-for-big-data/

<comment><AUTHOR> Digg will be hosting an Avro hackathon on Thursday, November 19. Sign up if you'd like to hack! <http://avrohackathon.eventbrite.com/>

</comment><comment><USER2> Can someone with more experience with these formats compare Avro to BERT/BERT- RPC? Is that an inappropriate comparison?</comment>