[Haskell] pros and cons of static typing and side effects ?
Bulat Ziganshin
bulatz at HotPOP.com
Thu Aug 11 05:49:28 EDT 2005
Hello mt,
Thursday, August 11, 2005, 12:09:30 PM, you wrote:
>> if you want to WORK, not hack - that is a right way
m> yes, that's the kind of answer i expected... that's the kind of thing you
m> always see when reading something about haskell. but i guess there's
m> arguments against... i'd like to make my opinion without just reading
m> a post saying "it catches many errors".
you must get more experience in programming in general and try to
write the same things in Haskel in particular and then you can make
your own conclusion on this part. my conclusion (based on C++, Perl
and Ruby experience) is just that i say
m> maybe this mailing list is not the
m> right place to ask this question ;-) maybe i should ask on a lisp mailing
m> list :)
haskell-cafe is definitely better place than this list :)
>>
>> m> Same question for (direct support of) side effects.
>>
>> it's just because Haskell is a lazy language. this rises expresivness
>> and strongly divides program to two parts - without side effects and
>> with side effects
m> the way it's divided is to remain purely functional. would it be bad if the
m> side effects part was designed without keeping a pure functional language ?
i think, it is no matter. really, we have purely fucntional part which
can be optimized just with mathematical laws, imperative part which
can't be so well optmized just because imperative operations creates
"optmization barriers" between statements, and unsafePerformIO to
those who wants to try optmizing imperative part as functional one
m> i see sometimes this kind of arg : it's easier to reason with a pure
m> functional semantic. is this hold when you have to program a fair amount of
m> imperative code in haskell?
i don't reason anything :) while an imperative code is a "fair
amount" of my program, complex (functional) computations is a part that
takes most time and attention, and contains most bugs. imperative
part, after all - is just sequencing of operations performed
m> in fact my first question was not haskell centric but more general, like if i
m> wanted to design a new language, not like if i wondered which language to
m> choose.
of course. there is interesting dynamic languages, such as Ruby, but i
prefer Haskell over anything i know
--
Best regards,
Bulat mailto:bulatz at HotPOP.com
More information about the Haskell
mailing list