|
Re: Strong typing and Type Safety.A multilanguage approach
by zentara (Archbishop) on Nov 19, 2010 at 17:33 UTC
|
Your article mentions alot of Perl finepoints, for which all have a best practices, for instance you write:
Consider another example :
open( my $FILEHANDLE, '<', 'myfile.txt' );
$a=<$FILEHANDLE>;
#<> returns just one line
open( my $FILEHANDLE, '<', 'myfile.txt' );
@a=<$FILEHANDLE>;
#<> returns the whole file contents
the diamond operator returns different values depending on the context
+.
So what? Thats a handy tool to have in the hands of an experienced programmer. So what do YOU think of Perl's automatic type handling? As a fairly long time user, I can say it makes programming alot easier, rather than being forced to make casts and lines of empty prototype specifications.
Now it does slow processing, to have the program itself, determine variable types, but when you need speed, you can always reach for C or Fortran. ( and call it from Perl thru IPC :-) )
| [reply]
[d/l] |
|
|
this was an example to show the difference between list and scalar contexts in Perl as the other examples in that section try to do
| [reply] |
|
|
... but my real question, not to hassle you, was: what do you personally think of this sort of Perl loose typing? C,mon... what is your personal preference? :-)
You did want our comments, didn't you?
Personally, I see Perl as one step up in the race for pure artificial intelligence, it works the way I think, it deals with the topic of context.
| [reply] |
Re: Strong typing and Type Safety.A multilanguage approach
by eyepopslikeamosquito (Archbishop) on Nov 20, 2010 at 12:41 UTC
|
I found this old MJD quote relevant:
After reading a lot of articles, I discovered that different people had at least eight different notions
of what 'strongly typed language' meant. Sometimes they weren't even sure themselves; I found some articles
which defined 'strongly typed language' and then classified languages as strongly or weakly typed in explicit accord with some other definition that contradicted the one they had first given.
My conclusion is that 'strongly typed language' doesn't mean anything at all, and that if you hear someone
say that some language is strongly typed, or some other language is weakly typed, you should assume that you don't know what they meant.
Your articles are based on your opinions, especially your opinion of what "strong typing" and "weak typing" mean. Yet these opinions were not supported by citations.
Accordingly, I found these articles somewhat lightweight and lacking in rigor.
Also, writing a series of articles on typing without describing type inference and functional languages (e.g. Haskell) is a serious omission IMHO.
Since I couldn't find any useful references on typing in your articles, I present a few below that I found useful:
| [reply] |
|
|
| [reply] |
|
|
were not supported by citations
Let's take this one to Room12A too!
if you hear someone say that some language is strongly typed, or some other language is weakly typed,you should assume that you don't know what they meant.
that is correct and is the exact point of the article which you unfortunatelly completely missed;the point was that such a distinction is not feasible.Have you noticed the section "Perl Weakly typed?"
and then "Perl Strongly typed?" or the conclusion of the article that you cannot label a language of one type or the other? however you should be able to understand the mechanisms behind typing though so when someone uses the terms strong or static or weak or dynamic or late or early binding, more or less know the whereabouts.Why do these terms exist otherwise if they serve no purpose?
I also think that the example with the void pointers makes the concept of type safety pretty clear
Also, writing a series of articles on typing without describing type inference and functional languages (e.g. Haskell) is a serious omission IMHO
what is your definition of type inference then and whose type systems' shortcomings does it address?
Update :
book citations through Google books :
Perl Cookbook 2nd ed (Page 408)
Beyond Java (page 57)
Beginning VB 2008: From Novice to Professional (page 66)
Practical Distributed Processing (Page 156)
| [reply] |
|
|
| [reply] |
|
|
Why do these terms exist otherwise if they serve no purpose?
Of course they have purposes, but that not does not speak to their utility in language analysis.
The purposes of these terms are many and varied. In my experience, their primary intended purpose is to form invalid arguments. (An invalid argument is an argument for which one cannot ascertain the truth of its conclusion.)
| [reply] |
|
|
|
|
|
|
|
| [reply] |
|
|
|
|
that is correct and is the exact point of the article which you unfortunatelly completely missed
You are right. I missed it.
Maybe I so was enchanted by all those advertisements that kept relentlessly popping up in my face
that I missed the point of the actual content.
Maybe I got distracted by having to click "Next" again and again because I could
find no option to display the whole article on one page.
what is your definition of type inference then
I think I've found the definitive definition of "type inference" on page 6 of
"Type Systems Demystified" by Nikos Vaggalis:
type inference: used extensively by Linq where a lot of times you cannot use explicitly typing, so you let the compiler decide
If you find a better definition, please let us know.
| [reply] |
|
|
Re: Strong typing and Type Safety.A multilanguage approach
by Anonymous Monk on Nov 19, 2010 at 08:09 UTC
|
disorganized and shallow, almost aimless | [reply] |
|
|
Maybe it looks disorganized because it is split into 2 parts and maybe you need to check
first part also to get the full picture.
But I don't get why you think that it is shallow.I would be most interested in hearing your opinion in more detail
Also it is not offensive towards Perl, in case you got offended, and furthermore helps people not initiated to Perl (especially to the visitors of the site hosting the article since it is a general programming site) get a view of how Perl works
| [reply] |
|
|
From your earlier part:
The main difference, roughly speaking, between a strongly typed language and a weakly typed one is that a weakly typed one makes
conversions between unrelated types implicitly, while a strongly typed one typically disallows implicit conversions between unrelated types.
You then imply, in Example 2 in the "Weak Typing in Perl" section, that using the numeric + operator
on a Perl string is "implicit" and therefore weakly typed. As chromatic once remarked:
What's implicit about using numeric operators on strings?
If you use string operators on strings, you get string behavior.
If you use numeric operators (which you must do explicitly), you get numeric behavior.
What isn't explicit about that?
Update: The same argument applies to your "Example 1" in that applying the Perl string concatentaion operator to a number is explicit. Perl is different (and superior IMHO) to many languages in that it does not overload + to mean both numeric addition and string concatenation.
| [reply]
[d/l]
[select] |
|
|
|
|
|
|
|
Maybe it looks disorganized because it is split into 2 parts and maybe you need to check first part also to get the full picture.
Disorganized in the sense that it tries to follow some kind of mobile phone type formatting, where width is limited to 60 chars, table of contents is forbidden, and starts off written in the 3rd person. Its almost has a playboy article feel, but without the benefit of nude females.
But I don't get why you think that it is shallow.I would be most interested in hearing your opinion in more detail
Because it is not in depth; it doesn't deliver what it promises and borders on incoherent wishy-washy.
Based on the vocabulary its clearly written for experts
but its full of vague generalities and not the kind of details experts would need to be demystified.
A beginner would be very confused but impressed by the authors immense knowledge, and left in awe of the coolness of these things and the author for knowing them.
An in-between-er would also be impressed, but lose interest after trying to decipher the prose between the code.
An expert would breeze through this article and think about thanking the author for a laugh, then do his own research.
Also it is not offensive towards Perl...
Did not think it was offensive towards any programming language
| [reply] |
A reply falls below the community's threshold of quality. You may see it by logging in.
|
Re: Strong typing and Type Safety.A multilanguage approach
by Anonymous Monk on Nov 19, 2010 at 18:07 UTC
|
That's quite an eye-bleedingly bad article layout.
There is this newfangled internet thing involving a "browser" that can render text on screens wider than 200 pixels, and you don't even have to know how many pixels when you write the text!
| [reply] |
|
|
OT: but there is a lot of research supporting the proposition that lines of 60 chars or fewer are easier to read (comprehend) than lines approximating the kind of max lengths those newfangled browser-things can render.
;-:)
| [reply] |
|
|
There is indeed lots of research showing what makes something easier to read. Then there's also recent research showing that making text more difficult to read can make the content of the text easier to remember. That's not definitive work yet and it had to do with the fonts used rather than page layout in general, but it's worth consideration.
Maybe in page layout as in Perl TIMTOWTDI. Of course, there are myriad wrong ways, too.
| [reply] |
|
|
FWIW, I doubt in that research the 60 chars of content were squeezed by 50/100 chars of advertising from each side respectively (squeezed, because there is hardly any whitespace around the content)
| [reply] |
|
|
that can render text on screens wider [...] and you don't even have to know how many pixels when you write the text!
Oh, you are so stuck in the pre-CSS web...
I bet you also think that text should never overlap confusingly or be cut off at the edge of the browser with no scrollbar to let you see the rest of it. That's so last decade!
I mean, who needs to be able to read all of the text on every page when the display elements can have... *gasp* round corners!!! *squeal*
| [reply] |