|
![](/i/fill.gif) |
Orchid XP v8 wrote:
>> Only if you're using a functional language and therefore you have to
>> pass everything around all the time, even if you're not using it right
>> now. :-)
>
> You don't have to do that if you don't want to. Smart programmers don't.
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.
> 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.
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.
I.e., to the extent that it's possible to not *know* what type your argument
is, you don't need static typing. 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. It's easy to do, but that's why
there are patterns you can follow to avoid exactly that problem. 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.
> (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 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? If the old
code took a single value, and the new code takes a list of values, and there
are 17 places you need to change, don't you have to decide what to do with
the other values in the list at each of those places?
> 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.
--
Darren New, San Diego CA, USA (PST)
The NFL should go international. I'd pay to
see the Detroit Lions vs the Roman Catholics.
Post a reply to this message
|
![](/i/fill.gif) |