<taw>
but if you want to speak polish i can live with it
<taw>
;)
<MadRat->
Oh good (:
<MadRat->
I don't suppose there are very many Micro$oft Windows programmers who use OCAML
gehel has quit [Read error: 110 (Connection timed out)]
<lament>
alas
<lament>
although, there's F#.NET
<taw>
hehe
<taw>
Mi what ?
<MadRat->
To be honest I don't even know what .NET is
<taw>
i think i heard that name ...
<whee>
if you don't know what .NET is, you don't need to :)
<taw>
i have to learn .NET for this silly course
<taw>
on my uni
<taw>
not sure why they put it there
<taw>
it would be nice with java alone ;)
<taw>
aa, i know
<taw>
they put it so people know that java isn't that bad
<MadRat->
Is OCAML a hard language for beginners to learn?
<whee>
I hate java :|
<whee>
MadRat: not really
<whee>
it helps to have some experience, but it's not that hard in any case
<taw>
it is hard ;)
<MadRat->
I haven't written a program in the last 10 years
<taw>
i wouldn't recomment starting with it
<taw>
it's rather for experienced programmers
<whee>
I would
<taw>
whee: i thought that about java too
<taw>
whee: but as the course includes DCOM and .NET
<whee>
it's better to get in the habit of doing things right, and not introducing bad design choices while learning
<taw>
whee: i started to think that java is quite sane
<whee>
I don't think OO should be introduced early
<whee>
it's a design thing, not programming in general
<MadRat->
I've tried to understand OO but it seems to be beyond me
<whee>
you can do anything with ocaml and not even touch the OO support
<taw>
nowadays oo is everywhere
<whee>
it's nice to have, though. some problems do work well with OO
<whee>
but a lot don't.
<MadRat->
I saw some benchmarks using 44 different languages and OCAML always came out in the top 5
<MadRat->
The only thing that really beat it was Visual C++
<whee>
ocaml is one of the faster high-level languages
<MadRat->
(this is all under Windows, sorry)
* whee
considers C/C++ low-level heh
<MadRat->
It also seems to use memory effeciently
<MadRat->
a lot of people do whee
<whee>
maybe, but they're used for the wrong things
<whee>
I see a lot (read: all) of applications using C or C++ when they do nothing that requires the low-level nature
<whee>
just look at freshmeat sometime :)
<Kinners>
would ocaml be ok for experimenting with compression algorithms, I would guess the only drawback would be having to use bigarray (for processing 16 bit data) ?
<taw>
mmm
<taw>
compression ?
<taw>
i wouldn't really use ocaml for binary stuff
<whee>
it's possible, but likely not in a functional style
<taw>
or for memory-heavy stuff
<taw>
that's where c++ clearly wins
<lament>
or even C
<whee>
yes
<taw>
many important compression algorithms are not functional at all
<taw>
they do lot of variable modifications etc.
<taw>
now, why people don't do cgi in ocaml ?
<MadRat->
Could you explain imperative vs functional? I don't really understand it.
<lament>
the better question would be, why do people do cgi?
<taw>
generally, server-side web programming
<whee>
taw: same reason they're using perl and friends. most people don't know any better :)
<taw>
doesn't matter if by cgi or some other mechanism
<taw>
perl is much better than c
<taw>
they aren't that dumb after all if they use perl
<MadRat->
Isn't it better to use python than perl?
<whee>
perl doesn't really encourage structured program design
<taw>
as if that was big difference
<lament>
taw: no, the point is, CGI is bad :)
<whee>
it's hard to maintain at a point
<taw>
lament: you mean CGI mechanism, or server-side www ?
<taw>
perl/python/php aren't really much different
<lament>
taw: uh, yes, they are
<whee>
not really
<whee>
well, php maybe
<whee>
but python/perl/ruby are largely similar, with the main difference being syntax and library support
<whee>
ignoring the OO nature of ruby and python
<taw>
i have seen big fragments of code that worked exactly the same way in php and perl
<taw>
and compiled in both to begin with
<lament>
taw: CGI is bad because it doesn't separate logic and representation
<taw>
lament: you can use CSS and stuff
<lament>
that's not what I mean :)
<taw>
and you can design scripts to separate them
lament is now known as lameAFK
<whee>
heh, I can't find a nice definition of functional programming
<MadRat->
Thank you for trying whee.
<taw>
foldoc:
<taw>
functional programming
<taw>
<programming> (FP) A program in a functional language consists
<taw>
of a set of (possibly {recursive}) {function} definitions and
<taw>
an expression whose value is output as the program's result.
<taw>
Functional languages are one kind of {declarative language}.
<whee>
they're similar in that I see them used for mostly the same purposes
<lament>
taw: different from what?
<taw>
diff(ruby,perl) > diff(python,perl)
<lament>
ah.
<taw>
i know both ruby and perl well
<lament>
I think you're wrong :)
<taw>
and i think they are still similar in general design
<lament>
Both Ruby and Perl have closures, while Python doesn't
<taw>
python doesn't have closures ?
<lament>
in Python everything is an object, while in both Ruby and Perl, it's not
<taw>
i know both ruby and perl well but i'm no python expert ...
<whee>
you're wrong already lament
<taw>
realy ?
<MadRat->
hmmm...how does this sound?
<MadRat->
In functional languages, functions are treated as mathematical objects. If you define a function exactly the same as its definition in mathematic, the languages can guarantee that you will get nothing but the exact function you defined - nothing more or less.
<whee>
everything is an object in ruby, no exceptions
<taw>
in Ruby everything with exception of maybe methods is object
<lament>
whee: no, you're wrong :)
<lament>
whee: and taw is right
<lament>
Ruby methods aren't even first-class
<whee>
pfft :P
<taw>
but that's pretty minor thing
<taw>
you can put them into closures :)
<lament>
taw: it's the language philosophy.
<taw>
and closures are objects
<lament>
taw: no, they're not
<whee>
are if statements objects in python?
<whee>
heh
<taw>
hmm
<lament>
the { ... } things are not objects
<lament>
Blocks are objects
<taw>
there was some talk about making methods objects too on ruby list
<lament>
taw: that would be very good
<taw>
so this isn't that much language design difference
<taw>
lament: what would it help ?
<lament>
taw: would make the language more consistent, for one. Would get rid of the stupid & prefix
<taw>
hehe
<taw>
"more consistent" isn't any goal
<taw>
in what real things would it help ?
<lament>
taw: It is a goal of Python
<lament>
taw: which is one of the differences between it and Ruby/Perl :)
<taw>
python has its own inconsistencies
<taw>
like smallint/bigint
<taw>
tuple/array
<taw>
none of them in ruby
<lament>
um, those aren't inconsistencies
<taw>
but what could you do that you can't do now if methods were objects ?
<taw>
or what would be much easier ?
<emu>
who needs programming languages? just use turing machines/lambda calc
<whee>
down with computing!
<whee>
heh
<lament>
taw: It hardly matters
<taw>
emu: functional part of ocaml is very much typed lambda calc
<emu>
indeed
<lament>
taw: I'm not talking about usefulness
<lament>
taw: I'm only saying that Python is not Ruby :)
<taw>
lament: of course it matters
<emu>
from my limited experience with Python, I would say that it is not a functional lang
<taw>
well, and for more differences
<taw>
Ruby is functional
<taw>
Python is not
<emu>
there is a distinct imperative flavour to it
<taw>
Perl is not
<taw>
so diff(ruby,perl) > diff(python,perl)
<lament>
taw: um, you're mad
<emu>
whereas Ruby seems to support fp more (as Smalltalk does)
<lament>
taw: Ruby is not functional
<lament>
and neither is smalltalk
<lament>
both are very much non-functional
<taw>
i had really cool example to prove you wrong ...
<emu>
what do you think ``blocks'' are?
<taw>
block is a closure
<lament>
emu: closures. So?
<emu>
tada
<lament>
emu: and?
<taw>
small function that takes any iterator
<taw>
and turns it into folding function
<taw>
you can't do something on such high level in ocaml even
<emu>
[|a b| a + b]
<emu>
(fn (a,b) => a + b)
<lament>
taw: anyway, how can a language without first-class functions be considered functional? I'm at loss.
<lament>
taw: In smalltalk, blocks ARE first-class objects
<taw>
lament: closures are first class objects
<taw>
that is blocks
<lament>
taw: no, they are not
<lament>
you have to convert them to objects
<taw>
block is passed as last argument to iterating function
<lament>
taw: yes. They're treated in a special way
<taw>
iterator calls method on it
<emu>
look, this usage of blocks as a special case for iterators is just dumb
<lament>
taw: because, again, they're not first-class objects :)
<taw>
the rest is syntactic sugar
<emu>
I haven't followed that that much
<emu>
but in Smalltalk, blocks are first-class functions/closures
<taw>
ruby is full of syntactic sugar
<lament>
taw: what if a function wants to access two blocks?
<lament>
taw: instead of just one?
<taw>
you have to use uglier way then
<emu>
I do recall ways of creating function objects in ruby
<lament>
taw: exactly
<emu>
lament: so?
<lament>
taw: because ruby blocks aren't first-class
<lament>
on the whole, i would not call ruby functional, though :)
<emu>
we're only saying that it has functional elements
<lament>
oh, sure. So do Python and Perl. And almost all other languages.
<taw>
it has more functional elements that some "functional" languages
<emu>
what a `functional programming language' is it not up for debate, and it's vague anyway
<lament>
didn't C win in ICFP one year?
<taw>
if something has closures and high level functions - it's functional
<emu>
ICFP lets all in
<emu>
but even C is considered `functional'
<emu>
by some
<taw>
as far as i'm concerned
<taw>
emu: by who ;) ?
<lament>
if C is functional, then Ruby, Perl and Python certainly are :)
<emu>
i'm not sure. i've just heard someone say it.
<emu>
presumably because it has functions =)
<taw>
emu: how much did he drank before ;)
<emu>
call-by-value and `referential transparency' (but in a stupid way)
<emu>
and perhaps also because it allows recursion
<lament>
taw: After all, closures are just a syntax issue
<emu>
recall in 1972 that recursion was a new-fangled thing
<emu>
lament: huh?
<taw>
lament: huh ?
<lament>
taw: you can emulate them with functions :)
<emu>
lament: try and depend on closures in C, and it gets painful fast!
<taw>
closures and high order functions are exactly the features that are not just syntactical
<emu>
you need to write your own trampoline for funcptrs and establish the bindings
<emu>
on the stack, or through some explicit mechanism
<lament>
taw: um, you just said that high-order functions are a syntax issue
<taw>
now, i'll have to chose language of the year 2003 to learn ;)
<lament>
taw: you're contradicting yourself...
<taw>
lament: where ?
<lament>
<taw> what's wrong with having to write lambda here and there ?
<lament>
<taw> it's design of parser if any design at all
<emu>
lament: no he said that a few syntax issues does not unmake a functional language
<taw>
lament: having to put lambda before block ?
<lament>
taw: a syntax issue, that
<taw>
in 2001 it was ruby, in 2002 ocaml
<emu>
lament: and has nothing to do with actually having closurse
<taw>
what language should i learn in 2003 ... ;)
<emu>
what was it prior to ruby?
<taw>
perl, but i didn't have such shedule then
<emu>
I recommend Common Lisp, Smalltalk, and Haskell
<taw>
i'm thinking about haskell mostly
<taw>
common lisp also makes some sense
<taw>
but why smalltalk ?
<emu>
Squeak is fun
<lament>
it's pretty :)
<lament>
and it seems logical, after knowing ruby, to learn the language it tries to emulate :)
<emu>
give you a glimpse of how computing should look
<emu>
if not ideal
<taw>
what does it have that ruby doesn't ?
<emu>
(ie, why are we still hacking with such non-interative environments)
<taw>
and are there any opes source programs in smalltalk i could learn from ?
<lament>
taw: clarity.
<emu>
taw: squeak
<emu>
non-interactive
<emu>
i meant to ay
<emu>
I don't understand why Ruby doesn't even have a repl
<lament>
repl?
<emu>
really, a dynamic language without decent interactivity/runtime support is kinda silly
<emu>
which is why perl, python, and ruby puzzle me a bit
<emu>
lament: read-eval-print-loop
<taw>
what is squeak ?
<lament>
emu: uhh, ruby and python do
<taw>
irb may not be perfect but ... ?
<emu>
yeah, but it's still far inferior to CL or Smalltalk
<lament>
emu: In Python, that's how the interpreter works
<lament>
How's it inferiour to CL?
<taw>
oh
<taw>
but the question was
<emu>
the error handling system is pathetic
<lament>
and in any case, "inferior" is not the same as "not having any"
<taw>
what real programs are written in smalltalk ?
<emu>
taw: squeak.org !
<emu>
who cares what real applications are written in it
<emu>
you should see it anyway, it's a whole environment in itself
<taw>
hmmm
<taw>
i use emacs
<emu>
note that I'm not a big Smalltalker, I just like Squeak
<taw>
i know whole-environment thing already ;)
<lament>
taw: emacs is nothing compared to squeak
<emu>
now think ``nice programmable graphical system''
<lament>
taw: emacs is ugly, with lots of horizontal complexity
<lament>
squeak is structured
<lament>
(by 'ugly' i mean 'overcomplicated')
<emu>
oh and those 3 languages don't even have compilers
<emu>
(not that squeak itself does, though smalltalk does. but squeak is still interesting)
<taw>
CL has compilers iirc
<emu>
yes, CL has compilers. I meant ruby, python, perl
<lament>
emu: so?
<taw>
aah yes
<emu>
ruby still uses a mark-sweep GC
<taw>
what's wrong with that ?
<taw>
what else would you like to use ?
<emu>
heh heh
<lament>
having a compiler is hardly a major feat
<taw>
certainly not reference counting
<taw>
ruby has nice c interface
<taw>
if program is too slow
<emu>
mark-sweep is the lowest kind of GC
<emu>
ref counting isn't GC
<taw>
you can write offending 1% of code in c
<emu>
taw: I don't want to program in C!
<taw>
you can't get faster than that
<taw>
in fact i got ruby+c program more efficient than comparable all-c program that way
<emu>
C isn't very efficient anyway
<lament>
together with GCC, it often is
<emu>
if ocamlc.opt isn't faster already, I fully expect it will be in the future
<lament>
s/gcc/sane compiler
<emu>
GCC is crappy
<emu>
on x86
<lament>
use that magic intel compiler, then.
<emu>
the reason is simple: more information means better optimization
<emu>
high-level languages give more information about the program, therefore better optimize
<lament>
emu: also a PITA :)
<emu>
you need a ``sufficiently smart compiler'' however :)
<lament>
high-level languages don't, as a rule, give more information about the program
<lament>
they usually give less :)
<emu>
are you kidding?
<emu>
rather than fiddling with pointers, you can tell it what data structure you really want to use
<lament>
depends on what you consider a high-level language
<lament>
emu: only if you have static typing :)
<emu>
C is weakly typed too
<lament>
I'd say that Perl, Ruby, Python, Smalltalk are all high-level languages
<lament>
neither is statically typed
<lament>
all of them are usually less explicit than C
<emu>
CL isn't statically typed either, but you can add annotations and there are compilers that do type-inference too
<lament>
yes, but in Perl, Ruby, Python and Smalltalk you can't, and they're still high-level
<lament>
Unless you consider CL "more" high-level
<taw>
mmm
<taw>
ocaml may use less cpu
<taw>
but the way it uses memory
<taw>
and also in case of other high level languages
<emu>
lament: different goals
<taw>
is often horrible
<lament>
emu: certainly.
<lament>
taw: that's a design issue
<lament>
taw: there exists the developent resources/execution resources tradeoff
<taw>
not really
<lament>
?
<lament>
it doesn't?
<taw>
it doesn't
<taw>
some languages use more machine resources and more human resources
<lament>
well, sure
<lament>
like Brainfuck
<taw>
like pascal ;)
<lament>
but there's the minimal room
<emu>
java
<emu>
I think, is the stereotypical example
<lament>
i.e. below some development resources threshold, the language cannot be fast
<taw>
are you sure ?
<lament>
below some execution resources threshold, the language can't be easy
<lament>
Yes, i'm sure
<taw>
where do you see this threshold ?
<lament>
With languages like Python and Smalltalk.
<lament>
I.e. languages with reflexivity, dynamic typing, late binding, object systems
<emu>
hah. I have a language with two symbols: {0, 1}. 0 means output a high-performance 3d game. 1 means output a word-processor. fast, easy, and high-level!
<taw>
if language is well-suited for usual stuff
<taw>
it can be both easy and fast
<emu>
there is definitely a trade-off between features and ease of compiler-creation
<lament>
usual stuff?
<lament>
taw: can you give an example of such a language?
<taw>
php
<taw>
it is optimized for one kind of work
* lament
screams
<emu>
yeah, creating simple home pages
<taw>
and that makes it both easy and reasonably-well-performing in that case
<emu>
anything beyond that and ... poop
<lament>
As far as I know, php is not fast
<taw>
oh it is
<emu>
for its kind, i hear it is
<taw>
naive c++ is slower than that
<lament>
taw: for what?
<taw>
it does database connection caching, and thing like that
<taw>
for free
<emu>
well, a cgi program will be slower than modphp anyway
<taw>
it does lot of magic for you
<taw>
modphp i mean
<taw>
naive c++ prog would connect to db on every run
<taw>
that would be slow as hell
<taw>
oh, not to mention fork/exec
<lament>
anyway, php is below my ease-of-use threshold
<lament>
i don't know much about php, but i don't think it satisfies my "reflexivity, dynamic typing, late binding, object systems" criterion
<emu>
taw: um, you're comparing apples and oranges
<taw>
you mean is it too hard or too easy ?
<lament>
too hard
<emu>
php is not very powerful language anyway
<lament>
oh, i should add strong typing to my criteria
<taw>
lament: it's very easy for web pages that aren't too complex
<emu>
ooh, strong typing and reflexivity
<emu>
you don't mean static, right?
<taw>
dynamic/static typing
<taw>
etc.
<lament>
emu: strong, dynamic
<taw>
are features of language
<emu>
oh ok
<taw>
ease of use doesn't depend on them
<emu>
i'm way too accustomed to ML people calling strong static
<emu>
er, static strong
<lament>
I think static typing is evil, but annotations are good
<emu>
how about implicit static?
<lament>
implicit static?
<taw>
implicit static like ocaml ?
<taw>
infered you mean ?
<emu>
yep
<lament>
that's still static :)
<emu>
okay =)
<emu>
I was curious whether you were bothered just by syntax
<lament>
Don't get me wrong, I love the HM type system :)
<emu>
explicit is just annoying
<lament>
you mean annotations?
<lament>
or really static static typing like in C?
<emu>
required ones
<emu>
explicit static typing means that you have to put the types everywhere you use them
<lament>
well, yeah.
<taw>
ocaml is very much like that ;)
<emu>
syntactically
<emu>
no
<lament>
taw: no
<taw>
you have to put them almost everywhere
<taw>
costructors of type foo have to be FOO_*
<emu>
ml has a implicit static type system
<taw>
fields of record bar have to be bar_*
<emu>
but of course, it's still static and it shos =)
<taw>
or they will clash
<emu>
also I think that the general case of type inference is undecidable
<emu>
particularly with modules
<taw>
hehe
<taw>
ocaml screws it in a few points already
<emu>
it's still a heck of a lot nicer than C
<emu>
or Java
<lament>
Haskell is supposed to be good at that, although I don't know the differences from ocaml
<lament>
(that == type inference)
<whee>
mmmm haskell
<lament>
but then, haskell doesn't have objects
<emu>
Haskell is subject to the same limitations
<emu>
but it does have a more expressive typesystem afaik
<emu>
huh?
<lament>
objects as in class instances
<emu>
they do better, with type classes
<lament>
That's not quite the same. In any case, OO doesn't make much sense in a purely functional language
<lament>
Certainly possible, but appaling
<taw>
there are many mixed funcional/oo
<emu>
blah, lets not get into OO
<taw>
like ocaml and ruby
<emu>
and CL
<taw>
but none of them is fully functional
<taw>
and cl right
<emu>
because no one seems to be able to define it well
<whee>
OO is pretty much useless in a purely functional language like haskell
<taw>
the point of objects is that they are modificable