6 ms·

I think you might be fighting an uphill battle here. Some developers prefer Python, some prefer Ruby. An individual developer might be able to reel off a list

by j4mie 16y ago

I think you might be fighting an uphill battle here. Some developers prefer Python, some prefer Ruby. An individual developer might be able to reel off a list of reasons why one is better than the other, but in the end it comes down to something intangible and subjective - "Ruby just feels better" or "Python fits my brain better". The concept of "magic" is very similar. What feels magical and opaque to one developer might be plain and obvious to another. When you ask what "magic" means, you'll get different answers from different people. From my point of view (as a Python/Django developer), even the basic commands that Rails uses feel strange. Compare the very first line of code that you run in a Django project vs a Rails project: django-admin.py startproject mysite with rails new blog The former says: "run the Python script called django-admin.py" (which immediately tells me that this is just a Python script that I could read, if I were so inclined) and pass the arguments "startproject" (which is a clear description of what is about to happen) and "mysite" (which is, fairly obviously, the name of the project to start). This reads like a sentence of the form 'use <tool> to perform <action> with arguments <arguments>'. The latter says: "run the command rails" (what is this? A Ruby script? A bash script? A binary? Why is it called "rails" when the whole framework is called "Rails"?) and pass the arguments "new blog" (obviously this is creating something, but what? In most languages, "new" is a keyword that is usually used to create instances of classes - so is it creating an instance of something called "blog"? Does that mean that Rails knows what a "blog" is already?) To me - this is magic. Rails says "type this incantation and I'll do some stuff for you". Django says "here are some tools you can use to do stuff". You might disagree with me entirely in this particular case - perhaps you find the Rails example clearer - which is fine. The point of this example is to say that framework and language preference is so intangible that the very first line of your documentation can sway someone's opinion either way. Instead of fighting against the "magic myth", you should just be trying to attract developers who like your particular brand of magic (or, alternatively, don't see your code as magic at all).

cmelbye 16y ago
django-admin.py and "rails" are the exact same thing, it's just that the Rails command line utility doesn't have an unnecessary Ruby extension. I'm not sure why "new" is a magic incantation while "startproject" is an intuitive command line option just because you're not familiar with the command line arguments for "rails".
- count 16y ago
  You're repeating exactly what he said :)
- j4mie 16y ago
  ... exactly.
rapind 16y ago
Both look like magic. Where's the XML?? ;)
ollysb 16y ago
Here's my 2 cents (I'm a rails developer). The rails command exhibits 2 qualities which I value greatly, good encapsulation and a high signal to noise ratio. When I create a new project that is exactly what I'm concerned with, I have no interest in _how_ this happens. The fact that the django command is twice as long to describe the same thing to me implies redundancy and from more of a philosophical than perhaps practical point of view, waste.
danieldon 16y ago
I look forward to your campaign to change hg init project to mercurial-admin.py startrepository project Those Ruby developers and their magic. Or something.
- Daishiman 16y ago
  django-admin.py commands are run once every blue moon. Explicitly documenting them even if they are slightly more verbose is a good practice. None of the most frequently issues Django commands are long, and all of them autocomplete with bash and zsh.
nroman 16y ago
I'm not a Rails developer...but it doesn't seem like rails should have a "new blog" command at all. Rails is a web framework. Frameworks are supposed to take care of all those annoying intricacies involved in building a web site. That would be things like URL mapping, routing web requests, handling gets and posts, talking with the database, session persistance... A blog, on the other hand, is an application that should be written on top of all this. It would make more sense to me include this as an example application. It seems pretty obvious to me that the intent of creating the "ruby new blog" command was to make it extremely easy to install the example blog app. However, by doing this, they are marketing rails as a magical framework. The framework auto-generating you a whole blog isn't really a good hello world program; it didn't teach me anything about how rails works. I remember back when ruby first came out (I'm sure a lot has changed since) I was watching videos that introduced it, and every time the presenter would say something like "Hey you want a blog? Just type magic make me a blog command, and now you have a fully functioning blog with a built in CMS." I remember thinking to myself, "but I'm not building a blog" and then I went back to my PHP. I'm not saying this was the correct reaction, perhaps I should have instead gone and investigated it further, but that's how it was marketed, and I found it off-putting.
- getsat 16y ago
  "rails new blog" doesn't create a blog, it creates an empty Rails 3 project using a SQLite database backend called... "blog". > I remember back when ruby first came out I think you meant Rails here (not sure if you can edit HN posts). Ruby's been around since the mid-90s. > I remember thinking to myself, "but I'm not building a blog" and then I went back to my PHP This makes me think that you're not using a MVC framework. PLEASE, please spend 30 minutes researching MVC and conceptualising the models behind your application talking to each other. In plain PHP, you would run a SQL query to see if a user can reply to a blog post. In a MVC framework (such as Rails), you would ask the user itself in a higher-level manner: if @user.can_reply_to? @post This helps keep your views clean and all your business logic separated out. Views should contain no logic, controllers should contain as little code as possible to grab model data and anything else needed to show in the view, models should be where all the magic happens.

by j4mie 16y ago

cmelbye 16y ago

django-admin.py and "rails" are the exact same thing, it's just that the Rails command line utility doesn't have an unnecessary Ruby extension. I'm not sure why "new" is a magic incantation while "startproject" is an intuitive command line option just because you're not familiar with the command line arguments for "rails".

count 16y ago
You're repeating exactly what he said :)
j4mie 16y ago
... exactly.

rapind 16y ago

Both look like magic. Where's the XML?? ;)

ollysb 16y ago

Here's my 2 cents (I'm a rails developer). The rails command exhibits 2 qualities which I value greatly, good encapsulation and a high signal to noise ratio. When I create a new project that is exactly what I'm concerned with, I have no interest in _how_ this happens. The fact that the django command is twice as long to describe the same thing to me implies redundancy and from more of a philosophical than perhaps practical point of view, waste.

danieldon 16y ago

I look forward to your campaign to change hg init project to mercurial-admin.py startrepository project Those Ruby developers and their magic. Or something.

Daishiman 16y ago
django-admin.py commands are run once every blue moon. Explicitly documenting them even if they are slightly more verbose is a good practice. None of the most frequently issues Django commands are long, and all of them autocomplete with bash and zsh.

nroman 16y ago

I'm not a Rails developer...but it doesn't seem like rails should have a "new blog" command at all. Rails is a web framework. Frameworks are supposed to take care of all those annoying intricacies involved in building a web site. That would be things like URL mapping, routing web requests, handling gets and posts, talking with the database, session persistance... A blog, on the other hand, is an application that should be written on top of all this. It would make more sense to me include this as an example application. It seems pretty obvious to me that the intent of creating the "ruby new blog" command was to make it extremely easy to install the example blog app. However, by doing this, they are marketing rails as a magical framework. The framework auto-generating you a whole blog isn't really a good hello world program; it didn't teach me anything about how rails works. I remember back when ruby first came out (I'm sure a lot has changed since) I was watching videos that introduced it, and every time the presenter would say something like "Hey you want a blog? Just type magic make me a blog command, and now you have a fully functioning blog with a built in CMS." I remember thinking to myself, "but I'm not building a blog" and then I went back to my PHP. I'm not saying this was the correct reaction, perhaps I should have instead gone and investigated it further, but that's how it was marketed, and I found it off-putting.

getsat 16y ago
"rails new blog" doesn't create a blog, it creates an empty Rails 3 project using a SQLite database backend called... "blog". > I remember back when ruby first came out I think you meant Rails here (not sure if you can edit HN posts). Ruby's been around since the mid-90s. > I remember thinking to myself, "but I'm not building a blog" and then I went back to my PHP This makes me think that you're not using a MVC framework. PLEASE, please spend 30 minutes researching MVC and conceptualising the models behind your application talking to each other. In plain PHP, you would run a SQL query to see if a user can reply to a blog post. In a MVC framework (such as Rails), you would ask the user itself in a higher-level manner: if @user.can_reply_to? @post This helps keep your views clean and all your business logic separated out. Views should contain no logic, controllers should contain as little code as possible to grab model data and anything else needed to show in the view, models should be where all the magic happens.