<rwmjones>
flux, the app I wrote was closed source
<rwmjones>
but the link above distills the main lessons learned
<flux>
rwmjones, well, did it work, was it usable?-)
<rwmjones>
and yes, basically it worked fine
<rwmjones>
it was quite a highly graphical/interactive thing
<flux>
rwmjones, would you choose the same tool were you tasked to do a desktop app for windows again?
<rwmjones>
lots of 2D graphs of a simulation running in realtime
<rwmjones>
flux, yes
<wy>
Thanks. I must run to my final exam. See you later! :-)
wy has quit ["Leaving"]
<rwmjones>
at the moment I'm porting a python program to Windows & it's a fscking nightmare
<rwmjones>
ocaml was actually a lot simple
<rwmjones>
simpler
<flux>
funny
<flux>
what are python's greatest problems?
<flux>
I haven't personally written any python code so I don't know if it has some other problems..
<rwmjones>
well the particular problem is that the program I'm porting depends on lots of C libraries, and they only compile with Cygwin, and you can mix Cygwin Python plugins with Win32 python plugins
<rwmjones>
python itself is a horrible language, the VB6 of the Unix world
<rwmjones>
endless problems caused by the 'meaningful-indenting' (eg. applying patches causes the indenting to get lost, changing the meaning of the code)
<flux>
those are the harhest words I've heard about python yet :)
<rwmjones>
and lots and lots of runtime bugs which could have easily been found by static analysis in the compiler
<flux>
I hear that was the reason why sun picked tcl for purpose X, instead of python.
<flux>
actually some java-version of tcl instead of jpython
<flux>
well yes, there's always the dynamic typing versus static typing-issue
qpu_ has joined #ocaml
<rwmjones>
every single code bug (rather than missing feature bug) I've seen reported against virt-manager would have been prevented with static analysis
<flux>
have you let this information pass forward, what have been the responses?-)
<flux>
rwmjones, that xphelloworld-thingy might actually be useful for me some day, thanks
<rwmjones>
flux, not positive .. they associate static analysis with monsters like java. Almost no one understands type inference.
<RobertFischer>
I was just on a panel where I tried to explain that to people.
<RobertFischer>
A bunch of Ruby-ists talking about how awesome Ruby was, and everything they liked about that type system (with the exception of Mix-Ins) is on Ocaml.
<RobertFischer>
Plus you get C++-level performance and code checking.
qpu_ is now known as qpu
Yoric[DT] has joined #ocaml
<Yoric[DT]>
hi
Snark has joined #ocaml
ttamttam has left #ocaml []
pango has quit [Remote closed the connection]
pango has joined #ocaml
Submarine has quit ["Leaving."]
ttamttam has joined #ocaml
olleolleolle has joined #ocaml
ertai has quit [Read error: 110 (Connection timed out)]
filp has quit ["Bye"]
ertai_ has joined #ocaml
qpu has quit []
olleolleolle has left #ocaml []
qpu has joined #ocaml
buluca has quit [Read error: 110 (Connection timed out)]
bluestorm has quit [Remote closed the connection]
<Yoric[DT]>
mmmhhh....
<Yoric[DT]>
I'm looking for syntax ideas.
<Yoric[DT]>
I've realized that my current syntax is ambiguous.
<Yoric[DT]>
That is, if I allow writing "[i | (List) i <- [1;2;3;4;5]]"
<Yoric[DT]>
it's bound to make things such as
<Yoric[DT]>
"[i | (i) <- [1;2;3;4;5]]"
<Yoric[DT]>
ambiguous
<Yoric[DT]>
So either I make the module name compulsory or I need to find something to differentiate between the module name and possible patterns.
smimou has joined #ocaml
Tetsuo has joined #ocaml
bongy has joined #ocaml
ttamtta1 has joined #ocaml
filp has joined #ocaml
ttamttam has quit [Read error: 110 (Connection timed out)]
<flux>
it's not ambigious, the first one has a constructor in parenthesis while the second one doesn't?
<flux>
but what is it supposed to do? contruct a list, or perhaps a stream instead?
<Yoric[DT]>
Actually, in that case, it builds a stream and, with my current syntax, the (List) is optional.
<Yoric[DT]>
However,
<Yoric[DT]>
[i | (MoreArray) i <- [|1;2;3;4;5|] ]
<Yoric[DT]>
is necessary for cross-comprehension
<Yoric[DT]>
i.e. building a list from an array.
<Yoric[DT]>
Now, on the left of <-, what I have is any pattern.
<Yoric[DT]>
So a no-argument-constructor would be alright.
<Yoric[DT]>
Which means that I can't necessary differentiate just by looking at what comes directly after |.
<Yoric[DT]>
I have to be willing to parse it twice, either as a pattern or as a module name.
<Yoric[DT]>
Camlp4 doesn't like this kind of things too much.
<flux>
:)
Snark has quit ["Quitte"]
ertai_ has quit ["leaving"]
ertai has joined #ocaml
olleolleolle has joined #ocaml
olleolleolle has left #ocaml []
dbueno has joined #ocaml
dbueno has left #ocaml []
bongy has quit [Connection timed out]
asmanur_ has quit [Remote closed the connection]
rwmjones has quit ["Closed connection"]
ttamtta1 has left #ocaml []
ttamttam has joined #ocaml
ttamttam has left #ocaml []
ygrek_ has quit [Remote closed the connection]
<Yoric[DT]>
Ok, fixed.
<Yoric[DT]>
Now, I'm looking for an idea for a nice syntax for folds.
<Yoric[DT]>
Currently, my for-each applies to map and iter.
<Yoric[DT]>
for each i in Array [|'a';'b';'c';'d'|] do
<Yoric[DT]>
print_char i
<Yoric[DT]>
done;
<Yoric[DT]>
for each i c in Array.iteri [|'a';'b';'c';'d'|] do
<Yoric[DT]>
print_int_char (i,c)
<Yoric[DT]>
done;
<Yoric[DT]>
for each i in Array.map [|1;2;3;4;5|] do
<Yoric[DT]>
i + 1
<Yoric[DT]>
done;
<Yoric[DT]>
etc.
<Yoric[DT]>
There must be an elegant way to make that syntax work also for folds.
<qwr>
for each i, j in ... ?
<Yoric[DT]>
What do you mean ?
<qwr>
that fold wants two arguments... or for each a b in
<Yoric[DT]>
that already works (cf. iteri)
<Yoric[DT]>
My main problem is that folds take one additional argument: the initial value.
<Yoric[DT]>
I can't see any nice place to put it.
<mbishop>
Yoric[DT]: where is your camlp4 code anyway?
<Yoric[DT]>
Not published yet.
<qwr>
Array.fold v [|1;2;3|] ?
<Yoric[DT]>
I'll try and finish it / clean it up / figure out licensing issues by the end of the week.
<Yoric[DT]>
qwr: if I do that, I have a syntactic ambiguity
<Yoric[DT]>
That is, if I understand correctly that you imply "for each acc x in Array.fold v [|1;2;3|] do ... "
<qwr>
yes.
<Yoric[DT]>
Mhhh...
<Yoric[DT]>
Actually, if I assume it's left-associative, that should be ok.