Haskell is not only for surpassingly intelligent people, or even optimized for them. If anything, it's the opposite: one of its core tenants is that we're not smart enough to reason about our programs in most languages. Much of the design work focuses on unloading complexity into the language, tools and abstractions.
Haskell goes out of its way to prevent common errors and help you design your program. In a very real sense, it trims the "search space" of possible programs, helping you zero in on a reasonable solution. To an extent, I use Haskell because I'm not smart enough to use C.
Haskell is unfamiliar. And people mistake that for some sort of innate difficulty. But the two are not the same.
I would argue that overcoming unfamiliarity is one of the most important ways to grow as both a programmer and, more generally, a person. That's why I think the article focuses too much on choosing a language that's familiar, codifying it as "just about all the good advice". This mindset is far, far too exaggerated in most programmers, and its what really slows down progress, especially for popular programming languages.
The blub paradox is also a bit misrepresented. Being a "blub" programmer is not a matter of being more or less intelligent—it's a matter of not knowing what you're missing. "Beating the Averages" is not "we used Lisp because we were smarter than you"; it's more like "we used Lisp because it offers some incredibly powerful tools that non-Lisp programmers have never used and so do not really appreciate". It's a matter of habits and experience, not intelligence.
My advice? Do try something unfamiliar. Especially if it seems to be higher in the great partial order of programming language power :).
Haskell discounts the very useful choice of reasoning about your code after it runs, favoring, instead, all-upfront reasoning, often at the expense of facilitating the former. There are some domains where figuring everything up front is very important. Others, where trial and error is far more productive.
Trying unfamiliar things is very good advice, but not for an important project you want done relatively quickly, and which you'd have to maintain for years to come.
Huh, I have never thought about it like that. Thanks.
I used to be a bench chemist in a pharmaceutical company and the tools we used to develop new drug candidates and the tools we used to put them into mass production were radically different. I don't see why software should be any different. Let Haskell be the proving ground for new ideas and we can cherry pick the best ones for simpler languages later.
This is a very interesting observation. I would hazard a guess that Phil Wadler developed (or at least significantly contributed to proving type-theoretic soundness of) Java Generics and Collections after they sort of proved their worth in Haskell world.
Same with Lambda which made its way to Java 8. STM is perhaps next.
I would say that adopting a language for the next 10 years that doesn't have purely functional data structures at its core is a fool's errand.
Persistent data structures, i.e. efficiently storing every version of your data structure, is the natural reflection of the new reality in computing where:
* storage is cheap
* random reads are cheap
* random writes are expensive
* serial writes are cheap
What will matter is that persistent data structures will inevitable become commonplace over the next decade and that techniques for leveraging it (such as functional reactive programming) will be adopted in one form or another.
@jacquesm: I live in Amsterdam so I can try to explain it to you in person once; virtually everyone still underestimates the impact this will have and (or perhaps because) it's very difficult to get that across in writing.
Besides your listed reasons mutable state is becoming a bigger and bigger bottle neck as the number of cores goes up and that's why functional programming is becoming more and more important. It also makes programs much harder to write in a bug-free manner and it makes testing much more difficult (if not impossible).
It's one of the core reasons why I felt so bad about dropping Erlang from the list because I feel that it gives me that plus a battle tested environment to work with.
Still tempted to put it back in. Your reasons add weight to an already very difficult decision, whether or not to pursue this opportunity as a way to get more into functional programming or to stay in my 'comfort zone'.
I've been toying around with FP on and off for the last couple of years and it is one of the most important revivals the computing world has seen to date (imo of course).
Finally, I must say that while Scala does indeed have a first-class web framework in Play, web frameworks are first-class objects in Clojure. Joke. Sort of. I personally do not want to have a monolithic pre-packaged web framework to bow down to; the Clojure community is a community of hackers, we like to make things out of other things, and to take things apart. Clojure and the work of its community allows me to compose my own web framework as needed very very quickly–and to drastically change it just as fast. I'm not saying you should stop doing what you like to do, but if you gave Clojure a chance...dude: it's addictive.
The code I write now is nothing like Java, but it's a question of how you get from there to here. When I started Scala I wrote what I'd write in Java. In the first week I removed the semicolons. In the second week I started to use function literals. Then I started using match/case. Later I found out about for/yield with futures. And so on. I learnt the language at my job, and I was delivering real, user-facing features in it from day 1. I don't think I could've done the same with Clojure.
(Reasonable people can disagree on syntax; I find that Scala's lets you get very close to the language of the domain (e.g. see the Spray "routing DSL") and that's worth the cost it imposes on the macro system)
Also, sometimes you want your updates to a data structure to be seen via an alias (happens often actually), then we are back at square one again.
Systems people are much more pragmatic about this: they see the trends in hardware before we PL people do, and their solution has never been functional programming. Ok, well...maybe once with MapReduce (but Jeff and Sanjay are both systems PL people).
Adopting it successfully does require separating essential from accidental state which naturally leads to some variant of FRP being adopted to manage (re-)derivation of accidental state; which is usually the hard to explain part.
I am wondering what you do see systems people doing by the way? I'm always interested in broadening my perspective on this.
The systems people I work with do a lot of key value stores (sharded NoSQL-style databases), there is a lot of pipelining for data parallel processing (MapReduce, Pig), and there is still a lot of classic locking going on, throughput is important. Oh, and lots of Paxos, logging, state replication, etc... The normal stuff you could find at Google (note I don't work for Google).
On the HPC side, the people that really care about performance, there is some map reduce via MPI, but most of the big gains are to be had in CUDA, which is an extremely imperative programming model with very synchronized core executions and memory accesses.
I've learned that whenever the FP people talk about high performance, they usually mean something else (like concurrency that isn't so slow), rather than the real high performance stuff that the big kids (systems and HPC communities) are doing.
The reality though is that well over 99% of the market works with data sets for which, with current hardware, the performance costs of these persistent data structures are very much irrelevant.
When you add FRP on top of that so that you can keep your managed state minimal you can actually often achieve quite dramatic performance improvements over the traditional hand-written data-to-UI synchronisation.
For persistent data structures to come into their own for big data quite a few more things are needed of course; but if you look at Nathan Marz's Lambda Architecture for example it's little more than a handwritten system for making large scale persistent data structures manageable with today's systems already.
I'm fairly sure that tooling for that will only improve over time until the very thought of manually managing derivation pipelines becomes as quaint as manual memory management.
As for HPC; yes... I would not be surprised at all if at that level mutable state no longer is a premature optimization. Even there I could imagine many of the more high-level control structures benefitting from persistent data structures though.
About the FRP part; which competing paradigm are you working on? I wouldn't be able to name a 'competitor' so I'm quite curious.
Yes; the managed time approach in Glitch is very interesting and indeed a competitor towards addressing the same problem I originally raised.
The core of my original statement/problem definition was that real mutable state, i.e. throwing away history by default, was no longer the smart thing to do given current hardware.
From what I can tell you would also agree with that...
Why is it hard to get across in writing?
a) it requires putting together a fairly large number of concepts of moderate complexity (and you never know which ones your readers already understand.)
b) many of the concepts sound trivial and people usually don't grasp their power until you've listed X amounts of things it would enable.
And to be clear; it's hard for me to put in writing for now ;)
Look at Python: The only reason people started to use it is because of the syntax. Now it's slowly eating Matlab and R in science - two specialized languages beaten in their own domain by a general purpose one because the general purpose one has nicer syntax.
How great wouldn't it have been to have a Haskell-like language with a Python-like syntax? But no, Haskell needs a "first-class syntax", as if keystrokes are the limiting factor in development.
I've seen this criticism before, and I don't understand it. The syntax of Haskell is not that big. There are some things a bit funky about it, especially the indent rules, but I don't see what there is to be mystified about.
On the other hand, it does introduce a lot of mind-bending concepts if your background includes imperative programming and no category theory, and that's typically what people find hard to grok. You don't find a pile of "Haskell syntax cheatsheets", you find a bunch of monad tutorials instead.
plus any more potentially introduced by any libs, or whatever else. When I see any Haskell code, I feel that I trip on those every time. And among them, especially confusion between: -> => <- -< >>= >>
Neither is APL's syntax.
Too much operator overloading is just a bad idea.
But one thing where Haskell errs, in my opinion, is in allowing arbitrary infix operators with random ASCII characters, which library maintainers take as an encouragement to each create their own DSLs which totally makes sense to them and nobody else, but that's not the same thing as saying that Haskell-the-language has a huge syntax. Maybe that's what you mean.
Another quick way to measure this - compare that beautiful pseudo quick sort to real quick sort (e.g. using Array.ST)...
(And if you're going to use Play, Scala is very much the best way to do so)
In most languages I have learned I've generally reached a point fairly quickly (without hours) where I've thought "wow - this is cool!" and this is generally because of enabling me to do something more easily than in other languages - I've never got to that point with Haskell.
Note - this is just my own observation, not a criticism of Haskell or any of the resources I have used to try and learn it!
In any case, I'm definitely not smart enough to use it. The issue isn't functional programming, though, which is why Elixir looks very interesting.
Given I have been working with web development in Ruby and PHP for years, I would love to find a nice "getting started" guide for a good/well established Haskell framework.
It also comes along with a free online book: http://www.yesodweb.com/book
Other popular alternative is Snap framework.
Which brings up another point: if we're talking about web frameworks for the next decade we should really be looking at service-oriented architectures / single-page apps or whatever you want to call that model. It's quite different from the web frameworks of yesteryear that generated UI on the server. Dropwizard can do web views but it really positions itself as a REST service framework.
That would eliminate it for me.
Not everyone is coding APIs and fat client web apps. I'd prefer a framework geared up to do standard web apps as well.
I'd be including a consideration of AngularJS, Backbone, Ember etc. + a service-oriented backend framework like Dropwizard. That's also incidentally how you'd architect your backend support a native mobile client, which is a good thing to prepare for even if you think you only need an HTML frontend right now.
Don't forget that old style web apps are basically REST frameworks that render content with a content type of text/html...
They really aren't. A REST API wants to be simple and orthogonal; if you want two different pieces of data you make two different calls, so they're well suited to the "one controller per URL" paradigm. A traditional web app needs to combine and reuse components on every page (e.g. you might have a "messages" widget or a "user info" widget, which you would want to be encapsulated with their own logic), so you need better support for composing together different pieces of logic, and a single controller no longer makes sense.
JSF it is :(
Dropwizard is still pretty easy to use for a Java developer but has the advantage of being standard Java and pulling together the very best open source projects out there.. so it inherits the communities and experience around each of those projects. That probably has better prospects in the long run.
I mean even if Dropwizard goes away, it's basically a glorified bundle of those projects which already have multiple years and tons of usage behind them.
Play does seem to have a burgeoning community though but it's too early to tell whether it's "take over the world" or "go the way of Scala".
I really think the author is missing out here - for the sake of just sticking with what they know and not wanting to do any actual research, it's impossible to come up with an actual objective choice. So misinformed, I get that .NET/C# development is not everybody's cup of tea but I think it's crazy to title an article "Choosing a Web Framework/Language Combo for the Next Decade" without even evaluating an extremely popular option due to simple disinterest. The lawyer comment is just irrational fear (and I get is probably meant to be a bit of a gibe towards Microsoft's licensing schemes), unless you're writing something completely from scratch, you need to be aware of the licenses of ANY library/framework you depend on, even if they're free.
Anecdotally, I agree with that. I once built a product on GWT because it impressed me so much on paper. Static typing, compiling permutations of your app and loading only what's needed, optimization of stylesheets, rendering only on the client etc. It seemed perfect. IIRC the two main issues at the time, a few years ago, were a) terribly slow tooling for any decent sized app and b) the usual interface-hell of Java. This may not be a problem if you're used to it, but for me it was an issue.
Did you hear that from a Googler that actually knows their long term budget/support plans for GWT, or just the usual misguided rumors?
Right now Google has 4-5 full-time developers working on GWT because it's used by AdWords (huge) and literally 1,000+ other projects (private and public) inside of Google (including for parts the new "Sheets 2.0" of Google spreadsheets).
The end-of-life comment aside, which I'm admittedly defensive about, your other criticisms are unfortunately very valid.
Personally, I think a good framework is essential, and the compiler is a known issue that they currently have several smart people working on. We should see by mid-summer if they pull it off.
Just to play devil's advocate, but with any compiled-to-JS language, you're right back to where GWT is with superdevmode: stuck in the browser's debugger.
My hope is that with enough "compiled-to-JS" languages (Coffeescript, etc.) becoming popular that browser vendors will build a standard debugging wire protocol, much like the JVM's, which would allow IDE-based debugging of sourcemapped JS code.
This project is taking that on for Eclipse, which is a huge challenge and I'm very impressed that they're even attempting it:
Given you use IntelliJ, which typically has a much faster turn around on supporting bleeding-edge browser/etc. integration, I would actually except them to get it first.
Google has a habit of pushing tech out for people to build on and then pulling the rug right out from under them.
A citation would really help here but 'I heard' makes me realize that will probably not be forthcoming.
Google did "re-open source" GWT a few years ago, and unfortunately it coincided their (AFAIK unrelated) closing of their Atlanta office (where most of the old GWT team worked).
So, it gave the impression of washing their hands of it, but in reality they a) staffed their GWT team back up to 4-5 people, and b) the open source model is much healthier for the project anyway.
(Previously the master GWT SCM has literally Google's internal Perforce/etc. repository, so any patches from external contributors had to be fostered by a Googler that cared about your issue, which made it really hard/impossible to have an external community of committers.)
This is no longer a problem in Python because of virtualenv and pip, which together allow you to tie down the version numbers of all the dependencies an application uses.
The lead developer, Qiang, is literally the second most active developer on github, so it's not like they're not trying - the guy is currently on a 370+ day streak - it has taken a huge amount of effort for them to get to this stage.
I would personally build on the beta at this point because I have a lot of faith in the core team and they've had a lot of time to iron out any major problems, at this stage any changes are likely to be quite minor or fixes, so the real release will probably ship before your new project does.
Kohana seems dead and CakePHP has historically been rather slow and ungainly.
The lack of library support for Lua is a bit annoying, but it's getting better and can possibly be mitigated by using Lua's FFI to talk to C. If the eco-system was a bit more mature OpenResty would be pretty compelling.
Out of PHP frameworks, I would rule out anything that doesn't use Composer. If you can't use the best bit of tooling PHP has gained lately (other than HHVM) and are stuck copying libraries in by hand, well if you want it to survive then you've made the wrong decision IMO.
Personally, I would pick either Symfony or Laravel, the latter for development speed, the former for robustness and power (and explicitness, I'm working on a 400k line web app in Laravel which has had too many shit developers hacking on it over the last 12 months, and we get bitten by magic weekly because a long since fired or quit dev worked against the framework rather than with it).
I just cloc'd my projects root and including laravel and some dependencies (/vendor) that's 295,000loc).
It's a corporate real estate web app, client facing and internal all in the one big app, so they can run their business (taking on a MASSIVE incumbent in the industry) all from the one bit of software. Has nearly 100kloc in an Angular front end, too. Huge bastard that I inherited two months ago, and have finally got it to a state where we can hand it over to the clients internal team. Easily the most challenging project I've tackled thus far in my career, but I managed to do it (with the help of two other awesome developers)!
The life-cycle of the software underpinning what I build is as important or even more important than whether or not it is 'the best way' to do something today. Because that best way is the bleeding edge and the day after tomorrow (or even tomorrow) that will be something else.
I don't have the manpower nor the interest and time to keep rebuilding the stuff I put out there.
It's a lisp that, as opposed to Lisp and Scheme, is not fragmented and seems to have mostly a healthy, united community. I see amazingly smart people, and so many of them, pushing Clojure forward (Rich Hickey, Stuart Sierra, David Nolen, Chas Emerick to name a few) and yet it's more approachable than Haskell. And I think these people will eventually find good, standardized solutions for things like the awfully ugly stacktraces.
At first it felt like a very mixed bag. There are a number of reasonable if boring things that Rails provides that help make it easier to get your app production-ready––robust logging and asset compilation come to mind––that generally have to be hand-rolled in Compojure (as in microframeworks in other languages). More generally, there aren't many clear signposts from an architectural point of view––for example, there does not appear to be much community guidance over how to organize your namespaces, or how much code one should contain. We made some messes early on.
Once my partner and I got past the initial pain, however, we were extremely pleased with our choice. There are still times when I suspect Rails might have gotten us to market more quickly, but Clojure feels like a good ten-year choice. I certainly agree it's worth a second look.
* I believe that the incidental complexity in web development is rooted in state and in the interactions between various pieces of state in the app. Choosing tools and patterns that reduce state generally results in composable abstractions and more reliable systems. I don't have the solution to web development (FWIW, I use Clojure server side and React client side) but evaluating every new tool I come across against this criterion makes it easy to decide whether to adopt it or not.
If you have a Backbone app, replacing your Backbone views with React is a pretty substantial win. The Backbone app structure works best if you can just listen for a change event and run your model through template code and slap it into the DOM but that gets complicated if you want to nest views, the DOM you're replacing has state, or you have something like jQuery UI widgets. All these issues simply go away if your view code is React and everything just works. I don't find the Backbone abstractions too useful so I've only done this personally when consulting and wanting to make the minimal set of changes to the codebase.
I was using Angular for two years before I switched over to React. React basically replaces directives and for that use it's simpler, composes just as well, and scales better for both data size and dom node count. Replace the Angular DI stuff with browserify/webpack and Jest and there's not that much left. The main reason to use Angular would be if you want to take advantage of the Angular ecosystem or if you plan on focusing mainly on directives to support a bunch of designers since non-directive Angular is super simple.
For other stuff, the main benefit in a two way databinding framework (or virtual DOM diffing) is that you can isolate your business logic from the DOM. That's the major win and everything else is pretty much taste. The React approach results in the least amount of state in my code by a fairly significant margin so I consider it the best but having different preferences is completely reasonable.
Rails is pretty much the premier MVC framework. If you are going to go MVC, go with Rails. If we are looking for an alternative to Rails, then we are probably looking for an alternative to MVC, and none of these mentioned choices fit the bill.
I wonder when the day will come that we finally get sick of recreating all the libraries that typically go into an MVC framework. That day, Rails will still be going strong and we will probably give up and just go with Rails.
Of all the choices mentioned, not many have been around as long as Rails. For every day that Rails survives, the stronger it becomes. The more likely it will continue while the alternatives shrivel.
One day MVC may become obsolete, but some people might still want to use an MVC framework for whatever reason. That day, Rails will be there waiting for you.
Years ago, I watched the video on how to build a blog in 10(?) minutes. Today, I can still somewhat follow that video. With many of the MVC frameworks in this list, you couldn't do that. ZF1 is not ZF2 for example. The framework was completely changed. They might as well call ZF2 by a different name. If it were called anything more interesting than "Zend Framework" then maybe it would have a different name.
Go is interesting, but the MVC web framework ecosystem has to be created, just like we did for Node. I don't even know if that will happen anytime, or ever. Maybe people are getting sick of doing that. And then you need to wait X years to see if something actually has any lasting power.
Screw it, just go with Rails.
Or Django. ;)
ETA: A blue collar match as opposed to an academic match. ;)
others may appreciate its influence but can see that a lot of what it offered is just a convenient packaging of what is available in other languages, presented in a more inviting "DIY" form. I used to be a Rails guy & have since learned Java. There is not much I miss, if anything.
I could definitely do some things faster in Rails but now... I don't know, given the task of creating a CRUD interface in Rails or Java i think i would be faster in Rails but not by a wide margin. If I had to add any side-effects/system integrations/free-form code/advanced persistence with the expectation that it will be performant & scalable -- I would be lightyears quicker in Java.
The kicker for me though is that I would expect the Rails application to need a gem upgrade, security patches, server migration, or minor refactor to comply with plugin API changes at least every 6 months. I think the Java app could sit on a cloud host for a decade without any maintenance required (provided it implements pretty open specs).
I mainly code node.js & client-side js for hobby projects, but am considering Dropwizard or Clojure instead of node (I only use this because my apps are pretty json heavy so I'm trying out mongodb and want to go full-stack js). I know I found it daunting to leave Rails & go to more free-form code, but now I find it really liberating & I'm not scared of much. There is a Java lib for pretty much everything. NPM is pretty well-stocked too.
I now rather like significant whitespace and often find myself considering that my ideal language would probably be half way between Python and Lisp.
Anyways - to mitigate the risk of misaligned code. The usual thing is that the wrong type of indentation is used. I use sublime text and in that editor there's a button where I can convert tabs to spaces and vice versa. The other thing is that of misaligned code with your existing code. You can usually get some plugins that handle this for you. In Python I use the Anaconda-plugin with the 'Auto format' feature which aligns in accordance to the PEP-8 standard.
I'm very happy with PyCharm.
You might like F# then. It's concise like Python and has all the power of functional programming.
The dismissal of Python and not Ruby over arguments of slowness of execution and dependency issues seems backwards to me.
The main reason I choose Python is because I can jump into a codebase that is years old and immediately understand what the code is doing. Brevity and readability trump just about everything else for me. I also like the pluggable nature of the Flask ecosystem.
Dismissing python due to maintenance difficulties and not Ruby seems weird. Both are highly dynamic languages with not much help from static analysis, and this is for me the reason why maintenance may be hard.
The fact that whitespace was an issue to OP probably means he never used PyCharm. I haven't had any single syntax issue since I started using this IDE.
- Dropping JBoss Seam as a framework was a good choice because the important parts of Seam have been added to the JavaEE system, which provides an end-to-end set of technology specifications. If you choose to run a Java Application Server (such as JBoss EAP, Glassfish or Wildfly), then the server will support the full set of specifications, but you don't have to use them. Since JavaServer Faces (JSF) is one of those specification, I'm not really surprised you hadn't heard of it ... it's essentially JSP with lifecycle control and data-binding.
- If you're looking for an ORM, none of the Java frameworks will include one directly, but it should be pluggable. When people talk about Java web frameworks, they're often constrained to just the "View" tier. Spring provides a much more full-featured stack (with DI and JPA) and is more analogous to JavaEE as a whole. I think you should consider those two as the full-stack contenders in Java. You can add GWT onto either if you need a client-side Java technology (I'm sure you'd NEVER use Java Applets for the client side right?).
- I happen to like Scala and appreciate how purely it seems to add a syntax to Lambda calculus. Martin Odersky's "Principles of Functional Programming in Scala" on Coursera was a great class, but I'm hoping the Scala IDE advances quickly. I'll admit I've never written production software in Scala (or using WAVE) but I also admire one project that's using it successfully (https://github.com/takezoe/gitbucket).
I should have also stated in my comment above that I almost gave up on Enterprise Java back in the J2EE 1.4 days (2005-2007 if I recall correctly). When you have to create multiple Java files for every EJB (mostly Entity and Stateless Session beans) and edit XML deployment descriptors (many times one deployment descriptor for each supported application server), Java programming feels as tedious as many people describe.
The contrast with JavaEE 6/7 is amazing - the technologies that are encompassed in each of the specifications tend to follow the same pattern. Write a POJO and add annotations. For instance, if you need a business method that consumes messages from a message queue and processes them, that's one (short) Java file with some annotations. For a more complicated example, if you have a database table and want to expose the records via a RESTful interface, here's what you'd have to write six (small) files as follows:
- One entity bean with fields annotated for the ORM as well as accessors and mutators.
- One stateless session bean with your business methods - in this case providing CRUD operations against the entity bean (using a PersistenceContext from JPA)
- One JAX-RS annotated class to provide the RESTful API's methods (again an annotated POJO).
- One Application class (with very few lines of code - it activates JAX-RS).
- One persistence.xml file to define a datasource.
- One (empty) beans.xml file to activate CDI.
If you stick with the JavaEE annotations and configuration files, there are some real benefits to this structure:
- The ORM's entities and configuration are database agnostic ... the same WAR file could be deployed against your MySQL servers, Oracle (for those who have money to burn) or PostgreSQL.
- The application will run on any JavaEE compliant application server. Deploy the file to Glassfish, Wildfly, JBoss EAP or even WebLogic (for those who have money to burn).
- The ORM will cache entities (and can be configured to use a second-level cache when it's prudent). When you start caching database rows, you have to be careful and there may be tuning involved.
- The Application Server will create pools of each of the objects that will be used so that it's not creating and destroying objects over and over again. This is a huge performance gain for servers with a lot of request-scoped web transactions that use stateless session beans for business logic.
There are also ways to create enterprise Java applications that are a little more light-weight (though today's Application Servers have lost a lot of their girth). If you simply use a servlet container you can still use JSF which has a better templating engine that JSP. You can add CDI by including the library and a little bit of bootstrap code. Application servers like Apache TommEE start with Tomcat and add libraries as needed.
It also occurs to me that the "experimental phase" you're embarking on could be leveraged to be both crowd-sourced and open-source. Since you're starting from scratch with each of these technologies, wouldn't it be interesting to have a complete newbie and an expert produce the same application using each of the surviving frameworks?
If you publish a light-weight specification for your test project and open a Github project with each framework's implementation in a sub-directory, I'd be really curious to see what efficiencies and problems were experienced with each implementation. It would also give you a way of comparing your implementations to others.
Starting at the framework end doesn't help me much. Instead I go with the people I have for the project and the things I want to do/validate - and start looking for what gets me progress as quickly as possible.
It's an exaggeration, of course, but the fact that we're undergoing some big changes in web development (more on the client-side with server-side api) makes me thing this might not be the best moment to think of picking something for the next ten years.
Express  has been the dominant framework for Node.js since 2009-2010. What frameworks are you talking about?
It's just a router and a few middleware. Hapi or Actionhero are frameworks though rest ones.Express is definetly not a framework,it doesnt do anything much.
Writing Spring like, Symfony like frameworks is hard in nodejs. Libs are bad,often tightly coupled,and frankly nobody's maintaining nothing on the long run.
Consider that your definition of a framework may be different from others.
But I get what you are saying, Express was among the most stable+popular pieces of js done in the last years.
Once it does that, I don't think there will be any doubt in anyone's mind that Go has less chance of survival than say Java. In fact, Java will immediately lose confidence once Android drops Java (in a reasonable 3-5 year timeframe).
Or that Android apps would be compiled into binaries executed without a VM?
Either way, fascinating idea, and it would be a good way to settle the Google/Oracle dispute once and for all. If they choose the second path (security will be a huge concern) they might even pick up a nice speed boost too.
> Or that Android apps would be compiled into binaries executed without a VM?
What I imagine in my Android-Go-fantasy is something like NaCl - your code compiles to native code, but a subset of provably safe native code ... so sort of a best of both worlds.
Symfony dumped all symfony1 users up s* creek when Symfony2 came out; Zend framework 2 is an entirely different beast to ZF1...
Are these mature frameworks any more stable than the new ones, or are they new frameworks, phoenix-like in assuming the name of the old one?
On the other hand, major version releases are when you make such dramatic departures from what's come before. At least in ZF, they got a lot a lot of things more-right.
I moved a (pretty complex, line-of-business transactional-type) project from ZF1 -> ZF2, and I'm happy I did. Some things changed a lot (dispatch, routing, forms), while other things were very easy to translate (caching, logging, etc).
In that case, most of the business logic was built around Doctrine2, encapsulated nicely into service classes, and therefore fairly framework-agnostic.
I'm glad that transitioning your project from ZF1 to ZF2 was worth the effort and relatively easy. I have a number of clients still on symfony 1.4 because although unsupported and a 'dead' system, without a straightforward migration path to Symfony2 it doesn't make economic sense for them to do so - not when the whole web system (CMS, order management, the rest) is written using symfony 1.4 and Doctrine 1.2. Until it stops working, as it's going to be a new build either way.
I think that kind of framework dead-ending is fairly irresponsible; certainly some of my clients thought I was irresponsible to have chosen Symfony when their 1-2 year old systems needed to be rewritten...
To be honest I still don't see any compelling reason to switch to anything else in 2014, but if I was looking I'd be strongly favouring Go as the language, as it seems like the preeminent forward-looking, popular-ish, well-supported language. Rust and Erlang would also get a look in.
Although looking forward, I have a strong feeling that HHVM/Hack will become one of the darling platforms given the amount of resources Facebook has and the poor state of performance many PHP frameworks are currently in.
Yes, Laravel does have a high "bus factor", but for me personally its the number one choice in terms of ecosystem, features, support and community,
There's a huge and active Laravel community, it's just that Taylor is the benevolent dictator.
If Taylor was hit by a bus, there would be plenty of others who would be willing and capable to take up the baton.
Seems to me pretty remarkable to rule out Laravel on this basis, yet keep CakePHP, ignoring all its other flaws.
Their approach is to have the whole framework compiled as an extension. Seems well documented.
Personally, after years of dealing with PHP and the regularly occurring panic when inevitably something is going wrong during deployment, I'd consider PHP's dependency on other moving parts a bit of a nono. There's just too many pain points around deployment, versioning, server conf, extensions that are compiled in etc. Admittedly this has gotten much much better since the advent of composer and tools like chef, vagrant etc, but that's another whole learning curve right there.
Compare that to go, where you just compile your binary, scp that up and then launch it. Done!
In this context (Restful JSON or XML from the server, JS client consuming it) Go again makes a great choice, as it's coming with great JSON and XML capabilities that make it easy to marshal/unmarshal into GO types.
I recommend that you take a second look at Scala. Considering that you "have a working knowledge of Java (but really don’t like it)", I think Scala is a good choice.
The usual cliche-but-true reasons:
A. It runs on the JVM, arguably the most performant VM.
B. It has mature, huge (Java) ecosystems. High quality IDEs, rich (3rd party) libraries, a plethora of build tools (for better or worse) and profilers.
But for me personally, the things I like about it:
1. I can use different languages (as long as it runs on the JVM, obviously) for different needs. Probably not wise to mix a dozen languages (http://en.wikipedia.org/wiki/List_of_JVM_languages) in a project, but at least I have a choice.
2. Since I'm a Java developer during the day, I can reuse my skills (can use same framework, same debugging approach, same build system).
3. I can start coding with Java/imperative style. When I started learning Scala, I literally coded like in Java, minus the semi-colons. Over the time, I enhance my coding style because I keep thinking, "There's gotta be a better way of doing this." At least this lowers my barrier to learn Scala.
EDIT: IntelliJ allows you to copy Java code and paste it as Scala.
Obviously you can replace "Scala" with "any JVM language other than Java", but I have my specific reasons in choosing Scala (over, say, Clojure).
My criteria differed somewhat, but the gist was the same -- maximize your investment, position yourself well, and as Wayne Gretzky would say, "Skate to where the puck is going."
I'm in a rush to be somewhere, but here's a quick rundown of my key criteria for a 10-year language:
1. Concurrency Model (we're in a multicore world)
2. Data Processing (data is driving everything)
3. Platform (cloud platforms are the new OS)
Python for its practicality, massive library in general and also in the data processing/data science space.
Clojure because of its concurrency model, first-class Java interop and thus massive library, plus its simple elegance and limitless potential appeals to the painter in me.
Go for its concurrency model on top of being a well-designed systems language that's backed by Google. I think Go is going to be the language to emerge as the dominant player in the next 10 years.
All three languages work on App Engine, and Google's Cloud offering is another one of those "skate to where the puck is going" things. It's already the most technically advanced cloud, and you can see signs that it's about to catch a Google-fueled hockey stick and blow past AWS at an exponential pace.
Honorable Mention: Scala.
Scala is in use by big companies like Twitter and LinkedIn, and it's the code behind some of the key open-source systems like Spark, Finagle, and Kafka. And Spark's the data-processing skate-puck destination: Cloudera is adopting it, and the days running up to the Hadoop eclipse keep growing shorter so I suspect Scala and I will keep crossing paths as these tools continue to make the rounds.
It's a good thing. By the looks of it, the community might be jaded in some way, which means no more running around trying to be the coolest /fastest kid in the block, mostly everyone just wants to get stuff done. The amount of useful gems and well-maintained libraries (years of being maintained, not just a few months) is amazing.
The language matured enough, and the ecosystem along with it. The ecosystem still has some flaws and voids here and there, but that's what makes it exciting in being part of it.
I don't use Tcl (not TCL!) anymore myself, but it'd be more honest to say that it's not that popular these days or not a language you happen to like. This is built with Tcl just fine:
With that out of the way, I think that was a good read, and a reasonable process. It's fair to be a bit subjective about some things, because... we're humans, and that's the way we are.
Personally, I use Rails as my go-to framework because while it's not super fast, it's very, very full of useful things to get up and running quickly, and keep iterating once things are built.
Edit: good catch David, I used modern web in one instance and 'web' in two others. Changed that to be consistent. TcL now properly spelled. Have a well deserved upvote :)
The l is a small l. Kind of like Fortran vs FORTRAN or Cobol vs COBOL or Perl vs PERL. Tcl people prefer Tcl.
I actually think Tcl would be fine for the modern web (it had an event loop before it was cool to have an event loop), but you could easily eliminate it for many of the reasons you eliminate other things - not too many people working on it, not as many ready-made components as something like Rails, and so on.
1. A awesome ORM
2. I could use Ruby for iOS applications(Rubymotion).
4. Great for writing scripts and little one off things I needed to do.
5. Capistrano (although you can use this with any language)
6. Opal(although this really hasn't taken off yet).
7. People are actively trying to speed the language up. MRI, JRuby, Rubinius.
So I invested in Rails because of the other things I could do with Ruby in addition to web.
This is all before the frameworks are even discussed, which are included and dismissed for reasons just as arbitrary. Smaller frameworks like Sinatra are discarded because they can't handle the complex logic that flash cards demand, Django's out because of the whole auto safety thing, and we all know that ExpressJS didn't show up at Jaques' birthday party that one time. Play's out because Scala is unfamiliar, despite that not being a specific quality of Scala and just something that's true in general of programming languages one hasn't bothered to learn.
So the final list contains some more PHP horror shows and a few Java and Go frameworks to make things look democratic. Thankfully, Rails makes an appearance, but it feels like this is just because it was lucky enough not to get hit by a dart.
Let it be a lesson -- we all procrastinate, but when you get to the point where you're writing blog posts about dozens of languages and tools, none of which you have direct experience with, the best thing is just to pick something, do what you'd meant to do in the first place (although you will note that writing the flash card app was itself a way to procrastinate on learning Romainian), and discuss the pros and cons of the tools you chose once you actually know what they are.
People are experimenting with new frameworks, e.g., beego, revel, martini, etc, but I don't think any of them are stable enough to meet your stringent criteria in that regard.
It seems to me (as an outsider looking in) that the Go community is relatively "anti-framework", instead preferring libraries, like Gorilla, for special oomph in routing or sessions or what have you.
I also think it's worth determining what you think the next decade's high level architecture will be: JSON api backends with fancy JS frontends, or more along the lines of standard Rails, Yii, etc? That will drastically change the type of web framework to choose.
So you are absolutely right. Will drop it from the list to try and will update the article.
It's actively developed (just follow the dev branch, which is quite stable) and the devs/community have been quite helpful. I wanted something much lighter than Laravel, but still have all the handy features, and that fit the bill. Based on your requirement of sheer usage numbers though, I don't know if it meets that (yet).
I'm not the only one who'd like people to choose frameworks and languages on something other than gut feel and googlefight results, right?
Of course specialization is optimal but as soon as you have to make multiple things and your resources are limited then a general purpose tool is the better choice.
Compare it with hammers. If I only need to do metalworking I'd buy a bench hammer. But if I need to do metalworking and woodwork then a clawhammer is probably a better choice.
As for the selection process, this was just the preliminaries, it's far from over and the next step will be a lot more work.
Finding Erlang programmers is admittedly more difficult, but finding someone willing to learn Erlang is not too big of a problem. It's also not a big deal to learn Erlang, because the language is simple.
As someone writing Erlang code for years, the good parts of using Erlang far outweigh the bad parts.
Presumably if you are an Erlang programmer, that is a plus point.
And the part about Python code breaking due to external modules must be a joke, right?! How hard is to specify a fixed version in the requirements.txt
Re: why there were so many "PLAY!" results in Google, that would likely depend on the query you use. Something like "play framework" would probably match for any page where someone said "I will play with this framework".
...which is another reason why "Go" was such a bad idea for a language name, BTW.
go: about 2,550,000,000 results.
go language: about 3,630,000,000 results.
golang: about 1,950,000 results.
I wish the poster published the Google query strings he used because I get very different results. Examples:
gorest: 984,000 results vs 6580 in the post.
ruby on rails: 11,900,000 vs 258,000.
And while Grails today is a great servlet framework, Grails 3.0 will allow new application profiles, like netty, hadoop and batch.
Additionally, even though I'm not a fan of the following frameworks, but any java web dev know about jsf (due to being pushed as the "standard enterprise web framework") and vaadin.
Is it somehow associated with a branch of industry that I don't have exposure to? Do you have some examples from the 100 top websites written using JavaServer Faces?
That would help me to place it better.
I'm quite biased here, but the big seal of approval as the official java enterprise web framework makes it often imposed by the upper layer of the enterprise than a willing choice by the developers.
Additionally, if the enterprise is licensing a lot of oracle products, it's not surprising if they have a ADF (adf is a jsf implementation and component library) license with jdeveloper, which is trumpeted as the successor of oracle forms.
http://en.wikipedia.org/wiki/Comparison_of_web_application_f... has a big fat 'no, modular event driven' in the 'supports MVC' column.
Once again, Wicket's approach is head and shoulders above every other web framework I've ever used. It's good enough to make me not mind using Java (I dearly wish I could find a framework with the same level of encapsulation in other languages). I urge you to examine it more closely rather than dismissing it based on this one line.
With its clear MVC model, clean HTML and a wicked component module, you can create new applications with reusable components quick and easy. Wicket does use a model inheritance for it’s components, which isn’t great due to a bit steeper learning curve.
The existence of markup files for every component gives you a clear separation of concerns between the controller deciding what to display and the view that specifies how to display. This not only reduces development time but also gives your web designers the confidence to modify the HTML code without worrying about crashing and destroying everything.
What do you mean about Laravel's "bus factor"?
ORM, templating engine, community, it's all there.
I'm well aware of the ups and downs of exposing myself to choice like this but I really want to get myself exposed to some real world practice with some of the top contenders here to make a more objective choice and I also feel that 'what you're comfortable with' is getting too close to unsupported that I should widen my view.
Fortunately this is not a commercial undertaking, nor am I on a tight deadline so I can afford the luxury of thinking this over. If it were for a customer and it would be required tomorrow morning then the story would be wholly different.
Sure, there is no real hack framework yet.. but you could help build one. Plus, all your PHP frameworks will work fine in the meantime.
keep tuned I will write a similar back end post soon.
So Xamarin is Microsoft now? Better tell them, because they don't know it yet. Clojure is a .NET language as well by the way.
First, Xamarin might not be Microsoft, but those languages are developed and controlled (feature wise) by Microsoft, and are best used and more mature with the MS ecosystem. Plus, Xamarin works professionally with MS for quite some time (and a complete acquisition/acqui-hire isn't even that far fetched).
Second, Clojure is not used in .NET by anyone but 10 people. That port is if not abandoned, very near it. And even if it was, most Clojure/JVM software is rendered unsuable on the CLR. For all intends and purposes Clojure is 99.9% a JVM language first (and Clojurescript which is also not .NET).
Xamarin also require that you log in to their IDE, so far so good with them though.
Also, it could be foolhardy to pick just one for the next 10 years. When all you have is a hammer everything looks like a nail.
It might help to try to think of the specific constraints that you envision running into. How can your technology choice help address those concerns and simplify your stack or speed of development, or ability to hire talent? You should easily come up with over a dozen items that you will want to be able to address with your choice of technology.