Help -- persuade my boss to adopt ruby

Hello Peter,

Tuesday, December 17, 2002, 12:52:08 PM, you wrote:

CPAN is a feature of the community, if befunge had its own CPAN library
then befunge would be be used more in corporate settings. There is
nothing about Perl that a multitude of languages can’t do and can’t do
better (I rather like SNOBOL and ICON).

i don’t know ICON but SNOBOL is even less structured than Perl. Perl is definitely
better for it’s niche

The phrase “features needed for corporate use” is weasel marketing speak
and the phrase “value propagation” only confirms it (and what on earth
is “accoutability” as a language featue). Just examine your list of
“features needed for corporate use” against the following languages and
see how many fall short on many criteria…

C/C++ Java COBOL FORTRAN LISP PASCAL BASIC Perl Python Tcl Forth

Then explain why they are used.

currently i feel that large projects need discipline, part of which is strong
(not “strict” :slight_smile: typing. that is why, i think, ruby can’t outperform java
in “bosses” minds

···


Best regards,
Bulat mailto:bulatz@integ.ru

Hi,

···

In message “Re: help – persuade my boss to adopt ruby” on 02/12/15, “Bulat Ziganshin” bulatz@integ.ru writes:

my point is that someone can’t fire managers which dont want to use
ruby. instead he must fire Matz because Matz don’t want to see at real
world ™. of course, it’s a lot easier and politically corect to say
about some abstract boss than about real Matz who read all these
“discussions”

Don’t fire me. It is a hard time for us, language designers.

						matz.

i feel that Ruby is not strict enough and can’t be compiled
for more or less fast execution.

I leave this argument to Matz and the core developers.

when i try to advocate these changes,
Matz says that Ruby is more or less a toy and he wants to find more
elegant ways to deal with these issues. beatiful! but on other side,
this gives us to the fact that Ruby will never steal Java place at
language racing

I’m not sure there is a real, palpable language race-- people generally use
programming languages because of either personal feelings/experience, or
hype, except in cases where special factors come into play (speed for
graphics,etc). But, if speed was the key to success, Java wouldn’t be a
market leader.

i don’n like the doublethinking i see here - when Ruby apologets says
“it’s not Ruby way” they must realize that in fact they say “wide
appreciation of language is not Ruby way”. Ruby will be a pure
language which seek for future language directions OR instrument for
Real Programmers - not both at the same time

This, of course, relies on the supposition that what you suggest is
technologically sound, and that the “Ruby Way” and success are mutually
exclusive due to some kind of incompatibility. I’ll leave the cracks and
crevices in this argument for someone else to pry open-- I’d like to think
that there’s programmers and companies out there with an ounce of vision.

Let’s not sacrifice Ruby on the altar of imagined commercial theory just yet.

~ Bruce

···

On Monday 16 December 2002 01:36 am, Bulat Ziganshin wrote:


Bruce R. Williams :: [iusris/#ruby-lang] :: http://www.codedbliss.com

‘It does not require a majority to prevail, but rather an irate,
tireless minority keen to set brush fires in people’s minds.’
– Samuel Adams

Hi,

java is “c++ better than c++” :slight_smile: and just in this role java conquered
the world. i say in my original posting about that type of use - ruby
can be used for large-scale, compiled applications, but Matz waits
that corporate America will go to the pure Ruby rather than adding
features which will drive Ruby to corporate world

I don’t understand what you mean at all.

Did “corporate America” ask me something that I refuse?

concrete, i feel that Ruby is not strict enough and can’t be compiled
for more or less fast execution. when i try to advocate these changes,
Matz says that Ruby is more or less a toy and he wants to find more
elegant ways to deal with these issues. beatiful! but on other side,
this gives us to the fact that Ruby will never steal Java place at
language racing

Did we envolved in the “langauge race” of any kind?
If Ruby steals the Java place, will it make any difference for me?
Remember no one but netlab.jp pays for me.

And finally, I couldn’t find good balance between Ruby’s goodness and
what-you-called-strictness. If you have any concrete feature
proposal, I’m always open, as long as feature-added Ruby still remains
being Ruby.

If your ideas hinders the “Ruby Way”, then go ahead, choose your
language, or even create your own one.

i don’n like the doublethinking i see here - when Ruby apologets says
“it’s not Ruby way” they must realize that in fact they say “wide
appreciation of language is not Ruby way”. Ruby will be a pure
language which seek for future language directions OR instrument for
Real Programmers - not both at the same time

  • wide appreciation is not my goal.

  • I believe it can be both at the same time, who proved it’s wrong?
    You? Notice being “instrument for Real Programmers” does not
    require wide appreciation.

  • parhaps your definition of “Real Programmers” is somewhat different
    from mine.

     					matz.
    
···

In message “Re: help – persuade my boss to adopt ruby” on 02/12/16, “Bulat Ziganshin” bulatz@integ.ru writes:

I have to disagree with this quote about XML. First, I don’t think
that XML can represent anything the human mind can conceive – it
imposes a particular way of thinking when attempting to represent
things which may not be conducive to representation of particular
concepts. (XML is a hierarchical data format; not everything can be
represented hierarchically.) XML also requires a lot of meta-data
and alternate “languages” to indicate the links between data, which
makes it very difficult to express the same information in multiple
ways.

The problem with a hierarchical data format is that it pretty much
requires that your data be able to be represented as a hierarchy,
and that enforces a single data query path (a la LDAP); you can’t
query efficiently in the opposite direction, or from the middle.

-austin
– Austin Ziegler, austin@halostatue.ca on 2002.12.16 at 07.37.02

···

On Mon, 16 Dec 2002 11:46:25 +0900, W. Kent Starr wrote:

XML may be a key enabling technology here. Another quote for your
collection, this one from Steve Litt (March 2001, Troubleshooting
Professional Magazine, Troubleshooters.com): “XML derives its
power from the fact that it can represent anything the human mind
can conceive.”

To the degree this observation is accurate, the potential is
mind-boggling. IMO opinion, within the specific domain of
programming, Ruby exhibits to a large degree these same
characteristics.

This is very much incorrect. It’s certainly possible to do things to
speed up the execution of dynamically typed languages, and there’s
been a lot of research into how. Ruby execution could, with the
appropriate amount of concentrated programmer talent thrown at it,
see speedups of an order of magnitude, perhaps two in some cases.
This is a very non-trivial thing to do, however, and something I
don’t think any single person, no matter how good, could pull off.
Give Matz four or five scary-smart people and a year and you could
see it. If you don’t have them, perhaps it would be best if you
backed off some, as it’s reasonably apparent you’re not sufficiently
familiar with the field to make a good judgement as to the problem or
its solutions.

Dynamic typing also has a number of advantages that make it better
suited for several classes of problems than a statically typed
language such as C or Java. The cost that dynamic typing imposes is
the price you pay for that better suitability–it’s an engineering
tradeoff like any other, as no feature is free.

···

At 3:36 PM +0900 12/16/02, Bulat Ziganshin wrote:

concrete, i feel that Ruby is not strict enough and can’t be compiled
for more or less fast execution.


Dan

--------------------------------------“it’s like this”-------------------
Dan Sugalski even samurai
dan@sidhe.org have teddy bears and even
teddy bears get drunk

Bulat Ziganshin wrote:

currently i feel that large projects need discipline, part of which is strong
(not “strict” :slight_smile: typing. that is why, i think, ruby can’t outperform java
in “bosses” minds

Strange how large projects succeed without this then. Discipline is not
a feature of the language and it never will be, it is a feature of the
programmer. A self-disciplined programmer will write good code in any
language but language features will not make a good programmer out of a
bad one. It is possible to write bad code in any language. Our large
projects are written in Perl with perltidy as our only (almost unused) tool.

The rest is programmer self-discipline, peer review and pride in our
work, no lanuage features will ever replace them or produce better code.

Time to stop trying to make the language fit some management fad and
start educating.

Bulat Ziganshin wrote:

currently i feel that large projects need discipline, part of which is strong
(not “strict” :slight_smile: typing.

I agree on the needing discipline, but the discipline is more related to
the development team than anything. Comments for the code, good docs for
the future maintainers, clean & readable code, peer review & verification.

that is why, i think, ruby can’t outperform java in “bosses” minds

Mmmm I’d disagree there, my limited experience has shown that what
bosses think tends to be more influences by hype (Java has been pushed
for years as a pen knife type language - Java can solve any problem)
than real knowledge or experience. Certianly none that I know could make
any “proper” descision based on the merits of Java or Ruby.

I often wonder how many other managers / bosses actually choose the
implementation language because they know off it and have heard “good
things” about it and how many actually choose based on a good knowledge
of languages and the problem space i.e. choosing the right tool for the
job.

Rob

Strong typing does not impose discipline, any more than language-
enforced formatting imposes discipline (e.g., Python). The people
who impose Java and Java-based solutions do not do so because of
strong typing (which isn’t necessarily the case anyway[1]), but
because of strong marketing and strong-arming. The same applies to
C#.

Java has its place, and there’s a lot of work that has been done
around enterprise-class work (e.g., J2EE and EJB), and I suspect
that if Ruby could come up with a way of managing some of those
things (e.g., being a EJB container or interacting with EJBs in
predictable ways), then it would gain in the same space that Java is
gaining. But this isn’t a core language feature (not really), but a
library. It’s also already sort-of possible with JRuby (and there is
that legal bugaboo of a licensing issue where it’s not yet non-GPL
and therefore enterprise unfriendly, especially given RMS’s
statements regarding dynamic linking – as incorrect as they are).

-austin
[1] I could make all parameters types of java.lang.Object and use
reflection and introspection to test for response to a
particular method and then do things that way. There goes all
that strong typing in Java …

– Austin Ziegler, austin@halostatue.ca on 2002.12.17 at 08.02.14

···

On Tue, 17 Dec 2002 19:17:34 +0900, Bulat Ziganshin wrote:

currently i feel that large projects need discipline, part of
which is strong (not “strict” :slight_smile: typing. that is why, i think,
ruby can’t outperform java in “bosses” minds

Hello Bruce,

Monday, December 16, 2002, 9:57:57 AM, you wrote:

i don’n like the doublethinking i see here - when Ruby apologets says
“it’s not Ruby way” they must realize that in fact they say “wide
appreciation of language is not Ruby way”. Ruby will be a pure
language which seek for future language directions OR instrument for
Real Programmers - not both at the same time

This, of course, relies on the supposition that what you suggest is
technologically sound,

real conversation was smth like:

  • please add optional type-checking to the language
  • no, i like to add method checking instead
  • this don’t allow COMPILE-TIME verification of program and don’t allow
    COMPILATION to fast static code. so please add optional type-checking, which
    is proven technology working last 30 or 40 years
    - it’s not Ruby Way! we want to go BESIDES existing languages, not TO them
    - i will wait for some new decision to this problems, please wait

ok. i wait. and with me wait all the corporate world. all looks up Matz and listen
for his Decision :)))

···


Best regards,
Bulat mailto:bulatz@integ.ru

Hello Yukihiro,

Monday, December 16, 2002, 10:24:48 AM, you wrote:

Did “corporate America” ask me something that I refuse?

can me and William Djaja Tjokroaminata say instead of them? :slight_smile: read:

concrete, i feel that Ruby is not strict enough and can’t be compiled
for more or less fast execution.

And finally, I couldn’t find good balance between Ruby’s goodness and
what-you-called-strictness. If you have any concrete feature
proposal, I’m always open, as long as feature-added Ruby still remains
being Ruby.

i see process of development of large application as prototyping w/o
type declarations, then “freezing” interfaces and adding
type-checking, pre- and post-conditions, huge comments and so on. then
process is repeated on a module-by-module basis

this is close to process used for C++/Java now and on this way i will
feel that our Ruby programs are better in all senses than programs
coded in old languages. only alternative to type checking i know is
unit testing but i don’t have feeling whether it will be definitely
more reliable (and this leaves problem of fast execution to some other
mechanism)

in my experience, static typing is appropriate for 90% of function
prototypes/variable declarations and this is the common idiom used
even by Ruby developers (see Array. or Date.<=> for example - these
checks for types, not methods supported by object)

···


Best regards,
Bulat mailto:bulatz@integ.ru

The problem with a hierarchical data format is that it pretty much
requires
that your data be able to be represented as a hierarchy, and that
enforces a
single data query path (a la LDAP); you can’t query efficiently in the
opposite >direction, or from the middle.

I don’t see what the problem is as long as you have ways to refer to the
same tag. That way you can have multiple, overalapping heirachies.

The thing that gets my goat about XML is that it is just a way to
persist structured information, whether it be data or meta-data. Big
deal. It seems a whole mass of the development community have just
woken up to the beauty of object models and meta-models. DOH!? It’s
just a shame that they haven’t chosen a better way to communicate them.
Give me UML-on-a-whiteboard any day . Anyway YAML + Ruby is the future!

Rusty

···

Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.427 / Virus Database: 240 - Release Date: 06/12/2002

Hello Dan,

Monday, December 16, 2002, 11:59:25 PM, you wrote:

concrete, i feel that Ruby is not strict enough and can’t be compiled
for more or less fast execution.

This is very much incorrect.
This is a very non-trivial thing to do,

yes, i mean exactly that

Dynamic typing also has a number of advantages that make it better
suited for several classes of problems than a statically typed
language such as C or Java. The cost that dynamic typing imposes is
the price you pay for that better suitability–it’s an engineering
tradeoff like any other, as no feature is free.

i think that 90% of declarations may be statically typed and this give more
robust and self-commenting code. deciding which types will be appropriate
here is just a kind of deciding which interfaces we will use

please see at Array docs. in overloaded functions one just writes what
we need a String or a Range here, not that you must supply any object
with given semantics

···


Best regards,
Bulat mailto:bulatz@integ.ru

Hello Peter,

Tuesday, December 17, 2002, 1:52:43 PM, you wrote:

currently i feel that large projects need discipline, part of which is strong
(not “strict” :slight_smile: typing

Our large
projects are written in Perl with perltidy as our only (almost unused) tool.

The rest is programmer self-discipline, peer review and pride in our
work, no lanuage features will ever replace them or produce better code.

i don’t think that perl is appropiate for large projects. maybe i must buy some more brain
to give perl more chances :slight_smile:

···


Best regards,
Bulat mailto:bulatz@integ.ru

I often wonder how many other managers / bosses actually choose the
implementation language because they know off it and have heard “good
things” about it and how many actually choose based on a good knowledge
of languages and the problem space i.e. choosing the right tool for the
job.

Rob

I don’t disagree, but I submit that managers often have real concerns that we
don’t have much sympathy for. That doesn’t make their concerns any less real,
and some of their concerns are probably justified.

They are undoubtedly affected by hype, but that doesn’t mean that their
reluctance to use Ruby is entirely baseless. It’s a shame, and I’m sure it
will change, but Ruby will have to change as well. (I’m not advocating
anything radical here, nor anything specific, just gentle evolution.)

Ruby compares very well with Perl in many/most ways, we all know that. It’s
probably a stand-in replacement now, when you trade the number of libraries in
Perl for the ease and elegance of Ruby.

Gavin

···

From: “Robert McGovern” robertm@spellmanhv.co.uk

currently i feel that large projects need discipline, part of
which is strong (not “strict” :slight_smile: typing. that is why, i think,
ruby can’t outperform java in “bosses” minds

Strong typing does not impose discipline, any more than language-
enforced formatting imposes discipline (e.g., Python). The people
who impose Java and Java-based solutions do not do so because of
strong typing (which isn’t necessarily the case anyway[1]), but
because of strong marketing and strong-arming. The same applies to
C#.

It is often said that Java makes it difficult to write bad code. It sort of
forces everyone to use a similar - incredibly dull - style. The string typing
definitely imposes some discpline. It disallows you from doing all the dodgy
things that Ruby lets you do :slight_smile: It’s like a seatbelt. Even smart programmers
like this safety sometimes because they don’t trust the self-imposed discipline
of their colleagues. In this way, Java’s blandness is a blunt tool for project
management. Dumb-arse managers (not implying they’re all like that) then get
this mindset that all Java programmers are replaceable because the language is
so “easy”… but I digress.

Like so many comments in this thread about the supposed competitiveness (or
superiority) of Ruby compared to everything else and in every way, your point
about bondage and discipline not actually being related is high on theory but
barely registers with my experience. The world is not full of smart
programmers.

[…]
-austin
[1] I could make all parameters types of java.lang.Object and use
reflection and introspection to test for response to a
particular method and then do things that way. There goes all
that strong typing in Java …

You could but you don’t. There, with respect, goes that argument. It is more
pertinent to point out the absense of type-safety in collections, but even then
things crash (ClassCastException) immediately rather than possibly executing
unintentional methods (or method_missing). Type “safety” cannot be discarded:
it is designed so the compiler catches errors, which can be handy in a large
project (even if only to remind you of your intention sometimes). It’s just
that the bondage and discipline involved is counter-productive, and we all love
Ruby’s point of difference here.

Gavin

···

From: “Austin Ziegler” austin@halostatue.ca

On Tue, 17 Dec 2002 19:17:34 +0900, Bulat Ziganshin wrote:

Hi, Dan.

Ruby execution could, with the appropriate amount of concentrated
programmer talent thrown at it, see speedups of an order of magnitude,
perhaps two in some cases. This is a very non-trivial thing to do,

This is a really interesting statement to me, mostly cause I don’t think
that I’d have the talent to do it!

Where would you start? Speeding up the syntax tree? Moving to byte-code
and then optimising the op-codes? Take a structure-by-structure approach
and refine?

If it is really non-trivial, which I believe it would be, when do you say
that it is better to start again? (Which is rite, right?)

Regards,

-mark.

···

At 05:59 AM 12/17/2002 +0900, Dan wrote:

Hello Austin,

Tuesday, December 17, 2002, 4:09:55 PM, you wrote:

[1] I could make all parameters types of java.lang.Object and use
reflection and introspection to test for response to a
particular method and then do things that way. There goes all
that strong typing in Java …

but noone do it. so, when language provide optional strong typing,
explicit type specifications will be used in most cases

···


Best regards,
Bulat mailto:bulatz@integ.ru

From: Austin Ziegler [mailto:austin@halostatue.ca]
Sent: Monday, December 16, 2002 5:42 AM
To: ruby-talk ML
Subject: Re: help – persuade my boss to adopt ruby

XML may be a key enabling technology here. Another quote for your
collection, this one from Steve Litt (March 2001, Troubleshooting
Professional Magazine, Troubleshooters.com): “XML derives its
power from the fact that it can represent anything the human mind
can conceive.”

To the degree this observation is accurate, the potential is
mind-boggling. IMO opinion, within the specific domain of
programming, Ruby exhibits to a large degree these same
characteristics.

I have to disagree with this quote about XML. First, I don’t think
that XML can represent anything the human mind can conceive – it
imposes a particular way of thinking when attempting to represent
things which may not be conducive to representation of particular
concepts. (XML is a hierarchical data format; not everything can be
represented hierarchically.) XML also requires a lot of meta-data
and alternate “languages” to indicate the links between data, which
makes it very difficult to express the same information in multiple
ways.

For what it’s worth, XML, through the use of id and idref attributes, can
break out of strictly hierarchical formats. Granted, though, that the more
intuitive nature of XML is to represent data as trees.

The problem with a hierarchical data format is that it pretty much
requires that your data be able to be represented as a hierarchy,
and that enforces a single data query path (a la LDAP); you can’t
query efficiently in the opposite direction, or from the middle.

I’m not really sure how even the use of idrefs helps with, say, XPath
queries in arbitrary directions. There are, though, XPath functions for
locating parents and siblings.

One is free to slurp the XML into whatever in-memory representation is
useful, and manipulate that object directly, forgetting that the data source
was ever XML. (Computer memory is sequential, yet developers don’t feel
that all data types must be linear. Interpretations are layered over the
physical data format.) This decoupling from fixed data types is one of the
things I like best about XML; it’s conceptually similar to dynamic typing in
Ruby.

Still, XML has been ultra-hyped (though often misunderstood) to the point it
makes my head spin, and that opening quote is a bit much.

James

···

-----Original Message-----
On Mon, 16 Dec 2002 11:46:25 +0900, W. Kent Starr wrote:

-austin
– Austin Ziegler, austin@halostatue.ca on 2002.12.16 at 07.37.02

Hi,

Did “corporate America” ask me something that I refuse?

can me and William Djaja Tjokroaminata say instead of them? :slight_smile: read:

I didn’t know you (and him) representing it.

i see process of development of large application as prototyping w/o
type declarations, then “freezing” interfaces and adding
type-checking, pre- and post-conditions, huge comments and so on. then
process is repeated on a module-by-module basis

this is close to process used for C++/Java now and on this way i will
feel that our Ruby programs are better in all senses than programs
coded in old languages. only alternative to type checking i know is
unit testing but i don’t have feeling whether it will be definitely
more reliable (and this leaves problem of fast execution to some other
mechanism)

in my experience, static typing is appropriate for 90% of function
prototypes/variable declarations and this is the common idiom used
even by Ruby developers (see Array. or Date.<=> for example - these
checks for types, not methods supported by object)

Ah, they are “dynamic” type checking. I don’t think it’s what you
want. Changing a language costs far higher than switching a language.
Why do you waste your time trying to change Ruby? Just switch to
Java, C#, or even ML, if you want static typing.

I feel like, compile time type checks would not work effectively with
“optional” type checks along with object-oriented method redefining.
By optional type checking, only dynamic type check can be done at most.
To accomplish compile time type checking, I have to change Ruby
completely, and the result would be “yet another Java-like language”,
which won’t survive long. I know for sure.

Prove I’m wrong. Ruby is opensource. You can hack it as much as you
want.

						matz.
···

In message “Re: help – persuade my boss to adopt ruby” on 02/12/16, “Bulat Ziganshin” bulatz@integ.ru writes: