performance comparison

[Lothar Scholz]

Hello Charles,


CM> Did you get that deep C secret from "Expert C Programming"?

And everyone who repeats the rules while sleeping would write the latter as 2==s

 

[Lothar Scholz]

Hello Alexey,
AV> Decent Java IDE gives you accurate code completion, continuous parsing
AV> and compile on save. I.e., most of the time instead of typing names, you
AV> select them from a drop-down of all visible identifiers in the scope
AV> (with most likely choices at the top of the list).

I doubt that very much typos that make it into compiled code are wrong
identifiers. And typos in identifiers normally don't get there way in
a runnable program.

code completion is 90% usefull for faster development (typing) but not for
avoiding typos.

AV> When you type
AV> something, your typos get highlighted as soon as you type them, not
AV> several minutes later when you compile and run unit tests. Correcting
AV> them in this way doesn't break the flow at all - which is very pleasant.

This the responsibility of the parser/compiler not the IDE
(the IDE has no AI for this, it's just a few lines of code to do this).

AV> 3.
AV> As a frequent code reviewer I've probably seen thousands of Java bugs,
AV> but very small proportion of them were typos. This is drastically
AV> different from my experience with all other languages, including both
AV> Ruby and C/C++.

Thats why i'm trying to only use Eiffel. Still much better when it
comes to avoid errors. For example overwritting methods by accident.

 

[David Ross]

Yes, that was the book

I have several others, I don't remember the exact
programming error that was in it. There are plenty of
other typo bugs that are easy to make that lint will
not catch. Just be around and watch OS developers more
often. The DragonFlyBSD team often report what they
are working on in the channel, plus I read the
commits.

--- Lothar Scholz

Oh really? That would explain the 20 million dollar
bug..

s=2 when it was meant to be s==2

Did you get that deep C secret from "Expert C
Programming"?
If I remember right he goes on to say that any half
way decent version
of lint would have found that bug. Then he argues
that lint should
have never been separated from the compiler in the
first place. Not
sure but I think the bug was the reverse 's==2;'
instead of 's=2;'.
The statement was all alone on one line and would be
flagged with a
warning by just about any compiler these days -
statement with no
effect.
-Charlie

--David

---------------------------------------
-- Name: David Ross
-- Phone: 865.539.3798
-- Email: drossuby [at] yahoo [dot] com
---------------------------------------



__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail

 

[David Ross]

Hello Charles,



CM> Did you get that deep C secret from "Expert C
Programming"?

And everyone who repeats the rules while sleeping
would write the latter as 2==s

That is a very programming habit, and one that I
follow. Unfortunately not everyone does. Most people
don't even read the `man syntax` in *BSD. Which
aparently has very good coding style which everyone
should follow.

--David Ross



_______________________________
Do you Yahoo!?
Win 1 of 4,000 free domain names from Yahoo! Enter now.
http://promotions.yahoo.com/goldrush

 

[Charles Mills]

That is a very programming habit, and one that I
follow. Unfortunately not everyone does. Most people
don't even read the `man syntax` in *BSD. Which
aparently has very good coding style which everyone
should follow.

--David Ross

Agreed that is a good habit and I can't say I follow it myself... if
you interested I found the 20 million dollar bug on google:
--------
In Spring 1993, in the Operating System development group at SunSoft,
we had a "priority one" bug report come in describing a problem in the
asynchronous I/O library. The bug was holding up the sale of $20
million worth of hardware to a customer who specifically needed the
library functionality, so we were extremely motivated to find it. After
some intensive debugging sessions, the problem was finally traced to a
statement that read:

x==2;

It was a typo for what was intended to be an assignment statement. The
programmer's finger had bounced on the "equals" key, accidentally
pressing it twice instead of once. The statement as written compared x
to 2, generated true or false, and discarded the result.

C is enough of an expression language that the compiler did not
complain about a statement which evaluated an expression, had no
side-effects, and simply threw away the result. We didn't know whether
to bless our good fortune at locating the problem, or cry with
frustration at such a common typing error causing such an expensive
problem. Some versions of the lint program would have detected this
problem, but it's all too easy to avoid the automatic use of this
essential tool.

 

[Alexey Verkhovsky]

Hello Alexey,

I doubt that very much typos that make it into compiled code are wrong
identifiers.

Not in static languages. But it is by far the most common mistake I make
when writing in Ruby.

And typos in identifiers normally don't get there way in
a runnable program.

One hopes so. Thanks heaven (and Nathaniel Talbott) for test/unit.

This the responsibility of the parser/compiler not the IDE
(the IDE has no AI for this, it's just a few lines of code to do this).

Oh, thanks for the enlightenment
It is the IDE that tells to parser/compiler what I just typed, and
highlights the errors under my cursor though. Both decent Java IDEs that
I know of apparently use their own syntax parsers (incremental and
tightly coupled to IDE's own project model). Have a look at Eclipse code
- it even has its own Java compiler; the part about continuous parsing
is a tad more than "just a few lines", too.

Thats why i'm trying to only use Eiffel. Still much better when it
comes to avoid errors. For example overwritting methods by accident.

What are such "belts and braces" programmers as the two of us doing on
ruby-talk?

Seriously though, even after becoming familiar with the syntax and
standard classes to the point where I mostly don't have to think about
them, I still find myself making notably more mistakes in Ruby than in
Java. Hacking out a small script using standard APIs is a bliss, but
adding 15 lines of unit test and 15 lines of code that makes it pass to
an existing project normally takes me 2-3 edit/test/debug cycles just to
get past the typos. Quick as these cycles are, they break my flow.
Simple refactorings (like "rename method") are also painful in the same
way.

I wonder if it's just another stage of the learning curve, or that's how
programming in dynamic language normally feels, or maybe I am doing
something wrong (?)

Alex

 

[David Ross]

Yes, that is the 20 million story. I smile at that one
still. Someone please fwap() me if I ever make a
release with a bug like that

It is equally important in any language that mistakes
are not made like this. They are very dangerous. I am
curious on the print functions in Ruby as to if the
ones that are unsafe to use in certain applicatoins
are equally unsafe in Ruby. Of course gets() is
unsafe, it is in every language.

--David

Agreed that is a good habit and I can't say I follow
it myself... if
you interested I found the 20 million dollar bug on
google:
--------
In Spring 1993, in the Operating System
development group at SunSoft,
we had a "priority one" bug report come in
describing a problem in the
asynchronous I/O library. The bug was holding up the
sale of $20
million worth of hardware to a customer who
specifically needed the
library functionality, so we were extremely
motivated to find it. After
some intensive debugging sessions, the problem was
finally traced to a
statement that read:

x==2;

It was a typo for what was intended to be an
assignment statement. The
programmer's finger had bounced on the "equals" key,
accidentally
pressing it twice instead of once. The statement as
written compared x
to 2, generated true or false, and discarded the
result.

C is enough of an expression language that the
compiler did not
complain about a statement which evaluated an
expression, had no
side-effects, and simply threw away the result. We
didn't know whether
to bless our good fortune at locating the problem,
or cry with
frustration at such a common typing error causing
such an expensive
problem. Some versions of the lint program would
have detected this
problem, but it's all too easy to avoid the
automatic use of this
essential tool.

----------------------------------------
-- Name: David Ross
-- Phone: 865.539.3798
-- Email: drossruby [at] yahoo [dot] com
----------------------------------------



_______________________________
Do you Yahoo!?
Win 1 of 4,000 free domain names from Yahoo! Enter now.
http://promotions.yahoo.com/goldrush

 

[Mikael Brockman]

Yes, that is the 20 million story. I smile at that one
still. Someone please fwap() me if I ever make a
release with a bug like that

It is equally important in any language that mistakes
are not made like this. They are very dangerous. I am
curious on the print functions in Ruby as to if the
ones that are unsafe to use in certain applicatoins
are equally unsafe in Ruby. Of course gets() is
unsafe, it is in every language.

Huh? Why?

 

[David Ross]

Its common security knowledge gets() is unsafe. It has
no bounds checking. I only talk about security and
ease of use. Its the only thing I like to talk about.


I love security.

from my manpages-- SECURITY CONSIDERATIONS
The gets() function cannot be used securely. Because
of its lack of
bounds checking, and the inability for the
calling program to reliably
determine the length of the next incoming line,
the use of this function
enables malicious users to arbitrarily change a
running program's func-
tionality through a buffer overflow attack.


---------

There are many other insecure function calls. The
knowledge on how to use them properly is very nice to
have. Which most people lack. Also using printf() for
certain types of usage can lead to exploits. buffer
overflow problems, etc.

btw, I am a BSD dragon. So expect to get information
like this from me

I bite, be careful

--David Ross

Huh? Why?

_______________________________
Do you Yahoo!?
Win 1 of 4,000 free domain names from Yahoo! Enter now.
http://promotions.yahoo.com/goldrush

 

[Jamis Buck]

Its common security knowledge gets() is unsafe. It has
no bounds checking. I only talk about security and
ease of use. Its the only thing I like to talk about.


I love security.

from my manpages-- SECURITY CONSIDERATIONS
The gets() function cannot be used securely. Because
of its lack of
bounds checking, and the inability for the
calling program to reliably
determine the length of the next incoming line,
the use of this function
enables malicious users to arbitrarily change a
running program's func-
tionality through a buffer overflow attack.

To clarify, then: David, you are talking about the C 'gets()' function,
correct? I agree that it should be avoided at all costs. However, Ruby's
"gets()" function does not map directly to a C "gets()" invocation -- it
does a lot more work, including bounds checking. Thus, saying "gets()
is unsafe in every language" is rather misleading. I won't say it is
"safe" in Ruby, since I'm not an expert in this area, but it is
certainly not as hazardous to use as in vanilla C code.

(Someone please flame me gently if I've mispoken anything grossly
regarging Ruby's internals...)

- Jamis

---------

There are many other insecure function calls. The
knowledge on how to use them properly is very nice to
have. Which most people lack. Also using printf() for
certain types of usage can lead to exploits. buffer
overflow problems, etc.

btw, I am a BSD dragon. So expect to get information
like this from me

I bite, be careful

--David Ross







_______________________________
Do you Yahoo!?
Win 1 of 4,000 free domain names from Yahoo! Enter now.
http://promotions.yahoo.com/goldrush

.

--
Jamis Buck
(e-mail address removed)
http://www.jamisbuck.org/jamis

"I use octal until I get to 8, and then I switch to decimal."

 

[Mikael Brockman]

Its common security knowledge gets() is unsafe. It has
no bounds checking. I only talk about security and
ease of use. Its the only thing I like to talk about.


I love security.

from my manpages-- SECURITY CONSIDERATIONS
The gets() function cannot be used securely. Because
of its lack of
bounds checking, and the inability for the
calling program to reliably
determine the length of the next incoming line,
the use of this function
enables malicious users to arbitrarily change a
running program's func-
tionality through a buffer overflow attack.


---------

There are many other insecure function calls. The
knowledge on how to use them properly is very nice to
have. Which most people lack. Also using printf() for
certain types of usage can lead to exploits. buffer
overflow problems, etc.

btw, I am a BSD dragon. So expect to get information
like this from me

I bite, be careful

I don't see how the safety of the corresponding C functions is relevant;
we were talking about the (safe) Ruby variants.

 

[David Ross]

To clarify, then: David, you are talking about the C
'gets()' function,
correct? I agree that it should be avoided at all
costs. However, Ruby's
"gets()" function does not map directly to a C
"gets()" invocation -- it
does a lot more work, including bounds checking.
Thus, saying "gets()
is unsafe in every language" is rather misleading. I
won't say it is
"safe" in Ruby, since I'm not an expert in this
area, but it is
certainly not as hazardous to use as in vanilla C
code.

(Someone please flame me gently if I've mispoken
anything grossly
regarging Ruby's internals...)

- Jamis

hrm.. well I don't know for sure.. I was told on
freenode #ruby-lang it was insecure when I asked about
it. Though I never actually read through the code to
see.

reading code...

appendline(..) is restricted to 8192 bytes. Okay,
so it does perform checking. A specification on ruby
would really help Its really hard reading thousands
of lines of code and trying to understand all of ruby.

Matz: *cough* *cough* you should write what is in your
head and on paper for everybody

..... <snip>
int cnt = bp - buf;

if (cnt > 0) {
..... </snip>

----------------------------------------
-- Name: David Ross
-- Phone: 8965.539.3798
-- Email: drossruby [at] yahoo [dot] com
----------------------------------------




__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail

 

[Jamis Buck]

hrm.. well I don't know for sure.. I was told on
freenode #ruby-lang it was insecure when I asked about
it. Though I never actually read through the code to
see.

Well, there are lots of ways for something to be insecure. The data from
gets is put into a string, which anyone with access to the executing
interpreter could intercept and read/modify... I'm certainly no expert
on security, but I wouldn't think Ruby should ever be suceptible to
buffer overflows, at least. I mean, isn't that one of the nice things
about interpreted languages? They kind of protect you from that kind of
"low-level" memory management.

- Jamis

reading code...

appendline(..) is restricted to 8192 bytes. Okay,
so it does perform checking. A specification on ruby
would really help Its really hard reading thousands
of lines of code and trying to understand all of ruby.

Matz: *cough* *cough* you should write what is in your
head and on paper for everybody

..... <snip>
int cnt = bp - buf;

if (cnt > 0) {
..... </snip>

----------------------------------------
-- Name: David Ross
-- Phone: 8965.539.3798
-- Email: drossruby [at] yahoo [dot] com
----------------------------------------




__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail

.

--
Jamis Buck
(e-mail address removed)
http://www.jamisbuck.org/jamis

"I use octal until I get to 8, and then I switch to decimal."

 

[David Ross]

well, not managing memory can be a good or bad idea.
Like in previous email.. I wouldn't write a OS in a
interpreted language. Sometime in the future they
might gain different concepts and not need to even
worry about memory management though (*wishful
thinking)

I suppose ruby doesn't unless there is a bug in the
code. I can't be 100% sure, there might be unsafe
methods or calls. I would need to learn more about how
the GC acts and the language details.

Well, there are lots of ways for something to be
insecure. The data from
gets is put into a string, which anyone with access
to the executing
interpreter could intercept and read/modify... I'm
certainly no expert
on security, but I wouldn't think Ruby should ever
be suceptible to
buffer overflows, at least. I mean, isn't that one
of the nice things
about interpreted languages? They kind of protect
you from that kind of
"low-level" memory management.

- Jamis

----------------------------------------
-- Name: David Ross
-- Phone: 8965.539.3798
-- Email: drossruby [at] yahoo [dot] com
---------------------------------------




__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail

 

[Gavin Sinclair]

Hello Alexey,

AV>> Insofar as easy debugging and not making typos is concerned, Java +
AV>> decent IDE (Intellij or Eclipse) delivers it even today

Typos are by definition easier to find in static typed programs.
This has nothing to do with the IDE, only with the compiler/parser.

ISTM that the state of the art in Java IDEs is much much much much
better than any C++ IDE. Is that the case?

If so, it could be because of Java's standard reflection mechanism and
intermediate byte code. Is that a fair comment?

I agree that in general static languages are far more amenable to
tools than dynamic ones (Smalltalk being an exception). It's probably
also worthwhile considering the differences between popular static
languages.

Cheers,
Gavin

 

[Gavin Sinclair]

Seriously though, even after becoming familiar with the syntax and
standard classes to the point where I mostly don't have to think about
them, I still find myself making notably more mistakes in Ruby than in
Java. Hacking out a small script using standard APIs is a bliss, but
adding 15 lines of unit test and 15 lines of code that makes it pass to
an existing project normally takes me 2-3 edit/test/debug cycles just to
get past the typos. Quick as these cycles are, they break my flow.
Simple refactorings (like "rename method") are also painful in the same
way.

Programming Java without a *really* good IDE is awful. Programming
Java with one is bliss (except for the Java bit, which brings the
whole experience back to "bearable").

Programming Ruby without a really good IDE is quite doable. There are
certainly difficult aspects to it (especially project structure), and
your point about losing flow with minor things is well made.

Whenever there's a complex-ish piece of Ruby code I have to do (i.e.
susceptible to subtle mistakes and/or unlikely to work first time), I
develop it in IRB. Just copy and paste the code into IRB, set up some
context (initial data), and run and edit until it works. It then gets
copied into the program with confidence. That only feels like one
"cycle" - an illusion, perhaps, but a useful one.

BTW, word completion (CTRL-P and others) in Vim goes a long way to
avoiding typos. Sometimes, however, it repeats them all over the
place!

I wonder if it's just another stage of the learning curve, or that's how
programming in dynamic language normally feels, or maybe I am doing
something wrong (?)

Some people are very good at programming in dynamic languages. You
get better with practice. The difference is that the practice is
enjoyable

Gavin

 

[Lothar Scholz]

Hello Gavin,

GS> ISTM that the state of the art in Java IDEs is much much much much
GS> better than any C++ IDE. Is that the case?

Yes. Absolutely.

GS> If so, it could be because of Java's standard reflection mechanism and
GS> intermediate byte code. Is that a fair comment?

No. Reflection has nothing to do with the things that Java IDE's do
and were mentioned here. Reflection is only available at runtime, but
IDE's need static code analysis by looking at the source code files.

The reason why C++ has so much problems is that the there are so many
things that has influences to complex C++ systems (and the standart runtime is
a complex C++ system). Remember the dozens of #ifdef symbols a C
system has and the size of "sophisticated" make files / build systems.
In java the only thing that has an influence is the CLASSPATH
variable, thats all.

Also calling C++ as static typed language is not true. Oberon, Java or
Eiffel are such languages. C++ has its typecasts and hunderts of dirty
tricks. It's still a high level assembler.

GS> I agree that in general static languages are far more amenable to
GS> tools than dynamic ones (Smalltalk being an exception). It's probably
GS> also worthwhile considering the differences between popular static
GS> languages.

Smalltalk is in a third class, so called image languages. Since these
language don't depend on the execution order of the files the tools
can do much more. What should a static code analyser do with a ruby
code like this:

if ENV["OS"] == "linux"
require "linux_optimization"
else
require "total_other_implementation"
end

This are code snippets that you will never find in Smalltalk.
So it is much easier to develop tools support for Smalltalk then
doing tools for ruby. I mean look at the ruby refactoring browser, its
not much more then a better search/replace tool which is only usefull
in very very restricted cases.

 

[Lothar Scholz]

Hello Gavin,

GS> Whenever there's a complex-ish piece of Ruby code I have to do (i.e.
GS> susceptible to subtle mistakes and/or unlikely to work first time), I
GS> develop it in IRB. Just copy and paste the code into IRB, set up some
GS> context (initial data), and run and edit until it works. It then gets
GS> copied into the program with confidence. That only feels like one
GS> "cycle" - an illusion, perhaps, but a useful one.

I think it is better to start with test cases and improve small programs
then doing a try and error way in the console.

And a huge problem is that copying code fragments into IRB is easy but
if you want to get some code you typed in IRB multiple lines) getting
this back to the editor is much more difficult.

GS> Some people are very good at programming in dynamic languages. You
GS> get better with practice. The difference is that the practice is
GS> enjoyable

But to be honest i think the most people using script languages are
not very good programmers. This has to do that they are very good
beginner languages for non technical persons who wants to see results
instead of learning a theory first.

But seeing results immediately make it a lot more difficult to think
about special conditions and error handlings. Adding this skills later
is much more difficult. So i can understand that a lot of universities
start teaching functional strong typed languages.

 

[Lennon Day-Reynolds]

I honestly think that the issues surrounding code analysis and
verification in Ruby, Perl, Python, etc., have less to do with the
langauge per se, and more to do with the lack of any formal semantics
for it.

C, C++, Java, and most other statically-typed languages began as an
implementation language well before they were picked up by the
verification and analysis crowd. Their inital design goals are usually
less important than the stability of their respective language
definitions -- given a stable spec, the academic/research community
can devise an endless variety of clever ways to increase the level of
confidence in a language.

Unfortunately, dynamic languages are not only at a disadvantage due to
their basic design, they suffer due to a lack of formal analysis. Java
began as a simple C-like OO language, with a minimal stack-based VM on
which to operate. Now, however, it is one of the most popular
platforms on which to base your code-generation, analysis, and
transformation tools.

Were some enterprising soul to create a formal sematics for Ruby, or
even to describe it in terms of a well-defined language such as Java
or Smalltalk, I suspect that excellent tool support could follow
quickly. Unfortunately, since the current implementation of the Ruby
language always serves as the "official" language definition, there is
little that the reseach community could do to improve the tool
support.

 

[Henrik Horneber]

Hello Gavin,

GS> ISTM that the state of the art in Java IDEs is much much much much
GS> better than any C++ IDE. Is that the case?

Yes. Absolutely.

GS> If so, it could be because of Java's standard reflection mechanism and
GS> intermediate byte code. Is that a fair comment?

No. Reflection has nothing to do with the things that Java IDE's do
and were mentioned here. Reflection is only available at runtime, but
IDE's need static code analysis by looking at the source code files.

As a side note, Reflection or Introspection does have something to do
with how the IDE handles code completion and stuff like that. If you
have a 3rd party library only as class files (in bytecode), most recent
IDEs still will give a decent amount of code completion when you use
these classes. Reflection is the only way the IDE is able to get those
method and class names.

Still, these kinds of errors we are talking about have nothing to do
with reflection.

Regards

Henrik