WordPress probably has the worst track record out there in terms of the number of hacked websites

Wordpress has also had the most scrutiny by far - I suspect that and their installed base is the reason they've had more exploits, and that should make the code at the present time far more secure as they've had a trial by fire when becoming popular. I agree it's not my first choice for security but I wouldn't be so sure about Drupal.

In contrast, many of the Drupal modules I've seen (and there are many on most sites, one client site had 200 installed!) have not been updated in a long time, break on every update, and are of a quality which makes me seriously doubt that security was a concern. Unlike WP many of these are used on a lot of sites (WP you can get away with a caching plugin, perhaps attachments, and that's about it).Many people are stuck on older insecure Drupal installs with no way of upgrading because their site breaks when they do. Core code is so complex that I highly doubt there are not significant undiscovered vulnerabilities - Drupal has many different ways to hook in dynamic content e.g. Core blocks, Context module, and Panels, hook_page_alter and then the render API, the rendering pipeline is extraordinarily complicated.

Have you used something like Rails and would honestly pick Drupal over it to build some sites?

Wordpress 'clean'?? Seriously??

If you've ever looked at Drupal, you'd know what I mean : ) Personally Wordpress is not my first choice, but they have kept the architecture relatively stable and simple and it is great for end-users who just want a custom theme as that is their focus. If all they want is basically a blog with some static pages I think it's quite a good choice - many, many websites fall into that category.

The Wordpress developers probably never heard of functions, because every file is one big piece of lineair code.

I'm afraid this damages your credibility somewhat for me. Functions are the things with 'function' in front of them, and there are rather a lot, even in WP!

If you're looking at building an actual app with MVC and a better architecture I'd seriously look at a better language than PHP, Wordpress is actually not bad for PHP code.

Have you ever used anything else? If so what? Nothing else I've used is so badly organised and so badly put together (Play, Rails, Sinatra, Flask, hell even Wordpress), save perhaps TYPO3, that was pretty bad (shudder). I wouldn't often be so negative about a web framework, and the devs are obviously keen and trying to improve, but the hubris involved in talking of world domination when your product is just awful in so many ways is quite incredible.

If you haven't tried other frameworks in a while, I do think you should try some other frameworks and languages, and then come back to Drupal with an understanding of how things can be better, then perhaps set about improving it. Frankly part of the problem with Drupal is the many people who have invested so much time learning all the unnecessary APIs and working around its idiosyncratic code and db schemas, or fixing upgrades that leave modules behind that they can no longer find it in themselves to suggest the radical improvements required. Drupal is broken, in so many ways, you should at least acknowledge that there are issues if you want to be taken seriously.

That to me is a big part of the problem with the Drupal ecosystem - unwillingness to listen (even in small part) to quite justified criticism and an insistence that anyone criticising is somehow to blame for the problems they have encountered. If you want Drupal to thrive, try actually listening to criticisms and acting on them - it has an awful software architecture for a start, to say that it has a good one is laughable, I mean they only just started try to clean up the mess with fields, and to do that they've introduced CCK! Have you looked at the drupal core or do you mainly set up and tweak sites?

Ultimately, the main problem I have with it is a philosophical one though, which has driven a lot of the bad decisions on design: the designers seem to think that end users can effectively specify a complex system involving a db and code, which they only partially understand, through the browser and by choosing modules written by other people. That's what has led to massively complex 'general purpose' code to deal with all the possible permutations, to code in the db, CCK and many other problems in Drupal, and it's not going away as they don't seem to have learned the lesson from previous debacles. The result is a complex tangle of poorly understood code which interacts in unpredictable ways and tries to be everything to everyone and ends up satisfying nobody's needs very well without lots of extra work. In other frameworks all that extra work is just not required, the framework helps, not hinders. Here's a report from someone in the trenches who has realised this:

http://benbuckman.net/drupal-excessive-complexity

Usable code isn’t a luxury, it’s critical to attracting and keeping developers in the project. I saw a presentation recently on Rapid Prototyping and it reminded me how far Drupal has come from being able to do anything like that. (I don’t mean the rapid prototype I did of a job listing site - I mean application development, building something new.) The demo included a massive data migration accomplished with 4 lines of javascript in the MongoDB terminal; by comparison, I recently tried to change a dropdown field to a text field (both identical strings in the database) and Drupal told me it couldn’t do that because “the field already had data.”

All that said, I'm not saying this because I have some axe to grind about Drupal (though it has wasted a few months of my life debugging client issues), but because beginner Drupal developers deserve to know that there are much better options out there. Drupal does not rock, in any way.

I've worked with Drupal for cms websites and seen it used on other customer sites. You should never use it, seriously. It's remarkably similar to early php in being a fractal of bad design. They are slowly trying to improve it, but their attempts at improvements are woeful. Some problems (which they've attempted to address, but many of which still plague users):

Hundreds of tables with the most Byzantine schema you can imagine, even for incredibly simple needs
Attempts to allow customers to define the db schema by adding fields etc
Code in the db - that anyone ever thought this is a good idea is a huge red flag
Upgrades are often incompatible
A horribly broken plugin system and ecosystem, resulting in sites which load hundreds of plugins to support simple tasks, and therefore have a huge attack surface and a huge amount of unmaintained, scarily bad code. I've seen sites with hundreds of these modules loaded.the learning curve is huge and the code extremely fragile due to the above decisions
Content is all stored in 'nodes' which are infinitely flexible, and therefore infinitely opaque and difficult to work with
There are no pros or professionals working with Drupal - anyone who was a pro would have run a mile a long time ago, so don't listen when someone says 'oh well you just don't know drupal well enough'

I dread to think what would happen if security professionals looked carefully at many drupal sites due to the above, particularly the modules situation. The closer you look at the code, the worse it gets

If you're thinking of using it for a php cms, think again, look at Wordpress for example - the code is relatively clean (though it is still php of course), the plugins are better maintained and fewer are required, upgrades for security are no hassle, and they didn't come up with crazy ideas like code in the db in the first place. I'd personally choose other options/platforms, but at least with Wordpress the environment is pretty sane for a small time cms, easy to adapt and friendly for an end user.

It should in my opinion have resource urls for each message, that's a design flaw that they get away with because its a closed web app used by one person with no information sharing. I their other apps like calendars they use stateless Uris for each doc though for obvious reasons.

Others who have tried this on the open web, like twitter and their crazy hashbang, have been roundly condemned for it and usually given up as its throwing away one of the biggest advantages on the web.

The problems with HTML/web arise because it is stateless, browsers differ in their implementation, and the only language available on the front end is js, which is not terrible, but not beautiful either, and content is not always separated from code.

The many advantages of HTML/web come from the fact that it is stateless, most operations are idempotent and cachable, URIs can be shared, and that it's so simple even humans can create it by hand (and getting simpler with html5), readers get to control presentation and parse content, writers get to use any language on the server, content is easy to separate from code, there is no one way to do things or awful widget library, and browsers are constantly pushing the envelope.

Personally I don't want a browser experience just like a native app, there are several aspects of web apps which I'd like to keep - urls, fast updates, stateless operation, control over presentation, open data, and many from a dev perspective, chief amongst which is i don't need to rely on a platform vendor at all, and deal with their annoying toolkit and their currently blessed technology of the year.

The only thing I'd change about html dev is a better front end language (ideally a sandboxed vm shared by all browsers on which people can port whatever language they want) and a faster protocol like spdy, otherwise it's really not bad compared to mobile or desktop app dev, the advantages far outweigh the disadvantages.

Perl's speed is pretty similar to Ruby, it's nowhere near the Java VM nowadays, plus Ruby is available on the JVM if that's what you prefer to use. But the parent was talking about system admin scripts and little one liners run on the command line. If you're expecting them to be 'webscale' you're talking about something else entirely. I don't know about you but my system admin scripts are not expected to scale past the few machines I work on and run by precisely one user at a time, they're not user-facing scripts and therefore performance is not critical - they could be in any language really, I don't really use one-liners but it is quite possible to do them in all those languages, even Python.

Finally, re Twitter, if you try to reinvent a messaging server using a CRUD web app (a la twitter), you can expect all kinds of pain, even if you write it in enterprise ready Java in the first place. I imagine their problems were more down to entirely the wrong architecture, though now that they are one of the biggest sites on the internet, things like language choice will become very important for them. It's interesting though that a site like Facebook compiles PHP to C++ and then to one big binary in order to stay up and still use one of the slowest languages available - if they wished twitter could easily have done something simliar with Ruby or moved to using the ruby on the JVM, but the new people brought in to make it work were probably coming from Java backgrounds and as it need a rewrite, they thought why not, and why not indeed, it's worked out pretty well for them. They were still on Ruby 1.8.7 till the end I think, which was pretty insane given the improvements in Ruby 1.9 and points to serious problems with the older code.

: )

Apart from the maths libraries, multithreading, UTF support (only just in - enjoy the bugs!) cross platform GUIs (TK or Fox. WTF if Fox?)
Yep, half the speed of perl and a web toolkit more obscure than PHP.

Ruby has maths libraries (but not as extensive as Python here IMHO), threading, has had Unicode and UTF support for years (since 1.9), and has good support for the best scripting language UI if you ask me (HTML displayed in a browser with the built in web server). I suppose if your idea of 'serious programs' is desktop apps using the platform GUI through some glue code, then you're out of luck (frankly I wouldn't use Perl OR Python for that either, just use C, C++ and/or the platform language of choice). That's a silly definition of 'serious' though.

Re the speed and web toolkit, you clearly don't know what you're talking about there, plenty of options on Ruby, none of them obscure or difficult, and speed is pretty good nowadays, certainly good enough for almost all applications save extensive number crunching, it's really not a problem in the real world.

Pick your tools to suit the particular thing you're building (i.e. don't pick a scripting language to build a desktop app), but why limit yourself with silly misconceptions about tech? It's only a scripting language, comparable to many others and suitable for most of the same sort of problems.

That's not really true, you can easily write code without OO setup in ruby, in fact you could write code without defining functions if you wish for one liners. e.g. here's a little one liner to count the words in a file.

ruby -ane 'w = (w || 0) + $F.size; END { p w }' test.txt

It can be used very like perl if you wish.

1. Ruby is not a toy not suitable for 'serious' programs, it's very similar to Python in fact, it's not as strong on science or math though as python because of libraries available in Python, if that's what you mean, say that, it's far more convincing.
2. Python could easily replace Perl for system admin tasks - come up with specific criticisms if you have met with any roadblocks - you would likely find similar problems with Ruby to Python if you somehow couldn't manage sysadmin or text scripting with Python.
3. Ruby, Python and Perl are actually quite interchangeable and could all be used for 'serious' tasks, or for short admin or text processing - all 3 are ideally suited to these things, and frankly the differences are not huge, Perl is slightly gnarlier, Python slightly stricter, Ruby slightly more anarchic, all 3 would get the job done easily.
4. WTF has Rails got to do with any of this? Troll much?
5. Why should we waste our time trying to convince someone with such trenchant and at the same time wildly inaccurate preconceived ideas?

Most other technologies do have exactly this kind of exploit (I think this is more serious than the article states, it's a remote execution flaw, not SQL injection as you seem to assume from reading the summary), and many have and will continue to suffer from SQL injection flaws as they find their safeguards weren't quite what they thought they were. Here's a hole in the Java from the day after (note that I don't think that makes Java immediately unsuitable for any use):

http://developers.slashdot.org/story/13/01/10/1540202/java-zero-day-vulnerability-rolled-into-exploit-packs

Security is a process, i.e. you have to keep continually on top of it and react quickly to disclosures. It's not something you can just assume because you chose 'secure' technology, or audit once and forget about, and it's not something which any particular technology has a monopoly on. It's quite possible to build secure sites with rails if you know what you're doing, do your own parameter checking on top of what rails provides, and keep on top of security updates. Perfect security probably isn't attainable with any language, but I'm sure you weren't implying that it was. Curious that you seem to think Rails is particularly insecure though, have you ever used it?

Which tool in particular did you feel would work for this purpose? All the major languages or frameworks I can think of have had serious security problems in the past, none are a priori secure.

QED

This one is quite a serious flaw, and the data this website in question deals with is very important data (citizen IDs), so I'm not surprised they're taking it seriously. The service being down for a day or two is probably better than millions of ids getting hacked. Perhaps the fix breaks something on their website, and they have to fix that before they can take it back up again? It has produced issues like this I think:

https://github.com/rails/rails/issues/8831

Most sites (like Slashdot) really don't matter if they are hacked and could just stay up, but something dealing with identity like this deserves special attention, and I'm sure they have good reasons if they have taken the site down while they look at workarounds. Perhaps it'll mean they get more money devoted to securing the site after this has blown over - time spent testing the site and looking at security is probably more important than the specific technology used (almost every major framework has regular security problems like this), contrary to the righteous flaming and trolling for asp.net/perl/php/other tech which is bound to erupt in the wake of your post.

Not really no, as they could impersonate an admin account and use that to execute whatever commands they wish.