 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New escreveu:
> Invisible wrote:
>> Isn't that precisely what Smalltalk also does? :-P
>
> Oddly enough, Ada can unload and reload new code while it's running too,
> and that's about the most anal-retentive language I've ever used.
Yes, Ada is a traditional descendent of Algol and Pascal.
> You know, I did my PhD work by patching into someone else's structured
> editor/compiler/interpreter written Smalltalk, without really
> understanding all the details. I had this kind of error maybe a handful
> of times, and it was never confusing what happened.
Good to know. And indeed, lack of static typing is not the tragedy
people like to paint it.
>> As soon as you start trying to do anything more sophisticated than
>> that, scripting languages become inadaquate.
>
> I disagree.
So do I and Amazon, Google, Yahoo and many others.
BTW, while his webpage seems down at Microsoft Research, one of the
fathers of Haskell, Erik Meijer, had a pretty swift view of what it is
about:
"Before joining Microsoft, I was an associate professor at Utrecht
University where I worked on advanced /scripting languages/ such as
Haskell, XMLambda, and Mondrian"
Cool, huh? ;)
Google Cache:
http://64.233.169.132/search?q=cache:6bWObCjUcd4J:research.microsoft.com/~emeijer/+Erik+Meijer+on+haskell&hl=en&ct=clnk&cd=1&gl=br
Perhaps he quit Microsoft?
BTW, besides strong and opinions (many that can be seen at
http://lambda-the-ultimate.org/ weblog), he's also author of a number of
cool papers, "Static Typing Where Possible, Dynamic Typing When Needed",
discussed here:
http://lambda-the-ultimate.org/node/834
:)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
>> Of course, much as I like Smalltalk, the lack of static typing makes
>> it really hard to use. [...] but *good luck* figuring out where the
>> _problem_ is. The
>> call stack only shows you where the problem get _detected_.
>
> You know, I did my PhD work by patching into someone else's structured
> editor/compiler/interpreter written Smalltalk, without really
> understanding all the details. I had this kind of error maybe a handful
> of times, and it was never confusing what happened.
Apparently I'm strange. For me, this is *the* most common class of
errors. (After silly things like typos, at least.) And having to track
down and fix these problems manually seems so tedious when a properly
designed system would have told me exactly what to fix before I even
finished compiling.
>> As soon as you start trying to do anything more sophisticated than
>> that, scripting languages become inadaquate.
>
> I disagree.
It's a free country.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
> Apparently I'm strange.
We knew that.
> For me, this is *the* most common class of errors.
Odd. Maybe as you're coding you don't have a good model of what the code is
doing in your head already? If you're good at functional stuff, you may be
very good at specifying results but not so good at thinking about the
step-by-step process of getting to the results?
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Apparently I'm strange.
>
> We knew that.
Oh, thanks.
I wonder I have no self-esteem...
>> For me, this is *the* most common class of errors.
>
> Odd. Maybe as you're coding you don't have a good model of what the code
> is doing in your head already? If you're good at functional stuff, you
> may be very good at specifying results but not so good at thinking about
> the step-by-step process of getting to the results?
It's more that when you have a very large number of things, some of
which are important and some of which are incidental, you tend to forget
about some of them.
Also, if you *change* how your code works (e.g., you add an extra layer
of indirection), having a type system means you can just follow the
error messages to find the exact places where you need to change something.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
> It's more that when you have a very large number of things, some of
> which are important and some of which are incidental, you tend to forget
> about some of them.
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. :-)
> Also, if you *change* how your code works (e.g., you add an extra layer
> of indirection), having a type system means you can just follow the
> error messages to find the exact places where you need to change something.
This is helpful, but it also seems to not be much of a problem in practice.
You have an object that represents a concept, and that's where you make the
change. Yes, I suspect this is very problematic for a dynamically-typed
functional language (like Erlang, say). But in an OO language, you don't
have (for example) "state" and "list of states": You have "where I am now in
the state machine processing". It's exactly this kind of change that good OO
design is trying to make trivially simple. (It isn't, of course...)
I suspect it's harder than just "follow the error messages", because you
have to decide the logic of what to do at each point anyway. If you don't,
then the "duck typing" works exactly as it should. If there are many places
in your code where you depend on whether you have an extra level of
indirection, and they're not all obvious (e.g., in one class), then your
code is poorly organized and your algorithms probably depend on the
assumption that you don't have an extra level of indirection there. If there
aren't that many places, finding them isn't that hard if you know how the
code works, and having a good development environment helps you find them.
One of my problems with Erlang is that the documentation for the libraries
and especially the dev tools suck badly. There's all kinds of system
information that's useful, but it's like reading man pages to learn how to
design an X application - if you don't already know how it works, the
tidbits in the documentation isn't going to tell you. There are half a dozen
tracing tools and log display tools and everything, and nowhere does it say
"this is the order you combine these six things to get an idea of how the
system works." Typical open-source big-company stuff - sit down with the
other programmers and ask them. Except when you're not part of the company.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 <voi### [at] dev null> wrote:
> Also, if you *change* how your code works (e.g., you add an extra layer
> of indirection), having a type system means you can just follow the
> error messages to find the exact places where you need to change something.
Not really the wisest approach.
Been there, seen it. Sometimes I confess I do just that. But when it comes to
changes in critical subsystems, or changes in a critical phase of a project, I
make sure I find *ALL* the places that need changing before the compiler does.
Because if the compiler finds some, chances are he's just reporting the tip of
the iceberg.
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.
Oh, and when it comes to strict vs. dynamic type checking, I advocate the
approach as done by most mainstream OO languages these days (like Java, C#
etc.): Strict type checking, with language syntax allowing to override it
("type casting") where needed. And polymorphism and/or interface patterns
designed into the language, to be able to tell both the static and dynamic type
checking mechanisms which types are interchangeable for which purpose.
The total absence of *any* type checking in some languages, like JavaScript, may
be handy for very small quick-and-dirty stuff, because it is easy to e.g. add
new properties to a whole bunch of objects without needing to rewrite any
interface declarations, but for larger projects I guess it is too inviting for
a write-first-document-later approach. In large enough projects it may work
again because good documentation must be in place anyway - but then again, at
that scale automatic type checking - both at compile and run time - should not
hinder development in any way at all (otherwise your development process is
probably bogus anyway), and the corresponding language constructs may actually
provide a good formalism for certain aspects of the documentation.
I didn't have the opportunity yet to work with functional programming languages,
but from what I see I'd probably experience them as a PITA, and an increased
risk factor for an early death from brain haemorrhaging ;)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> It's more that when you have a very large number of things, some of
>> which are important and some of which are incidental, you tend to
>> forget about some of them.
>
> 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.
>> Also, if you *change* how your code works (e.g., you add an extra
>> layer of indirection), having a type system means you can just follow
>> the error messages to find the exact places where you need to change
>> something.
>
> This is helpful, but it also seems to not be much of a problem in
> practice. You have an object that represents a concept, and that's where
> you make the change. Yes, I suspect this is very problematic for a
> dynamically-typed functional language (like Erlang, say). But in an OO
> language, you don't have (for example) "state" and "list of states": You
> have "where I am now in the state machine processing". It's exactly this
> kind of change that good OO design is trying to make trivially simple.
> (It isn't, of course...)
I reiterate: I found this to be a major problem with *Smalltalk*, which
is a non-functional, OO language. My problem is *not* some design flaw
of functional programming. I hated using untyped languages long before I
even knew what functional programming *was*.
(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.)
> I suspect it's harder than just "follow the error messages"
In reality... yes, usually.
> One of my problems with Erlang is that the documentation for the
> libraries and especially the dev tools suck badly.
Not unlike Haskell, really.
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?)
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka wrote:
> BTW, I really like Microsoft Visual C#
> in this respect: Comes with integrated code refactoring, which is a real
> pleasure to work with.
A good refractoring tool is a very useful thing.
> Oh, and when it comes to strict vs. dynamic type checking, I advocate the
> approach as done by most mainstream OO languages these days (like Java, C#
> etc.): Strict type checking, with language syntax allowing to override it
> ("type casting") where needed. And polymorphism and/or interface patterns
> designed into the language, to be able to tell both the static and dynamic type
> checking mechanisms which types are interchangeable for which purpose.
>
> The total absence of *any* type checking in some languages, like JavaScript, may
> be handy for very small quick-and-dirty stuff,
> but for larger projects I guess it is too inviting for
> a write-first-document-later approach.
AKA "write-first-document-never" ;-)
This is basically my point about scripting languages. They're designed
to figure out what you "probably wanted" with the fewest keystrokes -
which is totally great if all you're trying to do is some simple one-off
task and you don't want to spend all week implementing it. *Not* so
great if you're trying to develop a large-scale application... [Although
Darren keeps trying to insist that Tcl is the best programming language
there is for that kind of thing.]
> I didn't have the opportunity yet to work with functional programming languages,
> but from what I see I'd probably experience them as a PITA, and an increased
> risk factor for an early death from brain haemorrhaging ;)
Quoting Lucas:
"But I've learned so much!"
"...then, you must un-learn what you have learned."
It's like going from a non-OO language to an OO language; you have to
get used to thinking in a different way. And until you do, you keep
trying to structure programs in a way that doesn't work well, and
getting frustrated when the result is a malfunctioning mess.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
> Darren keeps trying to insist that Tcl is the best programming language
> there is for that kind of thing.]
No. I just insist it's possible to use it for that kind of thing, having
done so many times. :-)
It's not the best. Up until a couple of years ago, it was the scripting
language with the most useful features like threads, GUI, could run as a
service, could package into a single executable, could be embedded, etc.
Nowadays, I suspect Python has a lot of traction in that sort of area.
> It's like going from a non-OO language to an OO language; you have to
> get used to thinking in a different way. And until you do, you keep
> trying to structure programs in a way that doesn't work well, and
> getting frustrated when the result is a malfunctioning mess.
I was saying I suspect you were building your OO programs in a way that made
them hard to change argument types.
--
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
|
|
| |
| |
|
|
|
|
| |
|
|
