[Haskell-cafe] [ANNOUNCE] CoreErlang-0.0.2 + maintainer change
Hello, With the authors blessing, I'm taking over maintenance for http://hackage.haskell.org/package/CoreErlang, a parser/printer for an intermediate language for the Erlang VM. Changes in 0.0.2: - fixed float parse bug - added Data,Typeable instances to AST Package is rather esoteric, but it's nice for static source analysis - and when someone decides they want to compile a new language to the ERTS, the package is ready... Regards, Alex Kropivny ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Message
Short answer: no, and what it gives is quite different. Long answer: Erlang gives me two things that are hard to replicate: 1. firm-realtime performance, even at high load: the distributed GC is very nice 2. a very well defined model for handling, and recovering from failure Hot code reload is nice, but is mostly used as a bandaid for the multitude of bugs present with dynamic typing and a let it crash (minimal defensive programming, let process isolation handle bad cases by failing) approach. So it's absence in Haskell doesn't bother me. 1 is a personal preference that's been useful in a couple of projects. It's application specific and probably not a factor for most people, I just had a chance to enjoy it. 2 is solved in Erlang via techniques and know-how built up from years of practice and testing. High level abstractions like supervision trees, restart types, and gen_servers are well known. Most importantly, the correct way to use them to build robust systems is well known. This is definitely duplicateable, it just needs some time and lots of testing to reach the same level of trust I've got for Erlang. My Haskell code is mostly total, and avoids failure-in-the-small (stupid bugs) amazingly well. My Erlang code is an onion of recovery points, and avoids failure-in-the-large (hardware/link failures, nasty corner cases) amazingly well. CloudHaskell looks like it provides the fundamental abstractions needed to start building the onion, and bring Erlang's robustness to Haskell. Getting to the same point will take time and effort, but I think is possible. On Thu, Nov 3, 2011 at 9:09 PM, Ryan Newton rrnew...@gmail.com 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? (Hot code update being the big missing piece.) Cheers, -Ryan ___ 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] New CoreErlang maintainer + patch
Hello, I've got a patch [1] for the CoreErlang package. It fixes a parsing bug and adds Typeable+Data instances to the syntax tree. I was unable to contact the developers/maintainers via provided email. (No response in ~3 weeks.) The package hasn't been touched for three years, since first uploaded. I would like to take over maintenance of the package, and upload the fix ASAP. Regards, Alex Kropivny [1] https://github.com/amtal/CoreErlang/tree/0.0.2 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Message
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 matti.oi...@gmail.com 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 mich...@snoyman.com:
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 limestr...@gmail.com
wrote:
Wow, controversial point I guess...
I would add: and if yes, what would you use and why?
2011/10/21 Goutam Tmv vo1d_poin...@live.com
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
Re: [Haskell-cafe] Message
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 limestr...@gmail.com 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 alex.kropi...@gmail.com 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 matti.oi...@gmail.comwrote: 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 mich...@snoyman.com: 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 limestr...@gmail.com wrote: Wow, controversial point I guess... I would add: and if yes, what would you use and why? 2011/10/21 Goutam Tmv vo1d_poin...@live.com 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
Re: [Haskell-cafe] Erlang's module discussion
Regardless of how crazy it sounds, an idea from Joe Armstrong is worth seriously thinking over. This has bugged me before: think about how we design and write code as project size, or programmer skill grows. You start with composing statements inside a single function; later, you start to compose functions inside a single file; later you move on to composing modules; subsystems; systems... Different techniques, doing the same thing in different ways, depending on the level of complexity. Surely there's some unified approach that can replace them all? Erlang has the advantage of functions being the basic, composeable building block. Packages and modules are merely means to organize them, and mediocre means at that, so a better system is definitely a possibility. Haskell has the complication of having type definitions in addition to functions. On Sat, May 28, 2011 at 1:09 AM, Dmitry Vyal akam...@gmail.com wrote: On 28.05.2011 07:10, Tom Murphy wrote: Hi All, I sure love Hackage, but there's a very interesting discussion going on, on the Erlang mailing list, about completely restructuring the module-model. Before you dismiss it as crazy, know that the topic was brought up by Joe Armstrong, one of the creators of the language. Here's the archive: http://erlang.org/pipermail/erlang-questions/2011-May/058769.html Food for thought... Tom Hi Tom, sounds interesting! But seems to me this will raise current package dependencies problems on a new level. Now one sees modules and packages as some kind of aggregates, black boxes which supply useful functionality and hide non relevant complexity and tight dependencies. Moving to functions all the way down looks to me like a lowering level of abstraction. The meta information about the overall program structure would inevitably be lost. Dmitry ___ 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
Re: [Haskell-cafe] How about Haskell Golf just like vimgolf.com
Could a subreddit of some kind be used for this, or is a new site necessary? I can see a subreddit where people vote for problems they'd like to see elegant solutions to, then solutions are in the replies and get voted on. Might be tricky for larger solutions (you'd have to move them to git/gist or whatever) but would be amazing for learning good Haskell if it got off the ground! On Mon, Jan 3, 2011 at 8:19 AM, Ertugrul Soeylemez e...@ertes.de wrote: Alex Kropivny alex.kropi...@gmail.com wrote: Could something like code abstraction be done instead? Haskell lends itself to solving problems in really generic, high level ways that reveal a LOT about the underlying problem structure. Through some combination of descriptive data types, generic type classes, and generic helper functions... You get an extremely clear problem description. Example: https://github.com/amtal/snippets/blob/master/Key.hs (Haskell) versus http://siyobik.info/index.php?module=pastebinid=543 (C++) Clarity is a lot harder to score for, so you'd probably need to score things via votes. (Unless there's a way to measure how generic/high-level code is?) Such a site would fill a very nice role, that the programming language shootout definitely does not fill. Currently the only way to figure out what good Haskell code looks like is to browse lots of blogs, and dig through hackage until you find beautifully written packages. I really like this idea. New concepts in Haskell come up from time to time. Now if there was a competition for code quality and good ideas, they may become more frequent. Greets, Ertugrul -- nightmare = unsafePerformIO (getWrongWife = sex) http://ertes.de/ ___ 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
Re: [Haskell-cafe] How about Haskell Golf just like vimgolf.com
Could something like code abstraction be done instead? Haskell lends itself to solving problems in really generic, high level ways that reveal a LOT about the underlying problem structure. Through some combination of descriptive data types, generic type classes, and generic helper functions... You get an extremely clear problem description. Example: https://github.com/amtal/snippets/blob/master/Key.hs (Haskell) versus http://siyobik.info/index.php?module=pastebinid=543 (C++) Clarity is a lot harder to score for, so you'd probably need to score things via votes. (Unless there's a way to measure how generic/high-level code is?) Such a site would fill a very nice role, that the programming language shootout definitely does not fill. Currently the only way to figure out what good Haskell code looks like is to browse lots of blogs, and dig through hackage until you find beautifully written packages. On Sun, Jan 2, 2011 at 9:20 AM, Brandon S Allbery KF8NH allb...@ece.cmu.edu wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 1/2/11 02:48 , C K Kashyap wrote: I found this site called http://vimgolf.com/ ... the idea there is that people come up with challenges and try to come up with the least number of keystrokes to get it done. Code golf in any language is generally a recipe for obfuscation. Interesting, certainly, but I don't think I'd recommend it as a service or feature. - -- brandon s. allbery [linux,solaris,freebsd,perl] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0gs90ACgkQIn7hlCsL25XOAACfQhq2bb18442MYAROhnqZ3jJ6 b7kAoIaJ8LNsAdjlEHZDftAspWtUgJ43 =zjuv -END PGP SIGNATURE- ___ 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
Re: [Haskell-cafe] Google AI Challenge: Planet Wars - Accepting Haskell Submissions
The previous AI challenge (tron) was a lot of fun. I suspect the experience they gained from running the last one, will make this an exciting contest. Haskell fared well in the last contest, despite it favouring fast C/C++ implementations due to a focus on classic minimax/pruning. The current challenge looks more open-ended as far as solutions go, so hopefully there'll see even more Haskell submissions! :) On Fri, Sep 10, 2010 at 4:11 PM, Jake McArthur jake.mcart...@gmail.com wrote: Just wanted to let everybody know that there is an AI contest [1] that started today. Everybody has about two months to create bots that compete against each other 1-on-1 in a game based on Galcon [2]. A couple issues to mention for full disclosure: There is some sponsorship by Google, but unfortunately they aren't running the hardware, so the site is getting pretty hammered right now. We (it's all open source and open for contributions) are working to get it optimized to better handle the load. Also, the version of GHC on the server is very old (6.8.2) and isn't likely to get updated. I'm working to allow binary submissions though. If that goes through, you guys will be able to submit 64-bit Linux binaries rather than Haskell code to be compiled on the server. Just letting everybody know so the Haskell community can represent! - Jake [1] http://ai-contest.com [2] http://galcon.com ___ 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
