Forum: Ruby Ruby vs PHP for the web

A0a20335a2e89b30a3d4948866af11ee?d=identicon&s=25 Ruby Me (rubyme)
on 2010-11-04 02:49
Hi

I am not here to say that PHP is better or the opposite, I am here to
ask, how web development in Ruby compared to PHP. Does Ruby use the same
tools? for example MySQL and Apache?

And the most interesting point, which language can create a web
application with less code? (I am talking about the languges not the
frameworks).


Thanks.
E5a40ecaf45692b8692e9ac6e8c67610?d=identicon&s=25 wroxdb (Guest)
on 2010-11-04 03:25
(Received via mailing list)
2010/11/4 Ruby Me <i_baseet@hotmail.com>:

> And the most interesting point, which language can create a web
> application with less code? (I am talking about the languges not the
> frameworks).
>

But Ruby with Rails does create a web app with much less code than
others.
5b2b0852d464f20072e6c1961784a6c8?d=identicon&s=25 Rajinder Yadav (Guest)
on 2010-11-04 08:53
(Received via mailing list)
On 10-11-03 09:49 PM, Ruby Me wrote:
> Hi
>
> I am not here to say that PHP is better or the opposite, I am here to
> ask, how web development in Ruby compared to PHP. Does Ruby use the same
> tools? for example MySQL and Apache?

yes it works with the same DBs and others, not sure what you mean by
same tools?

>
> And the most interesting point, which language can create a web
> application with less code? (I am talking about the languges not the
> frameworks).
>
> Thanks.
>

Why not do something in PHP and then try doing the same thing in Ruby &
Rail, what speaks to you will be the better choice for you!

Here is a rails 3 screencast to give you an idea about rails 3

http://rubyonrails.org/screencasts/rails3


--
Kind Regards,
Rajinder Yadav | DevMentor.org | Do Good! ~ Share Freely

GNU/Linux: 2.6.35-22-generic
Kubuntu x86_64 10.10 | KDE 4.5.1
Ruby 1.9.2p0 | Rails 3.0.1
D1309ef77561e3cdf0ddcab60b244e52?d=identicon&s=25 Mike Stephens (aspirer)
on 2010-11-04 08:59
If you use eRuby, then the two are very similar in the way you code, the
way you inter-operate with middleware, and in the amout of code needed.
753dcb78b3a3651127665da4bed3c782?d=identicon&s=25 Brian Candler (candlerb)
on 2010-11-04 14:48
Mike Stephens wrote in post #959251:
> If you use eRuby, then the two are very similar in the way you code, the
> way you inter-operate with middleware, and in the amout of code needed.

That's true, but I'd say that most ruby app designers don't write their
app logic within eruby.

To try a different way of doing things, have a look at Sinatra. A
starter Sinatra app is 4 lines:

require "sinatra"
get "/" do
  "Hello world!"
end

Run your app standalone from the commandline, or from within Apache or
Nginx using Phusion Passenger.

Your next step would be to use templates for response pages - templates
can either be stored inline, or in separate files - and helper methods
for code snippets to be called within templates. Then connect it to a
database using an ORM layer of your choice.

eruby is one of many choices for template languages (I prefer HAML), but
what you're trying to do is keep your request processing logic out of
the template, and centralised in your application code.
1797efbfae933c5eac9611e1724f7345?d=identicon&s=25 Jose Hales-Garcia (Guest)
on 2010-11-04 15:45
(Received via mailing list)
On Nov 3, 2010, at 6:49 PM, Ruby Me wrote:

> I am not here to say that PHP is better or the opposite, I am here to
> ask, how web development in Ruby compared to PHP. Does Ruby use the same
> tools? for example MySQL and Apache?

I went from PHP to Rails and have never looked back.  I recommend using
Rails 3.  It easily connects to MySQL and PostgreSQL.  Running
development code is quick as it comes with a built-in web server and
database.

I don't know if you're using the Zend framework, but Rails is a MVC
framework.  Zend's framework is relatively new and came out after I made
my switch to Rails.  I also haven't compared Rails to Python's Django.
I have used WebObjects though, and I find Rails to be extremely elegant
with respect to that system.

> And the most interesting point, which language can create a web
> application with less code? (I am talking about the languges not the
> frameworks).

Ruby, the language that facilitates Rails and all the other favorite
frameworks, is unequivocally less code.  It's a big reason why I won't
go back to PHP.

Jose
.......................................................
Jose Hales-Garcia
UCLA Department of Statistics
jose.halesgarcia@stat.ucla.edu
A0a20335a2e89b30a3d4948866af11ee?d=identicon&s=25 Ruby Me (rubyme)
on 2010-11-05 03:11
Thank you guys,

It would be helpful if anyone writes any conde in PHP and then writing
it in Ruby? I want to see the difference and how the code will be less.
5b2b0852d464f20072e6c1961784a6c8?d=identicon&s=25 Rajinder Yadav (Guest)
on 2010-11-05 06:12
(Received via mailing list)
On 10-11-04 10:11 PM, Ruby Me wrote:
> Thank you guys,
>
> It would be helpful if anyone writes any conde in PHP and then writing
> it in Ruby? I want to see the difference and how the code will be less.
>
you must be sitting in agony trying to decide between php and ruby =P,
code is only half the battle, with rails it comes with code generators
and rake tasks which make life really easy for a web developer! you're
not going to see this if some cut-n-paste static code!

please don't ask a ruby or rails developer to write php code samples for
you, it's just inhumane! =P

--
Kind Regards,
Rajinder Yadav | DevMentor.org | Do Good! ~ Share Freely

GNU/Linux: 2.6.35-22-generic
Kubuntu x86_64 10.10 | KDE 4.5.1
Ruby 1.9.2p0 | Rails 3.0.1
34339790bbfb524b877a79d8af706e9c?d=identicon&s=25 Ammar Ali (ammar)
on 2010-11-05 08:17
(Received via mailing list)
On Fri, Nov 5, 2010 at 7:11 AM, Rajinder Yadav <devguy.ca@gmail.com>
wrote:
>
> please don't ask a ruby or rails developer to write php code samples for
> you, it's just inhumane! =P

I agree. With all those dollar signs, arrows (->), and mandatory
semicolons, it's like licking sandpaper. And that's just the syntax.

Cheers,
Ammar
161289732b5b8c9dcb5834a3f0535340?d=identicon&s=25 Chad Perrin (Guest)
on 2010-11-05 09:01
(Received via mailing list)
On Fri, Nov 05, 2010 at 11:11:18AM +0900, Ruby Me wrote:
> Thank you guys,
>
> It would be helpful if anyone writes any conde in PHP and then writing
> it in Ruby? I want to see the difference and how the code will be less.

As someone who has written a fair bit of both PHP and Ruby for the Web
over the years -- and very little of the Ruby actually using something
like Rails -- I think I know something about the subject when I say
this:

1. Code snippets will not give you a good idea of how much one or the
other might save you any total code weight in the final version.  Pick
one small task that can be represented in a small snippet, and one
language wins; pick another, and the other small task wins.  In fact,
for
the smallest tasks, PHP will almost certainly win because of its
literally *thousands* of core functions -- which, by the way, is *not* a
sign of good language design.  Last I checked, there were about 3100
core
functions, which is *obscenely* complex for a procedural language, and
pollutes the main namespace of the language to an insane degree.

2. Final code weight to accomplish a specific task is nowhere near the
same thing as the amount of code you have to *write*, anyway.  A lot of
code that gets written for any given non-trivial project is ultimately
deleted, usually to be replaced by other code.  One of the benefits of
Ruby is that it tends to lend itself to finding the "right" idiom for a
given task sooner rather than later.  PHP is not as good at that, and
tends to require a heck of a lot of refactoring as it scales up past the
size of a relatively trivial application.  A lot of projects simply do
not do that much refactoring, but the end result is a largely
unmaintainable mess of an application, like WordPress.  Reading the
source of WordPress is a bit like using thumbtacks for contact lenses.

3. Ruby's object model lends itself to far better code organization than
anything PHP offers.  This means that, even in cases where Ruby might
have the same amount of source code (or even more) to accomplish the
same
task, it's a lot easier to understand because of the way it can be
divided up into discrete chunks that make sense.  PHP's unreasonable
facsimile of an object model and bolted-on half-baked namespace support,
by contrast, tends to creak under its own weight when developing any
nontrivial application.

All told, PHP is easier to use for the most trivial, single-page dynamic
templates, and harder to use to accomplish for anything more meaningful.
If all you're going to do is maintain a simplistic Website that contains
nothing but a little bit of simple logic in otherwise static pages,
perhaps populating some content areas from a couple of extra files, and
learn as little as possible, you might want to go with PHP.  If you're
going to do some real programming, though, I recommend Ruby; it'll
facilitate development more on larger projects, it'll encourage better
coding practices, and it'll be more fun.

A lot of people complain about the superficial ugliness of Perl.  PHP,
however, inherits pretty much all of Perl's flaws as a language, and
almost none of its benefits.  Ruby inherits a substantial percentage of
Perl's benefits, and not so many of its flaws -- even by the markedly
uncharitable opinion of what constitutes a "flaw" that may Pythonistas
would give you.

I have recently stumbled across a brilliant characterization of PHP as
training wheels without the bike.  It's hilarious -- and having used
Ruby
for a while, it feels pretty true, too.  I suppose your mileage may
vary.

Note that a lot of this has been a liberal mix of opinion and fact.  I
encourage you to *think* about what I said and do a little investigating
to confirm what I've said for yourself, rather than just taking my word
for it.  If you want my opinion, though, it's easily summed up:

I'm glad I don't have to write PHP these days.
5535295c69d23b872494f6b137badf4d?d=identicon&s=25 Andola Soft (andolasoft)
on 2010-11-08 14:56
For creating a web application, you need to use ruby on rails and not
simply ruby. of course you can create application with much less code
and you don't have to write sql queries as in PHP; database interface
can be handled with object relational mapping in RoR.
Ac0085dae0703db56ad7f8cb9e1798ba?d=identicon&s=25 Phillip Gawlowski (Guest)
on 2010-11-08 15:19
(Received via mailing list)
On Mon, Nov 8, 2010 at 2:56 PM, Andola Soft <call@andolasoft.com> wrote:
> For creating a web application, you need to use ruby on rails and not
> simply ruby. of course you can create application with much less code
> and you don't have to write sql queries as in PHP; database interface
> can be handled with object relational mapping in RoR.

Correction: You *can* use Rails or any other Ruby-based webframework,
but you don't *have* to, nor do you *need* no.

--
Phillip Gawlowski

Though the folk I have met,
(Ah, how soon!) they forget
When I've moved on to some other place,
There may be one or two,
When I've played and passed through,
Who'll remember my song or my face.
1aad4121bdf6ac299a03a2371af993ae?d=identicon&s=25 Oliver Schad (Guest)
on 2010-11-08 16:15
(Received via mailing list)
Ruby Me wrote:

> And the most interesting point, which language can create a web
> application with less code? (I am talking about the languges not the
> frameworks).

Ruby cause of the high dynamic approach and a cleaner language design.

Ruby allows you to build DSLs (Rails is such a thing) to make things
shorter. You have to understand that the Ruby language itselfs can be
modified (not the whole language but parts).

A important thing is DRY, don't repeat yourself. Ruby allows you to
write programs where you don't have to double your code many times.

In many languages you can see, how people have to copy'n'paste code and
modifiy only small things. It's not the way how to do this in ruby.

Yes, you can repeat yourself in Ruby, but you don't have to as much as
in other languages.

I read the online documentation about ruby and thought: Great, this
people made concepts first and tried to repeat this concepts in every
piece of the language. So you have an very consistent language with less
pit falls.

One thing is: Everything is an object. Yes, it means, everything is an
object and you can use the pattern of an object everywhere.

Another thing is: Everything is dynamic. So you can change an object and
a class at runtime (a class is an object too but at a higher level), can
define new methods. Yes, the internals of the language are objects and
you can work with them like any other object.

This is simply GREAT. With this dynamic approach you can build your own
DSL.

And the third thing is very important: Every piece of code can be
handled as an object. So you can write methods, which expects code as a
argument. This is a very heavy used concept in Ruby and is called
"blocks" where the given code is the so called block.

You write for example an algorithm for traversing a data structure. And
you have code which can handle the or some elements of the structure. In
Ruby you can easily split this code into two parts. You should do this
because the two problems, knowledge about the data structure and
knowledge about the elements are complete independent from each other.

You could exchange the elements with other types of elements and you had
to traverse the data structure the same way.

Or you could use the elements somewhere else in another data structure.

So you should split the code and ruby supports you very well on that
task.

So you can write shorter, cleaner and less error prone code. And yes,
writing ruby code is much more fun than writing PHP. You can feel the
support for abstraction. On the other side writing PHP code feels like
walking through a shelter. You feel thick walls everywhere. The language
controls you very hard.

Regards
Oli
161289732b5b8c9dcb5834a3f0535340?d=identicon&s=25 Chad Perrin (Guest)
on 2010-11-08 18:38
(Received via mailing list)
On Mon, Nov 08, 2010 at 11:18:24PM +0900, Phillip Gawlowski wrote:
> On Mon, Nov 8, 2010 at 2:56 PM, Andola Soft <call@andolasoft.com> wrote:
> > For creating a web application, you need to use ruby on rails and not
> > simply ruby. of course you can create application with much less code
> > and you don't have to write sql queries as in PHP; database interface
> > can be handled with object relational mapping in RoR.
>
> Correction: You *can* use Rails or any other Ruby-based webframework,
> but you don't *have* to, nor do you *need* no.

In fact, you do not need any framework at all.  Ruby can be run
comfortably via CGI, mod_ruby, or eruby, for instance (and I, at least,
wouldn't call eruby a "framework").
B2b20140efe14944692ab82a08f9b1c7?d=identicon&s=25 Charles Calvert (Guest)
on 2010-11-10 19:51
(Received via mailing list)
On Wed, 3 Nov 2010 20:49:22 -0500, Ruby Me <i_baseet@hotmail.com>
wrote in <1cd601a47b01edd27940e192d7465996@ruby-forum.com>:

>I am not here to say that PHP is better or the opposite, I am here to
>ask, how web development in Ruby compared to PHP. Does Ruby use the same
>tools? for example MySQL and Apache?

As others have said, yes.  There are Ruby libraries to allow you to
use most, possibly even all, of the external resources that you're
used to using from PHP.  Examples include MySQL, PostreSQL,
ImageMagick, encryption libraries, etc.

>And the most interesting point, which language can create a web
>application with less code? (I am talking about the languges not the
>frameworks).

That's not really a useful question, as it's fairly uncommon to create
web applications without a framework of some sort these days.

Having worked with both, I'll tell you why I like Ruby a lot more than
PHP.

1. PHP is a poorly designed language that suffers from a number of
problems, including design by committee and the misguided effort to
"make programming easy for nonprogrammers".  Google "PHP sucks" and
you'll find plenty of detailed articles enumerating the issues with
PHP.  Some of these have been corrected (or at least deprecated) in
version 5 and more will be corrected in version 6, but others are
still there, notably the horrible inconsistencies in the standard
library.

2. PHP's support (in version 5) for OO programming is rather anemic.
You get single inheritance only; there is no support for multiple
inheritance or mixins.  While you can use __get() and __set() to
implement properties
<http://en.wikipedia.org/wiki/Property_%28programming%29>, this is
nasty and can lead to huge switch statements on classes of any
complexity.  The standard library is still heavily procedural.  It
doesn't support namespaces.

Ruby has mixins, which makes multiple inheritance less necessary and
properties (called attributes).  Namespaces can be faked using
modules.  Finally, Ruby was designed to be an OO language from the
beginning, while PHP has tacked OO features onto a procedural
language.

3. PHP uses weak typing, which leads to all sorts of problems with
ensuring that code behaves the way that you intended.  Ruby uses
strong, though dynamic, typing.

4. There are a ton of very cool tools surrounding Ruby that can make
your life a lot easier.  PHP has many fewer of these.

5. Ruby attracts smart, experienced programmers.  PHP attracts people
who are new to programming.  Don't underestimate this one.  If you're
going to interact with a community and learn from people, which of
these would you pick?
D1309ef77561e3cdf0ddcab60b244e52?d=identicon&s=25 Mike Stephens (aspirer)
on 2010-11-11 23:48
Charles Calvert wrote in post #960599:
>  Ruby uses
> strong, though dynamic, typing.

Can you explain what you mean? That seems a contradiction in terms.
E088bb5c80fd3c4fd02c2020cdacbaf0?d=identicon&s=25 "Jesús Gabriel y Galán" <jgabrielygalan@gmail.com> (Guest)
on 2010-11-12 09:07
(Received via mailing list)
On Thu, Nov 11, 2010 at 11:50 PM, Mike Stephens <rubfor@recitel.net>
wrote:
> Charles Calvert wrote in post #960599:
>> Ruby uses
>> strong, though dynamic, typing.
>
> Can you explain what you mean? That seems a contradiction in terms.

http://en.wikipedia.org/wiki/Strong_typing

It means that the language imposes restrictions about how different
types are mixed, and avoids implicit conversions of types, among other
things. Compare:

Javascript (weak typing):

2 + '2' => '22'

Ruby (strong typing):

2 + '2' => TypeError: String can't be coerced into Fixnum

On the other hand:

http://en.wikipedia.org/wiki/Dynamic_typing#Dynamic_typing

Most of the type checking (if there actually is some type checking) is
done at runtime, and while values have types variables do not:

Java (static typing):

int i = 3;
i = "abc" => Error

Ruby (dynamic typing):

i = 3
i = "abc"

It's also related to the very powerful duck typing, which you can search
around.

Jesus.
B31e7abd14f1ceb4c4957da08933c630?d=identicon&s=25 Josh Cheek (josh-cheek)
on 2010-11-12 13:54
(Received via mailing list)
2010/11/12 Jess Gabriel y Galn <jgabrielygalan@gmail.com>

> It means that the language imposes restrictions about how different
>
Is Ruby strongly typed?

2 + 2.0 # => 4.0

Here it has implicitly converted the integer 2 to a float, in order to
be
able to add them. You can even make your specific example pass, exactly
as
written, by defining String#coerce:

class String
  def coerce(num)
    return num.to_s , self
  end
end

2 + '2' # => "22"
E088bb5c80fd3c4fd02c2020cdacbaf0?d=identicon&s=25 "Jesús Gabriel y Galán" <jgabrielygalan@gmail.com> (Guest)
on 2010-11-12 14:28
(Received via mailing list)
On Fri, Nov 12, 2010 at 1:54 PM, Josh Cheek <josh.cheek@gmail.com>
wrote:
>> http://en.wikipedia.org/wiki/Strong_typing
>>
> written, by defining String#coerce:
>
> class String
> def coerce(num)
>  return num.to_s , self
> end
> end
>
> 2 + '2' # => "22"
>

I know that, but that's not an implicit conversion performed by the
compiler, it's explicitly implemented in the classes.

Citing from the above wikipedia article:

The object-oriented programming languages Smalltalk, Ruby, Python, and
Self are all "strongly typed" in the sense that typing errors are
prevented at runtime and they do little implicit type conversion,

Also, in Ruby, you cannot change the class of an object.

Jesus.
E0d864d9677f3c1482a20152b7cac0e2?d=identicon&s=25 Robert Klemme (Guest)
on 2010-11-12 14:30
(Received via mailing list)
On Fri, Nov 12, 2010 at 1:54 PM, Josh Cheek <josh.cheek@gmail.com>
wrote:
>> http://en.wikipedia.org/wiki/Strong_typing
>>
>> 2 + '2' => TypeError: String can't be coerced into Fixnum
>>
>
>
> Is Ruby strongly typed?
>
> 2 + 2.0 # => 4.0
>
> Here it has implicitly converted the integer 2 to a float, in order to be
> able to add them.

Strongly typed because there is no _implicit_ conversion.

> You can even make your specific example pass, exactly as
> written, by defining String#coerce:

Exactly: this is an *explicit* conversion of types.  Implicit
conversion would be if Ruby would convert 2 to 2.0 *before* invoking a
"float + operator".  But in Ruby just method :+ is invoked on instance
2 which internally uses the coerce mechanism to (hopefully) get two
instance which can properly work out how to +.

See
http://blog.rubybestpractices.com/posts/rklemme/01...

> class String
> def coerce(num)
>  return num.to_s , self
> end
> end
>
> 2 + '2' # => "22"

There seems to be some disagreement what exactly "strongly" and
"weakly" means here.  This becomes apparent of you read the
complementary article on http://en.wikipedia.org/wiki/Weak_typing in
Wikipedia.

Kind regards

robert
D1309ef77561e3cdf0ddcab60b244e52?d=identicon&s=25 Mike Stephens (aspirer)
on 2010-11-12 17:35
Robert Klemme wrote in post #960960:
>
>
> There seems to be some disagreement what exactly "strongly" and
> "weakly" means here.

To me it's pretty straightforward. An object of Class A cannot be
treated as an object of Class B - the language system detects and
prevents this. Ruby does not follow this approach. It uses duck typing
which is the opposite.
B31e7abd14f1ceb4c4957da08933c630?d=identicon&s=25 Josh Cheek (josh-cheek)
on 2010-11-12 18:04
(Received via mailing list)
2010/11/12 Jess Gabriel y Galn <jgabrielygalan@gmail.com>

> I know that, but that's not an implicit conversion performed by the
> compiler, it's explicitly implemented in the classes.
>
>
Gotcha, so if that same thing happened when the code was interpreted
rather
than when the addition method invoked coerce, then it would be weak
typing.


> Also, in Ruby, you cannot change the class of an object.
>
>
I've seen some black magick ^_^
http://rubyconf2008.confreaks.com/evil-code.html 4m55s
0e6ac58dab6125c1cd2e7ac645076b6f?d=identicon&s=25 Joel VanderWerf (Guest)
on 2010-11-12 19:08
(Received via mailing list)
On 11/12/2010 08:35 AM, Mike Stephens wrote:
> Robert Klemme wrote in post #960960:
>>
>>
>> There seems to be some disagreement what exactly "strongly" and
>> "weakly" means here.
>
> To me it's pretty straightforward. An object of Class A cannot be
> treated as an object of Class B - the language system detects and
> prevents this. Ruby does not follow this approach. It uses duck typing
> which is the opposite.

What makes this so slippery a question is what "treat as" means.

Does

   a = [1,2,3]
   s = "count = #{a.length}"

mean that a Fixnum is treated as a String? It may look so at first
glance. But what's really happening is that #to_s is called on the
Fixnum. So String interpolation is using, as you say, duck typing, to
convert types. I don't really know whether this counts as "treat as" or
not.

IMO, the most clear-cut example of weak typing is this:

$ cat a.c
#include <stdio.h>
main(){
   float x = 1.23;
   printf("%d\n", (int)x);
   printf("%d\n", *(int*)&x);
}

$ gcc a.c
$ ./a.out
1
1067282596

Not even perl is weakly typed, in this sense.
E0d864d9677f3c1482a20152b7cac0e2?d=identicon&s=25 Robert Klemme (Guest)
on 2010-11-12 20:51
(Received via mailing list)
On 11/12/2010 05:35 PM, Mike Stephens wrote:
> Robert Klemme wrote in post #960960:
>>
>> There seems to be some disagreement what exactly "strongly" and
>> "weakly" means here.
>
> To me it's pretty straightforward. An object of Class A cannot be
> treated as an object of Class B - the language system detects and
> prevents this. Ruby does not follow this approach. It uses duck typing
> which is the opposite.

So you are claiming that Ruby is weakly typed.  It is not.  Ruby does
not allow an instance of A to be treated as an instance of B.  Duck
typing really only means that Ruby does not have interfaces and uses
dynamic typing.  In other words, all instances answering a particular
set of methods can be used in a piece of code, e.g.

def append(a,b)
   a << b
end

append $stderr, "Last warning!"
append ARGV, "--help"
append [1,2,3], 4

See also Joel's example from C.  This is not possible in Ruby.

Kind regards

  robert
Be07c8d0d6867fd9a0d525f7d17600e2?d=identicon&s=25 Damjan Rems (ther)
on 2010-11-12 21:30
Ruby Me wrote in post #959480:
> Thank you guys,
>
> It would be helpful if anyone writes any code in PHP and then writing
> it in Ruby? I want to see the difference and how the code will be less.

I had 15 years of programing after me when I ended my programing carrier
and got a job as system administrator. My skills were mostly with
languages with little code to write. I Started with RPG on IBM
mainframes and ended with Clipper on DOS and windows.

But since programming is like a hobby I tried to learn something new and
in early 2000 PHP looked like a good language(Java to me is like a
Cobol. Too much lines about nothing). But I never got really into it. As
example I had a program which has created dates to schedule Backup Exec
jobs for a whole year and write result to file. About 60 lines in
Clipper. It took me about 3 days when I start learning PHP and I ended
up with 150 lines. But I never did anything sirius in PHP.

Few years later I heard about Ruby. It looked really cool. I had the
same program written after 4 hours of learning and in 35 lines. And
after that I didn't done any program again in any other language. 3
months later I installed rails and done my first web application after
another month (I knew something about HTML before).

I've been using ruby for 5 years now. And I don't use anything else. I
script Linux, Windows, web apps with rails. It is so simple. I have
programmed Intranet application in my company which connects to Oracle,
MS-SQL, Postgres (my favorite). And thats from the guy who never thought
that would ever make a program for Internet.

by
TheR
161289732b5b8c9dcb5834a3f0535340?d=identicon&s=25 Chad Perrin (Guest)
on 2010-11-15 05:51
(Received via mailing list)
On Sat, Nov 13, 2010 at 01:35:41AM +0900, Mike Stephens wrote:
> Robert Klemme wrote in post #960960:
> >
> >
> > There seems to be some disagreement what exactly "strongly" and
> > "weakly" means here.
>
> To me it's pretty straightforward. An object of Class A cannot be
> treated as an object of Class B - the language system detects and
> prevents this. Ruby does not follow this approach. It uses duck typing
> which is the opposite.

Not quite.  The type of an object of class A is never changed.  Rather,
a
method of class A is executed to produce a return value of class B.  The
class of the object of class A never changes.

    :~> irb
    irb(main):001:0> a = 3
    => 3
    irb(main):002:0> a.class
    => Fixnum
    irb(main):003:0> b = "foo"
    => "foo"
    irb(main):004:0> c = "#{b} #{a}"
    => "foo 3"
    irb(main):005:0> a.class
    => Fixnum

Would you prefer that a programming language have no way to do anything
with an integer in conjunction with a string if it's called "strong
typing"?
D1309ef77561e3cdf0ddcab60b244e52?d=identicon&s=25 Mike Stephens (aspirer)
on 2010-11-15 08:55
Robert Klemme wrote in post #961079:
> Duck typing really only means that Ruby does not have interfaces and >uses
dynamic typing.

OK so what's the difference between dynamic typing and weak typing?

My take on strong typing is you cannot assign an object of Type A to a
variable of Type B unless you use a transform method so you convince the
'compiler' you intended to do this (and such a method exists). It's more
to do with trapping programmer errors than to do with making compilers'
lives easy. Where that leaves you on adding (etc) an object of Type A to
an object of Type B is less clear but I would be inclined to think that
falls into the same camp.
E0d864d9677f3c1482a20152b7cac0e2?d=identicon&s=25 Robert Klemme (Guest)
on 2010-11-15 09:31
(Received via mailing list)
On Mon, Nov 15, 2010 at 8:57 AM, Mike Stephens <rubfor@recitel.net>
wrote:
> Robert Klemme wrote in post #961079:
>> Duck typing really only means that Ruby does not have interfaces and >uses
> dynamic typing.
>
> OK so what's the difference between dynamic typing and weak typing?

Dynamic typing only says something about _when_ types are evaluated.
In dynamically typed languages variables typically do not have a type
and typing is enforced at runtime.

Weak typing OTOH is about _what_ you can do with "something".  In C
you can easily cast a char* to a int* and use it as that (e.g. for
math).  That's weak typing.  Such things are impossible in a strongly
typed language - either dynamic or static typed.

> My take on strong typing is you cannot assign an object of Type A to a
> variable of Type B unless you use a transform method so you convince the
> 'compiler' you intended to do this (and such a method exists).

You describe a language with strong typing *and* static typing.  In a
language which does not have static typing the statement you make is
meaningless because variables do not have a type there (as in Ruby).

> It's more
> to do with trapping programmer errors than to do with making compilers'
> lives easy.

That is a description of a goal but not of a technology.

> Where that leaves you on adding (etc) an object of Type A to
> an object of Type B is less clear but I would be inclined to think that
> falls into the same camp.

The mere fact that you can add a string and an integer does not tell
you much about the nature of the type system.  In Ruby you have
#coerce and in C++ you have operator overloading.  Both languages are
statically typed.  If you define an operator like in the C++ program
below you still have static and strong typing (at least for this piece
of code, you can still cast via void* in C++) even though you can add
strings and integers.

Kind regards

robert


#include <string>

int operator + (const std::string& s, const int i) {
  return i + s.length();
}


int main(int argc, char* argv[]) {
  std::string x(argv[0]);
  return x + argc;
}
E0d864d9677f3c1482a20152b7cac0e2?d=identicon&s=25 Robert Klemme (Guest)
on 2010-11-15 10:08
(Received via mailing list)
On Mon, Nov 15, 2010 at 9:30 AM, Robert Klemme
<shortcutter@googlemail.com> wrote:

> The mere fact that you can add a string and an integer does not tell
> you much about the nature of the type system. In Ruby you have
> #coerce and in C++ you have operator overloading. Both languages are
> statically typed.

Typo!!! This should of course have read "strongly typed".

Sorry

robert
B36389b7f60f41b4f97f48c8fe9e6fe4?d=identicon&s=25 James Vince (james0vince)
on 2010-11-15 10:45
PHP has more lines of code in the actual File than ruby. If you take a
controller (in Rails) and compare it to a PHP program, PHP has more
lines of code. However Ruby has libraries to do most of this code for
you, if you include the libraries that you use Ruby has much more lines
of code.

But because people who program Object Oriented Code tend to consider
library code to not part of the actual program (as it is part of the
API) they see it as "the actual code you write is less".

Having large libraries of code (coupled with the fact that Ruby has a
slow interpreter) does make Ruby somewhat slower performance wise,
however a Ruby programer would argue that because Ruby language is more
efficient that PHP by re-using code and by using symbols where necessary
instead of strings that makes up for it's slow rendering time.
C2c9a9a76a9e859e4bd00cfda181c660?d=identicon&s=25 Tony Arcieri (Guest)
on 2010-11-15 12:37
(Received via mailing list)
Cool story, bro
E0d864d9677f3c1482a20152b7cac0e2?d=identicon&s=25 Robert Klemme (Guest)
on 2010-11-15 12:56
(Received via mailing list)
On Mon, Nov 15, 2010 at 10:45 AM, James Vince <me@jamesvince.net> wrote:
> PHP has more lines of code in the actual File than ruby. If you take a
> controller (in Rails) and compare it to a PHP program, PHP has more
> lines of code. However Ruby has libraries to do most of this code for
> you, if you include the libraries that you use Ruby has much more lines
> of code.

That sounds convincing on first sight yet I am missing hard facts.
Can you put figures on this for a concrete application?  We could
start with versions of Ruby and PHP you are comparing here.

> But because people who program Object Oriented Code tend to consider
> library code to not part of the actual program (as it is part of the
> API) they see it as "the actual code you write is less".

Which is true of course.  You only need to write and test your own
code and can rely on the library author's QA for their code.  Of
course, from time to time you'll find a bug in library code as well.

> Having large libraries of code (coupled with the fact that Ruby has a
> slow interpreter) does make Ruby somewhat slower performance wise,
> however a Ruby programer would argue that because Ruby language is more
> efficient that PHP by re-using code and by using symbols where necessary
> instead of strings that makes up for it's slow rendering time.

Again, this sounds convincing on first sight but it actually isn't.
Using a library does not automatically mean that more code is executed
or an application is slower.  Without hard facts all these statements
stand on a very shaky ground and I would certainly not base my choice
of language or framework on what you wrote.

Kind regards

robert
34339790bbfb524b877a79d8af706e9c?d=identicon&s=25 Ammar Ali (ammar)
on 2010-11-15 13:32
(Received via mailing list)
On Mon, Nov 15, 2010 at 11:45 AM, James Vince <me@jamesvince.net> wrote:
> PHP has more lines of code in the actual File than ruby. If you take a
> controller (in Rails) and compare it to a PHP program, PHP has more
> lines of code. However Ruby has libraries to do most of this code for
> you, if you include the libraries that you use Ruby has much more lines
> of code.

This is not entirely true. PHP does not have a "standard library",
instead all functionality is either built into the interpreter or
comes in an extension. If you take PEAR into account then the higher
number of LOCs that is characteristic of PHP will change the picture.
As for frameworks, Zend looks pretty bloated to me for what it does.
Rails might be bigger, LOC wise, but it does a lot more too.

> But because people who program Object Oriented Code tend to consider
> library code to not part of the actual program (as it is part of the
> API) they see it as "the actual code you write is less".

I believe Ruby's libraries tend to have less code than PHP's
libraries. Even though I don't have numbers to back this up, I have a
hunch that mixins in Ruby, which PHP doesn't have, play a role in
reducing the LOC count in libraries.

> Having large libraries of code (coupled with the fact that Ruby has a
> slow interpreter) does make Ruby somewhat slower performance wise,
> however a Ruby programer would argue that because Ruby language is more
> efficient that PHP by re-using code and by using symbols where necessary
> instead of strings that makes up for it's slow rendering time.

Large libraries of code do not necessarily mean lower performance
overall. Ruby's parser is very fast, and once the is code loaded, and
cached by the OS/FS, the effect of it's size on performance is
negligible. Unless the code is being reloaded on every rendering
request, of course, which should not be done if one is concerned with
performance.

Regards,
Ammar
A5dbf79f90041e79418a6829d414b46e?d=identicon&s=25 John Morrice (Guest)
on 2010-11-15 14:23
(Received via mailing list)
> Having large libraries of code (coupled with the fact that Ruby has a
> slow interpreter) does make Ruby somewhat slower performance wise,
> however a Ruby programer would argue that because Ruby language is
> more efficient that PHP by re-using code and by using symbols where
> necessary instead of strings that makes up for it's slow rendering
> time.

Neither PHP or Ruby are high-performance languages. [1]  To bring up the
obvious example, neither are (usually) compiled.

So it seems a little strange to compare the two in this manner.  Kinda
like racing snails! (Cute little snails...)

In the functional programming community, a language design is deemed to
be elegant when it has a small 'core', because then you get
benefits like not needing lots of syntax, a more organized compiler -
indeed, this minimalism is something the functional community strive
for! [2]

I'm don't know how Ruby is implemented, but it certainly *feels* like a
small language, at least to me.  Initializing an object - a method
call.  Defining a class can be done with method calls.  All you need
are methods and objects, and constants:

A = Class.new

A.module_eval do
   def neatsville
      puts "That's Jazz"
   end
end

a = A.new
a.neatsville

=> That's Jazz

It's easy to see how the more traditional way of defining a class can
be decomposed into these simpler operations - this is definitely
subjective, but from a minimalist point of view that is a *good thing*.

How would you do this with PHP?  Is it even possible?  Someone else will
have to take this up, for I am a PHP noob.

[1] Ruby and PHP are both close to the bottom of the (flawed) benchmarks
  game, way outpaced by rockets like Javascript and Smalltalk...
http://shootout.alioth.debian.org/u32/which-progra...

[2] Simon Peyton Jones - Implementing functional languages: a
tutorial.  The chapter on the G-Machine is quite accessible.
http://research.microsoft.com/en-us/um/people/simo...

Johnny
32bbfde7d847fc0f82804c4c26cf64a6?d=identicon&s=25 Kenneth Leung (lkfken)
on 2010-11-16 20:31
(Received via mailing list)
On Nov 3, 5:49pm, Ruby Me <i_bas...@hotmail.com> wrote:
> Thanks.
>
> --
> Posted viahttp://www.ruby-forum.com/.

I wrote programs in Assembly.
I wrote programs in BASIC (i know...but it was considered IN during
the 70s/early 80s), then PASCAL, JAVA, and now Ruby.

If you have develop programs in Assembly before, then you'd know you
have write so many lines in order for it to do so little...

Thus comparing number of lines is really pointless, because if you
want, you could add a lot more lines yourself by not using any
"standard libraries"

This is one of the reasons why OOP is the mainstream now -- re-
usability.
But the trade off of this re-usability is "performance".  This is due
to all the overheads you added by using the "standard libraries"  But
this could be neglected with better hardware performance...

So to answer your question, you have to tell us WHY you want to create
a web application with less code?  If you answer is "Performance,"
then you picked a wrong measurement (# of lines).  Instead you should
use "number of cycles"

Kenneth Leung
0424443e8fdddae8327187cd2c6a2a01?d=identicon&s=25 zuerrong (Guest)
on 2010-11-17 09:09
(Received via mailing list)
2010/11/12 Jesús Gabriel y Galán <jgabrielygalan@gmail.com>:

>
> Javascript (weak typing):
>
> 2 + '2' => '22'
>

And even worse:

$ perl -le 'print 2+"2"'
4
E0d864d9677f3c1482a20152b7cac0e2?d=identicon&s=25 Robert Klemme (Guest)
on 2010-11-17 09:41
(Received via mailing list)
On Tue, Nov 16, 2010 at 8:30 PM, lkfken <alpha.azieru@gmail.com> wrote:
> On Nov 3, 5:49pm, Ruby Me <i_bas...@hotmail.com> wrote:

>> I am not here to say that PHP is better or the opposite, I am here to
>> ask, how web development in Ruby compared to PHP. Does Ruby use the same
>> tools? for example MySQL and Apache?
>>
>> And the most interesting point, which language can create a web
>> application with less code? (I am talking about the languges not the
>> frameworks).

> I wrote programs in Assembly.
> I wrote programs in BASIC (i know...but it was considered IN during
> the 70s/early 80s), then PASCAL, JAVA, and now Ruby.
>
> If you have develop programs in Assembly before, then you'd know you
> have write so many lines in order for it to do so little...
>
> Thus comparing number of lines is really pointless, because if you
> want, you could add a lot more lines yourself by not using any
> "standard libraries"

Interesting tidbit: research has shown that developers have roughly
the same productivity in lines of code per day _independently of
programming language_.  From that automatically follows that with more
preproduced code at your hands (either in libraries, interpreters or
compilers) your overall performance increases.

> This is one of the reasons why OOP is the mainstream now -- re-
> usability.
> But the trade off of this re-usability is "performance". This is due
> to all the overheads you added by using the "standard libraries" But
> this could be neglected with better hardware performance...

I am not sure this analysis is correct: typically, if you have a
library with a good implementation efforts have gone into it to
provide a good interface and to optimize it.  While it might be
relatively easy to implement the same functionality yourself, doing so
in a robust, bug free *and* efficient way typically involves
significantly more efforts.  Of course, if one uses a library in
unintended ways it might perform poorly - but then you are using the
wrong tool anyway.

> So to answer your question, you have to tell us WHY you want to create
> a web application with less code? If you answer is "Performance,"
> then you picked a wrong measurement (# of lines). Instead you should
> use "number of cycles"

Absolutely!  And: /first/ measure, /then/ judge.

Kind regards

robert
B31e7abd14f1ceb4c4957da08933c630?d=identicon&s=25 Josh Cheek (josh-cheek)
on 2010-11-17 11:00
(Received via mailing list)
On Wed, Nov 17, 2010 at 2:40 AM, Robert Klemme
<shortcutter@googlemail.com>wrote:

>
>
> Interesting tidbit: research has shown that developers have roughly
> the same productivity in lines of code per day _independently of
> programming language_.  From that automatically follows that with more
> preproduced code at your hands (either in libraries, interpreters or
> compilers) your overall performance increases.
>
>
Though you take a hit learning how to use the preproduced code. I have
spent
a lot of time failing to learn libraries and conventions.
2ee1a7960cc761a6e92efb5000c0f2c9?d=identicon&s=25 w_a_x_man (Guest)
on 2010-11-17 11:35
(Received via mailing list)
On Nov 17, 2:09am, zuerrong <zuerr...@gmail.com> wrote:
> $ perl -le 'print 2+"2"'
> 4

In awk, "+" always means arithmetical addition; string concatenation
is indicated by juxtaposition.

C:\>mawk "BEGIN{ print 2 + '2'; print 2 '2' }"
4
22
2ee1a7960cc761a6e92efb5000c0f2c9?d=identicon&s=25 w_a_x_man (Guest)
on 2010-11-17 11:37
(Received via mailing list)
On Nov 17, 4:27am, w_a_x_man <w_a_x_...@yahoo.com> wrote:
> > $ perl -le 'print 2+"2"'
> > 4
>
> In awk, "+" always means arithmetical addition; string concatenation
> is indicated by juxtaposition.
>
> C:\>mawk "BEGIN{ print 2 + '2'; print 2 '2' }"
> 4
> 22

Or even

C:\>mawk "BEGIN{ print '2' + '2'; print 2 2 }"
4
22
32bbfde7d847fc0f82804c4c26cf64a6?d=identicon&s=25 Kenneth Leung (lkfken)
on 2010-11-18 03:41
(Received via mailing list)
> Interesting tidbit: research has shown that developers have roughly
> the same productivity in lines of code per day _independently of
> programming language_. From that automatically follows that with more
> preproduced code at your hands (either in libraries, interpreters or
> compilers) your overall performance increases.

Thank you.
My English is not very good.  So from what I understand, you are
saying that productivity has not direct relationship to the
programming language?

Based from your comment, I did a little research.

http://www.codinghorror.com/blog/2005/08/are-all-p...

Will you please point me to the source of your comment?

Anyhow, I was not talking about productivity.  I was trying to say
measuring the web framework in "number of lines" in 2 different
languages is almost pointless...esp. when it is used as a reference on
performance.

In Ruby, I know you can increase the script's performance by writing
an extension in C.  But then, is it necessary?  One can obtain this
increase of performance by running the program in different hardware
(ie: 386 vs 486 vs core 2 dual )

> I am not sure this analysis is correct: typically, if you have a
> library with a good implementation efforts have gone into it to
> provide a good interface and to optimize it.

You are right.  I love libraries/OOP...  I cannot imagine if I have to
write EVERY routines myself in order for my script to work.

But what if it is an mission-critical scenario?  First, I prob.
shouldn't use Ruby to begin with.  Second, if I have to use Ruby, in
order to gain back few extra cycles, I might need to write my own
extension in C instead of using "standard libraries".

I am already way off the original topic.  Sorry.
E0d864d9677f3c1482a20152b7cac0e2?d=identicon&s=25 Robert Klemme (Guest)
on 2010-11-18 09:25
(Received via mailing list)
On Thu, Nov 18, 2010 at 3:40 AM, lkfken <alpha.azieru@gmail.com> wrote:
>> Interesting tidbit: research has shown that developers have roughly
>> the same productivity in lines of code per day _independently of
>> programming language_. From that automatically follows that with more
>> preproduced code at your hands (either in libraries, interpreters or
>> compilers) your overall performance increases.
>
> Thank you.
> My English is not very good. So from what I understand, you are
> saying that productivity has not direct relationship to the
> programming language?

IIRC the statement was that independent from programming language the
number produced lines of code per day that were error free is roughly
identical.  So this was not only about the writing itself but also
about ensuring quality.

> Based from your comment, I did a little research.
>
>
http://www.codinghorror.com/blog/2005/08/are-all-p...
>
> Will you please point me to the source of your comment?

Unfortunately I don't have a URL handy.  Candidate sources are
http://www.amazon.com/dp/3540520392
http://www.amazon.com/dp/0201835959
http://www.amazon.com/dp/0932633439

But the source may be a totally different one.  It's been a while that
I found that bit.

> Anyhow, I was not talking about productivity. I was trying to say
> measuring the web framework in "number of lines" in 2 different
> languages is almost pointless...esp. when it is used as a reference on
> performance.

And I absolutely agreed (and agree).  I was digression because I found
that bit interesting and thought others would, too.

>> I am not sure this analysis is correct: typically, if you have a
>> library with a good implementation efforts have gone into it to
>> provide a good interface and to optimize it.
>
> You are right. I love libraries/OOP... I cannot imagine if I have to
> write EVERY routines myself in order for my script to work.

Exactly.  And that does not only save you writing effort but testing
effort (and probably documentation effort) as well.

> But what if it is an mission-critical scenario? First, I prob.
> shouldn't use Ruby to begin with.

And you would base that decision on what?

> Second, if I have to use Ruby, in
> order to gain back few extra cycles, I might need to write my own
> extension in C instead of using "standard libraries".
>
> I am already way off the original topic. Sorry.

Drifting off topic can reveal interesting insights and produce
discussions which lead to new knowledge. :-)

Kind regards

robert
161289732b5b8c9dcb5834a3f0535340?d=identicon&s=25 Chad Perrin (Guest)
on 2010-11-29 05:30
(Received via mailing list)
On Thu, Nov 18, 2010 at 11:40:20AM +0900, lkfken wrote:
>
> My English is not very good.  So from what I understand, you are
> saying that productivity has not direct relationship to the
> programming language?

I suppose that, if you are going to produce the same number of lines of
code in either of two languages, and all else is equal, the more
expressive language -- that is, the language that allows you to express
more in the same number of lines of code -- will "make" you "more
productive".  This is because the following two things could happen, and
which happens depends on the language:

Language A -- You write 40 lines of code per day for three days.  You
finish your program, because for every 20 lines of code you achieve one
complete feature in your program, and it needs six features to be
finished.

Language B -- You write 40 lines of code per day for six days.  You
finish your program, because for every 40 lines of code you achieve one
complete feature in your program, and it needs six features to be
finished.

In this case, if all else is equal, Language A would be your best bet.

Then again, "all else" is pretty much ever equal.
Please log in before posting. Registration is free and takes only a minute.
Existing account

NEW: Do you have a Google/GoogleMail, Yahoo or Facebook account? No registration required!
Log in with Google account | Log in with Yahoo account | Log in with Facebook account
No account? Register here.