197 reputation
17
bio website
location Germany
age 36
visits member for 4 years
seen Sep 8 at 15:14

Haskell programmer. Diploma in Informatics (=Master in CS).


Dec
4
comment What's the worst question you were ever asked at interview?
LOL! and Ouch! What was your answer? A counterquestion?
Dec
4
comment What's the worst question you were ever asked at interview?
This was definitely a trick question: 1.) The coding style question is about what the interviewee would do in a situation of free choice, which is not given. 2.) The question itself /seems/ to be a stupid question, so there will most likely be a /hidden/ question, whose answer will be implied by the other. 3.) There were (how many?) bugs to be found.
Nov
10
comment Beautiful Erlang Code
oh, i just found this click-through slide show: slideshare.net/bos31337/…
Nov
9
awarded  Commentator
Nov
9
awarded  Critic
Nov
9
comment Beautiful Erlang Code
@Inaimathi: "networks of inter-communicating nodes", yeah, that might be very easy in Erlang, but I'm not that sure about reimplementing already existing protocols. In Haskell, I'd implement a library that wraps the TCP/Socket lib, and then use the Binary lib for serialization of Haskell values (which sounds of more than it is.). I did sth like that in my diploma thesis. It might look as easy as in Erlang, but I don't remember how Erlang comunicates over network. Dependant of the task, I would then prefer to design the flow with Arrows(fancy mathemagical stuff) instead of Actors(processes).
Nov
9
comment Beautiful Erlang Code
@Inaimathi: One example: Suppose, I already have an algorithm and want some parts of it parallelized to an unknown number of cpus. In that case, I just specify which chunks should be evaluated parallel (par) and which sequential (pseq). That is as easy as tagging on stackexchange.com, see <haskell.org/ghc/docs/6.12.2/html/users_guide/…;. The compiled program will have the number of OS-threads (=cpus) at the command line specified, on which it should run its internal lightweight haskell-level threads.
Nov
9
comment Beautiful Erlang Code
@Inaimathi: I did learn Erlang once, maybe 7-10 years ago, but did never code much in it. That was before I learned Haskell. Actually, I compare Erlang's concurrency support to that of Java, while Haskell can do far more with concurrency than just realizing the Actor design pattern. This might be interesting: <haskell.org/ghc/docs/6.12.2/html/users_guide/…;
Nov
9
comment Beautiful Erlang Code
@Inaimathi: "language whose principal construct is the process" seems weird to me: Erlang has not many types, and so is not well-typed and has to be debugged often. ProcessIDs have their own types, that seems to be all to me. Well, it is easy to have better concurrency support in functional programs than in imperative, but I do compare functional languages. In Haskell, you have far more features for concurrency, like parallelizable arrays (an extension) and a great (small) library for concurrency. see Control.Concurrent in <haskell.org/ghc/docs/latest/html/libraries/>;
Nov
9
comment Beautiful Erlang Code
@Inaimathi: Well, yeah, I know that Haskell is my Blub(see paulgraham.com/avg.html) language. I know only of one feature, where Haskell is not superior to Erlang: you can exchange running code in Erlang. I can't think of anything else than that.
Nov
8
awarded  Supporter
Nov
8
awarded  Editor
Nov
8
revised Beautiful Erlang Code
added 736 characters in body; added 97 characters in body
Nov
8
awarded  Teacher
Nov
7
answered Beautiful Erlang Code