Slashdot Mirror
The Problem Of Developing
A reader writes "ZDNet News is running an editorial about the choice of programming languages for developers today. The author suggests that developers have been left with little choice because all of the current programming languages are essentially the same."
The author obviously is not in the right industry if he thinks developers only will program in VB.NET, C# or Java. I suppose I shouldn't show up to work on monday for the job I got programming C, because once the word gets out I'm *sure* that C will only be found in a museum.
Yes but every time I try to see it your way, I get a headache.
The question left for the reader is where this leaves developers. Was it a better world when developers could chose different languages based on the requirements of the application? Or should all languages do the same thing with different syntaxes? Microsoft has decided which way it prefers, and choice is out.
You still can choose different languages. Nothing says you can't use C/C++, VB 6, Perl, Python, or whatever else you want. While the implication in the article is that all developers have only two choices, the article should have said that Windows-specific developers are left with the two choices of Java or the CLR languages while other developers are still free to choose the tools that fit the problem. Nothing has changed unless you are only going to do Win32 programming.
The article is overall pretty positive, but I do disagree with a few things.
I specified VB.Net as opposed to VB; even though Microsoft would have you believe otherwise, the two are really different languages.
I don't think MS is really trying to hide that VB.Net is very different, and many many VB developers are mad at it for changing things so dramatically. Although the syntax is close, there were many changes, some make necessary by the fact that everything is now an object, and some just to drop bad practices (Wend, Goto, Variant, As Any, etc.).
The article also makes it seem like MS is advocating C# completely replacing C++, which it is not. C++ is still included in Visual Studio.NET and although MS is pushing C#, it's not going away in the MS toolbox.
If you want an example of MS dropping a language, look at Visual FoxPro. Anyone remember FoxPro? MS is still officially "no comment" on the matter, I wish they would just come out and announce that it's dead.
The different languages for CLR being alike to skins is a pretty original argument. We could pick it apart, but I see where he's going with it.
Please subscribe to see the more insightful version of th
Hmm... I'm no expert, but neither, apparently, is this guy.
A) All languages share a common runtime: Assembly. Just because I can run LISP and C on the same computer/runtime doesn't mean that they're similar. CS is all about abstraction. Of course you can have the same underlying structure, you can have different underlying structures too. That's the beauty of abstraction!
B) Java and C# are not the logical successors to C/C++. They're more like a smalltalk with a C-syntax and some trade-offs for efficiency. In terms of providing system calls and API's that are cross-platform... Well, even more like smalltalk!!
C) Remember, C++ started out as a preprocessor for C. Any "C++" code just became C code that was uglier to look at. The difference between procedural and object-oriented isn't that big a deal, other than it's often easier to think in OO and easier to implement a language that's procedural.
For a more interesting observation about the same problem that comes from Rob Pike (big UNIX guy at Bell Labs, co-wrote the UNIX Programming Environment) go here: Systems Software Research Is Irrelevant. It makes many good points about how cs is more the same than different now as compare to 10, 15 even 20 years ago!
The author suggests, clearly "Microsoft has decided which way it prefers, and choice is out.", and not that developers face today a hard choice when looking for programming languages.
It's easy to see the difference here. This article only scratches the "All languages look the same", specially for coders. Maybe for deployers (if you make this separation).
He even let the essential point, for developers, by throwing questions (2) to the air.
Well, let me answer what the article should have touched. It's not the programming language that MS or Sun is controlling, but the tasks to be performed that they are limitating. By making a common programming framework, so widely marketed and, good or bad, soon to be accepted, from Microsoft or not, they are essentially narrowing the solutions that one might come for a problem, since you have to do the 'framework-way'.
Yes, it's good to have a common ground where applications, services and solutions can be distributed. But a lot of problems will arise when you can't (or perhaps should not) use the right tool for the right job.
Buy a Nintendo DS Lite
Usually in media the editorial process is such that the writer doesn't determine the headlines or titles for his articles -- that'll happen at the production stage, at which point the article is out of the writer's hands. I agree that it should have been made clear, though, and if I were the writer I'd be getting on the editorial staff to get on the web staff to change it, because it reflects poorly on him, when it shouldn't.
--------
Bleah! Heh heh heh... BLEAH BLEAH!!! Ha ha ha ha...
That's funny...I've been developing for many years, for a number of very large companies, and I've seen no indication of a mass exodus towards J2EE and .NET. With a large base of C/C++ legacy apps already in place, there's not a chance in hell J2EE and .NET will "rule the world" anytime soon (if at all). I've seen too many "large-scale enterprise solutions" become waterlogged by voluminous requirements birthed from the loins of the J2EE standard, or slowed to a crawl by megadollar application servers that simply can't scale worth a damn.
Sounds like this guy's just trying to make a name for himself. To me, it simply appears to be a load of FUD, with no basis in fact (like most FUD).
Author seemed to not consider Scheme and Prolog. Meanwhile its not widely used, they find a niche in research community. They use different paradigm, not just a mere different syntax.
It is true that general programming language is dominated by OO-based or imperative based programming language, but things keep improving. Like Java -- it includes features on type safety to some extent. Newer programming languages are designed to ease developers for rapid development phase and overcome various limitations from their predecessors. Thus, developers in turn do have choices: Whether they want to use the newer ones or not.
Since programming languages are designed to ease users, they are specifically designed with as minimal amount of learning as possible. Hence, since virtually all programmers are familiar to C/C++ syntaxes, the design of the new programming languages tend to adopt them in the hope that the language will be quickly embraced. Thus, this explains why the newly programming languages are like C/C++ or using this paradigm.
Now OOP paradigm has "invaded" the market. Aspect Oriented Programming is yet another new concept to supplant the OOP. When better paradigm comes, it will eventually be embraced after it has been proven cost-wise and time-wise worthy. We will witness whether this is true in the near future.
Just my 2c.
--
Error 500: Internal sig error
In fact, if one were to look at computer science departments across the country, you'd see that Java has replaced C++.
Yes, and don't we all remember computer science departments espousing all sorts of other languages that had no commercial following (AlgolW) or limited mainstream application (Pascal)?
Computer science courses use computer languages for a variety of purposes, such as teaching algorithms, language design and compiler writing, several of which are quite different to the requirements of engineers building substantial systems.
Yes, language B might end up supplanting language A, and if it does you might note in retrospect that computer science courses started using language B before engineers, but you can't make the deduction the other way around.
Just check out how many Java contractors are currently out of work in the UK and compare with C++ contractors.
Comment removed based on user account deletion
Its just not funny.
Its a technology, an innovation, a new way of thinking, ok and its a MS library or VERY useful and powerful tools.
Prediction: MS is going to start giving their OS away in no more then 5 years (Remember Don said it first!)
Peace Out
(SIT,OWGO,02,DER,CW,79,42,,38/81/481/90/12)
Interpreted languages pushing aside compiled languages for high performance computing? Uh, no, that doesn't follow, and the reason is that if you need the maximum possible speed and efficiency, you don't want the over-head of an interpreter. In other words, if you can get by with using an interpreted language, it is not high-performance by nature. Only by having the luxury of more-than-adequate system performance can you afford to interpret everything.
But, on a different tack, why do we care so much about the languages we use? Why are we so stuck on "my-flavor versus your-flavor"? And more importantly, why is there always this huge push to make one language dominant over all fields? Why can't I just use the language that best expresses my ideas? (if starting a new project ;-)
"Avast! Prepare for the rodgering!" THWACK! "Arrr.. me nards.."
"i still see a lot of development with c or c++ for speed reasons. Java may be a great language in theory, but it still has issues with speed over a native language."
a tter.setMinimumFractionDigits(2);a ximumFractionDigits(2);
It's not just speed; I do pretty much ALL of my coding in C (including building a feed forward neural net if you can believe that) and I LIKE it for the same reasons I like Linux; the system/language proudly hands me more than enough rope to hang myself and doesn't bother to complain if I do. In the IT industry hanging rope = flexibility... I LIKE the fact that I can do weird sh!t with the system and I like that I could type rm -rf *.h if I wanted to and the system would follow my command.... another reason is this email I once got:
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();
form
formatter.setM
String s = formatter.format(x);
for (int i = s.length(); i < 10; i++)
System.out.print(' ');
System.out.print(s);
Oh god, that woman is John Romero!
Hah! That bug was in certain versions of the commodore 64 rom (backspacing over an extended line could crash the machine). Of course commodore basic was originally written by ... microsoft!
What if there's a security hole/bug that was prevalent in the CLR? All the languages that use the CLR would be affected.
Yeah, but then, when that bug is fixed, all the... oh, wait. (Light goes on above head)
If you fall off a building, go real limp, because maybe you'll look like a dummy and people will be like hey, free dummy
... is being an engineer who's boss will read this article and take it as The Truth.
Nosce te Ipsum
I suppose the key advantage of microsoft's new langauges is their accessibility. They make programming easy and allow just about everyone and their pet monkey to make interactive web-based services. The problem with the article is that it refers to the majority of programmers and not the majority of programming. I'm sure 5x as many people are employed using these langauges, but I truly believe they are doing 5x less programming from a difficulty standpoint. The difficult applications (signal processing, computer graphics and games, server and embedded systems, AI, whatever) are all developed using C, assembler, or some other more empowering language. I think we need to develop a distinction between end-user net-service based programmers and true developers. Something like the distinction between a carpenter and my sister who assembles furniture from ikea. I apologize to everyone I have offended. But all the hard stuff is still done with langauges that I respect.
We're just now getting standards-compliant compilers, implementing the fancy stuff like partial template specialization. At the same time, people like Andrei Alexandrescu have just lately (past couple years) showed us what can be done with these capabilities. The combination of operator overloading, multiple inheritance, and fully-implemented templates lets you do some flat-out amazing things.
To paraphrase Andrei's book: You have a meeting about this big app you've written. You decide Module X needs to be speeded up, so all the smart pointers should go unchecked. You change one line of code. You discover you need multithreading in module Y, and all the smart pointers need to handle multithreading and locking. You change one line of code...
That's policy-based programming, which is just one of the techniques Andrei presents. Design your app right, and you can put off all sorts of architectural decisions until later, and change them whenever you want. And this flexibility costs you nothing at runtime.
Hell, I am tired of arguing over what language to use to do simple applications, and most applications are pretty simple. Don't believe me? Then consider the poliferation of applications that are written in VB.
I take the "if it feels good do it" approach to programming. If you like the language and feel productive with it, then, hell, use it.
I like writting apps that do things, not learning new languages or arguing what language it better.
The author has over simplified multiple things in his article. Every simplification has enabled him to claim things that on the surface seem reasonable but in practice are false. To further increase the noise he has a lot of his 'facts' and 'assumptions' incorrect.
1) "J2EE and .Net--will essentially control the programming languages market"
How does he define the programming languages market? There are more people employed writing "vertical applications". Their choice of language and libraries is typically dictated by legacy: fortran, cobol, lisp, C, pascal, etc. What about embedded systems: assembly language, C, C++, Forth. High performance computing using vectors and parallel algorithms have a whole set of specialized languages.
2) "Still, it is an amazing achievement to be able to support different languages on the same runtime, right? I certainly think it is, but others would disagree."
Where has this guy been? By the early 1980s there were compilers for Pascal, C and Fortran that compiled to P-code (a common runtime) and were either compiled to native machine code or ran in an interpreter. Not a new concept. It is just that people are ready to accept the cost today.
3) discussion of what is the natural descendant of C++.
Who really cares? Once you've chosen a language to write in, it doesn't matter how it came to be. It supports a set of programming constructs and has a number of libraries available for use (that may support the type of program you are writing). The evolution of the language is completely irrelevant.
Language designers are very aware of other languages (more so than Liotta) and will borrow/steal ideas and syntax that they like. The language is designed with a particular purpose in mind. There are literally hundreds of domain specific languages that work better than C#, Java, VB for their intended task. They may be similar to another language, or use similar constructs but they are not the same.
4) "With .Net, there is only a single runtime (functionality), but different language syntaxes (look and feel) can make use of it."
There has always been a single runtime, the machine code. It hasn't prevented languages from having different semantics from one another. .Net and JVM won't prevent it either. The syntax of a language is almost accidental from the point of view of the language designer.
I could keep going but I'm also over simplifying so I'll stop.
- AndrewN
My sole exception to this is a language called K. Yes, it has its roots in APL and has added to the APL model from languages such as Lisp and Scheme, but it has some very interesting new features of its own.
K is very very very fast to write and the run. It blazes in both categories. There is a full relational database that is written in K, called KDB. It crushed Oracle on the TPC-B and TPC-D benchmarks in both speed and storage size, requiring only a few percent above the dataset size in overhead. It has native clustering and replication that allowed it to run on a 50 cpu Linux cluster loaded with 2.5 billion stock trades and quotes and have simple table scans (such as, select max price from trade) take under a second and multi-dimensional aggregations (such as, 100 first desc select sum size*price by sym from trade) take only 10 seconds. Starting the database cluster took a tenth of a second. It is SQL92 compliant, has an extended ultra-powerful query language called KSQL that makes writing queries very simple, and the stored procedure languages are K and C.
In bwk's language benchmarks, even though this is not the K strong point, the sum of the execution times were: K at 32 seconds, Perl at 95, Java at 300, and TCL above 1400. The lines of code to implement were: K at 9 lines, awk at 95, Perl at 96, TCL at 105, Scheme at 170, VB at 200, and Java at 350.
Yes, K can look like line noise, but unlike Perl, you get alot from this. First you get extreme code density and see the entire problem on the screen at once. I came from a Scheme background and Perl hurt my eyes, so I was very skeptical, but after my roommate persuaded me to look at K harder, I realized that this high code density made it very easy debug and write code. It is rumored that KDB is written in 26 files of code, each file consisting of a single screen of code, labeled a to z. Try doing that in any other language. The language is exceptionally regular. It is so logical and consistent that it takes a little getting used to. You never have to remember any baroque language rules. Anything that makes sense, you can do. Also, even though it looks difficult, it is extremely easy to learn because K is directly translatable to English, in fact there is a K program that will do this automatically. For example to split a line by tabs you could write: And this is read: It may take a little getting used to, but with a month of K, my roommate and I were able to converse this way when describing K and you could see the picture developing in your head. It was amazing.
A unique feature of K is what is called the K tree. Unification is a very strong idea in K, so it unifies the idea of object, variables, attributes, namespaces, and dictionaries. A dictionary is a native K type. Each variable lives in a dictionary (somwhat like Python). These dictionaries are joined hierarchically and can be removed and added dynamically. All variables are on the K tree, too, so a new namespace is really just a dictionary on the K tree! This means that you can rearrange the K tree and change what functions get called. This is the most reflective language that I have ever seen (Python, Scheme, and CLisp come in a very close behind). All variables have attributes. All attributes are is a special dictionary attached to the variables (the language is so regular that this is really a namespace with a blank name so to refer to the attributes of a variable you say ns.var..attrib). And, of course, each attribute is just a variable so each of those can have attributes, too.
This interesting K tree leads to a very elegant GUI. Each variable can have an attribute named c (for class), and this can have certain values like `table, `check, `radio, `button, and others (the backtick ` is how you make a symbol). Lets take radio for an example. Then you would have another attribute o (for option) with possible values: These four lines would create a radio box with five choices, zero through four, and everytime you evaluated r whatever the radio was set to, r would evaluate to. Basically, each variable has a direct on-screen representation (they default to `data) and is directly manipulable.
K also has the ideas of dependencies and triggers in the language, so if a..d:"1+b" then refering to a will dynamically calculate 1+b, but only when necessary (if you refer to a multiple times but b does not change between those references, a will only be calculated once and stored; K figures out the dependency graph for you). There are also triggers. If b..t:"a:b-1" then whenever b is assigned or modified then a will get the appropriate value. This trigger can be anything, such as a network operation or a gui command.
The language has some other unique features like an interesting callback oriented interprocess communication system and an on-the-fly optimizing vm.
Of course since it inherits some background from APL it has bulk operators, called adverbs, that modify functions in every conceivable way (much more powerful than APL or Perl). One of the signs of a good K programmer is one who knows how to do this and doesn't use any loops (KDB, the relational database, is written without any loops).
From functional languages K inherits higher-level functions and projections. Both which are very standard practices especially when combined with the bulk operators. b f[a;;c;]'d takes the four argument function f, fixes the first and third arguments projecting a function of two arguments, then applies it to each down the list of argument in b and d.
When you use K you truly are standing on the shoulders of giants. The person who wrote it, Arthur Whitney, has this amazing ability to identify the important pieces of a problem and simplify away the rest. The performance in K and KDB is incredibly; the simplicity and power of the language and the database is incredibly.
K runs on various flavors of Unix and NT, so people should take an open mind (I didn't have one at first and was very skeptical) and really try the language and try a new style of programming. Your code and thoughts on developing will never be the same.
-j