Indeed. Sass and Compass have been doing this for years. Using mixins for CSS framework rules so markup stays semantic is basically the core concept behind Compass.
- about the same number of Perl programs are faster than the Ruby 1.9 programs by about the same amount, as there are Ruby programs faster than Perl programs
- some of the Perl programs use half the memory of the corresponding Ruby 1.9 programs
- the Perl programs and Ruby 1.9 programs use about the same amount of code.
That's certainly one leading theory, and probably the most likely. However, that happened earlier in the summer, a month or more before he actually shut everything down. There are other possible theories, eg, in his last tweets he lamented about feeling left behind by the progress of open source, or the theory that he planned it all along based on the Poignant Guide's ending.
No matter which of those reasons it was, it's pretty baseless to claim that he took down all of his websites, comics and open source software in a variety of languages including one he created due to some mysterious, unmentioned, irreconcilable beef the Ruby community, especially considering he was one of the most influentual people in defining that community.
Ok. Shitload of lib err bricks. Great. Where are the prefab houses (frameworks) that help you get the thing done ... fast ? Perl has building blocks but lacks known products. Either finished products you just have to configure (like Drupal or Wordpress) or higher level building blocks (say Rails) that help you get where you want to get faster.
Note I didn't say there is not such product/framework, just, as the articles says, they are not promoted/known.
I didn't there wasn't, just that the need better promotion. Call it screencast if you wish. They need Promotive Passionate Users.
[edit]
I'm gonna pick a little bit on Catalyst and do a quick surface review at website level from a non-Perlist POV.
Homepage : ok, looks nice.
Documentation : uuh ! Dry redirect to CPAN.
First impression before reading, it's not the doc, it's the API doc. Ah, wait a second, it _is_ the doc. Not very appealing and some things are so not obvious that it takes a note to understand it like "Note: Click on the heading in the previous line to jump to the actual chapter. Below is a "table of contents" for this chapter."
Download : Again directly to CPAN, at first sight confusingly looks like an API doc. For newcomers not versed in Perl it is not very friendly.
Community : not much to say, a good wiki with apparently interesting stuff to read. But the first thing you see is that the "Why Catalyst is an excellent web application framework?" is an empty page.
The perl community has every reason to be proud of CPAN. It's great tool but it's not the answer to everything. It's all therem but it lacks the last mile, the 20% of polish to make it a tad more friendly/attractive.
It's the whole point of the article I think. It's not to criticize Perl, just to say it needs a better marketing strategy.
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.
Have you looked at Padrino? I recently experimented with it and was surprised that it was an extremely awesome middle ground, to the point where I'll probably use it for my next project. It's very fast, close to Rack and easy to use with Rack middleware, has Rails-style view helpers, has sinatra-style controllers, very simple and elegant mountable apps, a focus on DB agnosticism, among many other things
Question: Have you experience with it on heroku? Does it work well there? Any difference between its behavior and the "normal case" of RoR as far as what heroku is designed for to your knowledge?
(Like I've said, got nothing about ruby, just don't feel rails is a good fit for the stuff I do; something lighter weight like this could be a good substitue on heroku).
I haven't, but I know it works fine. Heroku is more of a Rack host than a Rails host, so any Rack-based framework (AFAIK, all Ruby frameworks at this point) run seamlessly on it.
Python will be more useful if you decide to do
something with the language other than ruby on rails
If by "ruby on rails" you mean "anything to do with web development, deployment and server config management," then you'd have a point. Of course, when the context is a discussion about web development, then whether you can easly write OpenGL apps is irrelevant. Good developers also don't just learn one language and try to use it for everything.
with it as well (SPSS, SciPy, NumPy and various other
things)
That has effectively nothing to do with which web framework to work with. The OP has already worked with Java, C# and Objective-C. Assuming he comes across a project that requires something like SciPy or NumPy and assuming he doesn't use something from one of the languages he already knows, I'm guessing that he, like most hackers, wouldn't have a problem learning Python or another language no matter what web framework or language he had been using recently for web development.
You have that completely backwards. If you are coding your Python like that, you are doing it wrong and almost certainly drawing the ire of the people you work with.
I mean, they get really pissed off when we hack a view 2 days before a deadline instead of just not delivering it. I mean people LOVE when you don't deliver.
Hacks are not good. Hacks should not be done all the time. But sometimes, shipping is more important than beauty and elegance. Hacks you put up while you get the real, good code in place is next to godliness when working in multicomponent systems under tight deadlines. Rails just isn't as good when you need to do that sort of thing. It doesn't have that flexibility, by design!
When I write the hacked up glue code first so they can do their stuff while I write mine, they f-ing love that. It lets them do their job!
I do things "the right way" 99% of the time. That buys me incredible flexibility to use utter crap code that's otherwise functional that other 1% of the time when required by the job.
I don't presume to know your work environment, but personally I work on my own projects and do contract work and, in my experience, taking on debt is usually a sign that there's a problem with the requirements and estimates, so I usually change those before making the code less maintainable (which, IMO, is usually a case of treating the symptom).
Regardless, I'm weary of claims that controller-level (django view level) code is a major pain point in Rails. In some ways it's actually easier since you can make fewer decisions by making them resource centric, but even deviating from that is as simple as map "/path", :to => "controller#action".
Rails/Django controllers/view and routing/urls aren't as elegant as micro-frameworks like Flask and Sinatra or not-so-micro-frameworks like Padrino, but they aren't anything close to serious stumbling blocks (though maybe routing to a very small degree in resource-centric Rails 2). Every blocking issue I've had with either framework has been on a deeper level. In Rails pre-3, it was usually configuration-related when trying to do something too unconventional. In Django, it's when trying to deviate from the overall Django philosophy and use something other than the included batteries.
I'm not arguing for systemic mortgages worth of debt. I'm arguing for using your credit card occasionally cause its easier than constantly going to the cash machine.
Use case:
iPhone dev "can you do this"
Ruby dev "Sure, takes a sec to rejigger things to allow that"
A few minutes/hours later "Done, and its perfect"
Alternative
iPhone dev "can you do this slightly differently"
Django dev "Like that?" [Just mocked up the entire thing in pure text, django happily returns it]
iPhone dev "thanks"
Django dev "I'll go make that work right now now that you can integrate your code
I have a real problem with the inability to provide a good enough version now when its more valuable than a very good version later, especially when there is room in the schedule to deliver both.
I work in an integration based environment, where the turnaround on the backend development is the maximum schedule issue, not the overall development scheme. I don't want my software development effort to look like the execution of a python program in a GIL bound multiprocessor environment. I want the thing done asap, if that means I'm paying the backend guy to redo his code 3 times cause the prototype is valuable and speeds up final time, I want the flexibility to do that.
I'm Excited that rails 3 promises to help part of this (as you correctly surmised, it is mostly rails 2 code and coders and turnaround issues I've dealt with), but I haven't yet seen it very much yet at all.
Schedules, requirements and all that are great, but if you can put a little hustle in at the end when there is something big on the line and get paid for that, you have very happy customers and very fat wallets. Non software people like delivery and there is a modicum of debt that sometimes requires.
How is Django not dramatically more opinionated? It is, we all know it and we know that it's a virtue in that it produces consistent, readable code code. Why are you trying to pretend otherwise?
With Django, there's a whole philosophy behind the right way to do templates. There's a whole explicitly written philosophy behind the specific coding conventions. Whole sections of the framework still assume you are using SQL, ideally Postgres.
Meanwhile, Rails 3 doesn't just support, it increasingly encourages doing things however you want to. Not only that, the community accepts it. Try to use anything but Django templates in your Django project and you'll likely get strong resistence from others on your team or someone who picks up the project after you.
I'd still go python over ruby, cause I'll take libraries
I use both Ruby and Python for web development and, frankly, this is utter nonsense. Even in situations where there is a larger quantity of libraries, such as template engines again, it doesn't translate to greater breadth of viable options since the widely used Python templating engines are mostly variations on the same theme. There is no widespread adoption of something like Haml because, again, the Python community is opinionated. There are good reasons for this, but if you like a template language like Haml and work on anything other than personal projects, you are SOL.
In general, there are far more situations when using Python for web development where I'm pining for a Ruby library than vice-versa. Thankfully some, like Sass and Chef, don't require that the project itself is in Ruby.
What happens when you do a django template "your way" or "they way we can do it in 2 hours instead of 12"? What happens with the same thing in a Rails project?
People may dislike that you did it, but you still CAN. That's the difference. With Ruby on Rails, you can't necessarily due it without the wheels coming off.
>I'd still go python over ruby, cause I'll take libraries
This is a comment about the non-web components of the language.
>how is Django not dramatically more opinionated?
The Django community is perhaps more opinionated. The actual software isn't. That's the issue with Rails. The actual software has strong opinions (aka, intentional inflexibility) baked into it. I honestly wouldn't pick Django either (preferring even less strict frameworks), but the OP asked a question X or Y, and I told him of those two I feel is better.
What happens when you do a django template "your way"
or "they way we can do it in 2 hours instead of 12"?
I've worked on a lot of projects and can't imagine the situation where you'd have this kind of a variation in time to create two remotely similar versions of a template. If you are talking about a fully designed template + CSS + JS, then you could possibly get up to 12 hours, but there would be no way to shorten that to 2 hours without doing something completely different.
This is a comment about the non-web components of the
language.
And this entire discussion is about web development. The OP, who already knows multiple non-web-centric languages, asked specifically about web frameworks.
The Django community is perhaps more opinionated. The
actual software isn't.
Depends on what you mean by the software. The framework overall is very opinionated, even if you can use parts of it in a modular way.
The actual software has strong opinions (aka,
intentional inflexibility)
Let me take the opportunity to give you a heads up that Rails 3 has been out for months now and is widely used in production. One of the most significant design goals of Rails 3 was intentional flexibility.
>Depends on what you mean by the software. The framework overall is very opinionated, even if you can use parts of it in a modular way.
Also, Django is WSGI. WSGI is very easy to add layers to to get the job done. (Side note, does everyone pronounce that Wizz Gee in your part of town? They sure as hell do in Atlanta and it slightly confuses me every time I hear it in conversation but can't figure out they're saying WSGI).
You're thinking web apps. Think "apps that have some views which are to the web, but most data feeds for other services" and you'll be in the zone were in. Json and Xml feeds and the like.
