My guess will be he will eventually arrive at Ruby on Rails or Laravel.
Choosing a Web Framework/Language Combo for the Next Decade
121–130 of 228 posts
Re: Choosing a Web Framework/Language Combo for the Next Decade
#122Coming from years of .NET, a year spent with Grails and now 4 months into 'Ruby-land'. If there was a way to vote, I'd vote Rails/Ruby just Rails/Ruby isn't cool anymore, everyone moved onto NodeJS/Scala or wherever. I'm only going by experience, and I haven't been deeply involved yet. 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…
What is 'cool' is not a factor. Long term vision and solid engineering is far more important to me than sexy or cool. It is funny how my needs probably align more with big enterprise than with small start-ups, because I'm just one guy and do not have the agility (for want of a better word) to follow ever new hot thing. Big enterprise is just like that but for reasons of inertia.
Re: Choosing a Web Framework/Language Combo for the Next Decade
#123Earlier quoted context omitted.
I wouldnt consider Express as a framework. 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.
> Express is definetly not a framework,it doesnt do anything much. Consider that your definition of a framework may be different from others.
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.
Re: Choosing a Web Framework/Language Combo for the Next Decade
#124Earlier quoted context omitted.
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 beat…
> 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 in…
> The syntax of Haskell is not that big.
Neither is APL's syntax.
Too much operator overloading is just a bad idea.
Re: Choosing a Web Framework/Language Combo for the Next Decade
#125"I still haven’t forgiven Microsoft for their countless misdeeds so Asp/C#/F# are all right out." 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.
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 devel…
Tools should work offline, period. Imagine having to call DeWalt or Bosch every time you want to use your drill.
Re: Choosing a Web Framework/Language Combo for the Next Decade
#126I've been in a quest for my favorite web server technology as well for the last 2 years, so this definitely rings a bell. I pretty much agree with evertyhing the author said, except for one : 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 whit…
I had the same knee jerk and even a bit further: ruby seems to embrace the "go fast and break things" philosophy much more than python.
Re: Choosing a Web Framework/Language Combo for the Next Decade
#127Python all the way.
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: Choosing a Web Framework/Language Combo for the Next Decade
#128Earlier quoted context omitted.
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: * stora…
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…
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.
Re: Choosing a Web Framework/Language Combo for the Next Decade
#129I (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…
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: * stora…
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).
Re: Choosing a Web Framework/Language Combo for the Next Decade
#130I've been in a quest for my favorite web server technology as well for the last 2 years, so this definitely rings a bell. I pretty much agree with evertyhing the author said, except for one : 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 whit…
I had the same knee jerk and even a bit further: ruby seems to embrace the "go fast and break things" philosophy much more than python.
That is quite possibly true but I've never even written a line in ruby so I'm unfamiliar with this. Thanks for the warning!