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.
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!
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
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
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