yariv

Having more megapixels allows you to crop more without losing detail and effectively zoom in on different areas on the photo in post processing. It frees you from needing to perfectly compose your photo when you take it and it makes prime lenses almost as versatile as zooms for getting closer to your subject. It has an important effect on ergonomics because it lets you carry around a lightweight prime lens instead of a big heavy zoom and still be able to achieve similar results, or even better ones if you can take advantage of the prime's higher max aperture.

If Erlang's syntax bothers you and like Clojure you should check out LFE (Lisp Flavored Erlang). It's Erlang with a Lisp sytax.

I work on the Facebook platform team.

Facebook Platform supports OAuth as a standard authentication protocol for 3rd party apps. It also provides APIs that developers can use to export data users have entered into facebook (with the user's permission, of course). What do you think is missing in Facebook's support for data portability?

The theory is that by accepting someone's friend request you're not automatically granting them the ability to export your email address to any application that asks for it. If it were possible there's a good chance your inbox would quickly be filled with spam from apps your friends use. I know of no social network, including Google's own Orkut, Twitter, and Myspace, which allows this kind of mass exportation of friend emails via its API.

It used to be the case that apps could only store your data for 24 hours, but we removed this restriction in the last f8 conference.

You can definitely export all your photos into SomeApp.com using the graph API and they can store your photos indefinitely. These APIs are documented at http://developers.facebook.com/docs/api.

The Facebook API allows 3rd party applications to access most of the user's data, including the user's email, if the user grants the application the required permissions. More details are at http://developers.facebook.com/docs/authentication/permissio....

(I work on the Facebook platform.)

With the Facebook API, the user doesn't have to provide any third party his credentials to allow the third party to access his data. Facebook uses OAuth to securely pass an access token to the third party while protecting the user's credentials. See http://developers.facebook.com/docs/authentication/ for more info.

(I work on the Facebook platform.)

ErlyWeb, an open source web framework: http://github.com/yariv/erlyweb/.

Twoorl, an open source Twitter clone: http://github.com/yariv/twoorl/.

Vimagi, a graffiti-like facebook app: http://apps.facebook.com/vimagi-paint.

Also, parts of Facebook chat (I work at Facebook).

On the flip side, if the team from 37 Signals worked for a great technology company like Facebook, Google or Apple, they could have built products that tens or hundreds of millions of users and hundreds of thousands of developers use every day. They could have worked with some of the best engineers and designers on the planet and have had a huge impact on the products they've built and their company's success. They also could have also created popular open source software that runs on massive infrastructures, written their own blogs, and achieved industry fame.

I'm not trying to argue that entrepreneurship isn't a great path to pursue for many people, but I disagree with the simplistic picture that people sometime paint wherein entrepreneurship is always glamorous and employment is always dreary.

Disclaimer: I work for Facebook.

We (FB) actually push new code every day.

"People tend to think of Common Lisp style hotpatching where you can dynamically build up your application from scratch without restarting the CL environment. Erlang doesn't really support that, but you can hack it to give you somewhat of the same."

I (almost) never restart my Erlang server, and that lets me develop just as you described. Why do you say it's not supported?

(Btw, it really sucks to go back and use languages that don't have hot code swapping. Developing in them feels terribly slow.)

Fast: if you put is_float() guards on your function definitions, Erlang will optimize their computation. If you worry about memory consumption of strings, use binaries.

"Note that the language was originally built for concurrency rather than parallel computation." I don't follow this argument. Isn't the point of concurrency to implement parallelism?

Erlang has reached prime time decades ago...

I think it's a lot easier to understand what some code does if you don't have to read a lot of language imposed cruft that surrounds the actual 'meat' of the algorithm.

Erlang really is easier than Java -- both to read and to write. I think people too often confuse "different" with "difficult".

The irony is that Erlang is so much easier than Java.

You can write readable code in any decent language, and you can just as easily write unreadable code in Python. The important variable is the programmer's skill, not some language-imposed restriction. Besides, bad use of white space is rarely what makes code unreadable. It's usually poor organization, functions/modules that are too long, non-descriptive names, overly complex class hierarchies, etc. I think Python is a nice language but I disagree that its whitespace rules make it so much more readable than other languages.

I launched Twoorl (http://twoorl.com), an Open Source microblogging platform, about a month ago.

Everything you said is true by my experience being involved in open source projects.

Another reason to do open source: it gives you a better chance of being able to work on something you enjoy because it connects you with like-minded people in the industry.

I think every programmer should be involved in some open source project. In most cases, a resume doesn't tell you much about someone's coding skills and real contributions, and technical interviews have many flaws in determining someone's qualifications. Only by looking at someone's code can you actually get a sense of their abilities.

It's much more interesting to interview someone who has done open source projects. You don't need to waste time figuring out if he or she can reverse a linked list. You can dive straight into more advanced topics.

I'm not sure about finding a cofounder though. I wouldn't feel comfortable partnering with someone if I hadn't gotten to know them by working closely with them.

Windows and Office are dominant but they are not monopolies. People have alternatives. I haven't used a Windows machine (at least at home) for years.

Twoorl started as a Twitter clone, but it doesn't mean it'll stay as such.

It's Twoorl (http://twoorl.com), of course :) Twoorl is open source and it's written in Erlang.

OO may not be inherently hard, but it is often used in overly complex ways, which makes it seem hard.

The OO patterns movement probably had something to do with it. It's easy sometimes to get the impression that with OO, you have to learn a bunch of weird patterns to produce good code, but with FP you don't have this conceptual overhead -- you just write the solution that feels the most compact and natural, almost in a mathematical sense.

Where OO does usually make life harder is in concurrent programming. Because objects have mutable state and hidden fields, it's difficult and often dangerous to send (and receive) them between processes. In Erlang, for example, all data is immutable and because it's made of simple (lists/tuples of) primitives, it's very easy to send it as messages (to processes on the local and/or remote VM) and to pattern match against it on the receiving end. This makes concurrent and distributed programming probably as easy as it can be.

I also find code written in function languages easier to read and debug because of data immutability. In code written in functional style, you know exactly where every variable is bound, so it's easy to track down bugs that cause it to have the wrong value. There's no mystery as to where a variable's data may be modified, which gives you confidence in the correctness of your solution.

I don't mean to suggest that FP is perfect and OO is broken. Sometimes when I write FP code I wish I could grab one or two concepts from OO. OO code can also be quite elegant as well.

Twoorl is broken in IE and FF3 I believe.

I hope such blog posts start appearing. It means Twoorl will have hit prime time :)

Mostly for convenience. ErlyDB makes working with databases very easy. I didn't see a compelling reason to use any alternatives.

Although I use MySQL, I haven't used any relational features. The app doesn't do any joins.

1700 LOC can't be that hard to port :)

Search is far from archaic. It's here to stay. Even if Xobni or Facebook figure out how to make useful suggestions by predicting my intentions (something I doubt would work very well, no matter how much they know about me), it would have a near insignificant impact on the utility I get from Google. People will always want to search for information and unless someone figures out how to build a better search engine than Google, Google will remain king.

With regards to new interfaces (voice/visual/whatever) that people sometimes say will be the "next big thing" in search -- these are just features that Google can easily implement if they prove to be so effective (which they probably won't -- I'd much rather type in my query than say it). Replicating the sophistication, performance and scale of Google is much harder.

Welcome to Erlang :)

I'm curious -- what kind of string processing tasks did you try to use it for? Did you compare its performance to other languages? Also, did you try to use binaries?

Erlang may not be optimal for applications that do heavy string processing, but the significance of that statement is overblown. Take typical webapps for example. What kind of string processing do they do? Very light stuff. They spend of their cycles slurping binary data from the database and sending it down a socket. Erlang is excellent for this usage. They occasionally take form inputs from a user, in which case they do some simple processing to ensure the input is properly escaped. Erlang handles that just fine.

Most of the "Erlang sucks for strings" arguments remind me of the "Ruby/Java is slow" arguments. They're sort-of true, but they just don't matter for most applications.

Erlang is great for writing high-availability, low latency server-based applications -- including web applications.

What people will use it for is up to their imagination. Wings3d (http://www.wings3d.com/) is a good example of using Erlang outside of its "intended" domain.

Don't forget that when Java came out, it was only "good" for writing applets...

Representing strings as lists can be very efficient depends on what you're trying to do. Incidentally, Haskell does the same thing.

I think the "Erlang sucks for strings" argument is overblown, and it's rarely if ever backed by real world experience and/or data. Erlang is fine for most string handling tasks you'll find in a typical (web) application.

The JVM had them a long time ago. They're gone, and it will be very hard to bring them back.