Should We Rely on Language Constraints or Responsibility?

I think that one, if maybe not THE one, aspect is missing in all of the presented consideration. I don't know a single good developer that will use only one language to achieve all of his tasks. Every language has its pros and cons (some have more than others, but that's not the point), but more important, every language (even LOLCAT) was created with a certain vision on how to solve SOME problems.


The issue is that, for fun, by fear or by ignorance, some people tried to get out of the initial scope of the language.

• Perl wasn't suppose to be a graphical oriented language, but 3D modules exists.


• EcmaScript wasn't created to manipulate binary data, and now we are using it to stream content on the server side.


• Java was supposed to have an GC that you don't have to worry about, and now they is pushing to use it on critical real-time application.

Hi,

I think you guys missed an essential point in that interesting article: yes Ruby is one of the most permissive language around and yes it allows to easily to do mistakes while framework like Rails tend to make it really obvious what good practices should be.

So then you say some argue that the Ruby community is especially wise at encouraging the good practices. Very true, but one should also keep in mind one thing: currently Ruby coders are still essentially people who have chosen to escape J2EE or PHP for Ruby. Those are not the mass of stupid average coders who tend to follow the corporate conventions. And if the Ruby community is still so wise IMHO this is very much because they aren't composed by the average PHP developer guys.

But, as languages will move on, I expect Ruby and Rails adoption to increase when managers will finally get that J2EE is really overkill for 90% of the web dev and PHP doesn't lead to sustainable coding. When that happen just like Cobol, Smalltalk or C++ started to fall, I expect that the average Ruby coder will really not be as skilled as today's one. Then I think we will really start to see the pitfalls of a language that is so permissive.

So IMHO, a good tradeoff again might lie in the JVM language and polyglotism: things that should be strict and can afford to be developed slowly might continue to be developed in static languages such as Java or possibly Scala/Clojure, while integration code will be better written in JRuby using those lower level libs. Meanwhile, as you said, some smart frameworks such as Rails might continue to exist in permissive dynamic language at the condition that the static compiler guards are replaced by a smart wide community adopting very large test suites.

So in a word I doubt Ruby itself is the silver bullet because the community would be more responsible. It's true today but it won't be true tomorrow and languages guards will still be required at some point.

Raphaël Valyi

The topic of the debate is a bit polarizing as everyone knows it is not a binary decision between constraints and responsibility.

Any tool, be that a programming language or a kitchen knife has aspects of design constraints and user responsibility.

Any tool should be practical. It should do the job it was designed to do and as such it will have constraints. The constraints should not be there to hinder the user to do the intended tasks - they should help the user to do the job. The user can still misuse the tool but the intention of the tool should be intuitive enough so that anyone can learn it with little practice and understand the principles.

A knife as handle and the blade. You can grab the blade but you quickly learn you should hold it by the handle. The handle also protects the user while the knife is being used so that you do not slip your hand over the blade, and aids in proper cutting. You can still cut your fingers, stab yourself etc. but that is beyond the design of the tool. The user has the responsibility to learn simple rules about knives and practice to use it adequately.

That being said; the tool should not be so obscure to and complicated to its users that it is hard even for the experts to understand why it does or does not work. For that reason, there has to be constraints that simplify the usage of the tool. If the usage is simple, but consequences are complicated, it's still wrong. Consequences should be straightforward and unambiguous.

In that light, something like C++ is too complicated. Ruby is too loosely defined as problems are too easy to create and consequences hard to track.

A more constrained language makes it easier to read what code does, and generally makes it easier to build tooling around it.



It's also interesting to me to read that the Ruby culture somehow avoids the problems which C++ is infamous for. Is this because Ruby's user base doesn't include the plebs (I would think the opposite, since many have a PHP background), do we have a wiser generation of programmers who learned from mistakes in the past, or is Ruby's freedom simply better to handle than C++'s?



Ideally, I'd like a language where rules are strong and explicit, but can be broken if it makes sense and without a lot of hacking; a bit like poetry or songwriting maybe. What exactly that looks like is a tough question... maybe Scala is the closest practical thing currently available :-)

Excellent metaphor: the language as a knife. Some features are like that. A child is more likely to hurt himself or another with a knife, while an adult is less likely to do so, but there still is a possibility to harm himself and sometimes it happens. Beginners misused C++ in many ways, and language designers reacted to that introducing constraints. See Java. An experienced programmer wants freedom because he instinctively avoids some pitfalls that he has encountered in the past, so he prefers the freedom.



Indeed, it is not a binary decision, that's why the poll contains 3 options, not 2. Also, the quoted reactions represent different positions.

Any tool should be practical. It should do the job it was designed to do and as such it will have constraints. The constraints should not be there to hinder the user to do the intended tasks - they should help the user to do the job. The user can still misuse the tool but the intention of the tool should be intuitive enough so that anyone can learn it with little practice and understand the principles.

A knife as handle and the blade. You can grab the blade but you quickly learn you should hold it by the handle. The handle also protects the user while the knife is being used so that you do not slip your hand over the blade, and aids in proper cutting. You can still cut your fingers, stab yourself etc. but that is beyond the design of the tool. The user has the responsibility to learn simple rules about knives and practice to use it adequately.

"Those are not the mass of stupid average coders who tend to follow the corporate conventions."....Wow, talk about the Fundamental Attribution Error in action....

Not only is it a non-binary decision, it is also a non-linear one. Do we have to choose between no constraints at all and a strict set of rules put into the language by the designer? Is there an alternative solution, like, maybe, programmable constraints? Recent developments in functional languages suggest that such an alternative could exist. Take Haskell with its type-level functions, for example. There are also some experimental languages like Agda where one can define functions of both types and values.
And, yes, I do agree with Eelco that constraints are not to protect me from lame programmers. First, more constraints mean that it's easier for me to reason about the code, even if that code was written earlier by me. Second, more constraints on the type level means less unit tests. I don't have to write unit tests for some dumb errors that can be caught by the compiler before the code runs. Third, more constraints means more comprehensive tools available for the language.
I don't want a language designer telling me what constraints I should use, but I also wouldn't like him to tell me that constraints are bad in general, so, sorry, you can't have them. What I really want is programmable constraints that I can grow and get more sophisticated together with the rest of the code.

+1



This one size fits all mentality is sad, especially in this day and age. The language is no longer the platform, folks. Languages are just tools and you should use the right tool for the right job.