This is clearly a job for node.js and the /dev/null data store, since they are so web scale~ Less sarcasm: I think any of the main Haskell web frameworks (Yesod, Happstack, Snap) could scale better than Ruby or PHP, and would use any of those in a heartbeat for such a venture. I'd personally use Yesod. I think data store would be a trickier issue. I'd likely use one of the key/value stores out there, possibly Redis, though I'd really need to do more research to give a real answer. Michael On Fri, Oct 21, 2011 at 9:42 AM, Yves Parès wrote:

Wow, controversial point I guess... I would add: and if yes, what would you use and why?

2011/10/21 Goutam Tmv

...

Would you ever see yourself write a web application like Twitter or Facebook in Haskell?

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Let's look at this from a high, project management level. Twitter ran on... Ruby initially? Facebook ran on PHP. Immediately this tells me that programming language choice wasn't a factor in their success. One succeeded in building a large throughput system with a "slow" language, the other succeeded in building a massively popular website with a bad one. What hard problems did they have to solve? Twitter had to deal with scalability, distribution, and massive throughput. These are hard problems on their own, and are non-trivial even in languages tailor made to handle them. (Although using Erlang would make things a good deal easier.) Facebook is not a technical problem at all. There are interesting challenges hidden within (ad targeting and friend feed optimization) but they're tiny, isolated components. Rapid development and prototyping of features help Facebook, but if the features are easy CRUD stuff it's perfectly cost effective to hire a pile of PHP developers to do them. One has problems that are hard regardless of tool choice, the other has no hard problems at all. No Haskell needed, use whatever language you can outsource overseas. With that in mind. Using Haskell gives you an edge, for most problems, even the ones with poor libraries. If you can get the programmer manpower you need, it is a clear advantage over your competition. Your startup may not need that advantage - as Facebook retrospectively didn't - but you don't know that when just starting out. If Facebook went deep into user behaviour analysis and newsfeed optimization, the way OkCupid has with dating, Haskell would suddenly stand out. If you need every advantage you can get, you use the best tools for the job. Haskell is one of the best and shiniest - I personally would use Erlang for any embarrassingly parallel parts of the service and do the rest in Haskell. On Fri, Oct 21, 2011 at 1:00 AM, Matti Oinas wrote:

I don't think I'm going to write next twitter or facebook but yes, it is on my TODO list. If such an applications can be written with languages like PHP then why not. Can't think of any language that is worse than PHP but still there are lots of web applications written with that. Even I have written many using PHP.

Why I would use Haskell? To see if it is better option to that problem than other languages.

I have allready installed Yesod but for now I don't have enough time to work on this project. After 6 months the situation should be different.

2011/10/21 Michael Snoyman :

...

This is clearly a job for node.js and the /dev/null data store, since they are so web scale~

Less sarcasm: I think any of the main Haskell web frameworks (Yesod, Happstack, Snap) could scale better than Ruby or PHP, and would use any of those in a heartbeat for such a venture. I'd personally use Yesod.

I think data store would be a trickier issue. I'd likely use one of the key/value stores out there, possibly Redis, though I'd really need to do more research to give a real answer.

Michael

On Fri, Oct 21, 2011 at 9:42 AM, Yves Parès wrote:

...

Wow, controversial point I guess... I would add: and if yes, what would you use and why?

2011/10/21 Goutam Tmv

...

Would you ever see yourself write a web application like Twitter or Facebook in Haskell?

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- /*******************************************************************/

try { log.trace("Id=" + request.getUser().getId() + " accesses " + manager.getPage().getUrl().toString()) } catch(NullPointerException e) {}

/*******************************************************************/

This is a real code, but please make the world a bit better place and don’t do it, ever.

* http://www.javacodegeeks.com/2011/01/10-tips-proper-application-logging.html...

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On Fri, Oct 21, 2011 at 8:02 AM, Yves Parès wrote:

That's interesting, have you ever worked on interfacing Erlang with Haskell?

I have interfaced Erlang and Haskell... And delivered it as a product. I just came up with a dead-simple text based communication syntax from Erlang to Haskell that was very easily testable. It allowed for complete isolation of components and them to be developed and debugged in parallel. The Haskell code was an Erlang "pipe driver", which, in turn was connected to a C program to drive a polling interface, controlled by Haskell with the fancy IO done in C. All of this was on a relatively small linux "appliance". I'm pretty proud of that little system. It was quickly done, and I was able to mock out various pieces of it very quickly as well. When the hardware it was meant to control finally arrived I think I only spent a few extra hours turning the screws to make it work for real.... and then we discovered wiring problems :-)

BTW, Twitter switched to Scala, so obviously their initial choice of Ruby end up invalidated.

I believe they have Java, Clojure and Scala actually. I know of a guy doing a start up using only Go, and that language is not even fully released yet. They're most definitely using Clojure in their Storm "realtime" event processing framework anyway, and it's freely available. Other than finding people who can come work for you writing good Haskell code, I don't see any reason to avoid doing a startup using that language as a code base. The Haskell Platform makes things a little nicer, but needs to have more regular releases. Go comes with a lot of "batteries" already making it slightly more attractive. Dave

2011/10/21 Alex Kropivny

...

Let's look at this from a high, project management level. Twitter ran on... Ruby initially? Facebook ran on PHP.

Immediately this tells me that programming language choice wasn't a factor in their success. One succeeded in building a large throughput system with a "slow" language, the other succeeded in building a massively popular website with a bad one.

What hard problems did they have to solve?

Twitter had to deal with scalability, distribution, and massive throughput. These are hard problems on their own, and are non-trivial even in languages tailor made to handle them. (Although using Erlang would make things a good deal easier.)

Facebook is not a technical problem at all. There are interesting challenges hidden within (ad targeting and friend feed optimization) but they're tiny, isolated components. Rapid development and prototyping of features help Facebook, but if the features are easy CRUD stuff it's perfectly cost effective to hire a pile of PHP developers to do them.

One has problems that are hard regardless of tool choice, the other has no hard problems at all. No Haskell needed, use whatever language you can outsource overseas.

With that in mind. Using Haskell gives you an edge, for most problems, even the ones with poor libraries. If you can get the programmer manpower you need, it is a clear advantage over your competition.

Your startup may not need that advantage - as Facebook retrospectively didn't - but you don't know that when just starting out. If Facebook went deep into user behaviour analysis and newsfeed optimization, the way OkCupid has with dating, Haskell would suddenly stand out.

If you need every advantage you can get, you use the best tools for the job. Haskell is one of the best and shiniest - I personally would use Erlang for any embarrassingly parallel parts of the service and do the rest in Haskell.

On Fri, Oct 21, 2011 at 1:00 AM, Matti Oinas wrote:

...

I don't think I'm going to write next twitter or facebook but yes, it is on my TODO list. If such an applications can be written with languages like PHP then why not. Can't think of any language that is worse than PHP but still there are lots of web applications written with that. Even I have written many using PHP.

Why I would use Haskell? To see if it is better option to that problem than other languages.

I have allready installed Yesod but for now I don't have enough time to work on this project. After 6 months the situation should be different.

2011/10/21 Michael Snoyman :

...

This is clearly a job for node.js and the /dev/null data store, since they are so web scale~

Less sarcasm: I think any of the main Haskell web frameworks (Yesod, Happstack, Snap) could scale better than Ruby or PHP, and would use any of those in a heartbeat for such a venture. I'd personally use Yesod.

I think data store would be a trickier issue. I'd likely use one of the key/value stores out there, possibly Redis, though I'd really need to do more research to give a real answer.

Michael

On Fri, Oct 21, 2011 at 9:42 AM, Yves Parès wrote:

...

Wow, controversial point I guess... I would add: and if yes, what would you use and why?

2011/10/21 Goutam Tmv

...

Would you ever see yourself write a web application like Twitter or Facebook in Haskell?

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- /*******************************************************************/

try { log.trace("Id=" + request.getUser().getId() + " accesses " + manager.getPage().getUrl().toString()) } catch(NullPointerException e) {}

/*******************************************************************/

This is a real code, but please make the world a bit better place and don’t do it, ever.

* http://www.javacodegeeks.com/2011/01/10-tips-proper-application-logging.html...

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On Thu, Nov 3, 2011 at 9:09 PM, Ryan Newton wrote:

...

I have interfaced Erlang and Haskell... And delivered it as a product. I just came up with a dead-simple text based communication syntax from Erlang to Haskell that was very easily testable. It allowed for complete isolation

Interesting. I can't imagine there are too many people who have done this. So I must ask -- given the explicit attempt to imitate Erlang in recent CloudHaskell work, does that come close to giving you everything you would have wanted in this app?

I don't know, as I've not looked at all at CloudHaskell at all. My current job doesn't really give me a lot of time for it. There's definite advantages to polyglot programming approaches. The difficulty is in the glue, and that doesn't have to really be that difficult. I just picked a text based protocol that was really easy to implement and understand as well as test externally. No XML, no JSON, nothing "standardized", just tiny and really obvious. With a sufficiently simple protocol getting C++, haskell and erlang on the same page was pretty trivial, and the separation of concerns for each piece was really well drawn. It felt like what was meant by the unix philosophy of one good tool for each job coordinated over pipes because well that's exactly what I did. Dave

(Hot code update being the big missing piece.)

Cheers, -Ryan

Yes I did, in detail. There are two trivial solutions I like: 1. The BERT library (http://bert-rpc.org/) uses Erlang terms for the protocol, and has straightforward mappings to Haskell equivalents. - Pros: trivial on both sides, Erlang terms are really good primitives to build a protocol from - Cons: Erlang likes using large (5 to 10 size) tuples and Haskell doesn't, protocol needs to take that into account 2. JSON over HTTP, Erlang's the server Haskell's the client. - Pros: discoverable, flexible, readable, language agnostic. - Cons: I don't really know how to use Haskell JSON libraries + which ones are good, and good REST API design can be tricky. For higher performance there are other options, but these are the ones I like most. I used 1 to decent effect when using QuickCheck to test an Erlang system. On Fri, Oct 21, 2011 at 8:02 AM, Yves Parès wrote:

That's interesting, have you ever worked on interfacing Erlang with Haskell?

BTW, Twitter switched to Scala, so obviously their initial choice of Ruby end up invalidated.

2011/10/21 Alex Kropivny

...

Let's look at this from a high, project management level. Twitter ran on... Ruby initially? Facebook ran on PHP.

Immediately this tells me that programming language choice wasn't a factor in their success. One succeeded in building a large throughput system with a "slow" language, the other succeeded in building a massively popular website with a bad one.

What hard problems did they have to solve?

Twitter had to deal with scalability, distribution, and massive throughput. These are hard problems on their own, and are non-trivial even in languages tailor made to handle them. (Although using Erlang would make things a good deal easier.)

Facebook is not a technical problem at all. There are interesting challenges hidden within (ad targeting and friend feed optimization) but they're tiny, isolated components. Rapid development and prototyping of features help Facebook, but if the features are easy CRUD stuff it's perfectly cost effective to hire a pile of PHP developers to do them.

One has problems that are hard regardless of tool choice, the other has no hard problems at all. No Haskell needed, use whatever language you can outsource overseas.

With that in mind. Using Haskell gives you an edge, for most problems, even the ones with poor libraries. If you can get the programmer manpower you need, it is a clear advantage over your competition.

Your startup may not need that advantage - as Facebook retrospectively didn't - but you don't know that when just starting out. If Facebook went deep into user behaviour analysis and newsfeed optimization, the way OkCupid has with dating, Haskell would suddenly stand out.

If you need every advantage you can get, you use the best tools for the job. Haskell is one of the best and shiniest - I personally would use Erlang for any embarrassingly parallel parts of the service and do the rest in Haskell.

On Fri, Oct 21, 2011 at 1:00 AM, Matti Oinas wrote:

...

I don't think I'm going to write next twitter or facebook but yes, it is on my TODO list. If such an applications can be written with languages like PHP then why not. Can't think of any language that is worse than PHP but still there are lots of web applications written with that. Even I have written many using PHP.

Why I would use Haskell? To see if it is better option to that problem than other languages.

I have allready installed Yesod but for now I don't have enough time to work on this project. After 6 months the situation should be different.

2011/10/21 Michael Snoyman :

...

This is clearly a job for node.js and the /dev/null data store, since they are so web scale~

Less sarcasm: I think any of the main Haskell web frameworks (Yesod, Happstack, Snap) could scale better than Ruby or PHP, and would use any of those in a heartbeat for such a venture. I'd personally use Yesod.

I think data store would be a trickier issue. I'd likely use one of the key/value stores out there, possibly Redis, though I'd really need to do more research to give a real answer.

Michael

On Fri, Oct 21, 2011 at 9:42 AM, Yves Parès wrote:

...

Wow, controversial point I guess... I would add: and if yes, what would you use and why?

2011/10/21 Goutam Tmv

...

Would you ever see yourself write a web application like Twitter or Facebook in Haskell?

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- /*******************************************************************/

try { log.trace("Id=" + request.getUser().getId() + " accesses " + manager.getPage().getUrl().toString()) } catch(NullPointerException e) {}

/*******************************************************************/

This is a real code, but please make the world a bit better place and don’t do it, ever.

* http://www.javacodegeeks.com/2011/01/10-tips-proper-application-logging.html...

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On 11-10-21 03:59 AM, Ivan Lazar Miljenovic wrote:

2011/10/21 Goutam Tmv:

...

Would you ever see yourself write a web application like Twitter or Facebook in Haskell?

No. But then, I wouldn't write a web application like either of them in _any_ language.

+1 The world does not need another Twitter, another Facebook, another Reddit, another graphics engine, another database system, or another operating system.

Ok, I'll bite: what's it need? - Tom / amindfv On Fri, Oct 21, 2011 at 1:51 PM, Albert Y. C. Lai wrote:

On 11-10-21 03:59 AM, Ivan Lazar Miljenovic wrote:

...

2011/10/21 Goutam Tmv:

...

Would you ever see yourself write a web application like Twitter or Facebook in Haskell?

No. But then, I wouldn't write a web application like either of them in _any_ language.

+1

The world does not need another Twitter, another Facebook, another Reddit, another graphics engine, another database system, or another operating system.

______________________________**_________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/**mailman/listinfo/haskell-cafehttp://www.haskell.org/mailman/listinfo/haskell-cafe

The world needs programmers to accept and take seriously Greg Wilson's extensible programming, and stop laughing it off as "lolwut wysiwyg msword for programming", and start implementing it. http://third-bit.com/blog/archives/4302.html

Who is "the world"? For starters, I don't think it is Greg Wilson's idea, and if you look for alternate sources, often under other titles, you'll find parts of it implemented, with varying degrees of success and often little acceptance. The idea is much older than one might think - conferences on extensible languages were held around 1970. Early implementation approximations didn't have the disposable computing power of today's PCs, nor did early implementers find an audience ready for their ideas (to feed their students or themselves, some of those who were such ahead of the curve had to switch to working on more conventional, funded, topics). Useful search keys: - extensible languages (as in AI, the meaning of "extensible" tends to be redefined whenever a problem gets solved, so many features that used to mark an extensible language in the past have now become standard) - structure editors (in that they were forerunners of projectional IDEs, and exhibited some of their advantages and disadvantages; there have been many efforts to generate structure editors from language descriptions) - projectional language workbenches (instead of parsing source to AST, the IDE/workbench operates on an AST-like abstract model, and source code views are just projections of that; makes it easier to embed sublanguages); Smalltalkers will probably claim their image-based IDEs have been doing that all along. - hyper-programming (where persistent runtime data can be embedded in code via linking, similar to hypertext, with generic editors instead of generic Read/Show) - Banana Algebra: Syntactic Language Extension via an Algebra of Languages and Transformations (one example of research on language composition) IDE generators, IDE tooling for domain-specific languages, language-oriented programming, language workbenches, ... they all contribute to the now broader interest in the topic. In the context of Haskell, there once was Keith Hanna's document-centered programming: http://www.cs.kent.ac.uk/projects/vital/ http://www.cs.kent.ac.uk/projects/pivotal/ Perhaps Keith's projects can serve as an inspiration to just start hacking?-) The subject is an instance of these quotes: "The future is already here - it's just not very evenly distributed." William Gibson "The best way to predict the future is to invent it." Alan Kay Claus http://clausreinke.github.com/