Ideas on "Why Living Dangerous can be A Good Thing" in Ruby?

[Peter Wright]

Though that's funny, I really think it was part of the plan for
Java. They made no attempt to make doing it convenient or useful
(though that can be said for a lot of Java things), which is part of
the way they can discourage developers from being 'wild and crazy'

....which is all part of the appealing-to-management[0] concept of
programmers as being generic-and-replaceable cogs in the project
development wheel.

If programmers have too much (ie. any) ability to be "wild and crazy"
(== creative), that could be considered as dangerous to project
"integrity".

Of course, the sad thing is that there's some truth in that. And much
like knowledge, a little truth (especially when taken out of context)
is a dangerous thing.

That's true. We are really addressing the illusion of security. Or
at least a superficial level of security. I think a lot of people
are just scared by how damn convenient and common such practices are
in Ruby, even if their language is capable of doing similar things.

I think it's part of the old no-such-thing-as-a-free-lunch notion.
Some people (and they're not necessarily stupid people) have trouble
with a concept like "Ruby is just a better and more powerful language
than Java". They presume that there _has_ to be a cost for that extra
power.

And the idea that you pay for extra power by losing "safety" (whatever
"safety" means in this context) is a seductive one, because it has so
many physical-world parallels. Though it's dreadfully simplistic at
best (and just plain wrong at worst).

So... just about any management will read "increasing power" as
"losing safety" which translates to "increasing _risk_" and
INCREASING RISK IS BAD so no Ruby/Python/Smalltalk/Lisp for you,
heathen. Get back to being an indistinguishable cog in the low-risk,
industry-best-practice[1] Java machine!

Ahem. Not that I'm venting or anything.

Pete.

[0] I know, I know. Not _all_ managment. But definitely some.

[1] Where industry-best-practice => what-everyone-else-is-doing
=> if-everyone-else-is-doing-it-I-can't-be-blamed-if-it-fails-,
because-I-didn't-choose,-the-_industry_-did.

 

[Jonas Hartmann]

Gregory Seidman wrote:
...

3) duck typing allows unintended objects to be used in unintended ways

4) the ability to add/replace methods in existing classes allows library
internals to be inspected or modified

Also I consider myself a bad programmer I want to share my opinion on this:

4) is about social security. the private and protected stuff I know of java and all those things enable the tool language to be used by management to enforce devision of work.

the management and team leaders can create a work model and thus can set define who is responsible for what within the tools of work - the programming language.

this opens a discussion I cannot join cause I am not working in larger companies with high distances between management and workers (=programmers).

I think what java (and possible c++, but i don't know) offers can be archived in another way - but well, not by using ruby itself. Further I think it is the wrong place to implement such "security" features in work processes cause it can HINDER and reduce efficiency, creativity, output. I think working with a modular application model in mind may solve this. If you got commercial software written by software giants (this is where, i think, these "security" models, added onto the object-orientation-model cause it was just possible, apply) you can instead of taking your time to develop and implement a language-side "security"-model take your time and specify interfaces between parts, modules, of your software. different teams will work on different modules then which will run in different VMs communicating via inter process messaging or via databases for example.

maybe my view is very narrow, but well, maybe it helps.