The 3 Programming Languages you need to Know - <AUTHOR> http://blog.mathgladiator.com/2010/11/3-programming-languages-you-need-to.html <comment><USER4> Meaningless. I do not have a thinking language or a bread and butter language or a GTD language. I have apps (or tasks) that involve thinking, or are "just programming", or are "just get it done".

Sometimes I write quick scripts in Haskell. Sometimes I write them in Perl. Sometimes I write complex web applications in Haskell. Sometimes I write them in Perl. I choose the language based on good libraries for the task I am trying to achieve? I use Perl for network servers because libev performs better than GHC's select-based threads. I use Haskell for things that need to start up quickly. I use Perl for glue.

I don't think in Perl or Haskell or C or anything. I think in programming. I often find a nice way to express what I mean in the language I chose. Some problems look nicer in Haskell than in Perl. In the end, though, it's just programming. And while the programming part is 90% of the work in creating a working application, the other 90% is interacting with the outside world built by other people. Elegant syntax and beautiful algorithms are meaningless if you can't connect to the Foo server and get your data.

Incidentally, I always use C for libraries that need to be used my many people. C is not my favorite langauge, but I've accepted that if I manage memory correctly (client always allocates, data structures are structs with foo_ok flags) and don't use cstrings, C is not that bad. You just kind of tell the computer what to do, and it gets done. And then I can use it from Perl and Haskell with only a few more lines of code. And you can use it from OCaml and Python with just a few more.

<comment><USER5> >I don't think in Perl or Haskell or C or anything. I think in programming.

This is a good point, I tend to do this as well. I think up how I want to attack the problem first and then how to translate it into the language I'm going to use.

The only thing that sounds strange to me is that in every situation you end up with either perl or Haskell. Is this a job constraint? I would think, for example, that in certain cases Erlang might be the best choice if one is doing work that lends itself to message passing, object database, etc.

Personally, after I've come up with how I'm going to do something I tend to choose the language that will be the least amount of work (constrained by what languages are an option of course, in the case of programming for dollars).

<comment><USER6> "The only thing that sounds strange to me is that in every situation you end up with either perl or Haskell."

And C.

Perl sounds a little bit like his "get things done" language.

"I choose the language based on good libraries for the task I am trying to achieve."

With CPAN, that is going to be Perl the most of the time, certainly much more often than Haskell or C.

C sounds a little bit like his "bread and butter" language:

"Incidentally, I always use C for libraries that need to be used my many people."

Not exactly the same concept, maybe, but the importance of working on a team effectively is there.

I will have to take his word for it the jrockway does not have a Happiness language. But Haskell is certainly a good candidate for one.

Maybe a better definition of a Happiness language is a Just for Fun language. What language do you gravitate towards when you do not have a dollar denominated task in front of you, but just want to have some fun on your computer?

</comment></comment></comment><comment><USER7> Hey you kids, get off my lawn!

      1960s:
      Happiness Language:    Lisp
      Hack-it-out Language:  Assembly
      Bread and Butter:      COBOL

      1970s:
      Happiness Language:    Lisp
      Hack-it-out Language:  FORTRAN
      Bread and Butter:      BASIC

      1980s:
      Happiness Language:    Lisp
      Hack-it-out Language:  C
      Bread and Butter:      QBasic

      1990s:
      Happiness Language:    Lisp
      Hack-it-out Language:  C++
      Bread and Butter:      Visual Basic

      2000s:
      Happiness Language:    Lisp
      Hack-it-out Language:  C#
      Bread and Butter:      PHP

      2010s:
      Happiness Language:    Lisp
      Hack-it-out Language:  Python
      Bread and Butter:      Ruby

[EDIT: Added "s" to change significance from year to decade.]

<comment><USER8> Was there really a time period where BASIC and QBasic were bread and butter languages? I thought they were toy languages, like Logo.

<comment><USER7> _Was there really a time period where BASIC and QBasic were bread and butter languages?_

Yes. From the time they were introduced until today.

 _I thought they were toy languages..._

Don't kid yourself. I am aware of 3 different full blown enterprise packages written in 100% BASIC. Inventory, accounting, production, order processing, ERP, CRM, etc. still running multi-billion dollar companies all over the world. Now here comes the good part...2 or them were written by 2 people and the third was _written by one person_.

This thread started out a little in jest, but there is (and always was) a moral to the story: You can write almost anything in almost any language. The proficiency of the practitioner is way more important than the tool being used.

<comment><USER8> Good to know... but that's not the description of a "bread and butter language", at least, not by the definition in the OP. Or else, Lisp, Haskell and Prolog would all be BBLs! I wasn't around in the 60s to witness software development, but when I think of a BBL today, I think: Java.

If you want to revise your history made in jest, I'd be curious to see the result.

<comment><USER9> No way, it's the exact definition:

> This is the language that you can use to keep yourself alive when life hands > you lemons. This is the language that you know just in case you need to > hustle yourself to provide for yourself and your family.

If you're the one dude who wrote an entire package that runs a billion dollar multinational, you can pretty much charge whatever you want. It's like the ultimate job security. Any changes have to be made through you.

<comment><USER8> _If you're the one dude who wrote an entire package that runs a billion dollar multinational, you can pretty much charge whatever you want. It's like the ultimate job security. Any changes have to be made through you._

That's true regardless of the language.

<comment><USER9> Absolutely. But that's why BASIC is his bread and butter.

<comment><USER8> Ah, so that's where the confusion comes from. I thought that edw519's post was about "The _typical_ bread-an-butter language in the 70's, in the 80's, etc."

I'd still be curious to know what were the _de facto_ languages to get a good salary in the 60s, 70s and 80s.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER10> One of the best related comments I've seen on this topic was by coffeemug a few weeks ago:

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

 _"1. Be good. Be very good. Don't be the "front-end guy" or the "back-end guy", or some other "guy". Once you know what you want to build, building software is about five things: algorithms that solve your problem, programming languages that express your algorithms, computer architecture that makes your algorithms run efficiently on real hardware, the practical toolchain, and the management of complexity of real software. So study algorithms, and then graduate algorithms, and then advanced graduate algorithms. Do every challenge problem online. Study programming languages to express those algorithms. You can get away with three: C, Lisp, Haskell. Everything else is crud. ..."_

I interpreted that to mean that C, Lisp, and Haskell are best at expressing the most difficult algorithms and concepts in computer science and software engineering, while simultaneously giving one the conceptual understanding and ability to quickly use easier languages like Python or Ruby for glue, utility, etc.

<comment><USER11> I'd suggest ML rather than (or as a complement to) Haskell. The pervasive laziness in Haskell makes it rather unique - sometimes in a good way, but it means that algorithms often don't translate well to non-lazy languages.

ML is just as good for algorithms & complex data structures (H-M+ inferred static typing, pattern matching, etc.), and has optional laziness (in OCaml, and IIRC as an extension to some SML implementations), but is usually easier to translate to more conventional languages as necessary.

<comment><USER10> Thanks, that's good to hear. I'm working through the Little MLer right now. Good intro, but I'd be interested recommendations for other good books on ML.

<comment><USER11> _The Little MLer_, first and foremost - it seems to be the best intro to the ML-style type system.

My ML experience has mostly been OCaml-flavored. The best OCaml book I've seen is _Developing Applications with Objective Caml_ (In French, but a free English translation is online at <http://caml.inria.fr/pub/docs/oreilly- book/html/index.html>). It covers a slightly older version of the language, but that mostly impacts libraries.

Andrew Appel's _Modern Compiler Implementation in ML_ and _Compiling with Continuations_ are both great compiler books, which happen to use SML for the code.

Joshua Smith's _Practical OCaml_ is bad. _Really_ bad. I was shocked. Avoid.

Chris Okasaki's _Purely Functional Data Structures_ is a great data structure / algorithm book, and uses SML (but has an appendix with Haskell versions). Also quite good.

Finally, experience with Lisp, Prolog, and Haskell carry over to ML somewhat, if you've used those.

<comment><USER10> Great list, thank you. I've been eying _Purely Functional Data Structures_ on Amazon, good to have a HN testimonial on that one. Will add that to my shopping cart for the next batch I buy.

I've also been looking at _Modern Compiler Implementation in ML_ , but have no experience in compilers (no courses, work, anything). Should I read Aho first, or is that one I could dive right into?

<comment><USER11> > Should I read Aho first, or is that one I could dive right into?

I haven't read the newer edition of the dragon book, but MCIiML is a _much_ better starting place than the old dragon.

Relevant recent comments: <http://news.ycombinator.com/item?id=1820858> (on parsing + how I feel about the dragon book) <http://news.ycombinator.com/item?id=1822515> (more book, etc. suggestios)

<comment><USER10> Great, thank you!

</comment></comment></comment></comment></comment></comment></comment><comment><USER12> I strongly suspect that these three are not intended to be mutually exclusive.

For me, Python has at some point or another been in each category, though at most two simultaneously.

And for those of us who do web development, "bread and butter" can easily include a half dozen languages or more. After leaving a project where I personally (no joke) used AS3, Awk, C, C++, C#, Java, JavaScript, Perl, PHP, Python, and SQL (sqlite, MySQL, and Postgres!) [1], my current position is just a trivially "polyglot" mix of C++ and Java desktop apps. Before that, I was constantly afraid that I'd forever be doomed to be a jack of all trades, master of none, but now the majority of my time is gobbled up by languages I don't like very much. Can't have it both ways...

[1] mostly by accident, as the powers that be could never make up their minds about what they actually wanted

<comment><USER13> Yeah that was my answer:

Python Python Python

<comment><USER14> Mine was similar, Python Python C/Java. Though there are half a dozen others that I am perfectly comfortable with.

</comment></comment></comment><comment><USER15> Lisp is my happiness language, and everything else isn't. So for me there are really two types.

Every language that's not Lisp, while obviously inferior, usually has some domain-specific use.

I do get a huge kick out of C and assembly when I get the chance to do something low-level. It's a lot of fun to get in there and make something totally non-portable that runs 1000 times faster than the equivalent C++ program.

Getting small things done quickly used to mean Perl, but recently I've started to use Lisp for short scripts because Perl's built-in data structures are so poorly implemented. Last week I was playing around with parsing huge volumes of U.S. census data, which should have been Perl's bread and butter, but ten lines into the Perl script I missed map and nested lists so I switched to Lisp and was done in short order.

I've done a few things with Python, but nearly every design decision they made early on rubs me the wrong way.

I like Javascript for the same reasons I love Lisp. I have a feeling I'd really like Haskell if I could find the time to learn it fully.

And then there are the languages I consider to be abominations, like C++ and Java. Still, they have some great IDE's and libraries which make up for the language in some cases. I haven't gotten around to C# or F# yet. I don't know if I want to.

There are so few honestly awful programming languages. I have been forced to use a few, including Visual Basic for Applications, Matlab script, and a few other proprietary domain-specific languages that I've long since forgotten.

So three languages? Pssh. Learn as many as you can, enough to complete a useful project or two in each. After you do that, you'll realize that Lisp is the best by far and you've wasted most of your time. But at least you'll KNOW.

<comment><USER5> I agree with much of what you've said but every language is not inferior to Lisp. I would say Haskell is on par (in some ways superior).

The way I rate the power of a language is based on how many "patterns" you need when using it. For example, I find Smalltalk an extremely powerful language but it does have one weakness: dispatching on more than one type requires a pattern (e.g. double dispatch, visitor, etc.). CLOS doesn't have this limitation. But Lisp does have a pattern that Haskell doesn't have: delayed evaluation. Every time you need it you have to reach for a closure or a macro and each of these have design side effects (e.g. macros can't be used as first class functions). Haskell doesn't have this problem because delayed evaluation is how the language works by default.

<comment><USER16> Clojure has some lazy stuff but I agree that Haskell is better in some ways but Haskell has no cool makro-system.

It comes down to static vs. dynamic.

<comment><USER17> Haskell has a cool macro system : template haskell. So it comes down to typing.

</comment></comment></comment></comment><comment><USER18> Ruby Ruby Ruby

For some reason I feel this taints me with a stereotype that doesn't necessarily fit, so (somewhat defensively) I'd like to preempt that by saying I've been writing code for the last 25 years (give or take a year or two). Also, I've never been to Starbucks and I don't use TextMate (but I do own an aging MacBook).

<comment><USER13> I was under the impression that Ruby doesn't fit the kitchen sink aspect of the list. It certainly is a bankable language right now, especially if you are a web dev, and it seems to make lots of people happy. But my impression is the library support is still in the growing stage compared to perl/python.

<comment><USER19> Ruby gems provide enormous amount of functionality. You can do almost anything you want with Ruby, and even when there isn't a library to do exactly what you want, there are enough supporting libraries for you to quickly write the library you need.

<comment><USER20> I concur writing new gems is a good idea as CPAN is often the only reason I have to return to perl for some quick tasks. As CPAN is the grandfather of all package management systems and probably of (inet) shared libraries too it is perfectly clear why rubygems lacks the amount of available solutions to certain problem spaces. Doesn't mean we cannot get there some day :) So I'd say I. let's build more & sometimes better gems and II. use wrappers for C libs where money/time constraints are too significant to DIY (e.g. <https://github.com/ffi/ffi/wiki/Basic-Usage> ) Bottom line: try to share and contribute whenever possible. Love your language diversity :)

</comment></comment></comment></comment><comment><USER21>
      Fun: C
      Hack it out: BASH
      Bread and Butter: LaTeX

Welcome to systems research in academia.

<comment><USER22> Kind of funny in the sense that the bread and butter language of the academia lacks a grammar.

</comment></comment><comment><USER23> Seriously, Python fits the bill for all three categories for me.

</comment><comment><USER24> I like how MathGladiator managed to say something meaningful about programming languages and mostly steer clear from inciting the language war the headline implied.

<comment><USER25> Really? I took it as a "clever" hack for flattering everyone that actually indicates the author has even more to learn. To wit: there's a lot more relativism involved that one might expect at first inspection.

For me, Perl would be a "keep me alive" language. Yet I recognize that there's a lot of truly esoteric and impressive stuff in Perl. My "bread and butter" and my "hack it out" has been Smalltalk, which to a lot of people would be an esoteric "happiness" language. As it happens, it's a language with substantial libraries with which one can get some serious work done. Many languages have played two or all three roles for many different people. Also, lacking a "bread and butter" language is not a sign that someone has difficulty working in teams. It can also be a sign that someone is very good at navigating career pitfalls.

Often what a programmer thinks of a language and how they use it really says more about the programmer than it does about the language.

</comment></comment><comment><USER26> No one language can keep me happy for a long time. So my happiness language changes every year.

GTD - Python (Also my happiness language)

Bread and butter - Java (although that might change too given the recent developments)

<comment><USER27> My happiness language changes regularly too - at the moment it's Arduino's cutdown c/c++ language. Since I got that bit of the hardware working it's going to be Pocessing's java-a-like language next[1]. (A month or two back it was Atmel assembler).

I find my "bread and butter" and Getting things done" languages are both Perl.

[1] Now I've got Arduino driven lasers-on-servos, I need to implement face recognition on live video next...

</comment></comment><comment><USER28> Actually a GTD language means that the Happiness/Bread-and-Butter language is not powerful enough. If your Happiness/Bread-and-Butter language is powerful enough, and you really do use it whenever you can, then you should know how to either find all the libs that you need, or have hacked together the ones that you can't find.

Second, the Happiness language should be your Bread-and-Butter language. If you have a few years to work at learning a language really well, you should devote it to the most powerful language that exists. If you make your Bread- and-Butter language the most powerful language, and your Happiness language the same, you will have a very large programming lever and will be able to get the most done with the highest quality.

</comment><comment><USER5> Happy: Lisp, Haskell, Smalltalk, Ocaml, Self, Newspeak, Erlang

Hacky: Lisp, Python, Bash, Ant

$$$ : C# at the moment, but this one doesn't matter much in practice. My selling point is that with my language experience I can come up to speed on most any language quickly.

Personally I think it's important to learn the most advanced (and pure to that category as possible! [1]) language in each category to get the most tools in your tool belt you can.

OO: Smalltalk (classic OO) and Self (prototype, changes a lot about OO), Lisp (most advanced OO system I'm aware of and different than the rest) Functional: Haskell and Ocaml (for functors).

[1] Multi-paradigm is good for practicality but gives you an easy out when learning something new.

</comment><comment><USER29> I'm a lot more interested in algorithms than in languages these days. I used to be a big language aficionado but I get a lot more out of, for example, teaching myself a new machine learning technique than picking up another language now.

</comment><comment><USER30> Wow, the generalizations are running strong and swift with this article.

If I ever sit around wondering about what your "happiness language" is, you guys all have my permission to throw a pie in my face.

Seriously, one can personalize and over-generalize these things very easily. Programmers are famous for taking three examples and trying to build a templated framework of reality around them. It's probably the worst stupid people trick we have..

I love OCAML and F#, C++ and C#. I can tolerate Javascript and VB in a pinch. I do databases and all sorts of web programming.

But no thanks. I do not need or have a happiness language.

</comment><comment><USER31> 3 languages you need to know: 1) a functional language, 2) an imperative/OOP language, 3) an interpreted language.

</comment><comment><USER32> I guess "Happiness language" and "Hack-it-Out" might overlap.

Happiness - LISP is becoming a BLISS!!

Hacky - Python :):)

Day Job - Very sadly :( :( .... JAVA!!

</comment><comment><USER33> I use a combination of Python, Javascript and Lua. I use Lua with my editor(Textadept), Python for most server side work and Javascript client side. Am currently working on using JS server side as well.

Three languages is too limiting though - I plan to reintroduce Haskell and Scheme at some point into the fold.

</comment><comment><USER34> Actually: no.

I don't get the reasoning behind this. If there should be some languages everyone should atleast now, it would be one of each of these categories:

      hardware (asm or atleast some basic knowledge of how the thing works you program for)
      low-level (C, good base for procedural programming)
      high-level (java, good base for object oriented programming)
      script (.pl, .py, lua, etc.)

Somewhere in between there may be a functional languague (erlang, lisp, haskell, etc.) but i, myself, never needed one. What really came handy overall is to know some basic stuff (assembler) for insight in how stuff works, plus C knowledge because the tools, libraries and languages you use are likely based on C. Plus Java, because it's almost everywhere and some script language to get things done ;)

<comment><USER35> Even if you never use it in directly, knowing a functional language can give you a new way of thinking about how you structure your code in procedural or OO languages. That can sometimes lead to more elegant code. Apart from that detail I agree with you.

<comment><USER34> Yes, i guess so. It's on my list of things to learn.

</comment></comment></comment><comment><USER36> 1\. Python (used to be Lisp) 2\. Python (used to be Perl) 3\. C++ and occasionally Python

</comment><comment><USER37> I've got my bread-and-butter (PHP) and Python is rapidly becoming my Hack-it- out / GTD language, but I don't have a happiness language. However, Python is making me pretty damn happy...maybe that means I'm just a practical programmer.

</comment><comment><USER38> Happiness language: Actionscript 3

Hack-it-out: Python

$$$: Sadly at the moment Javascript (ugh)

I realize in the current 'zomg everyone hates flash' environment my choice for happiness language might make people look at me a bit strange, but AS3 is really a nice language. As ECMA dialects go I would rather write for the AVM than the browser any day. And when I think in code, it's usually Actionscript. Three years of hard-core Flex hacking will do that.

Python shows some signs of edging its way in as a replacement for my brain- speak, but I sadly don't use enough in my job right now for it to take over.

</comment><comment><USER39> Like others, for me these overlap a lot.

My happiness language isn't the one I think in. I think in Java, and a bit of Javascript for functional programming. However, neither of these are very fun for me. When I have spare time to hack for fun, I'm usually using Ruby or Scala.

My GTD language is PHP, and Java when I need things PHP doesn't provide.

My $$$ languages are Java, PHP, Javascript, and Objective-C (iOS). All of these are languages I'd rather not be coding in, but it's where the jobs are mostly.

There is a lot of overlap there. I think it's because for me productivity IS fun.

</comment><comment><USER40> _Language you think in_ is constraining... unless your language is the best that could ever exist. Of course, if you can only think in it, you couldn't imagine anything better.

Mathematical notation might be a better language to think in than any programming language; but even that is constraining - since mathematicians are constantly inventing new notation, and many mathematicians think in pictures or even... intuition.

Of course, he really meant _for coding_ ; I just wanted to note the bigger picture.

<comment><USER41> > unless your language is the best that could ever exist.

Mine is Scheme, so, yeah. :)

</comment></comment><comment><USER42> Happiness: F#

hack it out: ruby

Bread and butter: C# / php

<comment><USER43> Working mostly with .NET, I'm really trying to get a grip on F# these days. I have no ambitions on becoming as fluent as I am with C#, knowing pretty much all the ins and outs of the language, but just good enough to fool around with it and getting stuff done(tm).

You wouldn't happen to know any good recommendations for books/online resources to get up to speed quickly? How did you get into the language to the point that it's now your happy language?

<comment><USER42> Like every language I learned to program in I had a project and then decided to use that language with that project. I have to admit the first project was killer, it took me a long time to even get the code compiling. But once I had finished and looked at the lack of code I was sold that this was the way to go.

There is a really cool tutorial on writing the game of life in 32 lines of F# or writing the game of life that executes on the GPU using a similarly small amount of code.

<http://tomasp.net/blog/accelerator-life-game.aspx>

Start with a small project and learn the language, once you have a quite specific 'How do I do X?' question there are plenty of examples. I've never been the type person who could pick up a language from a book.

If you're doing ASP.NET google for F# + MVC + NHAML. There is a great tutorial for getting an ASP.NET project going in F#.

I'd say the primary thing that you need to learn for F# is how to convert loops to recursive functions and vice-versa. Also, look into the pipe operator, and figure out how to abuse the hell out of Seq.reduce and Seq.scan.

If you like LINQ and lambda's in C# you'll probably like F#, I'd say that's what really got me interested, I ended up loving LINQ and lambdas and wanted to know more about this whole F# deal. Using the pipe operator makes the whole thing look much more pretty IMHO.

      [0..10]
      |> List.map (fun x -> x*x)
      |> List.reduce (fun a b -> a + b)

vs.

      Enumerable.Range(0,10)
       .Select(x => x*x)
       .Aggregate((a,b) => a+b)

<comment><USER44> Minor refactoring note, since F# seems to bring that out in me: you could change the last bit to "List.reduce (+)". Or you could do the whole thing as "[0..10] |> List.sumBy (fun x -> x*x)"

</comment></comment></comment></comment><comment><USER45> 1\. Euskara (Basque) 2\. English 3\. Mandarin

<comment><USER46> I think people downvote you because the topic is about programming language, not human language.

I have to agree with you though, knowing English and Mandarin are better (at least for me) than knowing programming languages.

<comment><USER45> Ha, actually my point was that human languages ARE programming languages.

But this just demonstrates the general sentiment of the community - programming languages should only be thought of in one, narrow way.

Ok!

<comment><USER47> I don't want to turn this into a philosophical debate, but if what you are saying is true (I hope not), the community is wrong IMHO.

Human languages defines what concepts we are able to think and reason about. I believe that George Orwell showed this perfectly in 1984. By taking away a lot of vocabulary, you are taking away a lot of ways of to express yourself. I think that the term "expression" in regards to programming languages explains why this is important.

I only know Dutch, English and Latin (plus just enough German and French to get around when I´m buying a bread or asking for directions) so in no way I've experienced how a language like Mandarin changes the way in which your thoughts take shape. However, I did have the experience of playing around with Haskell and Lisp (not saying I'm experienced or whatever, I've just toyed around with them in my free time) and they did change some things of how I percieve and think about code. I can´t write code in these languages where I work, but just learning them (and learning their different, but just as valid, viewpont on programming) has changed the way I think about some problems and how I should solve some problems.

Language (whether it's human or programming) is all about expressing ideas in the broadest sense of the word. Knowing more just let's you express more...

<comment><USER45> How do those languages you mentioned as knowing (the human ones) fit into the 3 categories described in the original post?

</comment></comment></comment></comment></comment><comment><USER48> Anything with first class functions works for me. I pretty much program with closures and have no idea what classes and objects mean. Incidentally the first language I really learned was Ruby but I fell in love with how it handled blocks/lambdas and I haven't really looked back since.

<comment><USER13>
        ... have no idea what classes and objects mean ...

I hope you don't have to look for a job with that resume!

<comment><USER48> Looked at any clojure, erlang, javascript, scala, etc. postings lately? Objects and classes are out. Functional programming is in so I'm in good company and you don't have to pray for me at night.

</comment></comment></comment><comment><USER49> Happy: Ruby, javascript Hacky: Ruby, bash BnB: php, javascript, java

</comment><comment><USER50> Happiness - Python or oddly PHP Hack it out - PHP for web or Python for anything else Bread and Butter - C# and Java but I throw in Python to keep me sane

</comment><comment><USER51> * My own DSLs

* Erlang,Python,Octave/Matlab,awk

* C/C++,Java,JavaScript,VBScript,PHP,bash

</comment><comment><USER16> Clojure --> FUN! mmhh maybe bash for hacky stuff and VB to make money <\-- bäähh

</comment><comment><USER52> I guess mine would be:

Ruby - happy language

Perl - hacky language

Java - $$$ language

<comment><USER46> I think you can get more $$$ with PL/SQL, T-SQL, or ABAP.

<comment><USER5> You'd be wrong. There is a lot of money in Java right now.

<comment><USER53> I'm pretty sure the average ABAP developer earns a lot more than the average Java developer - but it's a pretty specialized niche.

Of course, you'd have to paid a _lot_ to do it.

</comment></comment></comment></comment><comment><USER54> Happiness: Python, Scheme, Erlang Hack-it: Python Bread/butter: C#

</comment><comment><USER55> Haskell

Python

C++

</comment><comment><USER56> Python, Bash, PHP

</comment><comment><USER57> For me it's:

Perl - <USER2>

C# - Bread and Butter

Python - <USER3>

Although, there's quite a bit of overlap.

</comment><comment><USER58> C is the only language that there's a strong argument for it being a fundamental language to know. Because almost every other language, OS and device driver is written in it. Not everything, of course, but it's a huge percentage.

I really _like_ some other languages other than C. But it's hard for me to make as strong of a case for any other language as a "must know" language.

<comment><USER59> I think this difficulty to make a strong point towards a single other language is that the area where languages excel are usually populated by multiple languages.

Do you want to look at a good object oriented language? Take a look at one of Python, Java, C#, Ruby and probably Perl with the right modules.

Do you want to take a good look at functional programming? Look at one of Haskell, OCaml, SML or something along these line.

Do you want something to prototype rapidly? Python, Ruby, probably Scala.

Do you want web programming? Ruby on Rails, Django, PHP, one of those.

Do you want embedded programming? Well.. look at C. Or C++ with C embedded, as some maniacs use it.

</comment></comment><comment><USER58> happiness+GTD+bread&butter = Python at the moment, thankfully

</comment><comment><USER60> Python Python Java .</comment>


Ask HN: What makes an API good? - <AUTHOR> I've consumed a great deal of major, public facing APIs over the years, some I've liked more than others. However, I'm writing a series of APIs for a new project, and ahead of starting I've documented the things I like about some APIs and things I don't  about others. For example, uri construction, documentation, response time, flexibility, code samples and organization of taxonomy help me differentiate good and bad.<p>I thought I'd ask, what do you think makes for a good api? <comment><USER4> 1) URL construction: KISS (Keep It Simple Stupid), or as Einstein said, "Everything should be made as simple as possible, but no simpler."

2) Documentation: Code examples, easy things like: "This is what you send, this is what you get." "If you change this, now you get this." Simple example heavy documentation. 1 example is worth a hundred lines of documentation.

3) Response Time: meh. If your at or around 100ms you don't need to worry to much. If people want ~50+ calls per second, then ask them what their use case is, or have them pony up money. Then worry about response time.

4) Flexibility: Largely over rated. You can waste a ton of processing power trying to figure out what the user _meant_ to say. Most of it is wasted, if their query doesn't make sense return an error. Your performance will go up. This hooks into documentation, if your documentation is easy enough to understand you won't have to fuzz the queries.

5) Code Samples: See documentation.

<comment><USER5> Einstein said "Everything should be made as simple as possible, but no simpler" Your misquote means the opposite of what he said.

<comment><USER6> Maybe Einstein should have made his quote simplier.

<comment><USER7> Can you make it simpler?

<comment><USER8> Simpler!

</comment></comment></comment></comment></comment><comment><USER9> First among all things: a good API allows developers to do something enormously useful within their applications which would be prohibitively difficult to do absent the API.

My two favorite APIs are, by a country mile, Twilio and Stripe. They have wonderful documentation, sane design choices, good first-party library support, responsive engineers on standby for questions, curl-able URLs which return human-parseable JSON, yadda yadda, but the most important reason they're my favorite APIs is that they directly enable me to build and sell the things which feed my family.

</comment><comment><USER10> Documentation is 1000x above anything else. This includes sample project(s).

Documentation is without question the deciding factor of whether I'll use a service.

Besides that, I care about support channels, adherence to standards (i.e. correct HTTP status codes), and as few hoops as possible to jump through to start (i.e. a curl command to get my auth key, and away I go)

<comment><USER5> Very true, but it needs to be a specific _type_ of documentation - <USER2> something that explains how to use the API rather than what the API endpoints are. By sitting down and writing about what's needed to get the most out of the API, as well as writing extensive code examples, you're forced to think about how people are going to use the API. Any problems, quirks or bugs should be obvious at that point _because you 're using the API as it'll be used by other developers_. Simply listing the endpoints with what parameters they need and things they'll return won't make your API better.

</comment></comment><comment><USER11> 1) Have the internal team use the same public API as much as possible. I believe Steve Yegge (of Google and Yahoo) wrote a long article about this concept. Here's a link[1] but I can't remember if it's the definitive one I read before. By forcing your internal developers to use the same API, you see the frustrations of any incoherent designs that outsiders would see. Also, bug fixes fix the defects for private & public users.

2) Design the API to encourage clients to stumble into the " _pit of success._ " I believe Microsoft's .NET team originated this phrase.[2] This means sensible defaults for the the most common tasks. It leads to related maxims such as " _make easy tasks easy and hard tasks possible._ "

3) Additional documentation that's organized thematically around "tasks", "workflow", "usage scenarios", and "concepts". It's not enough just to have a dump of functions listed in alphabetical order presented as a "reference guide". The reference guides are important but people unfamiliar with the new API need some handholding and reference guides don't do that. The task- oriented documentation would be things like "Getting Started" or "working demos".

[1][http://apievangelist.com/2012/01/12/the-secret-to-amazons- su...](http://apievangelist.com/2012/01/12/the-secret-to-amazons-success- internal-apis/)

[2][http://blogs.msdn.com/b/brada/archive/2003/10/02/50420.aspx](http://blogs.msdn.com/b/brada/archive/2003/10/02/50420.aspx)

</comment><comment><USER12> Aside from common things like "being useful" the key aspects of a good API (to me) are:

1\. Expose 2\. Wrap 3\. Consistency

Expose what's going on under-the-hood. For example, an HTTP.Get function may do what's needed 98% of the time, but if you don't expose requests, sending, keep-alive, etc. then I won't be able to do the last 2% when I really need it. Part of exposing is factoring your functions well.

Wrap what's exposed to handle the most common cases. If I want to perform a GET request, I shouldn't be required to create a request, open a socket, issue the request, parse the response, follow redirects, etc. There should just be a simple HTTP.Get function that does all that for me with the common options as arguments.

Finally, the API should be consistent. Consistency covers a range of topics. The API should be consistent within itself: consistent naming, modules, etc. It should be consistent within the environment (e.g. don't use underscored function names in Go). But consistency also means future releases shouldn't break existing code unless absolutely necessary.

</comment><comment><USER13> You might want to check out The Little Manual of API Design:

[http://www4.in.tum.de/~blanchet/api- design.pdf](http://www4.in.tum.de/~blanchet/api-design.pdf)

<comment><AUTHOR> Thanks! I will.

</comment></comment><comment><USER14> Some things that irk me:

0\. JSON. Use JSON.

1\. Version your API

2\. Any numerical value whose precise value you care about, send as a string.

3\. Any ID should be sent as a string.

4\. Any timestamp should be sent as RFC3339 UTC.

5\. Any data whose numerical value matters (i.e., must properly include NaNs, whatever) should be sent as an encoded base64 blob.

6\. Properly support HEAD, PUT, PATCH, OPTIONS.

7\. Send back your response as human-readable JSON, with newlines and tabs. If you can't afford the bandwidth (protip: you _can_ ), then you shouldn't be using a text format anyways.

8\. Allow me to change replies using accept headers _and_ extensions on the URI. Document the order of precedence.

9\. Understand the limits of the REST mental model for handling things--don't be afraid to have a _few_ "ugly" endpoints.

</comment><comment><USER15> One vote for _good_ documentation.

Not just a link to the Javadocs; preferably a "getting started" page that covers the most common use cases with plenty of plug and play examples (if such a thing is even possible in your case).

Also, getting back to the API reference, I'm grateful when there is a roadmap or overview of the class/package structure so I don't have to crawl through the entire thing.

<comment><USER16> >Not just a link to the Javadocs; preferably a "getting started" page

I wish more java projects had python-style documentation. I can probably figure out how to do things eventually by wading through Javadocs, but they can be really frustrating if all I need to know is how to accomplish the core activity of the project.

<comment><USER15> Among some, there is a certain "machismo" associated being able to make do with the API reference and nothing else. I think this is a waste of time, personally. I noticed this especially among the Rails developers I've worked with.

</comment></comment></comment><comment><USER17> Client libraries.

Release and support good client libraries for popular programming languages.

This is way more important than documenting your API at all.

Nobody likes having to read the gory details of how your API works and having to write a HTTP client around it. And everytime they do, error handling is badly handled, if at all.

People want to start using your service right away. They want to just call one function to do a thing, without having to worry about how it works underneath.

Even if this is not HTTP, think about MySQL. Used everywhere, via tons of different programming languages. Yet virtually no one knows how the protocol ("API") works. And this is completely fine.

Having good client libraries also allows updating the protocol without requiring users to change their apps.

</comment><comment><USER18> The Heroku platform team has a good document about their API design guidelines:

[https://github.com/interagent/http-api- design](https://github.com/interagent/http-api-design)

<comment><USER19> That is a very comprehensive set of conventions! Contents pasted here:

Foundations - Require TLS, Version with Accepts header, Support caching with Etags, Trace requests with Request-Ids, Paginate with ranges

Requests - Return appropriate status codes, Provide full resources where available, Accept serialized JSON in request bodies, Use consistent path formats, Downcase paths and attributes, Support non-id dereferencing for convenience, Minimize path nesting

Responses - Provide resource (UU)IDs, Provide standard timestamps, Use UTC times formatted in ISO8601, Nest foreign key relations, Generate structured errors, Show rate limit status, Keep JSON minified in all responses

Artifacts - Provide machine-readable JSON schema, Provide human-readable docs, Provide executable examples, Describe stability

</comment></comment><comment><USER20> At 18F (a digital services consultancy within the US federal government), we've drafted API Standards[1]. They're a set of recommendations, rebuttable presumptions, and bright line rules that we expect our APIs to adhere to. For an organization that may offer several APIs, having a set of standards will help ensure, among other things, baseline quality and consistency.

[1] [https://github.com/18f/api-standards](https://github.com/18f/api- standards)

</comment><comment><USER21> I highly recommend this ~hour long talk given by Josh Bloch a few years ago, it is quite good and gives plenty of concrete examples: [https://www.youtube.com/watch?v=aAb7hSCtvGw](https://www.youtube.com/watch?v=aAb7hSCtvGw)

<comment><AUTHOR> Thanks!

</comment></comment><comment><USER22> I highly recommend the following talk by Joshua Bloch: "How to design a good API and why it mattes" [1].

Key points:

\- When in doubt, leave it out - you can never remove things from an API but always add to it.

\- Write several clients of the API to get a good feel how its used. Three is usually enough, one is not.

[1] [https://www.youtube.com/watch?v=aAb7hSCtvGw](https://www.youtube.com/watch?v=aAb7hSCtvGw)

</comment><comment><USER23> My two pet peeves are authentication and rate limiting.

Authentication - unless you're dealing with uber-sensitive details, make authentication as straightforward as possible. HTTP basic over SSL works fine for me. Bonus points for authentication-free calls for all your public data that doesn't need to be hidden. If you absolutely must use OAuth, please make sure you implement it to the standard, and - ideally - give me a robust client library in my language of choice.

Rate limiting - ideally, don't. Obviously, this depends on your audience - <USER3> understand why twitter need to rate-limit. Otherwise, be as nice to me as possible, let me 'save up' calls over time if you can handle the traffic, and provide me with lots of information about what my limit is, when it will be reset, etc.

<comment><USER24> I'd argue the opposite about rate limiting - If you can add it in a way that allows 95% of valid use cases to never run into it, but stops broken implementations and bad actors from degrading your service, it's a net win for your clients.

I agree it should expose a lot of information though. There's nothing worse than an opaque rate-limit where you can't even predict how to work around it in your code.

</comment></comment><comment><USER25> Consistency, predictability, documentation, reliable sample client in a couple of popular languages (e.g. PHP, Python, Ruby), well abstracted.

</comment><comment><USER26> The main thing about creating a good API is that you have a good relationship and good communication with the consumers of that API. I've seen a lot of people making internal APIs inside companies treat it as another way to throw something over a wall.

There's very little universal about a "good" API design. Even response time might not matter if your users aren't using it synchronously. Best way to make an API is to have a plan to support old versions, release something early, see what people make of it and incorporate their improvements. Worst way to make an API is to try and think of everything before you start - you will fail and you'll take a long time

<comment><USER27> been in this position! I feel bad thinking about it now!

</comment></comment><comment><USER28> Assuming you take care of the essentials like documentation and code samples, following will make your API shine.

* Explanatory Error Responses: Tell what was wrong in a problematic request and, potentially, how to fix the request

* Introspection end points: Which can tell you more about the request (headers/body) and credentials (rate limits, app id, etc) observed by the server. Is very handy in case of debugging.

* API should be able to tell properly when its unavailable. Ideally by returning proper HTTP 503 response.

</comment><comment><USER29> 1\. Documentation. It has been said in other comments. If you do nothing else right, do documentation. It is paramount. Documentation must contain code samples that can be ran without scaffolding a huge project. cURL command lines -- or the equivalent in non-HTTP APIs, are, for me, as good as it gets.

2\. Account for failure. The failure path is more important than the-one-true- path. Be verbose in your errors. Be specific in your error descriptions. Be extensive in the kinds of error conditions you test, particularly when validating the input. Bonus points here if you can make the API introspectable.

3\. Resource oriented. Expose your resources, then verbs on top of that. These are application-level resources. Do not directly expose the data model. RESTful APIs obviously follow this, but going REST is not the only option.

4\. Stateless, or with as little state as possible. Stateless APIs make clients _a lot_ simpler. They have the added bonus of scaling better on your end (on the server end).

5\. Predictable. This is achieved by being both consistent and verbose. Do not use abbreviations on method names. Define a vocabulary and use always the same nouns to refer to the same entities. If using positional arguments, use the same calling order (i.e. avoid the needle/haystack you see in PHP).

<comment><USER30> > _2\. Account for failure. The failure path is more important than the-one- > true-path. Be verbose in your errors. Be specific in your error > descriptions. Be extensive in the kinds of error conditions you test, > particularly when validating the input. Bonus points here if you can make > the API introspectable._

This is something that I had to deal with just last week. I had been integrating a 3rd-party API into a business application, and it had very poor error handling and error descriptions. It wasn't even consistent on when an endpoint would throw an exception or just return some JSON with an error message.

To make things worse, I kept running into the same generic error message: "Something went wrong. Please contact support at email@example.com if it continues". Of course, that kind of error message doesn't help their support team, so they could only guess as to what was going wrong. We finally figured it out after several hours of guessing.

What's strange is that this was an API for a moderately popular Silicon Valley startup that's marketed to and primarily used by developers.

Please, if you're building an API, don't write these generic messages!

</comment></comment><comment><USER31> Well said by many above. Would phrase some thoughts as follows:

1\. Developer Experience (DX) \- How quickly can a developer get up and running trying the API (ideally immediately). \- Client code generation. \- How understandable is the API? Does it use common vocabulary or terms you have to think about what they mean?

2\. Accuracy of documentation \- API and docs in sync. \- Ease of locating items in the documentation.

3\. Debugabbility \- How easy is it to figure out why requests fail. \- How easy is it to test edge cases for success/failure and experiment.

4\. Consumer participation in design/prototyping design tools \- Mocking functionality. \- Collaboration in design that is immediately possible to test. \- Making it easy to get feedback on different design options.

In the end of the day, good design makes for a good API. And, being able to involve a variety of stakeholders in the design process in a human-friendly way is really important to achieve that goal.

As a contributor to ApiBlueprint [1], we have been working to develop a suite of tools to help all this. I include a link to a sample api blueprint [2] and to the public documentation/DX portal you get if you import it and render documentation for it in apiary.io [3].

[1] [http://apiblueprint.org/](http://apiblueprint.org/) [2] [https://gist.github.com/fosrias/6377469bf0e1d2fd10c7](https://gist.github.com/fosrias/6377469bf0e1d2fd10c7) [3] [http://docs.sampleapi42.apiary.io/](http://docs.sampleapi42.apiary.io/)

</comment><comment><USER32> If its a Java or object-oriented framework or library - follow SOLID principals and limit dependencies. Make it unit testable. Try to make it consistent - calls to get one type of object should be similar to ways to get other types of data, etc. Functional approach to the interfaces - pass in required arguments, get back result. Don't require user/developer to create several configuration or factory objects before they can call a simple method to get some data, etc. Don't require the use of dependency injection frameworks or other complexities. If its web-based API return data as simple JSON or XML without overly complex namespaces, etc. Name things consistently - the names of response objects and properties should be the same as the corresponding inputs, etc. Copy - look at a successful API or library which does something similar - then copy the way it works and the way its documented. Especially if the users/developers already know how to use that one...

</comment><comment><USER33> I think it depends upon the use cases of the API, but if you want someone to be able to build snappy and fast "apps" using your API rather than just facilitating movement of data in/out for an integration with another piece of software, I think granularity is important.

Having built our front end using AngularJS, we are the first users of our own API and that has driven it's design. In order to make things quick, we really needed to trim down response payloads in some cases which kind of deviates from standard CRUD patterns in some areas.

This has come at the expense of good documentation (we have a lot more methods now and having good examples of all of them will be expensive) and consistency --things are not very uniform anymore. However, as an API consumer I'd rather have the API give me too many options rather than too little. Our API has gone from "pretty" to "very functional".

<comment><USER34> Sounds like you're going in the wrong direction. An undocumented, granular API with lots of options won't be used, so it won't matter how fast it is.

<comment><USER33> So this is why I said it depends upon your use case. We are an enterprise software company and there are probably less than 50 potential customers in our target market that could ever use the API.

We are one of the only companies that actually has an API. If a customer has a use for our API they'll get personalized support.

</comment></comment></comment><comment><USER35> There was an excellent talk at the last QCon New-York conference about good API design: [http://www.infoq.com/presentations/API-design- mistakes](http://www.infoq.com/presentations/API-design-mistakes) Worth watch it in my opinion :-)

</comment><comment><USER36> Phil Sturgeon's "Build APIs You Won't Hate" is a fantastic resource. It is directed towards PHP but the ideas are obviously transferable.

[https://leanpub.com/build-apis-you-wont-hate](https://leanpub.com/build-apis- you-wont-hate)

</comment><comment><USER37> You can find these slides interesting:

[http://slideshare.net/guestbe92f4/how-to-design-a-good-a- p-i...](http://slideshare.net/guestbe92f4/how-to-design-a-good-a-p-i-and-why- it-matters-g-o-o-g-l-e)

</comment><comment><USER38> I know what makes it bad: [http://nordicapis.com/5-reasons-why-developers-are- not-using...](http://nordicapis.com/5-reasons-why-developers-are-not-using- your-api/)

</comment><comment><USER39> The ability to use/see the api in action in the page (like maybe a click here button to see it work), so you can do things like see the network traffic so you can see what works without having to worry about things like CORS or whatnot. (my .02)

Also a way to use the api without needing to expose keys, I primarily try to consume API's using angularJS which is client side only, so giving out my key can be a problematic experience.

Thus most of my apps I write are for myself, and not others, since this is very rarely considered.

</comment><comment><USER40> If that data is ever to be viewed by a human you should focus on presenting the data in such a way that it is as easy as possible to display on the screen, if the process of getting the data to the screen is not easy the vast majority will either try to find an easier product to work with or just give up on trying to find a solution to that problem. (IT guys have a lot on their plate, and mountain of forgotten projects because they didn't have the time)

</comment><comment><USER41> Agreed with all the previous comments.

URL Design is key. I often refer to the naming chapter of Uncle Bob's Clean Code book for this. This also helps with consistency and predictability, which in turn, makes writing docs easier.

I've got an API Design Readlist, which I've added this thread to. [http://readlists.com/6c5c6009/](http://readlists.com/6c5c6009/)

</comment><comment><USER42> Ease of use. It should be easy to use. Someone else commented that simple is what makes an API good. To the extent that a simple API is easy to use, I agree.

I think an API is no different from any other software product. People like software that is easy to use. I think an API should be easy to use too. To me, that's what makes an API good.

</comment><comment><USER43> I like it when APIs offer good filtering options for searches. When all you have is basically "here is a list of things" \+ "here is a single thing with an ID", all you end up doing is scraping the entire list to do fun things.

</comment><comment><USER44> Simplicity. As a consumer of your API I should not have to do anything I don't need to. The worst thing is when you have to jump through hoops to deal with an API that was clearly designed for the implementer's convenience, not yours.

</comment><comment><USER45> This superficially is about C++, but in practice it's a collection of good advice for APIs in general:

[http://doc.qt.digia.com/qq/qq13-apis.html](http://doc.qt.digia.com/qq/qq13-apis.html)

</comment><comment><USER46> I agree with most of Vinay Sahni's points: [http://www.vinaysahni.com/best- practices-for-a-pragmatic-res...](http://www.vinaysahni.com/best-practices- for-a-pragmatic-restful-api)

</comment><comment><USER47> Versioning. Also, make sure that you're committed to supporting old versions of your API for the foreseeable future (the actual time period depends on the company - for Google, 20-30 years, while 3-5 years for a startup).

</comment><comment><USER48> Would be great if you shared what you've compiled as well. Thanks.

</comment><comment><USER49> You may find some of these helpful:

• Web API Design Crafting Interfaces that Developers Love - eBook [APIGEE]

• How to design an API function that creates something [SHAREDOM] [SHAREDOM- HN]

• Microservices and the First Law of Distributed Objects [FOWLER] [FOWLER-HN]

• Lego's API Strategy: Resourcing Developers and Building a Business Case [LEGO]

• A review of all most common API editors — Medium [ORLIESAURUS] [ORLIESAURUS- HN]

• Best Practices for Designing a Pragmatic RESTful API [VINAYSAHNI] [VINAYSAHNI-HN1] [VINAYSAHNI-HN2]

• Best practices for API versioning? - Stack Overflow [SO] [SO-HN]

• Designing Hypermedia APIs [KLABNIK]

[APIGEE] [https://pages.apigee.com/web-api-design- ebook.html](https://pages.apigee.com/web-api-design-ebook.html)

[SHAREDOM] [http://sheredom.wordpress.com/2014/08/10/how-to-design- api-f...](http://sheredom.wordpress.com/2014/08/10/how-to-design-api-function- that-creates-something/)

[SHAREDOM-HN] [https://news.ycombinator.com/item?id=8160071](https://news.ycombinator.com/item?id=8160071)

[FOWLER] [http://martinfowler.com/articles/distributed-objects- microse...](http://martinfowler.com/articles/distributed-objects- microservices.html)

[FOWLER-HN] [https://news.ycombinator.com/item?id=8172980](https://news.ycombinator.com/item?id=8172980)

[LEGO] [http://nordicapis.com/legos-api-strategy-resourcing- develope...](http://nordicapis.com/legos-api-strategy-resourcing-developers- building-business-case/)

[ORLIESAURUS] [https://medium.com/@orliesaurus/a-review-of-all-most- common-...](https://medium.com/@orliesaurus/a-review-of-all-most-common-api- editors-6a720dc4f4e6)

[ORLIESAURUS-HN] [https://news.ycombinator.com/item?id=8505244](https://news.ycombinator.com/item?id=8505244)

[SO] [http://stackoverflow.com/a/398564/2541](http://stackoverflow.com/a/398564/2541)

[SO-HN] [https://news.ycombinator.com/item?id=7350432](https://news.ycombinator.com/item?id=7350432)

[VINAYSAHNI] [http://www.vinaysahni.com/best-practices-for-a-pragmatic- res...](http://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api)

[VINAYSAHNI-HN1] [https://news.ycombinator.com/item?id=6624229](https://news.ycombinator.com/item?id=6624229)

[VINAYSAHNI-HN2] [https://news.ycombinator.com/item?id=5819231](https://news.ycombinator.com/item?id=5819231)

[KLABNIK] [http://www.designinghypermediaapis.com/blog/index.html](http://www.designinghypermediaapis.com/blog/index.html)

</comment><comment><USER50> Thread safety. If you write an API never forget that people may want to use it in more than one thread.

</comment><comment><USER51> Documentation.

</comment><comment><USER52> Consistency. pick a convention and keep doing things that way, always and everywhere.

</comment><comment><USER53> Agree with notjosh on this -- so what makes documentation good?

<comment><USER54> In terms of documenting api's, Swagger is your friend : [https://helloreverb.com/developers/swagger](https://helloreverb.com/developers/swagger)

</comment></comment><comment><USER55> Be strict with your output and promiscuous with your input.

</comment><comment><USER56> The simplest API that could possibly work.

</comment><comment><USER57> NuGet availability is a strong win.</comment>


Israeli Iron Dome firms infiltrated by Chinese hackers - <AUTHOR> http://www.bbc.com/news/technology-28583283 <comment><USER2> CyberESI are using a conflict to push to media outlets their old 'news' from 2011, which even then weren't that interesting...

<comment><USER3> So, honest curiosity and it would be ace if you could be honest and truthful. Why did you post this, how did you find this site, where are you from, what is your agenda in the Palestine vs. Israel conflict?

</comment></comment><comment><USER4> more detail from krebs here:

[http://krebsonsecurity.com/2014/07/hackers-plundered- israeli...](http://krebsonsecurity.com/2014/07/hackers-plundered-israeli- defense-firms-that-built-iron-dome-missile-defense-system/)

<comment><USER5> More to the point: Krebs is the BBC's source.

He credits Cyber Engineering Services Inc., out of Columbia, MD, a threat- intelligence firm.

</comment></comment><comment><USER6> Curious question, has the NSA thought of doing root jails as honeypots in front of these important military contractor networks to not only catch intrusions before damage occurs but also catch on to new zero day attacks?

<comment><USER7> I'd imagine they've worked around that by just collecting everything that goes over the internet.

</comment></comment><comment><USER8> Previous discussion: [https://news.ycombinator.com/item?id=8096808](https://news.ycombinator.com/item?id=8096808)

</comment><comment><USER9> IAI refuting the claims here: [http://www.jpost.com/Defense/IAI-refutes-claim- that-Iron-Dom...](http://www.jpost.com/Defense/IAI-refutes-claim-that-Iron- Dome-makers-were-hacked-369505)

</comment><comment><USER10> pew pew, owned.</comment>


Show HN: devsigh.com - post all your stories of developer sigh - <AUTHOR> http://www.devsigh.com

<comment><USER2> In the annals of innefectual, misdirected, passive-aggressive online nerdrage this system of anonymous, groupthink-driven schadenfreude really takes the cake.

Of course, here I am shaking my fist on Hacker News so who am I to criticize?

<comment> guard-of-terra Every one of those are about "I should have confronted the decision because I know better but I'll shut up and write to devsigh instead"

Because you have no spine? Pathetic.

<comment><USER3> Firstly, ranting online and confronting the problem directly are not actually mutually exclusive. Secondly, in the real world sometimes a problem just isn't worth addressing; no matter how hard you try, sales/marketing/your manager/the CEO/the users just won't understand, so just work around it and let off steam online instead.

<comment> guard-of-terra The level of helplessness in those rants suggest they are.

In the real world you are THE responsive professional, and you tell people that the important thing is going to be wrong, politely but repeatedly, and they actually listen to you. And when you repeat it in simple words long enough, they eventually would understand. That's how it works. Or at least you land on better terms so you don't have to make a deal with your conscience.

How they know if it won't work if they didn't try? They just sigh and go on spending their time doing busywork, spending corporate money or failing projects.

<comment><USER3> In the real world, some battles are not worth fighting. Telling people that your way is correct, over and over again, doesn't necessarily mean that they'll learn, and even if you're right it doesn't necessarily win you any friends (even among people who agree with you). Sometimes you have to pick your battles and work around the incompetence, laziness, and sheer malice of others, and then vent a little to your friends, or to the internet at large if you have none.

<comment><USER4> In fact, it can bite you in the ass when it comes review time - people review you as an obstruction to getting things done. Note, this isn't always true; when it is, it's a good sign that you shouldn't be working for the company. But in some geographic areas, even IT/Dev positions are hard to come by.

I have a friend who runs into these kinds of problems all the time. Complains incessently about them, how he hates IT/networking and wants to get out of it. Every story he tells reminds me how grateful I am to work at an amazing company. His excuse for not finding an amazing company? He doesn't want to move away from where he lives.

What can you say to someone in that position?

<comment> guard-of-terra "His excuse for not finding an amazing company?" I think the main reason for not finding an amazing company is the same as one which prevents him from standing up thus making his life (and, in fact, lives of everyone around) better.

I guess the same people who work at nice jobs where they make a difference would continue to make so elsewhere and this in fact is what let them where they're now.

</comment></comment></comment></comment></comment></comment></comment><comment><AUTHOR> Hi everyone. I built this over the course of the last week as an exercise in learning Django.

I noticed my friends and I tended to share lots of stories about our work- related development woe on IRC and thought it would be good to create a place to share the stories!

Let me know if you've got any feedback.

<comment><USER5> (1) Add job listings to submission page

(2) $

<comment><USER6> This will work.

</comment></comment></comment><comment><USER7> TRWTF is that this a site like this already and is _hillllarious_ : <http://www.thedailywtf.com/>

Just kidding. I suppose there's a niche for shortform "sighs" too.

</comment><comment><USER8> _Told during the final stretch of a four month project that all the colors in the app had to be readable for people with Color Blindness_

Surely in these days of accessibility awareness this ought to be a design goal by default unless otherwise stated?

<comment><USER9> I'm more surprised that people actually expect us to have this in the back of our minds at all times. There's a reason they didn't go replacing all stairs with ramps.

<comment><USER10> Architects spend a _lot_ of time worrying about accessibility requirements. Accessibility, fire safety, and car parking are the major factors that shape buildings.

<comment><USER9> Definitely a fact, but I wasn't suggesting that it isn't. Everyone knows there are clear and obvious benefits to having a site that is accessible to everyone as opposed to only the majority.

What I mean by the stair/ramps remark is that stairs weren't suddenly removed from the architect's toolkit when the wheelchair was invented. Since ramps are clearly not used in all instances they are not always appropriate or desirable.

The same goes with web design, which is as much art as is architecture. Not all sites are going to select between a limited range of colors to cater to a relative few if those colors happen to clash horribly with their intended design.

<comment><USER3> But if you've only space for stairs _or_ ramps, then you'd have to use a ramp, which everyone can use, rather than stairs, which most but not all people can use. Similarly, if you can only have one colour scheme, you ought to be picking one which everyone can read, not just most people. It's not as if it inconveniences non-colour-blind people.

<comment><USER9> It's not always the case that you would choose a ramp over stairs given the choice of only one or the other. For example, there aren't many two-story homes that have a ramp leading to the second story. (Not to say they don't exist, just that they are a glaring exception.) That's what I mean by not always appropriate or desirable.

I feel I might be getting astray here. I simply think it's odd to impose on-- what is as much an art form as it is a medium for communication--the restriction of only being able to use a certain color scheme. I'd be bummed out.

Luckily you don't have to sacrifice any aesthectics. SparkFun does a good job of making their stock status icons accessible by employing a combination of color and shape to help color-blind people recognize the status easier.

Here's a good example: <http://www.sparkfun.com/products/10388>

<comment><USER3> I'm sure colourblind people would be even more "bummed out" that your design was unusable. Since, as you go on to mentioned, you don't have to sacrifice aesthetics for the sake of accessibility, I don't see why accessible design would be a problem.

While I take your point that ramps in particular aren't always appropriate, that doesn't mean that accessible design in general isn't.

</comment></comment></comment></comment></comment></comment></comment><comment><USER11> The voting system is quite.... Completely broken :) While the marker disappears, you can still keep clicking, voting as much as you'd like

<comment><AUTHOR> I think i've fixed that now!

Fingers crossed.

<comment><USER12> Not quite. Your rate limiting seems to be cookie based, which makes it easy for someone to circumvent just by replaying their initial request (or by deleting the cookie you set).

<comment><AUTHOR> Ooops.

There's about a half dozen people down_vote DOSing the server right now.

<comment><USER13>
      sudo iptables -I INPUT -s <offending ip> -j DROP

</comment></comment></comment></comment></comment><comment><USER14> Reminds me of Clients From Hell (www.ClientsFromHell.net). And a text only version of Dilbert. Nice!

<comment><USER15> There's also Not Always Right[1], but it's not tech related (and they're stories, not just sighs).

[1]: <http://notalwaysright.com/></comment></comment>


Trading Algo for Covered Calls - <AUTHOR> I built a trading bot that uses your portfolio long positions to sell covered calls, an easy low risk way to generate additional portfolio income, is anyone interested in using it? <comment><USER2> You should make a 'Show HN' ([https://news.ycombinator.com/show](https://news.ycombinator.com/show)) post demonstrating how the bot works.

<comment><AUTHOR> Thanks, mate!

</comment></comment><comment><USER3> What's the likelihood of getting your stock called away when the stock is making good gains?

<comment><AUTHOR> By default, the system is configured to immediately place an order for the same shares and price if this occurs, to cancel out the negative effects of this.</comment></comment>


Dropbox will kill your insane MacBook Air 2013 battery - <AUTHOR> http://blog.nicoschuele.com/?p=151 <comment><USER2> Dropbox is _terrible_ with CPU usage. This is something I reported to them several times, but it seems they don't really care.

Last I tested, Dropbox consumed CPU for ANY changes ANYWHERE in your filesystem, not just within the Dropbox folder. So its (slow) code processed changes even when you untarred a large set of files somewhere in /tmp.

I also stopped using Dropbox for storing my code because of that — it's nearly useless, as it consumes so much CPU and eats so much battery life, that it simply isn't worth the effort.

Another problem with Dropbox is that upon login it indexes the entire Dropbox, which if you have an HDD basically kills the machine for several minutes, e.g. you can't do anything else. That happens to me on a Mac Pro. On an SSD- equipped MacBook things are better, but it's still a monstrous operation.

And to everyone that says you should not store code in dropbox: a) there are good and legitimate reasons for doing so, b) dropbox could work a little more on optimizing CPU usage instead of adding "save your photos to Dropbox" features.

<comment><USER3> > And to everyone that says you should not store code in dropbox: a) there are > good and legitimate reasons for doing so

I'm genuinely curious: why do this, as opposed to using a DVCS like git?

<comment><USER2> I do use git. But I often develop on two machines: a laptop and a Mac Pro. Which means I am often in the middle of something when I have to just pick up the laptop and go. "In the middle of something" means that just pushing commits over doesn't cut it. I can (and do) rsync stuff over, but that is annoying and very error-prone (it's too easy to sync stuff the other way around and lose work).

I guess you could say Dropbox gives me finer sync granularity than git does.

Dropbox seems like a perfect solution: have a single place where you keep code, develop on two machines, just pick up your laptop and leave whenever you want, without worrying about sync.

<comment><USER4> I don't understand. You can easily cut a branch commit. Push the branch. Pull the branch finish it. Commit. (optionally rebase). Delete the temporary branch. Git handles this problem very well.

<comment><USER2> Right. I get a call, I need to leave for a meeting in 5 minutes. This is exactly the time when I want to cut branch commits, push branches, pull branches, commit and rebase. Even rsync is better than that.

Put it another way, I don't understand why you'd use Dropbox at all, after all you could easily version all your files in git, using push/pull/branch/commit/rebase to get your data to your different machines. Git handles this problem very well, after all.

<comment><USER5> The specific problem with git in Dropbox is that working in git can cause a large number of transient files changes as you, for example, switch branches. Dropbox doesn't know those are transient changes and attempts to sync all of them. That is one reason it can drain battery so fast.

Obviously with regular files, that is not an issue, so Dropbox works well. (unless you're managing them with git, I guess)

If you're willing to accept the "lightness" of git branching and commits, it's possible to "save and sync" your work very quickly. Assuming you're on a dev branch:

git add -A

git commit -m "temp commit 2013-7-3"

git push origin

You can even script this, see for example:

[http://stackoverflow.com/questions/8482843/git-commit- bash-s...](http://stackoverflow.com/questions/8482843/git-commit-bash-script)

Then when you're ready to work on a different machine, you fetch from origin.

If you want to keep your commits meaningful on your dev branch, you can create a temp branch first, then rebase later to get rid of the ugly temp commit.

git checkout -b temp123

</comment></comment></comment></comment></comment></comment><comment><USER6> That finding might be quite interesting and all... but I'm thoroughly confused about that guy always quoting power consumption in mAh (which is the unit for electrica charge).

I'd also check if that guy's dropbox daemon(s) are stuck in an obvious loop. I'm logged on in my private server, and when it's idle there's hardly any activity on the dropbox threads, the main CPU consumer is one servicing what I suspect to be the main select() loop. And that thread basically stat()ing the .dropbox/config.dbx file every 2 seconds, and reads 16 bytes out of it. That should hardly be measureable in terms of power consumptions on a modern CPU.

<comment><AUTHOR> Thanks for pointing this out. It's a typo, I meant mA, not mAh. Fixed.

<comment><USER7> No, that is not a typo. Thos is a typo - an error created during the mechanical act of typing. Yours was just a plain mistake, you got the units wrong. Own it and learn from the error instead of excusing it away.

<comment><USER8> I guess you might not be as good with words in Schwizerdütsch as he is in English.

<comment><AUTHOR> Lol. Thanks. But I'm from the french-speaking part of the country.

<comment><USER8> D*mn ;-)

</comment></comment></comment></comment></comment></comment><comment><USER9> > I use it to store my code repository [...] Not using Dropbox is not an > option for me as I switch machines several times during the day.

I'd suggest you invest in a hosted git repo.

<comment><AUTHOR> I store a lot more than just a git repo in Dropbox. I also use it to share files, etc. But yes, I'm starting to look at alternatives. Maybe I'll develop a small utility to push/pull/share files from my home NAS upon request rather than having a continuous process running in the background.

<comment><USER10> You can also, what I did, switch dropbox off and switch it on only when you are connected to power for a sync. It's not ideal, but it works. I don't see how dropbox could do better though. If you do it manually to your NAS, you basically do the same as switching dropbox on/off or dropbox in a cronjob. Anything monitoring your file system and synching up with many small files will incur load like this.

<comment><USER11> I use ControlPlane - [http://www.controlplaneapp.com/](http://www.controlplaneapp.com/) \- which monitors your "context" (like location etc.) and lets you trigger events on context change.

Just added some rules so that Dropbox quits when I'm in my "mobile" context, but reopens when I am in my "home" or "office" contexts. Will see whether it works on my commute later.

<comment><USER10> Nice! Thanks for that tip.

<comment><USER11> And I'll note that after my commute home, I do seem to have a bit more battery life than usual. So that's a win.

</comment></comment></comment></comment></comment></comment><comment><USER12> I had this happen in the past too and found it to be the result of two issues:

1) Using dropbox to house a very large git repo with massive changes and tons of branches... Every time I switched branches, the hundreds of files would change and obviously kick off a major sync job.

2) There were a few files in a folder than had the owner set to the wrong owner and Dropbox couldn't get permission to access them. This caused it to get stuck in a loop trying to sync those files and Dropbox ended up running my CPU up to over 100% load.

Fix those issues and you shouldn't see it causing any more problems with your battery life.

<comment><USER13> > Using dropbox to house a very large git repo with massive changes and tons > of branches... Every time I switched branches, the hundreds of files would > change and obviously kick off a major sync job.

I really have to say honestly: no shit. Sorry if i sound crass but really? When you use an arbitrary piece of software to automatically modify 100s of files the piece of software designed to detect that exact event has do do work and you are complaining? The mind boggles

<comment><USER14> Which part of that comment looked to you like a complaint?

</comment></comment></comment><comment><USER15> The only takeaway is that his power usage shouldn't be that high with Dropbox idling/paused. But given that he's * surprised at it using a lot of power when doing the initial sync * decided to have a git repo inside Dropbox (just don't do it, you will run into trouble; and it will cause heavy sync activity, thus waking CPU and wifi) * using a unit of capacity to express power consumption

I'm not sure I trust his methods.

I regularly turn off Dropbox on and off when switching between mobile broadband and wifi, and haven't seen any difference in power consumption. That's on Ubuntu 13.04 @ Thinkpad T530.

<comment><USER16> Dropbox behaves very differently on OSX versus Linux I've found.

<comment><USER17> likely because linux has inotify

<comment><USER18> Every modern operating system has inotify-like capabilities. Mac OS has an integrated desktop search since 2005, which wouldn't be feasible without filesystem events.

<comment><USER19> Dropbox has its own process though, doesn't it? dbfseventsd.

sudo fs_usage -w

I've been watching it recently and it seems to touch files that it shouldn't need to. I need to do more investigation. I uninstalled backblaze recently because I discovered that it manually scans the whole filesystem _all the time_.

<comment><USER20> Thanks for the Backblaze info! That's really good to know. Do you know if CrashPlan is any saner? Resource usage was a big factor when deciding between the two, and I want to know if I've made the right choice :)

<comment><USER19> I haven't used CrashPlan so I can't really say, sorry. I've moved to Arq now which has been working very well for me but it's OSX only.

<comment><USER20> Thanks for the reply -- I've looked at Arq before too. I find it interesting Arq (S3) is a third the price of Tarsnap (S3).

Out of interest, if you don't mind me asking, how large is your backup, and do you use S3 or Glacier backend?

<comment><USER19> Interesting question - I hadn't gotten around to checking the numbers yet myself. So,

      Indexes are stored in S3, data is on Glacier
      ~450GB of data stored
      316,189 Requests to upload it all (main cost)
      $17.39 to upload it all
      $5.09 to store it last month (but upload was incomplete)
      Expect closer to $6-$7 to store it this month
      ~$120 to restore it all (that was a back of the napkin figure before I started)

Arq has a number of good things to recommend it. The creator lurks around here, which is always nice to know. The design is very sensible - it's basically a git index on S3 with the data blobs in Glacier. The storage format is open and documented. All the data is encrypted using your own key locally and then pushed to your own AWS account. It works out really cheap if you use Glacier (only planning on restoring in catastrophic circumstances).

It all just works. The interface is easy and intuitive. I pushed my data to the EU region since it's closer. The more I think about it the happier I am with my choice at the moment. Even if I changed my mind and stopped using it - it's nice knowing that for a few dollars a month I have a huge snapshot of my data in a reasonable format in my AWS account.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER21> One solution to the whole "storing source in dropbox" problem that I liked to use previously (using bitbucket now instead) is just to have a bare git repo in dropbox + the real checkout somewhere else and just push commits to the bare dropbox repo whenever I'm about to switch machine. Could even be set up to happen more automagically since the repo isn't shared.

Syncing binaries (I mainly work in C#) and lots of small changes seems silly to me.

</comment><comment><USER20> I switched from Dropbox to SpiderOak recently, and they're a bit better, but feels so clunky. I'm just about fed up with all of them. I use CrashPlan for backups and they're at least good for CPU usage because they have a preference -- max CPU (%) when you're at the computer, and max CPU when you're away, which really does help.

Those who are using Dropbox may find something like cpulimit[1] useful. This limits the CPU usage of any process by repeatedly sending SIGSTOP and SIGCONT signals to your process. It's on homebrew for OS X. I think there're some other alternatives available too but can't remember off hand. But if the article's accurate, Dropbox has issues even when it's not indexing heavily.

[1] [https://github.com/opsengine/cpulimit](https://github.com/opsengine/cpulimit)

<comment><USER22> A non-open-source OS X app called AppTamer can be very handy for managing battery life. You can set process priority and automatically pause non- foreground GUI apps. So when you switch away from your CPU chewing IDE, it'll get SIGSTOP'd.

</comment></comment><comment><USER23> _" I just have to change my habit of having it constantly on while working. Turn Dropbox on and sync before starting to work and then turn it off."_

Hohoho. Allow me to suggest a solution. Suppose that you would be ok with having Dropbox sync files every five minutes. Let's suppose that 10 seconds is usually more than enough to do whatever syncing is necessary. Well, then:

      $ while :; do killall -STOP Dropbox; sleep 300; killall -CONT Dropbox; sleep 10; done

I do things like this to throttle the CPU usage and, in some cases, the power consumption of applications that really don't need what they're using. This really should be a feature provided by the operating system, but in the meantime, I resort to ridiculous hacks of this sort. (Note that, if you ^C the above loop, Dropbox will likely be still STOPped and you'll have to CONT it again. It is possible to write a more sophisticated program to address this problem.)

</comment><comment><USER16> This happens to me as well.

The Dropbox daemon wakes up every 10-15 seconds, uses 15% of the CPU then goes back to sleep. All this without any files changed or the index being affected. On 10.8, 10.9 with official versions and betas. Noticeable because I am on an older C2D MacBook Pro.

Wondering whether it's a side effect of something else installed e.g. iStat Menus.

</comment><comment><USER24> This is interesting, I've also got a 2013 MBA and use DropBox but I've not seen a big dip in battery usage. I might do a bit more testing this week and see whether it has had an impact and I've just not realised, and/or I've put it down to the code-compile-simulator cycle.

</comment><comment><USER10> I see this problem happening only to me when it's used as code repository. Which is what he is doing. I had that for one project because the client didn't want to use git, but it's horrible. So, logically, when you have a lot of files changing all the time (compiling (xcode, eclipse), adding libraries (node, RoR)) you'll see dropbox taking over your computer. For all other uses it seems fine.

Note also that when you have the issue with a lot of small files, during/after dropbox is done, Finder / mds will jump to the top of your top indexing the files. I disabled mds in my projects directory and will never place active source directories in dropbox again.

<comment><USER25> Well, yes, but if you read the result of his tests even with syncing turned off Dropbox is _still_ eating about 500 mAh.

And that is, I would say, rather strange.

<comment><USER18> I guess the Python interpreter is preventing the CPU from entering lower sleep states.

</comment></comment></comment><comment><USER26> Can anyone confirm his findings? I imagine that if this is real, then this is a problem for all MacBook owners not just the latest MacBook Air.

I have a 13" MacBook Air, medio 2011. I bought it almost right after it was released and have used it as my only computer almost every day since. I have the Dropbox agent running all the time.

While working last Sunday I got 5.5 hours of battery life out of it and I've never taken good care of the battery. I never drain it unless I'm not near a power outlet, in which case I just have it plugged in all day.

My current battery health information shows: Cycle Count: 253, Condition: Normal

</comment><comment><USER27> I have a cron script running on my MacBook to make sure the Dropbox client priority is always set to 20 (lowest). I also pause the client manually when moving to battery power. I really wish there was a better solution, like switching to a similar service that offers decent (or at least acceptable) software, but almost everyone else uses the same setup with terrible 'universal' Java/Python/etc-based clients that absolutely suck at synchronizing large amounts of data.

</comment><comment><USER28> Laptop operating systems need to start keeping tabs on what's using your battery, like Android does (with mixed success but that's another story).

<comment><USER29> OS X 10.9 does show battery use per app in the Activity Monitor. It also shows a short list of battery-draining apps right in the battery menu at the top of the screen.

<comment><USER30> Powertop has been available on Linux for a looooong time.

<comment><USER28> Powertop doesn't do that though.

</comment></comment></comment></comment><comment><USER31> Open Dropbox when you need to sync, then quit the process. Make sure it doesn't run at OS X start up. I don't see why most of the users want to have a perfect sync all day long since it doesn't happen in real time (large files, slow network, etc.)

</comment><comment><USER32> Oh if only it was one App that killed the battery on the last laptop I bought. Before nuking the default windows install, I did a quick test, with all the crapware that comes as standard, it managed about 4 hours. Fresh install 6.5 hours.

<comment><AUTHOR> Mac. Doesn't come with crapware.

For Windows boxes, there's decrapifier.

<comment><USER33> Doesn't Windows 8 come with a built-in "remove everything and fresh install the OS" button now? Can always use that.

</comment></comment></comment><comment><USER34> Since I'm stuck using an old computer I made a small script that turns Dropbox on every few hours and kills it after 10 minutes. I don't sync data all the time so this solution works well for me and I save system resources.

</comment><comment><USER35> I push to a bare repo in a dropbox folder because I can't for the life of me get a secure connection through the work firewalls / proxy so I don't bother and let dropbox deal with it.

</comment><comment><USER36> Doesn't seem to happen with the latest self-updated version of dropbox and 10.8.4 to such an extreme, on a retina MBP. I get 15 extra minutes.

</comment><comment><USER37> Thats awful, one can only assume this affects MBP as well. I think I'll now only turn DB on whenever I'm on A/C.

<comment><AUTHOR> Yeah, it sucks big time. DB is at the center of my workflow. Having my git repository in it, my projects plans, etc. I just have to not forget to "turn on, sync, turn off, work, turn on sync, turn off".

On the other hand, I didn't notice any difference in battery consumption on my Windows 8 laptops. Who knows, maybe OS X Mavericks will change that with the way it handles processes?

</comment></comment><comment><USER29> I have noticed this as well. And it's not just Dropbox. I have turned off Dropbox, Google Drive and Little Snitch.

</comment><comment><USER38> Which Dropbox client version are we talking about?

<comment><AUTHOR> As it is a fresh install, the last one.

<comment><USER38> v2.2.8, then. Thanks.</comment></comment></comment>


Is Node.js just a stopgap? - <AUTHOR> http://www.philipotoole.com/is-node-js-just-a-stopgap/

<comment><USER2> This is getting a bit old. Nobody's arguing JavaScript is the best (or even a particularly good) language for server development. Node's popularity for a large part is due to the fact that it turns JavaScript developers into full stack developers rather quickly which for a lot of companies can be a very (cost) effective approach.

</comment><comment><USER3> Man, all of these complaints just feel so _outdated_. Check out --harmony flags, traceur, promises, stack trace libs, etc.

<comment><USER4> Traceur is not fixing JavaScript per se. It's just another high-level language transpiling to JS at the moment. So his complaint is still relevant.

<comment><USER3> Kinda relevant, and less and less relevant every day</comment></comment></comment>


Is Craigslist search down? Any filter does not show results  - <AUTHOR> http://sfbay.craigslist.org/ Looks like craigslist search is down. Any filter does not show results though page numbers are shown <comment><USER2> Having the same problem here is Seattle, WA</comment>


Ask HN: Recommendations for a bank? - <AUTHOR>

First, some background: For as long as I've had a bank account it's been with a credit union in my hometown. I loved being able to call back and hear the local Midwest accent and know the names and faces of people I was talking to. However, my credit union recently merged with a larger entity, and their support for my lifestyle and needs is marginal.
So, what do you recommend? I love the credit union model but fear it can't provide everything I'm looking for. Ideally the features I'm looking for:
- easy access to local branches (in San Francisco now, but maybe elsewhere) - awesome online interface; bill-payment is a must - good service with good rates and low fees - easy to transfer money in and out
I hope BankSimple will do all this, but what do you recommend until then? <comment><USER2> I like USAA.

It's ostensibly a bank for those employed by the US armed forces (or related to someone in the service), but any American can freely open checking and savings accounts. If you qualify for a credit card and insurance, you can cash checks by taking a picture with your cellphone.

Amazing online interface (I design interfaces professionally, and theirs is one of the best I've used), iPhone/Android apps, online bill pay, no minimum balance required, free overdraft protection, and a refreshing lack of random fees like those I've encountered at Chase.

The only local USAA branch is in Texas, but they reimburse ATM fees (up to $15 a month, I think). I've been traveling around the world for an entire year and have had no problems. Customer service is fantastic.

</comment><comment><USER3> Here are some recommendations from True Ventures: <http://www.trueventures.com/recommendations/>

Disclaimer: I am not associated with True Ventures in any way.

However, I have been a long time customer of Wells Fargo and would vouch for them. I love their customer service and have done both personal and business banking with them. They're headquartered in San Francisco as well and are available almost everywhere nationwide. Hope this helps.

</comment><comment><USER4> ING has good rates, really low fees if at all, good website, bill-pay, easy in and out. There are no local branches, but ATMs abound.

My favorite though is their checking accounts can have a line of credit with super competitive rates (7.25% right now). And even if you don't go for a credit line they don't charge overdraft fees.

</comment><comment><USER5> I can sympathize, as I'm in a similar boat.

I love the CIA credit union, but their branches are all around DC, and I'm planning on moving soon.

I keep checking the BankSimple web site to see if they're any closer to launching, as I'm hoping to avoid having to open an account with Citi or Wachovia after I move.</comment>


The Serial-Killer Detector (2017) - <AUTHOR> https://www.newyorker.com/magazine/2017/11/27/the-serial-killer-detector <comment><USER2> Note that he's running this as a rather young retiree of 60 years, and is limited by the lack of corporate resources exposing him to possible lawsuits.

The news business still works well enough for this excellent article in the New Yorker to tell us of an instance where it stopped working. Right now, we still get a glimpse of what is being destroyed. Soon, the idea of someone having the freedom to devote a year's work to an unproven method of investigation will be lost to history.

<comment><USER3> I found that part rather impressive as well that he got one year to do this. I immediately said to myself he must make 50k or more a year and his boss let him do that so how much will this story make them or what is the motive in allowing such freedom. Cool. But I have the opposite feeling about the future. I think the age of robots is coming and we will be swamped with nothing to do. People may start doing what they are passionate about and this seems like something others may get on board.

</comment></comment><comment><USER4> More recent article from Cleveland news station indicates no serial killer caught yet, but I guess at least now they're actively looking for one (or three):

[https://www.news5cleveland.com/news/local-news/cleveland- met...](https://www.news5cleveland.com/news/local-news/cleveland-metro/are- unsolved-murders-along-clevelands-east-93rd-street-corridor-connected)

</comment><comment><USER5> Someone sent me this a few weeks ago, and I've been playing with loading his datasets into a graph database. It's kind of a mess of CSV and some column formatted files, but it's a fun process.

Will share if I make something of it.

</comment><comment><USER6> The improve crime solved statistics by implying correlation equals causation. How does the total percentage of serial anything compare to other countries.

<comment><USER7> Not at all. He's just identifying suspicious clusters of unsolved murders. He's not even identifying suspects. That's up to the police, mainly using standard methods.

So I really have no clue why he says:

> Hargrove is pleased about the investigation but he also worries that > something may go awry. "What if they arrest the wrong guy, and he sues?" he > asked.

Why would they sue him? I mean, his not-for-profit has ~no money. And I doubt that he's wealthy. It'd make more sense to sue the police.

<comment><USER8> People have sued the wrong person and lost plenty of times. He probably wouldn't lose if he got sued, but even if he won, the trouble might be more than he wants to handle. And if he does lose, well, that would really suck, and that's not impossible either.</comment></comment></comment>


My Favorite Business Model - <AUTHOR> http://www.avc.com/a_vc/2006/03/my_favorite_bus.html <comment><USER2> I think the most important bit is

'The best examples of this business model are when the customer implicitly understands why the paid service has to cost money. More storage costs for photos or virtual storage are good examples.'

If your customers are paying for their 'usage', but it don't understand how it is actually a cost to you, they can feel ripped off.

I'm surprised he didn't include Angry Birds in the list.

<comment><USER3> He didn't include Angry Birds since it didn't come out until 2009 (see why I added [2006] :))

</comment></comment><comment><USER3> [2006]

<comment><USER2> I take your curtness as being a bit harsh and you're suggesting that this isn't a business model that should be promoted??

Fred does acknowledge that this isn't new, and I suggest it has been around LONG before 2006.

This is Fred's favorite, it doesn't have to be yours, but he provides a good description of why he likes it.

Of course, it doesn't apply to all businesses. Note that he didn't suggest that Twitter should have used this model, though that actually may have worked quite well for them.

<comment><USER3> The purpose of my curtness was to be concise; no editorializing was intended. I just thought it was customary to include the year when an old essay is posted to give you the right initial lens for reading it and to help you know if it is the original or an update for a topic.

I actually enjoyed the article; the thoughts behind this were important for the last startup I joined and I'm thinking about how I can apply them to what I am working on now.</comment></comment></comment>


Show HN: Chartify – Lightweight and customizable React.js chart component - <AUTHOR> https://github.com/kisqin/chartify <comment><USER2> How many times has this been posted?

<comment><USER3> It's probably better to email the mods when you spot things like this.

[https://news.ycombinator.com/submitted?id=kirillstyopkin](https://news.ycombinator.com/submitted?id=kirillstyopkin)

</comment></comment><comment><USER4> Spam</comment>