Well, the UK is currently testing the opposite ridiculous notion - that by laying off lots of government workers (when there already lots of people looking for jobs), reducing benefits to everyone (which hits the poor far harder, of course), and cutting funding to education and research, you'll somehow help the country recover from a recession faster and better.
In fairness to the current administration, this was because the previous one had tested the equally ridiculous notion that if you stimulated the economy when things were going extremely well then debt would never become a problem
Edit: you can downvote me all you like, but that won't change the fact that the previous government ran up public sector borrowing deficits throughout the decade even whilst trumpeting their proud record of uninterrupted economic growth, and the only real disagreement in the political mainstream is over the _speed_ with which it needs to be returned to balance.
Public sector spending and working practices had been out of control for years - it was clear to anyone with any knowledge of how the public sector worked that it couldn't go on for ever and when it stopped things would be ugly.
There is no doubt that there are a lot of people in the public sector who deliver a lot of value. However, there are also a lot of organisations and people who clearly aren't - a tidy out was long overdue.
Indeed, a politically astute friend point out that the first reaction of managers would be to cut productive first line services first. The so called "Washington Monument Syndrome":
Laying off people who weren't and aren't contributing anything productive
Saying that UK public services are inefficient is one thing, probably true.
Saying that the layoffs can be confined to people who "aren't contributing anything productive" and be extension health, policing, education, research etc will not get worse at all is an entirely different thing, and I don't think it's true.
Just from reading through it quickly it includes the following things I believe are absent in all of the above (although I have only worked with ASP.NET MVC and MonoRail).
1) It has a built in web-server. This is hugely awesome, especially since it is based on Tornado. No mucking with Apache or Nginx, CGI, etc.
2) It includes command line app generation and compilation - missing from at least ASP.NET MVC.
3) Simple Routing - did you look at the route and lamba? That is awesome.
Some of what is here is similar to what exists, but this looks much improved. Pipes looks to be an improvement over the current HttpModules of ASP.NET. The view engine looks like an improvement over .aspx. The HTML5 template looks like an improvement over the crappy templates that MVC creates.
To be clear it isn't Tornado, it's a custom server inspired by Tornado. It sounds like the framework is fairly tied to the implementation of the server (most likely where routing, pipes, etc are all hooked up)
I posed the same question to the author on his blog. As far as I know at least ASP.NET MVC will run on Mono, and I would bet the other frameworks would as well.
I'm all for any new tool that would make my life easier, but it would be great to hear what this framework is going to offer that isn't already offered in the other existing frameworks.
> As far as I know at least ASP.NET MVC will run on Mono
ASP.NET (MVC or classic) is not efficient on Mono, the pipeline is too heavy, and Mono (at least until 2.8 / 3.0 is released) leaks memory if you're not careful with the object allocation patterns you're using, since the GC is conservative ... and of course ASP.NET leaks memory.
Async I/O is built around async sockets in the Windows kernel, and as such the API couldn't be implemented efficiently on top of poll/epoll. See this thread which is fairly recent:
ASP.NET (both MVC and classic) is designed for usage in an IDE ... and you shouldn't ignore this point. For references, compare the experience of using JSF / Struts2 to the PlayFramework.
It's practically the reason Java/.NET programmers say they can't live without IntelliSense, and Python/Ruby programmers are saying they can live just fine ... the difference it's in the design of those sucky APIs you have to use with Java/.NET
I also haven't heard of any web apps that are running on Mono, and if there are apps out there, pretty much nobody heard of them ... so this whole argument is a myth.
We've been building our web-based product on Mono and MVC2 for two months and are set to launch in under two weeks.
Initial benchmarks showed that the performance isn't that great compared to the same application running on Windows, but compared to similar applications on rails and django show that performance is comparable, even better than the dynamic frameworks (which is somewhat obvious since it's compiled).
I don't know of any .NET/Java programmers who say they can't live without IntelliSense. I certainly know I can, and do, frequently. Why, just this morning, I wrote some Java in Emacs. No IntelliSense there.
As far as async I/O, that is a problem. It might get better with the new GC, but proper async I/O would need to use one of the async I/O implementations available (libev/libevent, libaio, etc.).
I'm primarily a .NET developer on Linux. While I'm comfortable with other languages, and am quite proficient at using vim & and a little emacs - it simply makes no sense to not use an IDE for Java or C#.
These are tools built around the language and the workflow, and thus have been extremely tailored to ensure that productivity is high. While you can type the code out in any editor, and maybe even get CTAGS based completion and jump-to-type support, I haven't seen as tight an experience as MonoDevelop or Netbeans (or VS, but I don't know that very well).
There exists a tradeoff - you won't get the extensibility of Emacs or the efficiency of vi (they have vi-modes but it doesn't come close). Ultimately, when it comes to simply getting the idea from your head into the code, IDEs do help a lot.
How many frameworks is the right number? One is too few. One hundred is too many, it will just fragment people's skills.
Experimentation and inventing your own wheel is good for learning. But most of the time those wheels shouldn't see a wider audience - unless they have something new to offer.
This seems to be what Flask is to Django and what Sinatra is to Rails (From a very brief amount observation). There's a huge trend to move into more "lightweight", "self-hosted" types of development.
After building a moderate sized application (currently around 5-6k LOC) in .NET MVC2, some of Jacksonh's decisions start to make a little sense. However, there are a lot of situations when a paradigm seems neat but in reality it might not be _that_ useful.
For instance you can respond to queries using Lambdas/Anonymous delegates like Get("/foo", ctx => ctx.response.write ("foo")); YAY! I made a HTTP Response in just one line.
But looking at about 17 different endpoints I have in my application, not one will benefit from this feature. In the current model, I may spend a minute or two defining an action and specifying the route, but will spend atleast half an hour implementing it. For some reason, everyone seems to be focussed on cutting down the two minutes to one minute.
Also, this means that the routes aren't in one place. MVC2 has named routes and I can quickly change things from a single function. I used to like Flask's technique of making routing easier by simply specifying the route as a function attribute/decorator - but this made maintaining it quite hard.
Also, this tries to do everything. For instance, it allows you to serve static files as well like -Route ("/Content/", new StaticContentModule ()); When I have something like nginx which is known to serve files in a very efficient manner, there isn't any reason why I'd choose to let this server do it.
This seems fantastic for a quick hack and a tiny mashup, but for anything bigger, I'd definitely give it a second look.
> When I have something like nginx which is known to serve files in a very efficient manner, there isn't any reason why I'd choose to let this server do it.
A major selling point of this seems to be that you can package your application into a nice little bundle and just push it into your deployment environment.
In fact, I would appreciate if there was a way to make static files (like js and css) location-agnostic.
I could say:
<% Html.Stylesheet ("styles/foo.css") %> and it'll map to /Content/styles/foo.css or my nginx server or my Amazon cloudfront storage, etc.
No. You would have to know all the other frameworks in order to know that yours is simplest. You only need a few points of reference to be able to say it is simpler.
FTA:
"To me, writing apps with Django or Tornado has always been much more enjoyable. MonoRail and MVC were big improvements over webforms, but still they felt difficult to me, especially if you aren’t using an IDE."
I do wonder how much of that simplicity is because of dynamic languages and not directly because of the framework. I've done quite a few projects with ASP.NET MVC and in my opinion it makes most things pretty easy. But there seem to be some things in Rails that make life easier, but they are really features from Ruby that you can use in Rails.
Are you in the business of writing software that never gets used? I have, and I hated it. Quick feedback means quickly finding out if you're building the right thing.
Quick feedback means quickly finding out if you're building the right thing.
I agree. That's why I use a development process that encourages quick feedback. I don't consider that market research because I'm not out looking for customers to give me money in exchange for a DVD full of software. I'm sitting down with the person who hired me and demonstrating what I've done in the past week or two.
there is a lot of anger towards the agile movement because it was sold as a tool to pointy haired bosses to impose, rather than a grassroots movement among engineers that embraced flexibility.
the interesting thing is that the agile movement started as exactly the reverse of what you said: as a grassroots movement among engineers that embraced flexibility, not a tool to pointy haired bosses to impose.
If your experience is the opposite, you've been had by someone, and you're blaming agile.
whenever unit tests or test driven development comes up the proponents act like anyone not doing things this way is incompetent. I think the reverse is true
The reverse would be "anyone doing unit tests in incompetent", which is not a defendable statement. What are you trying to say?
Looks like in cases like that the bug tracker is making the underlying problems more visible. In that case, removing the bug tracker is not the way forward.
"The first Macintosh was introduced on January 24, 1984; it was the first commercially successful personal computer to feature a mouse and a graphical user interface rather than a command-line interface. The company continued to have success through the second half of the 1980s, only to see it dissipate in the 1990s as the personal computer market shifted towards IBM PC compatible machines running MS-DOS and Microsoft Windows."
Check your timeline. By 1990 betting on Microsoft was not betting against Steve Jobs.
Steve Jobs left Apple in 1985. Windows 1.0 was released in the same year. However Windows struggled at that point. According to Microsoft (see http://www.microsoft.com/windows/winhistorydesktop.mspx for confirmation) the first successful version of Windows was Windows 3.0. That was released in 1990, and its main competitor was a severely mismanaged Apple. At that point Bill Gates was emphatically not competing against Steve Jobs.
You can't successfully own code that you don't control.
I believe that the best outcome for both of you would be 20% of time set aside for refactoring and increasing test coverage. Sure you'd want more but features have to roll out too. Management may not realise that refactoring that much is necessary.
You may have to pad out estimates of new work, and say things like "in order to do that we'd have to understand the guts of the foo subsystem, and make sure that we don't break it while we change it, so we'll have to put tests around it while we change the code" while mentally adding a week's time refactoring and adding unit test coverage to foo to your estimate. Grease the moving parts - things that change once tend to change again, and you'll be happier the second time around.
If you can't even do that, ask them what they mean by "take ownership". Maybe they just want you to the go-to-guy for that particular monster. Say what would do if you really owned it. If you are completely overruled, you may have to be blunt and point out that this is not ownership in any non-bullshit sense.
If that fails, as the wise man said: if you can't change your company, change your company.
I'm not sure, I've never had a kindle (and don't do Apple products). I'm pretty sure I'd enjoy a real book more though. I'm getting the kindle because it would make importing English language books here in Italy a lot faster and cheaper.
Banks - their back-end processing is often in Java.