I’d like to see a serious enterprise-grade SOA framework that is either
written in an agile language or supports them well. Doesn’t matter if
it’s
Ruby or Python. Python’s Twisted has PB, but it’s several steps short of
what is really needed. Ruby has nothing close yet.
On 6/6/06, ReggW [email protected] wrote:
Austin Z. wrote:
On 6/6/06, ReggW [email protected] wrote:
Just like most open-source zealots, when presented with the facts you
change your story.
You really don’t want to take that attitude with me.
Why…are you going to beat me up?
Oh, good god. Once again, ruby-forum demonstrates its that it’s the
cess-pit of Ruby users.
No, Regg, I’m not going to “beat you up.” You don’t want to take that
attitude with me because you’re going to alienate me (and probably
others) from wanting to help you. Based on your responses, it seems
that you think that it’s your god-given right to have the
functionality you need in an open-source mostly-volunteer project.
Guess what: you don’t. You sometimes have to pay for what you need.
And sometimes, just sometimes, you can’t even do that. (I have had
people offer to pay me to do certain features on PDF::Writer. I have
appreciated the offers, but I don’t have time to work on PDF::Writer
right now because of a lot of reasons, but I’ll have time later and
I have my own priorities with PDF::Writer.)
-austin
It’s similar to the complaint that Ruby does not have an IDE such as
Eclipse; some Rubyists argue that there isn’t one because there is no
compelling need for it, as there is in Java.
Apologies for the rant, but…
On Jun 6, 2006, at 9:52 AM, Francis C. wrote:
I’d like to see a serious enterprise-grade SOA framework that is
either
written in an agile language or supports them well. Doesn’t matter
if it’s
Ruby or Python. Python’s Twisted has PB, but it’s several steps
short of
what is really needed. Ruby has nothing close yet.
Having worked with a number of “enterprise-grade SOA frameworks” I
think the best available one, by a long shot, is HTTP and and a good
glue language (Perl is the most common, Ruby is moving way faster
though). (2)
A realistic SOA framework is a set of state transfer idioms and
protocols which will be adhered to as best as possible across
languages, platforms, and applications. The most useful set of
guidelines for this which I have seen as an implementor (NOT as a
vendor) is Roy Fielding’s thesis. (1) I believe that a push model is
also important, but for that we have no good solution yet, in any
language, for any platform.
This is all completely language independent. In my experience the
tools and systems which have tried to create a super-high level
language for integration/SOA have pretty much been abysmal failures,
and the folks embracing protocol based and idiomatic integration at a
lower level have met with lots of success. This is, of course a
generality, but the correlation is very high based on the data
available to me.
One big problem seems to be that, by and large, when people are
shopping for an SOA framework they are looking for way to make non-
programmers (in which category I include incompetent programmers)
into useful programmers. This is all well and good, but training and
protocol understanding, not tooling to abstract the solution away
form the problem, is a much more fruitful path.
This is not to say the building these systems is simple with
protocols and glue, and that sophisticated tools are not useful, but
that the sophisticated tools which are useful are generally the ones
which embrace the wire protocols and data idioms rather than hide
them. Point of reference, mod_rewrite has done more good for
distributed systems than all of WS-* in its entirety or any of its
parts.
My 2p =)
-Brian
-
Architectural Styles and the Design of Network-based Software Architectures
-
For the enterprisey folks out there, JBI based tooling, and its
competitors in the programming standards space (SCA, Indigo, ???),
when the API’s are used directly, is HTTP with a set of idioms glued
on top and a mediocre to poor glue language. When drag and drop is
used to generate Java/C# by folks who don’t know what an idempotent
method is, it is generally borkage.
On Jun 6, 2006, at 1:01 PM, Peter E. wrote:
It’s similar to the complaint that Ruby does not have an IDE such as
Eclipse; some Rubyists argue that there isn’t one because there is no
compelling need for it, as there is in Java.
RadRails is for Rails, but it uses RDT which is the ruby toolkit that
can be downloaded separately:
Both RDT and RadRails rock. I use them daily.
-Mat
On Jun 6, 2006, at 1:54 PM, James B. wrote:
Java, then that’s quite slick.
To clarify, code completion is a bit limited, but works. Refactoring
appears to be non-existent in the current release, the I get by
pretty well with Eclipse’s search and replace features.
-Mat
Mat S. wrote:
On Jun 6, 2006, at 1:54 PM, James B. wrote:
Java, then that’s quite slick.
To clarify, code completion is a bit limited, but works. Refactoring
appears to be non-existent in the current release, the I get by
pretty well with Eclipse’s search and replace features.
-Mat
I can’t get any code completion to work with RadRails.
This is the ONLY thing that RadRails really needs, and it would be the
best Ruby/Rails IDE available.
I think JEdit has the best code completion, but it lacks the rails
features of RadRails and the ProjectViewer plug-in doesn’t bring your
entire project directory structure from the hard drive.
Anyway, RadRails is almost the best IDE.
Peter E. wrote:
It’s similar to the complaint that Ruby does not have an IDE such as
Eclipse; some Rubyists argue that there isn’t one because there is no
compelling need for it, as there is in Java.
I thought that was focused on Rails, and did not do automatic
refactoring or code completion.
But if it works for general Ruby the same way as Eclipse works for Java,
then that’s quite slick.
–
James B.
http://www.ruby-doc.org - Ruby Help & Documentation
Ruby Code & Style - The Journal By & For Rubyists
http://www.rubystuff.com - The Ruby Store for Ruby Stuff
http://www.jamesbritt.com - Playing with Better Toys
http://www.30secondrule.com - Building Better Tools
Francis C. wrote:
Ruby is the only programming language I know that (for specific reasons
inherent in the design of the language) has some potential to
challenge the
prevailing wisdom among businesspeople who manage IT projects. Which, to
oversimplify, is that a large problem requires something at least
resembling
a large team. I’m eliding some of the logical steps, but this entrains
much
of what you and others (with some justification) criticize as
backside-covering.
Well … I suppose it depends on how you define “large problem”. Let’s
assume, for example, that you have a well-behaved business problem whose
natural solution algorithm uses resources that grow no faster than N log
N, where N is the size of the inputs. A prototypical such problem is
sorting.
That may be a large problem, given, say, trillions of records to sort
through. But it does not require a wide variety of domain expertises,
and as far as I can tell is no easier in Ruby than in any other
language, including some very old ones.
In the scientific realm, consider the problem of hurricane forecasting.
Again, there isn’t a wide variety of domain expertises required,
although just about everybody understands sorting and not just about
everybody understands partial differential equations and atmospheric
physics. This is also a problem for which it is highly unlikely that a
Ruby solution would be proposed.
So there are two examples of large problems which would not necessarily
require a large team. I’m sure there are numerous others – Google has a
solution to one of them at its core.
I think perhaps you’re mistaking “large team required” with “non-agile
process required” and unconsciously linking agile processes with Ruby.
I’ve seen a lot of programming languages, both general purpose and
special purpose, and I guess I’m not convinced that Ruby is the “best”
general purpose language, or even significantly “better” than, say,
Java, Ada, or even Common Lisp.
actually consider doing it in Ruby.
Pure Ruby, or Ruby plus Rails plus all of the other tools that have
sprung up from Ruby? And what about .NET?The best Ruby programs are small ones. This is wired into the
genetics, and
the aesthetics, of the language. But small Ruby programs can be
remarkably
powerful, in ways that can fundamentally change the dynamics of software
production. If this point can be made by powerful and eloquent advocates
then Ruby may become a much more widely used language.
I don’t think this is true only of Ruby. Small, elegant solutions to
problems can be powerful in quite a few other languages. The ones that
spring to my mind right now are Lisp, Forth, APL, R and SmallTalk. And
one other that probably doesn’t spring to many minds except my own these
days – macro assembly language.
And I can think of languages where it isn’t true – Fortran, C, COBOL
are the obvious ones. And then there are “borderline cases” – Perl and
Java are the two that I know of. I don’t know enough Python or PHP to
classify them.
But so much depends
on the goals one chooses to pursue. Many committed Rubyists have
stated many
times that Ruby should not have widespread adoption by business as a
goal.
(Perhaps underneath this, there is fear that success would corrupt Ruby’s
essential character. If so, that’s a topic for another thread.) But this
does explain why the Ruby community has so few powerful and eloquent
advocates.
I wonder if a language can “have a goal”. Ruby, like some other
languages, is a community that sprung up around a creative force, in
this case Matz. Perl sprung up around Larry Wall, Lisp around John
McCarthy, APL around Ken Iverson and Forth around Chuck Moore.
John McCarthy’s goal was to create a computer that could take advice.
Chuck Moore’s goal was to write a lot of programs in a compact way. Ken
Iverson’s goal was to bring the tools of mathematical formalism to
programming. As far as I know, none of them – Larry Wall and Matz
included – had as a goal getting rich, or world domination, or creating
the “best” computer language.
I think Ruby does have powerful and eloquent advocates. I’m just not
sure they are advocating Ruby so much as they are advocating agile
processes, metaprogramming, domain-specific languages, “duck typing”,
dynamic languages, and, of course, Rails. 
–
M. Edward (Ed) Borasky
Phil T. wrote:
It may be years before you know if you’ve made the ‘right’ choice.
If you do happen to choose ‘wrong’ (whatever that might mean for you)
you can always go back and learn another language(s). It’s not like
you’re locked into some binding contract or something.
I’ve lost count of how many times I made the wrong choice of language. I
don’t regret the learning I’ve taken from macro assembler, Lisp, APL,
Forth or Java. But I made money programming in Fortran, Perl and R. So
…
–
M. Edward (Ed) Borasky
Hector wrote:
I’m at a point where I’m asking myself if it is worth the trouble for me
to learn Ruby. How many people are really writting Ruby? Are there any
truly robust, good applications being written in Ruby? How well are Ruby
libraries being maintained? I know there is a lot of documentation for
Ruby but I find it hard to find very specific docs. Python seems to have
a whole lot more doc and many more books exist for Python. Does Python
have a greater following. I love Ruby but I don’t want to waist my time
with a laguage that may not have a future.
I downloaded Ruby at monday. Today I’m creating fxRuby application with
MySQL backend and everything works fine :-)… BUT I think that Ruby
resources (docs, external modules like MySQL and others) are very very
scattered.
Large problems: you’re playing word games with me. “Large” has many
meanings. Two that are germane to my point are: information systems with
an
extremely long anticipated lifetime (meaning that it’s unwise to expect
the
original developers to stay committed to it), and systems that cut
across a
large number of knowledge domains in a single organization (meaning you
can’t leverage the expertise of a world full of developers). A lot of
resources go into solving problems that are understood along these
lines,
and a lot of those resources get wasted. THAT is a problem that’s worth
solving. Ruby could be part of the solution, if more of the community
were
interested in the problem.
Advocacy: you make a compelling point that the advocacy around Ruby is
part
of the more general enthusiasm for agile development and dynamic
languages.
Well and good, so long as your focus is on computer programs as
beautifully-crafted artifacts. But this advocacy is largely meaningless
several steps higher, where decisions are made about which computer
programs
to fund the development of. A different kind of advocacy is required
there,
and it’s becoming clear to me that Ruby advocacy probably doesn’t belong
at
that level. The original topic of this thread was Ruby’s future. It may
be
that Ruby’s future is all about projects that are undertaken for love,
not
money. And there’s nothing wrong with that.
Francis C. wrote:
and a lot of those resources get wasted. THAT is a problem that’s worth
solving. Ruby could be part of the solution, if more of the community
were
interested in the problem.
As in “Enterprise Integration With Ruby?” Yeah … I probably write what
you’d call “enterprise integration” but what I call “glue logic” in
Perl. That’s mostly because I learned Perl 4 about ten years ago and
haven’t needed anything better, except for math, where I have R. But I’m
a “domain expert” in performance engineering, monitoring, analysis, etc.
– at least that’s my role at present. Nobody would ask me to write a
web application. If they did, it would undoubtedly be in either .NET or
PHP, not Ruby.
Long lifetimes … is that air traffic control system from the late
1960s still up and running? The one that was written in System\360
Assembler, PL/I and probably some other languages? Is Chuck Moore’s Kitt
Peak Forth code still driving that telescope? Has NASTRAN been ported
from Fortran to some more “modern” language?
Resources wasted? That’s a “fundamental law of nature” having to do with
large teams starting to exhibit behavior reminiscent of gas dynamics. I
don’t see how Ruby changes the realities of large teams, any more than
any other “magic bullet” has in the 44 years I’ve been programming. If
the “Ruby community” isn’t interested in that problem, more power to
them!
there,
and it’s becoming clear to me that Ruby advocacy probably doesn’t
belong at
that level. The original topic of this thread was Ruby’s future. It
may be
that Ruby’s future is all about projects that are undertaken for love,
not
money. And there’s nothing wrong with that.
Yeah … Ruby is certainly a beautifully-crafted artifact. It’s perhaps
more complicated than it needs to be, especially when you compare it
with the stark simplicity of Lisp, Forth or LIW microcode. Any language
with “lambda” is OK in my book.prevailing wisdom among businesspeople who manage IT projects.
N, where N is the size of the inputs. A prototypical such problem is
everybody understands partial differential equations and atmospheric
special purpose, and I guess I’m not convinced that Ruby is the “best”
dream of
the aesthetics, of the language. But small Ruby programs can be
days – macro assembly language.
goal.dynamic languages, and, of course, Rails.
–
M. Edward (Ed) Borasky
–
M. Edward (Ed) Borasky
Francis C. wrote:
and he
doesn’t particularly care either.
When I was one of those “magical crazy people”, the choices were fewer.
And almost invariably the magical crazy people programmed in assembly
language whenever they could. Hardware was expensive, compilers sucked,
machines were slow and had limited memory.
Because of changing economics, programming language may not matter as
much as it used to, but I think today’s magical crazy people probably,
if they had their druthers, would program in … (pregnant pause) … C.
At least the compilers don’t suck any more.
–
M. Edward (Ed) Borasky
On Jun 6, 2006, at 5:25 PM, ReggW wrote:
This is the ONLY thing that RadRails really needs, and it would be the
best Ruby/Rails IDE available.I think JEdit has the best code completion, but it lacks the rails
features of RadRails and the ProjectViewer plug-in doesn’t bring your
entire project directory structure from the hard drive.Anyway, RadRails is almost the best IDE.
You may want to check your settings, then just hit you completion key
on a blank line and see if anything comes up. I get a whole slew of
things. But as often the case for dynamic typing, it’s not always
relevant to the variable I’m dealing with.
I’m on RDT 0.8.0.604272100PRD, RadRails 0.6.3.
-Mat
If I have a quoted symbol, i.e. :‘some symbol’ then when I dump the
YAML for it and then load the results I don’t get back the symbol I
put in, but get an extra set of escaped quotes. The following irb
session shows this:
irb(main):014:0> YAML.dump(:‘some symbol’)
=> “— :“some symbol”\n”
irb(main):015:0> YAML.load("— :“some symbol”\n")
=> :"“some symbol”"
irb(main):016:0> YAML.load("— :“some symbol”\n").class
=> Symbol
~> ruby -v
ruby 1.8.4 (2005-12-24) [powerpc-darwin8.6.0]
I was a bit surprised it wasn’t using something like
ruby/symbol ‘some symbol’
to do the encoding.
Dave.
On Jun 7, 2006, at 6:25, Francis C. wrote:
resources go into solving problems that are understood along these
lines,
and a lot of those resources get wasted. THAT is a problem that’s
worth
solving. Ruby could be part of the solution, if more of the
community were
interested in the problem.
I think it’s important to remember that you’re talking about a
distinct class of businesses; businesses that are too big and varied
to buy off-the-shelf software, but who aren’t involved in full-time
software development (and either staff-up or contract-out as needed
on a project-by-project basis). It’s a very large class of
businesses, I admit, quite likely it’s the large majority of the
available market for programmers, but it’s not all businesses, which
will be important later on.
In any case, it’s interesting that you think these are problems which
are solvable via language design (or by a particular language). If
you ask me, they’re problems of management; I’ll split up my analysis
below.
1: long lifetimes.
For small values of “long” (say, 5-10 years, though this will vary by
domain) the language will have some impact - languages which
encourage self-documentation will have a slight advantage over
languages which don’t, given similar standards and practices within
the organisation, but it’s those standards and practices which will
have the largest impact. This is a problem of management and
engineering, the realm of specifications and documentation and
requirements; it’s essentially language-agnostic.
For medium values of long, your implementation is going to become
obsolescent, especially if you don’t periodically renovate/
reimplement it. I expect this to be less of an issue between now and
2030 than it was, say, between 1975 and Y2K, but I believe there’s a
very solid economic reason to that obsolescence is the norm (which
I’ll briefly discuss below), regardless of your choice of language.
For big values of long - your guess is likely as good as mine, but
I’d pick Lisp. Four decades and still going strong.
2: organisation-specific knowledge.
Again, this is primarily an issue of management; it includes system
design and specification, organisational history, and also the
retention of those individuals who incorporate that knowledge. If
those processes fail, there’s little that the choice of language can
do to compensate for that.
required there,
and it’s becoming clear to me that Ruby advocacy probably doesn’t
belong at
that level.
And there’s the big disconnect: management decisions are made for
economic reasons, not purely technical ones, and there are big
economic factors throwing their weight around:
First: [Freely-available] Computer languages and their associated
libraries approximate public goods (I am aware of theoretical nits
that might be picked with this assertion). From a business
perspective, they represent a positive externality; businesses
benefit from the production of these goods (“language design”) while
contributing little to it. Typical profit-motivated businesses
either can’t afford or wouldn’t be willing to fund language design
simply to support their own projects, they instead rely on
individuals with significantly different economic motivations to
design these languages and libraries.
The catch is that unlike typical examples of beneficial externalities
in business (e.g. the road network), languages can change at a pace
faster than or comparable to the business itself. This is one reason
why projects tend towards obsolescence: current languages evolve,
their libraries change, deprecation ensues (Java), some fall out of
fashion (COBOL, Fortran), new languages are created (Perl, Python,
Ruby), some come back into fashion (Lisp), and so on. In the
maintenance phase of its life-cycle, your system is essentially
static with respect to this churn. Without a direct involvement in
the process of language design - which the typical business doesn’t
pursue - the odds are very much higher that your system will be left
behind.
The second big economic gorilla is the fact that for a certain type
of production - into which most ‘enterprise’ software falls - profit
is maximised at the expense of efficiency. If someone using
technically-sophisticated methods to accomplish a project should
leave, the cost of replacing them (basically, the time it takes to
find someone with equivalent knowledge + the time it takes the
replacement to get up to speed with the existing work/start over) is
quite high, but such methods are more efficient and will get the job
done faster. On the other hand, it’s easier to replace people
working using less sophisticated methods, but such methods are less
efficient and the project will take longer.
Accounting for this risk/efficiency trade-off, profit ends up getting
maximised somewhere in the middle of the efficiency spectrum - a
middle currently occupied quite comfortably by Java and .NET.
“Business acceptance” in this regard is highly correlated to ‘dumbing-
down’ the language to make it more suitable for less-skilled (rather,
de-skilled) labour.
The original topic of this thread was Ruby’s future. It may be
that Ruby’s future is all about projects that are undertaken for
love, not
money. And there’s nothing wrong with that.
You may be right, but I’m willing to bet that you’re only right
insofar as you mean your money.
The economic motivations of businesses mentioned above are often
contrary to the economic interests of the programmers they employ.
Where businesses have a motivation not to invest in the production
of public goods such as languages and libraries, programmers do have
such motivation; both in a higher value on non-monetary reward
(typical in particular of language developers), and as a method of
ensuring that they don’t have to pay to practice their trade[1].
Where businesses have a motivation towards average, simple systems,
programmers (on the whole) would prefer working on interesting and
sophisticated ones, again both for monetary reasons (better pay or
the strong likelihood of better pay in the future) and non-monetary
ones (intellectual stimulation and less chance of terminal ennui in
the future).
Recent changes in the programming industry have meant that
programmers can now pursue their own economic interests more freely,
instead of relying upon “business acceptance” for economic security
(and the associated compromise of their own interests).
Opportunities to pursue technically-sophisticated projects have grown
enormously: from Google’s Summer of Code to a few paid hours a week
at your usual job to contribute to an open-source project, to grants
and full-time employment on open source projects. In the private
sector, Google, Microsoft, NTL, and IBM all have well-funded and
diverse research divisions. I’d say that even academic opportunities
are improving (this is harder to quantify, since it occurs over
longer periods, though certainly industry-associated funding is
rising). It’s feasible to say that this class of businesses has
benefited from aligning their interests with the programmer’s
interests, rather than forcing it the other way around.
And as a result, “business acceptance” in its traditional sense is
becoming less relevant to language design because typical businesses
are contributing less to language design; essentially nothing in
direct terms, and even their marginal contribution of providing jobs
to direct contributors (i.e. jobs not involving those contributions)
is proportionally lower than it ever has been.
matthew smillie.
[1] Take the hypothetical situation where a company requires as part
of their license terms that everyone programming with their language
and/or library holds a certification (which only they provide).
On Thu, 2006-06-08 at 02:21 +0900, [email protected] wrote:
:“foo bar”
Symbol
“1.8.4”you are just confusing yourself with irb/inspect
That’s wierd. I’ve seen this problem before (I switched to Marshal in
the end), and I still seem to get it now.
$ ruby -v -ryaml -e ‘p YAML::Syck::VERSION’
ruby 1.8.4 (2005-12-24) [i686-linux]
“0.60”
$ ruby -r yaml -e’ qs = YAML.load(YAML.dump(:“foo bar”)); p qs; p
qs.class ’
:"“foo bar”"
Symbol
On Jun 7, 2006, at 1:21 PM, [email protected] wrote:
=> “— :“some symbol”\n”
=> :“some symbol”
makes the suffering disappear.
- h.h. the 14th dali lama
ara, try this:
% irb
irb(main):001:0> require ‘yaml’
=> true
irb(main):002:0> sym = :“a symbol”
=> :“a symbol”
irb(main):003:0> sym == sym
=> true
irb(main):004:0> sym == YAML.load(YAML.dump(sym))
=> false
irb(main):005:0> sym
=> :“a symbol”
irb(main):006:0> YAML.load(YAML.dump(sym))
=> :"“a symbol”"
irb(main):007:0> VERSION
=> “1.8.4”
Looks like a bug to me.
On Wed, 7 Jun 2006, Dave B. wrote:
If I have a quoted symbol, i.e. :‘some symbol’ then when I dump the YAML for
it and then load the results I don’t get back the symbol I put in, but get an
extra set of escaped quotes. The following irb session shows this:
i don’t see the problem:
harp:~ > ruby -r yaml -e’ qs = YAML.load(YAML.dump(:“foo bar”)); p
qs; p qs.class; p VERSION ’
:“foo bar”
Symbol
“1.8.4”
you are just confusing yourself with irb/inspect
irb(main):014:0> YAML.dump(:‘some symbol’)
=> “— :“some symbol”\n”
^^^^^^^^^^^^^^^^^^^^^^^^
this is the output of String.inspect - not the literal string
try
harp:~ > irb -r yaml
irb(main):001:0> dumped = YAML.dump(:‘some symbol’)
=> “— :“some symbol”\n”
irb(main):002:0> YAML.load dumped
=> :“some symbol”
irb(main):003:0> YAML.load(dumped).class
=> Symbol
regards.
-a