The Artima Developer Community
Sponsored Link

Articles Forum
Matz on Craftsmanship

16 replies on 2 pages. Most recent reply: Mar 9, 2004 12:17 AM by Ian Monroe

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 16 replies on 2 pages [ 1 2 | » ]
Bill Venners

Posts: 2251
Nickname: bv
Registered: Jan, 2002

Matz on Craftsmanship Posted: Dec 29, 2003 12:00 AM
Reply to this message Reply
Advertisement
Yukihiro Matsumoto, the creator of the Ruby language, talks with Bill Venners about becoming a better programmer through reading code, learning languages, focusing on fundamentals, being lazy, and considering interfaces.

Read this Artima.com interview with the creator of Ruby:

http://www.artima.com/intv/craft.html


Joost de Vries

Posts: 19
Nickname: yoozd
Registered: May, 2003

reading code Posted: Dec 31, 2003 8:21 AM
Reply to this message Reply
Matsumoto's advice of reading code made me wonder: what would be well written code for, let's say, java and c++?
Any suggestions?

groetjes,
Joost

Peter Hickman

Posts: 41
Nickname: peterhi
Registered: Mar, 2003

Re: reading code Posted: Jan 1, 2004 4:17 PM
Reply to this message Reply
The same criteria applies to all languages. Reading the code should inform you what the code achieves without loosing you in the minueta(?) of the syntax.

A novice should be able to understand a masters code (and hopefully learn something in the process).

Well written code reduces the need to comment.

Importantly a Perl programmer should be able to read a Java program and understand what is going on (and v.v.).

If one Java programmer cannot understand another's program even though they have similar abilities then there is something seriously wrong. As a Perl programmer myself I can read Java programs and see what is going on if they are well written but cant write a decent Java program for toffee.

Here we are entering linguistics territory, something well expressed will be understood by more people than are capable of expressing it. You can read Milton but you probably couldn't write it.

So well written code should be understandable by programmers who lack the ability to write it.

Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: Matz on Craftsmanship Posted: Jan 1, 2004 11:00 PM
Reply to this message Reply
When I was in college, I spent a lot of time reading through the V7 Unix source code. This taught me alot about writing C code in the K&R style. I have continued, to use this style of programming for ages. One of the fundamental things that I learned there was that you should consistently use the same variable names in all methods that deal with some particular type of action. In K&R C (including 'the book' on C), you see uses of s and t for char * operations. Indexes are i, j, k in for loops, and p is used for a general pointer operation. This style of programming is prevalent in Fortran and other early programming languages when memory space was an extreme concern.

The primary thing for me is that concise variable names reduce the clutter of the code. If a variable is global, or of more distributed use, then give it a better name to help anyone reading the code to keep track of it. One of the benefits of Java is that the language has limited forms of expression so that you don't have to learn so much to be able to read it. The simplifying design decisions in Java includes single inheritance, as in Ruby. But, there are several others such as no operator overloading. These things make it much easier to read Java, and make it extremely more likely that you can understand the code in software you did not write.

In Java, anonymous inner classes can be easily defined to be used as blocks and closures. I define Comparator implementations for sorting all the time. So the sorting example is not a great difference between Java and Ruby programming. If I need a closure, then I define an interface to define how that closure works, and if I need a more rigorous implementation to subclass, then I create it. There is something to be said for the convenience of prototyping in languages such as Ruby. However, there is a lot to be gained from some extra rigor in the development cycle that will keep you from spending extra time tracking down type conflicts during testing of an enterprise sized application.

Joost de Vries

Posts: 19
Nickname: yoozd
Registered: May, 2003

Re: reading code Posted: Jan 3, 2004 8:36 AM
Reply to this message Reply
I now notice that my comment does not express my question very clearly. What I meant was:
What would be open-source code that's especially well designed, provides and example of the best code that the language has to offer.

Gregg proposes the V7 Unix source code. So that's one contestant for the language C.

I'd be interested in what java source code people would suggest for Java for example. I have done some digging in the source code of the JDK but I seem to remember I was not very impressed. Some open-source project maybe?

And since I'm considering improving on my C++ skills I'd also be interested in exemplary C++ source code. Qt? (I think that comes with source, doesn't it?)

Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: reading code Posted: Jan 4, 2004 12:01 AM
Reply to this message Reply
> I now notice that my comment does not express my
> question very clearly. What I meant was:

> What would be open-source code that's especially well
> designed, provides and example of the best code that the
> language has to offer.
>
> Gregg proposes the V7 Unix source code. So that's one
> contestant for the language C.

Joost, I think that you have to decide what you'd like to get out of the language verses out of the platform. Only Java has a true platform that includes an OS independent library of software. Some might argue that Posix provides a platform for C, but Posix is not available everywhere C is used or deployed.

Certainly, the Java platform has changed through versions. What I was suggesting about the V7 UNIX code (and of course it is not the first release of the code there in) is that it demonstrates a certain repeated programming paradigm that was created by a very small number of people with a very limited objective to accomplish.

The result is that it is very consistent in style, very thorough in what C was designed to do, and exemplary in its attention to the notion of simplicity in design. I will say that I'd place the Johnson C compiler into a different category though. I tried to convert it to use 32 char identifiers when I was in college and just could not find all the dependencies.

What we find in the Java source code is what happens when 100's of developers are given 1 hour to design, implement and test 1 feature each. Java has grown up at internet speed just like many other languages and packages that we have around today. This means that it suffers from not having a single architectural focus.

I'm going to put up a blog about this issue. It's an important issue to me.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: reading code Posted: Jan 4, 2004 2:50 PM
Reply to this message Reply
> Only Java has a true platform that includes an OS
> independent library of software.

That doesn't seem to be correct - guess it depends how you define 'true platform'.

Smalltalk has long provided a 'true platform' that includes an OS independent library of software.

> What I was suggesting about the V7 UNIX code ...
> is that it demonstrates a certain repeated programming
> paradigm that was created by a very small number of
> people with a very limited objective to accomplish.
>
> The result is that it is very consistent in style, very
> thorough in what C was designed to do, and exemplary in
> its attention to the notion of simplicity in design.

Smalltalk provides a very different example of consistency and simplicity: everything is an object, the only action is sending a message to an object, every message send has a result.

(Naturally such sweeping generalizations usually turn out to be not quite true: assignment in Smalltalk is not a message send, conditional statements are often optimized by the compiler to avoid the message send...)

Peter Hickman

Posts: 41
Nickname: peterhi
Registered: Mar, 2003

Re: reading code Posted: Jan 4, 2004 3:28 PM
Reply to this message Reply
> Only Java has a true platform that includes an OS
> independent library of software.

For some value of 'OS independent library'. By default Java based GUIs follow the Unix / Windows model and require special code to get things to work correctly under OS X.

If we take the GUI out of Java as a special case then Python, Ruby and Perl have plenty of OS independence.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: reading code Posted: Jan 4, 2004 4:07 PM
Reply to this message Reply
> > Only Java has a true platform that includes an OS
> > independent library of software.
>
> For some value of 'OS independent library'. By default
> Java based GUIs follow the Unix / Windows model and
> require special code to get things to work correctly
> under OS X.

Smalltalk on OS X

http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=b759pp%24q2f%241%40bob.news.rcn.net

> If we take the GUI out of Java as a special case then
> Python, Ruby and Perl have plenty of OS independence.

Cross-platform GUIs aren't a special case - this has long been provided by Smalltalk.

Peter Hickman

Posts: 41
Nickname: peterhi
Registered: Mar, 2003

Re: reading code Posted: Jan 5, 2004 9:11 AM
Reply to this message Reply
> Cross-platform GUIs aren't a special case - this has long
> been provided by Smalltalk.

I have no experience of the Cincom Smalltalk so I may yet be proven to be wrong but when I use a GUI based application on any platform I expect it to look and feel like a native application of that platform. Hence my comments of Java based GUIs by default looking like Windows / Unix in the Mac OS X environment. They are consistent as Java GUIs because they look the same (Windows / Unix) everywhere they are run. But that is not what I want, I want the application written in whatever language to look and feel right for that platform - without writing special code.

In this respect Smalltalk takes the Java route (taking Squeak as an example). It brings it's own interface style with it, so all Squeak programs are consistent regardless of platform that are run on but they do not match the look and feel of the host platform.

Possibly what I want is too much to ask for, or at least a great deal of work for little gain, but I would read 'Cross-platform GUI' to mean that the GUI code need not have a whole bunch of special cases and it will still behave like a native application.

Until then I will probably stick with Tcl/Tk.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: reading code Posted: Jan 5, 2004 12:12 PM
Reply to this message Reply
I have no experience of the Cincom Smalltalk so I may yet be proven to be wrong but when I use a GUI based application on any platform I expect it to look and feel like a native application of that platform.

Mis-informed rather than wrong ;-)

There are many Smalltalk implementations - don't judge Smalltalk by looking at Squeak.

IBM Smalltalk used an approach that re-appeared as Java SWT to provide cross-platform GUIs (native widgets or emulated widgets when not on the platform).

VisualWorks VW (Cincom) Smalltalk uses an approach that re-appeared as Java Swing to provide cross-platform GUIs (emulated widgets, although they are moving towards native widget support).

They long ago realized that their customers wanted platform LAF (Look and Feel) - so that's what they provide.


> In this respect Smalltalk takes the Java route (taking
> Squeak as an example). It brings it's own interface style
> with it, so all Squeak programs are consistent regardless
> of platform that are run on but they do not match the
> look and feel of the host platform.

That isn't true of other Smalltalk implementations.

I just started VW Smalltalk and switched from my native platform LAF (Windows) to MACOS X Aqua. (I doubt it's perfect but you should judge how good it is yourself.)


> 'Cross-platform GUI' to mean that the GUI code need not
> have a whole bunch of special cases and it will still
> behave like a native application.

For non-commercial use, you can simply download the latest VisualWorks and see for yourself:

http://www.cincom.com/scripts/smalltalk.dll/downloads/index.ssp?content=visualworks

best wishes, Isaac

Todd Blanchard

Posts: 316
Nickname: tblanchard
Registered: May, 2003

Portability Posted: Jan 5, 2004 12:54 PM
Reply to this message Reply
when I use a GUI based application on any platform I expect it to look and feel like a native application of that platform.

There are portable GUI libs for many platforms. wxWindows is becoming popular - provides native look and feel, and people are adding more and more language bindings to it. Python for example.

This enforces Matz's comment about learning lots of languages and environments. Far too many "developers" cast everything in terms of how its like or not like Java - as if Java were the ideal somehow. The reality is that Java is a collection of compromises - some good, many not so good, and a lot of it is more primitive that what came before.

Merriodoc Brandybuck

Posts: 225
Nickname: brandybuck
Registered: Mar, 2003

Re: Portability Posted: Jan 5, 2004 3:24 PM
Reply to this message Reply
> This enforces Matz's comment about learning lots of
> languages and environments. Far too many "developers"
> cast everything in terms of how its like or not like Java
> - as if Java were the ideal somehow. The reality is that
> Java is a collection of compromises - some good, many not
> so good, and a lot of it is more primitive that what came
> before.

I've found that Matz's recommendation to learn a language a year to be a good one. Like he (and the pragmatic programmers) says, it helps by exposing you to new ideas and new ways of thinking about problems. That's the real key for me. Depending on your point of view, any language can be viewed favorably or poorly. It all depends on your experience and your needs.

I've had some real world experience with java, C/C++, VB in its various flavors, C#, Python, awk, a touch of perl, javascript and even Pascal. In school I did some work with a few other languages like assembler and LISP, but nothing beyond the course work I had to do. They all have their good and bad points and as such, it's hard to read the 'my language is better than your language' shouting matches. They are almost meaningless unless you get a good description of the problem domain or if you are talking about a specific feature that is important to you like object orientedness, performance, ease of debugging or typing lots of parentheses.

I think that idea can be extended to learning different paradigms as well. For example, I've started to take an interest in AI and game programming after being away from it for many years (I really haven't done any AI stuff since school) and in looking at the stuff that is out there, it is light years ahead of where it was a few years ago and it is radically different than what I do now, which is enterprise application programming.

I was thinking one neat really off the wall project would be to do a small simulator like Weta's massive (not as big or detailed of course, I don't have 3-4 years to work on this thing), for input have it read in finanacial data from various sources, whether they be companies, divisions in a single company, etc. and then have that data create AI agents that fight each other. Thus you can do a 'my company can beat up your company' analysis and have a neat representation of it that would be pretty to look at. Companies/divisions that create a ton of revenue would have great offensive capabilities, those with low debt and solid cost controls would have great defensive capabilities, etc.

Anyway, instead of learning another language this year, I'll be exploring a programming paradigm that is almost completely foreign to me. It should be fun. Time to dust off that OpenGL book I haven't touched in 8 years ;-) Last time I touched that, I was working on a 3D charting engine that, alas, didn't get used by the company I was working for. Who wouldn't want a chart you could rotate in 3 dimensions and do fancy lighting on?

By the way, if anybody knows of any good resoures on the subject, I would be happy to hear about them. I've been looking at picking up Game Programming With Python and AI Game Programming Wisdom. If anybody has an opinion about those books or others, please share. As I said, this sort of thing is pretty foreign to me and these looked like the most comprehensive starting points I could find. They've gotten good reviews from a variety of sources.

I've got a pretty good OpenGL book and have worked with that a little bit, so I'm not too worried about the graphics end of things. I basically need a good primer on the sort of AI things the better strategy and RPG games do. Those books looked like they had that and more, and in a general enough sense where I wouldn't have information that was useless after, say, DirectX 9 was obsolete. I'm not interested in the platform specific stuff. I would like information that could be applied to a wide variety of problem domains and used as a base for working with a wide variety of languages, tools and development kits.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Portability Posted: Jan 5, 2004 6:58 PM
Reply to this message Reply
'my language is better than your language' shouting matches... almost meaningless
Always we need to ask: better for what purpose; better according to what criteria.

Anyway, instead of learning another language this year, I'll be exploring a programming paradigm that is almost completely foreign to me.
Be over-ambitious! Learn both a new language and a new domain!

There are all kinds of things in Mozart/Oz that would make things easier for multi-agent games
http://www.mozart-oz.org/

Or there's a game development environment for the pure functional language Clean - that would give some novel ideas about programming
http://www.cs.kun.nl/~clean/About_Clean/Platform_Games/platform_games.htm

any good resoures on the subject
Rules of Play: Game Design Fundamentals
http://mitpress.mit.edu/catalog/item/default.asp?ttype=2&tid=9802

Merriodoc Brandybuck

Posts: 225
Nickname: brandybuck
Registered: Mar, 2003

Re: Portability Posted: Jan 5, 2004 8:05 PM
Reply to this message Reply
> 'my language is better than your language' shouting
> matches... almost meaningless

> Always we need to ask: better for what purpose; better
> according to what criteria.

I agree, which is why the 'unless' clause is in there. I like Python. I don't love it like, for example, Bruce Eckel does. Much as I respect the man, I don't find myself 10 times as productive in Python as I do other languages. Perhaps it's because I don't use it enough or maybe I'm just not that bright.

> Anyway, instead of learning another language this year,
> I'll be exploring a programming paradigm that is almost
> completely foreign to me.

> Be over-ambitious! Learn both a new language and a new
> domain!

I have two very young kids at home. I've tried over-ambitious several times recently and, well, the 'over' is the most appropriate part of the phrase ;-)

> There are all kinds of things in Mozart/Oz that would make
> things easier for multi-agent games
> http://www.mozart-oz.org/
>
> Or there's a game development environment for the pure
> functional language Clean - that would give some novel
> ideas about programming
> http://www.cs.kun.nl/~clean/About_Clean/Platform_Games/plat
> form_games.htm
>
> any good resoures on the subject
> Rules of Play: Game Design Fundamentals
> http://mitpress.mit.edu/catalog/item/default.asp?ttype=2&ti
> d=9802


Thanks for the links. I'll check 'em out.

Flat View: This topic has 16 replies on 2 pages [ 1  2 | » ]
Topic: CLR Design Choices Previous Topic   Next Topic Topic: To Plan or Not to Plan


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us