<Vincenz>
well I'm hoping someone isn't biased towards one
<Vincenz>
I did
<Vincenz>
they said haskell of course :P
<vegai>
makes sense
<Vincenz>
but as a newbie that doesn't get me anywhere
<vegai>
I guess the only choice is to spend some time to take a look at both
<vegai>
or use a die
<vegai>
flip a coin"
<pattern_>
i'm a beginner too, but i chose to learn ocaml over haskell
<vegai>
haskell seems more elegant, and ocaml seems more practical
<pattern_>
my reasons was that it seemed to be more efficient, did much better on the great language shootout (convinced the editor of the shootout to choose ocaml as his new favorite language)
<pattern_>
ocaml is supposed to be easier than haskell to learn (no absolute need for monads, less confusing than being forced in to lazy evaluation)
<vegai>
yes, that's one
<Vincenz>
the problem is, most people will tell you both, I don't have time for that.
<dash>
if i could define new python types with pycaml... i'd give up C
<dash>
Vincenz: in a hurry? :)
<Vincenz>
and that's why I chose ruby over python and I'm not touching python for the moment
<Vincenz>
dash: I work, have limited free time...
<pattern_>
and ocaml lets you program in the imperative, functional, and object oriented styles... so more flexible than haskell
<Vincenz>
haskell's argument is that it's cleaner
<dash>
"object oriented"? heh, not really
<Vincenz>
I'm just not sure how I would do normal coding in FP, I mean it's great to pass functions over collections and such....but regular code like gui, file IO, etc...
<vegai>
how about the language "clean"? It looks pretty ... clean
<pattern_>
i heard clean was proprietary
<vegai>
ruby vs ocaml... where do they come up with these ;)
<vegai>
pattern_: the compiler is LGPL, iirc
<pattern_>
read the article and see :)
<dash>
pattern_: it was, now it's lgpl
<pattern_>
ahh
<Vincenz>
vegai: that's like assembly vs javascript
<vegai>
Vincenz: indeed
<pattern_>
check out the article
<Vincenz>
I am
<dash>
"ruby vs ocaml"? that's like comparing apples and lumberjacks
<pattern_>
ok, ok... read the article :P
<Vincenz>
but....for short scripting...wouldn't ruby be easier
<Vincenz>
especially opening sockets and such
<Vincenz>
regexps
<Vincenz>
it's like perl but...clean
* Vincenz
hates perl
<dash>
heh
<dash>
python's better than ruby :) not least because of the ocaml interface
<Vincenz>
oh
<Vincenz>
ruby is cleaner than python, just a little less supported...
<Vincenz>
IHMO
<dash>
Vincenz: "cleaner" how?
<Vincenz>
pure OO
<dash>
meaning what?
<Vincenz>
really pure
<mellum>
dash: Well, *any* language is cleaner than Perl
<dash>
mellum: welllll
<Vincenz>
mellum: hehe
<dash>
mellum: i'd argue that C++ and Forth aren't. :)
<dash>
Vincenz: what do you mean?
<mellum>
dash: well, they maybe come close :)
<Vincenz>
dash: python is a combination of procedural and OO
<Vincenz>
in ruby EVERYTHING is an object
<Vincenz>
I don't know, it just fit for me
<dash>
Vincenz: in python, everything is an object
<mellum>
anyway, Perl is one of very few languages I would discourage people to learn...
<Vincenz>
even procedures you define?
<dash>
Vincenz: of course
<dash>
Vincenz: always has been
<vegai>
mellum: otoh, it's one of a kind
<pattern_>
"i finished a fp-and-co-languages review, incluing OCaml, Haskell (very nice), Scheme (extremely elegant), ML (well, you've got OCaml) and, last and very least, Python (please, use Perl instead). At first, it was hard to get used to OCaml's syntax, but i learnt step by step to love it... and, oh well, it's just syntax. What really matters is the new semantic world that functional programming opens up; each functional language i've tried came
<pattern_>
ed with a handful of little conceptual treasures: type inference, first-class currying and functors in ocaml; lazy evaluation and monads in haskell (with the nicest quicksort evaluation i've ever seen); continuations and macros in scheme... no wonder that reading the python tutorial was so disappointing!"
<dash>
pattern_: heh. how shallow :)
<Vincenz>
I don't know about scheme, I think macros are just problems waiting to happen
<dash>
Vincenz: mmh. scheme macros are boring and complicated
<dash>
not like CL macros
<dash>
Vincenz: macros are _solutions_ waiting to happen :)
<Vincenz>
dash: not for code readability
<mellum>
I think scheme macros are cool. The thing I dislike about Scheme is that because of the lack of compile time type checking, you find many errors only ar run time
<Vincenz>
that too
<dash>
Vincenz: anybody can write unreadable code. you dont need macros to make that happen.
<Vincenz>
compile time checking is nice
<dash>
eh
<Vincenz>
dash: of course, but some are more leniant towards it
<dash>
problem is, one keeps tripping over the typechcker
<dash>
Vincenz: no
<dash>
Vincenz: the question isn't "how hard is writing bad code"
<dash>
the question is "how easy is writing good code"
<mellum>
It's just nice for example if you choose to have a tuple where you used to use an int, to get pointed by the type checker to every instance where it is used wrong
<dash>
mellum: eh
<pattern_>
i agree... soooo many bugs get pointed out to you by the compiler with ocaml
<vegai>
personally, now that I've learned the excellent syntax of python, almost every other language looks dead ugly
<pattern_>
bugs that you wouldn't have caught except at runtime with most other languages... and catching bugs at runtime is unreliable
<dash>
i keep hearing that, but fixing type errors is not a significant time-consumer for me
<mellum>
dash: well, it is for us lesser beings
<pattern_>
python syntax doesn't look much different from perl... or most any other imperative language
<dash>
mellum: are you using unit tests?
<pattern_>
c-like language, i should say
<mellum>
dash: no
<dash>
pattern_: implicit references makes a _big_ difference.
<mellum>
dash: and testing can't catch all bugs anyway. Everybody knows that.
<dash>
mellum: nor can typecheckers.
<mellum>
Well, got to get back to work... see you later
<vegai>
pattern_: ...
<dash>
mellum: But it does at least exercise the code.
<pattern_>
dash, no fixing type errors might not take a lot of time, but it could cost you in terms of undiscovered bugs with other languages... every single one of those bugs is discovered for you with ocaml at compilation time
<dash>
pattern_: sure, but like i said, type errors are not the main errors i have to deal with
<dash>
anyhow
<pattern_>
unit tests are great... and there's no reason why you couldn't use them with ocaml
<dash>
agreed
<dash>
any of you guys know anything about denotational semantics? :)
<pattern_>
again, they may not be the main type of error, but a bug is a bug, and if your code is important to you any bug could be a serious problem
<dash>
pattern_: sure, but it's a tradeoff
<pattern_>
if the space shuttle crashed because of a bug it doesn't really much matter whether it was a type bug or not ;)
<pattern_>
what's the tradeoff?
<dash>
pattern_: that's a really bad example
<dash>
most programmers dont write space shuttles
<mattam>
dash: :)
<dash>
or anything that requires that level of reliability
<pattern_>
but they could write financial systems, where you could loose lots of money because of a bug... or medical problems, costing lives, etc...
<dash>
the techniques and practices appropriate to that sort of project are totally different
<pattern_>
not everyone is writing screensavers where a bug is no big deal
<dash>
pattern_: anyway. if you have a good suite of tests, your type bugs will be caught
<pattern_>
yep
<dash>
as well as other bugs a typechecker will not catch
<dash>
the primary reason i like ocaml is because it's fast and pointer-safe :)
<pattern_>
but why waste time essentially re-implementing a typechecker with your unit tests, when you get it with ocaml for free?
<pattern_>
yeah, those are great reasons too
<dash>
pattern_: because it isn't for free
<vegai>
unit tests do more than typecheck
<dash>
you have to adapt yourself to its strictures
<vegai>
or... they should
<dash>
vegai: yep
<pattern_>
vegai, nothing stops you from writing unit tests with ocaml
<vegai>
pattern_: of course
<pattern_>
yes, ocaml is definately restricting because of its type safety
<pattern_>
same with its garbage collection and lack of pointers
<pattern_>
similar arguments can be made against any high level language
<dash>
pattern_: heh.
<dash>
anyway, if nobody's wanting to talk about denotational semantics, i'm going to bed :)
<pattern_>
not that i think ocaml is heaven sent by any means... i'm still trying to really understand functional style, which is the most difficult thing about ocaml to me
<vegai>
I've learned a semi-functional style from python, and I didn't even try ;)
<pattern_>
well, you must be smarter than me ;P
karryall has joined #ocaml
<vegai>
I'd vote "no" to that
<dash>
oh well. back to monadic interpreters in scheme :)
dash has left #ocaml []
Yurik_ has quit ["Client exiting"]
gene9 has quit []
gene9 has joined #ocaml
gene9 has quit []
Kinners has left #ocaml []
systems has joined #ocaml
pattern_ has quit [Read error: 60 (Operation timed out)]
mellum has quit [Read error: 60 (Operation timed out)]
pattern_ has joined #ocaml
systems has quit [Read error: 110 (Connection timed out)]
mellum has joined #ocaml
Riastrad1 is now known as Riastradh
mrvn_ is now known as mrvn
<Vincenz>
lo Riastradh
<Riastradh>
Hi.
systems has joined #ocaml
lam has quit ["Changing server"]
lam has joined #ocaml
systems has left #ocaml []
docelic is now known as docelic|away
baader has joined #ocaml
palomer has joined #ocaml
newton has quit ["Client Exiting"]
xtrm has quit ["et hop"]
karryall has quit ["bye"]
lament has joined #ocaml
mattam_ has joined #ocaml
mattam has quit [Read error: 110 (Connection timed out)]
lament is now known as lameAFK
baader has quit ["I'll be back"]
systems has joined #ocaml
<palomer>
whats wrong with this statement?
<palomer>
let find_first_in v k =
<palomer>
let l = Array.length in
<palomer>
let rec helper i = function l -> -1 | n when v.(n) = k -> n | _ -> (helper (i + 1)) in
<palomer>
helper 0;;
<palomer>
ahh woops
<palomer>
hrm
systems has quit [Read error: 110 (Connection timed out)]
<palomer>
how do I backtrace in the ocaml intrepreter?
lameAFK has quit [Remote closed the connection]
<palomer>
can you match against values or only patterns?
<mrvn>
depends
<mrvn>
let rec fac = function 0 -> 1 | n -> n*(fac(n-1))
<mrvn>
thats works since 0 and 1 are literals
<palomer>
can you match against variables with the function construct?
<palomer>
like let b = 4 in let a x = function b-> 6 | _ -> 234;;
<palomer>
where I want to match x against b
<mrvn>
let foo = 7 let bla = function foo -> 1 | _ -> 0, _ will be unsued
<mrvn>
# let foo = 7 let bla = function x when x = foo -> 1 | _ -> 0;;
<palomer>
might as well just use match with in this case
<mrvn>
match and function use the same matching.
<palomer>
but I can do let foo = 7 let blah x = match x with foo when x > 8
<palomer>
whereas
<palomer>
I can't do that with function
<mrvn>
# let bla = function foo when foo > 8 -> 0 | _ -> 1;;
<mrvn>
val bla : int -> int = <fun>
<mrvn>
# bla 1;;
<mrvn>
- : int = 1
<mrvn>
# bla 9;;
<mrvn>
- : int = 0
<mrvn>
#
<mrvn>
works just as well.
<palomer>
I want to match the argument and then test the argument
<palomer>
ok heres an example
<mrvn>
match and function use the same matching. They are equivalent.
<palomer>
type u = BAR of int;; let foo = 5 in let a i = match i with BAR n when n> foo ->...
<palomer>
try doing that
<palomer>
oh, and any idea why this won't work:
<palomer>
let normalize_start_system s =
<palomer>
let l = Array.length s.m in
<palomer>
let rec helper i = match i with l -> () | n -> ignore (normalize_row_start_system s n);ignore (helper i+1) in
<palomer>
helper 0;;
<mrvn>
l -> () matches everything.
<mrvn>
You get a warning that the n case is never used.
<palomer>
I get an error
<mrvn>
match i with x when x = l -> () ...
<palomer>
why should l-> () match everything? l is bound!
<palomer>
im matching against a value
<mrvn>
palomer: no, match binds l (over your other l)
<palomer>
ahh, gotcha
<palomer>
so function and match really are equivalent
<mrvn>
You can't match against values, only literals.
<mrvn>
And use if for that, not match
<mrvn>
match is for structural matching like [] versus x::xs or None versus Some x