|
Just last week I was looking for a new language to learn that would have some added value to what I'm already doing.
I first looked at Python. A cursory evaluation is that it's a kid's language. A lot easier to learn that "real" web languages. Sort of a VB for the Web.
Then I looked at Ruby. Apparently it's popularity is diminishing. As recently as last night I mentioned it to my son-in-law and he said they used to use Ruby on Rails at his place (a multi-thousand employee software firm), but now it's pretty much phased out in favor of Google's GO.
I might look at that (oh, how modern!) but one line in it worried me a bit (Wikipedia description):Quote: Semicolons still terminate statements,[a] but are implicit when the end of a line occurs which allows for sloppy programming.
There's always Android but that would hurry the approach of the inevitable surrender to acquisition of a "smart phone" because life is made impossible without one.
Ravings en masse^ |
---|
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
W∴ Balboos wrote: A cursory evaluation is that it's a kid's language.
From what I've seen - which I fully admit is very far from comprehensive - it looks that way to me as well. I particularly don't like "run time type checking" as it's a recipe for badly tested code...
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
OriginalGriff wrote: I particularly don't like "run time type checking" as it's a recipe for badly tested code... For any interpreted language, those kinds of checks require that every single line of code is actually executed during your testing. Error handlers for unexepected "errors that should not occur" are sort of difficult to test. Even error handlers that you know might occur (e.g. from racing conditions or other timing dependent situations) may be very difficult to provoke in a controlled manner. When you haven't even had a syntax check of your code before the situation occurs, you just can't provide a well tested error handling, and you end up with "Exception in exception handler" situations.
What you point out, "run time type checking" makes it a lot worse. It is not sufficient to execute every line of source code during testing; you must do it with every possible data type! It really is bad enough with (semi)strongly typed, but polymorphic, data in languages like C# - I have experienced error handlers that crashed because I had added another subclass without accounting for it in the error handler. Dynamically typed languages are magnitudes worse!
|
|
|
|