Fog Creek Software
Discussion Board




Programming Languages

In today's story ("Working on CityDesk, Part 3"), I explain why we chose to use VB and C++ to develop CityDesk.

What's your opinion? (please read the article first, though!)

Joel Spolsky
Wednesday, October 17, 2001

I think there are a couple of 'almost' factual errors about Java in Joel's article:

Java's write-once run-anywhere is of benefit to developers of server applications.  If you're building something for in-house use the cross-platform nature of Java isn't that useful as you know what platform you've got and you can code for it.  But if you're developing a product to sell then WORA is a boon.  In my experience it really does work.

Secondly, some desktop Java app's don't look like second-class citizens.  They probably had to jump through hoops to create it (and maybe even get SUN to extend the JDK) but Borland's JBuilder is fast and good-looking, though memory hungry.  So one CAN build good desktop app's in Java, though you may well rather do it using something else.

Dave
Wednesday, October 17, 2001

If you fancy yourself as an "Engineer", you may need to understand programming languages in the  context of the time period in which they evolved. Every period in computing history had a very well defined set of typical
hardware available, the kinds of constraints it placed on you - (like very limited memory in the real olden days, the 640K restriction on PCs a while later and so on). On top of this, computing evolved from scientific  applications through defence through commercial applications. Typical users evolved from the very very select few to a profession of programmers to "dabblers" are comfortable programming.
These days, robustness in the code, extensibility and maintainability win over extremely tight code with impenetrable use of pointers. In addition re-usability emerges from very basic UI elements and data structures or design patterns in Java.

So what's the best language? Depends on what you are trying to do, what kind of uses will the program be put to, how many users you expect to use the program, etc.
Religious wars over programming languages always happen when the perspective is not broad enough!

Just my 2 cents!

Nari Kannan
Wednesday, October 17, 2001

I am thoroughly incensed by "like all good hackers I have been programming since junior high".

I consider myself to be a good hacker, but when I was in junior high, you whippersnapper, there were no computers that mortals could use.  (We were in fact still working the bugs out of fire, and wheels. Dodecagons may make a pretty good aproximation of a circle on paper, but it turns out that they do not make good wheels, and they were damned hard to make too.  I could tell you stories. I still have the bruises.)

Apart from our college paper-tape BASIC timeshare teletype ("we don't need no stinkin' monitor"), on which we were allotted 3 min/wk of runtime, no computer that I could actually use appeared until I was well into my 30s.  It had 16K of memory (12K after the OS loaded) and an audio cassette tape for storage. All other computers were in sealed temples attended by priests and acolytes in white robes, and you durst not approach them without the proper incantations or a 6-pack of Dr Pepper.

I'll read the rest of your article when I cool down from the personal insult. You young people today. :)

Chris Dunford
Wednesday, October 17, 2001

When I really "grokked" COM, I wanted to embrace the multi-language aspect of it. I'm a C++ programmer at heart, but I tried to be a VB6 programmer, applying my years of education and experience programming C++ to the highly productive language of VB6.

And I failed time and again.

VB6 was great for tiny, tiny projects, but as soon as I wanted to model my data, I found it nearly impossible to do without implementation inheritance. It wasn't 'til I was able to try again in .NET that I really realized just what it was that VB6 was missing, because .NET provides these features to VB programmers.

Now that I have .NET, however, I really, really enjoy the benefits I get from a smaller language (C#) and a larger framework. I can't believe how productive I am.

Chris Sells
Wednesday, October 17, 2001

I was about to suggest that [...] is the best language of all, but what I really would like to know is if there's some good literature for turning a hack programmer (like, me) into one who's doing it right...? Thanks.

Hans
Wednesday, October 17, 2001

Excellent article Joel, I really enjoyed it. The choice of language(s) for a project is dependent, as you point out, on the outcomes, timelines, experience of the staff, etc. Whilst my main experience is in C++, I get (dare I admit it) almost joy from programming in Perl, where pointers non-existant.
<p>
Many programmers/sw engineers tend to be precious about the language they use. As my software engineering skills mature I've found it increasingly important to become less precious about the language I use, don't use, like, don't like, etc. It seems to me that a ball-point pen is great for signing cheques, but a 2B pencil is good for doing sketches; it would be foolish to try to use the pencil for the cheque, just because I have more experience using a pencil!

Ellers
Wednesday, October 17, 2001

I find memory management trivial when using the STL (no harm in C++); plus I can code my own containers if I need extraordinary memory management (no risk in C++).

I don't use C++ for GUIs much, though.

Christopher Wells
Wednesday, October 17, 2001

Great Article!

Just some comment on the language that I used.

VB was a major change from version 4 to version 5 because it introduces class feature, which was the first step toward Object Oriented Programming. Then, with VB.Net it have introduce the inheritance and other object oriented feature.

The thing I hate most is the time to re-write the code in VB to VB.Net. This has driven me away from VB actually. The boss is quite upset that we need to re-write some of the VB program. It took lots of time to the testing and coding.

Perl is not a pretty tidy language. It is just like VB. I never like Perl. But somehow, I was force to use it because some of the project is done in Perl.

Perl's power is depending on the power of the modules. Almost you can find anything that you want to do; there is a perl module for it. This is somehow makes me begin to like it.

I have tried to make the pure oop out of it but somehow not very successful. Then, it could be my knowledge of perl is somehow limited.

I heard that Python is somehow better than Perl in it's design but I never use it. So, I have no comment on that.

Java is my love and my hate. I love it's oop feature but I hate it's slowness. I love it's Swing, but I hate it's slowness. I think that's why it never success in the Desktop applications. I have people complaining that loading a java applet took ages to complete.

Java is a great for server application. It's slowness have been hidden by the high performance Server speed. So, I managed to convince my boss to use Java on the Server side.

Powerbuilder is great in the reporting. Its datawindow feature is superb. It's OOP design is clean and tidy. But, it is just as slow as VB. Then, compiling takes a long time. You get GPF very often with Powerbuilder. So, you have to make sure that you rebuild the object structure every time before you compile. It takes ages to do that. I am thinking of making a script or batch file to do that but somehow cannot find anything that can automate this process.

To me, there is never a good language. Every programming language got it's own weakness. So, make a choice of the programming language careful before you work in a project.

Anonymous
Wednesday, October 17, 2001

In my opinion, there are three features that are needed by "real" programming languages:

1. Garbage Collection.
2. Introspection.
3. Extensibility (eg: macros, being able to talk to other systems etc.)

Then, there is the whole thing about popularity. There is a snow-balling effect there though.

There is wonderful article by Guy Steele on programming languages in OOPSLA 98.

PS: I programmed in C, C++, Perl, Lisp, Scheme, Tcl, Python. Never tried VB. Perhaps I will now.

R. Kanneganti
Wednesday, October 17, 2001

I have been getting almost all the benefits of .net in Delphi for quite sometime, the speed of the Delphi compiler and the highly productive environment itself is sufficient to never think of VC. VB yes its productive, but you soon reach a limit. Calling windows API from delphi doesn't even require a declaration like in VB. And there's more open source stuff and free components in Delphi. GUI - you just can't beat delphi's IDE. VB simply wastes your time in letting you resize non visual components, just a small example.The default size of a button placed in Delphi will be that of a standard Windows button, looks like with all these versions of VB, MS couldn't implement such basic productivity enhancements. Delphi was providing the power of VC and ease of VB for quite sometime. Only problem seems to be in marketing the product.

What's the use of coding in two environments when you can do both of it in one. About C#, Anders Heilsberg was the chief Architect of Borland Delphi and was pulled from Borland to MS to be the chief architect of C#.That could be because MS wanted a Delphi implementation.
 

Sunish Issac
Wednesday, October 17, 2001

Nice article. I enjoyed it and I had the same experience that how a C++ coder utilize VB. VB is very productive when you are building a Windows desktop application. It do suffer when you plan for a large scale, multi-tier and complex application. Well, every language has its own context.

But, I do think Delphi and BCB is as productive as VB. About memory management in C++ (when you use BCB for GUI programming), we have to push more programmers towards modern C++ programming.

yowkee
Thursday, October 18, 2001

No one has mentioned Delphi yet, so I will get that out of the way quickly:

--- begin Delphi plug ---

You can drop down all the way down to assembler if you like, and it also has those Variant things that are reference counted.  Seems to me that it's a very popular language for implementing small programs, but it's quite "alternative" - not uncool like VB, just ... not the norm.

When I'm stuck on something and do a search on the web, 9 out of 10 hits are Russian.  I wonder why the Russians embraced Delphi so eagerly?

Anyway, it definately deserves a mention because it has all of the great features of VB that Joel talked about, with a little more formality to boot.

--- end Delphi plug, begin interesting points ---

Back at the very start, when MS were choosing what to use to write Windows 1.00, did they consider Pascal?  How would the Windows API have been different if they had decided to use Pascal/Delphi?  I guess Pascal wasn't as evolved as C.  I guess it was owned by someone.

Just think about the reference counts that some of the strings would have had if the Windows API used garbage collected strings instead of PChars.

Anyway, something I think about a lot these days is:  When are we going to move up a level and write our software in terms of *what it will do*, not *how it will do it*?

--- end $0.02 ---

Mike
Thursday, October 18, 2001

Since most of my programming experience is on the unix side, and since I find the plethora of not-quite-complete unix GUIs disappointing and too complex, I haven't the foggiest idea where someone with little desktop programming experience can begin.  I'm considering learning more about windows programming, but COM and DLL conflicts intimidate the heck out of me.  Where's a good reference for the languages/libraries that beginning windows programmers can get a foothold?

Patrick Lioi
Thursday, October 18, 2001

And speaking of Anders Heilsberg (see previous post), he was also one of the key architects of Visual J++.  Visual J++ totally rocks when it comes to building Windows GUI applications.  It's far superior to VB. 

Sadly, the Visual J++ product was the victim of a lawsuit.

Bravada Zadada
Thursday, October 18, 2001

Does VB have some sort of closures (macros, inner classes, etc.) or lifetime management (memory, desktop resources, etc.) scheme?  How else can you avoid spaghetti without them?

ac
Thursday, October 18, 2001

Hear, hear, Joel.  Couldn't agree more.  One of the sad attributes to VB is it's bad persona, developed in the pre-v5.0 era.  In the right environment, VB is a high speed development tool.  As long as you apply common sense standards and approach in an OO paradigm, life is good and projects finish on time.  I think you nailed the upgrade path to C# as well.

Gary Baanstra
Thursday, October 18, 2001

Historical note: The Microsoft team that wrote Windows 1.0 probably had plenty of experience with Mac programming, which was done exclusively in Pascal. And Microsoft had Microsoft Pascal, the leader for a couple of years until (Borland) Turbo Pascal came out. So they knew about Pascal and decided to use C and Assembler for Windows 1.0 anyway. (Although they did use Pascal calling convention for functions, which is more efficient).

My guess is that Pascal compilers just weren't as fast or as tight as C compilers. Also C is a more natural mapping to Assembler. In those days before there were source-level debuggers, I got really good at looking at a page of disassembled code in the debugger and knowing exactly how it correlated to the C code I had written.

Joel Spolsky
Thursday, October 18, 2001

I just want to say that Joel's approach to software development, and his writing style that brilliantly reflects it, are second to none.  His writing makes up, hands down, the best software development editorials I've read.  Maybe it's because my own approach and "development ethics and principles" are similar to his in certain ways.  It is always invigorating to read work that is espousing views you already hold !  For me, his writing is one of the last remaining beacons of inspiration left in this now hype-riddled profession of ours.

Specifically responding to "CityDesk Pt3", I applaud the following excerpts:
* It's one click in VB. Now try doing it in MFC.
* I've spent years writing code for C++/MFC and years writing code in Visual Basic, and let me tell you, VB is just much, much more productive
* And the worst part about coding in VB is that people think you're not cool because your code doesn't have {'s and }'s.  (LOL!)
* Yes, I've used Java extensively, but unfortunately the language, the code libraries, and especially the GUI libraries are just too primitive for a commercial desktop application.
* frankly not a lot of desktop software is sold for Sun Solaris
* I'm not willing to write an app that behaves in an inferior way on 95% of my customer's computers to benefit the 5% with alternate platforms.
* Every Java app LOOKS like a Java app, takes forever to launch, and just doesn't feel completely native
* -- at some point, you have to stop debating and write code!


Speaking of fads, I, for one, long ago grew tired of the vapor and hype that increasingly permeates thru our coding profession.  I have all but stopped reading tech publications.  I have gone "back to basics" and most of my reading now consists of O'Reilley books.  Sometime back, I learned to only bother reading about proven technologies; one's that are actually represented in the help wanted ads.  (As opposed to the lastest flavor of XSLTHML that you will probably never use or see at work)

Several years ago, I weaned myself off the "industry" journals, like Information Week.  They were getting filled with more and more nonsense and speculation, especially as the stock market peaked.    I bailed party due to the fact that, b/w actual coding articles and misc. industry news,  there was simply to much being published to keep up with.  I resolved to stick to only real CODE related pulications, that would augment my skillset, and not my cocktail party chatter.     

However, even this proved overwhelming after time.  By the time the boom incremented into a gallop in 1998, there were several coding puiblications devoted to any particular language.  It got to be too much to even keep up with one particular discipline.  As a result of this dilution, even the code centric publications were spewing junk.  A dozen ways of doing the same thing, etc.  Profiling every single esoteric/experimental language this side of Xerox PARC.  And the articles topics drifted furthur and furthur from reality.  At this point in the tech mania, it seemed every single insipid emergining technology, from 3rd party products, to new languages, templates, however redunant to existing solutions, were being touted as the next silver bullet.  It was all becoming a waste of time.  Dilution.

In hindsight, the media coverage become comical.  The rampant speculation coupled with blatant igorance yielded articles that were a waste of everyones time.  Many articles compared apples to oranges.  However, when a technology is bleeding edge, it is hard to see thru that.  DHTML vs. Java.  Java vs Windows.  ActiveX vs. COM.  Jini vs whatever.  Sun vs Microsoft.  Javascript vs Java.  VB vs Java.  Jini vs. VB.  You name it, every permutation seemed to be represented.  Ugh, in hindsight, such reams of misdirected garbage. 

It seemed like there were at least a dozen technologies to accomplish any given goal.    In the peak,  the redundancy was staggering.  At some point, I realized all these "fluff" ancillary languages were just a byproduct of the bull economy, as many many people were being paid to play, not to solve business solutions.  They would all soon go away, or at the least, take a back seat, as technologies consolidated.  Now that we're in a recession, and excess fat is being trimmed, I suggest that it's back to basics.  I surmise that many of the bleeding edge purists are either out of work, or maintaining COBOL/Perl/VB/C++/SQL code that is actually in production in real firms that are still in business.  Reality is back.  XSL?  Yea right.

Disclaimer:  I am a business programmer.  I get paid to build apps that business' use.  Therefore, I am not a purist.  eg: I don't aspire to rewrite Windows Media Player with a more efficient vector proceesing algorithm, for my 3 users.  I will use what's there.  There is a optimal balance to be sought in every implmentation.  It applies to the entire gamut, from a quick one-off 5 line perl script, to a full blown enterprize wide project.  I notice it can be hard for many people to objectively assess the project at hand, and choose the most appropriate toolset.  (The old metaphor of using a screwdriver to fix every problem comes to mind)  There are many biases and ulterior motives that can cloud this decision.  Often, the purists can be shortsighted as to the needs and capabilities of the staff.  I've seen massive java/app server infrastructures built for low traffic sites that could have been written in a 10th of the time in ASP.  There is more to writing good code than good code.  One must write appropriate code.  A massively abstracted object model may not be appropriate if you don't plan to extend the system.  I attempt to assemble software to the best of my capability with existing tools and methods, while taking into account things like available skillset, and budgets and timeframes.  I do not push the envelope, nor do I aspire to.  This is the niche I have chosen, and the niche I get paid to deliver.  I'll code VB.  I'll code Perl.  I'll code Java.  I'll use any database.  Whatever works.  Whatever we have.  To an extent.  At times, hardcoded shit is the best solution.  It relates to the age old optimazation cost/benefits analysis.  eg:  Is it worth optimizing a batch process that runs once a year, down from 1 hour to 15 minutes?  Usually, no.  That doesn't mean your a bad programmer.  In fact, I say the opposite.  There are many sides to being an effective TECHNOLOGIST.  It depends on the context of the solution being developed.  Do I need to move some calculation to C++ if it's being called 5 times a week?  Nah.  The concept of "good enough" needs to be considered.  Always comes down to cost/benefit.  Unfortunately, many coders scoff at the traditional anaysis phase of the software lifecycle. 

SSSSS
Thursday, October 18, 2001

Small nit: the text says "...NextStep, or Cocoa, or perl, or Python...". That should be "Perl" not "perl" :)
(Traditionally, "Perl" refers to the language, "perl" to the program which interprets or implements the language, and "PERL" to "I don't know what I'm talking about" :)

Philip Newton
Thursday, October 18, 2001

Yep, I got sick of this conversation about 11 years ago.
I've worked on quite a few developments since then, some in C, C++, some in VB, some in Delphi, some in Pascal.

VB just makes it easier to achieve the end result.
Use the time you save having a life :-)

Tony McConnell
Thursday, October 18, 2001

I also feel the need to bring up Delphi here. Delphi and C++ Builder have all the benefits of VB that Joel talked about, but combined with a solid object-oriented, compiled language, and a solid component framework. This means that you drag-and-drop your GUI and make labels bold with one click, *and* write that fast word-counting code in the same language! You can even put in some assembler if you need to. Plus that you can access all Windows API functions without having to declare them all the time. I have been successfully working on a 100,000+ line project in Delphi for several years and I can't think of a better product (and I've used Visual C++ and Visual Basic). The only problem seems to be its poor marketing...

Frederik Slijkerman
Thursday, October 18, 2001

Well said!  Scripting languages are, IMO, the way
to write applications from here on in; there's really
not much excuse to write C/C++, if your code is to
run on a modern CPU, and it's not going to be performance-critical.  If the language of choice can
be compiled to bytecode, or even to machine code,
all the better.

Personally, I work in C, but I write my free software
with Perl (in a fully OOP style).

BTW what you say about Java is spot on.  Portability
everywhere, at the expense of usefulness anywhere.
Sun wound up painting themselves into their usual
market space, ie. the server side, IMO...

Justin Mason
Thursday, October 18, 2001

Joel is bang on target. Use VB or RB for UI and for process intensive modules on C/C++. We have done same mistake of writing GUI in C and had a nightmare. So before things went out of hand switched to RB. Its really cool and we implemented new feature almost in no time.

But I completely disagree with him when he says memory management should be left to the language for improved productivity. This really makes a programmer lazy. Languages should only give out features to make management easier. But the garbage collection should not be left to Runtime. As far my knowledge goes there can never be a proper garbage collector.

Rajesh Kamath
Thursday, October 18, 2001

To jump on the Delphi bandwagon...

"what happens if you take top-notch C++ programmers who dream in pointers, and let them code in VB," ... you get Delphi.

"One of the things about Visual Basic is that it doesn't always give you access to the full repertoire of Windows goodies that you need to make a polished application. But what it does do, better than almost any other programming environment, is let you drop into C++ code (or call C APIs) when you're desperate or when you need that extra speed. " ... Delphi lets you do both all in one package.

It's a bummer. Delphi's been a great tool, but its job market is so bad, I feel it's a disservice to my company to keep using it because they'll have a hard time replacing me if they ever need to.

I went to a .Net presentation the other day. It's pretty obvious where Anders has been working lately. The good news is C# looks like a happy home for me for a while -- a good tool (hopefully) and a popular company.

Chris Morris
Thursday, October 18, 2001

I think visual UI design is bad.  While it helps programmer get a working program quickly, it makes the UI pretty hard to maintain.  Also, how would you do a resizable window in a visual environment? (I know how... :)

Programming UI in C (or C++) is easy, if you're using the right toolkit (that is, not MFC, anyway...).  I would strongly recommend Gtk for C / C++ / Perl / Python / Pascal, and perhaps other languages too.  Also, Qt is a good multiplatform toolkit, for C++ only.

Mihai Bazon
Thursday, October 18, 2001

I manage a team of developers who use several languages. I don't much care which ones, as long as they don't put business logic in assembler!

Allan Beatty
Thursday, October 18, 2001

My own observations, as a VB programmer who can do pointer math:

1. much of VB's bad rep comes not because VB code is inherently bad, but rather VB because makes it easy to write extremely bad code (and in a few awkward places, hard to write good code);

2. to be a good VB programmer, you need to understand pointers. Call it an object variable, call it a variant, call it a resizeable array, it doesn't change the fact it's a reference type with a pointer hiding deep in it's dark little vm heart;

3. bring on C#! Yes, VB.NET is essentially the same language with slightly different syntax, but from what I've seen thus far, C# will be my choice. And no, not for the cool looking "{", ";", and "}" either -- this could be unique to me, but in every sample I've read thus far, next to C#, VB.NET looks painfully wordy.

Excellent column.

Craig Malloy
Thursday, October 18, 2001

Here are some links which gives a comparison between Delphi  and other languages/RAD tools.

A very detailed article on Delphi Vs VC
http://www.delphi3000.com/articles/article_672.asp

http://www.optimalcode.com/tscp.htm

http://delphi.about.com/library/weekly/aa042799.htm

Jake's code efficiency challenge - each language has its own pros and cons. I had to use the cached link at google as the original site seems to be down.
http://www.google.com/search?q=cache:HS8XX6M6BSE:home.xnet.com/~johnjac/Delphi%25205%2520vs%2520Visual%2520C.htm+visual+c%2B%2B+Vs+delphi&hl=en

And now with Kylix you can enter the Linux X platform too.
Have a look at what Kylix is at http://www.borland.com/kylix/

Joel why not have a look at Delphi ? Yes,switching tools can be a pain.But its a one time pain.

With all the coding in VB and VC I never regret the switch over to Delphi.



Sunish Issac
Thursday, October 18, 2001

I've probably worked in 30 languages over the years (put me down as another one of those folks who COULDN'T start hacking in Jr. High due to a lack of computers -- unless you count the Digi-Comp and the CARDIAC, both of which I owned). I was going to get involved in this eternal religious war but then I realized -- I've got a product to work on.

So I spent an hour writing code instead.

In VB. Which is letting me write this particular product (designed to do a lot of manipulation of SQL Server objects in a way that might actually make sense to non-DBAs) much quicker than anything else I've got installed these days.

Mike Gunderloy
Thursday, October 18, 2001

<< Qt is a good multiplatform toolkit, for C++ only. >> Not entirely true. Delphi and Kylix use QT for cross platform compatibility. Create your applications in Delphi 6 with CLX components and the only thing you have to do to get a Linux version is recompile in Kylix.

To all the Delphi supporters:
Please stop telling everyone about it. Delphi is one of the best kept secrets and I would prefer to keep it like that. If everyone starts using Delphi/Kylix we Delphi developers loose the competitive edge.

Jan Derk

Jan Derk
Thursday, October 18, 2001

Any of you gurus out there tried Clarion from www.softvelocity.com ? Welcome your comments on Clarion vs VB/Delphi

SurKam
Thursday, October 18, 2001

Frederik Slijkerma said:  I have been successfully working on a 100,000+ line project in Delphi for several years.

Just a note of caution.  Careful if that job ends, b/c as great as tool Delphi is, your marketable skill set is all but non-existant.  And yes, you may be a great programmer, but hiring managers, especially in a recession, aren't even going to look at your resume if it doesn't have the correct buzzwords on it.  Unfortunately, Delphi isn't one of them.  The fact that you have been at the same place of employment during the rise and fall of the tech boom, while admirable, also reflects the marketability of your particular skillset.  As in Dilbert, "We have such low employee turnover b/c we only hire people who aren't qualified for other jobs.."  Sad but true.

SSSSS
Thursday, October 18, 2001

Oh, and I forgot to say that Delphi directly compiles to a stand-alone, royalty-free EXE. You don't need to distribute any run-time libraries.

Frederik Slijkerman
Thursday, October 18, 2001

<<The fact that you have been at the same place of employment during the rise and fall of the tech boom, while admirable, also reflects the marketability of your particular skillset>>

I actually have my own company, so this is my own project. Funny, I'd never thought I would have to leave my own company just to be "marketable". And for your information, Delphi isn't the only language I know; it happens to be the most productive tool for my own products.

Frederik Slijkerman
Thursday, October 18, 2001

Many Delphi guys end up with their own companies to justify the right cause :-)

Sunish Issac
Thursday, October 18, 2001

Interesting discussion on the merits of VB.

Are there any books on VB that you'd recommend
for experienced C++/Java/Windows programmers?

How should such programmers learn VB?
(And VB.Net?)

Paul Cowan
Thursday, October 18, 2001

<quote>
Michael and I had a good laugh today when we discovered somebody  selling a beta crash-reporting product at $5000 for three months that Michael implemented in CityDesk in two days.
</quote>

Using Delphi, I duplicated that writing a SOAP server as the report server and and hooked the error handler of my application. It took about one and a half hours to do the client, the server, and the error handling.

:-)

Tim Sullivan
Thursday, October 18, 2001

Nice article Joel.

I would like to add a couple of things about Java.. WORA makes sense on the server. On the desktop, there are quite a few very good programs written in Java: Forte, JBuilder, Together J, and more. Also Java may blossom with the applet technology once the broadband - high speed Internet becomes widely used. Those applets will load quickly and they'll be a powerfull alternative to classic desktop software.

My experience with Java has been very pleasant. Never written a line of GUI code in Java, just some server code.

Every language out there has its pros and cons. And there are many places to discuss them. If you find a language that suits your needs - stick to it and learn the ins and outs of it and you'll be fine. Also know your basics. Without a solid foundation you're lost.

So let's talk about something else ;-)

Nesho
Thursday, October 18, 2001

If you're interested in other programming languages you might want to check out Suneido (www.suneido.com).

Andrew McKinlay
Thursday, October 18, 2001

Good article, even though I'm one of those old ones who didn't do any programming until college, and even then (1974) we didn't have PC yet -- I used a teletype terminal with a paper tape reader connected to a PDP-8 with a tape drive and a bunch of brightly-colored toggle switches.  And what language did we use?  Basic, of course.

I've mostly been an anti-Basic snob until recently, when I took over a small WIndows program and realized, hey, this *is* the easiest way to write a UI, and by FAR the best way to work with COM.

Now, I'm getting into C#, and I have the best of both worlds: the ease of VB and a C++/Java/Python-like syntax that I'm more comfortable with, plus real OO.  Using it in the ASP.NET environment finally makes ASP palatable for me, and makes SOAP very easy.

For portable, non-UI code, though, I really have to put in a plug for Python.  Great language, enormously productive.  And you can't beat an interactive, interpretive environment for quick turnaround.  Using Python, I've never even felt the need for a full-blown debugger.  Also, when used with the appropriate library, it's even simpler and easier than APS.NET/C# for writing SOAP-based web services -- and again, it's portable.

Dave Seidel
Thursday, October 18, 2001

Joel wrote:

"Philisophically, I think that C# has a bright future in the Windows GUI programming world."


Won't the fact that a (huge?) Common Language Runtime is needed to run C# applications be a big problem? It's not very appealing to need to redistribute a large runtime with every small app you make. (Same problem for Java, of course.) Or is it possible that a compiler for creating native exe:s will be released?

/Daniel

Daniel
Thursday, October 18, 2001

</quote>
Won't the fact that a (huge?) Common Language Runtime is needed to run C# applications be a big problem? It's not very appealing to need to redistribute a large runtime with every small app you make. (Same problem for Java, of course.) Or is it possible that a compiler for creating native exe:s will be released?
</quote>

The runtime is the OS, so it's a moot point.

C# is promised to a beautiful future not just in the Windows UI world, but everywhere on Windows.  It looks like C++ has finally found its successor.

Cedric
Thursday, October 18, 2001

Maybe VB (and others) is slow because of that handy garbage collection feature. If you program correctly (and maybe use STL while you're doing that), you don't really need garbage collection.

I think VB is great for the smaller projects too. But C++ can be used to implement a GUI app, you just need a larger frame work, but after that it will really work, be fast and won't crash as many times (all done in the good programming sense, of course).

Who needs bold text will build it into the frame work...

In fact; any language at some point in time wil become much better than before if people are still using it (and extending it).

A 'new' programming language is just a different syntax and maybe some extra features. In the end it will run on an OS (which functions it will have to use) and if there is a GUI; it will use functions to open windows and so on. So the 'trick' stays the same.

OO really delivers the benefits (other way of thinking).

Marco van Tintelen
Thursday, October 18, 2001

The issues here are specific to application programming.  Yes, like "eggs to order", it's nice to have VB to help with the GUI since that's what it does.

This has nothing to do with large, volatile, heterogeneous systems that require real computer science architecture.  Most of those systems have a minority in the GUI interface, rather than the majority (in fact, most application programs are so poorly designed the whole application is in the GUI.)

Since the GUI is a rather arbitrary and volatile creature (as is most application programming), I don't care which language is selected.  The opposite of this is architecture implementation.  A claim that complex systems can be addressed with VB is ridiculous beyond the possible proving of a prototype when you don't yet have any idea as to where you are going (been there, seen that tried, have the stories.)

--charley

Charley Bay
Thursday, October 18, 2001

Disclaimer:  I just want to say I dont mean to be combative.  I just get fired up sometimes.  Any fellow fan of Joel's pragmatic approach to software development has to be a well rounded technologist. 


> On the desktop, there are quite a few very good programs written in Java: Forte, JBuilder, Together J, and more.

Who cares if your IDE is written in Java?  That's such a classic example of misinformed hype.  I dont need a clunky Java frontend to write Java code in.  Please give me a fast native windows app.  Java doesn't apply here.  Corel's Java office suit DEBACLE was a great example of this type of thing. 


> Any of you gurus out there tried Clarion from www.softvelocity.com ?

I dont believe people need these redundant solutions in a recession.  All these extraneous products are simply noise now.  These "never were's" will go away soon enough.  It is now a time of technology consolidation.  Firms need to consolidate staff, etc.    Cancel liscences.  Chop R&D.    Back to basics.  Stick with common, lowest commmon denominator languages, not esoteric bull market promises and possibilities.


> If you're interested in other programming languages you might want to check out Suneido (www.suneido.com).

See above rant.


>  C# is promised to a beautiful future ....etc

Stop right there.  Haven't you learned anything in the last few years?  EVERYTHING is hyped as the "beautiful future" silver bullet.    ActiveX, DHTML, Jini, Java, XML, XSL, XHTML, COM+, COOL, C#, J#, J++, EJB, J2EE, App servers, etc etc etc.....You must learn to filter the marketing noise, and see where the technology fits in.  Also,  even if it works and is great, does it LEAPFROG existing solutiuons, which gives impetus for people to bother switching?  Usually not, which is what has resulted in so much clutter in the past few years.  Few things are pushing the envelope.  Client/server.  Browsers and the web protocols did.  etc.

SSSSS
Thursday, October 18, 2001

I see that anything I could say about Delphi or C++ Builder has already been said so I'll just drop a "B0rL4nD 0wnZ" to show support ;)

All programming languages have their strenghts and weaknesses, in the end it only comes to choosing the right one for you and your needs.

Peace.

Frank R.
Thursday, October 18, 2001

I'd just like to add my support for Delphi.

You don't need to 'drop out' of the language for low level access.  You can even use pointers.

Microsoft must have been impressed impressed with the language.  They hired Anders Hejlsberg, after all.

Also,  Java does not fully protect the programmer from referencing.  There are still so many wannabe Java programmers who cannot understand why they must use String.equals().

Ged Byrne
Friday, October 19, 2001

Never restrict yourself to one programming language. Sometimes, you fall in love with one programming language; you ignored all the benefit that other programming language can give you. I see lots of bias in this discussion group.

I see people who do lots of hacking in VB whereas they can just write a few lines of code in Delphi to do that or in C++.

I also see people writing the whole regular expression condition in C++ whereas they can do in a single line in grep or Perl.

Come on! Stay open in the world of IT. There is a lot of the solution to our programming problem. Don't stay in one programming language. Try different technique and ways. Find out the best solution to it. It doesn't matter if it is VB, Powerbuilder, Java, Perl or anything.

Anonymous
Friday, October 19, 2001

Sometimes, I was very worry about these programming language.

What if the programming language die or no market demand ? say Delphi. If Inprise is died, what will happens to Delphi? Say Powerbuilder, If Sybase died, what will happens to Powerbuilder? What if the open source decided to give out Perl? What will happens to us - the programmer that depend on these language?

Even some of the great programming language have died simply because there is no company to support them.

Annie
Friday, October 19, 2001

I would say the best programming language is the one that can solve the problem fast enough.

John
Friday, October 19, 2001

Just a note on Pascal and Windows development.  It wasn't really accidental that the stack frame used in Windows was the pascal convention rather than the common C stack frame of the time. 

Pascal was I believe a development language internally within Microsoft at the time, I think the Windows development happened before they even had their own C compiler, Lattice was the 8086 leader at the time. 

Most of the 'office' applications were shipped as pcode with a runtime written in assembler which OEMs could then port if they needed to (I still have the scars of porting Word engraved on my soul).

Simon Lucy
Friday, October 19, 2001

>  If Sybase died, what will happens to Powerbuilder?

Uhh, Powerbuilder died years ago.  Widespread VB5 adoption buried it for good.  I guess some people just never figured it out, like the rednecks in the deep South who are still fightin' the Civil War! 

SSSSS
Friday, October 19, 2001

As a long-time embedded programmer, I'll have to put in a plug for good old-fashioned "C".  When you consider that the overwhelming majority of processors sold these days are 8- and 16-bit dinosaurs destined for embedded systems, you realize that an awful lot of  programming is done for systems with minimal speed, memory, and processing power.  In such environments, pointers (used properly) are your friend.  Automatic garbage collection frequently interferes with even soft real-time deadlines (though they're getting better all the time).  And you can't create a fancy GUI with a handful of LEDs and a couple of buttons.

Of course, there's also an awful lot of programming done on desktop systems, where power and resources are more plentiful.  When I need something to run on a desktop enviroment, I still use C heavily (many of the tools I write share code with the embedded systems), but also use C++, Ruby, Tcl/Tk, and whatever language that existing code which almost does what I need is written in.

Mike Gauland
Friday, October 19, 2001

By the way, since we're also sharing personal histories, I first learned to program on a TI-57 programmable calculator, then a PDP 8I (BASIC and assembly language, TTY and paper tape) in high school.  Eventually, my father bought a VIC-20 (with a cassette player for secondary storage--very high tech!).  In college, I was able to get a computer of my own--a Commodor 64, with a real floppy drive--now that was luxury!

And that was actually powerful and roomy compared to some of the embedded systems I've programmed.  On one system, we were limited to 256 bytes of on-chip RAM!  Still, we managed to cram in a UI (with a bunch of buttons and 7-segment LEDs on the front panel), calibration, enough functionality to satisfy users, and an RS-232 control interface.  Ah, those were the days...

Mike Gauland
Friday, October 19, 2001

Someone asked early in this discussion about good books about programming practices.  To answer briefly, the single best book I've read on the subject is _Writing Solid Code_.  The second-best book is likely to be Joel's own collected writings.  That may surprise some people who've seen me be very critical of Joel recently, but it's true.  There's no shame in being a better coach than player.

I'm primarily a kernel hacker, so the bulk of my professional work is in C.  Even C++ is not available in-kernel on any but one of the platforms (NT) on which I program.  I've publicly lambasted people on more than one occasion for using Java to teach OS classes, or to implement functionality that belongs in a filesystem.  People who know all of this about me are often surprised to find out that I'm also an ardent Python user and advocate.  People who know that about me were in turn quite surprised to learn that I turned to PHP for some stuff on my website recently.  So where am I going with this?  It's simple: one size does *not* fit all.  Some languages are better for GUIs, some are better for business logic, some are better for device drivers.  Anyone who is well educated in the basics of software engineering - general hardware/software architectures, algorithms, development methodologies - should be totally unfazed by a switch to a new language.  There's an old saying that "a bad programmer can write FORTRAN in any language"; it's almost equally true that a good programmer can do good work in any language.

The key, I think, is that the "one language for everything" meme must die.  John Ousterhout, Guido van Rossum, Larry Wall, and Bill Joy - among others - all realized this early on.  More recently, Microsoft has gotten the message.  The hero of Joel's story, IMO, is not VB or C# but the CLR - a way to get code written in different languages to work together instead of requiring that the whole damn application all be written in one "jack of all trades, master of none" language.  We could have the same thing using the JVM, or P-code, or ANDF, but the important thing is that we stop fighting language wars while we still have other things to do.

Jeff Darcy
Friday, October 19, 2001

"What if the programming language die or no market demand ? say Delphi. If Inprise is died, what will happens to Delphi? Say Powerbuilder, If Sybase died, what will happens to Powerbuilder? What if the open source decided to give out Perl? What will happens to us - the programmer that depend on these language?"

You could spend time worrying about these things, or you could just dig in and start working. Delphi hasn't died. Powerbuilder still works. Your Sybase database won't stop working if the Sybase corporation is bought by Keebler and turned into a cookie company.

A tool doesn't have to be THE MOST POPULAR for it to be a good choice for a project. I started my company using a niche development tool on a niche platform. Most of you probably have never heard of this environment, but it's still around, and it's still being actively updated after 16 years on the market. It's a hugely productive environment that lets me create great looking and fast apps that our customers love and our competitors hate.

What else matters?

Jeffrey
Friday, October 19, 2001

It sounds like Joel is talking about the Alternate Hard And Soft Layers pattern.

http://c2.com/cgi-bin/wiki?AlternateHardAndSoftLayers

Sigh.  I can't begin to imagine what wonderful software we would have today if all of the people who had argued about their language being better than all other languages over the years had read this pattern and understood it.  But they were too busy worrying about pointer arithmetic and not being "lazy."

John Lindsey
Friday, October 19, 2001

You're going to think I am joking.  I can assure you I am not.  Back when I took my first introductory programming class (Yes, I was hacking years before that on my own... but you know how it is) I started invoking this prayer before every homework assignment: "Oh god, let me learn to use pointers." 

Anon Lover
Saturday, October 20, 2001

I am a VB programer in a company that uses VB for the reasons Joel stated in his article.
One of the things that bothers me the most in VB is the Error Handling.
It is so lame, and the try/catch blocks in C++ or Java are much more readable and easy to use.

What A Guy
Saturday, October 20, 2001

You do know that VB .NET uses try/catch/finally for error handling, right? Something to look forward to, at least assuming you're planning to make the Great Migration.

Mike Gunderloy
Saturday, October 20, 2001

My main problem with Joel's pro-VB tirade is how it confuses VB the environment with VB the language. I'm all for RAD-style software development, especially for front-end applications, and I do agree that VB provides a good framework for this. Add to that VB's database access capabilities (courtesy of ADO and its Data Environment) and you have a great tool.

The VB language OTOH and a terrible piece of convoluted junk, and is a hindrance to the capabilities of the environment. Here's why:
1. A dated language. Already dated in the 80s (70s?), MS has for some inexplicable reason decided to make it a cornerstone of their development strategy. "Intuitive and easy to understand" – don’t make me laugh! While I'm not a big fan of the C/C++/Java syntax style either, C# is certainly a step in the right direction.
2. Four dialects (VB, VBA, VBScript and now VB.NET) each seemingly similar yet surprisingly incompatible.
3. OOP extensions that aren't.
4. The worst exception (error) handling syntax ever.
5. The file manipulation functions, groan ...
6. The dumb-ass SET instruction
And the list goes on and on.

I have written some VB apps, mostly as a testing platform for COM components (C++ and ATL), and for that VB is great. I have also written some medium-size VB applications, which usually started nicely, but didn't take long before VB the language got in the way. I shudder to think about a large-scale VB app.

BTW, I would like to offer an interesting alternative for GUI development: HTML and JavaScript. Yes, I mean developing stand-alone, client-side applications in (Dynamic) HTML and JavaScript, with the data coming in through COM. You can even give your front-end an application appearance by making it HTA instead of HTML. This requires IE5+, but I think that this is almost universal now on Windows platforms (IE5 installed, not necessarily the default browser). And JavaScript is so much better than VB (VBScript): truly OOPS (yes it is), supports functional/high-order programming (like Haskell), good error handling, ...

Even the MS developers preferred JavaScript over VBScript. All the dialogs in IE, e.g. Find (Ctrl-F), About, Error, are done in HTML with JavaScript.

Dan Shappir
Sunday, October 21, 2001

As long as programming languages keep on needing { or } and us poor europeans need strange key combinations to get to } and { - we'll stick with VB!

(Member of the "Committee against Strange Characters in Programming Languages")

B. Ackslash
Sunday, October 21, 2001

I take it you're not a fan of APL then :)

Mike Gunderloy
Sunday, October 21, 2001

At least the VB syntax seems to avoid the need for "significant whitespace!" This is one of my only major gripes with Python - where intendation (tabs/spaces) actually defines the blocking of your code. IMHO this was a good experiment, and certainly worth trying out in a real programming language, but ultimately I think it is a failure. The killer flaw is that you can't cut and paste blocks of code from different indentation levels - you have to manually very carefully redo the indentation.

A smart editor might be able to mitigate this problem somewhat*, but personally I'd just rather stick a { at the beginning, a } at the end, and be done with it.

* surprisingly, I haven't been able to find a python-mode for Emacs that helps with this problem.

Dan Maas
Sunday, October 21, 2001

Since I've been a VB nut about as long as I've been a professional programmer, I think I'm going to disect Dan Shappir's criticism list...

1. Dated language...
BASIC is about the same age as C, and modern BASICs like VB6, VBScript 5.5, or vb.NET have about as much in common with Dartmouth BASIC as Java has with K&R C.

2. Four dialects...
That's all? I'm sure there are a few dozen other BASICs out there, at least, though it is kind of trivial in comparison to the number of C dialects out there.

3. OOP extensions that aren't...
Don't seriously make this argument now that vb.NET's in late Beta.

4. The worst exception (error) handling syntax ever.
vb.NET uses Java-style Try/Catch/Finally error handling, with the nifty little When clause for Catch that I haven't seen anywhere else (although it's probably not original).

5. The file manipulation functions, groan ...
vb.NET uses the .NET framework's file manipulation functions (just like C#).

6. The dumb-ass SET instruction
... doesn't exist in vb.NET.

Dave Rothgery
Sunday, October 21, 2001

Dan, if you cut and paste code from different indentation levels in a language that uses braces, and then don't reindent, you're often in a worse situation than you would be in Python: you have code that works now, but will mislead the next person who tries to look at it and try to change it.  I think one of the best points I've seen made wrt the Python/whitespace issue is that people who read code tend to follow the indentation rather than braces anyway, so you're only asking for trouble if you make the compiler/interpreter "read it the other way".  By only having one way to indicate nesting, people and programs which read the code will reach the same "understanding".

Jeff Darcy
Monday, October 22, 2001

Dave, seems that most for you answers to my issues with VB are along the line of "VB.NET fixes this issue". This may be true but VB.NET is more C# using VB keywords than it is VB. Seems to me that the whole purpose of VB.NET is to ease the transition from VB to C#. From this perspective VB.NET appears to be more of a transition-point than a final destination. This in itself is a major argument against using VB.

As to BASIC being as old as C - yes it is. But C was designed from the get-go to be a full-blown development language for system programming. BASIC OTOH was designed as a learning tool/toy. I personally think that what MS has managed to do with BASIC is quit amazing. Still doesn't mean that the syntactical underpinnings aren't all rotten.

About dialects: there *is* a C standard, there is no such thing for BASIC, not even for VB. BTW, my point wasn't about BASIC dialects, it was about VB dialects. Personally, I think that that major differences between VB and VB.NET are going to kill the language, if MS doesn’t do it intentionally first.

And BTW, C is *not* my language of choice either. Currently most of my development is done using C++, but I also use quit a bit of Java, JavaScript and, yes, VB (mostly for testing). I also like to play with C#, Python, Ruby, Haskell, etc.

Dan Shappir
Monday, October 22, 2001

Although there seems to be a popular story that vb.NET is just C# with VB keywords, that's even less true than the notion that C# is Java with Microsoft's class library.

Just off the top of my head...

vb.NET
- Has modules, so we don't have pretend that function libraries are classes
- Has the Handles clause for event procedures, which lets one procedure easily handle multiple events (that and WithEvents arguably make vb.NET the best .NET language for good-old-fashioned GUI work)
- Has the Implements clause for class methods, which lets one method of a class implement methods from multiple interfaces
- Has the When clause on Catch, which allows for conditional exception handling
- Has default and optional paramaters for functions
- Has parameterized properties (C# only can do this for the default indexer)

Dave Rothgery
Monday, October 22, 2001

Seems to me as usual this has turned into a replica of every language flamewar ever propogated.  We've got the try language X crew with Delphi.  We've got the Windows on the World crew marvelling at the ease with which VB cooperates with the rest of the Windows platform on the desktop and wondering why anyone would care about any other environment.  And we've got the "you forgot about feature Y" crew defending the C/C++ families with STL, GtK and other libraries.

We've also got more than a few voices of reason pointing out that tools are not as important as one's skill with those tools.  Furthermore one's skill in choosing the correct tool for the job is almost as important as their skill with the the tools in the first place.  As an analogy consider the precision of construction of the larger pyramids, Gothic cathedrals, Great Walls (China, Hadrian's) and other engineering feats of antiquity.  They are no less impressive for the lack of availability of power tools, but rather due to their designer's skills with what was available.  That said consider the achievements of Tao (http://www.tao.co.uk/2/tao/index.html) essentially using assembly language.  As a disclaimer I have no personal or financial interest in the group merely an appreciation for what they've accomplished.

So as another "programming since junior high" type, (Don't hold the availability of cheap computing power against us and we won't hold the social experimentation you may have enjoyed in the 60's and 70's against you either) let me say what I appreciate in a programming language.  Garbage collection is good, so are strong typing (and I am not referring the broken ALGOL model), first class functions (which can increase code reuse by an order of magnitude for those who've had the pleasure of using them in more than a toy project), support for concurrency (of which the best model is Ada95's tasking IMHO) and pattern matching (for function invocation not regexps) which gives all of the power of assertions with less pain.  No one language I know of has all of these features in equal abundance and (as anyone concerned about real time applications using reference counted garbage collectors can tell you) VB lacks a good implementation of most of them.  Although VB cannot be beat as a tool for adding basic functionality to a simple UI for Windows applications, which is a larger programming problem set than many people would like to admit.

Given that language feature sets are likely to converge over time (Fotran90's inclusion of record types and concurrency, C++'s STL, CLOS, VB.Net fixing VB's OO problems etc.) it seems to me that it is better for a programmer to be conversant with multiple styles than with any particular language.  Thus when "esoteric" feature X makes it into your favourite language you can use it to full advantage (efficient tail recursion and/or first class functions make many algorithms far easier to implement than in a stack based/imperative style (but not all algorithms ;-)).

This leads me to my concluding point, my primary criterion for programming languages is the maintainabilty of the resulting code.  Although good programming practice (comments, indentation, modularity, orthogonality etc.) can help the chosen languages' native capabilities are also important.  8 times out of 10 those "I can do it in Perl/VB/C/"insert your favourite here" that'll look ugly but get the job done" programs end up becoming a point of failure when someone uses them for a mission critical application not knowing one of the original design criteria was "no one will ever use this for mission critical work".  What does this have to with VB?  Not much.  However I will submit that there are languages that go out of their way to explicitly enhance the programmer's ability to write maintainable code (Python comes to mind, so do Haskell, WEB/CWEB (I know it's not a programming language but it counts here) and in its own perverted 1960's fashion BASIC).

Sseziwa Mukasa
Monday, October 22, 2001

My programming philosophy based on 24+ years of experience from OS programming to applications...

VB for Window Apps
C or Java for Unix Apps

Forth for anything you can't do otherwise. :)

I used to think that a programming language that doesn't allow memory access (pointers) is just a toy, until I realized that not everyone has the mental skill to program a computer for greatest efficiency.

When the speed and memory capacity of computers were finally able to overcome the need of programmer efficiency, then the people who know their *domain* well could program solutions to the problems that they had using these "toy" languages.

But programming as a profession suffers when those who truely don't know computers - being hidden behind multiple layers of acronym-laden hyped up "platforms" - are looked upon as the experts by business people who don't know either.

We truely have reached any era of the blind leading the blind. For a striking but obvious example consider...

Java for Server software (!) ... you've got to be kidding!

Why choose the slowest and most pathetic performing language for machines that need to process multiple clients as fast as possible???

Bill Zimmerly
Monday, October 22, 2001

As a follow up to my previous posting...

"Any" should have been "an"...

...and what other industry *other than* programming rewards people for *not* being the best skilled around???

A professional programmer who doesn't know how to use pointers simply doesn't deserve the title.

Bill Zimmerly
Monday, October 22, 2001

Hmm, apparently not many Java programmers read your site Joel.  Your criticisms of Java are dated and not accurate.  I won't go into all of them since it's not very interesting, but I'll just mention a couple.

It is possible to manipulate a window directly via HWND; that's what the Skin Look & Feel package does to get non-rectangular windows.  Java apps don't *have* to have the standard Java look (which is btw very lame).  It only takes one line of code to switch to the Windows look & feel (or Motif or Mac).

I am a GUI developer who had to make the transition from UNIX/C++/Motif a couple of years ago.  I first looked at MFC and found that to be horribly designed.  I looked at VB (don't know what version) too and was disturbed by all the weird artifacts from its Basic roots (the many uses of DIM seem pretty pervese).  Java is a nice language (especially for a C++ programmer), has nice OO GUI components, and with JDK 1.3 (which has been out for 1+ year) is definitely fast enough for GUI work.

Neil Weber
Monday, October 22, 2001

This has been an entertaining thread to read. We use VB6 for most of our development work with C++ thrown in when necessary. It works well and lets us churn out the Deliverables on time!

IMO its not so much the specific language but the quality of the structured code that is important.

Our rule of thumb is "How easy is it for another developer to debug the code?"

(Check out this C code: http://research.microsoft.com/~tball/papers/XmasGift/ as an example of how unreadable unstructured code can be)

VB code is great if the programmers have a defined coding standard that forces them to write modular OO style code.

I would like to see some of the sample VB code that Joel has produced for City Desk (or their Coding Standard). Then we could really discuss the merits of the different coding styles and which language suits which tasks. 

Nishith

Nishith
Tuesday, October 23, 2001

I think you miss Joel's point.  Look past the syntax.  He was extolling VB's RAD capabilities.  Sure you can use Jbuilder, VCafe, etc to drag and drop Java screens, but it just doesnt come close to a 10 year old refined GUI tool like VB.  You won't understand this until you do a real example side by side, WITH a timer.

PS: Just changing the PLAF to "windows" isn't an "authentic" windows app.  But since you've only coded Motif GUI's, it is doubtful that you have ever created a slick clean GUI anyways.  It must seem great to you, which is understandable.

SSSSS
Tuesday, October 23, 2001

I've programmed in the usual list of languages (C, C++, VB, Delphi, Tcl, Perl, Python, etc). Historically, most languages seem to be very good at the computational, conditional and looping control side of things (eg. Your integer/floating point math, your if/then statements, your while/for statements)

Joel feels that automatic memory management is an important point as well, something that is less common. Along with this however, I'd add at least 3 main structures that a language should support intrinsically in an efficient and well planned way:
1. Strings
2. Lists
3. Hashes/maps/associative arrays/dictionaries/or whatever your language calls them

Historically, C was probably the worst for each of these, especially 3 which is non-existant. Most scripting languages do well at all of these, to lesser and greater degrees. C++ now has some really powerful stuff with the STL and boost libraries. Lisp derivatives seem to love 2 especially. Surprisingly even modern languages like Java seem relatively poor on these (non-dynamic arrays?).

Whenever I use VB, it's the poor support for 2 & 3 above that really annoys me. I don't know if it's still true, but I remember reading that string concatenation was on O(N^2) operation under VB. VB array support is horrible, and maps were an additional component, rather than an inbuilt language feature.

With regard to language syntax, I think most arguments are generally pretty much hot air. {} vs keywords vs indenting are all relatively minor points in comparison to core data structure support in my mind.

However, I must admit to having a bias here. Everytime I used Perl, I used to be really pissed off by the 'noise' level of the language. Over time though, I've grown to really like it, as well as Larry's design ideas of 'huffman coding' a language. Basically the idea is that the most common things you want to do should be easy, and hard things not impossible. This extends down to how much typing should be needed for basic language features. This thinking manifests itself all through perl, including really deep support for 1, 2 and 3 above.

A biased example. Given a CSV file with two columns, create a list with the second column value where the first column contains the text 'blah'.

open(F, 'thefile.txt');
@res =
  map { $_->[1] }  # Return second item of pair
  grep { $_->[0] =~ /blah/ }  # Select pairs where first item contains 'blah'
  map { [ split(/,/, $_) ] } # Create list of (v1, v2) pairs
  <F>;  # Read file lines as list

My next installment would involve core language libraries, something .Net and Java seem really good at, Perl and Python fairly good at despite the lack of centralised design policy, and C++ the worst until the STL gets more widely spread (how many libraries with their own string class have you seen?)

Anyway, just some thoughts...

Rob

Rob Mueller
Wednesday, October 24, 2001

I must agree with Rob Mueller's thoughts, and they were layed out very well too.

Bill Zimmerly
Wednesday, October 24, 2001

Often then language of 'choice' is determined by the environment you are employed in, or simply the employment opportunities that exist. For this reason, as someone said earlier, so many languages are simply 'noise'.
I love programming in Pascal or C, but I'd probably be living in a trailer if I did'nt learn VB.
Occasionally, as master of your own destiny, you get the opportunity to determine the technologies that you will use.
At this point, as a duty to whoever is paying the bills, one needs to be wary of the 'noise' and provide mainstream solutions. Philosopy is great, and its the issues raised in discussions like these that raise the bar (for development languages) a bit higher year after year, but theres no point even choosing superb solutions if they have faded into obscurity 2 years from now. At the risk of being howled down, I'd say there are about half a dozen technologies that are relevant at the moment, and it makes sense to warm your heart to all of them.

Tony McConnell
Wednesday, October 24, 2001

Speaking of the STL, I like the idea and I'd love to use it more, but I'm very concerned about the code size and compile time hits associated with it. With my primary compiler (GCC 2.96+) it seems like my executables grow several hundred KB the first time I use a list<foo> or whatever, and it ends up linking in all sorts of junk I don't want like istream/ostream etc. So I always end up writing my own little list functions anyway.

Have people been finding good compilers that provide more of a "pay-as-you-go" approach for STL?

(I realize this is getting pretty far off-topic so, feel free to respond via email)

Dan Maas
Wednesday, October 24, 2001

<
open(F, 'thefile.txt');
@res =
map { $_->[1] } # Return second item of pair
grep { $_->[0] =~ /blah/ } # Select pairs where first item contains 'blah'
map { [ split(/,/, $_) ] } # Create list of (v1, v2) pairs
<F>; # Read file lines as list
>

A classic example of a write-once, read-never language. :-)
The job in this example would be just as short but far more understandable if done in REXX.  But hats off to anyone who can read the above.  Enjoy it, glad you got the job done.

The point being, people should use the language that does the job and in which they feel comfortable.  If it's VB, fine.  If it's perl, fine.

My personal experience is that VB is very handy for prototyping, for small apps, and for the UI of larger apps (the core of these apps being written in something else).

Chris Dunford
Wednesday, October 24, 2001

Just wanted to add some more to my comments above.

On VB. Although I complained about the lack of lists/maps above, I have to say that there are some things I really like about VB.
1. Building a straight forward Windows UI in VB is nice and easy (yes, Delphi is good in this respect to). I idea of using 'packers' and 'layout engines' (Tk/Java) is sometimes neat because it allows easy resizing of windows and the like, but generally it's a bit of a pain when you just know what you want to stick down and where.
2. The COM integration is great. Being able to access all sorts of external libraries really easily and in a 'Do What I Mean' way is really powerful. This is especially true with VBA. I've created numerous (mostly smallish) applications using Access and Excel as basically front ends with powerful objects to build my code logic around. One place where this falls down though is actually trying to use both of them at once. Using DAO/ADO (basically the Access data engine) from Excel works fine, but trying to use an Excel object from Access seems to randomly freeze up and cause all sorts of problems. At least last time I tried (which was Office 2k)
3. Variants _and_ strict types. Sometimes you just don't care about the data type being used and want 'Do What I Mean' semantics'. This is often the case when dealing abstractly with DBs or data you don't know about. On the other hand, sometimes you do care about the type, because your about to create a giant array of Ints and want it stored efficiently. For most compiled languages, it's strict typing only. For most scripting languages it's always weak typing. With VB I get to choose my time/space/easiness tradeoff for myself. And it's all at the language level so I don't have to worry about calling helper methods, wrapper classes, casting functions, etc. Yay!

With regard to {} vs keywords vs indenting wars, I really meant with regard to _procedural_ languages. Of course whole different paradigms like functional and logic languages are another kettle of fish that you can argue on completely different grounds. I wish I had some time to try out OCaml and Haskell which look really interesting.

As I said, I used to think Perl was noise and 'write once' too. I think it can be, but the example I gave isn't, it's just 'concise'. Do you prefer reading legalise writing like "the aim, not withstanding other obstacles to the successful completion of the exercise, is to increase the general vibrational energy of the H2O molecules present in the ceramic container, or in other words, to create a strong level of brownian motion", or do you prefer "heat the cup of tea". I see Perl as the second, and some other languages as the first. Of course it's a bit different to that, because from your perspective the second statement above was written in Russian. I admit I've never used REXX so I can't really comment on it.

Rob

Rob Mueller
Wednesday, October 24, 2001

I completely agree about Java - I hate C - it just feels like walking when you could be driving. I really want to like Java. The language does many things in what I consider The Right Way(tm) and the API coverage is good for the sort of things I worry about (threading, databases, sockets, etc.). 

What I hate about Java is the speed and Swing. Java GUIs *SUCK* - slow and they're a usability disaster because they look like the system widgets but do not behave the same in every detail.

My ideal Java would do native code (or close speed) and have the native API available (JNI is handy but annoying for little things). It turns out that this almost exists - Mac OS X includes the full J2SE and allows you to use the Cocoa API directly. You can create GUIs which are just as responsive as Objective C GUIs (much of this is probably due to the way Cocoa interfaces work - it's a good thing, particularly for easy of maintenance and localization) entirely within Java. The apps are a little slow the first time they load (on a 400Mhz powerbook) but they do have some clever resource sharing so a second Java app can reuse libraries & such which are already loaded, which reduces load-time to very acceptable levels. If someone at Sun chose to create similar Win32 bindings for Java so you could use native widgets, or even just something like Apple's accelerated Swing (which uses the native Widgets for the default appearance instead of emulating them) it'd go a long way towards improving Java's acceptance.

That said, I'm increasingly fond of PHP. It has many language features I like and includes objects. While it's not native code, the Zend engine is quite fast and I've yet to have language performance be an issue and the fact that I've yet to find a language which makes me more productive makes it very attractive for other tasks. I'm interested in the PHP GTK project which allows you to create GUIs within PHP and have been thinking about a similar Cocoa project - unfortunately this would require adding some multithreading support, which could get interesting.

Chris Adams
Wednesday, October 24, 2001

Rob M:
>As I said, I used to think Perl was noise and 'write once' >too. I think it can be, but the example I gave isn't, it's >just 'concise'.

I disagree.  I think you're probably more comfortable with such "concise" code because you know the language much better than you used to, not because it's anything but line noise.  IMO good code should be at least somewhat readable even to someone who's not terribly comfortable with the language; this tends to be true of Python or Ruby programs, less so of VB or Java, not at all of Perl or APL.  If understanding a piece of code requires a hundred bits of language-specific knowledge to undertand, *it's bad code*.

Being "concise" doesn't count for squat.  The compiler or interpreter can do just as good a job with "verbose" code that's more readable to humans.  If the issue is how long it takes to type, then I'd ask why you're typing the same damn thing so often anyway instead of developing some decent libraries and abstractions.  Storage, bandwidth, and CPU time are all incredibly cheap compared to the money that's leaking out of your budget every time some poor sap has to spend several minutes solving your little puzzle before they can get their work done.

Jeff Darcy
Thursday, October 25, 2001


My corollary after this long discussion is: learn every language that is in use and can give you a stable job.

I've programmed in VB for living, but Delphi is just better. All the reasons above, plus more.

You know, some things are better than others. Delphi is better. Note that I think that VB is a pretty good tool, too.

Leonardo Herrera
Thursday, October 25, 2001

Correction on the statement made by anonymous:

"VB was a major change from version 4 to version 5 because it introduces class feature, which was the first step toward Object Oriented Programming. "

VB 4 did have class modules.  Many people did not notice. :-)

Rich
Friday, October 26, 2001

Regarding Perl's label of "write once, read never".  I disagree.  If you have trouble reading perl code, it may also be a reflection on the programmer, not the language or code.  Sure, its a function of many things, I'm just saying theres more to it than that. 

Yes, Perl is not as intutitive to read as other languages, but like anything, you need to put your nose to the grindstone, and figure the shit out.  Many people who complain about unreadability will also have trouble reading BASIC code. 

In my experience, most programmers are LOATH to read anyones code, regardless on language.  They just want to run out and write their own.  However, in the real world, this is a crucual skill to develop, especially when rewriting systems.  these proects can have non-existant analysis/design periods, since "all the specs are in the current app". 

I have maintained gobs of Perl code that was written by a team long gone.  It's not always pleasant, but it's all right there in the code.  you just have to suck it up and concentrate.

Ta ta

SSSSS
Sunday, October 28, 2001

<If you have trouble reading perl code, it may also be a reflection on the programmer, not the language or code.>

Nah.  "$_" simply doesn't have any intrinsic meaning to the human brain that has been raised on normal human languages.  Can you learn it?  Sure, absolutely.  But what's the point?  Why not use words or word-like names?  Quick, what is "$;"?  How many of those things can anyone remember without having to have the black book handy?

I've never understood the attraction of extreme shorthand in programming languages.  Is something better simply because it has fewer characters and is therefore faster to type?  I don't buy it.  Seems to me that human-like syntax is easier for anyone to understand than computer-like syntax, even if it's longer (or maybe because of that).

This is NOT a flame (you won't find many on this board, thank heavens).  I've tried real hard over a long period of time to like perl, and I just can't.  But I'm not passing any judegments on people who DO like it.  Different strokes for different folks.

Chris Dunford
Monday, October 29, 2001

Let's lay off the language bashing, shall we?  Most of it is ill-informed.  I've met very few people who are sharply critical of Perl who know the language well.  To those who rant about it, I usually ask, "why are pseudo-hashes a failure?",  "Why are prototypes useless in OO Perl?", etc.  Once you get to the point in Perl that you can start answering questions like that, maybe you have enough of an understanding of the language to criticize it.

This points to a basic flaw in the reasoning of most who criticize other programming languages:  they criticize something they really don't understand.  Perl, for example, is a huge language so it takes quite a bit of time to learn.  But if we're going to criticize a language based upon its perceived "readability", gimme a break!  Have you ever tried to read Prolog?  Haskell?  Those languages have a less than intuitive syntax, but that does *not* mean that there is anything wrong with them.  They simply happen to be examples of Logical and Functional programming, respectively, as opposed to the Procedural and Object-Oriented world that most programmers live in.

Perl is a language with a different paradigm than many others.  Unfortunately, many who are new to Perl do not realize this and walk away grumbling because it doesn't fit their idea of what a programming language should be.

You're not going to write device drivers in Perl.  You probably won't distribute a lot of GUI apps in it and forget about thread-safe code.  When it comes to text-processing or rapid prototyping of Web-based applications, you can forget about coming anywhere close to my speed of development.

And that's the point:  use a language for its strengths, don't use it for its weaknesses.  'Nuff said?

Curtis "Ovid" Poe
Friday, November 02, 2001

If I cant read it, I cant understand it.
And if I cant understand it, there has to be a good reason to learn it. Unfortunately with Perl - there is no good reason.

Tony McConnell
Monday, November 05, 2001

I get suspicious whenever someone says, "I don't think such-and-such is worth learning." It's almost never true, in my experience.

I've learned a fair number of programming languages. Some of them I really don't like, and I don't expect that I'll ever use them. (At least not voluntarily. ;) But I'm glad that I learned them.

Language designers tend to be smart people. Even the designers of languages that I dislike. When somebody creates a language, it's usually for a good reason. Learning that language helps me think in new ways.

Of course, the prospect of learning to think like Perl can still be kinda scary... ;)

Adam Spitz
Monday, November 05, 2001

Oh, right.  Since I've written Motif GUIs I don't know what a "slick" interface is.  That's moronic.  I've seen tons of "usability problems waiting to happen" written in MFC and VB.  It's not the toolset that makes the quality of the application, it's ultimately the programmer.

I've written a Windows Explorer-style application in Swing using JDK 1.3.1 and my Windows users don't even realize that it's not a native application.  Yes, it took more effort to write in Swing than it would have in VB but that's because the Swing component market is so small.  But my application runs on Windows 98, Windows NT, Windows 2k, Windows XP, Unix, Linux, and supposedly MacOs X.

Neil Weber
Tuesday, November 06, 2001

Neil, not a critique of your programming or design skills, but now you've written a cross platform application that looks like Windows Explorer, doesn't that mean you've annoyed every "non-windows" user out there by making them use an interface that is inconsistent with what they are used to, and what they are using in the rest of their current session? Wouldn't that potentially result in a hit on the user's productivity?

These sorts of cross platform user interface designs seem to benefit the programmer most of all, and inconveniance the users.

(Just to be clear, I'm criticising cross platform user interfaces, not code!)

Robert Moir
Wednesday, November 07, 2001

It sure bothers me when an application running under Windows doesn't behave like a Windows application, but then again, I also read the Windows UI design guidelines, and I use all the keyboard shortcuts I can get away with.

The average user uses the mouse for everything that's clickable. I suppose that's the reason why tool buttons that duplicate menu items make any sense: They are not nearly as fast as using the keyboard to go through the menus, but still much faster than clicking through them.

In the application I work on, I added keyboard shortcuts to move between the tabs on a tab control. To make it perfectly clear to everyone that there was a keyboard shortcut, I appended the name of the shortcut key after the caption on each tab. As it turns out, nobody seems to be using the keyboard (except one fellow developer) even though it's way faster.

Heck, I heard that even experienced software developers have been known to switch to Explorer for file operations that they used to do much faster in the old days using a simple command prompt. I fail to understand why.

My point is that most users will never know the difference between a native and a cross-platform UI, because they just don't know all the advanced things that you can do with a native UI.

Oh, and to stay on topic: I agree that Joel should have used Delphi to develop CityDesk. I wonder why he decided to use VB now that it has been made obsolete.

Johannes Bjerregaard
Wednesday, November 07, 2001


Some things in my brain:

Chris Dunford said about "$_". Sure, looks weird the first time you look at it. But its not harder to find in the documentation that, say, ThisIsTheVariableByDefault.

Perl was design to match the human thinking model, no less. That's why we have so many obscured perl programs around here :-)

On the other hand, I like Visual Basic, but I _hate_ some limitations. For example, a couple of months ago I needed to fetch a webpage, parse it looking for certain elements, and then bring the content in our web page.

Which I did in Visual Basic _AND_ Perl. And it tooks me less than an hour.

(Created an instance of a ActiveX object (URLFetch, now defunct, I'm afraid), fetched the URL, then created a WSH component, then parse it with Active Perl :-)).

Bottom line: it's not the language, it's the approach. It's the way you use to solve the problem, not the tool used to solve it.

Leonardo Herrera
Tuesday, November 13, 2001

Ah! many verbose words about VB, but out-here in the world of languages lays a little unknown one, and before anyone dares shout out the odds. Be quit. It's called
CLARION. I can hear all manner of voices already, but before you but fingers to key's. It has a place and it does a it's job well. It, im my opinion has the best compiler around. It is fully OOP's. Runs like hell, AND.. if I may say so, in the hands of a good coder, can outstrip development time with those who use VB. Know, having said that. I must just say that I'm not against VB. I've used it on number of occasion. O! well, just my little say. It's worth a look at.

Regards
Nigel

Nigel Soden
Thursday, November 15, 2001

As usual, a provocative article. I have two unrelated comments to make:

1) re. memory management: Couldn't agree with you more. However, I think there is more than one feature in languages that help me become more productive - another I can think of is pre-packaged containers and a methodology of containing things. This is a common **necessity** in most "brain-alive" programs, and I find that languages which have these features and make them easy to use are a boon. They let me get on with solving the business problem without having to worry about what the language will or will not permit me to (Perl, Java and STL all come to mind; just for the purists, my vote in this area is on Perl).

2) Your comments on Java are bang on! I think its popularity has as much to do with its being over-hyped (read ovvvvvvvvveeerr-hyped) by Sun; in my mind it is a easier C++. The attempt to paint Java as the only language for server-side programming might appeal to some, but to me it makes no sense at all... how many times does one really run a server-side application on multiple platforms?

Dileep Krishna
Monday, November 19, 2001

>  Which I did in Visual Basic _AND_ Perl. And it tooks me less than an hour.
> (Created an instance of a ActiveX object (URLFetch, now defunct, I'm afraid), fetched the URL, then created a WSH component, then parse it with Active Perl :-)).
> Bottom line: it's not the language, it's the approach. It's the way you use to solve the problem, not the tool used to solve it.


Speaking of approaches, if you're already parsing with perl, why do the HTTP stuff in VB ?  Seems pointlessly convulouted.  Any particular reason you didnt use LWP::UserAgent  to get the HTML?

SSSSS
Tuesday, November 20, 2001

Let's start with a comment on the UI design of this page :-)

There is a message in this discussion that starts with "I just want to say that Joel's approach to software development, and his writing style that brilliantly reflects it, are second to none." and right next to it I see "Joel Spolsky" as author which made me wonder if this was irony or a poster with false name. Then it occured to me that the author is mentioned at the bottom and not at the top of an entry. I think there should be more visual clues in the layout that make clear this association.

Second is the comment on Java. I took up C++ very early and since then I am admiring it bridging low level and high level programming, perhaps even the macho bit of it. While I would personally be happy to stay with C++, work requirements got me working with Java, first in the early Java days, then again since the begin of this year.

My experience so far is that Java is over hyped regarding portability, when it comes to GUI client development. It never worked out that code ran nice without modifications on a different plattform than the development one. In fact the only nice Java plattform for GUI development IMHO is Win32. The other plattform is Linux and (perhaps I have no experience) Solaris. And these two already lack behind in various aspects (quality, release dates of various packages).

Another item is that I know how to write portable C/C++ code for various Unix systems or Windows. I still like a good port,
which makes use of the weaknesses and
strengths of a platform much more than the
common denominator approach that the Java
meta platform offers. I still believe that a software that got ported to many platforms tends to be a good software, because it will force the programmes to separate application and platform specific logic which will lead to better overall organization.

Next thing is managed code:
Garbage collection is nice. But relieving the burden from programmers to care about memory management seems at the other hand to make it too easy for them to forget about memory and thus to waste memory.

Java is generally bashed for its poor speed because of its VM interpretation, however here it made really astonishing progress in the last years, the hot spot VM makes a big difference. But the real problems I typically face is first related to the memory waste, which in turn leads to cycle waste when the system copies around data.
I believe optional garbage collection plus the use of good memory debugging tools like Purify is the better approach.

Then I am surprised how much weight is laid on the language. I believe Java teaches how important libraries are.
Wasn't this one of the strong points of C in comparison to Pascal, that C had the better standardized libraries?

At present I believe Java has better libraries than C++. The Java libs are modern, they were written by people who learned the design pattern lessons and working with the Java libs exposes one to this style of programming. Second the Java libs are easy to use and well documented. Ever tried to work with C++ streams? How many C++ programmers have the Iso C++ standard available?
Third they cover a wide range.
Sun has done an excellent job here.
Third is standardization. All supported Java platforms get similiar c
apable compilers, debuggers and libraries.
For C++ there is Microsoft C++ in the Win32 world and g++ everywhere else, which is of very different quality on its platforms.
C++ would benefit from a commercial force that would improve libraries and push out good quality tools for all plattforms.
Sun won't do this. Microsoft was never really promoting other plattforms.

Oh and Python is definitly an improvement over Perl. Perl is notorious for programs that noone understands after a few weeks of not looking at them. Python programs are easier to understand. Like Perl they have a great collection of libraries and the documentation is excellent. And there is Ruby, which seems to be a hit in Japan, if I judge it from the Ruby contributions from Japanese FreeBSD users.

Lets end with the question, why non-imperative languages have not gained more popularity. Prolog, a logical language is pretty cool. Lisp, Scheme, Haskell, Caml cool functional languages. Squeak, a Smalltalk descendant, is cool.
But none of them got really spread.
Is it because they need more learning effort?
Is it because their libraries are not general enough?
Or is it because they don't interface well to systems programming?

Marc van Woerkom
Saturday, November 24, 2001

P.S. Why is there no preview for submissions?

Marc van Woerkom
Saturday, November 24, 2001

The issue of java performance on the client side will be a non-issue very soon. Processor speed doubles every year, and the chip makers (Intel, ARM, etc.) are working on optimizing the execution of Java.

The difference in programming between Java and C or C++ is akin to the difference between programming in C and Assembly. Very few people code in assembly anymore, and very few people will code in C or other languages in a few years time.

I am not a genius programmer, but I have done serious programming in VB, C++, and Java. And, I have read books about Perl, Scheme, Lisp, Pascal and a variety of other languages.

It should be completely obvious to anyone with more than five years experience of commercial programming, that the features that Java offers will become standard requirements for programming languages in the future. Even Microsoft concedes this with the C# clone. There will be programming done in C and other languages, but only for a minority of specialists, like device driver writers.

Interested Observer
Thursday, December 13, 2001

I have some observations that seem to have eluded everyone else in this thread:

1) Yes, managed code is (much) easier to use. That's why such management is integral to the design of good C++ classes (exception safety in the STL, et cetera).

2) "Managed" code tends to manage memory, not other resources (UI widgets, file handles, network connections). Since managed languages like Java lacks desctructors, you're cut off from the beautiful and pragmatically convenient sandwich programming offered by C++.

3) VB allows people-who-don't-understand-indirection to write programs. I won't say this is bad, but this cognitive limitation of theirs must surely limit the kind and quality of program they can write. Perhaps pointer arithmetic and indirection is as good a way as any to separate the wheat from the chaff :-)

VB's "ease of use" does not turn amateurs into professional pro­gram­mers; it is no substitute for ac­tu­al knowledge and experience. Which is not to say that good programmers can't do good work in VB, of course...

http://pethesse.home.online.no/

Petter Hesselberg
Monday, December 17, 2001

Does it bother you that MS might not support your programming language choice two years from now? 

Christopher Baus
Friday, February 15, 2002

Everytime I consider using Java, VB, or C# for serious work I realize how much I like C++.

I love having simple protocols to eliminate whole classes of errors. But maybe it's time to move with the times.

A question for former C++ users - how much do you miss the resource allocation is initialization  idiom? What does not having deterministic destruction feel like? Does error handling without resource leaks get harder?

Ed Kaulakis
Friday, March 22, 2002

I am a novice for Powerbuilder and like to implement product management web solution using Power builder 8.0.
I have an expertise using ASP, VB and other MS tools and technologies.
Do anybody know about Powerbuilder 8.0?
As you know that I have an fear to go for new tool. and starting from scratch with PB8 etc.?
I have used PB4 in past. but it was long ago.
Now what to do with this dilema?!!
anybody pls. help for comparision of PB8 and VB.NET solution.

Nilesh Trivedi
Saturday, August 31, 2002

'An ode to C++.'

2000 years worth of engineering progress after the end of the Egyption civilisation and what are we left with?  A language that only Egyptions can understand.'

Darren
Tuesday, October 01, 2002

<
A biased example. Given a CSV file with two columns, create a list with the second column value where the first column contains the text 'blah'.

open(F, 'thefile.txt');
@res =
  map { $_->[1] }  # Return second item of pair
  grep { $_->[0] =~ /blah/ }  # Select pairs where first item contains 'blah'
  map { [ split(/,/, $_) ] } # Create list of (v1, v2) pairs
  <F>;  # Read file lines as list
>

And in Python:

w = [i.split(',')[1] for i in open('thefile.txt','r').readlines() if i.split(',')[0].find('blah') != -1]

or:

w = []
for i in open('thefile.txt','r').readlines():
      fields = i.split(',')
      if fields[0].find('blah') != -1:
            w.append(fields[1])

Steve Lucy
Monday, December 30, 2002

site not useful for students

raje
Thursday, September 11, 2003

</title></head></script>

unnamed
Saturday, January 17, 2004

*  Recent Topics

*  Fog Creek Home