Not teaching inheritance would be ridiculous both from a conceptual/theoretical point of view (it's a useful tool and interesting CS topic) and from a pragmatic point of view (it's a core principal in a number of important languages).

i think not teaching it would be ridiculous in the sense that it's such a common concept that you have to know it.

i actually think not teaching it would be a terrific thing other than that though. there are almost always better forms of code reuse, especially in languages that support mixins.

I disagree that Rails gets anything wrong here and completely disagree that you should decouple your business logic from the framework. Consider "Interactor" class part of another framework and try to make the same case - i.e. do I need to decouple my business logic from this Interactor in the DCI framework.

As I've argued before, if you want perfect architecture, you gotta do it yourself. The whole point of a framework (as opposed to libraries) is to save time making decisions and training people on your idiosyncratic architecture and avoid unqualified people from making major architectural decisions. And testability in some theoretical sense is nowhere near the most important concern and controllers are testable. Unless you're dealing with lots of complex domain-specific logic, abstraction of which will be driven by domain-specifc concerns, it's quite unlikely that it matters much where your "business logic" is.

And even then, most Rails projects die long before they reach the point where this matters. I don't know what you're trying to optimize for but it doesn't seem to be a typical real-world project.

How can I know what the interactor does in the blog example? The blog doesn't describe the abstraction's semantics well at all. This is a big problem with introducing random, poorly conceived external abstractions. Not only does the code look worse and longer, I have to go look at the source to figure out what it does. And its uselessness is connected to its obfuscation - it's much easier to figure out what a useful class does, because its design is driven by purpose.

As for async, that would be an example of a useful thing that it can do, but doesn't. Doing a bunch of asynchronous operations and handling errors in an arbitrarily configurable way, for instance, is not that easy just using primitives in most languages. When I first skimmed through the article, I thought that's what it did, along with automatically catching exceptions and such, but looking at the code, it doesn't seem to be the case.

The two things are not analogous. The Interactor is not part of a framework in anywhere close to the same sense. Write your own, name it something different. It's just a simple ruby class. The point is that this is code that helps you naturally express your business logic. It's not an appendage that has nothing to do with your logic and is all about web requests and routing. Or don't use any Interactor at all, just write your domain class and delegate to that.

The problem is when unqualified people make bad architectural decisions and embed them in the framework itself.

and yet the same complaints and failures come up over and over in large rails projects, and the root cause always seems to be this. it matters.

Any project, of almost of any size, would benefit from what I'm suggesting. Larger ones more so.

Seems like we're kind of arguing in circles now though... I think just agree to disagree.

Disagree.

Meh, maybe.

Edit: I still think this is a poor argument for not teaching an interesting / powerful concept. But I acknowledge its hard to imagine what the programming world would be like if there were no major languages built around the concept of inheritance. So maybe in such a world inheritance really wouldn't be that interesting...

jj, i'll take that "meh" to mean i can add you to my list of public supporters at www.inheritanceisevil.com. i thank you for standing with us.

But this is not what happened - nothing about Rails stops you from implementing business logic in classes that specialize in business logic. Yet, you're saying this happened:

Rails is what it is, regardless of whether you business logic in separate classes or in controllers.

Programmers ending up with more code than they can handle and later blaming the framework for not perfectly guiding them is something that happens with almost every successful project and every successful framework. Also, this is akin to not using Rails because of scaling problems and performance - worry about problems you have now. Most projects never get that far. I wouldn't use Rails anyhow but even if it was my favorite framework, I would never use Rails or Ruby for that matter if I know from the beginning that my project would have to scale to a large codebase, lots of connections and a large team of developers. It's not javascript, it's slow and it scales poorly to large codebases because of the combination of complex, dynamic language features that are easy to abuse and lack of static types.

Just about every software project is over-budget and late - there usually are going to be more important problems than my controller is too fat because Rails.

no, nothing stops you but the culture and framework encourages you not to do so. you even have the framework creator, who is a community leader of sorts, coming in and advising against it. imo it's harmful.



i agree with most everything you say here, except i think you are underplaying what "my controller is too fat" really means. it's a symptom of pretty bad overall design. and fixing it won't be as simple as moving your code to different files. you are right that a framework can't make bad programmers into good ones, but it can at least not exacerbate the harm. i'm saying that if it was rails convention, from its inception, to have PORO business objects that you delegate to and test outside the framework, things would be better today than they are. obviously i can't test that hypothesis, but i think it's true.

I think JS is worse than ruby when it comes to maintainability and scaling to a large code base. There's too many ways to do something where the implementation is drastically different to the point where it doesn't even seem like the same language anymore.

All languages have problems honestly. Python is split into 2.x vs 3.x and the community as a whole doesn't care about pushing forward and instead prefers keeping contracts written 10 years ago. It's why I think django will be irrelevant in a matter of time, the core devs just don't care enough about transforming the framework.

Ruby has abusive meta programming but at least with web dev with rails you can get very far without doing anything too crazy. Performance is also quite fine and it's pretty well accepted if you need to do something highly concurrent where latency is of the utmost importance you can easily just write parts of it it in Go or some other fast language and access it in your rails app or maybe talk directly to it through JS, depends on what you're doing.

If by "things" you mean the state of large Rails codebases, I can't really disagree. But without the effectiveness of the marketing pitch - view, controller, model, boom, here's your web app - Rails may be another fringe framework. Rails was an unbelievable phenomenon - I remember playing around with Ruby in college in 2000-2001 or so and it was a fringe language that everyone thought would be remain fringe, mainly loved by academic language geeks and Lisp programmers. It trailed even "academic" languages like OCaml and Haskell in mindshare, wasn't even as popular as Clojure today. I'm sure Ruby grew in popularity even before Rails came onto the scene, but I think Rails had to have a perfect marketing pitch to explode the way it has.

Python, Javascript and Ruby all have problems scaling to a large codebase and a large team, but Javascript at least has fast implementations and you kind of have to know it anyway. And Python is hardest to abuse out of the three. Ruby is most expressive, but that doesn't really help with large teams.

But Python, Javascript and Ruby are hardly all languages - statically typed languages fare quite a bit better with a large team that's not uniformly disciplined.

I never saw the extreme hype over static types implemented at the language level for web dev.

You can type restrict fields at the database level with rails and rails will convert your string inputs (form inputs from the user) into those types as best as possible as well as validate them with arbitrary rules you setup.

Sounds pretty safe to me. With a statically typed language I understand at compile time you can catch type mismatches rather than at runtime but for web dev I just don't see that as being that big of a deal.

yeah you are probably right about all that. (meaning rails marketing stuff @candybar)

I think any 'reasonable' programming feature/technique described in language as strong as 'evil' is generally a gross exaggeration. But yes, I'm genuinely in agreement with you about it especially in languages that offer mixins.

Statically typed languages aren't about storing correct values in the DB - that is one of the places where static typing doesn't help you all that much, because ultimately external constraints that exist at runtime cannot be validated at compile time. Every time you get an error because you put an incorrect value somewhere - you called a method that didn't exit, you passed an object where you needed a function, you had a conditional that puts in one type of value in one branch but another type in another branch, you passed in the wrong number of arguments, your closure didn't return the right type of value, you tried to put a number in a list of strings, etc; if you were in a statically typed language, the error would have been caught at compile time.

You're correct in that "web dev" or "anything" dev where anything has a large surface area that has to interact with external systems, whether that's browers or databases or humans, static typing is less useful because external input and output cannot be validated internally. Static typing can't tell you if the user typed in a number or a date. But the larger the application, the less surface area it will have relative to the entire codebase and the more your code will be talking to your other code. And that's where static typing shines - validating internal constraints.

A good editor will catch most of those errors instantly in a dynamic language. That's my only real draw to editors like rubymine/pycharm. Their static code analysis is superb. There's a lot of comfort in knowing that you'll never ship code where you typo'd a method name or passed in the wrong number of args to a function, etc..

RubyMotion seems pretty slick. I'm going through a few tutorials (I don't care for these ridiculously verbose Objective-C names) but am quickly able to test drive a basic application.

There are tons of gems available for it, which is super nice. There is one popular gem that makes a lot of these method/object names way shorter. Looking forward to getting a little bit more comfortable with it.

I mean am I supposed to remember this, or just live in the iOS developer API?

So take that and multiply awesomeness by a factor of 10 and you're where people are with C# and Visual Studio or Java and IntelliJ IDEA. Static analysis feels superb because you're going from nothing to something but RubyMine/PyCharm type-checking/inference is necessarily minimal and/or in many cases requires hand-written annotations. RubyMine for instance works well for Rails and Ruby standard lib because they got someone to enter all the type definitions - unless you do the same for your own codebase, you won't have the same level of confidence - it will find some trivial errors and miss others. The larger the codebase, the worse the type inference gets, because type inference is best along the surface area where you're interacting with frameworks and standard lib that the editor guys built in the type annotations for. In statically typed languages, this confidence exists by default unless you try hard to subvert it.

But getting back to the point, you can use these tools for yourself to get some of the benefit of static typing, but they are much less useful in a large team, because what needs to be annotated is not clear and the only way to get any kind of confidence that your codebase is typesafe is if you enforce coding standards (annotate everything) such that you're paying most of the cost of static typing while getting a fraction of the benefits. Again, by yourself, you know what you have to do to get the maximum benefit and minimize costs, but you will find that in a larger team, people will often do the least they need to do get the job done at the expense of others and it's difficult to communicate expectations.

Also when you get to Haskell/ML/Scala land, you can use types to express a whole lot more than just data types. The CS-ish way to look at is that type declarations are program invariants - they are statements about a program. Going backwards, tons of program invariants can be coded as types and verified statically. For example, you can design types such that user input cannot be sent directly as part of a SQL statement unless it's expliclty sanitized, values of different units cannot be used interchangeably, etc. At an advanced level, a type system can be used as a limited form of a declarative programming language that performs program verification.

https://speakerdeck.com/folone/there...-in-your-scala
http://cs.brown.edu/courses/cs173/2012/book/types.html

Now, you can do some of the same thing in dynamically typed languages, but your program will be verified at runtime and crash, instead of being verified at compile-time. The other problem is that dynamically typed languages provide much less support for encoding program invariants as types. Also, without a fairly crazy compiler, generally overusing types lead to performance penalties in dynamically typed languages that you don't incur in statically typed languages.

I won't contest statically typed languages are better on average for large teams but I have no goals to ever be a part of huge team where ****** protection mechanisms require me to write a ton of boiler plate.

For the record I did spend months working with Go and also fooled around with Scala and went through a Haskell phase. I'm aware of how beneficial defined types are for code analysis.

I just don't think they play a large enough role in web development that I would switch to a language that's statically typed but has horribad community support for web development vs rails. The trade off is just not there.

I never shipped any production code that had silly errors like passing in Bar to Foo when Foo expects Baz. I also don't code defensively with a million "type of" checks to get around lack of types.

I try to use tools to the best of my ability and write some trivial tests to prevent those errors from happening at run time. Also rubymine picks up my missing methods or wrong arguments instantly without annotating anything. It also does the same for anything that's on my ruby manager's path (aka., every gem I have installed). That's the bulk of where any potential errors could get through accidentally assuming you have zero tests written isn't in the case anyways.

The performance aspect seems like an ivory tower decision too. I doubt having too many classes in your application will be your bottleneck in any modern popular language.

I vaguely recognize some of the concepts in the above posts.

edit: I did take a few C++ comp sci courses in HS/freshman year of college like 11 years ago

Shoe Lace,

We're not questioning your preferences and habits, which are perfectly reasonable, nor discussing whether dynamic or static is better, which is silly, but discussing my statement that I would use a statically typed language even if I was most productive in Ruby/Rails if an oracle told me that my project would be extremely successful and I'd end up with a large userbase, a large team of programmers and a large codebase.

It's great that you're good with Ruby and don't make silly type errors and are disciplined enough to write exactly the right tests and what not, but it has very little to do with the hypothetical we're discussing. My experience is that the "be awesome like me" method of enforcing code quality and runtime safety scales quite poorly and human fallibility is much more obvious when you work with other people. If you want to learn more about limitations of type inference in dynamically typed languages (or more generally, langauges with late-binding and subtypes), that's fine but that's a whole lot of math and papers.

that brown course looks very good.

I'm not awesome though. I just offload the work to an editor so I don't need to think about it. I don't make the mistakes because the editor makes it almost impossible to make them.

Also extremely basic tests that anyone would write in any language prevent the things that the editor cannot protect against.