<CosmicRay>
the ocamldbi project uses objects for its dbi interface
<CosmicRay>
missinglib probably uses them elsewhere as well
<CosmicRay>
you might google for ocaml objects
<jourdechance>
thank you a lot !
<CosmicRay>
or ask on ocaml-beginners
<CosmicRay>
glad to help
Nutssh has left #ocaml []
smkl has joined #ocaml
jdrake has joined #ocaml
jason__ has quit ["Client exiting"]
TheDracle has joined #ocaml
CosmicRay has quit ["Client exiting"]
<Submarine>
yow
<Submarine>
I didn't know OCaml was so successful.
<TheDracle>
It is?
<Submarine>
well, there are people in the channel
<TheDracle>
Nah, we just made an ocaml bot that generates random names and joins the channel.
<Submarine>
in 1995, one would have said that Caml was a funny French academic language
<TheDracle>
There's nothing funny about Ocaml.
<Submarine>
actually there is
<TheDracle>
No. Ocaml is a very very serious subject.
<Submarine>
well, there's for instance the single-threaded gc whereas damien doligez did his phd on parallel gcs
<TheDracle>
The irony...
<Submarine>
do they teach OCaml at U-Utah?
<TheDracle>
It's a little known fact, he was actually an undergraduate in ballet.
<Submarine>
sorry?
<TheDracle>
I'm not in the CS program here, I wouldn't know.
<TheDracle>
I doubt it.
<Submarine>
what did ballet?
<Submarine>
who did ballet, sorry?
<TheDracle>
Damien.
<TheDracle>
It gets even more ironic..
* Submarine
waits.
<TheDracle>
Hm.
<TheDracle>
What are you waiting for?
<TheDracle>
I'm not clever enough to come up with another fabrication.
<TheDracle>
<insert something clever here>
pattern has quit [Read error: 110 (Connection timed out)]
* Submarine
actually knows Xavier and Damien personally
<TheDracle>
Really?
<TheDracle>
Was he in ballet?
<Submarine>
Sure.
<TheDracle>
I knew it!
<Submarine>
Well, actually, he was in maths/cs at ENS.
<TheDracle>
So, you must be uh, French then?
<Submarine>
Good guess.
<TheDracle>
Know what's Ironic? The United States millitary actively uses Ocaml in its guided missles.
<Submarine>
I doubt it.
<Submarine>
I know there are guys using OCaml at Raytheon.
<TheDracle>
Heh.
<TheDracle>
Really?
<TheDracle>
What for?
<Submarine>
I strongly doubt anything goes inside missiles.
<TheDracle>
Why?
<TheDracle>
Put a microprocessor into it.
<TheDracle>
They're cheap.
<TheDracle>
These GPS guided things definitely have some kind of computer control.
<Submarine>
Because you don't run mission-critical real time stuff on garbage collected languages.
<TheDracle>
Probably in Ada though.
<Riastradh>
Submarine, garbage collection can still be real-time.
<TheDracle>
Right.
<Submarine>
Riastradh, that's besides the point really. :-)
<Riastradh>
And anyway, missile programs probably don't generate enough garbage to matter.
<TheDracle>
Removing dynamicaly allocated memory on your own can cause the same time inconsistencies.
<TheDracle>
Especially since malloc and new have to search the heap for free space, etc.
monochrom has joined #ocaml
<TheDracle>
Allocation time for conveyor belt garbage collectors is actually pretty good.
<Submarine>
As a matter of fact, EADS space units tend to use ADA, the US military officially used ADA.
<TheDracle>
And fairly consistent.
<TheDracle>
And there are GCs made to be specific for such applications.
<TheDracle>
Right.
<Smerdyakov>
Submarine, you can run mission critical real time stuff with GC today.
<TheDracle>
ADA is heavily used.
<Submarine>
Anything aerospace civilian would have to comply with DO-178B, and something has complex as a GC would not pass for safety critical things.
<TheDracle>
But then again, the Mars rover uses Java.
<Smerdyakov>
Submarine, the bound on GC time is not infinitely low yet, but it will keep getting lower over time.
<Submarine>
Smerdyakov, the problem is not only that you "can". You must also convince the people authorizing the program to do it. Missiles and civilian planes can kill your own people if they screw up.
<TheDracle>
I think memory leaks will kill the system, GCs will simply possibly slow them down at an inoportune moment.
<Submarine>
Smerdyakov, let's put it this way: I've worked on code flying airplanes.
<Submarine>
TheDracle, the Mars rover cannot kill anybody.
<Smerdyakov>
Proving the safety of software systems is so much easier with functional languages than Ada and relatives.
<TheDracle>
Or can't it?
<Smerdyakov>
So it makes a lot more sense to use ML than Ada, for instance, if you care about guaranteeing safety.
<TheDracle>
Obviously you missed the missle launcher arm installed on it for blasting martians.
<Submarine>
TheDracle, and as a matter of fact, their Java code is so buggy, esp. wrt multithreading, that they have research teams working on debugging methods.
<TheDracle>
.. It seems to be working quite well actually.
<TheDracle>
I think they work on debugging methods for most anything.
<TheDracle>
I mean, what did this European thingamajig used?
<TheDracle>
It was buggy enough it burnt to cinders in the upper atmosphere.
Submarine has quit [Read error: 104 (Connection reset by peer)]
<palomer>
ADA is heavily ridiculed
<monochrom>
I think Ada is just fine, even when correctness is concerned.
<monochrom>
You can't do C tricks in Ada, you know.
<Smerdyakov>
monochrom, it's imperative. That makes verification much harder.
<TheDracle>
We're not talking purity here Smerdy, there are better alternatives, but it does its particular job well.
<monochrom>
I believe none of that. Dijkstra showed us how to verify imperative programs with simplicity 30 years ago.
<Smerdyakov>
TheDracle, I'm talking about tractability of verification.
<Smerdyakov>
monochrom, the hell he did.
<monochrom>
And during those 30 years we have further simplified it.
<Smerdyakov>
monochrom, he didn't show anything serious. Others have had to adapt his results for a toy language.
<TheDracle>
ML started out as a 'toy language' mostly, didn't it?
<TheDracle>
Unfortunately, good ideas don't seem to catch on in the realms of CS.
<Smerdyakov>
TheDracle, no. ML was used with sophisticated theorem provers from the start.
<TheDracle>
At least, not quickly.
<Riastradh>
No, it started out as a serious language for theorem provers.
<TheDracle>
Well, it didn't start out as a programmer's language.
<TheDracle>
Ocaml is a programmer's language.
<Smerdyakov>
monochrom, you are telling me that you think that you lose nothing by having to reason about how functions depend on and modify global state?
<Smerdyakov>
Programmers and mathematicians are similar enough that what you're saying is silly.
<Smerdyakov>
(that was to TheDracle)
<TheDracle>
Tell that to a mathematics major :) He'll laugh at you I assure you.
<Smerdyakov>
TheDracle, well, amend that to "programmers who use ML," which tends to be a subset of "computer scientists.":
<Riastradh>
There's a difference between programmers under the category of 'computer scientists' and programmers under the category of 'engineers.'
<monochrom>
No. I am telling you to read the latest advance before saying layman terms such as "toy".
<palomer>
hasn't haskell superseded sml in the theorem proving arena?
<TheDracle>
But, according to Smerdy, there's no difference between programmers and mathematicians.
<Smerdyakov>
I don't think so.
<TheDracle>
Give me a break.
<Smerdyakov>
Coq (based on OCaml) and Twelf (based on SML) are pretty popular.
<Riastradh>
TheDracle, he amended his statement, if you hadn't noticed.
<palomer>
what's THE theorem proving language?
<Smerdyakov>
TheDracle, changing it to "good programmers" also gives you a true statement.
<Riastradh>
Uh.
<Riastradh>
That's like asking 'what's THE GUI application language?'
<TheDracle>
Tk :p Hehe.
<Riastradh>
Or 'what's THE compiler language?'
<palomer>
ok, what are the top 3
<Riastradh>
...
<smimou>
coq and isabel are among the most used
<Riastradh>
palomer, whatever languages you are most comfortable with.
<Smerdyakov>
Riastradh, WHAT?!
<Smerdyakov>
Riastradh, you sound like a #C'er now.
<TheDracle>
Heh.
<TheDracle>
Smerdy is an ML' or nothin' kindof guy.
<Riastradh>
Smerdyakov, no, they'd suggest C or C++ or something.
<Smerdyakov>
Riastradh, no. People in #C are of the "all the languages are just as good" opinion, in general.
<TheDracle>
Depends what you think they're good at.
<Riastradh>
Smerdyakov, for such an extremely general question as palomer's, a vague and general answer is deserved.
<TheDracle>
Ria, just say "SML," whether you believe it or not and Smerdy will be happy.
<TheDracle>
Have faith in SML.
<Smerdyakov>
TheDracle seems to be a member of this camp, which doesn't allow anyone to assert that some languages are better than others for most things.
<TheDracle>
I never said that :p
<TheDracle>
I simply said I haven't closed my mind to other programing paradigms yet.
<TheDracle>
Obviously Ocaml is better than C for most programming practices.
<palomer>
why fight? All languages are born equal
<TheDracle>
I can think of some things where I believe it isn't.
<Smerdyakov>
"Closing your mind" to bad ideas is a good idea.
<monochrom>
My language is better than all others for all tasks.
<TheDracle>
Smalltalk and dynamic programming languages are definitely not bad ideas.
<Riastradh>
palomer, unless you ask a more precise question, you're not going to get a useful answer.
<TheDracle>
They're very interesting.
<TheDracle>
As is Ocaml.
<Smerdyakov>
TheDracle, being "interesting" need not lead to good engineering properties.
zigong_ has joined #ocaml
<TheDracle>
Perhaps not, it doesn't mean it leads to neccessarily bad ones either.
<Smerdyakov>
And I believe, in the basis of much investigation, that in the case of Smalltalk & co., it does.
<TheDracle>
Have you tried squeak out?
<Smerdyakov>
No
<TheDracle>
I'm really not convinced of that assertion in the least.
<Smerdyakov>
You can argue that my reasoning is faulty, but it's foolhardy to say that it's never OK to write off all languages in a certain family.
<TheDracle>
Ocaml is certainly not the most syntaticly elegant language I've ever seen, but it is one of the most interesting conceptually.
Xolution has joined #ocaml
<Riastradh>
Smerdyakov, Smalltalk isn't about the language; the language is exceedingly simplistic. It's about the _environment_.
<Smerdyakov>
Riastradh, when I say "language," I mean the holistic development tools and methodology.
<TheDracle>
Right.
<TheDracle>
That's the entire point of it, the syntax is very simple.
<Riastradh>
As far as I know, there is _no_ equivalent of Smalltalk environments in SML.
<TheDracle>
Ocaml has a much simpler syntax that C does.
<TheDracle>
Ahem, than.
<Smerdyakov>
Riastradh, that doesn't make what I say nonsensical.
<TheDracle>
Not as simple as Smalltalk has.
<TheDracle>
It could though.
<Riastradh>
Smerdyakov, how can you debunk an _environment_ that you have never even _used_?
<Smerdyakov>
Simple syntax is not a priori a good thing.
<TheDracle>
I can imagine a more powerful type inferance mechanism providing the same mechanics as smalltalk provides.
<Smerdyakov>
Riastradh, on the basis of information that I have about it.
<Riastradh>
What information do you have about it?
<TheDracle>
Look at Perl, it has an incredibly complicated syntax.
<Smerdyakov>
I have the information that it is dynamically typed and strongly incorporates OO.
Nutssh has joined #ocaml
<Riastradh>
Smerdyakov, that's the _LANGUAGE_.
<Riastradh>
Pay attention to what I'm saying.
<Riastradh>
Smalltalk is about the _ENVIRONMENT_.
<Smerdyakov>
The environment and the language come in a package here, from what I understand.
<monochrom>
Who is the Environment?
<Smerdyakov>
I would avoid using an amazing environment if it forced me to use a poor language.
<Riastradh>
Yes, that is correct. But it doesn't _matter_.
<monochrom>
Oh, as in IDE?
<TheDracle>
I've found languages with exceedingly complicated syntaxes to usually have such excessive syntaxes due to lack of functionality in the expressiveness of the language.
<Riastradh>
Smerdyakov, so you reject _ANYTHING_ that you haven't predetermined with certainty to be _perfect_ by your standards?
<TheDracle>
Because these concepts couldn't be expressed in ways other than through the syntax.
<Riastradh>
You're worse than I thought.
<Smerdyakov>
Riastradh, I reject anything that requires me to use a language that I conclude is a bad choice to use.
<TheDracle>
And you conclude everything is a bad choice to use except for ML.
<TheDracle>
ML has good ideas, but it is not the do all end all of language design.
<Smerdyakov>
TheDracle, wrong... gawd, you're so childish.
<TheDracle>
There are good ideas elsewhere.
<TheDracle>
.. Gawd..
<TheDracle>
Lol.
<Riastradh>
Smerdyakov, gawd, you're so childish. It doesn't meet certain _COMPLETELY_UNRELATED_ requirements, so therefore it must automatically be horrible.
<TheDracle>
Don't use the word "gawd" and then accuse someone of being childish in the same sentence. You probably should have followed that up with "dude."
<Smerdyakov>
Riastradh, I am talking about the _holistic_development_strategy_.
<Smerdyakov>
Riastradh, are you talking about a strategy that uses the Smalltalk environment and not the Smalltalk language?
<Riastradh>
Smerdyakov, I'm _NOT_ talking about holistic development strategies!
<Riastradh>
I'm _NOT_ telling you to drop everything and start using the Smalltalk language or environments for all your development!
<monochrom>
TheDracle: I am confused. Do you mean we should say "gawd, you're childish, dude"? Or "gawd, you're dude"? Or "Dude, you're childish"? :)
<Riastradh>
I'm _NOT_ saying that you're wrong to think that the Smalltalk language is 'bad.'
cj has quit [Read error: 60 (Operation timed out)]
<Smerdyakov>
Riastradh, then what _ARE_ you saying?
<TheDracle>
Smalltalk is completely about its environment. It can express iterations, callbacks, everything Ocaml or C or any of these languages can simply with the object oriented paradigm. Simply with objects and messages.
<Riastradh>
All that TheDracle mentioned was that the Smalltalk environment is cool, which I agree with, and which you _SHOULDN'T_ attempt to refute just because you disagree with the _language_.
<TheDracle>
It has no need for while, or for.
<Smerdyakov>
I never meant to refute that the environment is "cool."
<Smerdyakov>
TheDracle, neither does any functional language.
<TheDracle>
I think smalltalk is one of the most elegant.
<TheDracle>
Right, it does the same thing through iteration.
<TheDracle>
Ahem, I mean recursion.
<TheDracle>
So, functional programming is very interesting two, they aren't mutually exclusive.
<Smerdyakov>
I mean to suggest that _not_ allowing such a thing is a sign that a language shouldn't be used, rather than that allowing it is a sign of a superior language. It should be a minimum standard.
<TheDracle>
Ahem too.
<TheDracle>
Right, but Ocaml doesn't feature many things that smalltalk does, or features the same things in a different manner.
<TheDracle>
Which one does it better, or more correctly, or is more useful in the end? I'm not willing to say yet.
<Smerdyakov>
And I've concluded that it's OCaml.
<monochrom>
What is an example of a smalltalk thing that ocaml doesn't have?
<Smerdyakov>
Reflection
<Riastradh>
monochrom, the environment.
<monochrom>
You see, I actually don't know what is "the environment"... :)
<Nutssh>
Smalltalk, Ocaml, Common Lisp.
<Riastradh>
Then I suggest you download Squeak and toy with it a bit.
<monochrom>
I guess we say that the environment that can be named is not the True Environment.
<Smerdyakov>
I remain convinced that all such features are barely useful at all, and are supported on the basis of their "coolness factor" in the minds of geeks.
<TheDracle>
Not useful!?
<TheDracle>
Lol.
<Nutssh>
doesNotUnderstand messages --- you can do dynamisism smalltalk can't.
<TheDracle>
Seriously.. LOOK at squeak.
<TheDracle>
It's absolutely friggen amazing how useful it is.
<TheDracle>
How simple the syntax is yet how powerful and expressive it can be.
<Nutssh>
Err, that ocaml can't.
<Smerdyakov>
TheDracle, be sure to udnerstand me properly: No feature can be understood in isolation. I'm saying that a language design that includes it is probably clearly suboptimal.
<Riastradh>
Smerdyakov, how do you expect that your statements about Smalltalk can _POSSIBLY_ be taken seriously without ever having even _USED_ a Smalltalk environment?
<monochrom>
No, sorry, I won't download and try it. I am a scientist, not a priest, in this regard. I believe that a good idea can be conveyed with articulated and without immersion.
<Smerdyakov>
TheDracle, I'm sure it's very useful in the context of Squeak, but this could be because of other deficiencies in the language.
<monochrom>
s/articulated/articulation/
<Smerdyakov>
Riastradh, because I have a good understanding of programming methods.
<Riastradh>
Smerdyakov, or you're asking me to describe something that isn't very meaningful to describe.
<TheDracle>
Really good descriptions.
<monochrom>
You can count on me being a patient listener when someone is willing to take up the effort of describing the squeak environment. I am curios, but scientifically curious, not religiously curios.
<Smerdyakov>
Riastradh, no, if it isn't meaningful, then it isn't useful.
<Riastradh>
Smerdyakov, I said 'meaningful _TO_DESCRIBE_.' _READ_ what I say!!
<Smerdyakov>
Riastradh, if it isn't meaningful to describe, then it isn't useful.
<Nutssh>
squeak is a *highly* dynamic interactive environment, where everything is an object (so no 'primitives'), that can have arbitrary methods added.
<Riastradh>
Do you garnish your food at all, Smerdyakov, to add flavour?
<Riastradh>
Flavour, after all, isn't useful, because it can't be meaningfully described.
<Smerdyakov>
Riastradh, flavor is not a concern in engineering.
<Smerdyakov>
Riastradh, I am asking you about engineering.
<Smerdyakov>
Riastradh, if you mean to talk about some wishy-washy aesthetic judgments, then just say so.
<Nutssh>
It supports dynamism that pretty much nothing else has. Also virtually all of the environment, including the GUI/windowing system on up is implemented in smalltalk.
<Smerdyakov>
Nutssh, this certainly doesn't sound revolutionary yet. Most users of a dynamically typed language think up such things on a regular basis.
<Riastradh>
Smerdyakov, 'dynamically typed' is _NOT_ synonymous with 'dynamism,' regardless of the case.
<Smerdyakov>
Feel free to substitute some phrase using the word 'dynamism,' then.
<Riastradh>
Smerdyakov, why will you not just spend a few minutes toying with Squeak?
<Nutssh>
Eg, you can rewrite an existing class on the fly, adding methods, removing methods, changing the parent class, etc. The graphics are based on a bitblt set of primitives, so an entire GUI is possible. Also keep in mind that smalltalk-72, the precurser to smalltalk-80 is over 30 years old.
<Riastradh>
Consider it a new OS that you're trying out.
<Smerdyakov>
I never "try out new OS's."
<Smerdyakov>
If no one can describe why it's useful, then it probably isn't. Period.
<Smerdyakov>
I don't care about _liking_ it. I care about becoming _more_efficient_ because I use it.
<Nutssh>
Also a large amount of introspection, everything including calling frames, is accessible within the interpreter. Eg, a debugger can be written in smalltalk to debug a smalltalk environment, or even itself (its own code, not a seperate image a.la. gdb gdb.)
<Riastradh>
Oh, you're one of _THOSE_ morons. Never mind; I don't even bother trying to argue with the efficiency freaks who couldn't care less about anything else.
<monochrom>
Can I do this in Squeak? I write up some code, it becomes an object, let's say with a method m that takes a number parameter, then I can tell it to become some interactive artifact on the screen, and I can click on some place, and it will let me enter a number, and then method m will be called?
<Nutssh>
I've given an answer to that question--- which you have already discounted.
<Smerdyakov>
Riastradh, well, since you are so embarrassed of your position in the social ladder that you won't reveal it, I'm guessing that you have certainly paid the price for your unfocused attitude on this.
<Riastradh>
Smerdyakov, if you're going to insult someone in an argument, you could at _least_, as I have, make it _relevant_ to the argument.
<Smerdyakov>
Riastradh, it _is_ relevant. Caring about efficiency is crucial to success as a software engineer.
<monochrom>
I have not discounted anything!
<Nutssh>
Better yet, don't insult.
<Nutssh>
I don't care about micro efficiency (or most macroefficiency) until I run the code in a profiler.
<Riastradh>
Smerdyakov, so if you absolutely _loathe_ an environment, as long as you can generate code quickly in it, you'd prefer using it over something that is not quite as efficient in terms of code generation, but that is _vastly_ more pleasant to use?
<Smerdyakov>
I would like to point out that Riastradh begin the "insults" with "you're one of those morons."
<Riastradh>
Smerdyakov, that was at least relevant to the argument.
<Smerdyakov>
Riastradh, code generation? I'm not talking about _that_ kind of efficiency. I'm talking about the efficiency of the software engineering process.
<Riastradh>
Smerdyakov, I don't bloody _care_. It was quite obvious that I was asking you a question in which the emphasis was on how pleasant the environment was.
<Smerdyakov>
As an engineer, I will never loathe an environment that enables me to do my job the best.
<monochrom>
Nutssh: I want to thank you for the description. Much appreciated.
<Smerdyakov>
Nutssh, you haven't presented any arguments for the software engineering benefits of this that I've seen. Did I miss something?
<Riastradh>
How idealistic, Smerdyakov.
<Nutssh>
Smalltalk (squeak) is the most interactive development environment I have ever used.
<Smerdyakov>
OK. And here's "MS Visual Studio: Red Edition."
<Smerdyakov>
It has the most red of any IDE I've ever used.
<Smerdyakov>
Does that make it a good choice to use?
<Nutssh>
(no, i'v not used many)
<Riastradh>
Smerdyakov, so you'd rather repeatedly statically recompile applications every time you make changse?
<Nutssh>
If you want to be mocking, I'm not taking the bait.
<Smerdyakov>
Riastradh, it tends not to be a big problem for me, yes.
<Smerdyakov>
Nutssh, no, I'm trying to point out why I'm nonplussed by what you're saying.
* Nutssh
likes altering a running program, if needed, to add a feature or remove a bug. Did it before for a networking daemon on squeak.
<Riastradh>
Smerdyakov, have you ever used any environment that was designed for more interactive, dynamic use?
<Smerdyakov>
Nutssh, now we're getting somewhere.
<Smerdyakov>
Nutssh, to be convinced of the usefulness of this, I would need to look at alternative ways of swapping code, and evaluate what you lose by giving up easy static checking.
<Smerdyakov>
Riastradh, no
<Nutssh>
Smerdyakov: Its generally coonsidered rude to just discount something without experiencing it. State that you're not interested in hearing about it, or listen to what people say.
<Smerdyakov>
Nutssh, I don't think it's rude in scientific circles, when an advocate of an idea refuses to explain why it is a good idea.
<Nutssh>
There are tradeoffs, Its not a 'beats everything' language. Its a good language that you can learn a lot by learning.
<Riastradh>
Static checking doesn't verify everything; you can't fix every bug at compile-time. But in Smalltalk, you can modify the code as it's running once you _do_ get a run-time error.
<Nutssh>
I explained advanttages 10 minutes ago.
<Smerdyakov>
Nutssh, I don't think you did. You listed features without placing them in the context of effective development strategies.
<Riastradh>
And, in general, if you have to recompile/reevaluate only certain small parts of your program as you modify the running code, that's _definitely_ more efficient than _repeatedly_ recompiling the _entirety_ of the application.
<Smerdyakov>
Riastradh, apparently you've never heard of separate compilation? :)
<Riastradh>
What I said still holds.
<Nutssh>
'Development strategies' is a field laced with opinion and habit. IMHO, Its not something that can easily be judged scientifically at this time.
Xolution has quit [Read error: 110 (Connection timed out)]
<Riastradh>
All you need to do is substitute module for application.
Xolution has joined #ocaml
<Nutssh>
What is this 'compilation' thing you talk about? :)
<Smerdyakov>
Nutssh, well, if you can't talk about development strategies, you can't make a case for using a language at all.
<Nutssh>
Well, WTF do you mean by ''development strategies''.
<Smerdyakov>
Descriptions of processes whereby people create software that meets specifications
<Nutssh>
''smalltalk allows for highly productive interactive development.'' :)
<Nutssh>
.... increasing programer productivity.
<Smerdyakov>
This is a thesis, not evidence for a thesis.
<Riastradh>
We've given evidence above.
<Smerdyakov>
I didn't see any, save for slightly detail-deficient mention of runtime updating of code.
<Riastradh>
What details do you want?
<Nutssh>
Perhaps you should give an example.. Could you explain how ocaml helps people create software that meets specifications.
<Smerdyakov>
That was the first case where an actual application was mentioned ("networking programs" or similar).
<Smerdyakov>
Nutssh, why, certainly! Here is a scenario for you:
<Smerdyakov>
Nutssh, Alice and Bob are working on a project where each is in charge of some modules. They use abstract types to describe key values communicated between the modules.
<Smerdyakov>
Nutssh, when Alice changes the definition of an abstract type in one of her modules, there is no need for Bob to change his code, since the compiler has checked this property of Bob's code ahead of time.
<Smerdyakov>
End of scenario!
<Smerdyakov>
("this property" above is proper compatibility with the signature of Alice's module)
<Nutssh>
In other words, ocaml is strongly statically typed at compile time.
<Nutssh>
That situation is a direct consequence of that language property.
<Smerdyakov>
That is a feature of OCaml. What I described is one development strategy that takes advantage of that.
<Riastradh>
What do you mean 'changes the definition of an abstract type?'
<Smerdyakov>
Features in isolation are useless. There must be at least one way to use them to your advantage.
<Nutssh>
Dynamism means that programmers can fix bugs and interactively develope code much faster.. Are you requesting a fictional story about Alice and Bob where that feature would be used?
<Smerdyakov>
Riastradh, used to say 'type t = int', now it says 'type t = real'.
<Smerdyakov>
Nutssh, yes.
<Riastradh>
This is much too vague for me to be able to respond.
<Smerdyakov>
Riastradh, "changing the definition of an abstract type" has a very precise definition for ML.
<Riastradh>
Yes, but not in Smalltalk.
<Nutssh>
I've run out of carbon paper tonight and my shrinter is broken.
<Smerdyakov>
Riastradh, I was talking about ML....
<det>
Smerdyakov: Wow, you get everyone to play by your rules. Now make them tell a story in the form of a Klingon war song :)
<TheDracle>
Smerdy, if Bob's code used that type in a manner that wasn't compatible with the redefinition, wouldn't the code break?
<Riastradh>
Smerdyakov, so how do you want me to respond?
<Riastradh>
I don't think it's very easy to respond with a story involving Smalltalk, but keep talking about ML.
<Smerdyakov>
TheDracle, not if the misuse is captured by typing. If the observable semantics change, it could break.
<TheDracle>
Right, it would definitely get captured.
<TheDracle>
It would break at compile-time.
<TheDracle>
Which is a definite feature.
<Smerdyakov>
TheDracle, no, abstract types allow you to avoid even the need to recompile dependent modules.
<Nutssh>
I'm not interested in telling stories.
<TheDracle>
Smerdy: Yes, but the moment you recompile those modules with the different source.
<Smerdyakov>
Riastradh, I'm asking for a story about Smalltalk, not a story analogous to mine.
<monochrom>
I am!
<Riastradh>
OK.
<Riastradh>
Alice & Bob are working on two different Smalltalk classes.
<Smerdyakov>
TheDracle, ... they are guaranteed to continue working.
<Nutssh>
One would argue that thats broken. Do types matter? What matters is if the object supports the functions that are invoked. Real, bigint, fixnum, or float.
<Riastradh>
Alice writes some code to send a message to an instance of Bob's class.
<monochrom>
"Once upon a time there was a princess. Her CSC 423 assignment would be due in three hours, and she hadn't started...."
<Riastradh>
Bob adds a new method to his class.
<Riastradh>
Alice's code miraculously continues to work!
<Riastradh>
End of story.
* Smerdyakov
claps.
<Riastradh>
There, you have a story regarding Smalltalk.
<TheDracle>
Hehe.
<Riastradh>
Now, can someone please tell me how either my or Smerdyakov's stories had any relevance to the prior conversation?
<Smerdyakov>
Now, to evaluate language choices, we need much more involved story schemas that cover the whole development process.
<det>
Riastradh: I was certainly entertained, have you considered entering theater?
<Smerdyakov>
We need to evaluate the costs each implies, and go with the cheaper one.
<Nutssh>
Now copy it into triplicate and shred it.
<Riastradh>
You could just _bloody_try_the_environment_, Smerdyakov.
<sic->
php is the ideal language for all programming tasks because it makes web developers more efficient than any other language and all programming is just a special case of web development, what's all this about ML and smalltalk? those are too hard to learn and old, which equates to "obsolete" according to the spec. If coders would just agree to use strncmp_i in other languages, I think the object oriented nature of php's dynamic class system would
<Nutssh>
Smerdyakov, my shrinter is broken, can you play with squeak for an evening, and I'll shrint your reply?
<Smerdyakov>
Nutssh, no. There are things I'd rather use an evening for.
<sic->
have I summarized the arguments so far?
<Nutssh>
*CLAP*
<Riastradh>
Smerdyakov, can you tell me any useful result that has come out of this hour of bickering?
<Smerdyakov>
Riastradh, now you understand more about what is necessary to give convincing arguments for the use of any programming tool.
<Riastradh>
I am fairly certain that a _useful_ result could have come merely by you & monochrom just _playing_with_Squeak_ for a bit.
<Riastradh>
No, now I just understand how much more mulishly stubborn you are about what you haven't predetermined is perfect.
<Nutssh>
You've been given arguments... that you've chosen to not accept.
<Smerdyakov>
Nutssh, I've refuted the assertion that they are arguments for the conclusion you claim.
<Riastradh>
I'm going to eat supper now, and you still ought to _just_bloody_try_Squeak_.
<Smerdyakov>
That sounds like a mixed drink.
<TheDracle>
I'm still confused about this entire type thing :p type t = Bob of int | Joe of float, type t = Jack of float
<Nutssh>
dynamicism, interactivity, reflection, clean design. I guess they're not features you think helps people create software or helps people create software that meets specifications.
<TheDracle>
If you pattern matched on that expression from the module it was defined in, what would you reffer to those items as?
<Riastradh>
_Even_if_ you determine that you dislike Squeak, you'd have wasted less time than you have now by just having tried Squeak!!!
<TheDracle>
Like, if it suddenly changed, wouldn't your pattern matching break? Wouldn't you have to match for Jack instead of Bob or Joe? Lol.
<monochrom>
How can you have two different types both called t?
<Smerdyakov>
TheDracle, you can't pattern match on constructors of an abstract type.
<TheDracle>
mono, it gets redefined in the module it was being included from.
<TheDracle>
And then compiled again.
<Nutssh>
Riastradh, it takes a bit more than an evening to see the beauty of smalltalk.
<TheDracle>
Well, you can pattern match on data structures containing that type.
<Smerdyakov>
TheDracle, so? You'll never be able to tell which implementation you're working with.
<Nutssh>
There is a semi-abstract type in 3.07, I think, where you can have a type thats not abstract for purposes of pattern matching, but cannot be used for constructing values.
<TheDracle>
Hm.
<monochrom>
Alright, so if it is "type t = Bob ... | Joe ..." at one time, and some other code relies on that, and later you change it to "type t = Jack ...", then yes a lot of things won't compile.
<Smerdyakov>
monochrom, _not_ if it's an abstract type!
<Smerdyakov>
monochrom, because the other code couldn't rely on it!
<Nutssh>
TheDracle, 'type t = ...' sets up a binding, you can have several within a given scope. You can't however have two tags in the fully qualified module, eg, 'type t= ABC ;; type u = ABC' is illegal.
<TheDracle>
Yeah.. Abstract types are confusing me now :p I've got more reading to do :p
<monochrom>
"some other code" can be inside the same module.
<Smerdyakov>
It's not an abstract type within the module.