In fact, thinking about it, I remember my C++ university times, when
several
friends put together some program and the whole thing crashed badly at
compilation time.
Being the dynamic nature of Ruby, it will not crash at compilation (just
no
compilation!), it will just work till the given function is called (or
tried
to) and the problem is found, that may not happen to you but someone
else…
It is much harder to audit or make test for all the code than the
compiler
checking types, interfaces, etc. (Of course integrating is not only
about
making it compile together)
I am just arguing that the author may have reason and dynamic language
have
some flaws.
Knowing them is the first step to improve Ruby (please don’t think I’m
trying to troll)
I am just arguing that the author may have reason and dynamic language
have some flaws.
A dynamic language + test driven development is considered, in some
circles, to
be incredibly more productive than a static language with both static
type
checking and unit tests. Productivity means robustness, and the more
code you
can remove, the more robust you generally get. Dynamic languages and
TDD both
make removing code - refactoring to remove duplication - super easy.
Block closures are a major help, too, because they solve the ‘finally’
and
‘RAII’ issues that plague other languages.
Then, all the static languages tend to bend over backwards to provide
dynamic
features.
The closer to the metal you run, the more static you must be. The
farther you
are (such as the web), the more dynamic you should be.
Well, I didn’t find it to be a good article at all. I felt it was
just some guy speculating wildly about something he knows very little
about. He pretty much admits that, multiple times.
After reading the post, I followed a couple of the links. I read a
little and watched a podcast. In just doing that much research (I’ve
never heard of Chandler before), I felt like it was quite possible the
project had trouble defining their scope and establishing their
financial viability. Perhaps it failed for those reasons.
Perhaps it failed because the entire development team converted to a
religion that tries to minimize their computer usage. I’m totally
making that up and I mean no disrespect to the developers, but that’s
really my point.
If you watch the video podcast, it’s interesting to see how many of
the interviewer’s, a self proclaimed Outlook fan, questions these
“Outlook killer” developers don’t really have a good answer to. I
feel that was much more likely to be damaging in the long term than
their choice of language.
exemplary virtue.
If you build a mail system that relies on a database, someone will
inevitably decide that a mail system, with its built-in queueing, routing
and simplicity, is a great transport for asynchronous replication, which in
turn, can be used to create a distributed file system. And once you’ve got
a file system, well, wouldn’t it be great to get a database running on it?
What does any of this have to do with Ruby core?
Naively small-scale question that demands a large-scale answer the size
of a book. On the other hand, because of my current experience with a very “large-scale” Ruby on Rails system, my answer is “YES!”
“Large-scale” projects have many axes of “largeness” and solutions
thereof. In the big picture, most of those axes have no correlation
with an implementation language’s ability to do eval() or introspection,
etc. That is not to say that the choice of language does not have an
impact on the feasibility (time-to-market, maintenance cost, deployment
cost, etc.) of a large system. But at some point, you need to push
those details down into other layers of design and live with what you
have.
Naively small-scale question that demands a large-scale answer the size
of a book. On the other hand, because of my current experience with a very “large-scale” Ruby on Rails system, my answer is “YES!”
The point I think is that being the dynamic nature of languages as Ruby
where you can for instance open a class anytime anywhere, is virtually
impossible to create a tool to verify the code without actually running
a
unit test or similar on it. (correct me if I am wrong)
In fact, static language needs that also (to verify semantic
correctness),
but having a static tool called compiler that can catch some common
errors and being more strict languages (they have types and a mismatch
of
types will be caught) they can say for instance that method will only
admits
integers.
But the point is that there is a lot of information out of the
specification
of any language. For instance if you return an integer, -1 means error?
That information is documented not defined and checked by the compiler.
So both times of languages have the same “problem”, test are needed to
verify them. The only difference is that dynamic languages don’t have
the
“simple” static verification of the compiler. So that need is made more
accurate. Knowing this and improving Ruby in this area can only make
the
language even better.
Well, I didn’t find it to be a good article at all. I felt it was
just some guy speculating wildly about something he knows very little
about. He pretty much admits that, multiple times.
I find it telling that the article begins by citing Eclipse as a paragon
of
exemplary virtue.
Eclipse, while I find it useful as an IDE sometimes, is sluggish,
incredibly complex, and about as far from agility as one can get. It’s
only just starting to break free of its own gravitational field - and
that
was accomplished only by doubling the codebase from 7 to 17 million
LOC.
Eclipse (and Java in general) is a great example of what I call
“stratification” - the re-implementation of lower layers in ever-higher
layers, because nobody even remembers the lower layer is there anymore.
If you build a mail system that relies on a database, someone will
inevitably decide that a mail system, with its built-in queueing,
routing
and simplicity, is a great transport for asynchronous replication, which
in
turn, can be used to create a distributed file system. And once you’ve
got
a file system, well, wouldn’t it be great to get a database running on
it?
accurate. Knowing this and improving Ruby in this area can only make the language even better.
Sorry if this comes across as rude (it’s definitely not the
intention), but this subject is really off-topic on ruby-core.
Moreover, it has been discussed (on ruby-talk) at least 1000 times by
now. The article you cite is the same line of reasoning 995 out of
those 1000 earlier conversations started with.
At this point, I would be hugely amazed by anyone adding anything
interesting to the “Ruby should have type checking” idea.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
that can catch some common