clipka wrote:
> BTW, I really like (attention - possible flamewar ahead! :)) Microsoft Visual C#
> in this respect: Comes with integrated code refactoring, which is a real
> pleasure to work with.

"Visual C#" is not a language and languages don't come with code 
refactoring.  Visual Studio comes with code refactoring and other 
standard IDE goodies, like most good IDEs.  Of course, code refactoring 
is much more needed in more straightjacket languages with lots of 
scaffolding to make the compiler happy. ;)

Post a reply to this message

nemesis wrote:
> code refactoring is much more needed in more straightjacket languages with lots of 
> scaffolding to make the compiler happy. ;)

You mean, like Smalltalk? ;-)

(I assume you know something of the history of it?)

-- 
   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

Darren New wrote:
> nemesis wrote:
>> code refactoring is much more needed in more straightjacket languages 
>> with lots of scaffolding to make the compiler happy. ;)
> 
> You mean, like Smalltalk? ;-)
> 
> (I assume you know something of the history of it?)

I know Xerox GUIs were developed in it and that Smalltalk is deeply 
integrated to them and a programmatic environment.  Except for GNU 
Smalltalk, which is text-only. :)

I said more needed, not that it doesn't help at all.

Post a reply to this message

nemesis wrote:
> I said more needed, not that it doesn't help at all.

I was under the impression that Smalltalk was the first system to have 
refactoring built into the UI.  I might be wrong about that, as I can't find 
anything online easily backing up that assertion.

Nevermind.

-- 
   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

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

Darren New wrote:

> I was under the impression that Smalltalk was the first system to have 
> refactoring built into the UI.  I might be wrong about that, as I can't 
> find anything online easily backing up that assertion.
> 
> Nevermind.

Rick-click that method name, select "rename", it renames it in all your 
code.

Although IIRC, there was some catch to it... I think it might be that it 
does a simepl find-and-replace, without awareness as to WHICH CLASS 
you're dealing with. So if class X and some unrelated class Y both have 
a "foo" method and you rename it to "bar", it's renamed for *both* 
classes. Which usually isn't what you want.

But then, we're talking about a weakly-typed language, so unfortunately 
it's kind of unavoidable...

Post a reply to this message

nemesis wrote:

> Of course, code refactoring 
> is much more needed in more straightjacket languages with lots of 
> scaffolding to make the compiler happy. ;)

Why is it that some people see a propper type system as "unecessary 
garbage that's only there to keep the compiler happy"?

Post a reply to this message

Invisible escreveu:
> But then, we're talking about a weakly-typed language, so unfortunately 
> it's kind of unavoidable...

Please don't counfound dynamic typing with weak typing.  Python, Scheme 
and Smalltalk are all strongly typed languages.  C, Perl and Tcl are 
weakly typed.  I'd be very surprised if Smalltalk refactoring wouldn't 
take class scope in consideration for scoped refactorings.

I still prefer "monkey patching" or "ninja patching" to refactoring, 
though. ;)

Post a reply to this message

Invisible escreveu:
> Why is it that some people see a propper type system as "unecessary 
> garbage that's only there to keep the compiler happy"?

Don't worry, languages with the Hindley-Milner type system are much 
better in this regard. ;)

Post a reply to this message

Invisible wrote:
> 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.

Don't you have to pass the state monad around?

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

I'm not saying it's *because* you wrote in a functional style, which is 
clearly close to impossible in Smalltalk. I'm saying it's because you wrote 
in a non-OO or not-very-OO style.

> 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.

Yes, but hopefully in only one place. There shouldn't be a lot of places in 
your OO code that know what's in that collection if it's reasonable to 
change the collection to a non-collection.

Obviously, if your image has a collection of pixels, you're not going to be 
able to change that to a non-collection, so the question is moot.

If your server accepts commands from a socket and you change it to accept 
commands from many sockets at once, then the "get next command" is pretty 
much the only method you should have to change. Nobody outside the "command 
reception" class should know how many sockets you have.  If your server is 
issuing socket.read() calls from inside the body of the server that you'd 
need to change, you've structured your code incorrectly.

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

I do too many things where the data has to change over time to get away with 
that sort of stuff. Sure, I pass in a hash table mapping strings to values, 
but nowhere keeps track of what the keys may be. (Indeed, the one place of 
enforcing that only the right keys got written to the database was the 
primary place I forgot to fix when adding new types of information to the 
system.)

> 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? 

Yes. Less and less as time goes on.

> 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"?

Yes. Less and less as time goes on. :-)  I've learned how painful writing OO 
software like that is, and I now avoid it.

> 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.

I see what you mean.

> (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.)

There are non-browser based javascript interpreters, too.

> 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?

If you're assigning to that from outside the class that's encapsulating 
that, you've done something wrong.

> 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...

Yeah. I can't tell you how often people have said "The interface is easy. 
It's XML."   "Oh, can I have the schema?"   "We don't have one, but here's 
some example records."   WTF?

-- 
   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