The Artima Developer Community
Sponsored Link

Artima Developer Spotlight Forum
Michael Feathers on Patronizing Language Design

37 replies on 3 pages. Most recent reply: Jul 30, 2009 12:36 AM by Darko Latkovic

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 37 replies on 3 pages [ « | 1 2 3 | » ]
Cameron Purdy

Posts: 186
Nickname: cpurdy
Registered: Dec, 2004

Re: Michael Feathers on Patronizing Language Design Posted: Jul 15, 2009 12:52 PM
Reply to this message Reply
Advertisement
Nemanja -

> I have always felt that it was not a business of a
> programming language to make up for deficiencies in the
> development practices.

I have to agree with James on this one in one sense: Some of the greatest decisions (IMHO) in language design were related to leaving things out of a language, not in how to put yet more things in.

So instead of thinking of "languages making up for deficiencies", perhaps we could say "choosing not to add all sorts of shiny yet dangerous toys to a language that can get by without them".

Peace,

Cameron Purdy | Oracle Coherence

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: Michael Feathers on Patronizing Language Design Posted: Jul 15, 2009 1:27 PM
Reply to this message Reply
> Ahh yes...a developer's freedom to express himself should
> be achieved by taking away his freedom to express
> invariants in his code. Makes perfect sense to me.

I don't recall saying that. I'm all for having the ability to express invariants in code.

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: Michael Feathers on Patronizing Language Design Posted: Jul 15, 2009 1:28 PM
Reply to this message Reply
> It seems that languages focused on preventing you from
> doing the wrong thing (e.g. Java) receive harsh criticism,
> whereas languages focused on enabling and encouraging you
> to do the right thing (e.g. Scala) receive much praise.
> Different still are languages that encourage you to do
> o stupid things like cast a pointer to an integer or
> vice-versa (e.g. C), which are languages that frequently
> come under attack.

I think that's a useful classification.

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: Michael Feathers on Patronizing Language Design Posted: Jul 15, 2009 1:45 PM
Reply to this message Reply
> I think Michael Feathers likes what he likes and holds
> things he doesn't like in contempt. I don't get his
> reasoning in some cases.

I don't think I feel contempt about anything in programming. I just don't think about things in those terms.

For what it's worth, I'm not a dynamic language zealot at all. In fact, Haskell is my favorite language today and I spend a lot of time in C++, Java, and C#.

Re reflection, yes, it is true that there is a cost issue, but Stroustrup was quite clear at one point that he was scared that it would be misused. He did later reconsider and accept RTTI.


> That post/article really feels like it is nothing more
> than the general "the stuff I like rules, the stuff I
> don't like sucks" garbage you see regarding technology
> these days. I think the assumption that language design
> decisions to restrict things, make some things hard to do,
> or not implement some feature results in "a decreased
> sense of responsibility and ownership" is fundamentally
> flawed.

I don't think so. Have you hung around Ruby or Python people much? Or go to their conferences? It's noticeable.

> One can easily turn his argument on its head and ask if
> Ruby makes one's sense of responsibility and ownership
> decreased because of a lack of manual memory management?
> After all, Yaz has decided I don't need to worry about
> taking care of myself regarding how I use it. Does Rails
> cause this problem with web apps? Rails is pretty damn
> particular in what it expects. You try not following the
> Rails naming conventions and MVC pattern and see how far
> you get. I'm sure Mr. Feathers will argue that these
> things are tools to help you get your job done in some way
> that is "better" than you could get it done without them.
> If they were <insert language other than Ruby here>
> features they would prevent you from being responsible and
> owning your work.

You seem to assume an awful lot about me.

> If you look at the comments following the post, you'll see
> he backs up on some of his points and questions things he
> doesn't seem to really understand, like how could pointers
> really be useful.
>
> "Laurent: I knew someone would bring up that point.
> Although, I thought their example would be pointers rather
> than goto. Frankly, I think goto is okay to have in a
> language for the odd cases when you feel you have to use
> it. Raw pointers in a managed memory language, on the
> other hand, are a harder issue. The question is really
> whether you can do anything useful with them."

I think you misunderstood that. I was talking about raw pointers (pointers which can point anywhere) in a managed environment.

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: Michael Feathers on Patronizing Language Design Posted: Jul 15, 2009 1:56 PM
Reply to this message Reply
Well, I knew this blog would cause a bit of controversy, but I didn't expect that so many people would see it purely in terms of the dynamic/static debate. It's really orthogonal to that.

The issue is really whether language designers accept the idea that ultimately developers should be responsible for the misuse of language features.

It is very easy to feel that some features are just too powerful for developers, and that they should be restricted. As I pointed out in the blog, I see the workarounds quite often, and I think they are worse than the disease in many cases.

Scala is a good non-dynamic example. It did not assume (as Java and C# did) that multiple inheritance was too much. Like Ruby, it tamed it and made it available through its traits mechanism.

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: Michael Feathers on Patronizing Language Design Posted: Jul 15, 2009 1:58 PM
Reply to this message Reply
> Nemanja -
>
> > I have always felt that it was not a business of a
> > programming language to make up for deficiencies in the
> > development practices.
>
> I have to agree with James on this one in one sense: Some
> of the greatest decisions (IMHO) in language design were
> related to leaving things out of a language, not in
> how to put yet more things in.
>
> So instead of thinking of "languages making up for
> deficiencies", perhaps we could say "choosing not to add
> all sorts of shiny yet dangerous toys to a language that
> can get by without them".

I'm a big fan of minimal language design also. I think that some of the things I'm complaining about can actually be seen as things which could have been general, but were hobbled instead.

Erik Engbrecht

Posts: 210
Nickname: eengbrec
Registered: Apr, 2006

Re: Michael Feathers on Patronizing Language Design Posted: Jul 15, 2009 2:02 PM
Reply to this message Reply
Michael,
> I don't recall saying that. I'm all for having the
> ability to express invariants in code.

I interpreted your blog as stating that a programming language where invariants can be expressed and are enforced is patronizing.

You, of course, didn't use the word "invariant," but your focus was very much on how enforced restrictions are unnecessarily patronizing. I interpret most of the restrictions you identified (e.g. sealed and final classes) as means of expressing invariants.

Erik Engbrecht

Posts: 210
Nickname: eengbrec
Registered: Apr, 2006

Re: Michael Feathers on Patronizing Language Design Posted: Jul 15, 2009 2:08 PM
Reply to this message Reply
> Scala is a good non-dynamic example. It did not assume
> (as Java and C# did) that multiple inheritance was too
> much. Like Ruby, it tamed it and made it available
> through its traits mechanism.

As a frequent user of multiple inheritance in Scala (and Python), I'm not sure Scala has made much progress in taming it relative to C++. A little progress, yes, and the result is wonderfully powerful, but it isn't really tame.

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: Michael Feathers on Patronizing Language Design Posted: Jul 15, 2009 2:18 PM
Reply to this message Reply
> Michael,
> > I don't recall saying that. I'm all for having the
> > ability to express invariants in code.
>
> I interpreted your blog as stating that a programming
> language where invariants can be expressed and are
> enforced is patronizing.
>
> You, of course, didn't use the word "invariant," but your
> focus was very much on how enforced restrictions are
> unnecessarily patronizing. I interpret most of the
> restrictions you identified (e.g. sealed and final
> classes) as means of expressing invariants.

I'm all for expression. Enforcement can be problematic. I like how Eclipse handles this.. with the "soft final" convention: http://www.eclipse.org/articles/article.php?file=Article-API-Use/index.html

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Michael Feathers on Patronizing Language Design Posted: Jul 15, 2009 2:25 PM
Reply to this message Reply
> The issue is really whether language designers accept the
> idea that ultimately developers should be responsible for
> the misuse of language features.

I think you first have to answer the question of whether all language features are equally legitimate.

As a hypothetical, I propose a new keyword for Ruby: 'scramble'. When executed, scramble reassigns all references in memory to random objects.

Now that I have defined this feature, would you advocate that it be implemented? I'll assume not. Is this patronizing? No one forces anyone to use this feature. It's up to the developer to take responsibility for their code, right?

Obviously this is a ridiculous example but I would say that there are features of languages that aren't much more useful and create nearly as much havoc.

If you agree that this feature should not be implemented, then you must admit that not all features are legitimate. Then the question is merely which features are good and which are bad and that is nothing more than a subjective assessment.

Merriodoc Brandybuck

Posts: 225
Nickname: brandybuck
Registered: Mar, 2003

Re: Michael Feathers on Patronizing Language Design Posted: Jul 15, 2009 2:28 PM
Reply to this message Reply
> > I think Michael Feathers likes what he likes and holds
> > things he doesn't like in contempt. I don't get his
> > reasoning in some cases.
>
> I don't think I feel contempt about anything in
> programming. I just don't think about things in those
> terms.
>
> For what it's worth, I'm not a dynamic language zealot at
> all. In fact, Haskell is my favorite language today and I
> spend a lot of time in C++, Java, and C#.
>
> Re reflection, yes, it is true that there is a cost issue,
> but Stroustrup was quite clear at one point that he was
> scared that it would be misused. He did later reconsider
> and accept RTTI.
>

And I granted you that. But that's certainly not the only reason for treading lightly on reflection and the post linked to makes it sound like that is THE reason that it wasn't available at all in C++. There were several reasons and I don't think you can discount backward comparability with C and performance as legitimate reasons for leaving it out for a long time given C++'s design goals.

>
> > That post/article really feels like it is nothing more
> > than the general "the stuff I like rules, the stuff I
> > don't like sucks" garbage you see regarding technology
> > these days. I think the assumption that language design
> > decisions to restrict things, make some things hard to
> do,
> > or not implement some feature results in "a decreased
> > sense of responsibility and ownership" is fundamentally
> > flawed.
>
> I don't think so. Have you hung around Ruby or Python
> people much? Or go to their conferences? It's
> noticeable.
>

Probably not as much as you, but I've spent some time with people from both communities. I still think the assumption is flawed. It seems like a big leap to say that Ruby people feel more responsible or take greater ownership of their code simply because the language is more flexible. I know people that have worked in a very wide variety of languages for a wide variety of reasons. Sense of ownership, in my experience, is a character trait and a very human one. It has little to do with the language one is working in. Some of the people i know that take the greatest pride in their work and complete ownership of everything they do work in Visual Basic of all things. It's what pays the bills. At best there is a weak correlation between language choice and sense of ownership and responsibility and I would say so weak as to not be worth considering.

> > One can easily turn his argument on its head and ask if
> > Ruby makes one's sense of responsibility and ownership
> > decreased because of a lack of manual memory
> management?
> > After all, Yaz has decided I don't need to worry about
> > taking care of myself regarding how I use it. Does
> Rails
> > cause this problem with web apps? Rails is pretty damn
> > particular in what it expects. You try not following
> the
> > Rails naming conventions and MVC pattern and see how
> far
> > you get. I'm sure Mr. Feathers will argue that these
> > things are tools to help you get your job done in some
> way
> > that is "better" than you could get it done without
> them.
> > If they were <insert language other than Ruby here>
> > features they would prevent you from being responsible
> and
> > owning your work.
>
> You seem to assume an awful lot about me.
>

All I'm saying here is that your observations about other languages and your stated comments about ownership can very easily apply to Ruby. Ruby and Rails make lots of assumptions and do some things that you characterized as "reducing responsibility and ownership" of people that program in other languages.

If my assumptions are wrong, how are the design decisions in Ruby and Rails not doing the same thing? Rails especially. It's notorious for being a bear to work with once you tread a bit outside of CRUD apps. I've had dyed in the wool Rails folks admit to this, so it's not just my personal experience or bias that I base this statement on.


> > If you look at the comments following the post, you'll
> see
> > he backs up on some of his points and questions things
> he
> > doesn't seem to really understand, like how could
> pointers
> > really be useful.
> >
> > "Laurent: I knew someone would bring up that point.
> > Although, I thought their example would be pointers
> rather
> > than goto. Frankly, I think goto is okay to have in a
> > language for the odd cases when you feel you have to
> use
> > it. Raw pointers in a managed memory language, on the
> > other hand, are a harder issue. The question is really
> > whether you can do anything useful with them."
>
> I think you misunderstood that. I was talking about raw
> pointers (pointers which can point anywhere) in a managed
> environment.

That I misunderstood. The statement could go either way, thanks for clearing that up. I've had a couple of times I've had to use raw pointers in C# from .NET, so I've personally found a use, in a couple of special cases, for pointers in a managed environment.

I'm more curious a bit about this observation now. Most of the people I know that do a lot of Ruby, Python, pick your not-so-mainstream-language, tend to work at smaller companies or they are trying very hard to do their own thing and want the tool that gives them the most leverage (I'm unashamedly borrowing from Paul Graham here). They wear lots of hats and at the end of the day, they can't turn around and blame anybody because if something isn't delivered, it isn't delivered. What kind of groups or organizations did you have in mind when making these observations? I'm wondering, simply if some of this feeling, and perhaps a great majority of the feeling, has more to do with the types of projects and the size of the organization than the specific language choice.

I ask this because currently i work for a small company that does all of its work using Microsoft technologies. The job I had before this one did almost all of its work using almost all of the same technologies. The company I work for now has 15 employees. The company I used to work for has about 40,000. In the company of 40,000 you can pass things up the chain, blame vendors, get your vice president to call the vice president of Vendor X to try and get things ironed out and spend a lot of time and money on this sort of thing. In fact, in some departments I worked in, it was encourage to do this sort of thing. After all, you got paid the same whether you produced or not. Why work when you could schedule yet another meeting? And this kind of mentality drove me completely nuts.

Now I actually get to get things done. Same tools, different people with a different mindset. Generally speaking, larger corps only use the big mainstream languages and I wonder if this is most of your experience with people using the other languages you question, then what affect is that having on your observations? You aren't going to find Ruby or Python in your average fortune 500 company. You'll find lots of .NET and Java and C++. You'll also find those languages and platforms in smaller companies as well, where people have to take responsibility for what they do and they have to own it or the whole organization dies.

I think if the communities and the people that used languages like python, haskell, schem, ruby, etc. were of the same size as those that use C++ or VB then they would probably revert to the mean and exhibit, on average, a much lower tendency to take ownership for what they do. I think people in general are just wired that way. A lot of them want to get into work, get their job done and go home. They work with the tools that the employer has and if they had to work in brianfuck they would do that, too, and you could say brainfuck developers lacked a sense of responsibility and ownership.

Anyway, I've rambled on long enough. Language X zealots being inherently more responsible, especially when Language X has a relatively small user base, simply because that's the language they use seems like a big leap. I simply think those developers would be that way regardless of the language or tool they use. It's who they are. If Ruby becomes mainstream 10 years from now somebody will be writing about how some not quite as popular language XYZ folks are better programmers and Ruby programmers on average don't take much responsibility for their work.

Nemanja Trifunovic

Posts: 172
Nickname: ntrif
Registered: Jun, 2004

Re: Michael Feathers on Patronizing Language Design Posted: Jul 15, 2009 4:19 PM
Reply to this message Reply
> Cameron Purdy :
>
> So instead of thinking of "languages making up for
> deficiencies", perhaps we could say "choosing not to add
> all sorts of shiny yet dangerous toys to a language that
> can get by without them".
>

Believe me, I do see the beauty of this approach. But if you take it really seriously where do you end up? R5RS Scheme? Basically you give the programmer a nice and simple syntax and powerful macros and let them build everything else on top of it. Paul Graham's "On Lisp" Nirvana. Except that it does not work that way in real world. People need a little more than that to get their jobs done within real life constraints. I have never used a "nice" language for production code - no Pascal, ML, Lisp, Haskell. It was always something "ugly": Fortran, Assembly, C++, Javascript, Perl, C#. The queston is not what is beautiful or even good - it is only what can get the job done in the ugly real world.

Frank Sommers

Posts: 2642
Nickname: fsommers
Registered: Jan, 2002

Re: Michael Feathers on Patronizing Language Design Posted: Jul 16, 2009 10:32 AM
Reply to this message Reply
> I have never used
> a "nice" language for production code - no Pascal, ML,
> Lisp, Haskell. It was always something "ugly": Fortran,
> Assembly, C++, Javascript, Perl, C#. The queston is not
> what is beautiful or even good - it is only what can get
> the job done in the ugly real world.

Well, I don't want to plug Scala here, but that's actually the very reason that attracted me to Scala on the JVM - I can use a language that is "nice" in the sense you're saying, but at the same time also helps me get my job done.

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: Michael Feathers on Patronizing Language Design Posted: Jul 18, 2009 6:58 AM
Reply to this message Reply
InfoQ has picked up on this topic: http://www.infoq.com/news/2009/07/Constraints-or-Responsibility

The page collects a bunch of responses from different forums.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Michael Feathers on Patronizing Language Design Posted: Jul 20, 2009 6:35 AM
Reply to this message Reply
Once again Stroustrup is out of touch with reality.

> Stroustrup had this to say about reflection and C++
> http://www.research.att.com/~bs/omo_interview.html
>
> "OMO: I agree. I believe high-level structures, especially
> with the help of generic collection classes, should almost
> always replace pointers in code.

Not possible because excessive copying can mess up a program's performance, especially in big data structures.

> BS: Often. However, I have not seen an approach to full
> reflection directly supported by a language that didn't
> cause serious overheads.

Reflection has nothing to do with performance. Qt provides reflection through macros, with no performance hit at the rest of the code.

Reflection is nothing more than meta information. It does not have any overhead in performance.

Also, reflection seems to
> encourage styles of programming that make it hard to
> determine what's going on from the source text and
> discourage static checking.

Sometimes it is necessary. In GUIs, for example, reflection makes life so much easier.

> Consequently, the C++ RTTI provides only the minimal
> information to determine the types of objects at run time.
> Where necessary, this can be used as a handle for more
> information about types (classes), but any such
> information is beyond what the standard guarantees."
>

Yet another example of Stroustrup presenting his own limitations as limitations of what languages can or can not do.

Flat View: This topic has 37 replies on 3 pages [ « | 1  2  3 | » ]
Topic: Laurence Vanhelsuwé on Java Collections Pitfalls Previous Topic   Next Topic Topic: Two-Way Data Binding in Flex 4

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use