Re[2]: functions with states

[khamenya]

Hello Corrin, Fergus and clean-list,

Thursday, May 04, 2000, 7:04:14 AM, Corrin wrote:

CL> It is usually a much better idea to reformulate your problem than to try
CL> and force a new language to work with your old solution.

1. I agree in general. Of course I understand that functional languages
oblige us to reformulate our tasks in different way and implement the
solutions in different way.

2. And what do I see in your word "reFORMulate" also? The essence of
solutions might be simple and almost unchanged for a huge class of
problems. All we need is to reFORM the solution.

CL> As soon as you
CL> break the functional model by introducing state, you lose most of the
CL> benefit of using a functional language.

I have no tendency to return this young and nice functional language
Clean into the existing family of old non-functional languages.

CL> [Clean is not a higher level version of C.]

hm, I understand that the ability to deal with high order function is
not a exclusively main feature of Clean.

CL> [Foo_counter example and explanations]

thank you for your explanation. I satisfied with your answer. As
Fergus Henderson mentioned, the "function with states"
needs reformulation. in current form this issue is complete for me.

CL> A:[nondeterministic code is good for debugging in isolation]

CL> B:[deterministic code is hard for debugging in isolation,
CL> and Clean is much harder here than languages such as C.]

I suppose here that the "deterministic code" in your sense rather stands
for code highly interacted with its "calling environment" than for
code with well defined order of execution. Than we have:

A: code noninteracted with its calling environment is good for
   debugging in isolation

B: code highly interacted with its calling environment is hard for
   debugging in isolation, and Clean is much harder here than
   languages such as C.

I've noticed that to myself already.

CL> You CANNOT implement usual C-code in Clean.  You cannot implement usual
CL> Clean code in C.  You can implement algorithms in C and you can implement
CL> algorithms in Clean so to write Clean programs you need to translate at
CL> the algorithm level, not at the code level.

[I will not shift the main focus of your statement with following:
we understand _all_ we can implement in Clean we _can_ implement in C
and vice versa. I rely on that. However, indeed:...]

[translation "C/C++ <-- Clean" might be very difficult]
       Of course, e.g. we can not directly implement in adequate way
       the high order functions in C. My experience says: even new C++
       ability with templates gives definitely less than Clean with
       its high order functions. (However 'bind' and so on already
       available in C++. The appearance of "object-like functions"
       makes C++ closer to functional language. Almost all benefits
       available at compile stage not a rn time stage. However the
       difference is still awesome)

[translation "Clean <-- C/C++" might be very difficult too]
       We also can not easy translate from C/C++ to Clean. Indeed,
       there is a terrible juggling with side effects in every line of
       program!

My not eduring (one year) observation on Clean gives me foundation for
the motivation wich penetrates my letters:

It would be such a awful disappointment to see Clean in category of
eccentric, extravagant or bizarre languages while it can... replace
(at the least to shake historical leadership of) C/C++ in class of
general purpose languages.

My wish to the main inspirer (I guess it is a Rinus Plasmeijer) of
Clean works is: "don't stop on success attained!". Clean is not like
a HTML, SQL or "some educational purpose"-language. I'm sure Clean is
not good, but excellent for general purpose programming.

>> The open question for me is: "is Clean ripe enough?"

CL> It is easy to implement some things in Clean, implementing other things is
CL> hard.  You can solve very hard problems in Clean so the language is
CL> 'ripe'.

I said 'ripe' but I should say 'ripe as general purpose language'.
Hmm, of course SQL is ripe! You don't need to mention about hard task
implemented in SQL.

Clean is ripe enough as a experimental language. NO DOUBTS.
I believe in more. Following part of this letters strongly do not rely
on specificity of Clean but rely on opportunity of general purpose
using of Clean.

CL> However some of the skills you have developed in breaking a
CL> problem into steps will be useless in Clean, learning to write real
CL> programs in Clean will be as hard for you as writing real programs in C
CL> was nine years ago, at least for a month.

Again I agree in general. What should we have when we descent deeper?

//============start of model project

// ------------------low level of my project:
foo::Int Int ->Int
foo x y = x+y

//------------------medium level of my project:
fib::Int ->Int
fib 1 = 1
fib 2 = 1
fib x = foo (fib (x-1)) (fib (x-2))

//----------------- high lveel (driver) of my project:
Start = foldl foo 0 (map fib [1..6])
//================== end of medel project

Here it is a naive model project I manage.
What do I need when the CUSTOMER says "well! everything is all
right!... but I also need a typical history of your 'foo' function.
Why?.. you said it is most expensive function i'd like to learn its
specific and improve my hardware for it."

[It is normal. And here no matter that 'fib' is not optimised enough!]
What should I have? All modules are debuged enough and I need only a
small modification dealing with low level function 'foo'. I notice that
Clean is touchy for such a modification. Type system which usualy
helps us now stops us.

Of cours the logging affects the 'world' environment. But the history
logging is not a "side effect" in its algorithmic essence.  Potentially
this history logging might be implemented in functional languages
style. Can we do such a small addition in Clean? inoffensively?

Don't rush to say "We can not."

C++ and Pascal have a 'goto' ability but still they are high level
languages!

Of course I can't see the whole picture of Clean formation, but I
think that the ability to quickly add a priori painless (without side
effects) code is not destructive direction for Clean's evolution.

CL> I see the real question not as "Is Clean ripe enough?" but as "Do the
CL> problems I solve fit nicely into the functional way of thinking?",

Well it might be really HARD for me to think about my projects in a
pure functional way, but as a mathematician I can estimate the benefit
of such approach.

CL> and "am
CL> I willing to put in the work needed to master the functional way of
CL> thinking?"

[of course I try to critically regard of my way of thinkig]
I do NOT believe that the "functional thinking" is exclusively intended
for some specific class of problems but not for general purpose field.

CL> Even problems that fit well into functional programming
CL> sometimes need to break the rules, and there are techniques to allow you
CL> to do this, but they shouldn't be used as the first step.

'goto' and 'exception' techniques are _not_ the framework of C++ (I'm
sorry for such an extensive exploitation of C/C++ phenomenology)

CL> Clean is good if your problem is primarialy a transformation.

Dear Corrin do you know a problem which is primarily not a
transforamtion? 

CL> For example
CL> Clean is good for complex AI algorithms, for many computer vision tasks,
CL> ray-tracing, etc.

There is an good level of formulisation for such a field. [No good
formulisation -- no good results]. There is an easy fall here saying

"Clean will make a massif for solutions in those fieleds".
[one can say here that it is better to have a small goal taken over than a
big goal fail.]

CL> Problems with a high degree of state, especially
CL> interactive programs are not so easy in Clean.  While such problems can be
CL> solved, solutions

[here your phrase was interrupted :( ]

CL> Clean has a c_call function for calling C or any language which supports
CL> the C calling scheme, including C++ and a few others.  Obviously from C
CL> you can call almost every language.  This calling ability is minimal, only
CL> enabling you to pass around strings and numbers, although that is adequate
CL> for most tasks.  You could also use the TCP libraries and set up a stream
CL> to another language, and I suppose using RPC wouldn't be much harder.

A good technical move! why to "surrender" with Clean?
There is still a question for me
"is Clean ripe enough for general purpose problems?"

I do believe the answer is "sure".
Without any redirection to other languages like SQL and/or my favorite C++.

CL> I hope you continue to learn a functional language, whether it is Clean,
CL> Haskell or another, but please do not expect the correct solution for C to
CL> be the correct solution in Clean.  Functional programming takes a bit of
CL> getting used to.

I do Corrin!

Thank you dear Corrin Lakeland for your thorough answer. You helped me
to settle with my attitude towards Clean.

P.S. hmm, letter seems to be too long and I'm not sure that I did not
     violate the rules of this mailing list... is there a moderator?

-- 
Best regards,
Valery A.Khamenya                            mailto:khamenya@module.ru