Judging by how fast technology is evolving nowadays I can't even imagine what is going to happen in 10 years from now... We might not even have the Web... I don't think nowadays you can choose something for the next decade. Maybe for the next 2 years Maximum!
I think the web will be around in some form just about forever. I'm more bullish on the web being around 100 years from now in some recognizable form than I am on quite a few nation states or species of mammal.
Apologies for that oversight, Xamarin was not even mentioned on the C# wiki page and I had totally forgotten about them. That said, I see C# very much as a Microsoft eco-system component even though there have been several re-implementations (such as Mono and DotGNU). Just like I see Go as part of Google and erlang as part of Ericsson.
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).
Keep in mind that Microsoft now require you to login with their latest IDE. The moment this will bite you in the ass depends on what license you use (retail, partner etc). If your a partner you get a rolling 30 day trial that's tied to your MS Partner account and if you've ever used the MS Partner website you know what a complete piece of shit that is.
From the Partner account you assign development rights to a developer which then flicks a switch in your MSDN account, allowing your developer to login to Visual Studio.
Problem is these stars dont always align and your left hanging on the phone to support for hours (this has happened to 2 of our 3 devs now, took 24+ hrs to sort)
The only solution is to switch back to VS2012.
Xamarin also require that you log in to their IDE, so far so good with them though.
Your not using the Partner license, your likely on Bizspark or a bog standard MSDN subscription.
Partners pay the most, then get treated like an ahole.
MS Partner licensing gives you broader usage, through to production servers, Office etc. Pretty sure MSDN is dev or training only.
Plus why pay twice, shit should just work without all the BS.
Part of the MS Partner benefits is a 10 user VS 2013 license, this is something you buy. However it works differently to retail versions which is probably what you have.
This is an exciting read, kind of like Game of Thrones for web frameworks.
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.
The google results should be easily reproducible, I simply used the exact same query string for every framework, "{framework name} framework", going on the assumption here that relatively speaking this will give an idea of how much information there is out there on a given framework. Probably it would have been better to use google trends for this using suitable criteria.
I'm also a bit frustrated with the Yii situation, although I do understand why they're doing it. Yii 2.0 is a total rewrite, and it is technically very impressive. However they have had the disadvantage of not being able to ship until it reaches feature parity with 1.1 which has been a huge undertaking.
The lead developer, Qiang, is literally the second most active developer on github[0], 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[1] would be pretty compelling.
Qiang being so much of the driving force behind Yii is actually a strike against Yii. It would be much better if that load were spread out more, even if that probably would delay a release. SPOFs are not good.
I think most projects have natural leaders, but if Qiang was hit by a bus tomorrow it would be a tragedy but Yii would not die with him. The other core developers, especially Alex and Carsten, are more than capable of picking up the reins, and the project has enough momentum, and has received huge investments of time and energy - it isn't going to go away at this point.
Kohana has died as far as I'm concerned. Such a shame, but it was a great replacement for CodeIgniter back in the day. CakePHP tried to hard to be Rails and messed it up, and I've never forgiven it, and it was horribly slow in my benchmarking.
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).
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)!
Dropwizard is where it's at right now for Java frameworks. It's a superproject that glues together the best pieces out there. Surprised it wasn't on the wikipedia list.
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.
So, that brings javascript frameworks into the consideration. And the author has a paragraph where he just dismisses it as a "terrible hack"...??? I think that is going to seriously hamper the outcome here. It's good that modern web apps leverage the power of the browser and JS frameworks are the way to do that.
That may be what you want right now but the article is about something that will last 10 years. And what constitutes a "standard web app" is definitely shifting and will likely solidify over that time. "Fat client" isn't really the best term for it, because the client code is usually pretty lightweight. I'd say "modern web app".
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.
The "cutting-edge" web frameworks that already exist today are the fat client frameworks you describe (client-side rendering). The web frameworks of the future will have robust server-side and client-side rendering, in my opinion. We're already seeing a little bit of this with Airbnb and Rendr for Backbone, React, and Twitter's web app, but it's not quite there.
> 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.
It's interesting but I don't know about 10 year longevity. I guess because it doesn't score super great in benchmarks, does bytecode hacking / is not standard Java, and all really just to focus on making those initial stages of a project a little easier.
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 think another question is how much you want done on the server (HTML rendering?) and how much on the client. It seems like we're definitely moving towards having the client handle all the UI. I understand this may not be appealing, especially as client side frameworks have even a shorter lifespan than server-side frameworks, but that seems to be the direction. If that's acceptable, for the backend I'd choose Java and Dropwizard (or Jersey+Jetty instead of Dropwizard). Spring Boot also seems nice. I discuss the state of modern Java web development in a non-comprehensive recent blog post[1]. For a more complete discussion of JVM web frameworks, you can take a look at this[2] and this[3].
As far as those two frameworks, it's mostly about retaining brand recognition.
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.
With the OP looking for a framework where he doesn't have to rewrite the code every few years (or more frequently, hello Drupal), major version upgrades matter.
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...
I (naturally) think that the article's summarily dismissing Haskell is unfortunate. It's probably just the result of poor PR on Haskell's part.
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 :).
Many of the brightest programmers I've ever met have struggled to get their heads around Haskell. Enough of them that I don't think it's really a PR issue or a lack of good introductory materials. I'm wiling to take the claims on faith that Haskell's design eliminates a lot of common programming errors but I've been listening to predictions of Haskell's emergence into the mainstream for almost 15 years now and, from where I sit, I have to say it's never going to happen.
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.
> 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 don't think the credit for the java implementation of 'Lambda' should go to Haskell pioneering it and proving it useful. First class functions were present in lots of other languages, most notably the lisp family long before.
Do you recommend any framework for Haskell web development? I really liked toying around with the language, but I hit a brick wall when trying to build something "real" with it - it's hard to find decent guides that made the jump between the basics of writing functions, using recursion, etc and using the language on a full-on application.
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.
I think Haskell underestimates people's intelligence when it comes to things like mind-simulating state change in simple subroutines, and overestimates it when it comes to understanding lazy evaluation and monads. Humans had built useful structures long before they've been capable of rigorous abstract thought. How? By trial and error. Most people find it easier to learn how to catch a ball by practicing rather than by calculating its trajectory. I'm not saying that is always the right approach, but it does come more naturally to the human brain.
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.
Pass in requests. Get responses back. Same input, same output, except for potentially dirtied DB hits. This is somewhat of a good fit for a functional language program that just handles request after request. For API's Haskell might be a great fit.
For server-side rendering of fat web clients, I don't see any way around node.js and my resentment of javascript without doing some impressive design of the client to be able to reinitialize itself from a JSON that pops out of the client state in the host language. It's possible, but I'm too busy with Kivy to mess with web development atm.
I have little to add, but I'd make a similar case for Scala. If you're tied to the JVM or existing code, or don't want to make the leap to laziness/purity/immutability for everything from day 1, Scala can be a smoother way to learn these new concepts (which will ultimately make you more productive whichever language you use).
(And if you're going to use Play, Scala is very much the best way to do so)
Out of interest, what would you say are the kinds of bugs that using something like Haskell helps you avoid? I've had a look at Haskell before and while all the individual parts looked reasonable I struggled to understand both what an application would look like at a high level and what the inherent advantages are (not saying there aren't any - just that they didn't jump out to me).
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!
The problem with Haskell is its syntax. Too many arbitrary and traditionless things to memorize. It's curious that the Haskell developers try to one-up the rest of the language space in nearly every other space, but choose such a weird and unhelpful syntax.
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.
> The problem with Haskell is its syntax. Too many arbitrary and traditionless things to memorize. It's curious that the Haskell developers try to one-up the rest of the language space in nearly every other space, but choose such a weird and unhelpful syntax.
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.
Yeah, but if the monads were the only problem it would be ok (for me at least). But I'm asked to learn monads while also learning this weird syntax. I'm asked to learn something I don't understand in a syntax I don't understand. It's a bit too much. Like a math lecture in which, aside from the new concepts, the lecturer has decided to replace the traditional symbols (+,-, etc) with his new and equally arbitrary ones (¤, @). Except, of course, that Haskell's syntax is often more arbitrary than its competitors.
Well, I basically went "fuck this" after looking at Haskell for a while, but there's surfaced some links in the comments (thanks, akavel) and they provide some examples:
>>=, >>, >, <$>, <$, <>, $, ., !!, !, <|>, :, ::, \, @, ~, -<, <-, =>, ->
Taken together the syntax makes no effort whatsoever to be self-explanatory. I could handle it if it was the only programming language I would ever use, but in the polyglot world we live in and with my leaky bucket of a long-term memory this is not good enough.
I see what you mean. Most of these are custom operators which happen to be in the stdlib, but I wouldn't say :: or ->, for instance, should feel particularly mysterious with a bit of practice.
There is not really any operator overloading going on. You can implement Monoid for your data structure, but as long as you follow the laws... well, you are implementing operations in the correct way, there is no abuse there, nothing that's surprising and going to bite whoever is reading your code.
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.
Yeah, have you seen what the Scalaz guys are doing? The operators aren't even ASCII! Apparently, there's something about monads that absolutely requires weird symbols.
For me at least, that means exactly what you mention in your other reply below. Even more than weird operators themselves, but the problem for me is that they're hard to vocalize in my mind when reading. In other words, this:
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: -> => <- -< >>= >>
After fairly long time playing with Haskell, I find it quite beautiful and pleasure to use, but only for theory/book-ish use cases. As for real world usage - it is quite ugly and cumbersome, e.g. when you need some error handling and multiple monads using (with transformers), etc...
Another quick way to measure this - compare that beautiful pseudo quick sort to real quick sort (e.g. using Array.ST)...
I have to say that I agree with you. In principle, I find the notion of an effect system extremely powerful, both for safety and optimization, but Haskell's way of intermingling effects using monadic towers is terribly awkward and cumbersome, not to mention that it comes with a mental cost.
I'm all for trying something unfamiliar, and I could even argue for Haskell that way, but from a different angle.
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
Whether you adopt this through Haskell, Clojure, scala or even Bloom e.a. is fairly inconsequential.
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.
Living in Romania right now, but I'll ping you when I'm back in NL (I go there at least once every few weeks), Clojure seems to be the most approachable from the languages you list.
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).
This may be my biases speaking but I'd say Scala is a more approachable option than Clojure (and more popular, and has a first-class web framework in Play). It keeps more of the traditional OO style and syntax - you can use scalaz and write scala that looks like Haskell, but you can also write code that corresponds line-by-line to java, whereas with Clojure you're forced to make a more immediate leap to the lisp-style syntax, immediately stop using inheritance, and so on.
That's a major appeal of Clojure, the Lisp (not Lisp-style) syntax, the functional paradigm (and the idioms are great). I really don't want to write code that corresponds line-by-line to Java. If I wanted to do that, I'd just write Java. However, Java interop with Clojure is straightforward. Furthermore, Clojure allows one to solve problems with an "orientation" toward objects, but as one learns to write Clojure well, the language guides one toward sublime and elegant functional solutions. An important thing about Clojure, however, is that it is not tied to the JVM; The original and most well-known implementation is for the JVM, but not only is there also Clojurescript, there are implementations that compile to CLR bytecode, Python, Ruby, and Actionscript. And with EDN, the extensible data notation, not only can you have your front-end and back-end codebases entirely in Clojure, you can transfer and store your data as Clojure too. I know not everyone has the same aesthetic tastes as I do, but I do like to think that there is something beautiful about this.
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.
> I really don't want to write code that corresponds line-by-line to Java. If I wanted to do that, I'd just write Java.
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)
Persistent structures are almost always O log N (because they have to be trees). You can fix your branch out for better performance at the cost of more wasted space. You will never be as fast as an array.
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).
At n=32 the performance costs are as negligible as dynamic typing once was (even less I'd argue.) As far as I can tell that very much puts us at the point in time where mutable state is usually a premature optimization.
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.
n=32 leads can lead to lots of sparseness, memory pressure, bad locality (given sparseness); its not going to fly easily as the default. The shared memory aspect is even a bigger hurdle: people share memory for a reason, its not very often accidental. FRP is hardly the answer, but I work on a competing paradigm so mark me as biased.
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.
I never meant to imply FP is already the right choice for big data (which is what I think you refer to by 'systems people') or high performance computing.
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.
It actually involves versioned data structures (similar, but a but more complicated than persistent data structures, and outwardly they appear mutable):
I already had a feeling we were essentially arguing the same thing...
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...
I would, but it doesn't necessarily have to happen with persistent data structures, and I would also argue that they aren't really sufficient (the history has to be useful, after all). They are convenient, and I'm using trees in my current implementation.
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 ;)
I also think "it shines in finance" is a little weird. It's used in finance because it's an industry with a premium on correctness and a sympathy for math, but I don't think it's generally better suited to solving those problems than to solving other problems. If I had to point to one area that Haskell is clearly better at than "mainstream" languages it would probably be tree manipulation - and as a consequence compilers - due to structural pattern matching (for small stuff) and evaluation strategies (for larger and more abstract stuff).
I love Haskell because I don't have to depend on my working memory. It's so nice to have the compiler tell me everywhere some type I've changed is used, or places I've forgotten to consider possible values.
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.
jaquesm's requirements, per the linked article, are that "Sessions, authentication, routing, internationalization, MVC, caching, mobile, templating, ORM and so on should preferably all be part of the deal, so batteries included please". GP's comment was presumably made with that context in mind. Arguing for Express on the grounds that the word 'framework' doesn't imply those those things doesn't invalidate his requirements - definitions aside, Express clearly doesn't satisfy them.
Looking from the top of todays technology some can observe subtle transition from desktop to mobile to wearable electronics (intelligent clothes). From this point of view Web becomes obsolete. Everyone prefers native apps on mobiles. Honestly I can't see bright future for Web in wearable electronics world now. I'm almost 100% sure there won't be HTML inside.
Web was designed with desktop in mind. The further form desktop the less Web. The future is not on desktop. C forever? Low memory footprint and small executables are still there.
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!
To add to that: I also think that these days you will need to have some sort of JS framework on top of your server stack. Angular and Ember are bot nice to work with, React would be something I'd look into next time.
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.
To me, the most interesting thing about this post is that there is no clear answer. We're mired in, frankly, a lot of junk. There's no winner because nothing is really very good.
If you arbitrarily reject everything unfamiliar then filter the remainder for stability you wind up with unremarkable stuff that will get the job done. There are better ways to write web apps but you're not going to find them following the process outlined in the post.
Boring unremarkable stuff that gets the job done sounds great to me. Sexy, new, hot, flashy are exactly what I'm trying to avoid getting sucked in to (though, believe me I can feel the draw).
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.
I was really drawn to the title of your post because that's just what I have done--well, over the last few months--and I went with Clojure. I want to absolutely focus now and I can see the momentum is gonna take me for at least the next 10 years. I never rode the Rails train and after becoming a functional programming believer I'm kinda glad I didn't in retrospect, but I had always been envious of people who did make that decision to become good at a stack. I agree with you that the error exploding in Clojure is not nice, but to me it makes up for it in being on top of both Java and JavaScript (having been a JS dev previously, but being entirely tired of the convulsion of frameworks and build tools and module systems.)
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.
Clojure doesn't really have a 'framework', and I like it that it's really composable in that sense. But things like Ring and Compojure are lightweight no-brainers, much like Rails is a heavyweight no-brainer for Ruby. What I want to say is, unlike JavaScript, after having picked Clojure as the language, the choice of everything else is mostly always a no-brainer (e.g. leiningen, core.async, enlive/hiccup, maybe Om soon.) And that really pleases my choice-avert brain.
Most welcome! I wrote that wall of text more in wanting to get my reasons out of my head, like you did, than in trying to wrestle you over to my side of the field. But if you want to be really tempted now, reconsider, like someone else commented here, the importance of concurrency and persistent data structures for web development going forward. Even for a one-man team (such as I plan to be, and actually one of my side-projects in Clojure has to do with language learning and SRS, would love to keep up with what you end up doing.) It means you can handle traffic spikes and trace errors as a one-man operation much more easily than if you had stateful bugs and failures to deal with.
I think this is a good assessment. I'm a little more bearish, though I love the language. I rode the Rails train in the past and recently embarked on a real web project with Compojure.
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.
Your decision process isn't the same one I would have gone through* but it's rational. I was responding to the conclusion that "nothing out there is very good".
* 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.
I've used Om and it works but the cljs ecosystem only really started up in December when Om came out and everybody discovered React. I don't use/recommend Clojurescript outside a Clojure shop because frontend skillset+clojure is extremely rare and you do have to do everything yourself.
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.
Interesting views on Python - I decided to start using it for personal projects after trying Go for a bit. Initially I hated the significant whitespace, and indeed many other things, but I stuck with it and I find it all rather elegant - I certainly haven't noticed any huge problems with dependencies but I've probably stuck with pretty mainstream ones (e.g. Requests).
I now rather like significant whitespace and often find myself considering that my ideal language would probably be half way between Python and Lisp.
I had enough syntax errors appearing after a copy and paste that ended up with difficult to spot unaligned code that I decided to use Python only for little scripts and when I'm forced to use it and nothing else would do. The problem with Python is that editors don't have hints to autoalign the code for us. Same problem with templating languages like HAML and Slim which, oh the irony, were born for Rails. Nevertheless many people like Python and it's growing strong (maybe stronger as system/desktop language than for the web) so those problems of mine are not as big as I feel they are. But how do you survive to them or make them not happen? I'm sincerely interested.
I've found the same as you - pasting code from anywhere to a Python application comes with a risk. This risk is however not too different from other languages where you wouldn't want mixed spaces and tabs in your code either. In my opinion, Python just enforces good coding style. You might have been as the error messages I get is rather verbose telling me the linenumber with an exception "IndentationError: unexpected indent" or "IndentationError: unindent does not match any outer indentation level". The first is for wrong identation level and the second is for mixed tabs and spaces.
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 like significant whitespace too, but it is not without its drawbacks (eg, sometimes you need to wrap things in parentheses when you want a linebreak). Playing with Rust reminded me that you can do very nice things with a curly-braced syntax as well.
I wonder if hylang (hylang.org) might suit your tastes. Lisp syntax, macros and full access to the Python ecosystem as it compiles to the Python AST I believe. The bad puns and cartoons come for free :)
I wonder if django and hy play well together.
Not sure what kind of applications he expects to build, but picking a "Web" Framework for the next decade should probably also include a Javascript framework that allows more app-y websites. Clients are already falling for those.
I'm very curious how the Google searches were done. I get 2.5 million results for "ruby sinatra" on Google vs. 5160 in the article. The numbers I get for "ruby rails" are similarly much higher. So clearly he must be searching for something else. Even "ruby sinatra framework" gets 388,000 for me.
Choosing a framework/language for the next ten years sounds like a fools errand to me. Both because what "best" is changes much, much more rapidly than that - and because I'd pick different frameworks depending on the team and project.
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.
Indeed. Picking a framework/language for the next ten years at this particular time feels a bit like picking the best horse and cart just as the automobile is getting popular.
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.
I don't know what "MVC" means to this guy, but Wicket's approach is much, much better than any other framework I've used; you build your web pages out of objects, your component hierarchies out of object hierarchies, with actual encapsulation, reusability and composability. If that's not MVC then I don't want to be MVC.
Well, I guess the question then becomes: what does MVC mean to that Wikipedia editor? And what is it you want to be able to do that you're trying to figure out by reading that 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.
Ok, point taken, I'll add Wicket back in. This thread is a goldmine of good information so far, I spent a full 2 days researching all this and it would have been absolutely impossible to evaluate all framework/language combos by writing a test app so I had to take some shortcuts. Apparently that caused a good framework to be thrown under the bus for all the wrong reasons so I'll revive it and we'll see how it does in the real world. Thank you!
Haven't used Wicket, but this is what a good web framework comparison had to say about it[1]:
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.
From users if most other modern mvc frameworks rails, django, asp mvc, spring. Mvc. I would say wicked is such a different paradigm and it's such a programmer centric view of web dev. Most websites aren't a set of components, unless you constantly make admin screens. Most of the major sites I've worked on have visual designers and they aren't so cookie cutter or recently they are single page apps that are more soa and rest oriented
Saying you are on your own figuring things out with Erlang is false. The community on the erlang mailing list and IRC channel is extremely helpful, especially for people starting out.
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.
My colleagues and I went through more or less this exercise in 2005 and ended up with Python/Django. I know everybody tends to become a crusader for their development stack, but I think this was a fantastic decision, either by luck or judgement.
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.
I agree and we also went through a similar process at work (although a few years later than you), couldn't be happier with Python and Django.
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.
Might as well go with the one which sparked the wave which inspired most of these.
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.
For all the mentions of MVC in your post, you should probably realize that Rails isn't really MVC. Some of the new JS frameworks are actually MVC, but Rails it is not. (Rails is more Model2: http://en.wikipedia.org/wiki/Model2 than true MVC).
i think only people who still code RoR tend to see it as the center of the universe.
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.
Aha, understood... yeah, I think Laravel is very similar to Rails in that respect. Would you not use Rails because DHH is at the wheel? They both have big active contributor communities.
227 comments
[ 4.9 ms ] story [ 268 ms ] thread[1] http://leafo.net/lapis
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.
So you are absolutely right. Will drop it from the list to try and will update the article.
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.
The lead developer, Qiang, is literally the second most active developer on github[0], 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[1] would be pretty compelling.
0. https://gist.github.com/paulmillr/2657075 1. http://openresty.org/
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)!
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.
So, that brings javascript frameworks into the consideration. And the author has a paragraph where he just dismisses it as a "terrible hack"...??? I think that is going to seriously hamper the outcome here. It's good that modern web apps leverage the power of the browser and JS frameworks are the way to do that.
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.
https://dropwizard.github.io/dropwizard/manual/views.html
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".
[1] http://www.techempower.com/benchmarks/#section=data-r9&hw=pe...
[1]: http://blog.paralleluniverse.co/2014/05/15/modern-java-pt3/
[2]: http://zeroturnaround.com/rebellabs/the-curious-coders-java-...
[3]: https://www.youtube.com/watch?v=ygW8fJVlDxQ
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...
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 :).
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.
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.
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.
For server-side rendering of fat web clients, I don't see any way around node.js and my resentment of javascript without doing some impressive design of the client to be able to reinitialize itself from a JSON that pops out of the client state in the host language. It's possible, but I'm too busy with Kivy to mess with web development atm.
Huh, I have never thought about it like that. Thanks.
(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!
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.
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.
http://stackoverflow.com/questions/7746894/are-there-pronoun...
http://www.haskell.org/haskellwiki/Pronunciation
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: -> => <- -< >>= >>
Another quick way to measure this - compare that beautiful pseudo quick sort to real quick sort (e.g. using Array.ST)...
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:
Whether you adopt this through Haskell, Clojure, scala or even Bloom e.a. is fairly inconsequential.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.
http://research.microsoft.com/pubs/211297/managedtime.pdf
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 ;)
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.
Express [1] has been the dominant framework for Node.js since 2009-2010. What frameworks are you talking about?
[1] https://github.com/visionmedia/express
But I get what you are saying, Express was among the most stable+popular pieces of js done in the last years.
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.
Web was designed with desktop in mind. The further form desktop the less Web. The future is not on desktop. C forever? Low memory footprint and small executables are still there.
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.
http://www.google.com/trends/explore#q=Laravel%2C%20symfony%...
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.
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.
Clojure doesn't really have a 'framework', and I like it that it's really composable in that sense. But things like Ring and Compojure are lightweight no-brainers, much like Rails is a heavyweight no-brainer for Ruby. What I want to say is, unlike JavaScript, after having picked Clojure as the language, the choice of everything else is mostly always a no-brainer (e.g. leiningen, core.async, enlive/hiccup, maybe Om soon.) And that really pleases my choice-avert brain.
Thank you!
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.
I now rather like significant whitespace and often find myself considering that my ideal language would probably be half way between Python and Lisp.
I'm very happy with PyCharm.
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.
You might like F# then. It's concise like Python and has all the power of functional programming.
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.
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.
[1]: http://zeroturnaround.com/rebellabs/the-curious-coders-java-...
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.
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.
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.
What do you mean about Laravel's "bus factor"?