Zona Research Does Programming Language Poll
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.
> 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.
I've finally had it: until slashdot gets article moderation, I am not coming back.
My favourite programming language depends on the problem to be solved.
If it's quick and dirty where getting the program done quickly is more important than having it run quickly, I'll choose perl.
If it's something that is large and involved, and it doesn't matter if it's slow, especially if there is a GUI involved, I'll choose Java.
If execution speed is everything, then I'll choose C.
If execution speed is important, but it's a large involved project, then C++ might provide a better compromise than C or Java.
The next Cmdr Taco duplicate will be ready soon, but subscribers can beat the rush and see it early!
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.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
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.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
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
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.
You be the judge.
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 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...).
Just my $0.02....
-- "Life is a bitch - and she hates me..."
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.
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:
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?
Slashdot - News for Herds. Stuff that Splatters.
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.
.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.
;-) So, yes, overall I'm still quite hopeful.
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
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.
Yours Truly,
Dan Kaminsky
DoxPara Research
http://www.doxpara.com
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%?
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?
It's 10 PM. Do you know if you're un-American?
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.
Borland Delphi:
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.....
> 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?
Sheesh, evil *and* a jerk. -- Jade
>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.
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:
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.-- Slashdot sucks.
And here's why: Learning curve.
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....
---
- Give a man a fire and he's warm for a day, but set him on fire and he's warm for the rest of his life.