Portrait of a Noob

Discussions

News: Portrait of a Noob

  1. Portrait of a Noob (35 messages)

    Steve Yegge's Portrait of a Noob provides an interesting analysis of how meta-data has crept into many aspects of programming and data modeling, with an insightful discussion about the abuses of meta-data present in many current frameworks and applications written in Java. Steve begins by describing how beginning programmers striving to do the right thing tend to over-document every aspect of the program, almost to the line level. In the next phase, after programmers have two or three years of experience, is a "teenage stage" in which the programmer is 50/50 likely to produce a pile of crap or a work of genius. This poses a problem for organizations since they are likely to combine noobs and veterans under the same roof, and both need to be able to understand one another:
    Hopefully the scene I've painted so far helps you understand why sometimes you look at code and you just hate it immediately. If you're a n00b, you'll look at experienced code and say it's impenetrable, undisciplined crap written by someone who never learned the essentials of modern software engineering. If you're a veteran, you'll look at n00b code and say it's over-commented, ornamental fluff that an intern could have written in a single night of heavy drinking.
    This discussion soon moves to comments as meta-data, and the abuses of meta-data that many Java programmers are guilty of. Steve argues that meta-data features like annotations, coupled with strong typing, result in noobish code that obfuscates the actual code and makes applications unnecessarily complex for the sake of explaining what would be otherwise obvious by looking at the implementation code.
    I think that by far the biggest reason that C++ and Java are the predominant industry languages today, as opposed to dynamic languages like Perl/Python/Ruby or academic languages like Modula-3/SML/Haskell, is that C++ and Java cater to both secure and insecure programmers. . . . Similarly, you can write Java code more or less like straight C, and a lot of seasoned programmers do. It's a little nicer than C because it has object-orientation built in, but that's fairly orthogonal to the static type system. You don't need static types for OOP: in fact OOP was born and proven in dynamic languages like Smalltalk and Lisp long before it was picked up by the static-type camps. The important elements of OOP are syntax (and even that's optional) and an object model implemented in the runtime. . . . Java has been overrun by metadata-addicted n00bs. You can't go to a bookstore or visit a forum or (at some companies) even go to the bathroom without hearing from them. You can't actually model everything; it's formally impossible and pragmatically a dead-end. But they try. And they tell their peers (just like our metadata-addicted logical data modelers) that you have to model everything or you're a Bad Citizen.
    This discussion leads at how the excess of meta-data written in XML support files, annotations, or other means comes to hinder a project and make it brittle, leading to its own demise. Steve quotes Struts and WebWork as examples of this trend. The extra verbosity, the need to model everything, the framework itself becomes a hindrance to the project, forcing developers to focus more time on dealing with the framework than on solving implementation issues. This, in turn, is the result of noobish programming style: model everything and otherwise create a mountain of meta-data:
    Java programmers, and logical data modelers, and other metadata-addicted developers, are burying us with their "comments" in the form of models within their static type system. Just like I did when I was a n00b. But they're doing it with the best of intentions, and they're young and eager and energetic, and they stand on street corners and hand you leaflets about how great it is to model everything. Seasoned programmers ignore them and just get it done.
    Steve proposes a few simple solutions, obvious to seasoned programmers. These same solutions are likely to horrify the noob or teenage-stage developer:
    • Let the code speak for itself - don't model everything!
    • When in doubt, don't model it; write the implementation and see if a model emerges from it
    • Create models for public-facing APIs, where they are necessary
    Like most things in computer-related topics, it seems that Steve's thesis can be summarize as many other things in computer-related topics: don't abuse your features. Don't treat every development project like a nail just because the only tool you understand (or are comfortable with) is a hammer.

    Threaded Messages (35)

  2. Insightful!? Come on![ Go to top ]

    Steve is talking more about types, not XML. Insanity. Yeah, I'd love to maintain code which dumps a bunch of heterogeneous objects into maps of lists instead of just using a couple classes. Give me a break. Did you really write well commented code as a newb? I'm guessing not. You wrote dense piles of crap like Steve claims to write today because you didn't care about maintainability. I'm starting to wonder if he's actually conducting a giant social experiment to see how many people he can trick into using scripting languages.
  3. Also...[ Go to top ]

    Struts 1/2 and WebWork 1/2 don't disprove static types. Those frameworks were all designed long before Java 1.5, back when static type checking in Java was pretty much useless, and as a result, they throw it out the window.
  4. Re: Also...[ Go to top ]

    Agree with Bob. Maybe there are a few beginners who overly comment their code, but I'm guessing that once the code they produce is not part of their homework, they tend to undercomment, like a lot of people. I would certainly not say that overcommenting usually indicates that the code was written by a junior developer. Now, if someone could summarize Steve's article in a few paragraphs, I'd be happy to comment more on it :-) -- Cedric
  5. Overly commented code.[ Go to top ]

    His example of code comments was hyperbole, obviously. He is not trying to say beginners are masters of good commenting, anymore than 2 year olds are master story tellers. I think we've all seen code like: // clear the screen ClrScrn(); // Move cursor to 10, 0 MoveTo(10, 0); // And write message PrintLn(outputMessage); That is what he's referring to.
  6. Re: Also...[ Go to top ]

    Now, if someone could summarize Steve's article in a few paragraphs, I'd be happy to comment more on it :-)
    I would just jump straight to the comments--very insightful. Bob
  7. Re: Also...[ Go to top ]

    actually no. what you mentioned are useless and vague comments more like pseudo code on top of the code! what i think he meant, is that sometimes overcomment, like how kids over detail everything, for example: And adult will say, we travel to alexandria a kid will say we took the car, dady opened the door to mommy, mommy smiled at daddy, etc..etc.., then moody picked my nose, then i cried, them momy yelled at moody, moody is my brother, then we went down the car, and momy put me in swimming pool then we swam, then daddy said to mommy he loves alexandria in summary, the closet road between two point is a straight line, noobs draw circles, experts draw the line surpisingly considering the size of his post, well .. definitely not a straight line
  8. Is he talking about the many Java frameworks out there that abuse the use of XML and/or Annotations? If yes I agree 100% with him...
  9. Re: Also...[ Go to top ]

    Now, if someone could summarize Steve's article in a few paragraphs, I'd be happy to comment more on it :-)

    --
    Cedric
    Hi Cedric, I didn't read it all, but read enough to get the gist and come up with a summary.
    One very real technical problem with the forced-modeling approaches that static type systems are often "wrong". It may be hard to imagine, because by a certain definition they can't be "wrong": the code (or data) is programmatically checked to conform to whatever constraints are imposed by the type system. So the code or data always matches the type model. But the type system is "wrong" whenever it cannot match the intended computational model. Every time want to use multiple inheritance or mixins in Java's type system, Java is "wrong", because it can't do what you want. You have to take the most natural design and corrupt it to fit Java's view of the world.
    Manifest types are one form of meta data. There to make your program error free (with the help of the compiler). The problem is what happens when the type system doesn't allow you to express what you want? Either you: A) Model the propblem in a unatural way that fits in with your type system (compiler). B) Use a language with a more expressive type system (e.g. Scala), in the hope that it will allow you to express what you want. C) Drop the "training wheels" and use a language that lets you write exactly what you mean. As a example, say that you have a situation where a method should return a value which could be one of several allowed types (a situation can occur in the real world you hope to model). You can go off and define a marker Interface and ensure that the types you return "implement" this Interface say with Java. I believe Scala allows you to declare that your method can return one of a number of types (TypeA | TypeB) so no need for the Interface. Or with a language like python you could just go ahead and return what you want. No need to try and coerce the type system into accepting that you know what you are doing. This is a contrived example, but this type of thing happens more often then you think. Interestingly he mentions C, which allows you to do more or less what ever you like, even though it has manifest types. The downside of C of course is it doesn't offer the dynamic type safety like Java or Python. So your program can blow-up at runtime and it is very difficult to find out why. Paul.
  10. Re: Also...[ Go to top ]

    One very real technical problem with the forced-modeling approaches that static type systems are often "wrong". It may be hard to imagine, because by a certain definition they can't be "wrong": the code (or data) is programmatically checked to conform to whatever constraints are imposed by the type system. So the code or data always matches the type model. But the type system is "wrong" whenever it cannot match the intended computational model. Every time want to use multiple inheritance or mixins in Java's type system, Java is "wrong", because it can't do what you want. You have to take the most natural design and corrupt it to fit Java's view of the world.
    He says it as if dynamic languages didn't have a type system. Like they often say, those languages are strong, dynamically typed, not 'untyped'. So, if you want to code something that doesn't fit their type system and computation model, they will also be 'wrong'. You are still constrained by its syntax rules. Or does all dynamic languages support multiple inheritance and mixins (and every feature you will ever want to use), and is it impossible to a static languages to have them?
  11. Re: Also...[ Go to top ]

    One very real technical problem with the forced-modeling approaches that static type systems are often "wrong". It may be hard to imagine, because by a certain definition they can't be "wrong": the code (or data) is programmatically checked to conform to whatever constraints are imposed by the type system. So the code or data always matches the type model. But the type system is "wrong" whenever it cannot match the intended computational model. Every time want to use multiple inheritance or mixins in Java's type system, Java is "wrong", because it can't do what you want. You have to take the most natural design and corrupt it to fit Java's view of the world.


    He says it as if dynamic languages didn't have a type system. Like they often say, those languages are strong, dynamically typed, not 'untyped'. So, if you want to code something that doesn't fit their type system and computation model, they will also be 'wrong'. You are still constrained by its syntax rules. Or does all dynamic languages support multiple inheritance and mixins (and every feature you will ever want to use), and is it impossible to a static languages to have them?
    Hi Ronald, You sort of answer your own question. The computational model Steve speaks of is a runtime model not a static "code on the page" model. There isn't that much a compiler can infer from static text on a page. It cannot tell how your code will actually behave at runtime and whether that behaviour is legitimate or not. So it takes the "safe" approach and if in doubt it says "you are wrong", when it fact "it may be wrong". In languages were the type system operates at runtime (dynamic), and where the programmers intent is maintained in the runtime code and not compiled out, then the runtime is in a much better position to decide whether what you are trying to do is legitimate or not. The only things you shouldn't be allowed to do is access memory not allocated to you. Place the wrong type of value into a memory location designed to hold a different type, or send a message to an object which does not understand that message. Beyond that everything else is legitimate and type safe. Paul.
  12. Re: Also...[ Go to top ]

    The only things you shouldn't be allowed to do is access memory not allocated to you. Place the wrong type of value into a memory location designed to hold a different type, or send a message to an object which does not understand that message. Beyond that everything else is legitimate and type safe.
    I think that's an extremely loose definition of type safety and completely disregards the mathematical underpinnings of strong type systems.
  13. Re: Also...[ Go to top ]

    The only things you shouldn't be allowed to do is access memory not allocated to you. Place the wrong type of value into a memory location designed to hold a different type, or send a message to an object which does not understand that message.

    Beyond that everything else is legitimate and type safe.


    I think that's an extremely loose definition of type safety and completely disregards the mathematical underpinnings of strong type systems.
    Hi Erik, This is precisely what type safety means. The confusion arises with regards to what you are talking about. If you say that your language is type safe, then the above definition is accurate. At runtime your language does not allow type errors to occur. If you say that your program is type safe then you are saying at compile time that your program does not contain code that will lead to type errors at runtime, this s a static analysis and requires static type safety. Incidentally there is no language out there that is 100% statically type safe. See this link: http://c2.com/cgi-bin/wiki?TypeSafe Paul.
  14. Re: Also...[ Go to top ]

    From the type-safety definition from c2:
    A more general definition is that no operation will be applied to a variable of a wrong type.
    From Paul Beckford:
    The only things you shouldn't be allowed to do is ... send a message to an object which does not understand that message.
    Your definition is looser because it focuses solely on structure and narrower because it is limited to OO languages.
    If you say that your language is type safe, then the above definition is accurate.
    Yes, it is accurate, because it describes a subset of the safety a strong type system can provide within the context of object-oriented languages.
    Incidentally there is no language out there that is 100% statically type safe.
    Yes, the good old halting problem, but it is both possible and practical to get much, much closer to 100% type-safe than simple structural typing.
  15. Re: Also...[ Go to top ]

    Hi Erik, Take a closer look at the c2 wiki definition. Type safety has to do with safe memory access. Strongly typed is different from statically typing. A language can be both statically typed and weakly typed at the same time. Dynamically typed languages are generally strongly typed. The difference is that the type checking occurs at runtime and type errors are trapped by the language runtime not the compiler. Paul.
  16. Type safety confusion[ Go to top ]

    Hi Erik, This quadrant spells it out in black and white: http://c2.com/cgi-bin/wiki?TypingQuadrant It is referred to from the previous link I posted. Paul.
  17. Re: Also...[ Go to top ]

    From c2 article:
    Any variable with a declared type will always reference an object of either that type or a subtype of that type. A more general definition is that no operation will be applied to a variable of a wrong type. There are additionally two flavors of type safety: static and dynamic. If you say that a program is type safe, then you are commenting on static type safety. That is, the program will not have type errors when it runs. You can also say that a language or language implementation is type safe, which is a comment on dynamic type safety. Such a language or implementation will halt before attempting any invalid operation. Some languages make certain guarantees on type safety. If the language interpreter must make some type-assumptions that can be violated by a programmer, the safety guarantee is called 'weak'... e.g. C++ is weakly typed because it assumes that C-style cast and reinterpret_cast operations are correct (the prototypical example being casting from a 'void*'). Conversely, if the type system can make inviolable guarantees, it is called 'strong'. See also TypingQuadrant and StronglyTypedWithoutLoopholes for more on the subject. TypeSafe is different from TypeChecking, which is a process (not a property). TypeChecking, however, is often a necessary step in providing any guarantee of type safety. Note that actual identification of types (e.g. via TypeInference) is not necessary to provide a guarantee of TypeSafety. This is relevant because some type systems lack a notion of 'most specific type' or are otherwise undecidable. Guaranteeing TypeSafety requires proving that certain relationships hold between expressions and operations, which is an easier problem than deciding on actual type.
    Where does it say anything about memory access?
    Strongly typed is different from statically typing. A language can be both statically typed and weakly typed at the same time.
    Very true. I don't think I said anything to the contrary. Suggested reading: http://cdsmith.twu.net/types.html
  18. Re: Also...[ Go to top ]


    Where does it say anything about memory access?
    It doesn't. I said that.
    Strongly typed is different from statically typing. A language can be both statically typed and weakly typed at the same time.


    Very true.
    Good so we are in agreement :) What do you think about Steves article? Paul.
  19. Hey Paul and Erik[ Go to top ]

    Wtf guys? Are you really going to sit here and go back and forth in a 200 reply thread again? It's so f-ing annoying... n00bs ..=p

    Where does it say anything about memory access?


    It doesn't. I said that.

    Strongly typed is different from statically typing. A language can be both statically typed and weakly typed at the same time.


    Very true.


    Good so we are in agreement :) What do you think about Steves article?

    Paul.
  20. Re: Also...[ Go to top ]

    Good so we are in agreement :) What do you think about Steves article?
    I thought he has some interesting insights that he overextended to draw his conclusions. Noob commenting - Steve can send those noobs that write too many comments my way, and I'll see about sending him some that don't write any at all. However, I agree with his point about wanting the whole algorithm on the screen at once. Modelling - I think it depends on what you're trying to do, and how well you have the problem defined. Fresh grads do tend to over-engineer, but I would consider what Steve was advocating under-engineering and probably worse. Dynamic typing - it has it's place. I'm finding that I REALLY like Scala's advanced type system, but that's just personal projects. Work is still Java and Python.
  21. Re: Also...[ Go to top ]

    Hi Paul. I thought you might pop in on this thread...
    The problem is what happens when the type system doesn't allow you to express what you want?
    I'd really like to see an example, because in my experience, failing to express something in a language is usually more a failure of the developer than of the language. With some practice, everything can be expressed with a language, and I hear that there are even programs written in Lisp that can attest to that.
    As a example, say that you have a situation where a method should return a value which could be one of several allowed types (a situation can occur in the real world you hope to model). You can go off and define a marker Interface and ensure that the types you return "implement" this Interface say with Java. I believe Scala allows you to declare that your method can return one of a number of types (TypeA | TypeB) so no need for the Interface. Or with a language like python you could just go ahead and return what you want. No need to try and coerce the type system into accepting that you know what you are doing.

    This is a contrived example,
    Actually, I think this is a pretty good example, thanks for providing it. I agree that returning tuples (and you're right, Scala lets you do that) seems to be the more natural thing to do, but in the long run, it will hurt you the same way as returning a void* would. Whether it's for human or compiler reasons, I think that (String, int) is a lot harder to read than Person(name, age) and also much more problematic to maintain.
    but this type of thing happens more often then you think. Interestingly he mentions C, which allows you to do more or less what ever you like, even though it has manifest types. The downside of C of course is it doesn't offer the dynamic type safety like Java or Python. So your program can blow-up at runtime and it is very difficult to find out why..
    Dynamically typed languages have the same problem, although they admittedly make it easier for you to find the cause (which is not exactly helpful when the failure is happening at a client site). -- Cedric
  22. Re: Also...[ Go to top ]

    Hi Paul. I thought you might pop in on this thread...

    The problem is what happens when the type system doesn't allow you to express what you want?

    I'd really like to see an example, because in my experience, failing to express something in a language is usually more a failure of the developer than of the language.

    With some practice, everything can be expressed with a language, and I hear that there are even programs written in Lisp that can attest to that.

    Don't knock Lisp :) Some would argue that Lisp is the most expressive of the lot. In Lisp the computational model is totally unconstrained allowing you to do what ever you like including writing your own compiler and adding new control structures to you language through macros. I'm sure Steve Yegge would probably say the same since he invented Scheme. But those brackets do take a little getting use to :)

    Actually, I think this is a pretty good example, thanks for providing it.

    I agree that returning tuples (and you're right, Scala lets you do that) seems to be the more natural thing to do, but in the long run, it will hurt you the same way as returning a void* would. Whether it's for human or compiler reasons, I think that (String, int) is a lot harder to read than Person(name, age) and also much more problematic to maintain.
    The interesting thing about Steves article is that his views have changed over time. I think it is a bit like beauty, it is in the eyes of the beholder, and the type of girl you would have gone for in your youth isn't the type of women who would be interested in now. I don't think either approach is right or wrong or more or less maintainable "intrinsically". I think it comes down to who is doing the the programming and the maintaining. The programmer is the one with the intelligence at the end of the day, and it is the programmer who breaths life into the program. I think language choice is more of a people issue then a technical one. Which is why I believe choice is a good thing. We have more "mainstream" language choices today then we have had in in the recent past which has got to be good. BTW Person(String, Int) can be expressed as Person :name => 'Paul', :age => 40 In Ruby. Smalltalk does even better: Person name: 'Paul' age: 40. And you declare the object intialiser (constructor) Person>>initialize name: aString age: anInteger"
    Dynamically typed languages have the same problem, although they admittedly make it easier for you to find the cause (which is not exactly helpful when the failure is happening at a client site).

    --
    Cedric
    Agreed, which is why it is even more important that you write unit tests. As you know I would argue that you should be writing tests anyway. Paul.
  23. Re: Also...[ Go to top ]

    I'm sure Steve Yegge would probably say the same since he invented Scheme.
    Don't tell that to Guy Steele and Gerald Sussman.
  24. Re: Also...[ Go to top ]

    I'm sure Steve Yegge would probably say the same since he invented Scheme.


    Don't tell that to Guy Steele and Gerald Sussman.
    Is Guy Steele the Scheme guy? Thanks for the correction. Paul.
  25. Re: Also...[ Go to top ]

    Regarding (String, int) vs. Person(name, age): this is more of a difference between structural and nominal types, rather than dynamic and static typing, as explained in the fine document that Erik provided earlier. And while Java (my bread and butter) only deals with nominal types, I had a warm feeling about structural types while reading about JavaScript 2 / ECMAScript 4 that has both.
  26. Re: Also...[ Go to top ]

    I'd really like to see an example, because in my experience, failing to express something in a language is usually more a failure of the developer than of the language.
    I disagree. I would say a failure to produce working code that implements the specified functionality is a failure of the developer. Some languages are like one-way hash functions from problem domain to design (data structures, algorithms, etc) to code.
  27. Hi Paul. I thought you might pop in on this thread...

    The problem is what happens when the type system doesn't allow you to express what you want?

    I'd really like to see an example, because in my experience, failing to express something in a language is usually more a failure of the developer than of the language.
    A trivial one for Java: java.util.Collections.sort(list, comparator) does not express that sort is a method on Collection - which it should be, as it is (A) standard for all collections, and (B) modify the internal state of the collection. The present location is a contortion done due to the type system. Specifically it is due to interface being a weak abstraction, forcing people to work around the lack of implementation inheritance by using procedures ("static methods") for what should be (object) methods. Eivind.
  28. Re: Insightful!? Come on![ Go to top ]

    Hi Bob!
    Did you really write well commented code as a newb? I'm guessing not. You wrote dense piles of crap like Steve claims to write today because you didn't care about maintainability
    I found a listing of code that I produced for a project I sold in 1986 or so. The coding began in 1985, when I'd been programming for roughly two years. I was right at the beginning of what Steve calls "teenage years"... Ah, those were the days... Cheers! E The Tesla Testament Like a cross between Indiana Jones and James Bond ISBN: 1-4116-7317-4 - BISAC: FIC031000
  29. Re: Portrait of a Noob[ Go to top ]

    Whatever the point is one tries to prove, it always works great to divide the population between people who get it and who don't, seasoned or noob, smart or moron, teenager or grown-up. That way you can point to people with other ideas and call them names and feel good about yourself.
  30. Re: Portrait of a Noob[ Go to top ]

    For instance, as just one random illustrative example, you might need to return 2 values from a function in Java (a language with no direct support for multiple return values). Should you model it as a MyFunctionCallResult class with named ValueOne and ValueTwo fields (presumably with actual names appropriate to the problem at hand)? Or should you just return a 2-element array (possibly of mixed types) and have the caller unpack it? I think the general answer to this is: when in doubt, don't model it
    One can only hope this is someone's sick idea of a joke
  31. Re: Portrait of a Noob[ Go to top ]


    For instance, as just one random illustrative example, you might need to return 2 values from a function in Java (a language with no direct support for multiple return values). Should you model it as a MyFunctionCallResult class with named ValueOne and ValueTwo fields (presumably with actual names appropriate to the problem at hand)? Or should you just return a 2-element array (possibly of mixed types) and have the caller unpack it?

    I think the general answer to this is: when in doubt, don't model it


    One can only hope this is someone's sick idea of a joke
    There actually is something to what he's saying, it's just that what he's advocating would produce chaos. Creating a new class every time one wants to return a pair or triple (or, more generally, an n-tuple) is rather stupid. But with appropriate language support you can have a nice statically typed n-tuple without any overhead. Let's say you want to implement a divmod method in Scala: Steve's way: def divmod(dividend: Int, divisor: Int) = { val result = new Array[Int](2) result(0) = dividend / divisor result(1) = divident % divisor result } The inferred return type is Array[Int]. You could use Array[Any] instead if you needed heterogenous objects. Better way: def divmod(dividend: Int, divisor: Int) = (dividend / divisor, divident % divisor) The (inferred) result type here is Tuple2[Int, Int]. So a little type inference and a little syntactic sugar make the function almost a concise as the dynamically typed equivalent: Python: def divmod(dividend, divisor): return (dividend / divisor, dividend % divisor) Again here I'm using Python's tuple type instead of an array or list.
  32. With limited tools use workarounds[ Go to top ]

    With Java returning multiple values is not supported directly. One workaround is to go to the effort of creating a class. Another is to use an array. The array is more simpler and more succinct. The class is more expressive. The is one best approach. The is one set of future maintenance that a code base will face. The right answer it the solution that minimizes the cost of the initial construction and that future maintenance. There is no simple way to get best approach. One thing worth trying is to give the code to a member of the target maintenance group for review and see what issues they have. Different people need different amounts of comment, and expressions of ideas. More expressive languages can reduce the bulk expressiveness takes. However they might be more complex to use or implement. Whatever the tools, expressing ideas and abstractions involves some complexity and bulk. Ideas and abstractions themselves have bulk. The Scala solutions for divMod presented here look like junk compared to what you can do in Oz. As a language feature how about something like: def divMod dividend divisor: return Quotient: dividend / divisor Modulas: dividend % divisor Quotient: q Modulas: m = divMod 11 3 print q m # 3 2 aQm = divMod 13 4 for v in aQm: print value # 3 then 1
  33. SteveY's premise is that noobs write too many comments (which he calls metadata), noobs love to use static typing (which he also calls a kind of metadata), therefore, seasoned programmers avoid both by using dynamic scripting languages. Wow, that's a leap! The logic is flawed and the article is mostly hyperbole intended to rationalize why seasoned programmers have moved beyond Java and C++ to dynamic languages: "Perl, Python and Ruby fail to attract many Java and C++ programmers because, well, they force you to get stuff done." Ouch. Its hard to even take his recommendations seriously after that one.
  34. Re: Portrait of a Noob[ Go to top ]

    If code was difficult to write, it should be difficult to understand...right? I read the blog, and not sure what the point is really, but couple of things. 1. Sometimes when I find I need to write lots of comments around code its a sign I need to refactor. 2. These days, I'm usually focusing more on splitting a project up into the best separation of modules, based on my understanding of the core domain and sub domains, ala what the Domain Driven Design book tends to explain well. I'm also trying to apply something like approaches in Martin Fowler's refactoring book (or similar books) to my code. The blog doesn't seem (?) to touch on any of this.
    Should a team write for the least common denominator?
    You should probably write the best code you know how to, and experienced people can mentor the newbs, and teach them about different approaches to refactoring/code organisation.
  35. Definition of a Recent Noob[ Go to top ]

    A "recent noob" is someone who wants to label other people "noobs". (I'm still a noob, so in a few years I might start calling other people noobs.) Peace, Cameron Purdy Oracle Coherence: The Java Data Grid
  36. A missed post.[ Go to top ]

    Hi. I’m very sorry to miss this post, it is so rich to comment on. Anyway, one month later, I still want to post a comment. I will actually expand the post in my blog. First, let’s summarize Steve’s post: 1.Comments are metadata. Metadata is of no use for the compiler, so it can be get rid of. 2.Noobs are comment obsessed creatures, thus metadata enthusiastics. 3.Modeling is a way to comment intention of code in code language itself. So modeling a metadata creation process. 4.Teenagers are obsessive modelers. 5.Classes and in general OO, are metadata in code itself. 6.Static typing is also metadata since the real thing is memory afterwards. 7.Seasoned Programmer is one enlighten creature that does not use metadata, and thus can see the real thing when coding, not ethereal domain models. What do I agree with: Metadata is useless for the compiler. True. Modeling is a metadata creation process. True. What do I disagree with: Metadata (at least not all) is not useless. Metadata is important, although not for the compiler. Lack of metadata does not mean better code. Here we talk about two very different issues: Code quality and the actual coding process. One may affect the other. A good coding process should help produce healthy and good code quality. Any code with or without the comments will execute the same, good or bad. So comments may not add quality per se. But, adding comment may affect (and improve) the coding process. Now, here are my definitions: Coding: Process of describing the solution using a specific language or set of languages. Language: Set of words (verbs, nouns) and grammar, used to create describing sentences. Coding Level: Abstraction level at which the solution is described. Compiler: Entity that will convert a solution description down into another description in another language (usually a more detailed one). So, for all of you that think that your Java lines of code actually execute, sorry to tell you that is not true. Those lines will be converted into bytecode. And that is another language that will not execute either. It will be converted again into (probably C) calls to the Operating system at hand. And those to assembler codes, to binary codes and then to electric impulses. Lots of compilers, huh? Well, for each compiler of Level X(n), the language of compiler X(n-1) is a level higher, and contains sentences that entities of that level can understand. And for X(n) those are just a less detailed solution. Since the sentences are actually the same solution, I may say X(n-1) is just a modeled solution for X(n-1) entities, and thus metadata for X(n). So, metadata is not a useless waste of characters, it is simply of use for other entities that are not the compiler at hand (Junit 4 and TestNG are proof of that). If you fail to see that, is because you are looking at your compiler level, with your actual language rules. Thus, for me, a NOOb is when you go out the street and start walking, knowing your block (you talk too much about all that is in your block). Teenage is when you have a car and star driving to know your city (you talk about love and other things, not much about your block). Seasoned programmer is when, using a SUV, you start climbing mountains and going out to wild lands and foreign countries (you start talking other languages). You become an analyst when you drop your car and start studying the world by TV and news channels, and fly around in helicopters and planes (you now talk politics, business). You end up being a senior ancient, when you take your ticket to the space station, and see the whole world at a glance, and start talking about future. I will blog more on this. Very interesting. William Martinez Pomares