Don't ban it, tax it as gambling.

So, basically, what your saying is "I don't understand most of how the market works, so please ban everything I don't understand."

No, since you didn't read the comment you replied to, I've repeated it here. They are *not* suggesting banning the activity, but restricting it with taxation to make it less attractive to profit from short-term fluctuations in prices - this would dampen volatility. Some volatility is a good thing, too much of it can be terrible for a market which relies on confidence to function.

A transaction tax sounds like a good idea to me, do you have any concrete objections to it?

Again, your assumptions and guesswork about me are entirely unfounded (not that it should matter in considering Drupal):

1. I don't recommend or use WP very often, it's good for simple sites, and I've seen a few Drupal sites that could more easily have been done with WP.
2. I've fixed/maintained a few drupal sites and replaced one big underperforming drupal site (bad developer, compounded by bad usage of drupal IMHO) with rails, taking less than half the resources (CPU/RAM), and half the time to do the same job (500k uniques a year, no not willing to link). These direct comparisons have led me to my conclusion that it is not so much better than other frameworks, quite the reverse.
3. Don't let yourself assume I don't know what I'm talking about to avoid cognitive dissonance, I think I've clearly demonstrated I know the framework and am not some hobbyist WP advocate, and plenty of drupal or ex-drupal developers agree with me, see [1]

A content neutral CMS is a *mistake* IMHO (nodes etc) - most CMS systems are tailored to the problem domain and rightly so. Not doing so leads to bad performance, inflexibility, complex db schemas, and ongoing problems with maintenance. Not many other frameworks try to do this the drupal way; instead a CMS should have pages, users, admin etc, and then you should build your own *domain specific* admin. See Django [2], Rails[3], Play[4] etc. Apparently the core developers have recognised serious problems with drupal even if you don't as they're ripping out the internals in v8 and starting again on many core components. I don't have confidence they'll do better then 8th time round, but YMMV. It's quite possible to build good websites with Drupal, but I think they could be built better, easier, and faster with most other frameworks, even ones which out of the box do far less. If you haven't I would honestly recommend trying one of those in my list and giving it a go to build a simple site just to compare (not another PHP one).

[1] http://benbuckman.net/drupal-excessive-complexity
[2] https://docs.djangoproject.com/en/1.5/topics/db/models/
[3] http://guides.rubyonrails.org/getting_started.html#getting-up-and-running-quickly-with-scaffolding
[4] http://www.playframework.com/documentation/1.0/guide7

I didn't choose uc but that was just an example - all drupal tables have several levels of indirection because of the overabstraction.

This strongly suggests you have very little experience outside extremely fixed type of websites

I'm sorry to tell you but your assumptions are entirely wrong, about me, and about other frameworks. Try not thinking of people who find drupal distasteful as automatically stupid, it might help. I'm just offering you suggestions re other frameworks, I do think rails, play, grails, django, revel, wp, all compete with drupal, not because I'm ignorant of what drupal can do, but because it tries to do too much, and does it in the wrong way. Also think they make an illuminating comparison with it. It does 80% of most cms tasks then leaves people with a difficult rigid structure they can't extend in a maintainable way. But we've both said our piece on that and this thread is too long!

As to the level of abstraction in Drupal, I don't find it difficult to comprehend at all, I just find it overdone and a messy cargo cult style of OO. Java is also full of awful frameworks which do the same thing and have module loaders, nodes, factories and plugins without getting the basic foundations right. Abstracting all content to a node is a classic AA error IMHO and a source of lots of perf. and usability issues and modules are too interlinked. PS I'm basing this on having to fix drupal sites written by others, so on personal exp with d6, not because of some irrational hatred of abstraction or drupal.

Yes but to add a small date function on from this module you have to pull in the whole thing, along with all its complex dependencies and hooks into other code. This was just an example, and loc on its own doesn't mean much, but 14k for a date module indicates a problem to me (and to many drupal developers). This is the sort of thing newer languages like golang were explicitly created to avoid, and its a serious problem on large projects.

IMHO no plugin should be that big, even some frameworks are smaller than that!

I don't see any difficulty in working with nodes, it's pretty straight forward.

Usually people pick abstractions based on the domain they're working with (DSL), so they'd have one products table and perhaps some joins to things like customers, orders etc. Instead drupal might have nodes and then lots of joins to them, like say 65 tables (count em!) of uc_products, uc_price_per_role_option_prices, etc etc. just to sell some products. That's because the CMS and modules try to do all things for all people. All those abstractions leak through to the front end and you end up managing nodes etc when you really want to get on selling stuff and managing your things (which are never really nodes). Nodes are used for things as disparate as any posting, such as a page, poll, article, forum topic, or blog entry and god knows what else, it's an abstraction too far IMHO.

It's not difficult if you've never seen anything else and think things have to work this way and that the system should bend you to its will and not vice versa.

Where's the proof for this? If there're no pros working with Drupal, who contributed the thousands of modules for Drupal?

Who indeed.

PS Use blockquote elements

I notice a lot of developers struggle with generic, reusable designs in this manner because the abstract nature of such designs make them a little harder to understand,

Those benighted, simple developers who value simplicity in an API even have a phrase for those who live on a higher plane - Architecture Astronaut.

http://www.joelonsoftware.com/articles/fog0000000018.html

If you're arguing that abstraction and the attendant complexity are usually good, I'm afraid a lot of smart people disagree. I've used systems with far better domain abstractions (named in the thread), in fact I find it hard to think of a system with a worse set of abstractions.

The newer versions of drupal, which have added things instead of refining them, remind me of this article. I do feel that most full-time Drupal devs could do with stepping away from the madness despite their huge investment in time learning it, and checking out other frameworks and languages (if you think all PHP CMSs are the same, look at other options). It's fine to think Drupal is the best CMS available, but you should do so from a position of knowledge having evaluated the other options, and if criticisms are made, accept them where they have some foundation (however small), and try to improve it. There is no need to start a holy war on behalf of Drupal the one true universal module loader.

Re PHP I actually think the last year or two they have shown signs of sanity with things like the new password API and changes in the latest version, perhaps they read that article and took it to heart!

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.

I choose Byzantine schema over everything stored in two tables any day of the week. I pick allowing the customer to add fields via actual database tables rather than stuffing them into a "meta" table in a serialized form. If by code in the DB you mean having a rules/actions engine that is defined with data from the DBI pick that over hand coding anyday. Upgrades incompatible? I pick testing your upgrade rather than blindly upgrading a production site.

Q.E.D.

Drupal definitely has a "cleaner" code base and better software architecture than Wordpress

I'd be interested to see some concrete examples, I have a hard time understanding why you would say that, save perhaps that Drupal has far more *abstraction* - that's not the same as being cleaner and leads to greater complexity if overdone. I don't really want to defend WP as it's not my idea of brilliant architecture (far from it), but they have kept it much simpler and procedural than Drupal, which is incredibly complex when it comes to rendering or even the simplest helper modules. For example:

Drupal date module: 14kloc (YES > 14,000 lines)
WP date helpers/calender: circa 1kloc
Rails date helper: 970 sloc (doesn't include visible calendar, I'd use jquery-ui for that)

Yes the above helpers probably do less, but the contrast is stark, and sometimes less is more (security, maintenance, readability). I didn't count the loc of some clients sites I've looked at, but wouldn't be surprised if it was in the hundreds of thousands for relatively simple sites due to core and modules.

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.