Darren New wrote:

> I'm not sure how you avoid passing something, if you call code that 
> nests many levels deep which then needs that information. You can't put 
> it in globals if it ever changes.

You don't have to pass it explicitly though. It's a simple matter to use 
a state monad, and then you don't have to care about any state 
information except in the places where you actually use it.

>> I reiterate: I found this to be a major problem with *Smalltalk*, 
>> which is a non-functional, OO language.
> 
> Yes, I know. :-) I wasn't clear. I'm saying that if you design your 
> dynamically-typed OO program like you write functional programs, you 
> have this trouble.

And I had this trouble before I went to Uni, over a decade before I 
learned functional programming.

Clearly if you try to write code using paradigm X in a language designed 
for paradigm Y it's unlikely to work well.

> If you use something like "map" to iterate over the elements of the 
> argument passed to you and create a new collection with the result, you 
> have trouble if you change the argument to be a non-collection. If, 
> instead, you write the code to tell the argument to map itself, then 
> when you change that argument to be a non-collection, you simply apply 
> the map to one element and return.

Yeah, but if you changed a collection to a non-collection, surely you 
must have intended to change the _behaviour_ of the code, so you'll need 
to change it anyway.

> I.e., to the extent that it's possible to not *know* what type your 
> argument is, you don't need static typing.

Technically you don't "need" static typing ever. Anything that can be 
done with it can also be done without it, and the converse is not true.

Personally, I prefer the reassurance of knowing that the caller is going 
to pass in the right kind of data. :-P

> If there is code all over the 
> place that knows how many levels of indirection are needed to get a 
> particular result, you've done something wrong in your design.

Probably.

On the other hand... haven't you ever written code where you reassign 
responsibilities that used to be in one place, but are now in another 
place? Haven't you ever tried to modify some object, and then gone "oh, 
wait, that isn't the Customer object, it's a WeakReference to the 
Customer object"?

> The only reason you have lots of places that you need to 
> fix are because you are treating objects like data structures instead of 
> encapsulating the knowledge of the type into the class.

Not necessarily. (Although it *is* a common mistake amoung people used 
to procedural programming.)

>> (I still find it to be a program with JavaScript, for that matter. Of 
>> course, the beauty of JavaScript is that you can develop and run it 
>> *anywhere*. No other language has that.)
> 
> Lots of languages run more places than javascript does.

I didn't say "run" - I say "run *and develop*". C runs in places where 
JavaScript never will, but how many places have a C compiler? By 
contrast, almost _everywhere_ has a web browser and some kind of text 
editor.

(The only real problem are those few places which run Linux but don't 
have X Windows. I'm reasonably sure there are no text-mode browsers that 
run JavaScript, and sometimes the only text editor available is Emacs.)

>>> I suspect it's harder than just "follow the error messages"
>> In reality... yes, usually.
> 
> Don't you have to, say, *decide* what to do with that new data?

Depends if you're adding new data. Maybe you added a new object to the 
chain just so that you can replace part of the structure with a single 
assignment?

>> Some things are very well documented. (E.g., how to invoke the 
>> compiler.) Some things are very poorly documented. (E.g., how do I 
>> write high-performance code?) And some things have no documentation at 
>> all! (E.g., what does Control.Parallel.Strategies.sforce do?)
> 
> Well, one example is the Erlang tracing facility. It's apparently very 
> good. You can trace all the function calls, all the messages sent and 
> received, etc. There's another tool that shows trace records in a GUI. 
> But there's absolutely no indication of how you get the tracing records 
> into the GUI, for example. (At least, that's sort of my memory of it.) 
> Using printf to debug in Erlang is a pretty nasty way of going about it, 
> methinks. At least, I gave up before I figured it out completely.

Likewise, Haskell has one or two excellent tools which are horribly 
under-documented. For example, the excellent Parsec library:

http://haskell.org/ghc/docs/latest/html/libraries/parsec/Text-ParserCombinators-Parsec-Combinator.html

(There *is* a seperate tutorial document, but it's one giant HTML page. 
Not very helpful when you're trying to look up one specific function.)

As you might have noticed, there are immunerable language extensions for 
Haskell. Usually the "documentation" for these consists of a dozen lines 
of "self-explanatory" example code...

Post a reply to this message