|
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.
|
|
|
|
|
Stephen Hewitt wrote: 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.
+5. I'd just add that I see dynamic languages as a better fit for web front ends.
|
|
|
|
|
I would tend to disagree. Those small utilities will grow into something else after a while (we do live in enterprisey world). After a couple of months when adding some additional "unforeseen" feature you will wonder why a+b works when a+c doesn't. Especially if someone else have been touching this utility.
I'd say scripting languages are good for quick prototyping and a throw away code, but just maybe. Why not do a proper prototype with a clever design that could grow up from throw-away to a fully usable base.
P.S. I'm biased, my perl scripts do look like a normal OO code after all (-.
Trust is a weakness.
|
|
|
|
|
AWdrius wrote: Those small utilities will grow into something else after a while
I recently wrote a Perl script that removes a useless macro from our C++ code. That won't grow into anything bigger and I did not need type safety: read files line-by-line, check them out if I find the macro, remove it, repeat. No functions, no types, ceirtanly no objects: done in 5 minutes.
|
|
|
|
|
That is covered by a "throw away code" part I believe. Unless you will be running your script on every c++ code compilation attempt. But then - why do you need some useless macro in the first place?
You example is good tho, script languages are almost ideal for a single "one-two" task, but when speaking about scripts that are meant to be used on a daily/weekly basis I stand my ground that strong typed languages should be preferred here.
Trust is a weakness.
|
|
|
|
|
AWdrius wrote: but when speaking about scripts that are meant to be used on a daily/weekly basis I stand my ground that strong typed languages should be preferred here.
OK, another example, this time form my open-source project: a Perl script that zips the files into a release[^]. I have used it for years, and haven't changed it for three years now so it is not "throw away code". Yet, it is small, simple and I don't see how it would benefit from static typing.
|
|
|
|
|
Very good example. In this case I have nothing to argue about. Shell script would suit your need in the same way.
BTW. I would create a small console application that could be configurable through arguments/config files so that it could be re-used for other projects or by other people. If nothing similar already exists of course.
Trust is a weakness.
|
|
|
|
|
It does not depends of the "how big the project is". Sometimes you need to break type-safety to make a feature, that application will depends on (usually feature is lower level than application) and for such libraries and features type-safety is unthinkable. However in commercial world, where it is more important to have results fast, rather than to have better result, it is prefered to have not-so-stable, but ready libraries and features than writing better on your own. Thus type-safety is not just a obligation. Companies prefering languages that have type-safety automated.
|
|
|
|
|
It does depend. I think few people with a C background will argue that .net is overmanaged, and there are times when low level access requires a slimy hack of some kind, and it gets in the way.. overall a good thing, but some caveats.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
