Things that Ruby on Rails people tell you(jameschambers.com) |
Things that Ruby on Rails people tell you(jameschambers.com) |
There's a large and growing number of useful, productive high-level languages, frameworks, databases, webservers, tooling, etc. The thing they all have in common is they're open source, they can be used on a variety of POSIX-compatible operating systems and distros, they're often used together, share underlying libraries, and help build off each other's advances.
OTOH, .NET is stuck in the walled garden it built around itself, with its fanboys trying to scream out over the walls at the rest of the world bustling by, demanding we pay them more attention.
Well sorry, no. You guys enjoy that garden though; you keep telling us how nice it is!
ASP MVC may be pretty rad, but I personally hate C# (Ruby is an amazingly better language) and I don't feel like buying into the Microsoft ecosystem. It's not one that shares my values and culture, and from the outside it seems to be losing momentum and relevance. I'm not aware of many developers who would decide to adopt Rails over .NET due to these "lies" - the choice is first cultural, then technical.
I'm not suggesting that .NET shops are worse places to work (although that has been my personal experience) but there's something about the MS ecosystem that puts .NET shops at risk of turning into overly-stuffy/corporate, aesthetically-unpleasing shops. There are exceptions of course (FogCreek/StackOverflow) but they don't appear to be the norm.
Why? I've spent the best part of the last 5 years programming python and JavaScript. Recently however a new project has shown up where I might have to use C# and I'm really excited. From what I've seen and based on the little tests I've done, C# looks like an awesome language. Striking a prefect balance between the being too dynamic and free from and being too rigid. What is it about C# that you "hate"?
I won't argue about Ruby being a better language(I like C# and Ruby and I am not inclined to pick a winner). But what version of C# have you used? If you had a brush with earlier versions of C#, I suggest you http://www.manning.com/skeet2/excerpt_contents.html read the first chapter.
It's not about just the templates(I have personally never used one). Rails has useful code generation(scaffold, controller, model, migration). I would rather not type what I can generate. This isn't something you can solve with project templates.
How is this a myth that you can bootstrap a project faster using Rails? Here, take this:
http://guides.rubyonrails.org/getting_started.html#creating-...
Show me how I do the "10 minutes blog" in your framework of choice.
> Myth 2: It's Easier to Manage Packages Rails
Great. Good on them for realizing adding assemblies using Visual Studio dialogs is a fucked up way to manage dependencies.
> Myth 3: It's Better to Develop with RoR Because it's Open Source
It's better to develop with RoR because it's open source, and when something breaks or I need to augment, I don't need to wait for my overlords.
> If your personal opinion or corporate agenda is that it's "better" to develop on OSS solutions, then good on you.
It's neither. How hard is it to understand that black boxes are a pain?
> Myth 4: I Get More Options for View Engines/I'm not Limited by Microsoft View Engines
> First of all...what limitations? The Razor view engine â the default for MVC â is likely one of the best view engines around right now.
And how is razor one of the best? http://www.asp.net/mvc/tutorials/views/introduction-to-razor... This looks like another run of the mill template engine.
> Maturity isn't dictated by age, and what is really important is how comfortable you are with your tools.
Maturity of a framework is independent of how comfortable you are with it.
> but it doesn't mean you can dismiss VS for what it is
Umm. RoR isn't an IDE. What has RoR's maturity got to do with VS? If you want to talk about tooling, please do, but how does RoR's tooling the same as RoR maturity?
> You're likely to find just as many bad questions, answers, arguments and features in any language, if you look hard enough.
Are you seriously positing all languages have same amount of activity and features?
> I know exactly where my models go. And my views. And helpers. And filters.
And I am least interested in learning a new project layout every time I work on a different project. You know your project layout - I don't and I am not interested in learning it. The point of a standardized layout is "it's more clear where things go".
I agree it's not just about the templates. We have support for scaffolding (controllers, views, migrations and more). Our models are POCOs, so they are trivial to write, and we have great helpers for that.
Agreed fully on #2. About time.
#3 - I haven't had to wait for anything. Most parts that I don't like I can and have just built my own parts for. The MVC Framework (and ASP.NET runtime) are pretty much pluggable up and down the stack.
As for the maturity piece, I think you're taking the VS comments out of context. I'm not saying MVC is an IDE and I'm not saying RoR is or isn't. My comments on this were from the segway from "tools" in the previous paragraph.
> Are you seriously positing all languages have same amount of activity and features?
No, I'm simply saying you can find bad features in any language. :o)
Again, I'm not saying "You have to drop what you're doing and try MS's implementation of MVC", I'm just saying, "Don't knock a horse before you try reading it."
Or however that goes.
Thanks again, great comments.
The amount of sheer idiocy in this thread is really surprising considering the website.
It's like people see "Micro$0ft", foam at the mouth, and start rambling on about FOSS. Without even using MVC3 for anything substantial.
To compare Razor with any other view engine and say it's more or less the same is SO IGNORANT it makes my blood boil; especially since people are upvoting those same stupid remarks.
How can you compare Razor's elegant syntax with Rails really smelly view engine:
@foreach (var person in Model.Friends)
{
<p>@person.Name</p>
}> For the record, the MVC Framework is [also] completely open source... [thus] This is not a differentiator for Rails.
I am not going to give up OS independence, on the development or server side.
I am not going to give up editor/IDE independence.
Microsoft is not seen as ahead of the curve with respect to web technologies, and this is reflected in its developer community.
Until these problems are fixed, the MS stack can pretty much go kick rocks.
"Myth 1: It's Easier to Bootstrap a Project In Rails"
Maybe, but still I doubt its cross platform (without headaches) - can you bootstrap MVC on Linux or Mac. This would mean you're married to the Windows Env (not a bad thing necessarly if thats what you decide you want).
"Myth 3: It's Better to Develop with RoR Because it's Open Source"
You say the complete .Net stack is open source? If so this really surprises me, considering microsofts rep, so I'd ask for links and is the C# compiler open source?
Finally, where's the advantage? ( I know you say your not trying to say this ) Why should people use something new unless there are reasons for it being not just as good but better at such and such? This whole post was about how MVC is just as good as Rails, which probably is true, but if you're a good dev and know your tools then Symfony2 or Django is probably just as good as well. The only reason to switch is when people start showing exceptionally new capabilities that make the devs life easier by trying out the new thing. Thats what rails did back in the day.
Rails, being built upon a foundation of open source, instills a strong open source ethos into its community. The amount of free, permissively-licensed open source libraries available for use with Rails is staggering. Rails' entire ecosystem, down to the preferred OS kernel, is open source and free. The buy-in to work with Rails is exactly $0. This produces a community who almost rabidly shares code and knowledge as permissively as possible.
Compare this to ASP.NET, where, until recently, there was a buy-in for everything, and you had to pony up a fair bit of cash just to play in the sandbox. In the ASP.NET world, everyone wants their $15 or $50 or $500 for every little bit of code or whatnot. The entire ecosystem feels like it's composed of people with an "enterprise" mindset who expect that everything should be paid for. This massively hampers growth of the technology and its community. It is directly antithetical to the open source ideals that have catapulted Rails to where it is today.
Any time I had tried searching for solutions to .NET problems, they were behind paywalls, behind license restrictions, or otherwise hidden away. When I search for solutions to Rails problems, they're on StackOverflow and Github. Where is the GitHub equivalent of ASP.NET MVC projects? The OP argues that the lack of SO questions is a good thing. I'd suggest that instead, perhaps it's symptomatic of the community's attitude towards distribution of knowledge.
Like I said, the last time I worked with ASP.NET was a couple of years ago, so perhaps this has changed by now, but if it has, it'd be a tectonic shift, and I'm rather doubtful that an entire ecosystem can change like that in such a relatively short amount of time.
Here is my pet peeve.
MVC is a well-understood idea in web development that traces its inspiration back to Smalltalk in the 70s. There are many MVC frameworks in many languages, which differ in various details. All of which, to avoid confusion, called themselves things other than MVC. Examples include Catalyst, Django, Ruby on Rails, Struts, CodeIgniter and many, many more. See http://en.wikipedia.org/wiki/Comparison_of_web_application_f... for more.
Why did Microsoft have the gall to try to confuse everyone by calling their product MVC? Yes, you've got models, views and controllers. So does everyone else. Yours don't work exactly like anyone else's. (Everyone else's work differently from each others as well.) Yours wasn't even the first one available for .NET. Get a less confusing name.
I don't see the issue with calling it "ASP.NET MVC". The Visual Basic event-driven style of programming is fundamentally different from MVC. Calling it MVC provides context.
Would you have preferred they come up with a "cute" name that doesn't explain what it is?
I was a RoR dev before and loved it, now I just hate .NET at work because of it's OS (Windows) and tools (VS, NuGet, MSBuild...). We don't use MVC though.
I don't know about NuGet or MSBuild, but back then when I used VS for misc tasks, it used to run circles around Eclipse or Netbeans.
Rails really doesn't do "IDE" well, but that's because its entire toolchain is built to be used independently of an IDE.
(Edit: There's Rubymine, which is actually pretty decent, but I usually just stick with Sublime and my console because it ends up being faster anyhow)
I'm a former C#/ASP.net programmer. This guy is delusional. Even when MS makes code available, that doesn't really mean it's useful in any practical sense. If you're targeting ASP.net, there is a 99.99% chance you're targeting Windows servers and only Windows servers. Does that sound like "open source"?
http://opensource.org/licenses/category
So yes, I'd say that is sounds like open source, using a very permissive license. People can (and do) deploy ASP.NET MVC apps using OSes other that Windows. The vast majority choose to deploy on Windows servers, but that does not make the source any less open.
I don't mean to come across as a Microsoft apologist; I've worked with .NET, Ruby, and Java...and find them all acceptable ways to get things done quickly, once you know what you're doing. I just feel like if we all spent less time navel gazing about whose language/tech stack is the most awesome, and spent that time creating things instead, we'd all be a lot better off.
I want to be fair here – there's more than one camp in the Rails world
To be fair, quit with the linkbaity titles that tar everyone with the same brush. I could find some developers to spout off some garbage and write "BS That Dumb .Net Developers Actually Believe In" except I wouldn't, because it's ridiculous, unfair, and antagonistic. It's as simple as adding the word "some", really.
You like asp.NET? Good on you. It probably has interesting concepts.
I have a feeling that a large percentage of the people choosing a framework base their choice on two main characteristics:
1. Language they wish to use/learn(C#, Java, Ruby, PHP, Python, etc)
2. Framework they know/heard of (ASP.net, RoR, Flask, Django, CakePHP, Symfony, etc.)
And there's nothing wrong with that.
For examples see here: https://www.ruby-toolbox.com/ , nothing like this really exists in the .net ecosystem, especially something akin to active record plugins, so you have to roll your own stuff a lot of the time when you could just use a plugin in rails.
Also, it seems like a lot of the useful .net stuff like mvc, nuget, entity framework are kind of clones of stuff that exist in the rails ecosystem already, so you are always going to be a bit behind the curve.
To me, "bootstrapping a project" includes source control and hosting. I absolutely adore the Rails/Heroku/GitHub trifecta.
I don't really know how this compares to what .NET MVC and VS can provide. Do they make it equally easy to get something live online with collaborators? Going to Project -> New is one thing, but only a small step in getting a project started.
(I don't know about NuGet and ASP.NET MVC; I only have Mono and MonoDevelop on my Mac because occasionally I modify C# plugins for a Windows app and I like being able to see compiler errors without having to install it on a Windows machine.)
Yay for stereotyping free software enthusiasts as basement-dwelling pre-pubescents.
Other than that, the article is pretty light on insightful content.
I particularly dislike the way it tends to result in code that is littered with leaky database abstractions where schema details tends to find its way into peoples controllers and views because it encourages people to call AR methods on model objects directly instead of even trying to encapsulate.
Ruby is my favorite language, but Active Record is one of the things I hold greatly against Rails, not only for AR itself, but for the inspiration it provided to many other Ruby ORM's, that while they may improve on various aspects still to a large extent also end up encouraging leaking implementation details for your models all over the place.
It'd be great if even 10% of the people using (and writing, it would seem, given that e.g. the Ruby ORM "Data Mapper" doesn't implement the Data Mapper pattern at all) these ORM's actually read the relevant chapters of EAA and pondered a bit on how it related to their applications.
I wasn't aware Fowler is a required reading for anything(or I would say even beneficial) for _anything_, let alone AR.
> I particularly dislike the way it tends to result in code that is littered with leaky database abstractions where schema details tends to find its way into peoples controllers and views
Your whole rant doesn't have anything concrete I can respond to. How does schema details creep into controllers and views?
> because it encourages people to call AR methods on model objects directly instead of even trying to encapsulate.
Ummm. What? I don't understand. Are you proposing person.save is wrong and save should be abstracted?
> Ruby is my favorite language, but Active Record is one of the things I hold greatly against Rails, not only for AR itself, but for the inspiration it provided to many other Ruby ORM's, that while they may improve on various aspects still to a large extent also end up encouraging leaking implementation details for your models all over the place.
More rant. Still nothing concrete. AR maps the whole table, and if you are using AR, you should know that. If you need to map parts of the table, or compose parts from various tables as one object, use something else. Not every tool has to solve every problem.
But what isn't? Plenty of Rails is sitting atop JRuby and friends. Nothing is immune.
Don't get me wrong. I'm not a massive supporter of .NET (outside of XNA) by any means. My point is if legal issues are what you're looking for; you'll find them; everywhere. It's just all so ubiquitous it's simply not cause for concern.
Anything can be made to be seen as illegal from a certain perspective. Everyone is suing everyone else. Does that mean we all pack it up and go home?
Unless your Ruby app is leveraging JRuby's integration with Java... you can just take your Ruby app, fire it up on Rubinius or MRI, and you're no worse for wear.
I've yet to see an IDE that can beat the productivity of that, or even get close.
Then I suggestion you read Enterprise Application Architecture. It's a great book for the way it formalises a number of very common patterns in a very concise way.
It is also directly or indirectly the inspiration for a large number of recent ORM's and worth reading for that reason alone. Active Record the ORM is a direct implementation of Active Record the pattern as described in EAR for example.
Unfortunately most picked off the easiest ORM pattern presented and stopped there, without alerting their users to all the caveats of the pattern.
> Your whole rant doesn't have anything concrete I can respond to. How does schema details creep into controllers and views?
Because the ORM spews methods all over the models that expose schema details whether or not they are relevant to the domain model.
> Ummm. What? I don't understand. Are you proposing person.save is wrong and save should be abstracted?
No, I am suggesting that, e.g. Person.where("some random SQL") is horrible. Yet it is hard enough to work with AR without resorting to crap like this, that you see stuff like that all over most code that uses AR. At least all the code I've looked at.
> More rant. Still nothing concrete. AR maps the whole table, and if you are using AR, you should know that. If you need to map parts of the table, or compose parts from various tables as one object, use something else. Not every tool has to solve every problem.
The problem is not what AR does, it is how it does it, and the way it's been packaged with Rails and given legitimacy that way despite being an exceedingly poor solution for anything but tiny projects because of a) the choice of the Active Record pattern, b) the poor level of abstraction.
A large chunk of developers are terribly excited about AR because it's better than what they're used to, and settle for it because it's part of Rails instead of looking for alternatives.
I have a general dislike for Fowler church of patterns. That is not to say I haven't gone through what is listed on his site. I didn't find it intriguing enough. I derive 100 times more value reading K&R than GoF. There is limited time and large number of books - one has to be picky.
> No, I am suggesting that, e.g. Person.where("some random SQL") is horrible.
Person.where("last_name = ?", last_name) is the most concise way to issue that query. Abstracting last_name so that if the field name changes, the query still is relevant is overkill. If you are so insistent, it isn't really hard to do a base model class which inherits from ActiveRecord::Base and do the mapper yourself.
> exceedingly poor solution for anything but tiny projects
github, twitter, heroku et al would like to disagree. Person.where("last_name = ?", last_name) makes it unsuitable for large projects? Personally, I have seen 1% cases where a migration changes column names, and when it does, re-factoring the code base for column name changes will take less than 2 minutes.
> A large chunk of developers are terribly excited about AR because it's better than what they're used to, and settle for it because it's part of Rails instead of looking for alternatives.
I don't understand. You are quoting it as if AR is the new kid on the block. It has been long enough to call it time tested. If Person.where("last_name = ?", last_name) is not abstract enough and makes it unsuitable for your projects(still the only concrete complaint from you), look for alternatives. I am not a fan of InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonPainter and I would stick with Person.where("last_name = ?", last_name) and will fork AR if someone has a bright idea of adding layers of abstractions over a simple query.
Very different comparison to the patterns Fowler presented. The patterns GoF presented were very basic, and were interesting then with languages like C++ when people were still fucking up many of the basic patterns. The number of horribly broken C++ Singleton implementations I've seen, for example, beggars belief. Today that's less of an issue.
The patterns Fowler presents are, as the title says, about architecture not low level implementation, and they are patterns you will tend to find in pretty much any large software project today yet that people still manage to fuck up royally, which is the reason the patterns matter.
Patters are nothing but recipes of best practice. They're not meant to be "intriguing" once you understand the tradeoffs. They're meant to become boring and bland and trivial once people are comfortable with them and their implementation is well understood. They're also meant to give people a shared vocabulary for talking about it. That's the entire point.
Most of the patterns in EAR are nowhere that for most people, judging by the code I see regularly and judging by how there's still this cargo cult around the AR pattern by people who in many cases have not even heard about the other ORM patterns presented by Fowler, much less other alternatives.
> There is limited time and large number of books - one has to be picky.
If I were to pick any book on software development from the last 10-15 years I'd like everyone to read, it'd be Enterprise Software Architecture, for a simple reason: I still see people using those patterns every day, yet screwing them up in horrible ways. Maybe you don't need it, but the developers I come across for the most part sure do.
> Person.where("last_name = ?", last_name) is the most concise way to issue that query. Abstracting last_name so that if the field name changes, the query still is relevant is overkill.
That is only true if you're dealing with a query that simple (even then, the "Rails way" of doing your example would be Person.find_by_lastname(lastname)). On the other hand, I've read the code of dozens of Rails apps that contains several lines long SQL queries littered just because they could.
The biggest problem in your example as why you are asking for persons with specific last names in the first place. 9/10 when I see code like that, it is the wrong (too low level) question, and leaks domain logic that should be confined to the model.
Also, what happens when you need to serve that query from a web API instead of your database? From a full text engine? From file? From a noSQL database? From on disk hash table? I've had to do all of these - often several from the same application. With a suitable architecture you just plug in your new storage and implement the finders you need supported, and won't have to play "hunt the raw SQL". Changing column names is the least of my concerns - that can be fixed with a simple search replace.
You also miss the point when you say you can do a base model class and do a mapper yourself: The point is the architecture of AR makes leaking SQL which often ends up in controllers and other places they don't belong all over the place the easy default, while implementing cleaner abstractions is more work.
The end result is that most places where AR is used end up with high degrees of coupling for no good reason.
If everyone used AR in a disciplined way and avoided littering their controllers and other code with query details that belongs in their models, there wouldn't be a problem.
Your argument reminds me of the old memory-protection vs. no memory-protection in the 80's, where the Amiga camp for example tended to be bitterly against memory protection because it was seen as expensive, slow and enabling lazy developers. Expecting developers to write clean code with ActiveRecord is a bit similar to expecting developers to write code free of bad memory accesses without memory protection - it makes it far too easy to do the wrong thing.
> github, twitter, heroku et al would like to disagree.
And Ebay at least used to be written using ISAPI modules, and large parts of Yahoo runs or used to run on a horrific mess of PHP and Perl (I used to work at Yahoo; there was a lot of dreadful code). Your point again?
(and Twitter is a particularly bad example given how much time they spend moaning about how they've needed to move most stuff off Ruby)
Besides, pointing to web startups as the pinnacle of engineering quality is ridiculous at best of times - while some of what happens in web startups is amazing, there are also plenty of areas where we're still lagging 20 years behind engineering practices in the enterprise space. Active Record was not by any means a new pattern, for example - none of the patterns in EAR were. They were Fowler's cataloguing of well established patterns with years of use in industry.
Rails, and AR, is still better than a lot of the alternatives. That does not mean there are not better ways for a lot of uses than resorting to AR.
> Person.where("last_name = ?", last_name) makes it unsuitable for large projects?
Strawman. If you think simple cases like that is what it is about, you've not seen much complicated Rails code, and it's a waste having this discussion with you.
> It has been long enough to call it time tested.
So is BASIC. That doesn't mean it's good. "Time tested" is not in itself an argument for anything.
> If Person.where("last_name = ?", last_name) is not abstract enough and makes it unsuitable for your projects(still the only concrete complaint from you), look for alternatives.
I don't use AR the library unless I absolutely have to, which means I only use it if I help out on Rails projects where I can't dictate policy. Otherwise I'll generally use Sequel, which though it suffers from many similar flaws drawn in large part to inspiration from AR, is cleaner in many ways. There's many things I'd love to change about it, but I already have at twice as much stuff to do as I should.
For small projects I might use the Sequel schema module which implements the AR pattern, and which allows for a lot of the same crap that people do with AR the library, but still makes it a lot easier to avoid raw SQL. The AR pattern has its place.
But for larger projects I'd generally be inclined to implement mappers, then often with Sequel (without the schema/model module) used internally by the mappers only.
<% Model.friends.each do |person| %>
<p><%=person.name %></p>
<% end %>
<% for person in Model.friends %>
<p><%=person.name %></p>
<% end %>
{{#friends}}
<p>{{name}}</p>
{{/friends}}
How can you compare that, to a simple `@` symbol? ERB (or even Mustache for that matter, feel like a relic compares to Razor.
I don't think you are doing an objective evaluation.
1. All goddamn editors can be configured to do a short key for the expression(I have mapped \1 to `<% %>` and \2 to `<%= %>`)
2. If that is too much of work, use Haml http://haml.info/tutorial.html or Slim http://slim-lang.com/
# slim
- persons.each do |person|
p = person
# haml
- persons.each do |person|
%p = personIf it matters, it'd take about an hour to put together a wrapper to let you use the @foreach ... { } syntax with Rails. Nobody bothers because this is about item #1045 on the list of pain points in web development.
FWIW: For my part I consider it a massive smell to have what appears to be code in the templates, which is why I prefer Mustache and similar which explicitly force the logic to be kept separate, so to me the Razor example and ERB examples look equally hideous.
Wow. That's revolutionary. Iterating over a collection.
/s
> Very different comparison to the patterns Fowler presented.
You are intentionally trying to miss the point. I don't have to explain how K&R and GoF are very different books, and how Fowler and GoF are very similar books.
> people who in many cases have not even heard about the other ORM patterns presented by Fowler, much less other alternatives.
You mention Folwer 10 times in a row as if he is the appointed expert on ORM. Call me when he has written one, and it's better than the existing ones. Yes, AR is based on AR pattern named by him. So what? Talks are cheap. Produce a better ORM if you are so sure about the deficiencies and Fowler already told you a better solution.
> even then, the "Rails way" of doing your example would be Person.find_by_lastname(lastname)
find throws and exception and where does not. Whoever told you the rails way is to not use where and use the dynamic finder is full of it.
> The biggest problem in your example as why you are asking for persons with specific last names in the first place.
Do I have to tell you that's an example? Really?
> Also, what happens when you need to serve that query from a web API instead of your database? From a full text engine? From file? From a noSQL database? From on disk hash table? I've had to do all of these - often several from the same application. With a suitable architecture you just plug in your new storage and implement the finders you need supported, and won't have to play "hunt the raw SQL". Changing column names is the least of my concerns - that can be fixed with a simple search replace.
Querying needs a language. SQL is for relational databases. A data source agnostic query language does not exist. You can't abstract something that doesn't exist in the first place.
<quote> > github, twitter, heroku et al would like to disagree. And Ebay at least used to be written using ISAPI modules, and large parts of Yahoo runs or used to run on a horrific mess of PHP and Perl (I used to work at Yahoo; there was a lot of dreadful code). Your point again? (and Twitter is a particularly bad example given how much time they spend moaning about how they've needed to move most stuff off Ruby) </quote>
You said AR is a pain for big projects. I pointed out big projects which use AR. And then you are selectively copy pasting to paint the wrong picture.
Twitter moans about Ruby's performance, not project size. Either get your facts straight or stop intentionally twisting them.
> Strawman. If you think simple cases like that is what it is about, you've not seen much complicated Rails code, and it's a waste having this discussion with you.
I have not seen big projects. Twitter and Github aren't worth mentioning. Apparently I missed the memo where you were appointed the authority on big projects.
I have wasted enough time with you. Apart from mentioning Fowler about 50 times, and whining about how Person.where("last_name = ?", last_name) will be an issue when we find life on Mars and we need to integrate with their data sources, there is absolutely nothing you have to say about AR.
You win. You can go home now.
Auto-completion is an editor feature, and support for auto-completion in text-mode editors is not a problem, though I don't use it as I hate auto-complete with a vengeance. If you need to type enough for auto-complete to matter, your language and/or your identifier names are messed up.
Re-factoring and code generation are features I expect of the editor and/or external command line based generators respectively, and there's no reason for a heavy IDE.
I can understand people grab onto IDE's if forced to deal with ridiculously verbose languages like Java or C#, possibly. Yet another reason to stay away from these languages.
Which mighty text-mode editor would that be where auto completion is not a problem? I use Vim and Emacs on a regular basis and it's very much a problem except for cases where it's handled by external tools(eclim, gocode, vimclojure).
> though I don't use it as I hate auto-complete with a vengeance. If you need to type enough for auto-complete to matter, your language and/or your identifier names are messed up.
Programming languages benefit a lot from auto-complete. The only people against it are people who couldn't get it to work in their choice of environment. I have zero inclination to type "validates_numericality_of" or "http.ListenAndServe" or ...
> Re-factoring and code generation are features I expect of the editor and/or external command line based generators respectively, and there's no reason for a heavy IDE.
Please refresh your memory. I said VS is a good IDE and you said a solid CLI is far more productive. I am not interested in your rant. I am interested in what does CLI do better than the IDE, particularly VS or Eclipse.
> I can understand people grab onto IDE's if forced to deal with ridiculously verbose languages like Java or C#, possibly. Yet another reason to stay away from these languages.
Oh man. My environment doesn't have reliable autocomplete. Let's pretend only verbose languages need autocomplete. Yay.
Are you kidding me?
Slim looks like something much MUCH better than the crufty old ERB.
And what difference it makes if it comes with Rails or I have to add an entry to Gemfile? Ruby has many different templates. What comes bundled with Rails is totally up to creators. DHH is opposed to haml https://twitter.com/dhh/status/58289541068492800 and hence, erb is the default which is unlikely to change.
They don't even have to accommodate alternate templates(which they do seamlessly). Do you cry a river every time you have to use a library which doesn't come bundled with .net?
> Slim looks like something much MUCH better than the crufty old ERB.
And it's better than Razor's crufty syntax as well.
But please keep tooting your horn about your Razor. I have wasted enough time here.