|
...but not mandatory.
There is always going to be times when you may need to step outside the boundaries a little, but I think that the language should make THAT move more clear. It should force the programmer to wrap the code in something that makes the condition obvious to other developers, and obviously the compiler and debugger, and should always be one of the focuses of code review sessions.
Not saying you can't. Just saying that if you do you better HAVE to, be able to explain it, and then make sure others that have to maintain it can locate it and know why you did it.
Ah, but to live in a perfect world.
- Specifications would never change mid-project.
- You would always have enough people for the project.
- You would always have enough time to design, code, and test (in that order).
- Project scope would never change mid-project.
<ahhhhhh, dream="" state="">
|
|
|
|
|
In general type safety is a very good thing. I have found the quality of code to be considerably better in typed systems, though there is a soft spot in my heart for perl.
However in C# for example the staticness is a bit stronger than I wold like. many times I have wanted duck typing or the adbility to cast to a type specified by a variable. These could be added without harming the language.
Perl also has a default variable $_ , I would truely love to see something like that even though it might change the language's flavor
Ken
modified on Thursday, May 20, 2010 9:27 AM
|
|
|
|
|
Type safety has its price. When performance is critical, I think, it can be bypassed.
So it is useful, but not critical.
|
|
|
|
|
and why do you think type unsafe variables are faster? ;D 
d{^__^}b - it's time to fly
|
|
|
|
|
Because compiler puts additional code to enforce type safety, during run time.
|
|
|
|
|
The question was about compile-time type safety as opposed to dynamic typing.
Obviously dynamic typing is slower than static typing.
Why do you think statically + weakly typed programs are faster than statically + strongly typed programs? I think there shouldn't be any difference.
|
|
|
|
|
Why do you think that? In general any performance penalties will be paid for at compile time, not runtime. In fact the statically typed language should be faster at runtime since the exact layout and set of allowed operations is known from the onset and there will be no unexpected type conversions.
Steve
|
|
|
|
|
I voted for "Type safety is useful, but not critical", but I would have preferred "it depends".
It's useful in large applications, but if you're knocking together some utility in a scripting language it tends to get in the way.
Steve
|
|
|
|
|
no it doesn't, it's critical, scripted applications are created on top of type safe code, you can't build house on the sand, can You 
d{^__^}b - it's time to fly
|
|
|
|
|
For tiny apps it is not that important, but is bad practise.
I like type safety as you can look back at 'Code implemented by Venerable Grandfather' and see whats what at a glance.
------------------------------------
I will never again mention that I was the poster of the One Millionth Lounge Post, nor that it was complete drivel. Dalek Dave
|
|
|
|
|
However Smalltalk variants improve on that even - you don't need to look at functions definition to see what the parameters mean for example - its right there in the call.
Personally, I use both typed and untyped languages - each has there own merits.
I think maybe C++ gives a bad impression of strong typing, largely due to its badly broken declaration syntax and over-complex overloading rules. You shouldn't need to have a language specification at hand to resolve issues.
For good examples of justifications of dynamic typing, I recommend reading Gilad Bracha's Room 101[^] Columns, detailing the Newspeak language.
|
|
|
|
|
Who said anything about building a house? I said "knocking together some utility". And I maintain that many small utilities benefit from loose dynamic typing.
Steve
|
|
|
|
|
you maybe maintain small utility, but the 'real' world is big ;}
d{^__^}b - it's time to fly
|
|
|
|
|
I live in a house on the sand 
|
|
|
|
|
You've obviously never actually built a house... It is better to build a house on sand as opposed to stone, because if you use stone in the northern regions the frost heave can destroy your house, your better off building on sand because the house "floats" on the foundation as opposed to being attached to the substrata.. a building at my former college was destroyed[^] because they had inadvertently put one of the foundations into a boulder, and every spring when the moisture seeped down it lifted that footing 1 mm, resulted in the whole building twisting.
I'd blame it on the Brain farts.. But let's be honest, it really is more like a Methane factory between my ears some days then it is anything else...
|
|
|
|
|
Fine if the sand is the foundation float, then surrounded by solid ground, but no help if the sand is surrounded by more sand, on a sandy slope into the sea, or a river and it rains. Goodbye house.
|
|
|
|
|
Ya.. i am also agree.
Its critical.
|
|
|
|
|
radioman.lt wrote: you can't build house on the sand, can You
You mean, like, dog house 
The OP was pointing to small utility not building a mansion... 
|
|
|
|
|
Stephen Hewitt wrote: you're knocking together some utility in a scripting language it tends to get in the way.
In all fairness, does it really get in the way? It takes about 5 seconds to declare the variable type.
|
|
|
|
|
Ever used templates in a language like C++? By your reply I'd say not. And there's more to it than that: like the free and easy conversion between "types" in languages without strong type systems.
Steve
|
|
|
|
|
Unless I've completely misunderstood, type safety and polymorphism aren't orthogonal concepts. But I agree with your choice of vote.
/ravi
|
|
|
|
|
Also voting for a best fit, choosing the useful-not-critical route seemed the way.
I learned to program without it (or even declarations) - and somehow it all worked out fine.
Well - actually, having declarations of types is very useful (anyone who ever barely misspelled something in Fortran77 will testify to that).
It's certainly helps to avoid errors (and with pointers, errors of potentially biblical proportions) - but one can certainly live without it: be careful. Test things.
Type safety doesn't prevent screw~ups, neither does its absence cause them. Both of these are our job.
/xml> "The difference between genius and stupidity is that genius has its limits." - Albert Einstein
| "As far as we know, our computer has never had an undetected error." - Weisert
| "If you are searching for perfection in others, then you seek dissappointment. If you are searching for perfection in yourself, then you seek failure." - Balboos HaGadol Mar 2010
|
|
|
|
|
|
I've never seen it actually get in the way when you know what you are doing.
(Granted, when knocking together some prototype, you don't always know.)
Still, I'd rather have a typed system than wonder what the result of a+b will be when a is a bitmap and b is a bugblatter beast.
A type is defined a a set of possible values, plus the operations on top of it. In addition, there are cross-set operations, such as scaling a vector. Reason for using a typed system are thus:
- the meaning of common operation symbols depends on the values (the operation encoded by a+b differs for real numbers and for vectors)
- many operations don't work for all combinations of values (multiplying a 2x2 matrix with a 4x4 matrix)
- types exist and play a distinct role in most problem domains
The only "immediate advantage" of untyped systems I see is that the same code can manipulate a wide range of "underlying types", and often does as intended if the system is well designed. templates / generics / a common ancestor type can somewhat mitigate that problem.
----
|
|
|
|
|
I Believe strong typing helps improve the code even thou I've built entire systems without it. On large projects, with lots of developers, it becomes more important, because the odds of something going wrong increases considerably.
However it does occasionally slow down the process of creating a quick little application to solve a simple problem.
Escaping a Bugblatter Beast: 
(no type safety)
1) Quick grab any towel and cover your whole head.
2) Chisel you name on the wall - this confuses him - but he'll get over it.
3) For safety - feel your way to an exit, without removing towel.
(type safe)
1) Grab a military grade towel to with a weave of no more than <insert specification> and etc.
- Whoops! To late - your time is up and you are dead.
Well that was a bit extreme, but so are some type specifications.
INTP
"Program testing can be used to show the presence of bugs, but never to show their absence." - Edsger Dijkstra
"I have never been lost, but I will admit to being confused for several weeks. " - Daniel Boone
|
|
|
|
|
I agree.
I don't normally post comments on these surveys but I was going to this time, pretty much on the lines that you have.
Henry Minute
Do not read medical books! You could die of a misprint. - Mark Twain
Girl: (staring) "Why do you need an icy cucumber?"
“I want to report a fraud. The government is lying to us all.”
Why do programmers often confuse Halloween and Christmas?
Because 31 Oct = 25 Dec.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
