Skip to: Content | Navigation | Footer
Dr. Blip's PC-Doctor Blog
function foo( a, b )
if a < 0.0
print( b )
end
end
foo( -12, 'This string is printed' )
foo( 5 )#1 - hector 2007-07-31 10:20 -
Personally, for large projects, I like the extra safety that a strongly typed language compiler gives you. Sure, you have to explicitly decide which type you want for a variable, but on a weakly typed language you should also know what are the types you are working with.
If I know it is a project that is not going to get too big or complex, I would use a weakly typed language, otherwise, I would take the safe route.
On a different note, I really like Java and the idea of GWT, so I think you made the right choice. Sorry for not flaming you ![]()
#2 - fred.bertsch 2007-07-31 10:26 -
Yeah. That was pretty much my assumption before starting that post. It's not exactly a surprise that I ended up there, too. ![]()
#3 - Andy Koch 2007-07-31 10:28 -
Did you actually run that Ruby code?
foo( 5 ) should throw an exception like,
ArgumentError: wrong number of arguments (1 for 2)
Also, it worth pointing out that you can build type controlling into Ruby (or other weak-type script language). As in...
function foo( a, b )
unless a.class == "Fixnum" raise
unless b.class == "String" raise
if a
#4 - fred.bertsch 2007-07-31 10:32 -
Oops. I got my Lua and Ruby confused!
However, the type safety you describe is not sufficient. That's essentially an assert that something hasn't screwed up, and it relies on a set of unit tests to ensure that it's correct when you compile it. (I'm assuming that your tests run when you build/deploy the project.)
That's not enough. A strongly typed language will tell you all of the type errors at compile time. It happens before you even have a chance to forget a unit test!
Thanks for the flame, though!
![]()
#5 - Andy Koch 2007-07-31 10:39 -
OK, the comment field cutoff the rest of my comment.
While I see the value in strong-typing, I've generally not had an issue with weak typing. If ever I need to ensure a type, for an SQL as example, I just do a "5".to_s.
The development speed that Rubyists tout isn't necessarily related to weak vs. strong typing. It's more related to being able to complete a project in less time than in Java (or other compiled language). Size of the project is generally irrelevant. Proper development techniques (unit/functional tests) ensure quality of the end result.
But comparing GWT Java to Ruby may not be fair, they have different use cases. Comparing GWT to Prototype sounds more reasonable. Afterall, the strong-typed Java compiles into weak-type JavaScript.
#6 - fred.bertsch 2007-07-31 11:13 -
Ruby on Rails folks definitely like to talk about how fast you can complete a project using RoR. A big part of that is their library, though. Their library is easy to write tests for, it strongly encourages small, loosely-coupled components, and it has a rich set of functions to express a problem with.
It'd be nice if GWT had that. Unfortunately, it's still young. For now, all it has is strong typing.
Generally, strong typing fans like to say that it's more important when a project gets bigger. As a project gets bigger, you end up with more coupling between individual components. (This is because you end up with more components to couple with.) The complexity of the coupling tends to grow faster than the complexity of the individual components. (The amount of coupling increases with project size. Individual components have the same complexity no matter what size the project has.) This means that anything that reduces the complexity of coupling components will, with a sufficiently large project, create a less complex project.
I wrote this in Big-O notation, and then decided that, while fun to write, it wasn't useful. ![]()
Anyway, strong type fans claim that strong typing is far more important in a large project than a small one. I'll admit it. I'm a strong type fan. I make the same claim! ![]()
#7 - Andy Koch 2007-07-31 11:23 -
Dang it Fred, you're not listening! (FLAME, FLAME and TROLL!)
I've got many large projects and typing has never really been an issue. If I need something to be a certain type I just cast it.
OK, so I agree that strong-typing has it virtues. But, your debate stems from usage of GWT. Therefore I don't think comparing GWT (via Java) versus Ruby is the correct focus.
The question should be rephrased as, "What JavaScript library enables me to get the project done the fastest with similar code quality standards?" So comparing GWT vs. Prototype is a better idea.
How long will it take to implement all the AJAX-ic stuff in GWT vs. the same task in Prototype? Do they both result in the same level of code quality? etc.
#8 - fred.bertsch 2007-07-31 11:32 -
Oooo. It's very clever to change the topic when you're losing the flame war! ![]()
It's a good topic, though. GWT and Prototype are both fairly thin libraries. GWT has some support for things like dialog boxes and Prototype has some fancy code for selecting DOM elements. (I'm thinking of the $$() function here.)
Prototype is tightly integrated with Ruby on Rails, so that would be a strong selling point if my web app had anything interesting going happening on the server.
At this point, I don't have a lot of experience with GWT. The tool support in GWT is much better than it is with Prototype. It's great being able to debug the Java code directly, for example.
Strong vs weak typing seemed like a better question to ask, since I had a better chance of answering it. Which one is actually better is a much better question, but it's a lot harder to answer. ![]()
#9 - Andy Koch 2007-07-31 11:38 -
>> Which one is actually better is a much better question, but it�s a lot harder to answer.
So I'm right that you're ducking the actual question. Very honorable of you to admit that.
Perhaps you could do a GWT code training, then I can do a comparison of GWT and Prototype. Perhaps we could generate another emomtional charged flame war.
#10 - Chris Hill said:
2007-07-31 11:43 -
While you two have been busy flaming each other, I've been busy fixing the comments. They should be much prettier now. ![]()
#11 - hector 2007-08-01 08:15 -
Hey Andy,
PHP Eats Rails for Breakfast. I just thought this thread needed a little starting fluid.
#12 - Andy Koch 2007-08-01 09:14 -
Your old news Hector,
First, what lunatic would state that one language is better than another based on the number of lines of code?
By that standard COBOL is a great choice, in fact why don't we just do assembly?
Second, PHP is a language, Rails is a framework. Comparing Rails to Cake would make sense. Or Rails to Django (python).
Finally, Ruby is younger than PHP and has had far less support till Rails came along. Consider the third graph showing the number of new projects. Ruby dominates all comers.
I predict in 5 years time people will think of PHP they same way they think of Perl today. That is, a stodgy old scripting language that still serves it's purpose but is bearish is usage.
Thanks Hector, I like a good flame war in the morning. ![]()
#13 - hector 2007-08-01 10:42 -
>>Second, PHP is a language, Rails is a framework. Comparing Rails to Cake would >>make sense. Or Rails to Django (python).
Yes, PHP is a language, but a language designed for the web. On the other hand, Ruby is a language which has been adapted, through Rails to be a web platform, so I think comaring PHP to Rails is valid.
>>I predict in 5 years time people will think of PHP they same way they think of >>Perl today. That is, a stodgy old scripting language that still serves it�s >>purpose but is bearish is usage.
And I predict that in 5 years, people will find that all the different optimizations to Rails will still not make it a highly scalable platform (there will be cool 3.0 sites in rails, but no wordpresses, no amazon.coms or no ebays on rails)
#14 - Andy Koch 2007-08-01 10:49 -
>> And I predict that in 5 years, people will find that all the different optimizations >> to Rails will still not make it a highly scalable platform (there will be cool 3.0
>> sites in rails, but no wordpresses, no amazon.coms or no ebays on rails)
Nonsense, Rails is highly scalable and the focus of Rails 2.0 (due out this fall) is enterprise quality.
The initial focus of Rails is saving development time and targeted not the giant J2EE sites but the 80% of smaller web apps where J2EE is overkill.
From experience I can tell that Rails run circles around PHP when considering development issues.
#15 - Dr. Blip’s PC-DoctorÃ?® Blog » Google Web Toolkit: said:
2007-08-27 08:37 -
[...] browser plugin based to using the Google Web Toolkit for the JavaScript part of the project. See my previous blog post about [...]
#16 - Dr. Blip’s PC-DoctorÃ?® Blog » Static Analysis of said:
2008-03-10 08:37 -
[...] 2008, 8:37 AM by fred.bertsch in Static Analysis, Software Development, fred.bertsch, Engineering A while ago I wrote about whether or not untyped languages were a good idea or a bad idea. I didn’t come [...]
© 2010 PC-Doctor, Inc. | About this site | Contact | RSS | Back to top
Design by Andreas Viklund | Serendipity Template by Carl






