nousernamesleft

getExecutablePath

No, I would expect a beginner to use getProgName. I would also expect anyone else to use getProgName also.

Because haskell has such a library (a few actually) and ocaml does not. So in ocaml you either have to give up safety, or write a bunch of verbose boilerplate. There's no reason someone couldn't write a lens library for ocaml of course, but the much smaller community makes for far fewer libraries.

Yes, it is a strawman. Strictness annotations are not unidiomatic any more than using laziness is in ocaml. The ocaml code is effectively using unsafePerformIO all over, ocaml doesn't offer the safety you are complaining that the haskell example gives up. And both of your invalid complaints are completely irrelevant to the question at hand.

The question was about difficulty, not a subjective idea of what idiomatic code looks like. Are you seriously claiming that the average haskell example there is more difficult to write than the average ocaml example? If so, just say that. Trying to redirect the discussion back to your subjective preferences is not productive.

You could just look at the code instead of making up a strawman to try to dismiss the only evidence presented. Poor evidence > no evidence.

I suspect the difference of opinion is due to a different understanding of what a functional style is. Python does not have tail call elimination. You literally can not write lots of normal functional programs in python. Python doesn't have currying and requires explicit extra code to create partially applied functions. This makes functional programming painful and verbose.

I think you are writing what I would call imperative code that uses some functional constructs where it is shorter. No doubt that is shorter than sticking entirely to imperative code, but it is a far cry from writing a program in functional style which requires that you not use imperative constructs.

>Not before writing his initial benchmarks

Yes, he did. Try talking to him.

>That measures ridiculous highly tuned implementations of the benchmarks

So, fast code. Which is what is at question.

>It contains absolutely no evidence of how hard it is to write fast programs in a language.

There is both lines of code, and actually looking at the code itself. Both of which make it appear that writing fast code is no more difficult in haskell than in ocaml.

>I'm pretty sure citing the language shoot-out is an automatic disqualification in any argument about language speed.

I'm pretty sure the language shoot-out is of greater value as evidence than personal anecdote is.

>He did the same for OCaml and got faster code

No he didn't. He took the time to learn ocaml.

>Obviously you can write fast code in Haskell, but that is not the same as it being easy.

The closest thing to evidence I can find suggests that it is no more difficult to write fast code in haskell:

http://benchmarksgame.alioth.debian.org/u64/benchmark.php?te...

>The "internal, ambiguous type" matters when you try to actually invoke (show . read) on some String

There is no internal ambiguous type. It is not a concrete type, it is a type variable. But it is inferred just fine. It is (Read a => a).

>which would lead many people to say that (show . read) is not "inferred just fine."

Even if you were to erroneously say that, it isn't type classes that is the problem.

Oops. So, I'm even more confused now. You know show. read is inferred just fine, and that means typeclasses break inference?

>I find it much easier

Ok, but your anecodes + my anecdotes = still just anecdotes. To support the claim that it is easier to write fast code in ocaml, we need to find evidence.

>Writing the equivalent Haskell code is much more work

I have not experienced anything like that, despite having much more experience with ocaml than with haskell. You are imposing limitations on yourself when using haskell and then saying haskell is imposing them. Every ocaml function is in IO, it just doesn't provide type information to tell you that. So doing the same thing in haskell is doing it in IO, which requires no special effort at all. Even if you choose to add a purity restriction on yourself, adding "runST $" does not seem like a lot of work to me.

Nope. Lenses aren't needed at all, they are just helpful. Lenses are just combined getter+setter that are composable. So you can use (lensA . lensB . lensC) to view, update or replace part of a data structure that is part of a data structure that is part of a data structure.

But both were fast. And if he had enabled optimizations like it was suggested, the difference would be smaller. And if he had used attoparsec instead of a regex it would have been easier, less error prone, and faster. He literally didn't learn haskell and copy and pasted random stuff from stackoverflow and irc.

No they don't.

    > :t read . show
    read . show :: (Read c, Show a) => a -> c

Having spent 6 years with ocaml, I can honestly say I both never wrote anything where ocaml offered a benefit haskell does not, and can not even think of such a program.

You pose two questions, one of which is effectively irrelevant, and the other I believe is based on an incorrect assumption. Maybe 5% of code the evaluation strategy matters. It makes no difference whether you are adding strictness for 2% of your code or adding laziness for 2% of your code.

The performance question I think is a misconception. Do you have any evidence to suggest it is easier to write fast code in ocaml? I've never found a person who has used both languages and felt that was the case. I've only found people without haskell experience believing that via second (or third, or fiftieth) hand rumors.

Ocaml offers two things over haskell. One, imperative constructs. This matters for people making a transition to functional programming, but not for people who've finished that transition. Second, the compiler is fast. I don't mean generates fast code, ghc does that too. I mean it generates code quickly. This is an annoyance with ghc, no question.

Haskell offers a lot over ocaml. A useful standard library. Cabal and hackage. Parallelism done right, out of the box (super cheap green threads multiplexed over a pool of OS threads). Tons of libraries that don't exist in ocaml, everywhere from attoparsec and aeson, to binary and lenses, pipes-concurrency and STM. A community that is ten times the size of ocaml's.

There are good reasons it has gone from ocaml having the larger community to haskell dwarfing ocaml in community size, language usage, library availability, etc. in the last decade.

The plan 9 team do not consider it a feature. Hence it does not exist.

Typeclasses don't interfere with type inference.

    > :t (+ 5)
    (+ 5) :: Num a => a -> a

>It's a pretty old page. I'm not sure its content is still accurate

Half of it never was as it is just "ocaml isn't lisp and I can't handle that".

Two reasons. First, they are both languages with useful type systems. There's not many languages in that group.

Second, ocaml is a multiparadigm language for real, and with a focus of functional first. Python, ruby, perl, etc are procedural/OO languages that have map and filter. It is a huge pain and tons of extra code to write a program in functional style in python, it is lacking basically everything. It is normal to write a program in a functional style in ocaml.

If you learn haskell first, ocaml will serve no purpose for you. But for someone coming from imperative land, learning ocaml can be a helpful half-way house on the way to haskell.

This isn't a shame, it does nothing. Plan 9 was already released under a BSD style license (one with an absurd amount of pointless legalese, but non-copyleft nonetheless). This is simply releasing it with additional restrictions so that people who are contributing to GPL software can use it now too.

Correct. Just like unix. If something crashes, there is a serious problem. Restarting it blindly is typically going to do more harm than good (allowing the attacker who crashed it infinite chances to keep trying to exploit the bug rather than just crash the process). When something crashes, you fix it, you don't just restart it and pretend that is supposed to happen.

Where to even begin. First of all, plan 9 is already under a BSD style license, it always has been. They just also let people have it with extra restrictions now (the GPL) because RMS is a lunatic and insists that some licenses are not GPL compatible because they contain a clause he thinks would make it a contract. Despite the obvious fact that the GPL is legally a contract whether he likes it or not.

>Every time I look at Android phone or TV or a router I regret that BSD/MIT/Apache is so popular

Android is built on the linux kernel, which is GPL. You are proving yourself wrong with that example.

> And users can't do anything about that.

Of course they can. If they do not want that, they can choose not to purchase it. It isn't rocket science. You are simply upset because actual users are proving you wrong, and showing that they don't give a shit about things being GPL. Your "but think of the users" histrionics are so transparently fake it is insulting everyone's intelligence to continue repeating it.

Proprietary software would still exist without free software. People who write software can do whatever they like with it, and it is incredibly self-absorbed and arrogant to suggest that giving away something they made is a problem because it violates your arbitrary belief system.

Oh, it read as though you were giving them as an example of problems.

>More fundamentally they were centralized and Linus had experience from watching the BSDs and knew that a centralized version control was actually worse than none

Watching another group from the outside is not experience. But what makes you say he even had that? He's pretty consistently suggested he has no time to pay any attention to any of the BSD projects going right back to 1993.

>Just remember the multiple WebKit debacles or the BSDs

I don't know anything about webkits, but how are "the BSDs" relevant?