From: David Vallner Date: 2006-10-19T07:35:44+09:00 Subject: Re: Lisp dinamism vs ML safety --------------enig9B596228237DFF7BEB20649B Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable > I am More of a Ruby guy but i programed in CL and Scheme and SML. > dynamic typeing allows for less code and faaster develipment. static > typeings safty benifits are pointless becaus the # of bugs is > preporial to the lines_of_code. a line of code not needed is a correct > line of code!!!!! and how often do you get type errors >=20 So, still bedazzled as to: a) why you crossposted the whole shenanigans that came before when it was unrelated to Ruby, b) why did you post into the thread at all when you had nothing to say, c) why the freaking hell can't you for once press the hotkey for "spellcheck" instead of the fifth exclamation mark, I'll bite on the sweet, sweet trollbait. Let me introduce you to my good friend, ITMS. A fairly common type of software project, automate paper-pushing for [insert European Union Perk here]. My friend weighs in at 750 model classes in 20 modules. (To that about 1900 controller classes and some 2800 view pages, but those are horribly redundant, and irrelevant for the topic at hand.) And mind you, those are model classes. No amount of metaprogramming shenanigans will save you from the fact that number's not changing between programming languages. So. Do you want to bet money on that you could avoid type errors? I would estimate no less than a week spent on you hunting typos. Not to forget that once erb evals your code, any exception thrown in it won't have a u And yes, I know that the app I'm describing is mostly boring grind. Yet, it needs to be done, and it needs to be done without a NoMethodError when an approval for several hundreds thousands of euros goes through it.= [cue comment about unit testing being able to catch those] That is arguably replacing following type constraints with another sort of grind.= Now, for the more salient bits of your twaddle than the chance to reinforce my position of resident [insert C++-derivative language here] troll. Nagging at ML is a very, very, very stupid idea. Nagging at it with how dynamic typing reduces code volume is even more stupid. In fact, dynamic typing in Ruby is the least contributing factor to reducing code volume - manifest typing declarations are hardly code that is prone to bugs in any way - it's just a declaration. To add insult to injury, ML isn't manifestly typed - not even optionally as opposed to Haskell as well as I'm aware. (Corrections on that point welcome). So that means the extra code volume of manifest typing just isn't there. Also, most of the code volume reductions that dynamic typing does bring are in my opinion achievable in other languages if you make a very granular object model. Think Java with one interface per one method as the very extreme. Since interfaces are only contract declarations, once again, that's lines of code that can't possibly contribute towards bugs - only lines of code where "something happens" do. The more important contributing factor to Ruby's productivity I see is an API designed for utility, straightforward regexps (despite all my rants against side-effect variables of those, even I get a migraine when I have to do RE hackery without $0-$9), good text-processing, each/map/select/inject, tab-completion in irb, and the fact that a Ruby quick hack doesn't get out of hand as early as a Perl one thanks to the first-class OO semantics and lack of a culture of implicit argument abuse= =2E Amusingly enough, ML can do enumerations just as well, and if you need to work with numbers more than text, the text-processing features get rather irrelevant. For problems backed by a more formal theorethical model than a use-case one, I would put my money on ML being much more productive than Ruby simply because it offers better ways to represent that model. Yes, amongst other things a strict type system that will let you tag even structurally identical entities with different types to fail fast when they are confused. (A type error between an annotated mixed directed / undirected graph and an automathon operating on the graph would be rather iffy to track down. Disclaimer: those are probably not structurally identical types, just a scary smug-looking namedropping example.) And oh, yes. Fail-fast is GOOD. If there's an unrecoverable error in your code, it should crash and burn in a rain of tears. The sad thing is that Ruby's NoMethodError is anything than fail-fast - the type error is detected usually far from the place where it originated. Defensive programming can of course prevent that, but I sort of have my doubts about whether goes through the chore of making his code more maintainable when it reaches a scope when that is needed. David Vallner --------------enig9B596228237DFF7BEB20649B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (MingW32) iD8DBQFFNqw6y6MhrS8astoRAmz5AJ9FrK3Fq2cGjWePObeFK+QvXiD0igCfccE8 n8NGF9NBlvonmCuy72LPXpg= =kxQ5 -----END PGP SIGNATURE----- --------------enig9B596228237DFF7BEB20649B--