13 Mar, 2010, Runter wrote in the 1st comment:
Votes: 0
13 Mar, 2010, David Haley wrote in the 2nd comment:
Votes: 0
Good article. I wish people would write these in more general terms. A lot of it is neither specific to Ruby or Java in particular, but rather the difference between static and dynamic languages. I guess having concrete places to point fingers makes it easier to grasp the concepts. But a lot of it could be recycled very interestingly into a general prog. lang. theory discussion on language features, so that people understand the concepts generally.

I'm bothered by the bit on typing, though. It misuses the mathematical definition of a type, namely that a type is a set of attributes and operations. It assumes that two attributes/operations having the same name means that they are the same type theoretically. But it's easy to see that this is wrong, for names are nothing more than labels. Objects of completely different types could respond to "get_data"; does that mean it's the "same" operation? (And no, duck typing is not the answer to this problem, it's merely a corollary of the original issue.)
13 Mar, 2010, flumpy wrote in the 3rd comment:
Votes: 0
We have our own dynamically typed language, thanks


It's called Groovy.

Kthxbah
13 Mar, 2010, Runter wrote in the 4th comment:
Votes: 0
flumpy said:
We have our own dynamically typed language, thanks


It's called Groovy.

Kthxbah


I have nothing against Groovy. I have nothing against Java for that matter. :p

In fact, I'm glad to see any modern projects in the mudding community, and I consider yours to be one.
13 Mar, 2010, flumpy wrote in the 5th comment:
Votes: 0
Srsly tho, many Java devs see ruby as a toy language (I'm not one btw). I think they look at some code and go wtf and that's where it stops


Languages like groovy bridge the gap somewhat between static and dynamically typed languages, although I don't think it necessarily encourages ruby use, it certainly opens minds to 'another way to do it' and, possibly, let us see how the other half live.

Which is nice….
13 Mar, 2010, flumpy wrote in the 6th comment:
Votes: 0
After looking at the first slide that's not intro, I'd say the author has it totally wrong.

Most java devs see no typing as inherently a bad thing. Certainly, the environments they use are heavily geared towards static typing and auto completion etc. Its not a small hurdle at all, in fact its like going back in time about 20 years.

I know i went wtf the first time I used Ruby and I came from a basic programming background with later grounding in c++, and it was absolutely no fun at all, sorry to say, and I still wouldn't go back to using ruby, even if someone was paying me.

Edit: it could possibly have been the horrible tools I was using more than the language it's self tbh, but I still have nightmares about my autocompletion disappearing. At least in groovy I can strongly type if I want, use autocompletion, and remove the typing afterwards.. (Adding a duck type check if need be of course)
13 Mar, 2010, Runter wrote in the 7th comment:
Votes: 0
I'm not a java developer so I'll take your word for it that the author got it all wrong. With only one slide required to know that.
13 Mar, 2010, Runter wrote in the 8th comment:
Votes: 0
Also

http://en.wikipedia.org/wiki/Jruby

For anyone interested. If I used Java more I'd use this implementation.
13 Mar, 2010, flumpy wrote in the 9th comment:
Votes: 0
Rofl


Well, it was that slide and that assumption that I think he got all wrong. If he thinks because ruby was easy for him and will be easy for others dismissing the reliance on autocompletion and other ide features then I question the rest of the article too. No one's saying ruby isn't powerful or useful, just very very alien. All the rest of the coolness gets lost in the wtf's of the "alien environment" you're forced to use.

I actually think the idioms in ruby are cool, btw, and as I said I can now appreciate what ruby dev's do. Just don't ask me to use ruby, because if I can't fall back on what I know about 'how to do it properly' I feel very uncomfortable and my productivity drops..
13 Mar, 2010, flumpy wrote in the 10th comment:
Votes: 0
Jruby is neat, yes, because at least I can use the JVM and all my code libraries too if I like

But it still has that alien feeling to it :(
13 Mar, 2010, Runter wrote in the 11th comment:
Votes: 0
flumpy said:
Jruby is neat, yes, because at least I can use the JVM and all my code libraries too if I like

But it still has that alien feeling to it :(


It's also two way which is sort of neat.
13 Mar, 2010, David Haley wrote in the 12th comment:
Votes: 0
flumpy said:
Srsly tho, many Java devs see ruby as a toy language (I'm not one btw). I think they look at some code and go wtf and that's where it stops

Huh, well, I know many a C++ programmer (myself included when I first started looking at Java many years ago) who looks at Java and thinks it's a toy language. I'm sure many assembly programmers look at other languages and think they're toy languages too. Personally I don't think that this is anything more than some odd rationalization of habit, or even a form of prog. lang. xenophobia. Now, it's reasonable that people should operate in environments they're familiar with, and that doing something foreign would tend to make productivity drop. But that alone isn't basis for criticism (I know flumpy isn't criticizing on this basis).

As I said in my earlier reply, this is really an interesting point to be made w.r.t. any comparison between static and dynamic languages. A lot of people have the exact same reaction to Python or Lua when coming from C++/Java/whatever.

I think part of it has to do with cutesy examples. When you read Ruby or Python documentation, the examples tend to be humorous or cute, with funny variable names, familiar real-world objects, fruits and vegetables, etc. While I think this makes it approachable for some people, I think it reinforces a childish impression in others. Furthermore I think that there is a general disbelief that anything useful can be done in so few lines of code, so people see examples and assume it's just a toy example and that "real code" takes more space anyhow. Lua documentation is a little different because they have the ref. manual which is rather dry (which incidentally I think is very good in a ref. manual), but serves a different purpose; perhaps the book Programming in Lua or the Lua wiki might be better comparisons. But Lua obviously suffers from the same issues, most certainly ones like disbelieving that so much is happening behind the scenes.

And now for something completely different, Scala is another interesting language that bridges the dynamic/static gap. It runs on the JVM so also gives you full library access. It's type inferred, which is a feature I really, really like. It's new enough to me that I haven't written much code in it, but I really enjoy it. Unfortunately I must choose languages these days that I can be productive in, because I have relatively little time… Anyhow, Scala has a lot of very interesting features from a prog. lang. theory perspective. Worth a look if you like such things.
13 Mar, 2010, Runter wrote in the 13th comment:
Votes: 0
To be honest I turned my nose at "scripting" languages initially years ago until I educated myself a little more on the subject.
13 Mar, 2010, David Haley wrote in the 14th comment:
Votes: 0
Yeah. I think the term "scripting" alone is unfortunate, as it implies "not a full language", "just a small portion, not the core", etc. That's why I'm trying to refer to them as dynamic languages these days. I don't even use "interpreted" anymore because Java itself is technically interpreted (although it's JIT'd).

Also I think there has been some performance stigma, which really was a big deal a few years ago, and even in modern Ruby continued to be until 1.9. (I was initially very turned off by Ruby several years ago because it was so utterly slow and I get get comparable results in other languages with superior performance.) But we seem to be getting over that now, which is nice. So, we'll see what happens…
13 Mar, 2010, flumpy wrote in the 15th comment:
Votes: 0
Groovy is monolithically slow, in comparison to some dynamic languages (esp scala which is often mentioned in the same sentence as Groovy would be), often in magnitudes of x10 or more.

.. That said the groovy team have made great strides in speeding it up, however are currently constrained by Bad Design.

The take up of groovy over scala I would consider to be a little greater however, because of how similar groovy is to natural Java, indeed I can write a Java class in Groovy and it will work the same way.

If you remember, java became popular initially because of it's C++ like syntax, and then really got going when it went server side - the JVM took enormous strides with speed and stability and also security (unrivalled I would say in the latter) so it would make sense to introduce a new language that gives the same warm fuzzy legacy feeling, which is where Groovy fits nicely.

What we really see with Ruby (and I mean java devs in general) is its a nice enough short cut language but is it really all that the Java language gives us (coupled with the JVM)? And the answer (at least for now) is no, it does not.

Not to mention the fact that unless you're going to write unit tests until they come out your ears (not that I don't agree we should, only most do not or don't write then well enough) then you can never even be sure that your code would even stand up in production. Its a little scary for any java Dev manager to say yes to, which is where the buck really stops wrt this sort of shift.
13 Mar, 2010, flumpy wrote in the 16th comment:
Votes: 0
Runter said:
flumpy said:
We have our own dynamically typed language, thanks


It's called Groovy.

Kthxbah


I have nothing against Groovy. I have nothing against Java for that matter. :p

In fact, I'm glad to see any modern projects in the mudding community, and I consider yours to be one.


Btw thank you that was a very nice thing to say :redface:
13 Mar, 2010, Runter wrote in the 17th comment:
Votes: 0
Quote
What we really see with Ruby (and I mean java devs in general) is its a nice enough short cut language but is it really all that the Java language gives us (coupled with the JVM)? And the answer (at least for now) is no, it does not.


It's usually polite to avoid snarky language comments like these in forums devoted to said language. I'm not really sure if you're fishing for an argument or just upset by the notion that a java developer might actually learn a language other than java or its derivatives. In any event, needless to say, I disagree with this type of categorization of Ruby. You know, that it's a "nice enough short cut language." Particularly after the post David Haley made. Perhaps he should add that term to his black list. It's not exactly endearing. The fact of the matter is Ruby is powerful. It's not unreliable. It does some things well. It could improve on others. It's not fit for all projects. Ultimately it's worth exploring for people expanding their toolbox. I don't think anyone would suggest any language being a single solution and I didn't start this thread to start some (rather strange) language war. I simply was linking what I found to be a read with a few interesting slides.
13 Mar, 2010, flumpy wrote in the 18th comment:
Votes: 0
Sorry, by shortcut I didn"t mean to be derogatory, on the contrary it was meant to be a complement.

Some consider java to be very verbose (too much so in some cases) and I happen to be one of those people.

However, that said, you should not be surprised that by posting a slideshow about the merits of dynamic languages a discussion on the common views of said languages would occur… Remember I am not espousing My View, only the views I have come across as a general commentary about the subject.

We can stop if you like?
13 Mar, 2010, David Haley wrote in the 19th comment:
Votes: 0
flumpy said:
If you remember, java became popular initially because of it's C++ like syntax, and then really got going when it went server side - the JVM took enormous strides with speed and stability and also security (unrivalled I would say in the latter) so it would make sense to introduce a new language that gives the same warm fuzzy legacy feeling, which is where Groovy fits nicely.

You know, to be honest, you're basically the only person I hear talking about Groovy so much (or even at all). Most people I know who want to move away from the C++/Java camp are going to Ruby, Python, Lua, or similar. (Lua occupies a somewhat peculiar niche, and should really be considered separately from Ruby/Python.) I'm not saying that Groovy doesn't have the characteristics you say it does (honestly I simply don't know enough about it to comment appropriately) but for whatever reason it doesn't seem to be taking off as well-known language.

flumpy said:
Not to mention the fact that unless you're going to write unit tests until they come out your ears (not that I don't agree we should, only most do not or don't write then well enough) then you can never even be sure that your code would even stand up in production. Its a little scary for any java Dev manager to say yes to, which is where the buck really stops wrt this sort of shift.

Type safety doesn't guarantee that code would stand up in production either, to be honest. It helps, but it's hardly a guarantee. You (should) write unit tests with C++ and Java code as well, ne?



I'm also curious, like Runter, what exactly you mean by "nice enough short cut language". It seems strange to me to say such a thing. Where exactly are the shortcuts? Even if you don't mean it to be derogatory, I don't know what you mean.
13 Mar, 2010, flumpy wrote in the 20th comment:
Votes: 0
Well by shortcut I mean 3 lines of code to write out a file to disk instead of about 30.. I'm also typing on my mobile device and am trying to minimise finger cramps so sorry if I don't come over well, typing is hard on this thing!


I entirely agree about unit tests, but my point was about ppl either actually writing them and writing them well, which actually some java devs aren't really all that vigilant about.

Anyway, compile time checking like you say is a tool to help minimise error. So all I was trying to point out is that some people are used to this security blanket and need convincing to let it go, eg some dev managers
0.0/25