Typos are by definition easier to find in static
typed programs.
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
···
On Aug 27, 2004, at 3:34 PM, David Ross wrote:
--David
--
Best regards, emailto:
scholz at scriptolutions dot com
Lothar Scholz
---------------------------------------
-- Name: David Ross
-- Phone: 865.539.3798
-- Email: drossuby [at] yahoo [dot] com
---------------------------------------
This has nothing to do with the IDE, only with the compiler/parser.
Decent Java IDE gives you accurate code completion, continuous parsing
and compile on save. I.e., most of the time instead of typing names, you
select them from a drop-down of all visible identifiers in the scope
(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.
When you type
something, your typos get highlighted as soon as you type them, not
several minutes later when you compile and run unit tests. Correcting
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).
3.
As a frequent code reviewer I've probably seen thousands of Java bugs,
but very small proportion of them were typos. This is drastically
different from my experience with all other languages, including both
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.
···
--
Best regards, emailto: scholz at scriptolutions dot com
Lothar Scholz http://www.ruby-ide.com
CTO Scriptolutions Ruby, PHP, Python IDE 's
ISTM that the state of the art in Java IDEs is much much much much
better than any C++ IDE. Is that the case?
Yes. Absolutely.
If so, it could be because of Java's standard reflection mechanism and
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.
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.
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.
···
--
Best regards, emailto: scholz at scriptolutions dot com
Lothar Scholz http://www.ruby-ide.com
CTO Scriptolutions Ruby, PHP, Python IDE 's
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.
···
--- Charles Mills <cmills@freeshell.org> wrote:
On Aug 27, 2004, at 3:34 PM, David Ross wrote:
>
> --- Lothar Scholz
<mailinglists@scriptolutions.com>
> wrote:
>
>> Typos are by definition easier to find in static
>> typed programs.
>
> 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
>
>> --
>> Best regards, emailto:
>> scholz at scriptolutions dot com
>> Lothar Scholz
>
---------------------------------------
-- Name: David Ross
-- Phone: 865.539.3798
-- Email: drossuby [at] yahoo [dot] com
---------------------------------------
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 (?)
> ISTM that the state of the art in Java IDEs is much much much much
> better than any C++ IDE. Is that the case?
Yes. Absolutely.
> If so, it could be because of Java's standard reflection mechanism and
> 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.
>>
>> --- Lothar Scholz
<mailinglists@scriptolutions.com>
>> wrote:
>>
>>> Typos are by definition easier to find in static
>>> typed programs.
>>
>> 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"?
And everyone who repeats the rules while sleeping
would write the latter as 2==s
--
Best regards, emailto:
scholz at scriptolutions dot com
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.
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
···
On Saturday, August 28, 2004, 11:25:43 AM, Alexey wrote:
Typos are by definition easier to find in static
typed programs.
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"?
And everyone who repeats the rules while sleeping
would write the latter as 2==s
--
Best regards, emailto:
scholz at scriptolutions dot com
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
--------
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.
--------
-Charlie
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.
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.
Some people are very good at programming in dynamic languages. You
get better with practice. The difference is that the practice is
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.
···
--
Best regards, emailto: scholz at scriptolutions dot com
Lothar Scholz http://www.ruby-ide.com
CTO Scriptolutions Ruby, PHP, Python IDE 's
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.
Heh, that's funny, I mostly do the exact same thing But I whished there was better support for IRB in the ruby ides/text-editors. Copying from/to irb isn't always as smooth as possible. It would be nice if this happened more easily and more automatically.
In the same way, I tend to do test cases. Fire up irb, setting up test data, and writing a few tests. I think there is still some nice automatisations left here, to actually "convert" this irb log into a test case.
It seems to me that an ide for dynamically languages pretty much copies what an ide for a statically language does. So you get those rather artifical limits, like the distinction between running a program and writing it.
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.
--------
-Charlie
----------------------------------------
-- Name: David Ross
-- Phone: 865.539.3798
-- Email: drossruby [at] yahoo [dot] com
----------------------------------------
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.
> Some people are very good at programming in dynamic languages. You
> get better with practice. The difference is that the practice is
> 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.
I'm seeing something different actually. Students in my class (computer science), are more interested in ruby. Absolute beginners on the other hand (not schooled in "thinking about special conditions and error handling"), tend to rather grab a "C++ in 21 days" book, or a "Java for dummies book". Not because they plan to write huge programs, or need the speed, but just because others use it. Suggest beginning with ruby, and they just say "never heard of it, so I won't bother".
Ruby may be an ideal language for beginners, but beginners tend not to find the way to it.
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.
--
Lothar Scholz
You noticed that too, eh?
I can't tell you how many times I ran across a neat
interesting piece of code, but when I look in the
sources it doesn't look nice at all. Most of the
pieces were doe by the inexp. or college kids that I
have seen. oh its scary. I brought that out loud
last time and was sent a nasty email by a college kid.
How nice!
···
----------------------------------------
-- Name: David Ross
-- Phone: 865.539.3798
-- Email: drossruby [at] yahoo [dot] com
----------------------------------------
So you know most programmers using script languages, AND their skills as a
programmer? Wow, you have amazing insights!
KB
···
On Sat, 28 Aug 2004 18:55:55 +0900, Lothar Scholz wrote:
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.
Nevermind the programmer, but I'm amazed that when they hit that sort of
debugging task they didn't bother linting the code.
martin
···
Charles Mills <cmills@freeshell.org> wrote:
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.
To me, the biggest problem with using irb in this mode is the "set up
some context" part.
Believe it or not, but it is quite easy to do with Eclipse/Java: one can
set a breakpoint, execute some test, wait till debugger stops on the
breakpoint, and then use Eclipse "Display" view to evaluate arbitrary
Java expressions in the current scope.
So far, I don't know any easy way to do the same with Ruby, so I end up
inserting things like "puts <expression>.inspect" and rerunning the
test. Which is not as nice as an interactive shell. Does anyone have a
better way?
Alex
···
On Sat, 2004-08-28 at 12:55, Lothar Scholz wrote:
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.
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.
If you are not afraid of a bit of text cutting, then it is not that
difficult.
Here is a simple addition to IRB that will save your session to a
file. Add this to your .irbrc file and when you want to save what you
have done to disk type "IRB.save_session("your_filename")".
# An extension to IRB to save the session to a file
# filename: is the name of the file to save the session in
# hide_IRB: is a command to suppress output of IRB class method calls.
# to prevent execution of the session in Ruby from giving errors.
def IRB.save_session(filename,hide_IRB=true)
file = File.open(filename,"w")
file.puts "# Saved IRB session for #{Time.now}",""
Readline::HISTORY.each do |line|
next if line =~ /^\s*IRB\./ && hide_IRB
file.puts line
end
file.close
end
Something like this may have been mentioned before, but if not I hope
someone finds it useful.
Best,
Zev
···
On Sat, 28 Aug 2004 18:55:55 +0900, Lothar Scholz <mailinglists@scriptolutions.com> wrote:
oh its scary. I brought that out loud