Posted by Roblimo on Wednesday October 27, @07:18AM EST from the VB's-still-on-top-but-Java's-moving-up dept. Anonymous Coward writes "Zona Research has polled a group of developers regarding their favorite development tools. Visual Basic is far more popular than I would have previously thought, given the amount of griping I hear about it. Not suprising that C is still quite popular. Java finishes third...due to its relative youth, or are developers simply not using it that much?" The story's from Yahoo.
Don't have an account yet? Go Create One. A user account will allow you to customize all these nutty little boxes, tailor the stories you see, as well as remember your comment viewing preferences.
I love Java - really, I do. It's a wonderful language. But 3rd out of programming languages? I think I've seen one serious application that was written in Java (Shiva NetManager) and that was just a utility. I always thought people were avoiding Java because of speed/platform issues, but am I wrong? Is there a mass of Java programmers out there with an equally large collection of programs?
-----------
"You can't shake the Devil's hand and say you're only kidding." - They Might Be Giants
I always thought people were avoiding Java because of speed/platform issues, but am I wrong? Is there a mass of Java programmers out there with an equally large collection of programs?
I've used Java intensively for many different purposes, and I almost always run into problems when dealing with cross-platform usage of multithreaded programs. thread scheduling, for some reason, is in the Java language specification specified to be left unspecified. This leaves the implementers of the virtual machines free to select whatever model they desire (and that is usually the simplest: non-preemptive fifo-scheduling), complicating development of platform-independant multithreaded applications (where one often expects time-sliced, "fair" scheduling of some sort). One solutions is to do as we've done in the Actor Foundry and implement a dedicated scheduler in Java. That way one can be sure to have threads scheduled in the way one wants....but at the expense of performance.....
Another drawback with Java is the lack of an updated language specification (at least last time I checked there had been no updates for a few versions).
I think Java is being used....but I also think that the language still has a way to go before being "mature" enough - part of that way would be completing the specification such that the virtual machines behave alike (and such that the "write once, run anywhere" can be delivered as promised by Sun...).
...thread scheduling, for some reason, is in the Java language specification specified to be left unspecified.
AFAIK, the reason thread scheduling is left unspecified is that all the platforms that can run a JVM do not all have the same threading capabilities at the Operating System level.
AFAIK, the reason thread scheduling is left unspecified is that all the platforms that can run a JVM do not all have the same threading capabilities at the Operating System level.
Obviously you may very well be right on that point. The thread-models in Linux, Solaris, Windows, MacOS etc. differ on many aspects (user- or kernel-space threads, based on scheduler activations - in Solaris "Leight Weight Processes - etc.)
However it doesn't change the fact that this may (and indeed does) violate the principle of "platform independance": the programmers of (multi-threaded) Java applications need be aware of on which platform(s) his/her applications will be running. Or alternatively go through the troubles of writing dedicated, thread-scheduling code or other "workarounds".
However it doesn't change the fact that this may (and indeed does) violate the principle of "platform independance": the programmers of (multi-threaded) Java applications need be aware of on which platform(s) his/her applications will be running. Or alternatively go through the troubles of writing dedicated, thread-scheduling code or other "workarounds".
This is true. If you do need a system that, for example, requires prioritizing of the Java threads, you have no choice but to write your own scheduler. It's the only way to get a guaranteed behaviour out of your application on every system.
Problematic, indeed. But then, if you compare the threading models of NT, Solaris and Linux for example, and try to figure out how to abstract the systems so that you can guarantee a similar behaviour under all those systems, my guess is you quickly find it extremely difficult to do.
Green threads are an option, but the cost is quite expensive.
IMHO, threads are such a low level feature of the OS, much like the memory allocation or pointer semantics, that either you go with the "mostly platform independent" way, or have to revert to something like green threads that don't scale.
This is true. If you do need a system that, for example, requires prioritizing of the Java threads, you have no choice but to write your own scheduler. It's the only way to get a guaranteed behaviour out of your application on every system.
I just came to think of Posix-threads. It's been a while and I haven't used them much, but doesn't the specification imply that one can set the scheduling policy (e.g. round-robin, priorities ) and other properties for the threads? Many systems comply to the Posix-standard without the underlying mechanisms being identical. I think Solaris with "leight-weight-processes", WinNT with - afaik - pure kernel-thread, and Linux with a different model for threading.
It is true - definite control over the execution of multithreaded programs require a dedicated scheduler. But it would be nice had Sun / JavaSoft actually specified one scheduling behaviour (rather than not specifying one as it is).
That way we would have the same execution across all platforms - and only those needing a specific or advanced scheduling would need consider implementing a dedicated scheduler.
Thread scheduling, for some reason, is in the Java language specification specified to be left unspecified. This leaves the implementers of the virtual machines free to select whatever model they desire (and that is usually the simplest: non-preemptive fifo-scheduling), complicating evelopment of platform-independant multithreaded applications (where one often expects time-sliced, "fair" scheduling of some sort).
Surely that's just a J(V)M QOI issue. If the implementation you (or your customers) are using is crap, bitch to you J(V)M vendor about it (or tell your customers to) until it gets fucking fixed.
And if it doesn't, change vendors.
If your bosses (or your customers) ask you to write stuff that's going to run on a broken platform, what else can they reasonably expect but a correct, well written implementation that happens to perform badly on said pile-of-shite platform.
I also think that the language still has a way to go before being "mature" enough - part of that way would be completing the specification such that the virtual machines behave alike (and such that the "write once, run anywhere" can be delivered as promised by Sun...)
I thought that a version of the language was complete? (completely specified that is). Do you mean you think that current implementations of the J(V)M have a long way to go before being able to be classed as 'mature'?
Surely that's just a J(V)M QOI issue. If the implementation you (or your customers) are using is crap, bitch to you J(V)M vendor about it (or tell your customers to) until it gets fucking fixed.
It's not only a vendor problem (unless you're using green threads).
On most systems the JVM uses native threads for performance and scalability reasons. Now let's take a look at the Java API. In java.lang.Thread there exists 10 levels of priorities for Java threads. Now let's see how this maps to a native thread system of say...oh so dear Windows NT.
On NT you don't have process priorities in the same sense that most Unixes have. Instead, what you have is thread groups (Low, Medium, High, Realtime) and each of these has 7 levels. So let's say our JVM runs on the High priority group. There's only 7 levels there, yet we have 10 in Java threads. There must be some overlapping going on here! So you cannot guarantee that your Java thread with priority of 7 is lower than your Java thread with priority of 8. Maybe they map to the same level 5 on the native threads!
Then take a look at the thread model Solaris uses... and Linux which clones light processes... it gets very messy real quick.
So its not just a vendor problems. Java leaves alot to desire when specifying threads, and mostly the reason is that abstracting all the thread models of the world is a pretty difficult thing to do.
Allen Holub has a great series of articles on Java threads. He goes into some length in explaining both the threading models of both NT and Solaris. He also nick names the NT thread system as an 'unholy mess' which is quite amusing :)
I didn't realise (having not looked incredibly closely at the Java threading spec) that it didn't even specify whether or not java threads were pre-emptive, co-op or a combination of the two.
In some cases, yes, implementation-defined behaviour is 'not too bad', but for something of that magnitude to be left out, especially in Java (where you're supposed to be able to 'write once, etc...), seems like such a cop-out.
(Almost as bad as the fact that operations on long (and double?) are not guaranteed to be atomic. What an ugly, unsymmetric piece of cruft that is.)
I thought that a version of the language was complete? (completely specified that is). Do you mean you think that current implementations of the J(V)M have a long way to go before being able to be classed as 'mature'?
To answer your questions: as far as I know, there is no current publication "The Java Language Specification", which specifies the language in all its glory. There exists an OLD version (for version 1.0 of the language) and an appendix, (patching the specification to 1.1), check here. But there is nothing current, i.e. for the current versions of the language. This complicates making a JVM and writing applications - and of course makes it more difficult to decide to blame a problem on the provider of the JVM or on the application. Instead, Sun/Javasoft have specified a comprehensive testsuite, which is supposed to ensure "standard compliance" (check here). I have not tested this, thus I have no opinion on that.
That said, the JVM's still have a long way to go before being mature. In particular the JVM provided by Sun for Solaris is disappointing in speed as well as other aspects (while the JVM provided by Sun for MS Windows is suspiciously optimized....).
At my company, we have implemented a complex time-series calc engine for financial data. It is implemented entirely in Java. We built it because there is no equivalent off-the-shelf application on the market. This application is way more complex than you can imagine and is definitely a "serious application".
Java is now our standard, enterprize development language. Legacy maintenance code is still in C, C++, and Perl. As the execution speed of Java increases, I do see Java replacing all of these.
I can honestly say that after coding in Java for the past 6 months (coding C the past 4 years), it is far quicker to implement a lot of stuff using Java than C. This is why Java has become our de facto development language.
It is not really a question of 'Is Java being used?' it is a question of 'Where is Java being used?'. You are right in that there are not a huge number of end user Gui Java apps out there supplanting native versions of software. Cross platform issues and past problems with the languages architecture & speed (which have since mostly been corrected) kept this from happening. However there are areas where Java is very well suited to the tasking and is rapidly taking over. The article mentioned one area but only caught the tip of the iceberg. Middleware. Java is rapidly taking over the middleware arena. This is an area which is not very visible to the average person but is a huge market with a lot of developers. Another place Java is really catching on is the server side of the web. How many of the dynamic pages you see were generated by a servlet, and if they were could you tell?
As an aside, I'd like to comment on the issue of speed problems. If you think that Java must be slow, you are mistaken. Java 1.0 was slow. Java 1.1 and 1.2 do not have to be. My experience has been that Java makes it easy to write slow programs, but that a properly architected program written by someone who understands how Java functions executes very fast. There are also options like native compilation, Hotspot, JIT compilers, and modern VMs which combined with a properly written program will result in very good performance. No, Java is not fundamentally as fast as something like C or Fortran, but the idea that it is too slow to be useful is obsolete.
"Linux is a beautiful thing, but beauty is in the eye of the beholder, and we're geeks. Support BeOS too so non-geeks can have a little beauty in their lives."
I think the only thing wrong with Java is that Sun tried to make everybody think that it was a wonderful architecture for writing client side software. In my few experiences with that I've found it to be bloated and inefficient.
Now, having said that, I use Java constantly to develop the server side of thin client apps (Servlets, JSP's and slowly gettting into Enterprise Java Beans). They are flexible, robust, and there are far fewer concerns about quirks between different JVM's because it need only run in one place.
--- What would happen if there were no hypothetical situations?
The company I work for is using Java and making pretty strong commitments to it in the future. However, what we do is in-house development and very specialized, so you won't see it unless you work for us.
We haven't run into that many platform problems, although the range of platforms we need to support is fairly limited. We are also mainly using it for applications and servlets, not for applets.
As for speed, for most things it has been adequate, although I am currently running into a few problems on one project. I am not sure its the Java code or the database (most of the CPU usage seems to be in the database).
Java is being used very heavily within large corporations for their own vertical systems. I worked at FedEx on their internal weather system and also for their ramp dispatch systems (fueling, deicing, maintenence). These systems have equipment that range in size from Sun Enterprise 6000s to various RF enabled handhelds and interface to all sorts of equipment (GOES Weather satellite ground stations, time clocks, GPS, mainframes, etc.). All in java.
Currently I'm working at a large European airline where we're developing all kinds of bleeding edge stuff, including e-commerce on mobile phones. Java gets used heavily for this type of stuff, it's just not very visible to the end user.
Java is an utter pain, in comparison to C. My school seems to prefer it for its more advanced programming topic courses for some reason (C++ is taught in the first 2 courses). System.out.println() to print text? What idiot thought of that? And don't get me into text input, especially on threaded apps, or, even worse, conversion between different variable types (eeek! its a different method for each conversion!). Combine this with a complete and utter lack of typecasting (no, you can't do if (a), where a is an boolean variable (or other type), you have to do if (a==true) (and it just gets worse from there... much worse)
Why anyone would prefer java is beyond me, unless you really *like* slowdowns and writing 3 times as much code.
Use straight C. No ++. No visual. Just C. Objects are slow, and a pointless method to do programming on all things that don't have an inherent, "physical-object" nature, such as a windowing environment. As a general rule, arrays and structs produce far more efficient code and add to clarity by not hiding what is running which function, in addition to giving the programmer a much better grasp of the actual state of the system (what instructions are being executed, and especially, what the memory looks like).
This and many other reasons is why, for most tasks, I prefer to use C. I've never used Perl, but I've used Scheme which is similar (I'm writing a scheme interperiter in scheme) and while it is a nice language for theory, its forced "make everything recursive" is unnatural for most tasks, and a performance drag. Java... well, unless being able to run your program on every platform in existance is extremely important to you, don't bother.
And use VB if you're too lazy to learn how to program for real - you don't even get the "every platform" option Java claims.
System.out.println() to print text? What idiot thought of that?
The kind of idiot who decided that System.out.print() was better than printf() is the one who realized that a) it makes sense to chunk system stuff into objects and b) that making you call System.out will remind you that not all platforms HAVE a standard output (remember how Java is cross-platform compatible? Well, it isn't if you call System.out methods!)
...or, even worse, conversion between different variable types... this with a complete and utter lack of typecasting...
Casting is unsafe. The people who designed Java knew that. C is unsafe, Java is safe. There are good reasons for both.
Why anyone would prefer java is beyond me, unless you really *like* slowdowns and writing 3 times as much code.
Err... Java programs are 3 times as much code if you're writing trivial programs. Hello World is quite a bit bigger in Java than in C. If you use Java's OO features well, you will find yourself writing considerably -less- code than you would in C. Not to mention that it's easier to debug (remember how Java is safe? That means you can catch bugs better.)
As a general rule, arrays and structs produce far more efficient code and add to clarity by not hiding what is running which function, in addition to giving the programmer a much better grasp of the actual state of the system (what instructions are being executed, and especially, what the memory looks like).
I'm really surprised that you would make a statement like "arrays are the clearest way to understand your program" after programming anything in Scheme. C memory-isms may be the best way to understand what's happening at the machine-level, but they're a real pain for understanding what's happening at the top level.
In short: if you want to program big things, you'll find that higher-level languages are far easier to use than lower-level languages most of the time. C is one step away from assembly language. That was intentional. Assembly language is a good thing to program in sometimes. However, you'll find you're a lot more productive (as in, you can finish your program faster and make it work better) if you program in a language that provides better tools for abstraction. Allowing you to name functions and call them multiple times with different arguments is certainly not the end-all and be-all of code reusability.
[Scheme's] forced "make everything recursive" is unnatural for most tasks, and a performance drag.
As a side note: it turns out that you can translate recursive functions into non-recursive functions automatically, so that they don't waste stack space needlessly (which is actually the only performance hit you take for a recursive function). Good Scheme implementations do that: if you want proof, run an infinite recursion in Scheme, such as
(define recur (lambda () (recur)))
You'll find that it runs forever. Now run the C version:
void recur() { recur(); }
You'll find that it runs out of stack space after awhile and dies.
(Oh, and if I were you, I wouldn't go around saying things like "Scheme is similar to Perl." Scheme people and Perl people hate each other [half-joke], and their languages are pretty durned different.)
And not all systems HAVE a 400mHz CPU or 32MB of RAM either, though there's no abstraction in Java to remind you of this. Java brings about that need to upgrade hardware regularly that some people installed Linux in part to avoid. I'm glad that Java is still limited to private, corporate networks, and hope that I'll never need Netscape 6.0 just to be able to use a search engine.
Seriously, though, the current implementations may not be great in general, but that's not due to the language. Did you read the article a while back that mentioned that Sun's JDK 1.3b1 has beaten C in some speed tests? (Not C++. C.) Encouraging news.
Relax about Java performance. It's not honestly all that bad, and it's getting a lot better all the time.
Java is a very serious language, and is starting to be used in profitable production systems. Our company use Java for E-commerce applications: communcations brokers, database agents, and a few front-ends. Our products are used for electronic distribution of Airline and travel reservation systems and are high-volume. However, these are fairly new components in our application systems. At lot of parts work in C and will continue to do so for quite a while. The back-end legacy is too immense to port in a quick-delay. There is an on-going re-engineering task force, but it will be a very slow process. As someone else responded later on: the poll is far from fair: a sample of 150 programmers is too small a sample to be representative. take slash-dot for example. The people posting on this thread are a very good random sample of programmers: I'm sure compounding statistics of the use of programming languages here would yield very different, and probably more conclusive results. Then again, you could argue that only *certain* types of programmers subscribe to slashdot, and that these are more likely to favour certain paradigms over others. In any case, you have garantee of random population sample, and a much larger sample group. Your email has been returned due to insufficient postage.
Re:Java's in third? (Score:0) by Anonymous Coward on Wednesday October 27, @03:43PM EST (#271)
In Oracle 8i, you can use Java instead of PL/SQL for writing stored procedures. So, at least in Oracle subculture[s], Java is growing by leaps and bounds as a useful programming tool!
Java may be handicapped by performance or design mistakes, but that's not the reason that it has not caught on. Big companies make very conservative decisions when selecting programming languages. They will only switch to a new language if it is already popular.
Everybody seems to be training their programmers in Java, but few are actually making the dive. This is similar to what happened with Pascal. Ultimately C beat it out because of its special ties to UNIX. That created a pool of experienced C programmers and reusable code which provided the critical mass necessary to attract attention. Visual Basic got the same sort of boost because Microsoft threw its weight behind it.
Java needs to secure a market niche so it can develop that critical mass. Web applets didn't seem to be enough to tip the scales, but with a bit more help it could displace VB.
You're absolutely right. VB may have still come out on top for "building business applications" but who did they ask? "Developers." That's a pretty big umbrella, and how was the question phrased? What were the other languages that made up the last 35%?
Perhaps they were thinking of who commissioned the study. Who *did* comission the study? That can influence the survey design quite a bit, as we have seen way too much lately. Too many of these "pundit tanks" seem to be able to offer "identified trends" for sale... -=Maggie Leber=-
Delphi? You expect the same results as the recent Inprise/Borland language survey that graced /.?? Seriously though...
Although it has many very zealous supporters, Delphi really isn't that popular in N. America, which is where I suspect this survey might have been based. Delphi is more popular abroad, but last time I was in the UK (a year ago), a look at the job listings showed VB as king, followed by C++ and Delphi (almost even at that time). When I say "king" I mean the shear number of positions available, not how much they were paying. I've just left a job where a team on another project was using Delphi (Denver) - they found it very hard to replace people, and most of them felt that it was a dead end career path as finding a new Delphi was getting progressively harder as time passes.
There are many developers using Delphi in Europe, especially in Germany. I think it is called "Delphi-Developers-Conference", where more developers are attending this event than in N. America
Of course it depends on what you are programming, though I'd have to disagree with you on real world programming.
If its Quick and Dirty the real world uses Visual Basic. Who cares if it's slow when the slowest desktop I have to support is a PII 300. We've got far too much power on the desktop. I can get a PII 300 Celery MB for just over $100, so my software costs more than the hardware...
VB is also fast enough for most webapplications, so perl is out of the question. I use Perl for NT on a few apps we may convert over to a mainfram platform, but most are not going to deal with perl in the real world.
Java...no one uses this if they want stable applications. This will change, but not soon. If I want a GUI I use the Web as the front end and my server as the application host. If ya want it standalone, use VB as a front end and C as the back end. I use to do this with Hypercard on the Mac,and ya'd have a easy to change GUI as well as a fast back end.
If ya want only speed, and a hell of a long programming time, go C or C++.
If ya want a decent GUI as well as a fast backend and ya want RAD where it is most applicable, go with the hybrid approach. As most of my C stuff is portable, I'm actually thinking of learning the KDE toolbox one of these days and using that as the front end on Linux (some one needs to port this to Win and the Mac...make my job easier :)
clif Editor Sonikmatter technology + music + kurzweil
I guess it depends on your definition of "real world". I've been programming in the "real world" for 17 years (not counting my university co-op work placements), and I have yet to write a single line of code that will run only on Microsoft platforms. I've done FORTRAN on mainframes, about a dozen varieties of Unix using C, C++ and perl, and for the past two years I've been writing Java code on Linux that gets released on Windows and Solaris.
That's why I said in my original post what I use, not what the "real world" uses.
--
Java leads to Javascript. Javascript leads to Shockwave. And Shockwave leads to ... suffering.
If ya want only speed, and a hell of a long programming time, go C or C++.
Well, this is kinda true and kinda not true. C++ has a steep learning curve, steeper then any other language I know of. For those who've reached the top of that curve, rapid development is possible. But it can take years to get there. In contrast, something like VB allows you to develop rapidly almost immediately. The difference is that C++ demands that you learn a hell of a lot just to be productive.
The other reason to use C or C++ over VB is that sometimes you just need more control over things then VB provides. Try to manipulate blocks of binary data, and suddenly VB isn't quite so easy.
Anyway, a valid poll wouldn't be comparing all languages. The real intereting question is not "C++ vs. VB" but "VB vs. Tcl". One of the problems we have right now is that C++ is more dominant then it should be in places were it frankly isn't the right choice. The reason for this, I think, is this attitude that there is a "best" language. There was a time when it was nearly impossible, in the non-Unix world, to justify using anything but C to management, regardless of the project. Fortunately, things seem to be changing. But it would be a real shame if we just replaced C++ with Java for all of our projects. Java is no more the solution for everything than C++ was.
Re:Dumb poll (Score:0) by Anonymous Coward on Wednesday October 27, @06:56PM EST (#303)
If it's Quick and Dirty the real world uses Visual Basic.
The real Windows world, you mean.
Here in the real Unix world, we write PERL scripts.
I think that VB's popularity is mostly due to the fact that it's very VERY easy to create simple applications with it. In the article, they talk about "Business Software". For PHB's, all that counts is the GUI, so VB is a lot easier there. :-)
To use any of the other languages, you need to be a Real Programmer. I think C or C++ is more used when what's under the GUI is more important (technical software?).
I think that VB's popularity is mostly due to the fact that it's very VERY easy to create simple applications with it. In the article, they talk about "Business Software". For PHB's, all that counts is the GUI, so VB is a lot easier there. :-)
Well.. then why don't they use Tcl/Tk or Python? ;)
TK is ugly and so not appropriate. The user interface is actually an important part of a program and when you have something visually disgusting like TK, you are hurting the application.
Actually, TK on windows doesn't look half bad. The TK widgets end up looking like windows native controls. My boss is not yet aware that my last two apps (for internal use only) were entirely done in Python. All he knows is that they were developed quickly, they have a nice interface, and they do ungodly amounts of complicated data manipulation behind the scenes (most of my devel time was playing with the algorithms). The biggest problem with using Tkinter is that the Tk event loop varies so much from the standard windows event loops. You can create Python COM objects, but embedding any Python Tkinter objects into another GUI (say in Delphi) is a real problem (that's where Pythonwin comes in). Despite this, I still tend to do a lot of work with Tkinter, for one good reason - I can work on my Linux box at home and bill my hours! q = ['print "q =",q,"; exec(q[0])"'] ; exec(q[0])
Tcl absolutely sucks. Python and Perl are both pretty cool and have decent Tk bindings. Python is probably easier to learn and maintain, but Perl is more flexible and makes the hard stuff easy once you've become proficient in it.
Tk is OK to work with, but the widgets don't quite look like native Windows widgets. Also, using Tk with Tcl/Perl/Python doesn't give you access to all the standard Windows controls like VB. That's a big problem in the Windows world where everything is supposed to look the same and use the same controls. Finally, VB is needed to extend/automate the MS Office suite, which is a common occurence in the business world.
The closest competitor to VB is actually Delphi. It's at least as powerful as VB, it's even more easy to use, and it (obviously) executes faster. The only downside to Delphi is that it isn't appropriate for MS Office based projects.
What really surprises me is how underused C++ Builder is.
|ON SOAPBOX| Because Neither of those have the abilities of VB. Before you respond with the usual "you can't do xxx in VB, or VB is not a 'REAL' Language" I suggest you learn it first. Writing a cutsy "hello world" app doesn't count. You want to know WHY VB is the Most Popular language? I has NOTHING to do with Talent. I would advise those that think otherwise to spend a bit of time learning ADO/DAO/RDO, MAPI,CDO,ActiveX and the Win32 API's and ASP development. Those are the tools you will find in your average "Business Application" VB has plenty of power, a decent learning curve (only Kiddies equate a steep learning curve with power) and is very flexable. Your average Programmer (those that write code for a living, not spend time bitching about how much they Hate this language or that platform) use the "Right Tool for the Right Job" and try to adhere to KISS (Keep It Simple Stupid! for those who haven't bothered to study the theory behind the code). Sure I can write a cool, quick interface in C++, but the code would be MUCH more complex and take MUCH more time than doing the same in VB. The Prevailing attitude amoung the kids that bitch about VB is that is regardless of the power, flexability, or ease of use, it must suck because M$ makes it. Listen up kids, I'll tell you a secret.... in the real world of those of us who write code to keep the food on your table we don't get to decide what platform to use, nor do we get to tell the customer "I'm sorry but I will need more time because I refuse to use a RAD tool to create this application for you". The platform is a corporate standard and the Deadlines ever tighter. Visual Basic is our favorite language because it means we get to go home somewhat on time and not worry about the pager going off at 3:00 AM.
Sure I'd love to write code on Linux in C++ (my favorite for personal use), and use a Tcl/TK front end, but it just ain't going to happen until they become Corporate Standard. Those a bit wiser have realized this. Linux has made HUGE inroads in the corporate world, but it's not there yet, and bitches about other platforms, or Development enviroments won't get it to where it needs to be. Focus on making Linux Better, not bitching about how bad the other guys are.
|OFF SOAPBOX|
I disapprove of what you say, but I will defend to the death your right to say it. —Voltaire paraphrased in The Friends of Voltaire, 1907
I Agree ... (Score:4, Insightful) by pvente on Wednesday October 27, @07:40AM EST (#18) (User Info)
What this survey proves is that the term 'developer' today is a far cry from the same term used 10 years ago. VB didn't exist like it does now (it was there, but it wasn't the same product). Large corporations like packages such as VB or Developer2000 for many reasons.
1) It's easy compared to the likes of C++ or java and because of this, you don't need to hire top-notch talent. The pool of available 'programmers' is much larger. Don't underestimate how important this is to a company.
2) They are RAD tools - much quicker development and turn-around times.
--That being said, these packages have their limits, especially when it comes to producing a large transaction-based system. I would never trust such a system built upon one of these packages.
I dunno, I recently moved from 80% VB, 20% C++ to basically 95% Java (J++). J++ helped me use the wonderful language Java is, without giving up my COM and ActiveX and Win32 API. Basically, it's only attractive to me because the language is BRILLIANTLY designed - not cause it's cross platform...
anyway, my point was Java is easier than VB in many ways....i can remember so many days of hacking away trying to add real threading support to VB only to fail horribly :). I tended to use VB as a shell for many components written in C++. I now do the same thing with java and WFC in J++....just with code that's nicer to read :)
To paraphrase Gore Vidal, it is impossible to underestimate the importance of top quality developers to most companies. The reason you don't have to hire top-notch talent to program in VB is that it makes it easy to write mediocre-to-awful code. As long as there's a GUI on top of it that resembles other Windows GUIs, then it's "good enough".
>The reason you don't have to hire top-notch talent to program in VB is that it makes it easy to write mediocre-to-awful code.
That's the bone I have to pick against VB. It parallels the myth that a GUI makes a computer easy to use.
The problem, in both cases, is that an "easy" interface to the job makes it possible for unqualified personel to give the appearance of getting by. That's fine in some circumstances, but it doesn't address the world's software crisis. Arguably it makes the crisis worse.
I once worked in a shop that used VAX BASIC. Kinda low-brow, but nothing really wrong with it per se (after all, it all compiles down to machine code). But the problem was that it made management think "programming is easy", and we ended up with people on the team doing incredibly stupid things, despite the fact that they could easily write a line of code that would compile.
The problem is that "easy" syntax does not and can not change the difficulty of the underlying problem. It makes sense to use "easy" tools whenever they are available, but the unfortunate side effect is that society, or at least your PHB, begins to expect intrinsically difficult problems to automagically simplify themselves to conform to the lowered bar of the language you're trying to solve them in.
-- It's October 6th. Where's W2K? Over the horizon again, eh? [991015: Now they're saying Maybe February.]
Yes! (Score:0) by Anonymous Coward on Wednesday October 27, @04:40PM EST (#283)
I'm not sure I totally agree with your point that a GUI does not make a computer easier to use, but as far as the VB quote, you are dead on IMO. That was one of the first things I noticed when first encountering VB and VB programmers: VB lets anyone write a Windows program. This is not a good thing. This is how you end up with database apps that do 4 full table scans to select a record.
Re:Yes! (Score:1) by Black Parrot on Wednesday October 27, @05:20PM EST (#288) (User Info)
OK, my gratuitous reference to the GUI was too brief to be useful, and I should have left it out. I was refering to an argument I made here several months ago (surely you all remember?) that the GUI makes a computer easier exactly to the extent that it filters access to the functionality.
If your computer is to retain the power of a Turing Machine, there is no such thing as an "easy" interface.
BTW, I am a habitual GUI user, so I'm not knocking them in general.
>This is how you end up with database apps that do 4 full table scans to select a record.
There was a fun tirade on comp.risks a while back, from a guy who partially reverse engineered a Windows program (one that ships with Windows, IIRC), and found all the absolute crap that was embedded in it due to being built by ease-of-use tools. And all that is in addition to the programmer-level cluelessness you mention.
-- It's October 6th. Where's W2K? Over the horizon again, eh? [991015: Now they're saying Maybe February.]
I agree that if the underlying problem is difficult, then a language like VB doesn't make it any easier to solve.
However, most of the problems out in the business world are relatively easy. VB is an enabling technology. It gives people who don't have the education or training to solve the difficult problems a way to work on the easy ones in an easy language.
VB is not chosen for it awfull Basic langage. But it's the best RAD IDE ! I've always dream of a real "visual" langage ... Delphi and JBuilder are good contenders, albeit not as "quick and dirty".
It's easy compared to the likes of C++ or java and because of this, you don't need to hire top-notch talent. The pool of available 'programmers' is much larger.
This statement is nonsense, and shows that you have totally misunderstood the reason. People use Developer/2000 so they can concentrate on the business not the tools.
You can be the greatest programmer in the world, but if you don't understand the business and can't get your application ready while it is still relevant, then you have failed in your mission.
Given that the professional Developer/2000 consultant brings both a technical and business expertise to the table, the pool of available talent is actually smaller than for conventional programming languages.
To use any of the other languages, you need to be a Real Programmer.
You have to be a Real Programmer to use any language other than VB? Being an avid C/C++ and Perl enthusiast, I find it rather interesting to have myself compared to this definition. Is there something vaguely reminiscent of bit bashing in hacking C/C++? I am well and truly boggled by the very assertation.
~ Kish
If you have something intelligent to say, you'll log in or get moderated up so I can read it. Otherwise, you're wasting your time.
Ha! (Score:1) by Greyfox(nride@uswest.net) on Wednesday October 27, @10:23AM EST (#154) (User Info)
Ten years from now some Visual Basic programmer will be writing a story about you comparing you to Mel. It will probably go something like "Kitsune didn't approve of visual design tools. He didn't approve of GUIs either. ``If you can't pipe it on a command line,'' he asked, ``what good is it''..."
I agree that VB is trashed a bit overmuch and so does Linus, judging by this quote from recent interview:
"Don't get me wrong, I like Visual Basic, really, and I think it is one of the best successes Microsoft has had. That was because it was a really good medium for customization, it was a great medium to the front ends for the real work. I think that is the future."
Compared to working with MFC, VB is a real pleasure. It can produce huge, slow, klunky applications, but it does so quickly -- which often counts for a lot in a internal business tool environment.
..along with most everything else GNU has ever made besides GCC. I think I'll stick to trusting Linus only with regards to kernel hacking and determine how I feel about other things like languages and applications on my own. ;)
~ Kish
If you have something intelligent to say, you'll log in or get moderated up so I can read it. Otherwise, you're wasting your time.
agreed. i think Linus is a decent enough kernel hacker, but he criticizes anybody and everybody who disagrees with his philosophy on "how things should be done". the man's flames are perhaps overshadowed only by his massive ego. from the now infamous flame war with Andy Tanenbaum (at the time Linus had 2-3 years OS programming experience vs Tanenbaum whom has taught and written books on the subject for many years) to the more recent flame fest between him and the egcs/gcc developers (yes he isn't pleased with gcc either, or the ISO C standard for that matter), Linus is well known for telling other (more experienced people) how they should be doing something. bottom line is don't take ANYTHING he says too seriously. he'll talk about anything regardless of if it is beyond the breadth and deepth of his knowledge and experience.
from the now infamous flame war with Andy Tanenbaum (at the time Linus had 2-3 years OS programming experience vs Tanenbaum whom has taught and written books on the subject for many years)
Writing books means *nothing*. In most fields, most of the best and brightest people don't write the books. It's the people who aren't contributing to the real research who write books. Like many academics, Tanenbaum was regarded by many as being out of touch even back then.
The fact is that despite his inexperience, Linus was right and Tanenbaum was wrong. Also, the fact is that Linux surpassed the functionality of Minix after only about a year of work primarily by one person (compared to Minix which took years by a bunch of grad students). Those facts alone establish that Linus with his 2-3 years of experience was the superior mind to Tanenbaum with his many books.
One thing that I've learned is that in the computer software industry, experience usually counts for jack shit. Similarly, most of the academics in the field are detached from all of the real innovation going on.
I'll agree that Linus has a massive ego. Wouldn't you have one if you were in his shoes? At least he isn't pretentious. Also, he has very rarely been wrong (so far).
idiot. (Score:0) by Anonymous Coward on Wednesday October 27, @08:13PM EST (#311)
"experience usually counts for jack shit"
You just invalidated your whole comment right there. Have any idea how stupid this sounds?
I spent 9 months programming in VB, then I quit because I found the language so frustrating to work in compared to C++ or Java. Yes you can do straightforward stuff very quickly but the minute you want to do anything just "off the beaten track" the attraction of VB soon fades. Because of that I consider the term "VB Developer" oxymoron in that the real developer is always doing stuff that's "off the beaten track". Am I alone here? Does any SlashDot regular consider VB a real programming language? Would you just love the opportunity to program in VB 8+ hours a day? I really want to know.
If a programming language (or any tool, for that matter) is frustrating to use, you are probably not applying it correctly. When you are building with nails, don't use a screwdriver and expect things to go smoothly.
Programming languages are nothing more than tools. As such, different languages are designed to facilitate the solutions to different programming problems. Just as you wouldn't use a screwdriver to drive a nail, you shouldn't use VB to implement a high-volume, enterprise-wide transaction processing system. However, it is ideal for developing user interfaces and front ends for such hardcore backend processing systems.
People who insist that one tool is better than other tools either (1) only solve one type of problem or (2) are not professional enough to learn to write good software using more than one tool.
VB is a tool that helps me to solve business. I get paid, like most developers, to solve BUSINESS not SYSTEM problems. VB hides many system complexities thus allowing me to produce a solution faster. I am very experienced and could produce exactly the same apps using VC++, but VB coding and maintenance is an order of magnitude quicker. The guts of VB incorporate the efforts of many C++ programmers so that I never have to duplicate their efforts (strings, array boundaries, instancing/using COM, pointers, etc). So, yes, given the choice I would rather program VB 8+ hours a day producing solutions to new business problems rather than wrestling with C++ to solve old systems/programming problems.
>Does any SlashDot regular consider VB a real programming language?
Meaningless question. Turing-machine code is "a real programming language."
>Would you just love the opportunity to program in VB 8+ hours a day?
I do. It's a fine language (though I do prefer Perl). The reusable code-base, in the form of VBX/OCXs, is enormous. And it's awfully easy to write your own extensions, either in VB or using a lower-level tool such as PowerBasic.
The sheer prevalence of Basic in overall business programming effort (by any reasonable measure) has been an open secret since at least the late 1980s, when an MS survey surprised even them with the numbers for usage of what was then QuickBasic.
VB is great for applications that are simple, non-computationally intensive, non-distributed, non-real time, non-mission critical, non-etc. etc. etc...
VB is only applicable to a small subset of problems. However, that small subset of problems generates the greatest need for developers. Let's face it, most developers aren't doing anything particularly interesting or challenging. Most programming tasks in the business world are quick, dirty, short and simple. They don't require a lot of analysis, modeling, design work, integration, testing, or documentation.
Are these "real" applications? Yes, but they're not particularly difficult or interesting, which is why they are well suited to VB. Let's face it, VB is intended to allow people who don't know much about computer science or software engineering to handle the majority of programming tasks in the business world. That frees up the people with more education and training to tackle the more interesting problems with other languages.
That's really scary. Perl is one of the few ``evolving'' programming languages that I like. In fact, I can only really deal with liking one at a time, which is another reason why I dislike Java, for those of you who bother to track my commentary (and for them I offer my sincerest apologies and condolences..).
[engage ``mindless'' psychobabble mode in a swift departure from original objective of this post]
Polls are always pointless. Obviously, whenever you ``poll'' anyone, you're only getting the goods from a narrow group of individuals (especially since developers working on specific tasks will require specific languages to get specific results.. ha!). It may or may not reflect well on the general populace (or other relavent supergroup) at large.
Visual Basic.. is not something I'd ever want to use for much of anything. C/C++ is perfect for general purpose programming. The kind of project you're doing will decide which you will want to use (not everything needs to be C++, though using ``clean'' C is usually a good idea -- that is, the grand majority of C that is compatible with C++). Java is probably the next best thing. What makes it an attractive choice is all of the features that are ``built-in'' (while the ANSI/ISO standards for C/C++ only go so far with what they cover as being the ``standard''.. graphics are beyond their scope, for instance).
C/C++ are going to remain the ``standard'' for quite some time. Java is somewhat inflexible, and since it is a corporation which regulates the standard, I'd fear for anyone wanting to jump whole-heartedly onto /that/ boat. I'll take ANSI/ISO stuff /any/ day. Java is good for when you want to do finish a program faster than you could in C/C++ (and don't mind the performance hit). And as much as certain bigots are loathe to admit it, Java is a simplified language meant to protect programmers from making common errors. It was designed that way (that doesn't mean that Java programmers are intrinsically ``less intelligent'' than C/C++ programmers, though you might want to wonder about the ones that slam C/C++ for no coherent reason whatsoever).
The short of it is this: There's really no point to these polls. I've never even bothered reading a poll like this before, and I could have already told you that if you're a programmer (working for a company), you're likely going to want to learn C/C++, although there is also a lot of Java work out there (in case you want to learn that instead of or in addition to C/C++.. either is likely to be a viable option), and if the company you work for deals with Microsoft stuff to any extent, you're probably going to want to learn VB (or find your niche doing something else ;). Real complicated, eh?
Every programming language has its uses, and functionality is a little bit more important than popularity. After all, in the realm of OSes Windows is still the most popular, but how many people think it's a major win? Popularity polls are pointless. I'd much rather see an academic comparison of the ``best'' programming languages side-by-side.
Anyway, just because some fools polled some other fools that didn't think Java whooped as much ass as VB doesn't mean it's serious lossage (or that it's ``not-so-hot''). But then, to do a story, you have to have some conflict, right? =P
~ Kish
If you have something intelligent to say, you'll log in or get moderated up so I can read it. Otherwise, you're wasting your time.
Re:heh.. (Score:1) by xmedar on Wednesday October 27, @02:42PM EST (#252) (User Info)
Yes, we need some thing more relevent, just talking about "business developers" means nothing. Some sort of objectified testing might be more appropriate, e.g. take the cream of developers in each language, and set them all a standarised set of programming tasks, the results are marked for speed of development, clean implementation, readability, portability, speed of execution etc. Then there would be at least a qualitative representation, as it stands the poll is next to useless, just a very sloppy way of garnering some PR.
I want to be a programmer, but I don't want to be, like, all "techy" and everything. 8-P
Well, it is true that you don't need to be much of a techy to learn VB. It was actually the first language I really learned. But it doesn't teach you very much or make for good programming. It does best at what it's designed to do; quick development for administrative, data crunching, low performance, non-technical programs with a GUI. Which often means that a bunch of poorly-thought out goals are being forced through without much planning. Good luck with it; cheap shoes don't last long and may cost you more in the long run than reasonably expensive ones.
I had to do an analysis of the different programming languages, both of their usefulness and their popularity, as part of a project for a former employer, so this is of interest to me.
I've seen Visual Basic used for *ugh!* web-page script stuff, and by engineers who wanted to crank out some cheap & nasty code, quickly. I've not once seen it used for any real work, though.
C I can understand. Java, likewise. Not only is Java new, the API keeps changing. There's virtually no relationship between one version and the next.
(Even for the Swing toolkit, which being new, you'd have thought Sun would standardise between 1.1 and 1.2... no way! It's in javax for one and java.swing in the other. During the betas, it's also been in java.awt.swing.)
Tcl/Tk also suffers from the lack of a solid API, with each new release having some major incompatibilities. Perl seems to be fairly solid, but Perl/Tk seems to always be several versions behind both of Perl and Tk.
Python only has one maintainer, last time I looked, which would give most industrial developers the jitters.
C++ is ok, but is a very complx language and seems to still be inefficient, compared to other languages. Maybe the problem is that the compiler has to translate between the OO model and the traditional functional model. If you ran C++ on an OO-based processor, it might actually have an advantage.
I've seen Visual Basic used for *ugh!* web-page script stuff, and by engineers who wanted to crank out some cheap & nasty code, quickly. I've not once seen it used for any real work, though.
a load of hogwash. GM runs many of their systems on VB based network applcations. Most of the shops and supermarkets here in New Zealand now run VB based systems at the checkouts.
VB is everywhere - from the Fortune 500s right down to the small business and home.
Certainly more useful VB apps have been written over Java, since VB is actually usable on the client side (C++ speed compared to uh...java speed).
Visual Basic 5.0 and 6.0 uses the same backend compiler as VC++.This means that simple loops and conditions will execute as fast in VB as in C++. GUI speed will be equivalent(since that depends on Windows, not the language used). VB is slower for small apps because one needs to load the msvbm60.dll, which is 1.2 MB, from disk. The main limitation in VB is not the execution speed or size of the executables, it is : - the feature bloat - the "intelligent" type checking - The lack of true inheritance - Not having constructors.
Anybody worth their stuff knows that when you are "retargeting" a language(VB) into another language(C++), the features required to support that are enormous and have to be VERY general.
VB is slow. C++ is pretty fast. C is the fastest, next to assembly. Though, not all C compilers were created equally.
Personally, I have translated applications from C++ to C that achieved 1/10 the size and 400% increase in speed. Especially in large data sets. I'm not bashing C++, I'm just saying it has it's place. For instance, event driven GUI's. Fantastic! Large scale mathmatical models.. UGH! Database systems.. depends. But in any case, be prepared to feel the power of BLOAT.
And remember, that PERL is written in C. Java (the jvm is, javac has mixed C and Java (used to be all C though))is written in C. Tcl/tk is written in C. I bet a good bit of VB was originally written in C. Linux is written in C. NT is written in C. Xwindows, Netscape, LDAP, Oracle, Informix... c,c,c,c,c.
There's alot of C++ out there.. but nobody should pretend that it's the one-all end-all. Same goes for Java, Perl, VB, etc, and yes even C. And remember that the implementation of the compiler, libraries, and envoronment can make all the difference in the world.
Pan
Pan Moderators Guide -- It's all fun and games till someone starts keeping score!
VB and C++ both use the same compiler. If you write robust C++ code that:
1) uses STL or CString strings 2) checks array boundaries 3) safely checks math operations 4) verifies pointers
...your C++ code will (suprise!) run at the same speed as VB. You can write code that ignores these precautions, but then you are trading reliability for speeed. If prefer to let VB do all of this work for me.
Damn, that's funny. WTF are you talking about ? Last I checked their were no "functional" processors either. Also "C++...seems to still be inefficient, compared to other languages." What other langauges are you talking about ? OK, it's slower than Fortran or assembly and C++ does tempt people to do wasteful things especially when they don't know the pitfalls, but it's pretty efficient when done right. I used to have a decent sig, but I got bored of it
OO-style programs behave in fundamentally different ways. Their memory allocation patterns tend to involve smaller but far more numerous chunks; their function calls are more frequent, with shorter methods; and if you use multiple inheritance, then you're doing more memory lookups for vtbl foo. Therefore, you find somewhat more instruction cache misses and so forth; and with more frequent function calls, you find things like a greater number of cycles devoted to things like save/restore.
Ergo, different optimizations may impact OO-style programs in different ways compared to straight C; and it may be possible to design an architecture that minimizes the extra overhead.
Here's a citation that may interest you:
"Quantifying Behavioral Differences Between C and C++ Programs", by Calder, Grunwald and Zorn; it appeared in the _Journal of Programming Languages_, 2:4, 1994. -- the silly student / he writes really bad haiku / readers all go mad
Perl has beaten C++ in performance tests. Not just anybody writing the C++, either- I think that "The Practice of Programming," by Kernighan and Pike, is where I read that. That might be why the original poster said that C++ is inefficient. And there are definitely some wastes in common implementation: templates, for example, while very cool, are well-known for being terribly inefficient in their implementation on most compilers.
(Oh, and incidentally, Lisp machines ran on "functional processors.")
Lisp machines did not run on "functional processors" (if you mean the same functional as in "functional programming"), they ran on processors optimised for lisp programs. They actually used lisp to write all of the OS, even the low level stuff. And let's not forget that the lispms weren't really meant for functional programming as much as for symbolic computing (which is what lisp really excels at). Lisp isn't really that functional a language, it supports both functional and imperative programming, though functional is often more natural. I could rave about all the cool stuff it offers, but I won't. I'll just say this: Lisp rocks. :) As for lisp machines, they were really cool. Type checking was performed in hardware, the later models had (for the time) kick-ass graphics (1280x1024 pixels, 24 bit color, genlocks, and whatnot), they came with 16-bit audio. And all this in 1984 (or maybe 1985). Lisp machines are still considered by many to be the best software development environment ever. They are really cool, even if the hardware is very dated. I only wish I could get my hands on one.
Faster languages than C++ (at least, those I'm familiar enough with to say): C, Occam, LISP, FORTH, Fortran, Algol, Smalltalk, Perl.
As for processor designs, let's start with the Transputer, where the machine-level instructions had a near 1:1 correspondance with the Occam programming language. :)
(I -loved- programming transputer arrays. THOSE were fun! And blew the spots off anything Intel could churn out.)
Then, I remember from my 1st year at University, talk of processors who could execute Pascal directly. Their opcode, again, had a near 1:1 correspondance with the Pascal language.
Even traditional processors, though, such as the 80x86, could be considered functional. You have conditions, loops, data types (8, 16, 32, 64, 80 bit variables), procedures & subroutines, maths operations, and all sorts of goodies. All the capability you expect in a functional programming language.
An OO processor is a bit more complex. Basically, it would need to think of operations on an object, rather than operations on a given address, which otherwise has no more significance than any other address. For that, you have to stop thinking in terms of linear, flat memory, but rather have each object in it's own "contained" memory space. ie: each object, at each level, would become a virtual computer, with "connections" as necessary. Not just at the "programming" level, but at the processor level. The processor itself would need to see the system that way.
It's my belief that translation between paradigms can never be as efficient as understanding the paradigm in the first place. Thus, it's my belief that a processor that is centered around the OO concept, and sees objects as objects, rather than flat memory models, would inevitably be better than translation.
> Faster languages than C++ (at least, those I'm familiar enough with to say): C, Occam, LISP, FORTH, Fortran, Algol, Smalltalk, Perl.
You may well be familiar with all those langauges, but I doubt you're very familiar with modern C++.
C is NOT faster than C++. If you use a bunch of objects inappropriately, then yes, it will be slower than the pure C version but if you need to achieve the same level of flexibility and encapsulation and you have a decent optimizing compiler then the C version will be roughly the same speed.
Fortran - generally is faster than C++, especially for numerical work. However check out http://oonumerics.org/blitz/ for C++ based numerical code that is as fast as fortran
Perl - is being re-written in C++, and somehow I suspect that perl's authors have a better understanding of perl's strengths and weaknesses than you do.
Occam - was effectively the assembly language for transputers, I too have programmed transputer arrays, and yes, they did kick ass, but it's pretty fucking useless for anything except low level programming on massively parrallel computers. Also, using indentation to control block termination is a BAD idea.
Smalltalk - if you have an implementation that runs faster than sensible C++, please tell me where I can get it.
I used to have a decent sig, but I got bored of it
Re:FUD (Score:1) by kafka(eemsizDONT_SPAM_ME@wi.leidenuniv.nl) on Wednesday October 27, @12:47PM EST (#216) (User Info)
> massively parrallel computers. Also, using > indentation to control block > termination is a BAD idea.
I assume you a are refering to Python. It's a wonderful language but this "feature" (as somebody called it) really pisses me.
Also, using indentation to control block termination is a BAD idea. Out of curiosity, as a not-quite-rabid Pythoner, why do you believe this? I'm not looking for a holy war, I just would like more info on your point of view.
q = ['print "q =",q,"; exec(q[0])"'] ; exec(q[0])
Re:FUD (Score:0) by Anonymous Coward on Wednesday October 27, @02:51PM EST (#254)
It means whitespace is important to the syntax, which is a bad idea (my opinion). It also means you have to trust your editor to "do what you mean" when indenting stuff. I would much rather just have to type curly braces (or even "begin" and "end"), where the intent would be very clear to the parser, and to the human, and that two pieces of code that appeared identical (but with different whitespace) had different semantics.
I don't think anyone writes code without using indentation to match the program structure. Just let me do it. If I want help, I will use emacs.
To put it another way: it makes the user adapt to the computer, rather than the other way around. Yes, there are many other places this happens, but with Python, it was unnecessary, and was put in in a misguided attempt to make the user conform to the creator's idea of useability.
It means whitespace is important to the syntax, which is a bad idea (my opinion)
I realize this is only your opinion but here's my experience: In four years of Python programming (and other languages with similar conventions) I have never once had it cause a problem. I have never personally known anyone who had it cause a problem. I believe that Visual Basic also uses white space significantly -- to separate statements -- and yet hundreds of thousands of so-called "stupid VB programmers" don't seem to have any problems with it. I'm surprised that so many hard core Real Men C programmers are so scared of it.
I think that your objection is not only unfounded but mostly pointless. Every language has problems because of how it handles syntax. I would argue that C's sometimes optional braces cause far more problems than using a newline as the statement separator. Contrary to the widely feared but never seen white space problem, I've seen the optional braces cause problems in production code.
Get a life! (Score:0) by Anonymous Coward on Wednesday October 27, @09:07PM EST (#315)
Someone asked me, and I responded with *my opinion*!! Then you, under the title "Python indentation FUD" (what stake do you have in python's success, exactly?), proceed to tell me I am wrong, and label me a "Real Men C programmer" who is scared of such syntax. Where exactly does fear come in? Not fear, irritation, which I did experience at first! Irritation that could have been avoided was this feature not there.
I guess I should have mentioned that, yes, I am a C programmer. And that, yes, I have used python, and no, the "funny" syntax did not prevent me from using it, and yes, apart from that quibble, it's a pretty nice language & system. Yes, I should have qualified it like this, so that the (incredibly) insecure python programmers would not get so incensed!
To be fair, I have never seen optional braces cause problems in production C or C++ code. I could imagine an extra tab causing problems in production python code, just as easily as the curly brace (if you deny the possiblity, you are fooling yourself), so I guess we are even. And that makes your argument just as pointless.
I guess python is perfect then. Thanks for enlightening me, and I will be careful to never have an opinion again.
I also suppose now is a bad time to bring up python's lack of typing. While I have not used python extensively, in other such languages that feature has costed me *hours* of time across multiple occasions, due to simple typos or whatnot, and that could have been avoided could I have specified the type of variable.
Peter.
ps. yes, vb has the same whitespace funnyness, but vb is much more broken than python is, in many other ways. Which means I will happily use python before I use vb.
I could imagine an extra tab causing problems in production python code, just as easily as the curly brace (if you deny the possiblity, you are fooling yourself), so I guess we are even. And that makes your argument just as pointless.
Wait. His argument was that in extensive use he has seen no problems with Python's indentation. How can you rebut that, aside from offering contradictor experience? All you have is a theory that it might impact productivity (and you're wrong about the details of the theory -- the odds of an indentation change actually changing the _meaning_ of the code without being an error is VERY small, and even that possibility can be eliminated by using tabnanny).
He didn't tell you you can't have an opinion; he told you exactly why your opinion is wrong. Which it is. Although I admit he also put a silly title on his post, so I can understand why you'd be annoyed.
To be fair, I have never seen optional braces cause problems in production C or C++ code.
What do you mean by "To be fair?"
How much production C code have you seen? I've seen and written my share, and I have seen the optional braces cause problems in real code. To be sure, it wasn't production code, because we corrected the bug before we shipped it -- but that was just luck (and skill), not any feature of C.
I could imagine an extra tab causing problems in production python code,
Imagination doesn't carry the day.
-Billy
Re:Get a life! (Score:0) by Anonymous Coward on Thursday October 28, @02:06AM EST (#329)
I've seen plenty of production code (you'll have to take my word), and I've never seen curly braces cause trouble. (have to take my word on that, also). I can picture it happening, though. My point was I think it's unlikely that python has never had the same problem (indeed, I'd be very suprised). Regarding semantics: while( some condition ) first statement /* a whole bunch more statements */ Oh. There is software available to assist the programmer to make sure such errors do not occur. I guess it has come up.
Re:Get a life! (Score:0) by Anonymous Coward on Thursday October 28, @02:28AM EST (#332)
What I'm saying is that I've seen plenty of production code (you'll have to take my word), and I've never seen curly braces cause trouble (have to take my word on that, also). I can picture it happening, though. My point was I think it's unlikely that python has never had the same problem (indeed, I'd be very suprised), and so the unique indention model doesn't really serve any good purpose.
Oh. You're saying there's software (tabnanny?) available to assist the programmer to make sure such errors do not occur? I guess it has come up, and I don't need to use my imagination.
And for "To be fair" please substitute "Honestly" (didn't really mean anything by it)
P.
(ps. I hit enter before I was done, hence the post and a half. I blame slashdot. perl, rather :)
What I'm saying is that I've seen plenty of production code (you'll have to take my word), and I've never seen curly braces cause trouble (have to take my word on that, also).
I believe you. I'm just stating that I've been involved in much development, and I see it happen all the time. The only cure is to always use [short and] curlies.
I can picture it happening, though. My point was I think it's unlikely that python has never had the same problem (indeed, I'd be very suprised), and so the unique indention model doesn't really serve any good purpose.
The *purpose* of the indentation isn't to avoid that particular problem. It's twofold: first, to remove a nasty source of style debate; and second, to make code easier to read by making style cues match up with meaning.
It works very well at both.
Oh. You're saying there's software (tabnanny?) available to assist the programmer to make sure such errors do not occur? I guess it has come up, and I don't need to use my imagination.
Nope -- tabnanny was written unwillingly after the insistent demands of people who knew nothing about Python.
(ps. I hit enter before I was done, hence the post and a half. I blame slashdot. perl, rather :)
Faster languages than C++ (at least, those I'm familiar enough with to say): C, Occam, LISP,
Somewhat offtopic... LISP is fast? I have very little experience with LISP, but from what I've seen, I'm amazed that it can run on real-world computers at all. For one thing, it's traditionally interpreted, although I don't know how common compiled LISP is in practice. But more importantly, the model just doesn't seem conducive to performance. I mean, extracting the nth element from a list is an O(n) operation?!?
I love thinking in LISP. But I can't see how a LISP program could be faster than C.
Try extracting the nth element from a list in C++ in less than O(n) using the standard linked list data structure. You could make a fortune with that algorithm ;) In my experience most Lisps in serious use are at least bytecode-compiled and most are compiled to native code.
A list is not the only data structure available in Lisp. For instance, Common Lisp has arrays just like C/C++ and they're as fast with proper type-declarations. Lisp is not inherently slower than C/C++; you just have to work a bit more to make it as fast. A Lisp program could be faster than C because it's easier to implement better algorithms in Lisp or because the Lisp compiler is better than the C compiler. The important thing in optimizing Lisp is to declare types and to avoid dynamic memory allocation during speed-critical code.
I've seen some numerical code go faster in CMUCL (a high quality free Common Lisp compiler for Linux/*BSD) than the equivalent in g++ (with all relevant optimizations, 10% difference in speed in favor of CMUCL), just because the CMUCL compiler is excellent in number crunching.
Try extracting the nth element from a list in C++ in less than O(n) using the standard linked list data structure.
I was of course implying that I wouldn't be using a linked list when I needed to extract the nth element of a set in C++, but I didn't have that option in LISP. But...
Common Lisp has arrays just like C/C++ and they're as fast with proper type-declarations.
... I wasn't aware of that. (Seems a bit like cheating to me, though... If you allow LISP arrays in this analysis, then can I use inline assembly in C++?)
Anyway, I'm willing to believe that LISP is as fast as C++. But I still don't buy that LISP is inherently faster than C++, assuming an equally comepetent compiler, which is what jd seemed to be claiming. I find it hard to believe that any language is inherently faster than C++, other than perhaps assembly. (Whereas there are definitely languages that are inherently slower than C++... weakly typed lanugages, for example.)
Let's take a look at this from a more abstract perspective.
C++ is a great language, and I enjoy programming in it, however -because- it's OO, it has the inherent drawback of translating from the OO paradigm into a functional one (machine code is, on all existing processors, based on the functional design concept, not an OO one.) It also has the drawback that it's object-based, not pure OO, which means that you can't explot many of the speedups you could get from the OO approach.
C, and many other "traditional" 1st and 2nd Generation Languages, have an almost direct mapping from the source to the unoptimised assembly. This means that you have much more control over how efficient the compiler can be in generating the code and, therefore, in optimising it.
With OO languages, no such mapping exists. There is no way to tell what the compiler will generate from a given construct, ESPECIALLY if you're taking advantage of the concept of objects, and the exception handling. (And if you aren't, then why are you using C++ at all?)
If you can't use code you can be sure will compile well, then you can't possibly write as efficiently as you can in a programming language where you have enough control to be able to hand-optimise your algorithms.
You are confusing "functional" with "imperative". They are very different things, although I have heard of function oriented VB programming dubbed functional by spaced-out VB programmers).
C and C++ are *both imperative languages*. There is basically *no* translation between the OO and imperative "paradigms". There is not very much difference in the compilers for both languages except in the frontends. It's all syntax, and beyond that, it's pretty easy to determine what the compiler will generate.
The same is not true of functional languages (real functional languages, not C++!). Your point about it being impossible to tell what a given construct will compile to is much more true of a real functional language that of C++. In C++, it's just function pointers and compiler tricks. There is not a whole lot the processor can do to speed it up (no more, at least, than C). On the other hand, functional languages have much more room for optimization by the compiler than does C++ (and conceivably, more room for the hardware, in the form of multiprocessors and other tricks).
Here's a guide for you:
Imperative languages: C (procedural) C++ (object-oriented)
Even if you are just using your own terms for the same things, it helps you use standard terms so that people know what the hell you are talking about.
But I still don't buy that LISP is inherently faster than C++, assuming an equally comepetent compiler, which is what jd seemed to be claiming.
Of course it isn't inherently faster, just theoretically as fast. In some languages it's easier to optimize the code than in others and consequently the compilers may produce better code. In the case of C++ there has been a lot of competition and the existing implementations are quite good. I would think that most Lisp implementations produce worse code.
The thing is that IMO Lisp is more expressive than C++ and because of that better algorithms get implemented (it's easier and faster). Good algorithms affect speed more than the quality of the compiled code in many cases. If you would implement the same algorithms in C++ the result would probably be faster.
Some of those languages I can buy as faster. But Smalltalk? Smalltalk, by definition, is a compiled language and uses a VM just like Java. In order for an imlementation to be certified, it MUST use a VM.
Additionally, if you need the features of C++, implementing them in those other languages will make them SLOWER than C++ (for instance, exceptions, generics (ie templates in C++), polymorphism, encapsulation, etc..
BASIC (Beginners All Purpose Symbolic Language). I think the names says it all. C rules. It is clean an efficent and quite flexiable. C++ is good for people who don't like to prgram, but rather like putting together legos. In C++, too much happens under the hood. Although, I will admit that a good C++ programmer can do some awesome thinbgs. I think I have only met one good C++ programmer in my life. My .02 Jamey Jamey Kirby StorageCraft.com
I'd rather new than malloc (which i can do anyway). C++ gives you both "under the hood" functionality, and the flexibility to change what goes on under the hood.
>Python only has one maintainer, last time I looked, which would give most industrial developers the jitters.
Possibly, but since Python is fully Open Source, maintainance of the language shouldn't be a problem. When push comes to shove, you can always find a way to fix the problem -- people can and do post public patches to the Python source to fix things they see as problems, such as better garbage collection, consistent return types from functions, etc. If anything, I'd be more worried about being tied to a proprietary language with a single company behind it. This applies for both good languages (Delphi), and not-so-good ones (VB). If the company goes out of business (Delphi again, sorry Borland), or arbitrarily breaks backwards compatibility (VB), you're screwed.
Also, Python the Language has been pretty stable for a few years now -- my copy of "Programming Python" is dated in 1996 and applies for Python 1.4. The current version is 1.52 and is mostly minor changes in the standard libraries. The major events for Python right now is how it is used, such as in Zope or JPython.
Also, if you read LinuxToday, you might have noticed the recent announcement of the Python Consortium being formed. HP is one of the initial members, and they're hardly an insignificant company.
Re: Python (Score:2, Interesting) by Meeko on Wednesday October 27, @01:40PM EST (#229) (User Info)
Amen -- Python is a beautiful language that is powerful and flexible and (most importantly) eminently readable!
I was blown away when I heard about JPython the other day. This will allow you to load and interact with Java objects on the fly, in the interpreter. When you're done you can stream it all out to disk. It's like a toy shop :)
Plus, the Win32 API and COM is exposed under Python too so you can take your pick. (Or Tk for the Unix folk.)
Anyway, If I wanted to read code that looks like Perl, I would 'cat' a core dump.
Re: Python (Score:0) by Anonymous Coward on Wednesday October 27, @02:31PM EST (#247)
Aww, come on. Perl isn't *that* unreadable. It's more like 'cat'ing a uuencoded core dump!
Tcl/Tk also suffers from the lack of a solid API, with each new release having some major incompatibilities.
Intriguing. Exactly what would these "major incompatibilities" be, then? There are some (veyr minor) changes between releases, but that's about it. Lots of new functionality, yes, but major incompatibilities, no.
That's not to say that Tcl is ideal for writing business apps. It's not. While it can be done (and I am doing so now, BTW), the language isn't great for large scale projects. Give me pointers, for fsck's sake! :-) Tcl is, however, very good at producing small utilities, and doing so very quickly. Shell have 1.5 million lines of Tcl running on one of their oil rigs, apparently, so it can be done. Speaking from experience though, if I was going there, I wouldn't be starting with Tcl...
NV is a typical TCL/TK application. It won't run on any Tcl 4.x or 8.x variations, because it's almost entirely built of calls that have been entirely replaced. It would be next to impossible to port to a recent version TCL and would require a complete re-write to get it to work. This is a bit more extensive han "minor" changes between releases. :)
Then, you only have to look at the changelog - I've yet to see even a minor version of TCL that hasn't at least 3-4 calls listed as replaced and no longer working.
C++ is ok, but is a very complx language and seems to still be inefficient, compared to other languages. Maybe the problem is that the compiler has to translate between the OO model and the traditional functional model. If you ran C++ on an OO-based processor, it might actually have an advantage.
Agreed. This guy should stick to his training wheel programming languag(VB) and save his analysis of c++ for another VB programmer who might actually believe it.
The only thing that needs to be moderated down are your trolls. Read the moderator's guidelines before writing such stuff. Moderation isn't about whether you agree or disagree, but whether the post contains a view which is provocative of thought. And, let's face it, the post has 9 replies and counting. I'd say I've provoked some thought, at the very least!
As for programming, I've probably more experience behind the screen than both you AC's combined. I was writing speech synthesisers for the Commodore PET by the time I was 10, and radio telescope control software in pure 6502 machine code by the age of 12. I have little patience and less time for low-grade flamebait from a couple of AC's. I -certainly- understand the OO paradigm better, and have far more extensive knowledge of microprocessor design.
(Even for the Swing toolkit, which being new, you'd have thought Sun would standardise between 1.1 and 1.2... no way! It's in javax for one and java.swing in the other. During the betas, it's also been in java.awt.swing.)
How could that many factual errors be done in that few sentences? Let me guess, you used this strange Symantec product called Visual Cafe?
Swing was in com.sun.java.swing for some time. And now, since release 1.1something, it is always under javax.swing on both 1.1 and 1.2, and it has been this way for more than a year already.
No, I used Emacs and Sun's own Java compilers, hot off the press from their Sun Developer's area. I was usually working with a new release within 2-3 hours of a new release being posted, either of the Swing set, or of Sun's Java compiler.
More than a year? Oh, goodness! And I've been working with Java 1.2 since 1997. I make that a little more than 1 year.
BTW, talking of factual errors, 1.2 was renamed Java 2, at the time of final release, which was about a year ago.
C++ is ok, but is a very complx language and seems to still be inefficient, compared to other languages.
C++ is very complex, but due to the pragmatic design of the language, its only as complex as you need it to be. Its also just about as efficient as C, assuming that you're careful about what you're doing. Obviously using features that require run-time support such as late binding are going to slow you down, and most compilers still produce less than optimal template code, but its important to distinguish between the language itself, and a particular implementation of the language (compiler).
FORTRAN may still be faster in certain instances due to its static activation records and restricted pointer operations, but in general C++ is not the dog that some people make it out to be. Recompiling a C program with a good C++ compiler will give you about the same performance, but with the added benefit of stronger type checking.
TedC
Re:C++ efficiency (Score:0) by Anonymous Coward on Wednesday October 27, @08:03PM EST (#310)
C++ can get pretty slow in certain circumstances. For instance, let's say your application has a highly entangled class structure (lots of associations between classes) and the classes are all defined in different compilation units. Then you will have tons of remote vtable lookups all throughout the code, causing really poor cache efficiency and potentially a lot page thrashing when memory is tight. C++ can be fast, but subtle things have a big effect on code efficiency. In my experience, FORTRAN and C are equally fast on most platforms. However, FORTRAN math libraries are usually more optimized.
Then you will have tons of remote vtable lookups all throughout the code, causing really poor cache efficiency and potentially a lot page thrashing when memory is tight.
I was under the impression that the vtable was used for virtual functions, and didn't have anyting to do with classes. Is this related to the C++ inheritance mechanism, and would this still be an issue if new classes were derived using composition instead of inheritance?
TedC
vtable stuff (Score:0) by Anonymous Coward on Thursday October 28, @07:15PM EST (#349)
Yes and no. vtable is the mechanism by which C++ implements polymorphism, so it is used whenever a virtual function is declared or a function or operator is overloaded. The problem is that the executable contains only one vtable per class, and all instances of the class perform lookups on the same table. If you have a class structure that makes extensive use of inheritance and polymorphism (like most frameworks and toolkits), then the resulting executable will be full of vtable lookups.
If the executable is small, the vtables will end up being close to the class method calls and it won't result in too much thrashing. But if the executable is big, the vtables get further away from the method calls. Also, if the classes are intertwined (many classes having multiple associations with or dependencies on other classes), then it is even worse. Good performance is only achieved when you keep the cache hit rate high. If the code generates a lot of vtable lookups (which are almost always remote), the principle of locality is violated and the performance declines a lot.
It would be nice if compilers offered the option to replicate the vtables for each compilation unit so the programmer can choose to trade off code size for speed.
So this situation can probably be avoided entirely by avoiding virtual functions, overloaded operators, multiple inheritance, and anything else that requires late binding.
Pure OO programmers would find this unacceptable, but since I tend to view C++ as a better C, the idea appeals to me. I can happily get by with just classes (for better interfaces between parts of a system), inline functions (pre-processor macros are evil!), and stronger type checking.
C I can understand. Java, likewise. Not only is Java new, the API keeps changing. There's virtually no relationship between one version and the next.
(Even for the Swing toolkit, which being new, you'd have thought Sun would standardise between 1.1 and 1.2... no way! It's in javax for one and java.swing in the other. During the betas, it's also been in java.awt.swing.)
Um, no.
The Java API has been very stable. The class file format hasn't changed since 1.0. The only changes to the virtual machine spec (besides clarifications) are the addition of strictfp and widefp in 1.2. The addition of inner classes required a change to the language spec (and the compiler), but not the JVM itself. It was an excellent addition, BTW.
Upcoming Java releases will support generic programming (templates). Once again, there will be NO changes to the JVM spec itself; the language spec and the compiler are being modified.
What has happened is that the class libraries have grown a great deal. All of the old functionality is still there; if you want to write a program using the 1.0 event model, go right ahead. Backwards compatibility has been kept. This isn't any different from any other platform; the shared libraries grow and change over time, while backwards compatibility is preserved with old versions of the libs.
The Swing changes you mention are BS. At some point, it was com.sun.java.swing.* (1.0, I think). You can get a javax.swing.* package for 1.1 (which actually is more up-to-date than the version of Swing for 1.2!). Sun made this change to follow their own conventions for naming packages; it wasn't capricious.
To change a program from the com.sun.java.swing.* packages to the javax.swing.* packages requires a grep. BFD.
. If you ran C++ on an OO-based processor, it might actually have an advantage.
Now I know that you are clueless. Please explain to me what an "OO-based processor" is. Supply some examples.
I've seen Visual Basic used for *ugh!* web-page script stuff, and by engineers who wanted to crank out some cheap & nasty code, quickly. I've not once seen it used for any real work, though.
Be afraid: VB is used for more and more increasingly large, mission-critical projects. VB is fine for certain tasks. However the comments (see other posts), about managers thinking it requires less qualified software engineers, are valid. I see this happening every day in my work, and while the systems we build become more complex, the quality of of programmers has steadily declined, and with it the quality of the software.
Incidently, the same thing happens in the area of system administration. Setting up a Windows NT server seems very easy, so managers think they can get away with hiring much less experienced (and cheaper) admins. The rude awakening comes later...!
That is why I choose a language like C or C++ for larger projects: it keeps non-qualified programmers away from the team. A nice GUI and pretty colors are simply no substitute for brains.
It all really depends on what I do, if I have to code for Winblows (co-op job and stuff) and its quick and dirty, I would use Visual Basic (repenting now). If it is something long or big, I use Visual C++ or Inprise/Borland C++ Builder or Delphi. For UNIX, I go for PERL for quick and dirty, C for speed and C++ if it is big.
Exception: if speed is not important and GUI fanciness is, then Java is my choice although I'm still relectant on it as its kinda of changes too much. -- Note: These Comments are Generated by ME! Not You! ME!
Well, if you asked a group of embedded systems engineers what language they used for fine tuning time-critical sections in drivers, you would see that Visual Basic is not popular, while 90% of the developers seem to be using asm for their ``applications''.
I'm sure VB is hot for business apps. But I can't say I care. What about real-world apps ?
One heck of a lot of programmers use Pascal (because of Delphi), and we're a lot out there using C and C++ because of run-time efficiency and portability, and because of language sophistication (well, that holds for C++ at least).
The main problem I guess is, that people tend to see the most popular language (or, the one that requires the most programmers to work with it) as the ``winning'' language. In real-world large applications however, a number of languages are often used. LISP/prolog for the extensibility and AI parts, C for the APIs, C or C++ for the core parts, Pascal/VB/objc for the front-ends etc. etc.
The fact that a language has a lot of programmers either reflects that it is a language which is good, or a language which require many people working with it to actually get results.
What the heck to do you mean by "What I'm sure VB is hot for business apps. But I can't say I care. What about real-world apps ? ??? What a stupid statement. If a business isn't a "real-world" app, then what is it? Is some obscure scientific program a "real-world" app?
IMHO, "business software" probably makes the most revenue of all the types of software, its the easiest place to find a niche to make a living from, and the majority of the software being developed is probably for some business need. And you claim that this isn't "real-world"?
You also state: "The fact that a language has a lot of programmers either reflects that it is a language which is good, or a language which require many people working with it to actually get results."
Rubbish! Perhaps a language is popular because it simple to learn and it is easy to turn out simple solutions that brought to market quickly. Smalltalk was a very good language, but does it have a lot of programmers using it? A language that requires many people to get results doesn't sound very efficient or profitable... how would this become a popular language? Then again, C++ is everywhere! lol :)
You mention LISP, well how major LISP applications are in COMMON use everywhere (ie. a "real-world" application? Only one really springs to mind: my favourite editor, EMACS - but even this has a relatively limited potential user-base, and even amongst developers it certainly isn't close to being the most popular.
You misunderstand. Walk into your local software store, and I bet you could count the apps written with VB on one hand. The reason VB is so highly ranked in this survey is because of in-house developers writing one off hacks (what else can you do in VB?). No one writes real applications that have any kind of long term maintenence requirements in VB.
The reason VB is so popular is that people who don't have the skills to be a real developer can wire together components to make simple applications, especially database frontends. Companies can pay these VBers a lot less than a software engineer would demand, so they're happy too.
Agreed. Most of the software in the local is Windows apps, _probably_ written in C++. A large majority of them are put together from COM components... so who knows what percentage (probably just in the UI) is actually VB.
I have to admit being very snobbish against VB , but I try hard to accept that it does have a valid place in the market because it does meet of the needs as a solution of a larger number of problems.
Those morons who wrote the Unreal engine obviously "don't have the skills to be a real developer" because they chose to write UnrealEd in VB. But that's another story.
Let's be fair here, there are also plenty of morons who write in C. These are the ones can hammer out code, but they have no concept of what the application will be used for, how it fits into the business, or why the app is needed in the first place. They just take the specs and hammer out code. Are these guys "real developers?"
I think "real developers" will use whatever tool they're using to the greatest possible efficiency, regardless of what that tool actually is, be it VB, C, C++, Java, Cobol.
An example-- we've had to develop a warehouse management system that handles importing data from Symbol barcode guns, processes it, prints out pallet labels (with more barcodes), balances/stages/repairs orders, and finally stores it in our Informix system (SSA BPCS). Of course, there's a whole bunch of other "stuff" going behind the scenes, combined with making a user interface that can be used by minimum-wage guys on a shipping dock. Do you know how many man-hours that would've taken to do in C++? In VB, it took one guy 6 weeks, and surprisingly enough, the system works very well. This, to me, is a perfect example of a real-world application, not just "stringing together components." Now, we could've spent 6-12 months doing this in C++, and it would perform probably perform... about the same. At any rate, you *can* write real apps in VB, just as you can write crappy apps in C/C++. It depends on what you want to do, taking into account the capabilities of the language vs. budget constraints. Your last statement would suggest that VBer's are higher in demand, because they can do things more quickly and less expensively, correct?
Have you actually tried to convince management that slower and more expensive is the way to go for any particular in-house project?
-CausticPuppy "Of all the people I know, you're certainly one of them." -Somebody I don't know
I think you miss the point. Obviously, the guys who wrote the Unreal engine aren't morons for using VB to write UnrealEd. They used the tools appropriate to the task at hand. I'm sure they didn't write *Unreal* in VB. VB is best at making front-ends (and since an editor like that is primarily made up of the interface, VB is the natural choice); for other tasks other languages are often better.
Using VB does not make one a moron; but the thing with VB is that because it's very simple to learn it tends to attract more morons than a lot of other languages. Thus VB programmers get a bad reputation (which may or may not be deserved, though every VB programmer I've known has fit the stereotype).
I think you're absolutely right. I'm relatively new to VB (1 year) but I've programmed in other languages before (Pascal, Java 1.0, and hell even Motorola 6800 machine code)
VB is very simple to learn, which is why there are plenty of people who use it but don't know much about programming theory. I think my previous, albeit limited, programming experience made me productive in VB almost immediately.
I certainly don't claim to be an expert programmer, but I firmly believe that being good at programming is independent of the language you use. I have met some truly brilliant VB programmers (many of whom aren't even MS Certified, and it's too bad that many resumes are overlooked because of that fact) Look behind the code, for instance at the algorithms and ideas used-- all the good programming concepts and theory can be applied to VB, which is how ones gets nice apps out of it.
Nowadays I mostly write VB stuff, because that's much of my job. I'm just starting with shell scripting and perl on my home Linux box, but that's just for fun right now since I don't see that getting incorporated into my career just yet.
Anyway, the "morons" learn VB from the "21 days" book and that's it. I learned most of the syntax from that same book, but it doesn't actually teach you how to write PROGRAMS. That's where books like Code Complete and my old college texts come in handy, and I've also applied some stuff from various Algorithms in C and Java type books. Most of the "good" (as opposed to Evil) VB programmers are the same way.
So, my point is this: VB is a very accessible language. You don't have to know a lot about it to write something that compiles. But there's also a lot of potential there, which fewer VB programmers will ever learn to use. I think that many of the hard-core C types dismiss VB for these reasons alone: 1) It's "BASIC" which means it's for wussies, 2) It's Microsoft, and 3) They don't know much about it.
-CausticPuppy "Of all the people I know, you're certainly one of them." -Somebody I don't know
You sound like a good programmer to me, you understand and have the "right" attitude. You hit it upon the head: programming takes more than a vocation skill such as VB. I agree completely with, languages are such a way of expressing yourself. Of course, you have to know a bit about the language too.
Ever notice how many good programmers/software engineers are or were also muscians (I looked at your web page)?
Funny you mention that, because there are quite a few musicians in my IT department. Strangely, they seem to mostly be on the support side. That's where I started out at my company though, over there on hardware/software/network support.
Now here's a little philosophy for you: programming languages aren't meant for computers, they are simply a tool to express an abstraction of logical human thought, which are converted into itty bitty simple steps for the CPU to process (op codes!) Just think, no matter how elegant your code is, it's all reduced to a bunch of reading and writing to registers, shifting bits, etc. Cool.
Naturally, having a firm understanding of the language is a requirement, along with all the language-independent programming techniques.
I like composing music (everything from industrial to 3 part fugues) for the same reasons I like programming-- the mental exercise. I moved away from support because it felt like I was just fixing wrong notes all day, with whiny orchestra members (end users).
I think the strong correlation you refer to arises from the fact that maybe programming and musicality come from the same parts of the brain? Just my theory, for which I have no supporting evidence :)
-CausticPuppy "Of all the people I know, you're certainly one of them." -Somebody I don't know
Very good points. I did an internship at Motorola once doing various programming duties in one of their factories. One of the systems we wrote had to 1:) work on *old* macs (Mac SEs) 2:) interface to the main defect database. What was the solution? A combination of a C program and shell scripts (awk and sed) on the unix/database side and a *Hypercard* application on the Mac side. We had Hypercard modules to interface with laser scanners and the mac had touch screens. This system worked wonderfully. This whole thing about 'real world' programs is stupid. *every* program is a 'real world' one because the developer (or developers) is using tools at hand to get a job done...in the real world. Man I get sick of the whole academic/theoretic look at things all the time.
You mention LISP, well how major LISP applications are in COMMON use everywhere (ie. a "real-world" application?
You ask the wrong questions. Lisp is not used to solve common problems, people gravitate towards Lisp because their problems cannot be solved by the 'common' languages.
You mention LISP, well how major LISP applications are in COMMON use everywhere (ie. a "real-world" application? Only one really springs to mind: my favourite editor, EMACS - but even this has a relatively limited potential user-base, and even amongst developers it certainly isn't close to being the most popular.[)]
Good point. But I don't think emacs is the only program that adds extensibility with lisp. ISTR an engineer friend of mine telling me that AutoCAD uses lisp as an extension language too.
There is also siod (festival uses siod; probably other apps to too) and hopefully guile will take off some day too (some gnome apps might use it already). --
> I'm sure VB is hot for business apps. But I can't say I care. What about real-world apps
Since you've no doubt been duly flamed over the bogus distinction between "business" and "real world" apps, I won't visit it. I'd just like to register my opinion (okay, pontificate) on what a "real-world" app is.
Real world is not when your entire company has a need, goes to development, draws up requirements, negotiates price, goes through develop, test, deploy, test for real, revise, etc. Real world is when a department head has, say, an employee database like schedule times, for example, and wants it popped up on a web page or viewable in some quick tool they can pop up on their desktop. They go to the department's local programmer-dude (which I am in my department) without an actual developer title (usually a tech/admin) and say "hey can you do this?". Tech bangs out some perl or VB or shell script or excel macros, and there ya go, that work for you? Good, problem solved.
Real world is ad hoc, and VB lends itself to ad hoc solutions. I would consider software engineering to be necessarily several levels removed from this Real World, in order that the problem space becomes their world for an extended period. That's when you have systems programming languages like C++ or Java (yes it's the systems language of the Java platform).
Personally I don't think VB is ad-hoc ENOUGH, and its greatest weakness is that it only manages to do a half-ass job at being a quick-and-dirty prototyping system and being enterprise class, by trying to be both.
VB has been around for 8 years. Java has been around for about 3 years. C/C++ was around when time dawned
But VB still came out on top when 150 developers where polled. Perhaps they only asked developers who worked in Microsoft houses.Perhaps Microsoft funded the survay. Perhaps we are all missing the marketing from Microsoft and are using the "wrong" dev tool when we whip something quick and dirty up in Perl.
IMHO C/C++ will never die out. Java will continue to grown as long as Sun and IBM continue their support. VB and the other Microsoft "Visual" (I never did work that out) development tools will last as long as Microsoft continues it's agressive marketing of NT server / Windows dekstop enviroments.
I wouldn't grapple with the problem of "not getting the poll"... they don't give much in terms of the poll from a bird's eye view. Who did they poll? Were they young, old? Do they have educations? Did they only poll developers at Microsoft partner companies? We just don't know (at least at 7am I couldn't find any links with any poll info/background).
I agree that C/C++ will probably never die (look at Cobol/Fortran), and I think Java will continue to grow huge on the server-side, especially servlets, given how easily they are developed and scale.
Something doesn't smell right with these statistics. The artical is too vauge on a lot of needed points. What types of companies were polled? What platforms to the develop on? What type of software do they write - internal, shareware, commercial, web, ...? Who sponsored the poll? What are their geographical locations?
I am biases myself, but it looks like the poll started in favor of Microsoft development tools. If you ask ANYone I know, they would say for the Windows platform, Visual C, Delphi, and last Java. *nix is another story.
Let me explain why. If I look on my Windows computer, most of the software is commercial. I have Netscape, MS Office, Seti@home, Easy CD Extractor, Norton Antivirus, etc... All of the above is written in Visual C except for one, Easy CD Extractor is Delphi. I have other software written in Visual C others written in Delphi, but I can't say the same for Visual Basic. I have zero programs running on my computer using Visual Basic.
But I am biased.
Ozwald --------------------- "To avoid seeing this message again, always shutdown your computer by selecting Shut Down from the Start menu" -- scandisk
You can't really argue that VB isn't programming cause it hides too much - cause then Java would lose out big time (considering VB has access to memory directly thru varptr, strptr, objptr and memcpy).
How do you combind C and C++ in one category? On their extreem ends, C++ being written with OO and templates and C not, you get two very different languages, though you can write C++ in C style. But then again, you are just writting C.
But then again, combinding php 2 and php 4 is a very arguable situation.
You don't have to use all that many of the C++ features as long as some are useful -- such as overloading. For some applications, you wouldn't use templates, multiple inheritance, or a boatload of other stuff, but a handful of classes and some of the syntactic sugaring can save you time -- and it's not strictly C anymore.
-- the silly student / he writes really bad haiku / readers all go mad
Because C++ is a superset of (most of, that is, ``clean'') C, and I'd imagine that there aren't huge mounds of programmers out there who know C but don't know anything of C++ yet. Of course, for those that know C++ but not C, I fear for them having to learn it backwards, should they ever find the need for C -- regardless of what Bjarne may say, as egotistical as he is.
On their extreem ends, C++ being written with OO and templates and C not, you get two very different languages, though you can write C++ in C style.
While it's true that using C code in a C++ application is usually counterproductive at best and a complete kludge at worst, I'm not sure how you mean, ``write C++ in C style''. You mean bother yourself to use all of the features of C++ by ignore their intended usage? That's even worse than including C code in there. ;)
So, yeah, C and C++ are two completely different approaches to programming. However, they are quite similar, one being the obvious extension of another, and most people who know one, know the other. It's not that big of a leap. Java, on the other hand, may have syntax similar to C (but then again, so does Perl), it is not a natural extension of C++.
In short, to be very precise, the C++ specification includes most of C (there is very little of the original C language that is unsupported). C is a subset of C++, C++ is a superset of C. So, in essence, they are the same language.
~ Kish
If you have something intelligent to say, you'll log in or get moderated up so I can read it. Otherwise, you're wasting your time.
"C style" (Score:0) by Anonymous Coward on Wednesday October 27, @03:14PM EST (#263)
I think what he meant was (if you think of C++ as an object-oriented language primarily, rather than a language with a whole bunch of features), was that you could write code making use of C++ features (eg. overloading) without really taking advantage of the object model, and so still be in the "C style" (ie. procedural) but without C compatibility.
There are some advantages to this. Making use of function templates for nice typesafe algorithms has some appeal, even if you don't want to use classes and objects.
Re: "C style" (Score:0) by Anonymous Coward on Thursday October 28, @10:17AM EST (#341)
You could go the other way around too. I mean, there's nothing about the C language that stops you from writing extremely object-oriented programs (not quite the same approach as C++, though). Substitute structs for classes, and use pointers whereever a struct contains another struct, and you can create a hierarchy of structs that resembles a C++ class hierarchy, even to the extent that each different type of struct has its own constructor and destructor (which are called directly instead of malloc() and free() or C++'s "new" and "delete"), and calling the constructor of the top-level struct malloc's the entire hierarchy. In case you've never seen this done before, it would look something like this:
Re: (Score:0) by Anonymous Coward on Thursday October 28, @10:33AM EST (#342)
You could go the other way around too. I mean, there's nothing about the C language that stops you from writing extremely object-oriented programs (not quite the same approach as C++, though). Substitute structs for classes, and use pointers whereever a struct contains another struct, and you can create a hierarchy of structs that resembles a C++ class hierarchy, even to the extent that each different type of struct has its own constructor and destructor (which are called directly instead of malloc() and free() or C++'s "new" and "delete"), and calling the constructor of the top-level struct malloc's the entire hierarchy. It's C, C++ style. For clarity, an example (not included: error checking):
C++: // Essentially calling the constructor // directly anyway... For some reason // C++ programmers seem to like capital // letters, so I'll call the class // Barclass instead of barclass
foo = new Barclass(creation_parameters);
foo -> do_stuff();
// Call the destructor, again, essentially // directly.
delete foo;
C: /* Call the constructor directly without trying to hide the fact that you're doing it. */
foo = new_barstruct(creation_parameters);
/* So the function that handles {foo} is outside of {foo}. So what. */
do_stuff(foo);
/* Call the destructor. */
destroy_barstruct(foo);
Re:Well.. (Score:1) by Carbon Blob on Wednesday October 27, @03:55PM EST (#273) (User Info)
> C is a subset of C++, C++ is a superset of C. > So, in essence, they are the same language.
Wow... try taking that to comp.lang.c!
C is not a subset of C++. C++ is not a superset of C.
Re:Well.. (Score:0) by Anonymous Coward on Wednesday October 27, @04:29PM EST (#280)
C is not a subset of C++. C++ is not a superset of C.
Yes, they are. They are not a proper superset or subset. There are small areas where the standards do not overlap, but more than 99% of the standards do in fact overlap and are subsets/supersets.
Re:Well.. (Score:1) by vt@office on Wednesday October 27, @04:37PM EST (#282) (User Info)
In short, to be very precise, the C++ specification includes most of C (there is very little of the original C language that is unsupported). C is a subset of C++, C++ is a superset of C. So, in essence, they are the same language.
Exactly, as the Java and Fortran are the same language because you can still write code using Java syntax and Fortran mentality and semantics.
C is a functional programming language, C++ wanted to be object-oriented, but failed because it allows people to think that, quote, C and C++ are the same language, end quote, and not enforce the object oriented thinking, which results in a terrible mess.
Java, on the other hand, doesn't allow that, and though you still can get away with programming using Java syntax and (name-it) functional mentality, it's much more difficult than to grok what OO is and do it the right way.
OK, kids, now get away from appliances, we're gonna reboot the house
The argument that Java changes more than C/C++ is not entirely accurate. The API's do change, but at least they are trying to change them for the better. In C/C++ the standards took *YEARS* (too long) to hammer out. You also can't trust what one platform (especially *nix) or compiler supports. Give Java the same amount of time that those standards committees took to "standardize" C/C++.
Intersting that the survey treats C as sepreate entities. I mean, I know they are technically but how many programmers are exclusivly one or the other. In terms of the survey this wouldn't have changed the result first question but when asked thier second favorite how many who had chose C as their favourite chose C++ as their second favortite or vise versa. Would java show as being more popular other wise. I'm not syaing there's a hidden agenda - just it pays to be suspicious. Especially when we don't have the study just the review. ... with eskimo chains i tatto my brain all the way...
There are a lot of UN*X people still writing ANSI C code, and it's not just the FSF either (though they're a high-profile offender :). There probably are people out there writing C code with C++, but from what I've seen, most C++ programmers are actually writing C++ code. I'm not saying it's good C++ code, but it is C++.
I'm one of them - I program pretty much exclusively in ISO C and Tcl in my professional capacity. The amount of C++ code (as opposed to C code that happens to go through a C++ compiler) I've written in my life fits on one A4 page in 12 point type.
This surprises many people, especially when I mention the size of the main application my group develops and maintains. There are a lot of people who regard implementing, and especially maintaining, a moderately large (tens to hundreds of thousands of lines) project in C as essentially impossible. I *know* this isn't true - it's actually not too hard at all *if* you hire people who know what they're doing.
Many people will write difficult to maintain, non-scalable code no matter what programming language you put in front of them. ISO C isn't perfect by a long shot, but those who claim that using C effectively in a large project isn't a realistic thing to do are simply wrong.
ISO C isn't perfect by a long shot, but those who claim that using C effectively in a large project isn't a realistic thing to do are simply wrong.
While one can use C for large projects, using even a very restricted subset of C++ is probably a better solution. For example, if the only C++ feature you use is classes, you can design a much cleaner interface between different parts of a large software system.
A lot of people take the "all or nothing" approach to C++, but it wasn't designed to be used that way. Use what you need, and forget about the rest.
A lot of people take the "all or nothing" approach to C++, but it wasn't designed to be used that way. Use what you need, and forget about the rest.
Hmm, I don't see this as that simple an issue.
There are things in C++ I'd rather people not use or even know about. So can I just forget them? Of course not.
This is how it usually goes. You end up inheriting code from somewhere or someone. You need to maintain it, or maybe further develop it, or whatever. But the people who first wrote it, used those things you don't want to know about.
So do I just forget them? No. I have to live with them. Either that, or rewrite the whole thing.
So you just can't "forget" a feature exists in a language. You'll have to learn it, know it, and live with it. Like it or not. Software and especially source code lives a long time. And all the not-so-nice things live with it.
However, if I was faced with a choice of doing a very large project either in C or C++, I might still be inclined to pick C++ and try very very carefully to use very limited set of its features. Just having real objects around when designing a large software project is really worth it. But that's only if the only alternatives were C and C++.
Ah, well... I was assuming that we were talking about new projects; its sort of obvious that you can't forget about code that someone else has already written and needs to be maintained.
I can't think of a good reason to use C for anything new, now that there is an ISO standard for C++, but sometimes I do it anyway. :-|
TedC
bah (Score:0) by Anonymous Coward on Wednesday October 27, @07:49AM EST (#25)
I don't think this survey is representative. Anyone using a decent operating system can't use VB. I think they asked Windoze users only. Among them, VB *is* popular (for whatever reason), and might actually get 35%.
But, of course! How DARE they step on your righteous foot and include a non-unix OS. After all, everyone knows that if you can't do it in a unix, it simply should not be done. Damn that decent graphic arts software on mac and windows platforms. Real elite d00dz use command line programs for graphics.
drwln 482 382 5 1 clr 83 255 48 0
Oh yea. I almost forgot to say how much everyone who doesn't know c or c++ sucks. You all suck! A LOT!
You probably got me wrong - I'm not saying they shouldn't have included Windows programmers in their survey. I'm just saying they should have asked everyone including Unix, BeOS and MacOS developers. For all of those, VB isn't available. Therefore, I don't believe it has 35% total. 35% among Windoze programmers, maybe.
Sampling is a big issue here, and they probably didn't do it well.
Remember, though, most programmers are still forced to write for Windows or (gasp!) mainframes. I wish it weren't so, but that's why Microsoft is still a behemoth. Even with proper sampling VB would be in the top 4.
Folks complain about vb, and it's really a pretty horrid language, but the dev environment fills a very distinct and useful niche, which is what makes it so popular.
If you need a quick GUI, say for a DB front-end, it can be tossed together in vb very quickly. Java's nice, but the gui stuff keeps changing. And, whatever you think about the COM/CORBA wars, there's an awful lot of useful COM objects out there, and vb makes a nice glue for them.
This comes as no surprise to me. The advantage VB has over other scripting languages is that it has a reasonable learning curve. People who would rather be focusing on something else can very quickly learn how to do simple stuff in VB, and as their skills improve the language still supports their new needs up to a fairly high semantic level. I know quite a few companies whose basic development methodology is to string OLE/COM/ActiveX components together with VB, and it actually works quite well for them.
For contrast, consider something like C++. This is simply not an appropriate choice as a first language for someone new to programming. People (ab)using C++ without having a decent grasp of programming (particularly modularity/OO aspects) first have caused more pain and frustration for their better-trained fellows than I care to think about. In this group I include the designers of the most common C++ class library - MFC, which by itself has done more to turn people off C++ than even the language's own nastiness could do. This relative inaccessibility explains C++'s place behind VB.
As an aside, is perl a good choice as a first language? Personally, I don't think perl is a good choice for much of anything, but I suspect that even the most ardent perl advocate would admit perl isn't likely to appeal to first-time users. It's not meant to. (Python, on the other hand, would IMO make a very good first or teaching language.)
Java's low position on the list is best explained by three things: its relative youth, lack of proper support for certain types of programming, and performance. The youth issue is pretty self-explanatory. As for lack of support, here are some thoughts:
The first issue is platforms. You'd think you could find a JVM on just about anything, but you'd be surprised. For example, even though an MS JVM exists Windows CE, the manufacturer of the particular device I own (a Sharp TriPad, same as a Vadem Clio) didn't see fit to make that available and I've had no luck finding one elsewhere. So much for Java on that platform.
Support for the latest version of Java is often lacking. Java 2.0 Platform is still pretty much a Windows/Solaris thing even after all this time. Admittedly, this is mostly a library issue, but as long as Sun makes it difficult for someone else to provide equivalent libraries this will remain an issue.
Lastly, while Java may be great for applets, some aspects of Java make it difficult to use for standalone applications of any complexity. In the real world, programmers often need to interface with in-house libraries. The fact that these interfaces are probably C-oriented is a minor issue. The major issue is that Java doesn't provide a decent way to interface to these libraries even if they were also in Java. Stupid.
I think the performance issue is mostly BS. Sure, an interpreted or incrementally-compiled language such as Java will never be as fast as a fully-compiled language, but with modern technology the difference is very small. The weird thing is, the same PHBs who can't get "Java is slow" out of their heads have no qualms about using VB. What's up with that?
*Cough*. From experience, VB3 produced executables with only dependencies being vbrun*.dll.
Let's just say that when I did pre-University work experience, I learnt & hacked VB3 and above. When I got to Uni, I was doing C, C++, ML, ... and now I'm working in the IT industry (surprisingly enough) I'm not doing that much actual coding. Perl scripting is prevalent, java does the rounds, and the mainstay is C. ~Tim -- .|` Clouds cross the black moonlight, Rushing on down to the circle of the turning world .|`
But how efficient are those executables? I can think of several ways to generate an executable from VB:
Just toss the interpreter plus the original code into a "pseudo-executable".
Compile the original code into some intermediate form and toss in an interpreter for that.
Actually compile the original code, and toss in or link to a run-time library.
None but the last approach offers any significant promise of being comparable to the same functionality implemented in C/C++, and even then it depends a lot on the complexity and quality of implementation of the runtime.
One experiment would be to see how large a very minimal VB executable would be: if it's really big, chances are that they're "cheating" and they're probably using one of the first two approaches. I don't use VB myself, or else I'd do the experiment myself and post the results.
printf() is a huge function; did you link statically? Did you strip debugging info from your executable? I get it down to 2900 bytes (dynamically linked PowerPC ELF bin) with GCC 2.95.1. sterwill@zappa [~] cat foo.c int main(int c, char ** v) { printf("Hello World!\n"); } sterwill@zappa [~] gcc -o foo foo.c sterwill@zappa [~] strip foo sterwill@zappa [~] ls -l foo -rwxrwx--- 1 sterwill sterwill 2900 Oct 27 10:33 foo* sterwill@zappa [~]
-- If you won't log in, I won't read your comments. Anonymity is for cowards.
This is so compiler dependent as to really be meaningless, especially since both have their own library DLLs.
Anyway, I can tell you are running VC++ 6.0, as I got the same results. However, simply selecting "Multithreaded DLL", essentially telling C++ to use the C library DLL instead of statically linking to it, brings the executable size down to 16kb. I suspect that VB simply doesn't give you this choice.
But again, this is really all meaningless as it is all compiler dependent. I remember a time when most compilers could produce real, useful executables under 16kb. Does this mean that vendors now suck? Well, not in and of itself, because being able to produce small executables means just so much less today.
Blame gcc. On my Ultra 10 running 64-bit Solaris7, hello world compiled with DevStudio comes out to 6104 bytes, and with gcc comes out to 24,368 bytes. gcc compiling with any amount of optimizations shaved a whopping 16 bytes off the executable. DevStudio compiling with -xO5 -xspace brought it down to 1999 bytes.
Gah, I managed to screw up the name of the compiler every time. It's DevPro, not DevStudio. Suffice to say I prefer it to gcc every time, and thankfully so does autoconf.
Oh, please, not yet another complaint about the size of "hello, world" compiled. Let me guess: you've never written anything larger than the Fahrenheit-to-Celsius converter in K&R. This has absolutely nothing to do with any real world problem. If you want a program to say hello, here you go:
#!/bin/sh echo "hello, world"
Use the right tool for the job.
Judging C/C++ compilers by comparing "hello, world" sizes is like buying a car based on the horsepower of its starter motor.
Re:Makes sense (Score:0) by Anonymous Coward on Wednesday October 27, @12:02PM EST (#197)
You're missing the point. The discussion is not a complaint about how big "hello world" is, but is a (misguided, doomed) attempt to determine what's really in a Visual Basic executable - original code, bytecode, or actual compiled code.
I can think of several ways to generate an executable from VB:
Actually compile the original code, and toss in or link to a run-time library.
This is what they do -- actually compile the original code down to a Win32 PE. The end result includes some stub code that links in the executable to the runtime library. They've been doing this since VB5.
Benchmarks indicate that in some areas, the performance is in the same range as VC++. Most VB programs spend their time in the GUI, accessing a database, or making Win32 API calls, so they don't see much of an improvement anyway over P-Code (which is still an option).
Natively compiled or P-Code compiled (compacted?), the same runtime must be shipped with every VB program. Not a problem when you're writing a database app (as I'd wager most of these "business apps" mentioned in the article are), but when your 50K utility requires you to ship a 1.3 MB runtime, it's a real pain. It's also why the market for the ActiveX controls I write is pretty much limited to the VB world -- they've already got to ship the runtime, so it's not as big of an issue for them.
Eliminating the runtime dependency by having VB statically link in selected portions of the runtime (I don't need a minimum 1.3 MB executable, thank you) has been a long-standing request of a portion of the VB crowd. Unfortunately, MS is still all fired up to make VB a web site development tool, and the preview of VB7 (probably an alpha build) showed only how to create HTML pages in VB. Gack.
Minimal EXE would not let you tell 'truly compiled' from 'pseudocode+interpreted' approach: runtime may weigh too much. This is the case if you use Delphi: all that mechanics to load forms, etc takes a couple of hundreds of kilobytes (unless you don't use anything Delphi is designed for, that is, RAD features). But it's not of importance, since exe size grows slowly as code is added. Good pseudocode + good interpreter for it can de pretty fast, at least, for a GUI frontend :-) VB has disadvantages more important than the performance, IMHO... But it's a good glue if you have something to glue :-)
>Minimal EXE would not let you tell 'truly compiled' from 'pseudocode+interpreted' approach
True enough, but not quite for the reasons you state. What you need to look at is the executable plus whatever libraries it links to, and how much that increases system memory usage. Some examples:
If a VB executable is statically linked with a large runtime library that could otherwise be shared with other VB executables, it's a hog.
If a VB executable is dynamically linked with a large runtime library but it's the only executable on that system using that library, it's still a hog.
If a VB executable is dynamically linked with a large runtime library that is actually shared with a whole bunch of other VB executables, it's not a hog.
If a VB executable is linked with a small subset of a runtime library, whether statically or dynamically, it's not a hog.
And so on. I think the secondary issue here is what typically happens for VB executables and C executables. On most systems, pretty much everything uses the C runtime, so its memory cost is amortized across a bunch of programs. Another poster has pointed out that VB executables can be dynamically linked to get the same effect in the right environment, which is nice, but that they are often statically linked with a large runtime and are, therefore, hogs. Hogs slow down your system by consuming resources even if they themselves don't seem particularly slow.
Getting back to the original issue, which performs better: Java or VB? I don't know the answer, actually. My point is that the PHBs who complain about Java performance and then use VB don't know either, and that's stupid.
I doubt anyone is still reading this, given /.'s collective attention span, but I'll provide some facts here anyway:
Another poster has pointed out that VB executables can be dynamically linked to get the same effect in the right environment, which is nice, but that they are often statically linked with a large runtime and are, therefore, hogs.
I don't know what post you're referring to, but this is incorrect. VB programs are always dynamically linked. It is impossible to statically link a VB program with any other compiled code. This is something that many VB programmers have been complaining about for years, although I understand the reasoning behind it. (You haven't seen many VB programmers worried about the Y2K bug, have you? That's because MS simply distributed a patched runtime library, and most VB programs were instantly fixed.)
Getting back to the original issue, which performs better: Java or VB?
In theory, since VB compiles to machine code (by default), and Java compiles to bytecode (always, AFAIK), VB should be faster. In practice, of course, the quality of the compiler and the runtime is a much more significant factor, so YMMV.
You haven't seen many VB programmers worried about the Y2K bug, have you? That's because MS simply distributed a patched runtime library, and most VB programs were instantly fixed.
Ha! I note you say most, but I just wrapped up a contract to rewrite a VB3 program in VB6. Why? The VB3 program used Jet 2.0 for data storage, and MS won't certify Access/Jet 2.0 as being Y2K compliant.
Funny thing is, the program does no date calculations at all! Still, it was a nice chunk of change...
To be concise: hell no.. It is probably best for those that know C and a little about OOP (or those that know C/C++.. if you don't know anything about OOP, you might not ``get'' it -- in its entirety -- quite as easily while trying to learn Perl, though YMMV). I personally think it's incredibly useful for what it's designed for, but anyone who wants to learn that as their first language is crazy (though not quite as bad as Pascal). C or Java are much safer choices (though I'm sure you know which I'd prefer).
~ Kish
If you have something intelligent to say, you'll log in or get moderated up so I can read it. Otherwise, you're wasting your time.
That's the conventional wisdom all right, but I wonder if it's really true.
If Larry Wall is correct that the design of Perl reflects human natural language in a deep way, it could actually turn out that Perl isn't all that bad as a first language. If you've got the head of a math geek, Perl looks like a mess, but not everyone really has a head like that. Could it be that Perl would be a better first language for English majors?
I doubt that anyone has actually tried a pilot program "Introduction to Programming Using Perl". I bet that the main reason that people keep trying to discourage newbies from using perl is that the perl gods were getting tired of the hordes of clueless twits that descended on comp.lang.perl.misc when the web went critical.
>If Larry Wall is correct that the design of Perl reflects human natural language in a deep way
On the other hand, Larry Wall might be full of it. I personally think he is, on this and other topics - but even more than usual with this claim. The "design" of Perl (a misnomer, since Perl wasn't so much designed as evolved) certainly does not reflect in any meaningful way how I personally process either human or computer language.
I learned PERL as a my first language and I'd have to say I liked it a lot. I found it very approachable, as a newbie. Why?
It isn't strongly typed - I like the fact that a scalar can hold any one chunk of data, whether it be a string, a float, or a int.
It's pretty abstract - I know that more experienced programmers will laugh, but the truth is I could care less about what's actually going on in memory. When I want to add items to an array, I don't want to worry about overflowing the stack. Perl makes room for me (at the expense of speed, sure, but I can live with that).
It's pretty intuitive - (In my mind)
Learning Perl - Randall Schwartz's book is great.
No, I'm not a full blown programmer (I don't claim to be) and yes, I was a liberal arts major. For the things I wanted to do (CGI programming, primarily, and just learning the basics of programming), PERL was great. It gave me enough familiarity with data structures, control structures, etc., that I've been able to pick up some C and Java on my own. Now that I have some experience programming, I can see why things like working in a strongly typed language and actually knowing what is going on in physical memory are useful.
Before learning PERL I tried learning some Java, but I couldn't wrap my head around issues like why you wouldn't want all your variables to be global, or why all variables is so strongly typed (yeah, I know, stupid liberal arts major). OOP was beyond the scope of my comprehension, and a majority of the books I found on Java assumed you knew C and C++. Now that I have experience working with subroutines and have made mistakes (like not my'ing my local variables), I can see the advantages of these things...
I find the notion of anything even approaching bit bashing to be.. well, I have a strong aversion to it, because I'm not overly mathematically inclined. My forte is English. When I first tried to learn Perl (after having a bit of experience with C), I was ``mildly'' lost, to say the least. After learning more about C++, it all fell into place.. quite nicely.
Of course, even though that was some time ago, I still doubt anyone but the most eclectic of programmers would find Perl to be a good language to begin with. It would be a very strange progression indeed to move from Perl, to, say, C. Perhaps even more painful than regressing from C++ into C with no previous working knowledge of C.
I bet that the main reason that people keep trying to discourage newbies from using perl is that the perl gods were getting tired of the hordes of clueless twits that descended on comp.lang.perl.misc when the web went critical.
I rather doubt that. The Perl community, overall, is a rather friendly one (even if I still think that Tom Christiansen is.. well, let's not go into that ;).
~ Kish
If you have something intelligent to say, you'll log in or get moderated up so I can read it. Otherwise, you're wasting your time.
VB first? (Score:0) by Anonymous Coward on Wednesday October 27, @07:52AM EST (#29)
Basic is a inherently bad language and one company decides to make a visual equavilent of that bad language. M$ has made VB popular for better or worse. Another thing is that it is so easy to use because of M$'s idiot proofing (if grandma ever master that mouse then VB would be her programming language).
I personally do not have vb and I had a whole year of classes on it. Of course, I do not do any gui stuff really, but when the time comes I will use a good tool kit like qt or gtk (I have heard bad things about gtk, but it is gpl).
p.s.-- M$ Word '97 seems to have this annoying habit of putting a space at the beginning of a line. An example would be when there is a end to a sentence I put a period then I put two spaces like any half decent typist would but if the first space makes the cursor move to the next line then the second space idents the line slightly (by one space). There anyway to change this? No other word processor seems to do this.
Like any good typist? Yep, but you aren't using a typewriter.
You should use two spaces if (and only if) you are using a monospace font. Even then, the extra space ought to be inserted by the word processor.
You should only use a monspace font for special effects. The whole concept is a hack designed for older printer and typewriter technology. Nobody prints a respectable magazine that way. Proportional fonts are just easier to read.
You should never underline text. No joke. In places where a typist would underline, you should use italics. Underlining is yet another hack for typewriters and old printers. Good quality printing has always used italics.
I'm not surprised VB is so popular. Look how many Windows desktops there are out there, and look at how god-awful Visual C++ code is. VB has a pretty nice development environment, and is (apparently--I'm not a VB guy) great for quick and dirty Windows GUI apps.
The fact that the entire language seems to me like a gigantic glueball(in the sense of it binds everything together, it picks up some rather shocking cruft, and you'll sometimes get stabbed by something locked inside) doesn't take away from the fact that glue can be great for whipping things together--just ask TCL developers.
Past that, I'm not surprised Java hasn't overtaken C. Beyond the whole speed factor, C is just alot cleaner for the non-expert programmer to mess around in. Particularly when it comes to making patches to existing codebases, there's just so much less to need to figure out in C than in a fully object oriented language such as Java. Granted, when C is forced to do things C does not like to do, C gets very crufty(thus the recent complaining I've been hearing about lsh's pseudo-object system), but a) There's a massive codebase out there written in C, b) There's a massive amount of deployed C code(this isn't the same as a), and c) C is less daunting for a moderately skilled programmer to mess with.
However, I must say that the reason Java hasn't displaced VB down to third(VB/Java address a different market than C, if you think about it) is that Sun royally and utterly bungled its deployment. VB projects "compile" down to an .EXE and a few random .DLL's that might have to be installed. C code compiles to executable files and some libraries that you probably already had anyway.
Java development with the JDK is laughably awful, and will someday be a textbook example of how not to burden your coders and your users.
From what I've seen--and I'm sure the experts can enlighten all of us further--merely getting javac to function(got everything in the right folder? Got your path environment set right? Sacrifice the correct barnyard animal?), then executing that Java app(better nuke the henhouse just to be sure) is far beyond the difficulty in even writing a simple Hello World!
The fact that code never compiled into a single file didn't help either--web deployment was a mess, with forty web server connections for a single semi-useful app. JAR finally fixed this, but THAT standard got mangled by CABs.
Don't even get me started on Code Signing--there are three, three, three ways to go for this little project.
Alot of the problems wouldn't have been as significant if javac was as straightforward to play with on your average Linux distribution as, say, gcc. The non-free aspect of Java destroyed this possibility--and Sun's new "Gotcha Source" License isn't helping.
Java came out of the gate hard to install, harder to deploy, slow to load, and slower to run.
Things have gotten better--J++ and the MS VM have been instrumental in this regard--but the core usability of Java is farrrrr less than VB, and even less than C.
Actually, I had just about given up on Java until I found the one company that has truly understood the promise of Java. Mindbright. I've already written about these geniuses here, but suffice it to say, the fact that there's now a extremely high quality Java deployed SSH and SSH-VNC(VNC into those hosts behind the IP Masq, all via SSH) solution is amazing, and caused a complete reversal as to my opinion of the viability of Java as a useful platform.
Using something written in a language on a daily basis will do that. ;-) So, yes, overall I'm still quite hopeful.
Yours Truly,
Dan Kaminsky DoxPara Research http://www.doxpara.com
Debugging is anticipated with distaste, performed with reluctance, and bragged about forever.
I'd have to differ on the statement that Java is more daunting or difficult than C to the newbie. The Java VM hides tons of stuff the newbie doesn't have to care about.
C to print something: printf("foo: %i %b", 10, TRUE) // something like that right?
whaa? As a newbie I found C very cryptic and daunting. Java hides, for instance, nasty things like pointers, and is very developer friendly. C is good for small tight algorithms, libraries, etc. But anything to do with output or something complex enough to require an object model, C becomes a tangled mess.
Precompiler directives, that's another confusion. For machine indepence you're going to have to know about special defines for basic types, and also calling conventions (stdcall, etc.), all sorts of weird mangling phenomena, exports imports, linking, object files, etc...
I agree that the types can cause problems. For a lot of my code, I've got my own typedef.h that aliases things like int32 to types native to that machine. Why? Because I'm reading/writing binary data to network storage, accessible to different platforms, as well as transferring it over the network, and it *really* matters that I know what size data I'm using. That, plus the endianness (the convention being to use big-endian on disk or wire...).
OTOH, the Java docs that I've seen didn't even bother to mention the endianness issue -- a bit of a bother considering that one has to know about it if you're not requiring that java be used at both ends. Turns out that it seemed to be big-endian on all platforms that I tried, a Good Thing.
C/C++ also aren't that bad if you're used to thinking abstractly. Then, pointers aren't a problem at all if you're not doing rampant dynamic memory allocation (especially in C++, with destructors, combined with class methods if you want to be truly evil and lazy)... -- the silly student / he writes really bad haiku / readers all go mad
According to the specifications, Java *always* uses big-endian byte ordering. It is in the documents; it's simpy buried somewhere (I don't remember where I found it, unfortunately, otherwise I'd provide a link).
I discovered this when trying to read a file formatted little-endian, and had to come up with (what I considered) to be some very clunky hacks to read the little-endian data correctly (reading it in backwards, then doing byte swaps). Doing that also pointed out how few unsigned types there actually are in Java. I wound up having to use the next size up (ints for short ints, etc.) in order to not have Java mangle the value of the data I was reading in.
I suspect it was done this way because of the platforms they developed on (I'm assuming Sparcs or similar) being big-endian as well. Then again, you know what they say about assumptions ("When you assume, you make an ass out of 'u' and 'me'.")
It probably has something to do with the fact that the default network byte ordering is big-endian. Of course, that probably has its roots in the platforms the Internet got its start on...
C is much, much easier to hack on than to code from scratch. I know, I'm a much better code hacker than a coder.
I am convinced, though, that Java would be far, far more universal had it been deployed better. It seems to me that Sun, in its zeal to shift the deployment pain from the client to the server, shifted pain that didn't need to exist in the first place.
What, did Sun fire every single one of it's UI guys? Or is there a presumption that developers can handle any nasty UI problems that are tossed at them? Might explain vi...;-)
[No, I'm not getting into a language war. This is beyond language.]
Yours Truly,
Dan Kaminsky DoxPara Research http://www.doxpara.com
Debugging is anticipated with distaste, performed with reluctance, and bragged about forever.
This is sort of a non sequiter, but I have to post somewhere....
I think Java is a pretty good language...some things really bug me (inability to abstract fields in a class, etc.). I, personally, would love to see Java natively compileable. There really isn't any reason it can't...it's a language just like any other.
Then we would see /true/ platform independence...not only would Java be able to run on any platform, it would be able to be /ported/ natively to any platform, which is a boon for C and sometimes C++.
I programmed in Java before C and found it to be much easier. The difficulty in Java is simply in understanding object orientation. Once you understand that it's all easy.
Compare that to C where you have to understand pointers, precompiler directives, makefiles, and all kinds of nasty things.
The above example shows one thing that Java does amazingly well compared to C: strings. As a beginner programmer the concept that a string is a null-terminated array of characters, and that when you talk about the "string variable" you're actually referencing a pointer to the first element in that array... that's just plain hard. Java makes Strings super easy.
Compare: if (strcmp(blah, "bob")) to (ps, you also have to include the right libraries for this one using strange precompiler syntax but we'll ignore that for now) if (blah.equals("bob"))
Which is more intuitive?
Java is very young, very unstable, and not very well suited to certain things. But I'm convinced that if you give it about 5 years it will be a huge mainstream language. I'm actually surprised that in such a short time, and despite all its flaws, that it's already in third place!
I think that, just perhaps, your argument is strengthened by the fact that you got the C wrong.
if(strcmp(blah, "bob"))
If I recall correctly (and I *did* just check the man page, just to make sure), strcmp returns 0 if the two strings are equal, not 1 (which indicates that blah is lexicographically "greater than" "bob").
The "Microsoft VM" is correct. Its kinda a cross between Java, DOS, and the toaster. Plus some unholy relics from another dimention. It sure as hell isn't a JVM.
The "Microsoft VM" is correct. Its kinda a cross between Java, DOS, and the toaster. Plus some unholy relics from another dimention. It sure as hell isn't a JVM.
It runs Java applets, it's faster than a WOW Potato Chip, and it's surprisingly stable(unlike anything embedded in Netscape).
C'mon. You know you'd love it if it came from Linus. You know you'd praise its speed, and say that its bugs would be worked out soon enough, etc.
Linux bigotry isn't any more rational than PHBigotry, but it sure is a hell of alot more annoying.
This is coming from a hardcore Linux user, btw.
Yours Truly,
Dan Kaminsky DoxPara Research http://www.doxpara.com
Debugging is anticipated with distaste, performed with reluctance, and bragged about forever.
My, my, my... What a tempest in a teapot (er; coffee mug, that is ;-) we have here. Let's not forget that they sampled only 150 buisness developers for their survey. In my field, if you sampled 150 developers the #1 language would be: FORTRAN. Yup. FORTRAN. No other language has quite the support or the libraries to do full-up parallel and/or scientific programming on 'big iron' (Cray T3E) systems. As many other poster's have pointed out, VB is a good RAD tool (which, coincidentally, is probably what it was designed for). However, it is really only applicable when you are building front-ends for Windows stuff. Java is a great language to program in (read: fun) but, like C/C++ is kindof a big hammer when it comes to solving small, UI problems. Similarly, Perl is The World's Most Useful Language &tm; for textual applications, but not so good for graphical stuff. I guess my main point is that 35% of 150 people does not constitute a trend. These folks are a niche, just like supercomputing folks are in a different niche.
However, I must say that the reason Java hasn't displaced VB down to third(VB/Java address a different market than C, if you think about it) is that Sun royally and utterly bungled its deployment. VB projects "compile" down to an .EXE and a few random .DLL's that might have to be installed. C code compiles to executable files and some libraries that you probably already had anyway.
How is Sun supposed to compile to an exe and dlls when one of the whole points of java is binary compatibility between platforms? Also, there are options out there (Visual Cafe on Windows one example) that let you compile native executables.
Java development with the JDK is laughably awful, and will someday be a textbook example of how not to burden your coders and your users.
Then use a development environment. There are tons available including NetBeans.
From what I've seen--and I'm sure the experts can enlighten all of us further--merely getting javac to function(got everything in the right folder? Got your path environment set right? Sacrifice the correct barnyard animal?), then executing that Java app(better nuke the henhouse just to be sure) is far beyond the difficulty in even writing a simple Hello World!
I can't speak to JDK on other platforms besides Windows. On Windows 1.2 JDK none of these are issues. CLASSPATH is irrelevant. javac your application to compile it then java it to run it. It couldnt be any easier.
The fact that code never compiled into a single file didn't help either--web deployment was a mess, with forty web server connections for a single semi-useful app. JAR finally fixed this, but THAT standard got mangled by CABs.
JAR is the java standard. CAB is a Windows standard. Youd be hard-pressed to use CAB files with java on a Mac.
Alot of the problems wouldn't have been as significant if javac was as straightforward to play with on your average Linux distribution as, say, gcc. The non-free aspect of Java destroyed this possibility--and Sun's new "Gotcha Source" License isn't helping.
And exactly who is this affecting? Blackdown is working on 1.2 for Linux and IBM has a kick ass 1.1.8 VM for Linux.
Java came out of the gate hard to install, harder to deploy, slow to load, and slower to run.
Quite true.
Things have gotten better--J++ and the MS VM have been instrumental in this regard--but the core usability of Java is farrrrr less than VB, and even less than C.
No...J++ and the MS VM made things worse. The core usability of Java with a *proper tool* is just fine. How usable do you think VB would be without its GUI builder?
From what I've seen--and I'm sure the experts can enlighten all of us further--merely getting javac to function(got everything in the right folder? Got your path environment set right? Sacrifice the correct barnyard animal?), then executing that Java app(better nuke the henhouse just to be sure) is far beyond the difficulty in even writing a simple Hello World!
I'll play the expert for this one.
First of all, if you run the installer, it'll set up your environment so you can just type "java" at a command prompt to invoke the JDK.
Secondly, starting with Java2 (which was released nearly a year ago), you could specify the starting class in your .jar file's manifest, as well as any other .jars which are needed (and optionally, where to download them from if they aren't on the local system). Any decent Java IDE will build all of this for you automatically. I happen to prefer CodeWarrior.
So, with the latest JDK, you can run a Java program by typing:
java -jar foo.jar
That's it.
The fact that code never compiled into a single file didn't help either--web deployment was a mess, with forty web server connections for a single semi-useful app. JAR finally fixed this, but THAT standard got mangled by CABs.
um, .zip files fixed this in 1.0. Only MS uses .CAB, and their Java support is basically dead. There are a few dozen IDEs out there for Java now, and the vast majority of them can build direct to .jar files.
I get the sneaking feeling that you are thinking of Java for applets. Applets are perhaps the WORST use of Java around. Enterprise apps and embedded apps is where Java's at.
Things have gotten better--J++ and the MS VM have been instrumental in this regard--but the core usability of Java is farrrrr less than VB, and even less than C.
No serious company is using MS' Java tools. They don't support standards, and they haven't been updated in a LONG time. The IBM JVMs (and recent Sun JVMs) are faster on Win32 than the MS JVM.
-jon
Why Not VB? (Score:2, Insightful) by quakeaddict on Wednesday October 27, @07:57AM EST (#35) (User Info)
Just because something is simple to use doesn't mean smart people shouldn't use it. Not to be a little out of line here but I use VB for 85% of my work and I have to say that as a language it isn't as bad as some would like to think it is. It has great object based charcteristics and its devotion to COM makes component creation a snap. What VB does is allow you to abstract away the GUI. A textbox is a textbox. Theers nothing magical about it anymore, and it shouldn't be teduious for us programmers to add one to an app we are creating. There isn't a tool out there that makes adding GUI elements easier than VB (save Delphi...which has a very VB'ish interface). Alot of Microsoft's success is directly related to the tools they provided for business programmers to get their jobs done. The other thing that makes VB attractive is the way it allows easy access to various databases. In literally 1 or 2 statements you can be connected to just about any relational datastore, assuming you have an ODBC driver for it. Data is the blood of the IT revolution. Easy access to that data is a big plus. What people don't realize about VB, is that it can be used to create very powerful software components using COM, or the Component Object Model. For the last several years I have been developing statistical COM components for use in various projects here at Educational Testing Service. Once created (if created with care) these suckers fit in everywhere....they can be used in ASP scripts in IIS, in a Word macro, and even a larget program written in C/C++. You can fault Microsoft for many things but you have to give them credit for consistency. Everything Microsoft does is centered on COM. They have focus. Imagine if there were a VB like tool for Linux. What a tool that would be. Unfortunately Linux can't agree on the guts behind their GUI's (will it be KDE's version of CORBA or will it be Gnome's self created version?). What major market vendor is going to gamble on the outcome of that horse race. So again I reiterate, just because something is simple to use doesn't mean smart people shouldn't use it. I'm still working on a clever footer.
Actually there are two flip-sides to what you say. Some thoughts that come to mind: It's all very well everything being "consistent" but if you're consistently Microsoft, you're consistently closed-source. There comes a point where the warm fuzzies of "building" on existing APIs freeze their bits off and you realise you're just clicking-in more bloatware with tie-ins to Windoze, to Micro$loth, to your particular development environment ("what vbrun300.dll?"). Does VB do containers for its controls like java, or like gtk?
Is COM really common? Is it free? Where are the implementations on Unix boxes? Do people even want such implementations?
You have a *major* misconception of how things operate in your phrase "Linux can't agree on the guts behind their GUIs", as though "Linux" were a company deserving of "their". To cut to the quick, don't do it :)
There is always glade, an open-source development environment for gtk+ pushing out C, C++ or Ada code (Perl to follow, at the last count). That's quite close to a "visual" environment, if you think such things are cool. That and I suspect you've never done any coding in xemacs, either. Also you've got gnome/kde the wrong way round, IIRC: KDE is the one that uses some-CORBA,some-proprietary stuff; AFAIK gnome tries to do *everything* through CORBA. (There have been discussions on /. before now about this, I'm sure :)
It's fair enough that 'simple doesn't mean smart people shouldn't use it', but it does make it quite likely that there will be people out here who don't want to use it, quite often because it doesn't do all they want. Developers are and should be prepared to work to get things right.
A micro-story: at my last company, we had one customer from hell, as far as support was concerned. He was writing stuff in VB, using ODBC to connect, and he had a problem. I long-since decided it was a bug in VB, for various reasons (it was :) and decided, amidst the insults, to have a look at his VB project. After looking through it for 15minutes, despite his bad attitude I was thinking "this chap is paid, what, £25k/pa, to spend all day every day looking at this interface hacking this language?!", and I actually felt sorry for the chap!
Just my DM0,6- :)
~Tim -- .|` Clouds cross the black moonlight, Rushing on down to the circle of the turning world .|`
You have a *major* misconception of how things operate in your phrase "Linux can't agree on the guts behind their GUIs", as though "Linux" were a company deserving of "their". To cut to the quick, don't do it :)
Some folks wrote: >>You have a *major* misconception of how things operate in your phrase "Linux can't agree on the guts behind their GUIs", as though "Linux" were a company deserving of "their". To cut to the quick, don't do it :) and >>Thanks for amplifying his point. Yes I guess I do have a major misconception. I am new to Linux (it was installed at home until recently...I just built a new machine and haven't reinstalled it yet) and I am only going by what I have experienced. That experience, thus far, has been chaos, in a controlled sorta way. Thus my comments regarding KDE and Gnome and COM and VB. I'm still working on a clever footer.
No I suspect that despite all of our collective whims as programmers that there be something we can hang our hats on as being "consistent" or "available" across platforms, for various reasons, that just doesn't exist.
Unix folks don't like COM because its from Microsoft. Microsoft folks don't like Corba because it reminds them of Unix. We programmers decide how we want to approach the problem. In the end we decide what technology lives and what technology dies.
As to your pity being directed at us poor VB programmers, thanks but no thanks. VB has an amazingly productive UI. It sure beats the hell out of 4 xterms and writing my own make files.
I just recently took a class in X-Windows. There was a relatively simple excercise that we had to do. There were 3 sliders Red, Green, Blue. We had to chnage the color of the client area based n the RGB value of the sliders. We were using Motif. It took me a few hours (I was new to X...thus I was taking the class). The teacher asked for volunteers to bring in development stuff from work and i volunteered. In front of the class I did that same excercise in about 2.5 minutes using about 10 lines of code.
So I maintain...just because something is simple to use, doesn't mean smart people shouldn't use it.
>I just recently took a class in X-Windows. ...etc. Yes, well Motif isn't exactly the best way of doing everything, or so I've heard (comments about square roots and roman numerals come to mind :)
> As to your pity being directed at us poor VB programmers, thanks but no thanks. VB has an amazingly productive UI. It sure beats the hell out of 4 xterms and writing my own make files. That's up to the individual, I think. But give glade a blast before writing the non-VB world off as "4 xterms and writing your own Makefiles"! ;]
~Tim -- .|` Clouds cross the black moonlight, Rushing on down to the circle of the turning world .|`
Have you seen XForms? It's strictly X, making it not completely portable, but...
...it allows a C programmer to graphically layout a simple GUI, specifying callback functions and arguments. It then generates headers and .c such that your application can start the GUI quite easily.
Being mostly a C/C++/Perl programmer w/ a slight distaste for the AWT, and a greater one for Tk (which, to be fair, has graphical layout tools like XF, and *is* portable to Windows as well as Unix boxen), I find it useful.
Admittedly, the designer isn't *that* powerful (for instance, while the code will let you have a scrolling list of drawable canvasses, the designer does not appear to have a way to do that -- so what you do is write a scrollbar callback that does a left or right shift), it still lets one put up a decent utility pretty darn fast without worrying about packing or so forth.
-- the silly student / he writes really bad haiku / readers all go mad
Absoulutely true, not to mention that Basic is the language lots and lots of programmers used first. Add to that the fact that it's easy to write a slick looking program in VB fast, and it's no wonder VB is so popular. While I wouldn't even consider using VB for, say , a game program, for large bizness apps, and little personal programs, too, VB is a winner. And I hate Microsloth as much as anyone, too, maybe more (but that's another topic).
> There isn't a tool out there that makes adding GUI elements easier than VB (save Delphi...which has a very VB'ish interface).
Please don't think that this makes Delphi the same as VB. I have used both, and know that VB quickly runs out of steam when trying to do interesting stuff, whereas Delphi gets you 95% as far as C++ does.
However, if you want to, you can use Delphi like VB. Perhaps this is not a good thing - As someone who often reviews Delphi code from programming job applicants, it is sad to see how low the bar has become. The VB, Data bound, cut & paste, drag & drop programming style is very noticable. Some of these people barely know procedural programming, let alone OO.
> Any good VB programmer avoids the data bound controls like the plauge.
Ah, I was not aware of that. It makes sense though. I have long said the same about good Delphi programmers.
Unfortunately, the majority of VB code will use databound controls. Last time I used VB, there wasn't much else you *could* do. I could also add an opinion that any good VB programmer doesn't use VB, but that would just be stirring up trouble.
One of the design goals of Delphi was to do everything that VB does, and a depressing number of Delphi programs don't even venture beyond "VB for dummies".
I use VB all the time, for a very specific purpose, connecting a Windows GUI to data. I can easily get to any ODBC DB out there. VB excels (Microsoft Excel?) at easy data access. The newest version can end up looking more like Foxpro, or Access, if you want. You can connect to a database and drag and drop to create forms that link to the data. The language pretty much sucks, it not OO, no matter what the documentation says. If you try to do anything OO in it, you just get confused by it's poor implementation. (It really only has encapsulation.) I works great as a glue between C/C++ components, DBs and a GUI. It is kind of like the way you would use Perl on Unix. A lot of Perl code is real ugly, but if it gets the job done quicker, it's cool.
> Just because something is simple to use doesn't mean smart people shouldn't use it.
You forgot that smarter people use the right tool (language) for the right job.
Far too many programmers too easily blaspheme their favorite language in the name of the Holy War of Languages by preaching their language is the One True Way.
You aren't going to write a compiler or an OS in VB. Use the langauge(s) for what they were designed for. (Design and Evolution of C++ is a great place to start for what C++ IS and IS NOT good for.)
For my needs VB is absolutely useless, for others its perfect. (I'm a game developer, performance has the hight priority. Throwing an interface together and data mining has the lowest priority.)
The general tone of the discussion though (not just this thread) was that VB is to easy to use and therefore should be immediately dismissed as a "serious" programming language.
> You forgot that smarter people use the > right tool (language) for the right job.
No, no no. Really smart people avoid learning new stuff if they already know something that works. The question is, would it be easier to learn about a another language than to convince everyone else that it isn't worth knowing?
An interesting article at the vb-zone by the author of "Hardcore Visual Basic": http://www.vb-zone.com/upload/free/features/vbpj/1999/mckinney/mckinney1.asp
The March of Progress? C printf("%10.2f", x); C++ cout setw(10) setprecision(2) showpoint x; Java java.text.NumberFormat formatter= java.text.NumberFormat.getNumberInstance(); formatter.setMinimumFractionDigits(2); formatter.setMaximumFractionDigits(2); String s = formatter.format(x); for (int i = s.length(); i 10; i++) System.out.print(' '); System.out.print(s); Source: http://www.horstmann.com/ (Before you flame: I *like* Java, as does the author of this bit.)
Re:Why Not VB? (Score:0) by Anonymous Coward on Wednesday October 27, @11:34AM EST (#191)
I have programmed in programmed in vb, pascal, c, and c++. Of all the languages vb I liked the least. Vb aims to let the coder do worry about the core of there code and mostly forget about the gui.
If I wanted to make a program that my mother will use, then I would most likely use vb at the moment. But vb works on the assumption that the gui is good- because the programmer has no why of debugging that shit. I will admit that for the majority of the stuff seems stable, but I started to find odd memory leaks and other odd stuff towards the end of my vb programming tenure. Given the stuff seems to be compiler bugs but 99% of my programs do not need a gui.
The bottom line is that a lot of "programmers" do not know how or do not want to make there own gui. The vast majority of programs would/do work as text programs. I just think that everyone and there dog can program to some extent and the extent they do not know they look to be automated.
Whilst a lot would appear to depend on the size of the survey, this result isn't particularly suprising. VB has a (relatively) simple to use UI builder which gives immediate results. The closest thing to it is Delphi (why didn't that show up in the results?). Java on the other hand has several UI builder offerings, but nothing really sticks out as being as friendly as VB. The really sad thing is that programmers carry on programming in the language that they start in ... which means that we'll have a lot of Java written in VB ;-)
Fortunately, a lot of educational establishments start people out in Java now :)
Why VB,... (Score:0) by Anonymous Coward on Wednesday October 27, @07:59AM EST (#38)
Why do so many use Micros~1 VB? Because it makes sense to use (and learn) a current, well supported product.
I'm still maintaining a DOS product, written in Professional Pascal, linked using PLink and it depends on old Netware function calls to Novell servers. Data is via Btrieve, of all things.
Today I've linked a new version together and it works on some machines here, and not on others. How the **&^"%£$&! do I figure out what's gone wrong?!! I wish I was working with something where I could get some help!
On the other hand, if your software aborts because of an MS bug there's ^%"$£ all you can do about it either.
Aren't computers wonderful?!
Oh, and don't spout the Linux argument at me because we've ZERO chance of persuading all our hundreds of clients to abandon Windows, Office etc just for our sake.
You don't have a very good chance of getting all of your clients to ditch windows in order to switch to Linux. Your probably right. Even if the alternative is better, they won't do it... They, like so many people are affraid of change. But there is something you can do! PERL! Ditch your old dos sessions and switch to perl. Setup a MySQL engine and apache+mod_perl at each client site and rewrite your app in pure perl... Don't even use the apache api, just straight cgi perl with apache::register... It will be smooth, fast, and stable! What are your waiting for? You should be hacking out some perl code right now! ;) Later - and good Luck
In some sense most "programmers" are pretty ignorent when it comes to programming languages. They might know a small handfull, all of the same basic paradigm (procedural, or perhaphs OO). The problem with shallow but wide languages like Perl and VB is that they make it extremely easy to solve the problem %80, but getting the last %20 is almost impossible. Emperically, applications in such languages are always full of bugs and hard to extend and maintain.
Contrast this with declarative languages that emphasizes clear and clean definition. Although it might take a little to learn and a little longer to program (often not), the result is always much more robust and maintainable.
/Tommy PS: You want examples? Ok, for example Haskell, ML, Mercury, etc.
Somewhat off topic, but here goes anyway. Haskell? ML?? You've gotta be kidding. These aren't programming languages, they're academic toys. Very nice academic toys, I've had many hours of fun playing with them, but when it comes to writing code that'll needs to be extended, they're a total nightmare. Demanding the entire program be written before the horrible process of bashing your head off the type system does not make for programs that can be extended, improved or even just maintained. Me? I enjoy writing in Java, especially as I write non-GUI code that works across networks. Network bandwidth is low enough for the speed of the program to be mostly irrelevent. You do have to jump though some hoops to make the same code work on different JVMs, and yeah, that's real annoying. But a few more iterations on the spec should solve that. The language will conform to programmer expectations eventually, but it needs more code and more programmers before enough of a consensus can be built. I'm waiting, and trying to take part in that process.
Despite Java's growing popularity, many big businesses just aren't ready to use it for their most important applications, the study said. For instance, business software developers still primarily reach for tried-and-tested tools, such as Microsoft's Visual Basic, along with C and C++ for building business applications, according to the study by Zona Research.
The survey found that 35 percent of programmers use Visual Basic as their preferred language for writing business software, while 20 percent picked C and C++. Java ranked third with 9 percent in the third quarter of 1999, up from 5 percent six months ago.
The question is how to interpret the reoccurring word "business" in this quote, does it mean:
business in the larger sense (which would make this study more significant as virtually all software is written to satisfy the needs of some business)
business in the traditional sense (financial, spreadsheet, database - as in "I've just been to college and I got a business degree")
I suspect it is the latter, and if it is - I'd rather have my language of choice not show up first on that list. In general, I have found that closer an application is to money (manipulating it, tabulating it, etc.) the less fun it will be to work on and write. Would you rather write software to calculate mortgage payments or manipulate/view objects in 3d?
I believe the type of software most "real programmers" enjoy writing is the type of software that poses enticing and possibly difficult problems to be solved, programs that are heavy on the mental stimulation aspect. The problem is, the programs that are most highly in demand are the run-of-the-mill, let's-crank-it-out business applications - after all it wasn't that long ago that COBOL was listed as the language having the largest number of active lines of code (it may very well still be true today).
It is possible that the study is really asking: "When you don't want to bother actually having to get too much into the computer science side of things and just want to bang out an app as rapidly as possible, which language do you use?". If this is an equivalent question to the one they are asking the results are hardly surprising. just my tan(M_PI / 4) + exp(i * M_PI / 2) cents ...
Java (Score:4, Interesting) by Hard_Code on Wednesday October 27, @08:04AM EST (#45) (User Info)
We use Java here in the academic environment /extensively/. I work for the IT department of a large university (Cornell, 30,000 people), and our distributed infrastructure is being developed primarily with CORBA and Java, as are the new apps we're kicking out. Because of changing client-side API, specs, implementations, Java has been so far, a boon on the server side, but I think it's alive and kicking on the client too. JDK 1.3 is going to make it even better, with the incorporated HotSpot engine, which I've already seen to speed up client-side apps. I haven't seen the poll, but it's scary to think that many people have chosen Visual Basic as their favorite. I can understand if they are forced to use it...but personal favorite? Was it just MS lackeys and novice kiddies who think VB is the coolest thing?
I haven't seen the poll, but it's scary to think that many people have chosen Visual Basic as their favorite.
I don't think this is actually the case - the CNet item seems to state that the report was on the ubiquity of usage of programming languages rather than how well-liked they are by the developers who have to use them. Hence the preponderance of VB.
Actually the CNet report isn't really interested in that at all, it's just another poor piece of Java-bashing journalism[1]. I don't know if the Zona study itself takes this line too[2].
Actually I think Java comes out of the report pretty damned well given its age. But I'd be interested to know how well the other languages fared, esp. Perl, Python and the like.
[1] Not that I especially like Java personally. Well, the language is nice, but the standard libraries really bug my balls.
[2] (Who are Zona Research, anyway? Is there any good reason we couldn't set up a bogus market research company and forward studies to the media made up entirely of our own opinions?)
-- This comment was brought to you by And Clover. (Sorry.)
Re:Java (Score:0) by Anonymous Coward on Wednesday October 27, @12:12PM EST (#204)
Wait until you get out in the "real world" and try to get a Java job. Sorry, but VB rules in the marketplace.
Re:Java (Score:1) by naarok on Thursday October 28, @05:16PM EST (#348) (User Info)
I'm in the real world (sad to say) and have been doing Java work for between two and three years now. I've worked at four different client sites and at those sites have seen one project being done in VB while the rest (at least two dozen) were a mix of Oracle Forms/C/Java/Newton Script. The marketplace I'm in doesn't view VB with a whole lot of respect and you wouldn't get a contract at any of my clients with VB skills.
Re:Java (Score:1) by renoX on Thursday October 28, @02:19AM EST (#331) (User Info)
> [] but I think it's alive and kicking on the > client too. JDK 1.3 is going to make it even > better, with the incorporated HotSpot engine, > which I've already seen to speed up client-side > apps.
I thought that the HotSpot thing could only accelerate Server-side Java ?
The JDK1.3 will be really nice, because it will suppress many important bugs (you wouldn't believe how buggy Java is now, especially on the client side).
With fewer bugs, may be increased speed (note that in the volano benchmark, the much touted HotSpot comes behind the IBM JVM, so it is not the magic bullet, but anything that can help increasing speed is welcome), Java may become usable on the client side with the JDK 1.3...
PS: If you have enough memory, on the client side, Java is a pig, it needs lots of memory just to do very simple GUI.
Re:Java (Score:2) by Hard_Code on Friday October 29, @08:38AM EST (#353) (User Info)
"I thought that the HotSpot thing could only accelerate Server-side Java?"
I will work on any Java, but it specializes in sniffing out and optimizing critical performance areas, "hot spots", so server side code, which does a lot of repetitive stuff will see the best increase. Unfortunately we don't run our server stuff on OSs with a production ready "Java 2" VM available, so we can't take advantage of it really. And the older JITs are notorious for screwing things up, so we disable JITting too.
"note that in the volano benchmark, the much touted HotSpot comes behind the IBM JVM, so it is not the magic bullet, but anything that can help increasing speed is welcome"
According to this report:
http://www.javalobby.org/features/jpr/
IBM's JVM was clearly the winner, but HotSpot was not far behind. Unfortunately, IBM can't possibly keep up with releases as fast as Sun can, so HotSpot will always be the fastest VM for the most current release (I figure). I don't know if IBM has a "Java 2" JVM out yet, but tge HotSpot engine in 1.3 looks pretty good.
Re:Java (Score:2) by Hard_Code on Friday October 29, @08:43AM EST (#354) (User Info)
I don't know what I was talking about, because that report doesn't even have a HotSpot benchmark on it. I'm pretty sure that HotSpot is only a bit behind IBM's VM, and probably getting much better. There were a ton of things they had left to implement after the 1.0 release of HotSpot.
Hm. Maybe *viruses*, or *macros* ... if writing macros for your MS-Office app counts, then I can indeed see why VB topped the poll. If every administrative assistant who writes a macro or two counts, then of course.
Assembler C C++ Python Pike Perl Tcl Java BASIC (VB fits into this catoegory too) Ada LISP (Scheme fits here, too) Erlang Prolog
Another thing that would be fun, is a poll about what language the /. citzens does NOT (like to) use... --The knowledge that you are an idiot, is what distinguishes you from one.
Not too many computer science people program in it, but it's still *very* popular in the scientific computing community. --Troy "My life's work has been to prompt others... and be forgotten." --Cyrano de Bergerac
Perhaps Java should be split into 1.1 and 1.2... just because I'm interesting in who is really developing Java 2 (certainly nobosy doing serious browser deployment as messing with the plug-in is a joke).
And Smalltalk - a great language still in use in some places. One of Java's founding languages?
Sorry for forgetting Pascal/Delphi. I really thought it was on my list...
With assembler I meant the assembly language of any architecture; i.e. low level languages. And I am very aware of that that language differs quite much between RISC and SISC architectures, end event between two RISC or SISC architectures...
First of all, everyone is suggesting his/her own special language. That's OK, but we need to cut the list down a bit. Perheaps group similar languages into one option.
Yes, BASIC is a bit different from VB; especially if you mean ABC Basic or COMMODORE BASIC...
But we can not have a poll with one hundred options. Or perheaps we can, Rob?
If we are going to have a short list, I suggest joining languages with the same programming paradigm/sub paradigm. Such a list may perheaps look something like this (Please don't kill me, just comment on it, if you feel something is _very_ wrong):
1) Low level (The machine language of your favourite machine, C)
2) Ada descendant (Ada, Pascal, etc. To be really evil, I place BASIC here too, even though it does not belong here...)
6) Stack oriented languages (PostScript (Yes it is a programming language, or at least it is Turing Complete...), Forth)
7) Other
And this list is anyhow too long...
Second, I realize that there is no reason for this poll; each of these language categories has its application area. The important thing is which language inside each group you select, not which group, because that depends more on what you are going to write than on your personal preferences.
--The knowledge that you are an idiot, is what distinguishes you from one.
"But we can not have a poll with one hundred options. Or perheaps we can, Rob? "
Not a tradional one selection poll I presume! lol
"Second, I realize that there is no reason for this poll; each of these language categories has its application area. The important thing is which language inside each group you select, not which group, because that depends more on what you are going to write than on your personal preferences. "
We've already bombard with biased polls from Inprise/Borland and Zona Research, I think that it would be interesting to see the biases of all these opionated /.ers!
Oh yes it is, though, _Common_ LISP does provide imperative structures. But Common LISP is just a big cludge. It's not even a one-cell-LISP. --The knowledge that you are an idiot, is what distinguishes you from one.
I remember a 'PS' from one of slashdot readers, saying "Microsoft just lowered the standards" for programming.
How true it is. VB Programmers churned out by half baked organizations have enough skills do build a simple ODBC based VB app as shown in the Idiots guide. Thats it. Most of these "programmers " do not have any understanding of complex data structures or OS related issues. I am generalizing. I know a lot of VB programmers out there who do complex stuff, but they all have a decent background in a more low level language. C/C++ and Java are used for enterprise development. Yeah GM does VB so do a lot of other organizations. Then why the hell is CORBA/Java liked by so many developers. Platform independence. To top it all have you looked at VB Error messages, "Path not found" - So what do you do - find a path ! VB is good for small operations. Yeah with good programmers you can scale applications, but my advice dont. Try C++ or Java. Try a class library. Stop coding on the fly and do some analysis and design. If you want your apps to live beyond two years, stop using VB.
This may be obvious, but some people on this board don't seem to get it.
There are two types of programmers.
Your typical /. reader is in a different category from most of the programmers working for big corporations. Don't sneer down at them too much. Not everybody can be a genius. They fulfill some necessary functions, and you'd be bored to tears if you had to do their work.
This is not new. Microsoft didn't lower the standards. Remember COBOL? VB fills the ecological niche left empty when COBOL didn't catch on among PC programmers. (Let's count our blessings BTW.) Your typical VB programmer has the same skill level as your typical COBOL programmer.
If you look at the number of people in "business" computing who are not paid to be full time programmers, yet who can assemble a database-oriented "Application" from parts with Visual Basic and some ActiveX controls, you're stretching the definition of programmer. How many people have "Software Developer" or equivalent on their business card and yet only know Visual basic? I hope that number is somehwat lower. I hope that it's not the language of choice for the average B.Sc. Computer Science graduate. I'm often reminded of an old axiom in computer science: When all you have is a hammer, everything looks like a nail. In other words, the surveyor started out to find the answer to the question they already knew: Does Visual Basic meet the needs of the people who use it? Yes. he/she/they surveyed exactly the right kind of people to find out if Visual Basic was still relevant to the small custom database oriented application building thing. My other problem with this is that a sample size of 150 people is laughable when they pretend they are answering the question "Is Java a failure?". Hmm. Does Java have a target niche now? Yes. So why not go and look at it's penetration in that niche. It's not news that Java hasn't replaced every other language for every purpose. Neither has PERL, C, C++ or Visual Basic. Welcome to reality. I'd like to know what the over 3,000,000,000 people who spend all or some of their time developing software think. I'd like that survey broken down according to whether or not programming is their primary job function, and ask them if their choice is dictated by job description or the "shop" you work at, or if you are off in a corner like embedded systems, etc. The number of languages that people say they know and have written software with would be interesting as well. Some interesting statistics could be calculated. For example, if 50% of people who know both Delphi and Visual Basic still choose Visual Basic for most projects, I think Inprise/Borland would sit up and take note of it.
A more interesting survey would have included a trawl of the universities to find out what languages they're using. Although no one in business now seems to be using Fortran (apart from in legacy systems), many maths departments code almost exclusively in F77: everyone understands it, and it has none of those new-fangled pointer things to slow down your code. As it's fast and 'easily' parallelized, maybe we're about to see a rennaisance in Fortran coding for Beowolf and SMP? It's a shame the GNU project seems to be in limbo.
Bloomberg has the bulk of its system written in Fortran. Especially, anything that has to do with their terminals and proprietary databases. their web site
When they did this survey, did they look at the quality of the programmers and their projects?
Are the VB programs generally quick and dirty applications written for a demo or proof of concept? Are the people who are doing these VB not really programmers, but maybe a QA person or a technician writting a quick application that they need?
The reason VB came out on top is because of all of the legacy crap they cranked out before the notion of Internet development and thin client started to become a viable option. They need a certain amount of people around to just maintain that code, so I'm sure many of them are just using the skills of the people they happen to have.
C++ is a language I have very rarely seen used in the realm of internal business applications. It might be used to interface with some component that only has C API's but other than that its complexity makes it too expensive to work with.
Java finished 3rd only because it is new and because a lot of people still don't realize that you can write wonderful thin client applications with it on the back end. I have yet to see an applet or client application that is actually useful and performs reasonably. I've worked in both Perl and Java, and to be honest, I prefer working with Java (sorry folks!).
One thing I do find amusing though is why didn't COBOL show up on the list? Most big companies pretty much live on mounds of legacy cobol code.
--- What would happen if there were no hypothetical situations?
The poll's driven by legacy code, sure. That's a lagging indicator. If they want a leading indicator, look at programming language book sales.
The fact is, C/C++ is used quite a bit in large corporations. VB is a very accessible, easy to learn language and that's why you see it so much in corporate America. But I work for a quite large Internet ecommerce site, and Java has exploded in use here in the last 4 months. Most of our legacy code is C/C++ and Perl, but almost all new development is in Java. We may eventually rewrite the C/Perl stuff, or we may just use it till it dies.
I realize this is probably a hopeless task here on slashdot, but I wish folks would lighten up on the VB-bashing.
Vb is like any other computer software/hardware tool. It's just a tool. There are good VB programmers, and there are bad ones.
VB is used in corporate settings a lot because it integrates well with other microsoft products they probably have (or non-microsoft products like crystal reports, visio, whatever). It is trivial in VB, for instance, to OLE embed existing excel sheets users already use and populate and strip data from it instead of rewriting the same interface. (can you type OLE1.CreateLink c:\Docs\Excel.xls, OLE1.Refresh?)
It can be written so that it is VERY quick to develop and VERY fast. If you class properly, type your variables & scope correctly, use a proper database backend (NOT access) and don't use bound controls, it can approach C++ in execution speed with FAR lower devopment time. Generally, on these types of corporate data matinenance applications, it is not application execution speed that is the limiting factor, but network bandwidth and database access. The speed you would gain from taking a well-written VB app of this type in C++ would be miniscule. Note the well-written part. You could redo a poorly written VB app in C and speed it up, could so could a proper re-write in VB! Granted, it is not for every project, but there is a reason it is used in lots of fortune 500 companies (Like GM). Because it is the proper tool for the job.
--a PROUD vb programmer "Nostalgia isn't what it used to be"
Don't get me wrong, I think it's interesting and it generates a lot of interesting comments, but it's a bunch of hogwash. This survey doesn't address the needs of the companies who are employing these developers. It doesn't address the platforms they are developing for...it doesn't discuss if the people are working on long term or short term projects...etc...
I can drive to Idaho and conduct a survey on what kind of vehicle you drive and the survey will show something different if I go to Los Angeles and perform the same survey. Meaningless.
Businesses are looking to fill specific needs. They need applications that are developed for those needs. The tools used to develop those applications will be based upon what the application does... quick with a gui for Windows...yeah..VB.. that isn't a statement on the quality of the language..or the quality of the programmer... it's a statement on the needs of your typical "under the gun" business of the 90's.
Now...back to my latest obbsession (I don't care if it sucks :) Perl...
I know most Slashdot readers, don't consider VB a "real" programming language, but its popularity poses real problems for the growth of Linux. A huge amount of critical apps (even if they are not "real" apps, but only "business" apps) are written in VB. Until this changes, desktop competiveness (never mind dominance) for Linux is a pipe-dream. I remember hearing there was a group that wanted to port VB to Linux. If you ask me, this would be one of the best ways to popularize linux.
A visual development language for Win32. Uses Object Pascal for the core language. Native code compiler. It has the best IDE I've ever used, bar none. I've used a lot. Think of C++ power, VB-style visual development and an elegant programming language rolled into one, and you are somewhere close.
It supports DirectX, ActiveX, COM, CORBA, and virtually every bit of drag-and-drop database functionality you can think of. Special emphasis on internet functionality. Huge number of solid third-party components, though you can craft your own with the minimum of effort. I've even used it to write web server applications (ISAPI and CGI), for which there is a wizard included.
You don't have to touch the monstrosity that is MFC, because you get a great object-oriented component library (Borland's VCL). Delphi thrashes C/C++ on compilation time and matches both for execution speed. And yes, there is an inline assembler for all the keen hackers out there.
That any programmer worth their salt is voting for VB when Delphi is around totally baffles me. Seriously, I think that most people don't even realise that this tool exists.
Apologies for the language rant - but I really felt the need to shout about another fantastic bit of software largely sidelined by the Microsoft Monopoly Marketing Machine.
When Delphi finally arrives for Linux, I for one will be cheering very loudly indeed.....
Object Pascal for the core language ... an elegant programming language
I'm sorry but I can't agree on this. Object Pascal is far from being an elegant language. It suffers from a buttload of unuseful syntactic sugar, and very obviously alot of features have been put in to keep people used to C++ idioms happy. Unfortunately they also introduced the same flaws as C++ has.
Object Pascal can only be called an elegant programming language if you happen to think C++ is an elegant programming language. Which I don't. Both languages suffer from the fact that they attempt to uphold compatibility to their ancestors (C and Pascal) while at the same time serve people with OO paradigm. It all ends up being real messy, IMHO,
Not commenting on Delphi and the IDE in general, just the language underneath.
>I'm sorry but I can't agree on this. Object Pascal is far from being an elegant language.
I'm sorry but I can't agree on this.
> . It suffers from a buttload of unuseful syntactic sugar
eh? I find it very readable.
> very obviously alot of features have been put in to keep people used to C++ idioms happy
If you mean things like virtual methods & function overloading, naah, they are put in because they are useful.
> Unfortunately they also introduced the same flaws as C++ has.
Hm. They purposefully left out C++ style multiple inheritence and templates as these were regarded as not worth the complexity. C++ Operator overloading - now there is unuseful syntactic sugar. Guess what, Delphi doesn't do it.
I honestly don't know what flaws you are refering to, unless you are one of them wussy VB programmers that regards real OO as a flaw because it's "too hard"
> Object Pascal can only be called an elegant programming language if you happen to think C++ is an elegant programming language
I beg to differ. I think C++ code is ugly write-only typrographic soup, and Delphi code is elegant.
Good for you :) I'm sure C++ programmers feel the same way of their language as well. And Cobol programmers etc...
After you've stared at it long enough, most things start to look like readable. It's just a matter of how long do you want to stare before you start understanding.
But back to the point. I find syntactic sugar like stdcall, published, the whole property MyData: Integer read GetData write SetData; thingy, {$R BUTTONS.RES} compiler commands, ANSIChar ANSIString WideChar WideString @MyRecord ^MyRecord, PChar vs String, far external etc etc... All the syntax makes it harder for me to learn and understand the language, plus it makes the syntax look too busy to my liking. Are all these different words really necessary?
Much like I feel about C++.
The fundamental flaw I think both C++ and Object Pascal have is the fact that they try to be both procedural and object oriented at once. It doesn't work. Either be procedural (C = elegant) or do OO (SmallTalk, Java = elegant). Don't do the hybrid. It doesn't work. In the end, procedural programming always breaks the OO model. If you need both ways, just use two different languages, the ones that excel in their respective fields.
unless you are one of them wussy VB programmers that regards real OO as a flaw because it's "too hard"
Ah, so quick to jump to conclusions. I've never programmed in VB. Maybe Delphi is better when compared to that (VB is the closest thing to Delphi after all, or is it the other way around).
As for OO, I'm for it all the way. It takes a serious effort to change your way of thinking from procedural to OO (I'd say easily 18 months, even if you practice OOP almost daily), but I don't think OO is particularly hard, nor do I slam Object Pascal because of that. I just think there are far more elegant languages for doing OOP than Object Pascal.
Good points on Object Pascal not including templates or multiple inheritance though. I agree on those somewhat. Although I find generic programming quite useful, just the implementation in C++ (templates) is messy. Don't know my Delphi enough to tell how generic programming is achieved using Object Pascal. If at all?
I invoke Godwin's law and mention Lisp on a thread about programming languages...
Seriously LISP is living (or maybe dying...) proof that multiparadigm programming works. It's the static languages that are all messed up. LISP was designed to be an evolving language. It has incorporated functional programming, logic programming, more dynamic OO than Java and imperative programming in one language and very cleanly compared to, for instance, C++. Go ahead, just invent a new paradigm and LISP will assimilate it as well. Resistance is futile.
> I'm sure C++ programmers feel the same way of their language as well.
Um, fine but IMHO the design of OP pays a lot more attention to source code readability than the design of C++ does.
> Are all these different words really necessary?
Hm. I always thought that "syntactic sugar" was something that looked nice and read well, but actually didn't contribute any functionality. For E.g. in C++ MyObject1 += MyObject2; (with the += operator overloaded to do something obscure) is syntatically no different from MyObject1.AddValuesFromAnotherObject (MyObject2); It just looks cuter.
Many of the constructs that you describe, (stdcall, {$R BUTTONS.RES} compiler commands, WideChar WideString PChar vs String, far external ) are quite the opposite: They are ugly and everyone knows it, but they are neccesary to get the program to work with the outside OS of Windows. They are not needed internally. You should see the syntax that was added to get Delphi to do COM!
For the property declaration syntax, Property MyPropertyName: TMyType read MyGettorMethod write MySettorMethod; IMHO it is a thing of beauty and a joy forever. Simple, unambiguous, flexible and readable. If you want the source code to be terse as well - sorry, OP consistently compromises terseness in favour of those other goals. Unlike C. But then maybe that was a reasonable consideration back in 197x when C was thought up. It sure isn't now due to large hard drives & code generation & helper tools.
> Maybe Delphi is better when compared to that (VB is the closest thing to Delphi after all, or is it the other way around).
Ouch. But let's see - VB came first, Delphi did it better, and with a real language under the hood.
> takes a serious effort to change your way of thinking from procedural to OO (I'd say easily 18 months, even if you practice OOP almost daily),
From experience that sounds about right.
> Don't know my Delphi enough to tell how generic programming is achieved using Object Pascal. If at all?
Hm, some can be achieved with clever use of objects (ie TObject is the ancestor of all object classes, there are list/queue etc. classes that deal with it.) However it is kinda lacking.
The original point hat I was on about is this: I have reviewed code and seen the same procedure attached to 10 different forms, when it could just as easily been written once as a free-standing function in it's own code unit. So many "programmers" (who probably learned their tricks on VB) have barely come to grips with procedural programming, let alone OO. You may think that this is the exception, but after many code reviews I can assure you that it is not. VB is IMHO to blame for a lot of this. ribbit StrawberryFrog
IMHO the design of OP pays a lot more attention to source code readability than the design of C++ does.
Ok, I tend to agree with this somewhat. I just don't think OP does it enough. Too much of the burden of its Pascal roots. IMHO.
For the property declaration syntax, Property MyPropertyName: TMyType read MyGettorMethod write MySettorMethod; IMHO it is a thing of beauty and a joy forever.
Matter of personal taste, for sure. But earlier in your message you defined "syntactic sugar" as "something that looked nice and read well, but actually didn't contribute any functionality. [...] It just looks cuter.".
Now if I've already designed the field for my object, and made the necessary accessors to modify it, what added functionality does the property declaration syntax offer? Isn't this just syntactic sugar? It looks cute...
It looks cute, but for sure, to most people having their first encounters with OP, it will cause the reaction of "oh sh*t, what the heck is going on here?!". And after that starts the frantic searching of the OP manual.
An elegant language tries to avoid these unnecessary searches to the manual as much as possible. IMHO.
I have reviewed code and seen the same procedure attached to 10 different forms, when it could just as easily been written once as a free-standing function in it's own code unit. So many "programmers" (who probably learned their tricks on VB) have barely come to grips with procedural programming, let alone OO. You may think that this is the exception, but after many code reviews I can assure you that it is not. VB is IMHO to blame for a lot of this.
I've not only seen code like what you describe, I have to live with it almost daily. And it was written in Delphi. Now I do know that the original author wasn't just a disgruntled user of VB, forced to the Delphi environment, but was using Delphi by his own choice, and liking it.
It didn't make his code very nice to read or easy to maintain though.
So I don't tend to just blame VB on this. I tend to blame any environment that lets you get away with drag and drop without ever paying attention to the design of your application. I blame the paradigm of user interface centered design. And to me, it was quite revealing to see that Delphi does not ease people's way into the OO world, or require they make that leap. It doesn't even require you to be very good at the ole procedural programming.
The use of OP in Delphi doesn't automatically lead to maintainable code, at least when used by your average enterprise programmer. And as long as people can get away without actually learning to program, I don't see this changing. And I blame Delphi for that as much as VB (well, I don't blame VB, cause I'm not forced to deal with that, but the people on the other side of the office do...)
Now if I've already designed the field for my object, and made the necessary accessors to modify it, what added functionality does the property declaration syntax offer? Isn't this just syntactic sugar? It looks cute...
Well, yes but... The property inspector for visual components wouldn't work without it. That sugar is pretty sweet! The principle here (in the design of Delphi 1 as a VB competitor) was that Delphi had to do what VB could do (ie visual inspection of object properties) and also do it without any "magic", with the mechanism there for all to see and use.
When I saw the Javabeans thing, where a pair of methods called Get_XYZ and Set_XYZ are automatically assumed to form a property called XYX, my immediate reaction was that they had looked at Delphi properties, but not quite gotten it. The programmer should specify what the propery name is (does not have to match the name of the gettor & settor methods, same getteor and settor methods can be used in more than one propery if you want) and should decide to surface read or write independantly, irrespective of if there are private/protected methods that can do that internally.
I've not only seen code like what you describe, I have to live with it almost daily. My Sypathies.
Operator overloading - unuseful? You're joking, right? I don't know or care about Delphi, but let's look at Java. Which makes more sense and looks better: if (string1 == string2)...(C++) or if (string1.equalsNoCase(string2)).. A language without at least some operator overloading is stupid. As for multiple inheritance - what a load of crap. How in Gods Earth (again - looking at Java) can you implement multiple interfaces _and_ some of the pre-coded methods of multiple classes wihtout it? Multiple inheritance is useful in limited cases - it should be in the language. Templates.. A must have. Another Java weakness. I like Java - but it's not perfect.
I honestly don't know what flaws you are refering to, unless you are one of them wussy VB programmers that regards real OO as a flaw because it's "too hard"
As an official OOP hater I resent this "too hard" comment.
OO is harder than procedural, but it is also nearly useless in many domains. It is complicating software, languages, and training in exchange for minimal benefits. Perhaps in large RAM-centric scientific or modeling applications it shines, but I have found OO to add nothing but complexity, headaches, and mind-numbing buzzwords to regular business apps.
It seems like OO is all geared up to solve "problems" that are not really problems. For example, the apps I work on expand at least as much in the operational dimension as they do in the sub-type dimension. OO tends to assume the type-wise orientation is better than operational-wise orientation, which I find to be bogus. (Some OOers try to remedy this OO weakness by adding "pattern" classes. These are often nothing more than bulky, silly middlemen classes that add nothing useful to software except satisfaction for anal-retentive OOP class protection purists.)
Inheritance is another look-good-on-paper-just-like-socialism OO concept that makes bigger messes than it solves. The real world does not expand or change in a hierarchical fashion. Businesses love to recombine features into unpredictable new arrangements that do not follow any clean hierarchy. OO books like to use animal species and shapes for inheritance examples, because most business examples would prove too inter-relational in growth and change patterns.
Finally, there is not one shred of scientific evidence outside of pro-OO organizations that proves that OO is superior for most applications. Even the hyper-promoted reuse of OO is being withdrawn as a benefit. Any remaining benefits are vaguely stated in a Zen-like tone or are perhaps personal preferences. (Software engineering is about modeling developers' minds and habits more than about modeling the real world, which OO does not do well either. Thus, OO may simply be a subjective personal preference.)
Much of the criticism that OO fans toss at procedural concepts are based on a bad specific language (like C), or a bad procedural experience that they were too uninformed about to solve. For example, I sometimes bump into OOers who claim that procedural/relational programming cannot factor as well as OOP. However, with a few language constructs included, it can indeed factor as well as OO. (My results are often ugly from a type-safety standpoint, but they factor.)
However, that amount of abstraction is often not a goal of most programming projects anyhow. It is widely accepted that building generic routines takes roughly 3 times longer than building per-application routines. Very few business will budget for this.
Part of the reason is that they know a new language or paradigm fad will pop up and eat away at their source base within a few years. I can't wait for this day. OO has been mucking up software and progress with useless mind-candy and abstraction toys for too long. It is time to leave the dOOrk ages behind.
That any programmer worth their salt is voting for VB when Delphi is around totally baffles me. Seriously, I think that most people don't even realise that this tool exists.
I used to be a big fan of Borland products, but I've been burned too many times. Too many products that were buggy and never fixed or just discontinued.
They also have the problem that the company has been struggling, changing direction and has lost too many of their best people.
If I commit to Delphi, what guarantee do I have that the product will exist and be actively supported in N years?
The real news is that java has almost doubled its use in the past 6 months! From 5 percent to 9 percent! I can't believe that they are spinning this as "Java is still in trouble" when it's growin at 400%/year!
Remember the persian chessboard problem*? Rate of growth is at least as important as amount.
* For the proverb impaired, a king promised a young man a reward of his choosing. The young man asked that the king take a chess board, put one grain of wheat on the first square, 2 on the second, 4 on the third, and so forth. The thing is that this ends up being:
2^64 + 2^63 + 2^62 ... + 2 = a whole lot of grain.
As anyone with an alpha can tell you, 2^64 is a huge number. I heard somewhere that this number was quite a bit more than the annual grain yield for the whole world for any given century.
-- Sometimes, the best applause lies in knowing you have offended a fool. -- Anonymous
Re:The real news. (Score:0) by Anonymous Coward on Wednesday October 27, @11:06AM EST (#174)
2^64 + 2^63 + 2^62 ... + 2 = a whole lot of grain.
Uhm actually it is 2^0 (=1) + 2^1 (=2) +...+2^63(last field), assuming ^ means power. This adds to 2^64-1 (for the math impaired, think about it) teske
A bit off topic, but I thought the proverb impaired might enjoy the whole story.
The proverb is the legend of the creation of chess. The King in question was about to fight a war with his neighbor and asked his Wasir (counsellor) to come up with a means of avoiding an actual battle. The Wasir invented the game of chess and had the two kings play a game instead of fighting. The game was a draw which made the two kings realize it was a bad idea to fight each other for real as they were so evenly matched as tacticians and the war was thus averted.
In gratitude, the first king then asked the Wasir to choose a reward and he chose the grain reward described in the original post.
It is what we use for large projects and it screams on Linux...what more could one want? Linux... The inevitable defeat of inferior companies like Microsoft is living proof that the laws of natural selection still are effective
I've seen at least one statistic from Microsoft claiming over 60% of all new software is written in Visual Basic. In that same presentation, they claimed that only 20% of all software for the PC is written for the shrink wrapped market. This is the point of the whole "enterprise" buzz that started a few years ago. Traditional C-style applications are in the minority compared to in-house corporate web tools, custome databases, time trackers, etc.
I followed the link to the article, but couldn't find the actual results, or proper description of the sample population, or proper description of how the survey was carried out, or a statement of its accuracy (e.g. +/- 2.5%). Therefore I think it shouldn't be take too seriously - it doesn't seen very scientific or statistically accurate to me (of course statistics can be massaged/manipulated to make anything seem true). I tried looking on Zona Research's web site, but that's a pretty closed place.
35% VB + 20% C/C++ + 9% Java = 64%. What about the other 36%???? And what is this mixing of C and C++ about? That's what ignorant HR departments do when they post job descriptions!
In 1997 when another language poll was posted on /. the results were highly in favor of Java. In 1997 Java was going to save the world. Corel had ported WordPerfect to Java. Web browsers were being written in Java. Well now it looks like they're emphasizing Visual Basic. Basic seems to have taken over the world in 1999. As for C++, since when did efficiency in the workplace outweigh credentials and business suits?
The problem here is IS management. They are increasingly clueless and are easy prey for vendors who claim that the difficult and complex task of systems development can easily be solved by mediocre developers with a souped-up IDE. Ask the average "VB guy" if they know what a finite state machine or Statechart is. Or if they know how to elicit data requirements from users and end up with a normalized ERD. Usually, I get some guy who can make an entry in a grid become deleted by dragging the entry to a trash can and have a flame pop out of the top of the can followed by a puff of smoke. But when I tell him that the file I'm sending him is sorted and that he should use a binary search to quickly look things up in it, he tells me VB can't do that. Oh well...
The guy your describing is not an average VB programmer Seems to be more some kid out of high school who has decided he's a programmer cause he can drop a command button and have it do something The average VB programmer that I know can tell you, in detail, everything you just talked about. Most of these VB programmers are students in college or just graduated and either took a LOT of courses in VB or started in c++ and took a lot of vb after that. Most had database courses (where we learn about data req's as a by product of databases) So overall VB has a wide range of programmers Kids in high school who have no clue about smooth clean code but just want to do something cool and deem themselves programmers (same would probably exist with any language but not to the level of VB) And people that know what they are doing can develop fast clean programs and do it well
Every human being who has taken just a few lessons in probability would know that a poll with no more than 150 participants is very likely to give an incorrect result. The probability that Zona simply picked more people that favors C/C++ that in the real world is simply far too big when the number of participants is this low.
I am not a business programmer. I live and will live on campus for a while. My colleagues, my friends, and even I when I decide that it's time to program, only use Matlab. Does that count as a language?
When for speed matters we don't use Matlab or Octave, we go to C. One guy uses Fortran and another likes C++, but they are exceptions. And this is valid for any kind of platform, from win95, to Win NT, to Linux, to Solaris, to IRIX, to HP-UX. I personaly use Matlab for everything, you can even build a GUI for your input parameteres now. Easy, powerful and almost like C.
I thought BASIC was the ZX Spectrum language where most of us started to play... Is it now aitec?
Interns and co-op students are constantly forced to use VB for all kinds of tasks, including tasks that are incredibly tedious using VB. Visual Basic has become the tools of choice for many professions (including engineering, finance, etc..) A big problem many businesses face is the fact that students with VB training are a dime a dozen. You'll be able to find C\C++ programmers that can code in VB quickly. However, finding people that can go the other way is more difficult. The cost of employing/training people to become proficient in C/C++/Java is greatly outweighted by the result in many cases.
The learning curve on Java is a BITCH. Yeah, yeah, I know you're thinking "Bunk! Java's as easy as they come!"
Bull. Points of fact: 1) Java keeps changing. If they'd get down to standards already more people would use it. Look at Swing for crying out loud.. 1.1 to 1.2 was a whole radical annoying thing.. 2) Java, being wholly OO, is a lot harder to learn for the person that has programmed C for twenty years. C is used WAY more out there in the real world than C++.. I learned the OO way. I have no problems. C++ is my language of choice, but everyone I work with just can't grasp it easily. It takes them a while. Java? Forget it, they don't even try! They don't try because: 3) It's a slow, clunky, badly designed, interpreted, overrated, security-overconcious, bug-riden piece of shit.
I have a program that I would consider to be something fairly easy to do, but it's in Java, thereby becoming extremely difficult. It has to be on the web, and that means java. CGI just ain't gonna work for this one. ActiveX can blow me.
The program basically connects to a Database over the network, and lets a user modify it. The mapping of inputs to tables is fairly one to one, so basically it's just a front end to the DB. Easy right? Hardly...
JDBC works maybe 75% of the time. Often it fails for no reason... There's no standards in how JDBC connects across a network.. It all depends on the server you're running... Come to think of it, there's no standards on Java between the two major browsers (both of which must work, yes, bloody m$). That means the simplest way is to use the Sun Java Plugin, adding one more thing that users must do for this POS to work right.. All the servers that support JDBC (This is on NT, not by my choice, mind) seem to suck terribly. Most of them crash a lot, few will run as a service, none are open-source and/or freeware...
Bloody annoying, that's what java is. You can't get around to programming any damn thing because you're too busy finding any way to get the stuff to make it work in the first place..
Sorry, I had to vent a bit.... --- "Never underestimate the power of human stupidity." - Lazarus Long
Having profitably worked exclusively in Java since early 1997, I beg to differ with your impression of it.
First of all, Java comprises a whole spectrum of technologies, from a processor specification to a programming language. We shipped products written for the Java processor specification largely written in Java assembler, for example. The project is very ambitious, and thus results in some of the problems you see with Java technologies. When people change their focus from "language" to "platform" then Java makes much more sense. We ship the same code running without changes on anything from Palm V to HP/UX mainframes.
(As a small aside, Microsoft's marketing continually hammers the "Java is a language" mantra among corporate types in an effort to lock them in NT/Visual tools/DCOM/etc. I've been to many of those meetings at several companies worldwide, playing Java's advocate. I wouldn't be surprised if this study was paid by Microsoft to position Java at the same level as VB with some disadvantages, not as an alternative platform to Windows)
2) Java, being wholly OO, is a lot harder to learn for the person that has programmed C for twenty years.
Java is far from being "wholly OO". The language suffers from the same problems that C++ has in the OO department, just far less. Both Java and C++ are hybrid programming languages; the inclusion of stoopid primitive types in high-level object definitions is a no-no. Granted, Java is more OO than C++ because it enforces the paradigm far better, but it's far from "wholly OO." You should use Smalltalk for wholly OO.
3) It's a slow, clunky, badly designed, interpreted, overrated, security-conscious, bug-ridden piece of shit.
One at a time. Slow: Yes, in general is slower than executable code but not slower than PERL once the JVM and needed classes are in memory. I'll be happy to tell you how to improve performance. Clunky: C++ is a lot clunkier. At least Java enforces one programming paradigm (for the record I've written a C++ compiler and I programmed in C++ for many years, probably since before most of you even knew what C++ was). Badly designed: That's just flamebait. Interpreted: Hm... define interpreted. P-code running on a VM hardly qualifies as interpreted. Scripted languages are interpreted; Java is not such. Again, go to Java assembler if you don't believe this. Overrated: Er, I'd say overhyped. Security-conscious: At least there is a security model associated with the class library. C++ still doesn't have a standard class library (don't moan about STL; templates are a bandaid on poor design. C++ should've had a class library out of the gate. Dr. Stroustrup knew better), much less a security model associated with it. Bug-ridden: Depends on the implementation.
JDBC problems usually have to do with the database vendors, not with Java. Vendors must write the driver managers for JDBC, which only acts as a conduit for moving result sets between the Java address space and the database. If JDBC is failing for "no reason" then it's either your application or your driver manager, not JDBC itself. As for Java running on NT -- NT sucks, regardless of whether it runs Java, C++, C, or BASIC code! I'll be happy to assist in troubleshooting your Java application. Drop me a note.
Cheers!
E Unsolicited e-mail (spam) notice: http://cime.net/eugene/spamoff.html
The program basically connects to a Database over the network, and lets a user modify it. The mapping of inputs to tables is fairly one to one, so basically it's just a front end to the DB. Easy right? Hardly... i>
The funny thing is, I could whip this up with as a three-tier, pretty robust IIS, whatever databse you have (I mean, everything has an ODBC driver)and a VB-COM object in a few days.... oh, that's right, VB is a TOY language... GOOD LUCK ON THAT JAVA! Hope you get those JDBC drivers to work! "Nostalgia isn't what it used to be"
Looking over the comments here, I guess most Slashdotters figure that if you aren't coding Open Source projects, you aren't a programmer.
A clue, folks. This was a poll, which means that it measures quantity.
Corporate America employs programmers in truly astounding quantities. These folks are known in the trade as Applications Programmers. They crank out huge amounts of code following the formal specifications provided by the company's Applications Analysts.
These days, the language of choice for Applications programming is VB. It used to be COBOL. (Anyone remember COBOL?)
Applications Programmers are, by and large, a breed apart from Slashdotters. That doesn't mean that they don't exist.
That tools that could be used by a brain-dead monkey are better. Of course, 9 out of 10 MS developers are brain dead monkeys, too.
I've never been too impressed with visual development tools. They can be handy for laying out what your windows will look like, but so can a sheet of graph paper. And they tend to lead piss poor programmers into believing that they actually have enough talent to stay in programming. This in turn leads to good programmers having to come in 6 or 8 months into a project and redesign and rewrite everything from scratch. The Morale of this story being that it doesn't matter how good a programmer's tools are if he can't tell his ass end from his elbows.
Of course if you want to do Windows programming your choices are Visual something-or-other or deal with Microsoft's decade-old programming model. Scratch the surface and you'll find that significant portions of it are still 16 bit. How primative!
A sample of 150 developers? How could that possibly be representative? Furthermore, what are the 41% of developers doing who aren't writing C/C++, Java, or vb? Hmm? This is an example of journalists (remember the dumb kids in college, who said "eww...." when you mentioned your cs/math major?) reporting on a story that actually is based on facts of minor significance. Apparently, statistics and addition are a little too difficult, or too easy to overlook.
MOO is by far not a very featureful language in terms of library code. It has no native interface, it has no graphics libs, it doesn't even handle I/O very well. However, what it does have is a very consistent and sensible syntax using if/endif, for/endfor, while/endwhile, try/endtry, and a pretty-printer that lets others read your code in an indent style that's readable but doesn't force you to use it when entering the code (I wish python had figured that out). String and list slicing use identical syntax (hint hint perl), lists can be created and nested as literals and spliced with a single operator (another hint, perl. python, how about a splice operator?)
But what I love most about MOO is the flexibility. As an artifact of the way the MOO command parser was built, methods on objects can have aliases and wildcard endings. This is poor-man's pattern matching and meta-object protocol. Not as ultimately flexible as python (and perl if you really dig into the guts) but intuitive to grasp. You can call methods as a string expression, and it will search for the proper method, matching against aliases and wildcards. I've written some amazing funky dispatch tricks with this.
Any language can do this trick, python is pretty close to it and includes even more features than MOO (like multiple inheritance), and java has niftiness like anonymous classes (java has several scriptable variants now). But what really shines about MOO for me is that the write/run cycle is practically zero. I can have a MOO method in an editor window, make a change to it, and the change is there. I am hacking on a running system, there is no script to invoke, there is no explicit compile command (well there is, the core just hides it very well). I change a line of code, and the whole database of code has its behavior changed as intended (well, hopefully :)
MOO is ubiquitously persistent. When I create an object, there are no explicit semantics to "pickle" and "unpickle" it. It's just there, it's live, it's always there as long as the database is running.
Finally, add multi-user protection into the equation. Every persistent resource has an owner, including methods, and methods always run with the permissions of their creator, and that's on a per-activation basis. Call a method owned by someone else, it runs with its owner's permission. Only the superusers (wizards) can set the permissions otherwise. This means a trojan horse program isn't possible, because it cannot run with your permissions. It could call an improperly written method that that could mess you up, but it wouldn't have required you to run it in the first place. I am seeing much movement toward persistent object databases, but I have yet to see one that takes multi-user protection seriously I've seen Perl and Python both try it, but it's laughably light security. You write an execution monitor that can potentially be modified by code it's meant to monitor, and I don't think I have to tell you what that means to security.
Give me an industrial-strength language with a transparent write/compile/run cycle, a persistent DB, and bulletproof execute-as-owner permissions, and you've got a convert. Till then, I hack in "standalone" languages for work, but I'll stick with MOO for the joy of hacking it brings.
hmm used to do a lot of programming for MUDs. mostly LPC. And now it's also available as a standalone language, named Pike. Anyone have any experience with Pike?
//rdj Homophobes are just pissed cause they can't get laid. --Propagandhi
Now, it's been a long time since I took a statistics course, but I seem to remember that you would need many more participants to get a statistically valid result.
"Hey, I asked 3 people what their favorite color is. 66% said it was blue. Blue is the greatest color! Blue is much more popular than green!
If VB has one thing going for it, it is ease of use. Having hardly paid any attention in class for the last two years of my HS Computer Science class, I have been able to get by (with a 95% or so) mainly by reading the help files. Obviously, efficiency isn't a forte, but that doesn't seem to be important in North American culture (ie: SUVs, Windows, etc.)
As for Java, I can only speak for what I know, but it seems to be getting some attention at the university level. A local university teaches nothing but Java for 1st-year Computer Science students. Perhaps the exposure is gaining it popularity.
I can build an aircraft from aluminum or wood or composite plastics -- the underlying principles of flight don't change, only the context in which those rules are expressed. The art is not in knowing how to make a wing, it's in knowing that for this type of flight and this propulsion system, I need to use this structure and material.
Programming is (or should be) an act of engineering. A programming language is a material from which we shape a piece of software; knowing the form our programs will take gives us the insight to select the right programming language.
In the last year, I've been paid to write code in C, C++, Java, FORTRAN(!) and Visual BASIC. My current projects include a C-language network simulation and a Java-based server-side application. My personal preference is largely based on what I'm developing; there is no perfect programming language.
IMNSHO, Visual BASIC and Java suffer from the same problem: They are trying to be everything to every one. VB works well for quick business apps, although it's lack of serious structure can breed poor programming practices. Java is a fine tool for web applications and server-side processing, and could be better if Sun gets its head screwed on straight.
My language of preference for most things: C++, because of its inherent power and flexibility -- but Bjarne's creation has its limitations, too, and suffers from annoying complexity. As creations of the human mind, no programming language will be perfect.
Advice from a grizzled 25-year veteran: Learn the fundamentals of program design, object-oriented decomposition, and computer architecture. Try every programming language you can get your hands on. The best engineers are those that understand both design and materials; if you can analyze the problem, you have a far better shot at picking the right tool for the job.
I've used all three of the above languages as an independant consultant and for developing GUI apps, VB gets initial results incredibly fast. I've been able to churn out data collection apps with full interfaces including error checking in a matter of hours that look and feel just like MS apps (not that this is a Good Thing, but it's what people want and it's what they'll pay me for.
I've found, however, that when people need to get past the basic data goes in, gets stored in DB, or data is collected from equipment, gets stored in file, etc. that VB becomes a truly evil beast. Anything beyond basic operations has been hidden, tucked away, and completely obfuscated that it becomes extremely difficult to use. Add to that the inconsistencies that abound throughout the development environment and interfaces and all of a sudden the rapid development time you started with has blossomed and flowered into a serious long-term project. I've seen logic errors in VB along the lines of:
(a and b are fields from tables in a database object, same type, same properties)
if a = b then //always fails, regardless of values, weird error!
replaced in code with:
if b = a then //code works properly!!!
Bugs like that scare me. It's not something that makes sense. It was working with database objects, and it took me 3 hours to fix it (searching docs and various online sources of info). That was when I realised that you always need to be able to trust the language you are using, and to have some idea of what's going on behind the scenes. VB takes all of that away from you, and you really have no idea of what's happening underneath. I'll take C++ with source code to the class/object interfaces over the VB property sheets and drop lists any day.
VB has its plusses, and is really useful for Windows quick projects. Beyond writing calculators and little data entry screens, however, it's more trouble than its worth.
...Cross platform? VB? hah hah ha ha ha.
VB is popular because Windows has no bundled development tool available at all. Under *NIX there are a hell of a lot of useful little tools available to develop your own solutions to simple problems. People already familiar with getting around the shell can manage to churn out a script or two if they have to, and most have probably been tempted to toss a few lines of perl together. Most Windows users don't have those options. VB really caters to Windows users who need some kind of simple tool to write simple programs. If Windows was supplied with a GUI oriented language of its own, VB wouldn't be successful.
Tec
------------------ got a tiger in my tank. fish very unhappy.
I would like to see the statistics combined with what the people actually do for a living and what architecture they do it on. Frankly, this seemed like an article to simply say Java isn't good enough and I can't agree more. Who really needs an extra "compatibility layer" between pc and user? Not I. Next, where was Perl? I'm sure more people use Perl then some of the other choices to solve day to day problems.
I'm tired of reading all of this bullshit about "real programmers". I code full time and pay my bills with coding. I am a "REAL PROGRAMMER". Students are not "real prorgammers" because they just putz around in school. Wannabe geeks working at help desks are not "real programmers". A "real prorgammer" is somebody who does it day in and day out, 40 hours a week. Period. I'm a full time VB prorgammer, and quite proud of it.
A "real prorgammer" is somebody who does it day in and day out, 40 hours a week.
That's an interesting distinction. In my own experience working on Unix/C systems, we spent a lot of overtime getting the system done. When I switched to VB, I quit working overtime... because I didn't need to anymore.
It seems (IMHO) that the "gee wiz, look at that pretty logic structure!" guys are the ones staying late and working their lives away, because they love the stuff. Most VB guys, even those who have previous experience in other languages, seem to leave at quitting time and go live their lives. Or is this just my experience?
Either way is a valid life-choice, of course... I wonder, though, how much of it is cause and effect... do the VB guys leave early because they're sick of looking at VB, or because they're more efficient and can go live their lives instead of being chained to the desk? Do the gee-wiz guys have to stay and grind out the code, or do they like what they do so much that nothing else seems attractive to them?
I just wonder about these kind of things sometimes... usually it means I've overdosed on the allergy medicine again...
Good point. I'm a VB guy who leaves as early as possible in order to have a life. I couldn't care less what language I use. Programming pays my bills. There are lots of VB jobs, it was easy to learn, and the pay is great. I couldn't care less about the logic structures or all of the other crap that people are whining about. VB gets the job done, and that's all that matters.
"Real programming" is not the be-all and end-all of programming. I've seen far too many "real programmers" whose heads are so "real far up their asses" that they write stuff that their users don't want or don't fit their needs. If you're way more interested in implementation technologies than serving the needs of your users, get a human-computer interaction specialist on your team! I'd much rather use a program by a competent VB programmer who knew want was needed and wroite a useful and usable program than the most hardcore C++ guru who cared more about how kewl his optimized Patricia tree algorithm was.
If some of the arguments presented in this discussion held water, nobody would have written any good music on the piano. It's too damned simple an instrument; however could you play or write anything more complex than twinkle twinkle little star? After all, look at its interface. Notes get lower as you play the keys to the left, and higher as you move to the right. Volume is proportional to the velocity with which you strike the keys. Only "tune kiddies" (or perhaps "score kiddies" is the better term) would be caught dead with one of those things.
I'm a strong believer in having a life and as a result also believe in tools that let you have a life. For most business applications, VB does the job quite nicely. Need speed? I'll use C++ Builder. Writing an enhanced CD? Director. CGI? Python. Given a choice between being "elite" and having a life, the life wins every time.
Perhaps it's time for everyone to go demonstrate the slashdot effect on the Ask Tog site and look at the article How Programmers Stole The Web. It provides the best and most rational argument for having an "easy" language around: "real programmers" aren't the only people with good software ideas. Think of the of those who don't qualify as "real programmers": Dan Bricklin, who came up with the spreadsheet, and Robyn and Rand Miller, who came up with Myst.
Of course VB is the most used language. Actually the most common one is probably still COBOL, but those maintenance programmers out there don't want to admit that they're using it. VB has a very gentle learning curve, there's a tremendous amount of learning material out there for VBers, and MS markets the hell out of it. A lot of the self taught VB people couldn't program their way out cardboard box if you wet it and poked holes in it, but they can get up to a level of moderate productivity very quickly. I work at a MS partner company. That's not to say I take everything they dish out and recite it as gospel -- it only means there was someone out there who wanted to give me money to develop programs. VB has its bugs. I do a lot of work in it, and I'm pretty good at working around them. It's a kludgy, awkward, buggy and inconsistent language. A lot of things feel like they were imlemented piecemeal and never really designed. It's also not terribly fast and distributing it requires you to distribute a hell of a lot of stuff, even for a Hello World app. The strength of VB is that I can take 5 junior programmers, give them a design, some coding standards and guidance, and crank out a pretty good app in half (or less) of the time it takes to do it in C++. What's more, a junior C or C++ programmer costs a lot more than a VB programmer and is *much* harder to find. VB puts many projects in reach of a departmental budget that could never afford to do it in C. Is it is good a system as the one that could have been done in C? Well, C could have produced a better app but the department wouldn't have been able to afford it. Bummer. This ease of development is why VB is popular. Delphi should have this role, since it's far superior to VB, in virtually every way. Unfortunately, MS saw this and (for the most part) crushed Borland. This is why, IMHO, Borland porting Delphi to Linux is one of the biggest developments that will spur its acceptance. Who really cares about how much the OS costs??? The real expense is the cost of developing and maintaining the apps that run on it, and customizing the apps that are purchased. This is also the strength of open source. VB is slow? Bloated? Sure it is. I don't think there's any compiler optimization. Nasty, nasty, nasty! But at the same time, hardware is cheap and fast these days. Buggy? Yup. Sucks don't it? Check out http://www.vb-zone.com/upload/free/features/vbpj/1999/mckinney/mckinney1.asp. This guy was in the languages group at MS for a long time. Well, I've ranted enough. :-)
This article is very against JAVA. Yet more FUD from the media. Please note that Zona got to choose the group of business developers. If they were using VB, they are Windows (probably Intel) platform. Responding to quotes in the article... "The Zona study found that, in the eyes of business developers, Java still has some significant shortcomings that Sun will need to address. Topping the list is performance speed, according to the 150 developers surveyed by Zona. Users have long complained about how slow Java applications run on the desktop." ...Is VB really faster? C, C++ can be, but VB? I wonder about this. The GUI I can see, because JAVA talks through its GUI (say AWT) to X or Windows, whereas VB can hit the Windows layer directly. "The other major concern among developers is the lack of a Java standard managed by an open-standards body. Currently, Sun is the arbiter of Java specifications and standards." ...And Microsoft is the arbiter of VB specifications and standards. "Other concerns include: Java's scalability, or the ability of Java applications to be expanded to keep pace with business growth, and migrating applications across all platforms." ...And VB, C and C++ also have a problem migrating applications across all platforms. At least JAVA makes an attempt to tackle the problem. VB is Windows only, and C, C++ don't have a defined GUI that is standard. ...And VB doesn't scale... It goes to NT and that's it. C and C++ scale... sort of. Threads, MP, etc are not defined (well... they are, POSIX, but that isn't part of the language... and try running POSIX threads on Visual C++ without add-in libraries!) What they are implying is that JAVA won't overtake VB until some problems are worked out -- speed, portability, scalability, and ownership of the specifications. For each of these points, JAVA has an answer, while VB doesn't even address the issue. Ratboy666
How can you survey only 150 people and make a sweeping statement that VB is #1? Its absurd and should be totaly ignored because its statistically insignificant.
There are millions of Developers out there and to only ask 150 is just plain stupid. Visit the Arcade Restoration Workshop @ http://www.primenet.com/~bking
VB is easier to learn and debug than most other languages. When you create forms, you drag and drop controls to the form almost as if you where painting them on. Many big businesses use VB for that and other reasons.
Granted my C/C++ skills would come in handy to make more robust applications; however, I have to have other programmers in my company cover for me when I am not there. Since they don't know C/C++ but know VB, I have to develop in VB.
Java not only is new, but when Java is used the program that runs will run a whole lot slower than one written in VB or C/C++, etc. Java has to get around a lot of bottlenecks that slow it down to unacceptable levels.
Visual BASIC, as far as I know, is limited to the WINTEL platform. Windows and X86 CPU chips (unless I am missing that Alpha version of VB, didn't know that one existed?), you won't, for example find it for MacOS, Linux, BeOS, AmigaOS, etc.
For serious programming, Java does not cut the mustard, in my humble opinion. Sure it is portable, but my employers look for more power and something that the team I work with can program in. Out of like 12 programmers, only 2 of us know Java. But 12 of us know Visual BASIC. So guess which one is the lowest common denominator?
You guys/gals should check out REBOL at: http://www.rebol.com Written by the key architect of the AmigaOS. It's small, fast, easy to learn and growing.
This survey seems to be geared to client-side business applications.
I can almost guarantee you that there are more *new* COBOL applications being written today on the server than other languages. (Primarily for Y2K, but even for new apps. CICS+COBOL is proven, it scales, even if it can be monotonous.)
The biggest reason novice and casual developers love Visual Basic is because it hides a lot of the complexities of a multi-tier environment. A great example of this is the ActiveX Data Object (ADO). This is a great way to access data in Enterprise data sources, provided that:
1) your needs are relatively simple
2) your backend is stable
What happens when either condition is not met? There are endless problems. What is the single biggest source of these problems? Lack of transparency of the components.
When I had to work with ADO, I found it impossible to debug. The biggest reason was because it made native calls to the ODBC driver on the platform, and never produced debuggable SQL code. This was true in spite of the fact that the database the code was accessing was a Sybase SQL Server. What a nightmare!
Most of the people in this community are not from a school of thought that would ever accept a tool like VB. Not only do we not typically use component assembly techniques to write our programs, but also many of us will not accept code from third parties in most cases unless we have the source.
So, it makes perfect sense to me that VB comes out high in a poll like this and many of us can't understand it. The same thing would happen with databases. Access, MS SQL Server, and Oracle would make the list. mySQL would be left off.
-- Dave Aiello Chatham Township Data Corporation
Not surprising (Score:0) by Anonymous Coward on Wednesday October 27, @03:14PM EST (#262)
Every poll is partial, it seems like the programmers having been surveyed in this poll are consultants working with extensions to different M$ products. Hey, who wouldnt use Visual Basic for those tasks? Java would be completely off track in such a problem domain. As for 'Which language is mostly used/appreciated among the average joe programmer', we have a completely different picture. Still, such a poll would also be colored: Who were to be polled? In sum: Noone is without bias.
Since this discussion seems to have a lot to say about VB, I figured I might bring this up:
There is a VB to C/GTK converter that will handle most of the VB stuff. It's command line and therefore basically useless for development without VB for Windows. Search Freshmeat for this -- it's called vb2c. The guy doing it just made it for fun, but now, considering that we have "proof" that VB is the most popular language, it's useful.
I want to work on a VB GUI for Linux to complement this program; would anyone want to help me (or has this already been done)?
Kenneth Arnold
PS - I got interrupted while writing this so maybe someone has already posted something about vb2c. If so, just ignore this.
Do whatever you want, but be prepared to accept the consequences.
Use VB for mission critial apps? That's laughable. And I doubt that many people use VB for the critical components of their mission-critical applications.
In my experience I've only seen VB used for a non-critical Client interface to a perhaps critical back end. If a PC client dies once a day, who cares? But if the backend dies once a month, there is hell to pay. "Just fire the guy".
I'd never ever do mission critical application components with VB. Or with Microsoft Windows anything. Sorry, I just don't see the stability or tools to do so.
COBOL on the IBM mainframe is THE most mature backend. And I find it incredible that it didn't even make their list, given all the COBOL programmers I've known.
Recently, a friend of mine wants to implement a simple parser for basic +,-,*,/ computation, well, a binary tree is needed. Simply speaking, I want some data structure like this(in c) struct node { int data; struct node *left; struct node *right; } I can do that in java, perl, c, c++, python, but don't know how to do that in VB. Can somebody enlighten me on this? In my opinion, a language not capable of complex data structures sucks.
1) Create a Class file Have as members of class file: Integer (should implement as properties) Left Node (integer, as property) Right Node (integer, as property)
2) Declare an array of this class, the nodes are offsets, assume 0 is root If I can't reinvent myself, can I at least copy someone else?
while I found this poll interesting I wish some more information was given about the group of 'developers' they questioned. Of course if the people polled were mostly developers of small business apps for windows platforms VB would come out on top. If the majority polled were unix administrators, who knows maybe perl would have been most commonly used. This is because most languages I feel have their own niche they try to fill. Not claiming to be an expert, so please point out any mistakes here.
VB - small quick and dirty business applications often for use only within the company. When program development time is crucial.
C/C++ - large programs in which speed is an important factor, or when anything else just won't do.
Java - originally hyped for the ability to write applets (Ya know the ones that take an hour to load when they do, and often crash your browser) but seems to have increase popularity on the server side because of the ability to seamlessly(sometimes) run across NT and *nix servers.
I think a poll should be taken asking the language developers use for specific jobs. For example some catagories could be: database apps, web apps, commercial software, etc.
Given the outcome of the NT vs Linux benchmarking a few months ago, who wants to start a betting pool on when it will be revealed that M$ bought this one too? Never doubt my powers, mortal.
I use VB for a significant amount of my work, most of which consists of connecting to some form of database backend. I find COM to be a very useful model to work with.
Using VB I can build a small DLL to do any processing I need in no time at all. If performance is really important, I can do it in VC++ as well..., or any other lanuage that can create COM DLL's. I build a couple stored procedures for that DLL to work with in the database, and put together a GUI in no time with VB. The GUI calls the DLL, which calls the database. Instant 2-tier application. Depending on the backend (anything from MS Access ugh..., to SQL Server on NT or Oracle on linux, or a giant mainframe..., whatever), can support a damned lot of users. Drop another NT box in with MTS, change 1 config setting on the client, and it's a 3-tier app. Add another NT box with IIS, make a couple calls to that DLL from ASP, and now you have a WWW interface to your data. The ASP code would be almost the same as the GUI, almost no development time. I don't know of any other languages that can do that as quickly.
Now I admit that VB is severly limited for a lot of things, and that there are most definatly places where it shouldn't be used. The moment you get very far into the Win32 API, things start to get ugly, especially if you ever have to deal with pointers. It can be done, but yer better off moving to a C++ app, or at least a C++ DLL to call from the VB GUI.
The other great thing about VB, is that it is pretty much the standard for anything on windows. It's a programming language with VB, a scripting language in MS Office and other apps, as well as a web scripting language. It's the language to script the OS to do stuff (WSH, though it can also use other languages if they have COM objects to parse them) If you know VB, you can automate any MS windows app there is, as well as a lot of other windows apps, there are a LOT of other companies that have licensed VBA to use as their scripting languages.
Anyways..., I look forward to the day I can use VB under linux, and await the flames I forsee I will get for posting pro-MS stuff here. I don't like MS, but that doesn't mean they don't have some good products. --- Take out the spam to e-mail me.
heehee (Score:1) by nawleed on Wednesday October 27, @09:04PM EST (#314) (User Info)
In a business environment with windoze desktop machines and DB servers... Let us both tender for the job of the DB-front-end application, I'll propose to do it in VB and you propose to do it in C++ or Java.... Now change the situation to ANYTHING else and VB will be the last on the list (I hope :) -= That is my first point =- My second point is a bit more clear, but less serious: Don't we (as programmers/developers/etc) have anything else to "discus" (read: argue about) than this? If not the we are in a better world that I realised :) Just for the record (read: keep flames at bay :), I am a vb programmer by trade and that is why there is one windoze machine on my LAN. "They know enough who know to learn" -HENRY ADAMS
As I work for a rather large software company, I'd just like a make a few observations.
First of all, Java is really popular - but not for PCs - but server programs (distributed stuffish). Java and Java Servlets are gaining ground really quickly as far as I can see. Additionally, I'm seeing more and more companies switch to Java - not because it's a great performer (although the new IBM JDK is really really fast!), but because you can deploy large scale apps rather quickly, and fairly painlessly.
However, I don't see C/C++ going away anytime soon, because although Java certainly has it's merits, for most quick and dirty programming jobs, it's overkill. Although C/C++/Perl have the ability to program OO in them, they don't *require* you to program that way to get anything done. I, myself, do about 90% of my programming in Perl - because it's incredibly easy and quick to program in (once you spend a bit of time learning it). I constantly end up amazing the VB/C/C++/Java developers because I can get programs done quickly and efficiently. Go Perl! Thanks, Larry!
As far as someone becoming a new programmer, I'd start them out on C, and then work them up to Java as quickly as possible - although this survey doesn't say so, I see the industry switching more and more to Java in the future.
Well, enough on my rambling! Mina Inerz [N. Reinking] PGP User ID:0x9E9CA97F
Hard to believe (Score:0) by Anonymous Coward on Thursday October 28, @01:04AM EST (#327)
I find these statistics a little hard to believe. 35% of developers prefer VB? They certainly didn't ask unix developers. They only asked 150 people and now they're making broad assumptions about "developers". If "developer" means "anyone who has ever written a program of any kind", then I guess there are enough business majors to give 35% to VB.
I like Google! (any posting mentioning Google automatically gets a +1)
I use VB/VB Script daily in my job and agree that most VB programmers are poor lost souls. They create crappy code with no thought behind readability or maintainability. The other problem is that most VB programmers are not _really_ programmers. They have no experience in other languages, no knowledge of common algarithms or data structures, and no understanding of how to write proper code.
When a good programmer uses VB, it is possible to achieve fast, maintainable, and understandable code.
However, I'd never use VB on a web site open to millions of users, a product for public use, or anything which requires true 24x7 uptime. (but then we wouldn't even mention microsoft products at all)
However, speed rarely matters in a buisness application because most buisnesses need GUIs, buisness logic, and data storage. Users usually have more latency than GUIs, networks tend to have more latency than any buisness logic implemented in the back end, and data storage is almost never the problem because of user and network latencies.
If high speed really is needed, encapsulate the needed portion in a language like C++ and then glue the pieces together with VB.
The only holdback left (that I can think of) is hardware resources. Since hardware is cheap in a large organization (by comparison to the cost of head count), IT managers are quick to jump on the NT/VB bandwagon. Build dedicated servers with a gig of ram and four processors each. IIS, SQL, Application Services, and a file storage system will hold a large portion of the company up for quite some time.
The problem is of course that IT managers are mislead into thinking that if somthing is written in VB, anyone who can build a GUI can therefore maintain any and all existing code. Which is a completely false assumption.
The other problem I see is that IT managers go down the NT route because they believe it is easier to support. And, their right. As long as they don't believe in 24x7 uptime (or, anything but 9x7 for that matter) What they don't see is that a very large orginazation must be built to support an NT infrastructure. While the same can be true for a Unix infrastructure, I believe that with the same funding, a Unix based infrastructure is easier to maintain. Unix's main problem is the lack of good online programming documentation and examples.
While IRC and UseNet are great for these kinds of things, almost anyone can go search msdn.microsoft.com for information on almost any microsoft technology and how to implement it without having to beg someone for an example. This is especially great for begginners who don't want to feel like newbies in front of a bunch of people.
Josh
What this country needs is a good five dollar plasma weapon.
Posted by Roblimo on Wednesday October 27, @07:18AM EST
Zona Research Does Programming Language Poll
All trademarks and copyrights on this
page are owned by their respective owners. Comments
are owned by the Poster.
The Rest © 1997-2004 OSDN.