performance comparison

D

David Ross

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.

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
----------------------------------------





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

Kristof Bastiaensen

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.
So you know most programmers using script languages, AND their skills as a
programmer? Wow, you have amazing insights!

KB
 
M

Martin DeMello

Charles Mills said:
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.

Nevermind the programmer, but I'm amazed that when they hit that sort of
debugging task they didn't bother linting the code.

martin
 
L

Lloyd Zusman

Martin DeMello said:
Nevermind the programmer, but I'm amazed that when they hit that sort of
debugging task they didn't bother linting the code.

martin

Maybe that's how they found the error.
 
D

David Ross

--- Kristof Bastiaensen said:
So you know most programmers using script languages,
AND their skills as a
programmer? Wow, you have amazing insights!

KB

I might disagree with lothar on some points, but this
time he is right. Using a dynamic language you don't
running in to problems you would with other languages
like C. The common script languages have protections
for thier programmers, and I find it most difficult to
trust other peoples code at most. The more you use
"safer" languages, the less you are able to learn
about the problems. The less you learn about problems
the less you tend to not think about several methods
of programming and your skills are not as good as a C
programmer.

Ruby certainly does reduce programming time, but reeks
in performance. Its not as simple as to "send
patches". The ruby design is fine, and most likely
will lways be improving.

C programmers have to think more about design and
safety. With Most scripting languages which have
safety protection force the programmer not to even
think about the underlying code. With this, this is
the proof of why scripting language programmers are
not as good as per sey.. C programmers. I am sure this
is what lothar was meaning by "But to be honest i
think the most people using script languages are not
very good programmers"

------------------------------------------------
-- Name: Daid 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
 
M

Mikael Brockman

David Ross said:
--- Kristof Bastiaensen said:
So you know most programmers using script languages,
AND their skills as a
programmer? Wow, you have amazing insights!

[...]

C programmers have to think more about design and
safety.

You assume that most C software is well-designed and secure. The
opposite is true.
With Most scripting languages which have safety protection force the
programmer not to even think about the underlying code. With this,
this is the proof of why scripting language programmers are not as
good as per sey.. C programmers.

You assume that good programmers design with machine-code in mind;
again, the opposite is true.
I am sure this is what lothar was meaning by "But to be honest i think
the most people using script languages are not very good programmers"

And I agree. Additionally, most people using non-script languages are
shoddy programmers, too.
 
D

Daniel Cremer

(...) The less you learn about problems
the less you tend to not think about several methods
of programming and your skills are not as good as a C
programmer.
(...)
C programmers have to think more about design and
safety. With Most scripting languages which have
safety protection force the programmer not to even
think about the underlying code. With this, this is
the proof of why scripting language programmers are
not as good as per sey.. C programmers. I am sure this
is what lothar was meaning by "But to be honest i
think the most people using script languages are not
very good programmers"

Hmmm... this sort of reminds me of a post I saw once of someone stating
that if you didn't write your win32 programs in assembly you were going
for the easy option and weren't _really_ a good programmer as you
weren't thinking performance.
I'm very far from considering myself as the prime example of a great
programmer:) , however I'm sure that ruby has taught me a lot,
especially in OO and general design of code. If using C or C++ I simply
go for the "shortest route" possible to get results. In ruby it's not
so. It's so flexible and encouraging that you actually _want_ to think
of various possibilities to solve a problem and find the best fit (short
term and long term).
It also depends on what your definition of a good programmer is. When I
see someone doing all their web development in C (yes I've seen that), I
don't think "what a great programmer, he can do the hardcore stuff". I
think, "why on earth is he using the wrong tools". There's no way I
would hire such a person, they don't have one of the basic qualities of
being a programmer: laziness.
Of course I have to agree that I'd have serious doubts about anyone who
had only ever used scripting languages, as it points to either
disinterest in programming or a beginner.

-Daniel
 
A

Anders Engström

--HlL+5n6rz5pIUxbD
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

=20
And I agree. Additionally, most people using non-script languages are
shoddy programmers, too.
=20

Well said. +1

//Anders

--=20
=2E . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
=2E Anders Engstr=F6m (e-mail address removed)
=2E http://www.gnejs.net PGP-Key: ED010E7F
=2E [Your mind is like an umbrella. It doesn't work unless you open it.] =
=20


--HlL+5n6rz5pIUxbD
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBMd8quNLLbe0BDn8RApZwAJsG3vQrwb60mBamCDn9ONsRhIYT0ACgkKpg
uOFxXARS8D7XdYpV8yu2Wm4=
=EeaQ
-----END PGP SIGNATURE-----

--HlL+5n6rz5pIUxbD--
 
A

Alexey Verkhovsky

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.

Try "irb --noprompt".

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
 
L

Lothar Scholz

Hello Daniel,

DC> Hmmm... this sort of reminds me of a post I saw once of someone stating
DC> that if you didn't write your win32 programs in assembly you were going
DC> for the easy option and weren't _really_ a good programmer as you
DC> weren't thinking performance.

DC> I'm very far from considering myself as the prime example of a great
DC> programmer:) , however I'm sure that ruby has taught me a lot,
DC> especially in OO and general design of code. If using C or C++ I simply
DC> go for the "shortest route" possible to get results. In ruby it's not
DC> so. It's so flexible and encouraging that you actually _want_ to think
DC> of various possibilities to solve a problem and find the best fit (short
DC> term and long term).

No this was not exactly my the point.

And remember that this thread was not about ruby as a programming
language. It started with Java and moving to whole language families
(static typed <-> dynamically typed).

Ruby is special here because it still is a freak language. Freak in
this context may be substituted with "nerd", "scientist" or "old wise
man". My statement may become more understandable when you look at
the popular scripting languages out there

- PHP
- Java Script
- Perl
- Visual Basic (for Applications)
- TCL
- Python
- Ruby

in this order. And only compare the professionals doing there work
in (at least one of) these languages. At least from my experience in
the last 10 years i see a correlation between the main languages and
there programming skills. I don't know exactly why but i think David
Ross's argument is one of the main reasons. Many of the buggy PHP and
Javascripts are out there because failures don't have serious
consequences and if a person did not learn (or forgot) to be afraid of
errors he stops thinking about it intensively. In germany we say "er ist
versaut fürs Leben".

I see a huge problem with this in many Java apps where the normal
reaction is to say: "okay lets throw an exception" but the programmer
never tries to handle it somewhere else then in the main loop with a
catch all clause.


DC> It also depends on what your definition of a good programmer is.

A good programmer is someone who is able to analyse a problem and
create a software implementation that meets the goal, keeping all
contraints (security, performance, extensibility) in acceptable ranges
according to the problem domain and customer requirements.
This should happen in a reliable and fast way.
 
L

Lothar Scholz

Hello Alexey,

AV> So far, I don't know any easy way to do the same with Ruby, so I end up
AV> inserting things like "puts <expression>.inspect" and rerunning the
AV> test. Which is not as nice as an interactive shell. Does anyone have a
AV> better way?

My Arachno Ruby IDE will have this feature in it's 0.4 version. But it
is already available in the default ruby console debugger. You can simply
evaluate all statements and even redefine methods by cut&paste from your editor
after a breakpoint is hit.

We already had a longer discussion here if it is possible and good to
write an environment that acts more like a Lisp/Smalltalk image. But
i'm still not sure if this is the right way for a language like Ruby.
 
A

Alexey Verkhovsky

I see a huge problem with this in many Java apps where the normal
reaction is to say: "okay lets throw an exception" but the programmer
never tries to handle it somewhere else then in the main loop with a
catch all clause.

I'd say, in any language with exceptions support, handling an exception
where you don't know what to do with it (instead of propagating it up
the stack) is a much more common "shoddy programming technique" than
what you describe.

Variants of this anti-pattern are "Print stack trace and forget", "Wrap
and re-throw" or even "Throw another exception and forget (losing the
stack trace to the original error)".

In most cases main loop or somewhere quite close to that is precisely
the right place to handle exceptions, provided that "ensure" clause (or
Java "finally") is used judiciously to close things like database
connections and other expensive resources.

Alex
 
D

David Ross

well. I didn't include a bit of information of the
people I was targetting. I am not talking about the
half-job programs which are insecure or imcomplete. I
am talking about professional programmers who have had
years of experience. Most programs that are insecure
are most likely maintained by someone still in
college, or is a programmer with only a few years of
experience.

I assume nothing. I keep forgetting to include the
information I think about and only seem to include the
end conclusion. Professionalists design machine code.
I do not count the everyday application programmer as
a safe programmer.

I will introduce a quote to the public which was
brought to me that will basically shatter people if
all they do is want to write applicatoins as well that
don't have any contribution to the programming or
scientific community as well.

"The world can be a place for achievements where you
can expand, but why would you want to write throw away
code"

What does this mean? I have thought months on this
one. Why is this in the topic? Everytime I think about
programming this goes through my head. I refuse to
become a drone.

I can't exactly share on what this means for personal
reasons. You think for yourself. Though, I will have
to say this about other programmers. If you make a lot
of money programming, or even write code for a big
product , this does not make you a good programmer.

"Well, you can be a professional programmer, or you
can be a rich programmer"

This was another from a different friend. I get the
point, but I think even a good programmer can make
money. :) Hopefully.


Why am I even going over this?!
These are a couple quotes that I think about once and
a while, and that first one comes to my mind each time
I program. I am sharing. Okeday? Questions or comments
are wanted.



--- Mikael Brockman said:
David Ross said:
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.

So you know most programmers using script languages,
AND their skills as a
programmer? Wow, you have amazing insights!

[...]

C programmers have to think more about design and
safety.

You assume that most C software is well-designed and
secure. The
opposite is true.
With Most scripting languages which have safety protection force the
programmer not to even think about the underlying code. With this,
this is the proof of why scripting language programmers are not as
good as per sey.. C programmers.

You assume that good programmers design with
machine-code in mind;
again, the opposite is true.
I am sure this is what lothar was meaning by "But to be honest i think
the most people using script languages are not
very good programmers"

And I agree. Additionally, most people using
non-script languages are
shoddy programmers, too.

----------------------------------------
-- 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
 
F

Florian Gross

Alexey said:
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?

I've done a quick implementation of breakpoints that will spawn an irb
session at the point of the break point in your application yesterday.
I've attached it.

Regards,
Florian Gross


require 'irb'
require 'binding_of_caller'

module IRB
def IRB.start(ap_path = nil, main_context = nil)
$0 = File::basename(ap_path, ".rb") if ap_path

# suppress some warnings about redefined constants
old_verbose, $VERBOSE = $VERBOSE, nil
IRB.setup(ap_path)
$VERBOSE = old_verbose

if @CONF[:SCRIPT]
irb = Irb.new(main_context, @CONF[:SCRIPT])
else
irb = Irb.new(main_context)
end

@CONF[:IRB_RC].call(irb.context) if @CONF[:IRB_RC]
@CONF[:MAIN_CONTEXT] = irb.context

trap("SIGINT") do
irb.signal_handle
end

catch:)IRB_EXIT) do
irb.eval_input
end
end
end

# This will pop up an interactive ruby session at a
# pre-defined break point in a Ruby application. In
# this session you can examine the environment of
# the break point.
#
# You can get a list of variables in the context using
# local_variables via +local_variables+. You can then
# examine their values by typing their names.
#
# You can have a look at the call stack via +caller+.
#
# breakpoints can also return a value. They will execute
# a supplied block for getting a default return value.
# A custom value can be returned from the session by doing
# +throw:)debug_return, value)+.
#
# You can also give names to break points which will be
# used in the message that is displayed upon execution
# of them.
#
# Here's a sample of how breakpoints should be placed:
#
# class Person
# def initialize(name, age)
# @name, @age = name, age
# breakpoint("Person#initialize")
# end
#
# attr_reader :age
# def name
# breakpoint("Person#name") { @name }
# end
# end
#
# person = Person.new("Random Person", 23)
# puts "Name: #{person.name}"
#
# And here is a sample debug session:
#
# Executing break point "Person#initialize" near file.rb:14
# irb(#<Person:0x292fbe8>):001:0> local_variables
# => ["name", "age", "_", "__"]
# irb(#<Person:0x292fbe8>):002:0> [name, age]
# => ["Random Person", 23]
# irb(#<Person:0x292fbe8>):003:0> [@name, @age]
# => ["Random Person", 23]
# irb(#<Person:0x292fbe8>):004:0> self
# => #<Person:0x292fbe8 @age=23, @name="Random Person">
# irb(#<Person:0x292fbe8>):005:0> @age += 1; self
# => #<Person:0x292fbe8 @age=24, @name="Random Person">
# irb(#<Person:0x292fbe8>):006:0> @age += 1; self
# Executing break point "Person#name" near file.rb:14
# irb(#<Person:0x292fbe8>):001:0> throw:)debug_return, "Overriden name")
# Name: Overriden name
def breakpoint(id = nil, &block)
Binding.of_caller do |context, extra_data|
file, line = extra_data[1], extra_data[2]
puts "Executing break point #{"#{id.inspect} " if id}near #{file}:#{line}"
catch:)debug_return) do |value|
IRB.start(nil, IRB::WorkSpace.new(context))
block.call if block
end
end
end
alias :break_point :breakpoint

begin
require 'simplecc'
rescue LoadError
def Continuation.create(*args, &block)
cc = nil; result = callcc {|c| cc = c; block.call(cc) if block and args.empty?}
result ||= args
return *[cc, *result]
end
end

# This method returns the binding of the method that called your
# method. It will raise an Exception when you're not inside a method.
#
# It's used like this:
# def inc_counter
# Binding.of_caller do |binding|
# eval("counter += 1", binding)
# end
# end
# counter = 0
# 2.times { inc_counter }
# counter # => 2
#
# You will have to put the whole rest of your method into the
# block that you pass into this method. If you don't do this
# an Exception will be raised. Because of the way that this is
# implemented it has to be done this way. If you don't do it
# like this it will raise an Exception.
def Binding.of_caller(&block)
old_critical = Thread.critical
Thread.critical = true
count = 0
cc, result, error, extra_data = Continuation.create(nil, nil)
error.call if error

tracer = lambda do |*args|
type, context, extra_data = args[0], args[4], args
if type == "return"
count += 1
# First this method and then calling one will return --
# the trace event of the second event gets the context
# of the method which called the method that called this
# method.
if count == 2
# It would be nice if we could restore the trace_func
# that was set before we swapped in our own one, but
# this is impossible without overloading set_trace_func
# in current Ruby.
set_trace_func(nil)
cc.call(eval("binding", context), nil, extra_data)
end
elsif type != "line"
set_trace_func(nil)
error_msg = "Binding.of_caller used in non-method context or " +
"trailing statements of method using it aren't in the block."
cc.call(nil, lambda { raise(ArgumentError, error_msg) }, nil)
end
end

unless result
set_trace_func(tracer)
return nil
else
Thread.critical = old_critical
case block.arity
when 1 then yield(result)
else yield(result, extra_data)
end
end
end
 
D

Daniel Cremer

Hello Daniel,

DC> Hmmm... this sort of reminds me of a post I saw once of someone stating
DC> that if you didn't write your win32 programs in assembly you were going
DC> for the easy option and weren't _really_ a good programmer as you
DC> weren't thinking performance.

DC> I'm very far from considering myself as the prime example of a great
DC> programmer:) , however I'm sure that ruby has taught me a lot,
DC> especially in OO and general design of code. If using C or C++ I simply
DC> go for the "shortest route" possible to get results. In ruby it's not
DC> so. It's so flexible and encouraging that you actually _want_ to think
DC> of various possibilities to solve a problem and find the best fit (short
DC> term and long term).

No this was not exactly my the point. (...)
Ruby is special here because it still is a freak language. Freak in
this context may be substituted with "nerd", "scientist" or "old wise
man". My statement may become more understandable when you look at
the popular scripting languages out there

- PHP
- Java Script
- Perl
- Visual Basic (for Applications)
- TCL
- Python
- Ruby

in this order. And only compare the professionals doing there work
in (at least one of) these languages. At least from my experience in
the last 10 years i see a correlation between the main languages and
there programming skills.

Ok, I get your point and agree with it. I guess what was important for
me was just to point out that part of being good a programmer is picking
the right tool (language) for the task. I have enormous respect for the
"mature" hackers out and have realised it will take me many years of
experience to get anywhere close, including generous helpings of static
languages. However comparisons between static and dynamic languages
sometimes seem unnatural to me. I don't put on my hiking boots to go
dancing. :)

-Daniel
 
D

David Ross

Hmmm... this sort of reminds me of a post I saw once
of someone stating
that if you didn't write your win32 programs in
assembly you were going
for the easy option and weren't _really_ a good
programmer as you
weren't thinking performance.

hehe, well writing programs that are massive in
assembly could take years :)
I'm very far from considering myself as the prime
example of a great
programmer:) , however I'm sure that ruby has taught
me a lot,
especially in OO and general design of code.

Oh indeed, I am not talking about learning new
techniques in scripting languages, but what you don't
learn from using non-scripting(and considered lower by
others, not me(*C,C++,etc)) languages.
If using C or C++ I simply
go for the "shortest route" possible to get results.

Libraries, libraries, libraries! and documentation :)

It also depends on what your definition of a good
programmer is. When I
see someone doing all their web development in C
(yes I've seen that), I
don't think "what a great programmer, he can do the
hardcore stuff". I
think, "why on earth is he using the wrong tools".

weeell... It is certainly possible to create web
applications in even assembly. I have only practiced
with using C. I wish that I could expand on
programming safely with CGI using C. I don't think it
would be considered using a wrong tool. There is
available documentation for reading on the link below.
I just wish there was a more complex C library for
use.

http://www.cgisecurity.com/
There's no way I
would hire such a person, they don't have one of the
basic qualities of
being a programmer: laziness.

Don't watch TV?
Of course I have to agree that I'd have serious
doubts about anyone who
had only ever used scripting languages, as it points
to either
disinterest in programming or a beginner.

You just insulted most people out there :) You
wouldn't imagine how many applications are being made
in.. php..

php irc bots, php mp3 players(they boot an installed
mp3 library), etc.

I also think those people are really full of
themselves.

So do I like Ruby? Yes. I like many things. Ruby is by
far the most dynamic language I have come to interact
with and like the community despite some people who
are blind.

Thanks for your input, much appriciated.

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




__________________________________
Do you Yahoo!?
Yahoo! Mail - You care about security. So do we.
http://promotions.yahoo.com/new_mail
 
D

David Ross

I don't put on my
hiking boots to go
dancing. :)

I do. ;)

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



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

Alexey Verkhovsky

I've done a quick implementation of breakpoints that will spawn an irb
session at the point of the break point in your application yesterday.

LOL. Next time I make a wish on ruby-talk, I should remember that
fairies are reading it, too :)

Thanks a lot!

Alex
 
L

Lothar Scholz

Hello Alexey,

AV> In most cases main loop or somewhere quite close to that is precisely
AV> the right place to handle exceptions, provided that "ensure" clause (or
AV> Java "finally") is used judiciously to close things like database
AV> connections and other expensive resources.

One of the problems are that far to many Java exceptions are not
exceptions but simple program control flow operations for things that
happen not very often.

As an Eiffel programmer i have of course another opinion to this.
 
M

Mark Probert

David Ross said:
With Most scripting languages which have
safety protection force the programmer not to even
think about the underlying code. With this, this is
the proof of why scripting language programmers are
not as good as per sey..

For me, programming languages are like tools. A good tradesman uses the
right tools for the job. The right tool is the one that makes works best
to achieve the desired outcome. A bad tradesman only is best described as
the one who uses a hammer to put in a screw, 'cause they only know how to
use hammers, not screw drivers.

Ofcourse, real programmers use microcode, ASM and FORTH.

;-)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,995
Messages
2,570,230
Members
46,818
Latest member
Brigette36

Latest Threads

Top