<?xml version="1.0" encoding="UTF-8" ?>
<rss version="2.0" xmlns:s="http://www.techrepublic.com/search" xmlns:dc="http://purl.org/dc/elements/1.1/"  xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
    <title><![CDATA[Discussion on What are your top five programming languages? ]]></title>
    <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-247965]]></link>
    <atom:link rel="hub" type="application/rss+xml" href="http://pubsubhubbub.appspot.com/" />
    <atom:link rel="self" type="application/rss+xml" href="http://www.techrepublic.com/forum/discussions/102-247965/rss" />

    <description><![CDATA[]]></description>
    <language>en-us</language>
    <lastBuildDate>2013-05-19T17:11:25-07:00</lastBuildDate>
             

    <item>
        <title><![CDATA[My five]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-247965-3524438]]></link>
        <description><![CDATA[1, Python2. C++3. C4. Basic5. SQLCut my teeth on Basic, moved to C, then C++ and now favor Python.  Use SQL when necessary.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-247965-3524438]]></guid>
        <dc:creator><![CDATA[drednot57]]></dc:creator>
        <pubDate>Tue, 22 Nov 2011 10:04:41 -0800</pubDate>
    </item>
             

    <item>
        <title><![CDATA[You poor soul]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-247965-2615407]]></link>
        <description><![CDATA[But how is the COBOL business these days?  I hear there's plenty of demand.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-247965-2615407]]></guid>
        <dc:creator><![CDATA[Sterling "chip" Camden]]></dc:creator>
        <pubDate>Sat, 11 Oct 2008 15:08:57 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[a matter of scale]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-247965-2614708]]></link>
        <description><![CDATA[I think we may be speaking at cross-purposes.On a line-by-line basis, what you say is probably true of COBOL in general.  How well can you achieve paradigm shifts between different levels of abstraction, to think about the logic flow of an entire program, though?  The same thing that requires a lot of search and replace to make minor changes also interferes with the ability to reason through program flow from one end to the other without having to draw out a flowchart for each level of abstraction you want to consider.At least, that's my experience with languages like that.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-247965-2614708]]></guid>
        <dc:creator><![CDATA[apotheon]]></dc:creator>
        <pubDate>Fri, 10 Oct 2008 11:26:47 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[Hmmm]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-247965-2614696]]></link>
        <description><![CDATA[Mainframe sideCobolJCL I know it's not &quot;really&quot; a language but..Client PC sideC#VBJava]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-247965-2614696]]></guid>
        <dc:creator><![CDATA[LarryD4]]></dc:creator>
        <pubDate>Fri, 10 Oct 2008 10:59:21 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[In all fairness...]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-247965-2614656]]></link>
        <description><![CDATA[... it's been 25 years since I wrote my last line of COBOL code , so some of the innovations introduced by MicroFocus and others may make it a less repetitious process than it was back then.But in my projects at that time (which were numerous), there really wasn't anything to figure out about the code.  It was dead simple.  But if you needed to change anything, you'd better have an editor that does search and replace well (and that was on a system that didn't have a regex-capable editor).]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-247965-2614656]]></guid>
        <dc:creator><![CDATA[Sterling "chip" Camden]]></dc:creator>
        <pubDate>Fri, 10 Oct 2008 10:26:49 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[yes and no]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-247965-2613894]]></link>
        <description><![CDATA[If you start repeating yourself that much and bending over backwards to make each statement as clear as possible, you achieve exactly the same results I just described.  In COBOL, you're damned if you do, and damned if you don't.  Either the problem is that short chunks of code are kinda difficult to read because they're overly verbose and repetitious themselves, or the problem is that the whole program is kinda difficult to read because it's so verbose and repetitious that it's difficult to fit much of it in your head all at once.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-247965-2613894]]></guid>
        <dc:creator><![CDATA[apotheon]]></dc:creator>
        <pubDate>Thu, 09 Oct 2008 11:50:11 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[If done well...]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-247965-2613830]]></link>
        <description><![CDATA[COBOL can be made to read very clearly.  However, it often involves a lot of near repetition.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-247965-2613830]]></guid>
        <dc:creator><![CDATA[Sterling "chip" Camden]]></dc:creator>
        <pubDate>Thu, 09 Oct 2008 10:04:08 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[I disagree.]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-247965-2613045]]></link>
        <description><![CDATA[To me, COBOL looks more like the language in the GPL -- tortured, overly verbose, unnatural constructions that tend to result in unintended consequences.  Sure, I can read it -- but anything longer than a couple paragraphs is fraught with peril, and writing it is an exercise in masochism.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-247965-2613045]]></guid>
        <dc:creator><![CDATA[apotheon]]></dc:creator>
        <pubDate>Wed, 08 Oct 2008 12:20:46 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[Yes, it's very readable]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-247965-2612876]]></link>
        <description><![CDATA[much the same way that children's books are.  But it isn't very expressive.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-247965-2612876]]></guid>
        <dc:creator><![CDATA[Sterling "chip" Camden]]></dc:creator>
        <pubDate>Wed, 08 Oct 2008 09:48:17 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[COBOL Rules]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-247965-2612192]]></link>
        <description><![CDATA[At least COBOL is readable and self-documenting which is hardly the case with the alphabet soup OOP related languages.  We can all thank the lovely, witty and pioneering Admiral Grace Hopper crew for a very powerful ?common language? still in use to this day; otherwise programming would?ve been for the very select binary brainiacs.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-247965-2612192]]></guid>
        <dc:creator><![CDATA[psiegmun@...]]></dc:creator>
        <pubDate>Tue, 07 Oct 2008 15:50:49 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[I was kinda disappointed...]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-247965-2400964]]></link>
        <description><![CDATA[... that this thread didn't bring the flaming Pythonistas out of the woodwork.  Oh well.Hey, thanks to everyone who contributed to this conversation -- most comments yet on any post on this blog!]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-247965-2400964]]></guid>
        <dc:creator><![CDATA[Sterling "chip" Camden]]></dc:creator>
        <pubDate>Fri, 11 Jan 2008 14:50:25 -0800</pubDate>
    </item>
             

    <item>
        <title><![CDATA[apotheon: you spell out a number of good points]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-247965-2395275]]></link>
        <description><![CDATA[I was tempted to mention the Java IDE &quot;factor&quot; but I decided to leave this out of the equation because I did not want to get into the &quot;IDE's are for sissies&quot; argument. However, I think you are correct about this. Eclipse for example handles most of the scafolding most of the time. Of course once this code is generated it has to be maintained so the &quot;IDE factor&quot; is also not a free lunch. A couple of comments about the state of JRuby and Groovy: 1) Groovy 1.x and JRuby 1.1rc1 both compile to byte code (.class). So both will be able to take advantage of JVM &quot;just in time&quot; optimization. Of course because of the dynamic aspects of both languages not everything can be compile ahead of time (eval for example). 2) Netbean 6.0 is a really nice IDE for Ruby. I use it for my JRuby project and I am quite impress by it. It is also a nice demonstration of the improvement to Swing in Java 1.6 (the GUI is quite responsive compared to past version of Swing). Both the JRuby and Groovy team have done an excellent job. In the past, the performances of Groovy have always been among the best for JVM based interpreters. I expect the compiled version to be even better. The current release candidate for JRuby has improved a lot and I expect the final 1.1 release to actually outperform the Ruby C interpreter for some tasks.JS]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-247965-2395275]]></guid>
        <dc:creator><![CDATA[jslarochelle]]></dc:creator>
        <pubDate>Thu, 03 Jan 2008 20:00:13 -0800</pubDate>
    </item>
             

    <item>
        <title><![CDATA[Java   Groovy  Ruby; optimizing runtimes; verbosity]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-247965-2395203]]></link>
        <description><![CDATA[&quot;What I am saying is that there is no silver bullet.&quot;That's not what you were saying before -- even if somewhere in the back of your mind that's what you meant to say.  What you were saying is that Java's scaffolding and noun addiction made it readable, and the lack thereof in more concise, expressive languages made them effectively unreadable by comparison.  I'll buy the notion that this is not what you meant, though.. . . and I agree: there's no silver bullet.  Ultimately, I think Java's greatest contribution will be the JVM, which will be used as a platform for languages like JRuby, Jython, Rhino, Groovy, and even some kind of Perl 6 port at some point (most likely), along with a slew of others.  It's entirely possible that Groovy will be the big winner on the JVM platform, since it combines some of the positives of Ruby with some of the positives of Java, and throws away a lot of the unnecessary rules-lawyering that is baked into both the Java community and the Java language at this point.&quot;I do not think that languages like Ruby (I didn't have time to look at OCaml) are a free lunch.&quot;Oh, they're not, of course.  As things currently stand, Ruby is much slower than Java for long-running processes, for instance -- and because of the incredibly dynamic nature of the language (duck typing and all), it probably can't benefit nearly as much from an optimizing runtime the way Java can.  That's one positive benefit of static type systems, at least: certain types of optimization are much easier to have you tools do automatically for you.&quot;I think that if for a project you get x% bug prevention or detection at 'build time' in Java after N(j) hours of work you will have to spend a similar amount of time N(r) doing the same work in Ruby and N(r) will be very close to N(j). The way you do this will be different but the amount of time spend will be similar I think.&quot;I think that writing good test suites in Ruby buys you more than static type systems in Java, in terms of ensuring relatively bug-free code.  I also think that the greater conciseness of code in Ruby contributes to its readability while still providing a syntactic form similar enough in its superficialities to Java that Java programmers will not find it entirely foreign, and can adapt quickly.  Language-to-language, Ruby is simply more readable than Java, assuming similar levels of familiarity.On the other hand, the real benefit to static typing and extra scaffolding in Java for readability is not in the staticness and verboseness itself (which mostly just puts a bunch of ugly substructure between the programmer and the real code for readability purposes) -- it's in the fact that these language characteristics make it easier to write IDEs that work with Java.  As a result, there are a lot of great IDEs out there for the language, and not quite so much for Ruby.Ruby isn't a language that needs an IDE -- but when you factor in what IDEs can do for you, even if the Java doesn't really get more readable, it probably becomes about as manageable as the Ruby code.By the way, part of the reason I think Java can close the gap is that it's possible to write good test suites in Java, too.  Of course, most Java coders don't, so in practice Java probably fares worse on average than Ruby -- but that's not the language's fault.&quot;I did not find the examples that you have given me to illustrate Java's verbosity very convincing. I have already explained why I do not think that the public static main 'Hello world' example is not a convincing argument (it is impressive and this is why you see this example everywhere when the advantages of Ruby ? or similar language - are discussed) so I will not explain that again.&quot;Actually, the reason you see it everywhere is not because it's &quot;impressive&quot;.  What would be more impressive is an actual comparison of big software projects, side-by-side, complete with code line counts, invested development time, relative bugginess, and so on.  Ruby would probably win on all counts, since while the Java code was being finished in its first complete iteration the Ruby guys could hunt down hard-to-find bugs, produce greater test suite coverage, and so on.  No, the real reason you see examples like &quot;hello world&quot; and fibonacci generators is that they don't take up nineteen pages of code, so they're very portable and can easily be displayed.&quot;Instead I will comment on the other example that is often given. Something like:instanceOfClassX.getMemberY().doSomethingWithIt(..);Where memberY is often a collection. This also, is not a good example of Java's verbosity. It is just an example of bad programming (implementation details being exposed through the interface of the class). Most of the time this type of operation should be encapsulated inside ClassX and then the chain of calls would collapse to:instanceOfClassX.doSomething();&quot;Okay.  Now show where you defined that class and that method and all the plumbing for both.  You're under-representing the verbosity of the solution.&quot;Looking at the Java code on my projects I find that most of the code looks very much like Ruby code (and the reverse is also true): objects sending messages to other instances of classes using the familiar instanceName.methodName(..) syntax. It is true that Ruby has a number of features that are more economical in terms of typing but you can get those without totally loosing the advantages of the more verbose static types. Groovy for example includes closures and a number of other Ruby &quot;verbosity antidotes&quot; but you can use interface and static types when appropriate (and it often is for me).&quot;That's because Groovy is an attempt to make Java more like Ruby, by the way.&quot;Yes using a Java (Groovy) interface is more verbose than using dynamic types but the interface is a formal specification of the API and is much better than a document because part of its implementation is checked by the compiler and so it is not useless verbosity. The same is true of other features like annotations, Enum and static parameter types. I don't use annotation because I like being verbose. I use them because they allow me to check high level design constraints at compile time and thus help me enforce those contraints when other programmer modify the code. Doing the same thing in pure Ruby would actually require more work.&quot;I like having options.  As such, I like some of what Groovy supplies.  Unfortunately, Groovy fails at the one thing that most draws me to Ruby: making programming fun (for me).  Ruby, interestingly enough, was primarily designed for exactly one thing -- enjoyment of the programmer.  Everything else was secondary.  There are cases where that shouldn't be the primary purpose of the language, of course, but a lot of the time it's very easy to get by with that at the top of your list of criteria.  While Groovy introduced Java to a lot of Ruby's benefits, to some degree at least, it also (from Ruby's perspective) imposed a lot of Java's &quot;programming is serious business&quot; feel.  If you don't detect that feel to Java, you probably haven't spent enough time with a more-fun language.Python, by the way, probably has enough of the bureaucratic feel to keep Java programmers comfortable, and enough of the fun factor to be a good one to learn for that contrast with Java.&quot;Again, don't get me wrong I like Ruby and I am using it everyday. I am working on an internal project using JRuby (1.0.2 under Netbeans 6.0) and so far this is going well. The reason I am using JRuby is because I want to use the interpreter (eval) to support loading different test scripts at runtime (the project is an automated testing tool for our suite of Java applications). JRuby is really nice for java programmers because it adds many Ruby extensions to the Java library classes (Collection, etc...) and those Java libraries can be used. However, for large commercial project I prefer Java.&quot;For &quot;enterprisey&quot; software, running these thirty-year processes handling great masses of requests without ever restarting the runtime, Java is the better option than the current implementation of Ruby (but we don't know what the future will bring) -- if for no other reason than the efficacy of the optimizing runtime which, as I pointed out, is the sort of thing doesn't work as easily with very dynamic languages.&quot;I might actually start using Groovy on large commercial project because it is more 'Java like'. I will have to experiment with it and run some benchmarks.&quot;Let me know what you find.  From the benchmarks I've seen, Groovy outperforms Ruby at least some of the time, and underperforms noticeably compared with Java most of the time -- but Groovy is also a very young language implementation.  It may get better.What most interests me about Groovy performance is how (and whether) it makes use of the JVM's ability to support bytecode optimizing runtimes for long-running processes.  If so, Groovy doesn't necessarily need to get much faster to completely supplant Java, I think.&quot;I suspect that we will never agree on this but it is nice to be able to talk about it.&quot;Well -- we obviously disagree on the relative value of more-than-necessary verbosity for readability.  Otherwise, however, I'm not sure we've really run into anything on which we've established distinct disagreement.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-247965-2395203]]></guid>
        <dc:creator><![CDATA[apotheon]]></dc:creator>
        <pubDate>Thu, 03 Jan 2008 17:01:21 -0800</pubDate>
    </item>
             

    <item>
        <title><![CDATA[Guys: one last clarification]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-247965-2394910]]></link>
        <description><![CDATA[What I am saying is that there is no  silver bullet . I do not think that languages like Ruby (I didn't have time to look at OCaml) are a free lunch. I think that if for a project you get x% bug prevention or detection at ?build time? in Java after N(j) hours of work you will have to spend a similar amount of time N(r) doing the same work in Ruby and N(r) will be very close to N(j). The way you do this will be different but the amount of time spend will be similar I think. I did not find the examples that you have given me to illustrate Java's verbosity very convincing. I have already explained why I do not think that the public static main &quot;Hello world&quot; example is not a convincing argument (it is impressive and this is why you see this example everywhere when the advantages of Ruby ? or similar language - are discussed) so I will not explain that again. Instead I will comment on the other example that is often given. Something like: instanceOfClassX.getMemberY().doSomethingWithIt(..); Where memberY is often a collection. This also, is not a good example of Java's verbosity. It is just an example of bad programming (implementation details being exposed through the interface of the class). Most of the time this type of operation should be encapsulated inside ClassX and then the chain of calls would collapse to: instanceOfClassX.doSomething(); Looking at the Java code on my projects I find that most of the code looks very much like Ruby code (and the reverse is also true): objects sending messages to other instances of classes using the familiar  instanceName.methodName(..)  syntax. It is true that Ruby has a number of features that are more economical in terms of typing but you can get those without totally loosing the advantages of the more verbose static types. Groovy for example includes closures and a number of other Ruby &quot;verbosity antidotes&quot; but you can use interface and static types when appropriate (and it often is for me). Yes using a Java (Groovy) interface is more verbose than using dynamic types but the interface is a formal specification of the API and is much better than a document because part of its implementation is checked by the compiler and so it is not useless verbosity. The same is true of other features like annotations, Enum and static parameter types. I don't use annotation because I like being verbose. I use them because they allow me to check high level design constraints at compile time and thus help me enforce those contraints when other programmer modify the code. Doing the same thing in pure Ruby would actually require more work. Again, don't get me wrong I like Ruby and I am using it everyday. I am working on an internal project using JRuby (1.0.2 under Netbeans 6.0) and so far this is going well. The reason I am using JRuby is because I want to use the interpreter (eval) to support loading different test scripts at runtime (the project is an automated testing tool for our suite of Java applications). JRuby is really nice for java programmers because it adds many Ruby extensions to the Java library classes (Collection, etc...) and those Java libraries can be used. However, for large commercial project I prefer Java. I might actually start using Groovy on large commercial project because it is more &quot;Java like&quot;. I will have to experiment with it and run some benchmarks. I suspect that we will never agree on this but it is nice to be able to talk about it.JS]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-247965-2394910]]></guid>
        <dc:creator><![CDATA[jslarochelle]]></dc:creator>
        <pubDate>Thu, 03 Jan 2008 10:41:37 -0800</pubDate>
    </item>
             

    <item>
        <title><![CDATA[Larry's a real character.]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-247965-2393529]]></link>
        <description><![CDATA[I've always liked his essays and transcribed presentations.  Full of truthiness and verisimilitude.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-247965-2393529]]></guid>
        <dc:creator><![CDATA[apotheon]]></dc:creator>
        <pubDate>Tue, 01 Jan 2008 16:40:05 -0800</pubDate>
    </item>
             

    <item>
        <title><![CDATA[Larry Wall]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-247965-2393451]]></link>
        <description><![CDATA[Yeah, I really enjoyed this:http://www.perl.com/lpt/a/997]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-247965-2393451]]></guid>
        <dc:creator><![CDATA[Sterling "chip" Camden]]></dc:creator>
        <pubDate>Tue, 01 Jan 2008 12:20:59 -0800</pubDate>
    </item>
             

    <item>
        <title><![CDATA[programming, scripting, and &quot;general purpose&quot;]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-247965-2393264]]></link>
        <description><![CDATA[I've been known to differentiate &quot;general purpose&quot; programming languages from others -- but those others tend to consist of things like Brainf*ck and PL/SQL (SQL made Turing complete by adding proprietary extensions to it), which are not particularly &quot;general purpose&quot; even though they're Turing complete.Thus, the word &quot;programming&quot; is still relevant for differentiating between limited DSLs and, well, programming languages.As for scripting -- I'll just quote Larry Wall:A script is what you give the actors.  A program is what you give the audience.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-247965-2393264]]></guid>
        <dc:creator><![CDATA[apotheon]]></dc:creator>
        <pubDate>Mon, 31 Dec 2007 20:35:31 -0800</pubDate>
    </item>
             

    <item>
        <title><![CDATA[about imaginary towels]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-247965-2393146]]></link>
        <description><![CDATA[apotheon - 12/31/07 It's easy to be a majority -- and thus to have a higher chance of &quot;winning&quot; -- when the opposition just throws in the towel....or doesn't perceive the existence of a contest.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-247965-2393146]]></guid>
        <dc:creator><![CDATA[Absolutely]]></dc:creator>
        <pubDate>Mon, 31 Dec 2007 15:20:40 -0800</pubDate>
    </item>
             

    <item>
        <title><![CDATA[Apotheon's right about the need for more precise language]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-247965-2393104]]></link>
        <description><![CDATA[... but I also agree that the word &quot;programming&quot; has become too blurred in usage.Perhaps &quot;general purpose language&quot; or some similar term should be applied to a language that is not only Turing complete, but also reasonably capable of programming nearly any application -- distinguishing that class of language from languages that are specifically designed for a more limited domain, like query languages and scripting languages.Of course, now I have a problem with the term &quot;scripting languages&quot;, because many so-called scripting languages are actually some of the best general purpose languages.  I'd want to limit &quot;scripting languages&quot; to languages that are designed for scripting the behavior of a specific class of application.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-247965-2393104]]></guid>
        <dc:creator><![CDATA[Sterling "chip" Camden]]></dc:creator>
        <pubDate>Mon, 31 Dec 2007 14:05:57 -0800</pubDate>
    </item>
             

    <item>
        <title><![CDATA[Then you would be TRULY lucky]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-247965-2393103]]></link>
        <description><![CDATA[If for every new thing you want to learn, it immediately goes on your expertise list AND you get to do a lot of it.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-247965-2393103]]></guid>
        <dc:creator><![CDATA[Sterling "chip" Camden]]></dc:creator>
        <pubDate>Mon, 31 Dec 2007 13:58:40 -0800</pubDate>
    </item>
    </channel>
</rss>

