|
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
