Slashdot Mirror
What Makes a Programming Language Successful?
danielstoner writes "The article '13 reasons why Ruby, Python and the gang will push Java to die... of old age' makes an interesting analysis of the programming languages battling for a place in programmers' minds. What really makes a language popular? What really makes a language 'good'? What is success for a programming language? Can we say COBOL is a successful language? What about Ruby, Python, etc?"
Is directly proportionate to the amount of /. posts talking down on it.
Fact.
I thought it was the beards on the creator(s) of the language that determines the success?
"Quote me as saying I was mis-quoted." -Groucho Marx
Portability and scalability are what win it for me, I like to write my code once and it's got to be powerful enough to deliver a complex solution.
Procrastinators, Unite Tomorrow!!
Java's well organized, has a great standard library and is (mostly) consistent with itself. Its only problems, as far as I can see, was that it was initially slow and that it marketed itself as a web language, when there were better choices for that.
Disclaimer: I've only coded in Java since 1.5.
What Makes a Programming Language Successful?
those who don't know how to use it.
the answer is facial hair
The lack of type-safe variables, the possibility to write unreadable code, hunt for bugs that are caused because two files are incompatible. Interpreting languages has been tried before, and they are never working for large projects that shall live for a long time and has to be maintained by a lot of different programmers.
Java may be a bastard of Ada, but at least it has some type checks built in. However, it's a bit weak on the side where the user can't control memory management in a good way. Another weakness is that methods can't be declared to allow/disallow the return of 'null' values to be detected at compile-time.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
Either evolve or die.
Java hasn't changed all that much in the last few years and younger languages are pushing programming further.
Although oddly enough the languages for which I speak are things like C# and not "I wish it would die but it likely won't" languages like Python.
Power: What can it do?
Performance: How fast can it do it?
Ease of Development: How fast can quality code be turned out by regular programmers?
Most modern languages fail on a couple of these. C is first class in Power and Performance, but it's not Easy. Ruby is okay in Power, and its very Easy, but it's slow. Java is Powerful, but doesn't match C for Performance, and it's not the quickest for development.
I'm sure many fanboys will disagree with my analysis. They'll say "Regular programmers don't matter (C)" or "It's NOT SLOW (Ruby)" or "Development is too quick! (Java)".
Really though, that's what it comes down to. The problem is, that there are unfortunate tradeoffs that have to be made. Most languages have a strength, but they all make sacrifices to be strong.
ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
I think many people fail to recognize that the average age of software engineers has gotten higher and that many have realized that most of the pitfalls in software development have little to do with the language chosen. I would rather concentrate on good engineering practices and refining familiar modules I have developed than learn a new language.
love is just extroverted narcissism
Not to sound too much like Obi Wan, but many of the truths we cling to depend a great deal on our own point of view and all that.
If I was working for O'Reilly, Manning, APress, Wiley, et al I'd say a successful programming language was one which sold lots of books.
If I was a hiring manager for a large software company, I'd look closely at what language allowed the most cheap new grads to work together an produce something resembling quality code.
If I was teaching intro to computer science, I'd worry about what was preparing my students for the rest of their education.
If I was teaching a certificate-level course to people looking to get into the job market quickly, I'd look for the language with the highest placement rate.
If I was a person of little clue, I'd go largely by the hype. Some would go with the mainstream hype, and some go with the counter cultural "that's the big hype, but our language is better" underdog hype.
As a programmer, I prefer the language that helps me turn customer requirements into working programs that fastest with the least fuss on my part, and allows decent maintenance and customization later.
As the owner of a small boutique programming shop, I want my expressive, powerful language to give me an advantage over others using less expressive languages. I'd like to find others who can use it, but a few is alright as I don't need a huge team to work on programs.
Python's success is based on how much python coders bash PHP. The more they attack PHP the better the language gets.
MABASPLOOM!
Every program on your screen and your OS was written in C/C++
The less cryptic the better. This generally means, be C-like in your operators and be easily readable at a loop level.
Having multiple abstractions available. Multiple ways to do the same complex task efficiently, not just for() or while(). Regex plz.
Being able to access hardware directly. This includes RAM allocation.
Few unexpected side effects. Documentation is important for both adoption and maintenance of programs written in the language.
That's all I got.
Often wrong but never in doubt.
I am Jack9.
Everyone knows me.
Slashdotted already, that was quick!
I review code for security flaws for a living. I am a pioneer in this field and have literally written the book on it (the OWASP Guide and the OWASP Top 10 2007). I've been doing secure code reviews for the last 10 years.
.NET. I haven't reviewed a .NET application this year.
.NET a very distant second.
I've reviewed 400-500 applications (it's unclear to the total number, but I usually do a review every other week, some shorter, some longer).
I've never reviewed a Ruby application or been asked to review code written in that language. I have been asked to review a Haskell application.
I have reviewed:
* 85-90% Java, usually with shell and ant scripts and occasionally some Perl. Some *years*, this is the only language I am asked to review.
* 5-10%
* 5% COBOL. Primarily as a side line - there's a lot of old code to review, but most folks never do.
I've reviewed three PHP applications professionally, all in the last year, even though this is my preferred language to write stuff.
Java is overwhelmingly used in large commercial settings for high value applications, with
I don't get to review that many COBOL or other mainframe apps. I've been doing ground breaking research in this area as there's no advice today. There is a false belief that this code is somehow "safe" as it resides on the mainframe. Nothing could be more wrong.
Ruby and Python, although interesting langauges, has zero commercial penetration, even for worthless brochureware or community apps.
What they do have is an extremely loud fan base. These languages will not kill COBOL or Java any time in the next forty years or so as the fan base is fickle and will move on to the next big thing when it comes along.
Andrew van der Stock
To make a language successful, it must be "good enough" for its purpose to attract developers, and promoted enough so that management types will actually allow the language to be used.
There is a huge difference between languages that work well for one- (or maybe two-) person teams and ones that scale to large projects. Many of the scripting languages (PHP-like) are great for quick results and small projects. Strong type checking, documentation, enforcing good coding practises don't matter if the project size is small enough that one person can keep it all in his or her head.
As you get into large projects all of this starts to matter.
The quality of the IDE also starts to matter--you'll find better/professional IDEs at the top end languages.
Websites built with Java can support more than 10 users concurrently!
that is going to kill poor Java
It is not the fact that it is overly verbose, too rigid, and is bloated as as a puffer fish on helium.
how long until
Jesu effing Christo.
One thing ain't got nothing to do with the other.
I can't decide which is worse, this particular bit of idiocy or the all-to-common: "dynamic vs strong typing" arguments.
Actually, maybe I'm being to hasty.
The conflation of runtime implementation details with language capabilites, or the above-mentioned typing confusion, does provide a quick and easy way to tell that someone doesn't know what the hell they're talking about.
There are only two people in the world that should be allowed to create languages: Brian Kernighan and Dennis Ritchie. Everybody else should just f**k off.
Seriously now, I've been working lately on a full-fledge distributed application using the latest of typical Java products (Spring, Hibernate, Apache CXF etc) and I feel the Java platform offers great portability and good standard libraries, but integration between components is hard, not all features work the way you want them to, refactoring is costly because the language is too strict, and there are still pitfalls like the need to use DTOs to marshall objects back and forth. However, I don't have decent experience with alternative stacks (.NET or Ruby on Rails) and I don't know how they compare with the current Java stack. Perhaps Slashdotters could shed some light on the issue from their own experiences (not just say "I like this because of that," but real experience.)
If the "13 reasons" site is written in one of Ruby, Python or the gang, I'm not too impressed.
Don't count out the "dead" languages... IBM estimates that more than 30 billion transactions occur within Cobol programs every day. By contrast, Google averages about 150 million searches each day, or about .5% of Cobol's daily workload.
Rather than a "gee I need a cool website for my mom" choice, perhaps the number of transactions or dollar value would be a better count.
Cobol would probably win, followed by java and the Microsoft languages (C++, C#).
Really points out some solid arguments about syntax and others things that alot of people have been saying for awhile.
This is my sig. There are many like it but this one is mine.
I just got.
/2008/05/28/13-reasons-java-die-old-age/
/2008/05/28/13-reasons-java-die-old-age/
...
Maximum concurrency limit of 10 exceeded.Currently serving the following requests:
Not sure what language they used, but it should be dead too.
Right here.
I can think of two ways to judge the success of a language.
1) If people use it.
2) If you can find people who will pay you to use it. And assorted corollaries: if people will hire you because you know how to use it, etc...
Given that programmers need to eat, I'd tend to go with the second though the two are basically related anyways.
Google Cache
Languages are a Social/Cultural phenomenon as much as a Technology. A big part of a language's power is how good and complete its libraries are. And these are built by a community of programmers.
Only to idiots, are orders laws.
-- Henning von Tresckow
Sorry, but this article presumes too much.
Python and Ruby are not going to push Java away. For one thing, they are SLOW which automatically disqualifies them in a lot of areas (like high-performance computing). Also, Python interpreter is STILL single-threaded.
Besides, JVM can serve as a platform for many languages. My favorite one is Scala (which is now often deemed as a 'Java killer').
I just started at a new job at the beginning of this year after quitting from my last job where I barely got to do any programming. The place where I work now is a Java shop. I was getting back to Java programming after a hiatus of a few years. For the last few years I mostly doing Perl with a smattering of C (PHP and Javascript on occasion). My experience with Java was mainly from college and a few odd projects I did here and there. The language had changed quite a bit over the last few years and to be honest, I surprised myself by being happy to get back to it (I had some sort of vague dislike for it for a period of time).
The company sponsored a trip to JavaOne at San Francisco earlier this month, for the Dev Team. I also got to go. This was my first time at JavaOne. It was amazing, exciting, and I learnt a LOT of new stuff. The main thing I got from there was that Java, far from being a programming language, is also a platform. There are a lot of new things being built on TOP of Java. For example, Groovy, and JavaFX. Java now has excellent support and frameworks to roll your OWN domain-specific languages.
Python and Ruby are not going to push Java out of the way. For example, you have mergers of Java with these languages (Jython and JRuby). Essentially you have Python and Ruby using Java resources and libraries. I think instead of "dying", Java is just going to evolve into a stable platform that lets you build stuff on top of it.
Vivin Suresh Paliath
http://vivin.net
I like
None of the new languages are useful in legacy environments unless someone ports compilers for those languages, so programmers in those environments tend to have a different definition of "useful" than Linux developers. :-)
However, it all comes down to the same things: Will the language do what I want? Do I already know it or can I easily learn it? If I end up leaving, is it supportable by someone else? Etc.
Mainframe/UNIX Bit Twiddler and long time Windows/Linux Hobbyist.
The Theorem Theorem: If If, Then Then.
TFA: "Some languages made strange mistakes. For example Python is a great language but the idea of using indentation as block demarcation really is a cannon ball chained to its feet. While most of the pythonistas defend this idea with a lot of energy, the truth is this feature makes it really a dangerous tool in big, world wide distributed projects - and most important enterprise projects are big and distributed."
Elsewhere: "Python Creator Guido van Rossum now working at Google"
Well. Now I finally know how Google is dangerous.
CC.
TaijiQuan (Huang, 5 loosenings)
there are many colleges with microsoft oriented stuff (I do not want to imagine the reason) ... ergo, many people is educated with a short range of options and ideas such as ".net is the only and true way"
What makes a programming language successful?
Same thing that makes a religion successful. Adherents.
Lately democracy seems to be based on the skybox, the Happy Meal box, the X-box, and the idiot box.
Comment removed based on user account deletion
Every time Slashdot posts a link to an article on another website, that site gets hammered and (usually) goes down due to bandwidth being exceeded. Maybe Slashdot should adopt a policy of copying the article or at least, informing the webhost of the site you're about to shut down that a link will be posted.
~smith55js
Good old google. It has a cached copy, here: http://tinyurl.com/6qo4nh
seriously, what specifically are strong features for a language? ANY language, not just php,perl,c,java,python,ruby,prolog, etc, etc, ad nauseum.
I find php interesting for being interpreted and therefore having the ability to call functions by name at runtime. Is this actually useful? Not to me, but maybe I don't know a good application for that feature.
Semaphore constructs, useful base libraries, concise solutions to common problems...
I'm really curious to know, slashdot audience, what FEATURES make languages good or useful, and in what languages do you find these features?
A language analysis that slams Python for using indentation to delimit blocks. Oooooh, how 20th century.
Puzzle Daze is now my job
No exception. If any of them were any good, there wouldn't be so many. They suck primarily because the computer itself is fundamentally flawed. Computer science has shot itself in the foot and now that parallel programming is all the rage, the computer industry is paying the consequences. It's time for all of you old computer geeks to retire. You messed up big time. There is better way to design and program computers.
Obviously there's more than one factor to a language's success, but the breadth and quality of the libraries and application frameworks is a huge factor - if you "know a bit" about programming then I'd say that learning your way around a new API is just as much work as learning a new language.
A big plus for C was that it always came with a substantial standard ("de-facto" to start with, then ISO) library based on the Unix API so it was great for writing portable programs - c.f. Pascal where ISTR the core language couldn't even open a named file. C++ was largely popularized by application frameworks like MFC and OWL, and Delphi did the same for Pascal.
PHP is pretty fugly as a language but comes with a huge library of functions and add-ons that are just what the doctor ordered for web scripting - and when people talk about Ruby, do they really mean Ruby or do they mean Rails?
I don't know about Python - it seems to be a secret society rather than a language and you can't join unless you pass this initiation test where someone tells you a corny joke (stolen from an ancient email circular about Unix and Makefiles) about a language which uses leading whitespace to delineate blocks. I always laugh and fail the test, so I've no idea what the real language is like. :-)
In a survey of 100 programmers, 111111 thought that duck-typing was a good idea.
It took me till halfway through my soft eng. degree to realize, but java is an engineer's language. It implements MIS consisely. Other languages have their place as have been covered a million times (Except for PHP. God won't someone somehow kill PHP), but java is just excellent for the engineering process.
I had to reload a bunch to get past the "Maximum concurrency of 10" thing, but I finally made it. So here it is for everyone else who's had problems:
Lately I seem to find everywhere lots of articles about the imminent dismissal of Java and its replacement with the scripting language of the day or sometimes with other compiled languages.
No, that is not gonna happen. Java is gonna die eventually of old age many many years from now.
I will share the reasoning behind my statement. Let's first look at some metrics.
Language popularity status as of May 2008
For this I am gonna use the TIOBE index (tiobe.com) and the nice graphs at langpop.com. I know lots of people don't like them because their statistics are based on search engine results but I think they are a reasonable fair indicator of popularity.
Facts from the TIOBE index:
TIOBE Index Top 20
What I find significant here is the huge share the "C like syntax" languages have.
C (15.292) + C++ (10.484) + Java (20.176) + C# (3.963) = 49.915%
This means 4 languages get half of all the attention on the web.
If we add PHP (10.637) here (somehow uses a similar syntax) we get 60.552%
As a result we can extract:
Reason number 1: Syntax is very important because it builds on previous knowledge. Also similar syntax means similar concepts. Programmers have to make less effort to learn the new syntax, can reuse the old concepts and thus they can concentrate on understanding the new concepts.
Let's look at a group of 10 challengers:
Python (4.613) + Ruby (2.851) + Lisp/Scheme (0.449) + Lua (0.393) + SmallTalk (0.138) +
Haskell (0.137) + Groovy (0.131) + Erlang (0.110) + Caml (0.090) + Scala (0.073) = 8.985%
This is less than the attention Visual Basic gets: 10.782% and leads us to...
TIOBE Index Top 21-50Reason number 2: Too much noise is distracting. Programmers are busy and learning 10 languages to the level where they can evaluate them and make an educated decision is too much effort. The fact that most of these languages have a different syntax and introduce different (sometimes radically different) concepts doesn't help either.
Looking at the trend for the last 7 years we can see a pretty flat evolution in popularity for most of the languages. There are a few exceptions like the decline of Perl but nothing really is earth shattering. There are seasonal variations but in long term nothing seems to change.
TIOBE Trend
This shows that while various languages catch the mind of the programmer for a short time, they are put back on the shelf pretty fast. This might be caused by the lack of opportunity to use them in real life projects. Most of the programmers in the world work on ongoing projects.
Reason number 3: Lack of pressure on the programmers to switch. The market is pretty stable, the existing languages work pretty well and the management doesn't push programmers to learn new languages.
Number of new projects started
Looking at another site that does language popularity analysis, langpop.com, we see a slightly different view but the end result is almost the same from the point of view of challenger languages.
What I found interesting here was the analysis regarding new projects started in various languages. The sources for information are Freshmeat.net and Google Code. The results show a clear preference for C/C++/Java with Python getting some attention.
Reason number 4: Challenger languages don't seem to catch momentum in order to create an avalanche of new projects started with them. This can be again due to the fact that they spread thin when they are evaluated. They are too many.
Other interesting charts at langpop.com are those about books on programming languages at amazon.com and about language discussions statistics. Book writers write about subjects that have a chance to sell. On the other hand a lot of discussion about all theses new languages takes place online. One thing I noticed in these discussio
Online Starcraft RPG? At
Dietary fiber is like asynchronous IO-- Non-blocking!
We all know a dozen languages here, and we all know they have overlapping roots, but are focused on different things.
Each new language tries to take what's good about the past, but re-focuses on the new type of problem. At the same time, it creates or opens itself up to new issues, which take some time to resolve. I find the third generation of a programming language usually hits the mark.
* Generation 1 - Hot, New, and Filled with Hype for what it does, but kind of buggy
* Generation 2 - Less hype, but better adept at filling the holes in Generation 1.
* Generation 3 - Almost no hype, but solid language. Very useful features added that weren't predicted in Generation 1
Ironically the biggest problem I've had with Java is that, because it is relatively easy for developers to write code using an IDE such as Eclipse or NetBeans in the core language itself, but there are tons of various classes even within the core JRE, many programmers I know who write Java have created a sort of "ecosystem" of artificial complexity.
For example, I worked on one project which was a client/server system which handled maybe 10 transactions per second, with each transaction translating into maybe one or two table updates. The application could have been put together using something simple, like Tomcat and MySQL on the back-end, and something easy to use like an XML/RPC link to the client side. (There were only something like 10 remote procedure calls being made, and this was an internal application, which means the total audience was perhaps 100 people.)
But rather than keep the whole thing simple, we had a whole bunch of "Architecture Astronaut" wannabes who started tossing in third party frameworks like there was no yesterday, without carefully thinking if the framework was needed, and if so, how best to integrate the framework. Before we knew it, the server was broken into 8 separate EJBs, Hibernate and Spring were called in to handle the server side coding framework, and the entire build process was so complicated it no longer could be run or debugged within an IDE--apparently someone on the project didn't understand ant and used makefiles for part of the build. And to top it off, because so many different frameworks were thrown in for no good reason I can determine (there were something like 40 third-party jar files in the build directory), there were all sorts of runtime problems as each jar file was not designed or tested on the full range of Java 1.4 - 6.0 environments.
Now if this was my first exposure to Java, I'd say that while the core language itself wasn't bad, the entire Java ecosystem sucked hard core. But no; it was the developers: rather than keep it simple, they used the 'refactor' button in NetBeans about 100 times too many, until what should have been a one person-three month job turned into half a million lines of crap, that, to their credit, limped along okay.
PHP - Great if you want to get web apps up FAST.
C++ - Great if you want to write OS-dependant apps.
Java - Great if you want to hire a bus-load of CS majors fresh out of university tomorrow.
C# - Great if you want to replace your old VB projects.
Perl - Great if you want to keep your job intact, as no one else will ever able able to read your code.
Python/Ruby - Great if you want to impress PHB's who buy into hype and buzz-words.
That said, the fact that Google apps runs python may see a major shift from PHP in the next few years. It's the only reason I'm starting to learn it. So far, it seems to be a cross between "Perl I can read" and "not quite Java".
(my captcha is develop ~ how apropos)
Quick, sell your Google stock!
There is a lot of solid Python code out there. The best way to write Python is to also write unit tests. Which is a good practice in any language.
Some privacy policy Slashdot.
Cashed web page
John McCarthy did. They were inventors of COBOL, FORTRAN and LISP - three languages still in use from the 1950s.
I found it interesting in this graph in the article that, beginning around 2004, the popularity of Python closely follows the popularity of Delphi. Is this some kind of flaw in the methodology in how the data was collected, like too small a sample size (as Delphi has nothing to do with Python I think)? Or is there some overall pattern causing this? A few others are pretty close in some spots, too, in terms of first derivatives.
Note that the server isn't really /.ed at the time I am writing this, but is throttling itself based on limitations of the hosting account (says only 10 concurrent servings). If you keep trying (aka refreshing the browser) you will get the image I linked to above.
I'm sorry, the number you have dialed is an imaginary number. Please rotate your phone 90 degrees and dial again.
My god People Know The Answer ... the answer is beyond simple ... and any other answer is simply BS ...
1.) Clear, simple, and familiar grammar/semantics in the core language.
2.) Simple well documented techniques for creating multiple domain specific extensions (i.e. libraries).
3.) Multi-platform compiler/interpreter support.
Now stop wasting my time with this trivial crap ...
I bet I can tell you alot about this person and I have only read the article. He is over 40 and has been programming for over 10 years. Possible associates degree, even more unlikely is it being higher. He has good information, but I deal with these people all the time, it is annoying, and now slashdot is putting his information up.
Look, technology changes everyday. With the change in technology comes a change in everything around it, including programming languages. In order to be a good programmer, you have to know, and understand, many languages. It is your job. If you are unable to accept that, than it is time to either retire and let somebody else take your 100,000 salary or simply quit.
The best language translators know more than two languages. I know that is a little bit of a different example, but it still proves the point I was trying to make. You need to be versatile in order to do your job. If all you do is program in COBOL, then talk to 1974, because they want their programming language back.
I don't even like Java all that much, but know it, and know it well. I just don't like it because I do web based work and it is easier to do it in PHP. Speaking of PHP, the syntax is as similar to c++ as it is Java.
Somebody wrote an article without doing their homework. Once a PHP script is done running, it is done, and you need to use additional resources, like AJAX or Javascript, in order to get something else to run afterwards, where-as C++, with clever coding, can continue to run, but that clever coding would be done within C++.
Let me guess, your company wants to move from Python/COBOL/The Stone Age to Java, and you wrote an article to show why Java sucks? Guess what, you have to learn Java like all of us did in order to be successful. I have a Bachelor's in Computer Science without taking a single Java course, and I had to teach myself Java for my job.
Your job as a computer programmer is to do what you are told in the language you are told to do it in. No wonder it is so hard for us younger people to get jobs programming. Mr. I don't want to learn a new language so I am going to cry about it, cry all you want, but in the end, you need to quit your job. I get frusterated with you old people now doing your job good enough and holding the positions us young people are looking for. We are hungry and looking for a job, you have been doing Python since computers were made from vaccuums and refuse to do anything but what you are doing. Leave you job, we could do your job better than you in a day.
Every college kid we get in the company I work for does more than double the work load of any of you old people, and you old people do nothing but complain. Step down or shut up.
(rant over)
The world is how you make it
Yeah, the server must have been written in .
Well.. maybe. Or Maybe not. But Definitely not sort of.
Maximum concurrency limit of 10 exceeded.Currently serving the following requests: /2008/05/10/script-thy-java-app/ /2008/05/28/13-reasons-java-die-old-age/ /2008/05/28/13-reasons-java-die-old-age/ /2008/05/28/13-reasons-java-die-old-age/ /2008/05/28/13-reasons-java-die-old-age/ /feed/atom/ /2008/05/28/13-reasons-java-die-old-age/ /favicon.ico /2008/05/28/13-reasons-java-die-old-age/ /2008/05/28/13-reasons-java-die-old-age/ /2008/05/28/13-reasons-java-die-old-age/ /2008/05/28/13-reasons-java-die-old-age/ /2008/05/28/13-reasons-java-die-old-age/
If you are the owner of this website, you may need to upgrade to a more advanced plan.
BASIC and PASCAL etc. are of the "functional programming" ilke (as is SQL, but that's another story - look up "the vietnam of computer science" if you're interested and also http://advogato.org/article/964.html ).
python falls into the same category as LISP, scheme and smalltalk: incredibly incredibly powerful.
it is very difficult to write unreadable code in python, for two key reasons:
1) the indentation method
same number of tabs (or spaces) indicates a block - FORCES programmers to make their code "tidy". many programming languages are absolutely xxxxing awful and impossible to read due to inadequate use of white space.
2) compactness and elegance.
key to python's readability is the lack of messing about and the use of english words. LISP, SCHEME and SMALLTALK were all developed when space was at a premium. so, you kept the source file small by using as obtuse-as-possible a syntax.
by the 90s, this was completely unnecessary, and so languages like python are not only highly readable, but also due to having similar OO capabilities as the other elegant languages (lisp, scheme, smalltalk) you can do more with less code.
result: less code on-screen, therefore you don't end up wading through pages and pages of code.
overall... there's just really... no comparison to any other programming language.
_especially_ java.
Java isn't going to die any more than C. Nor will Python or Ruby die any time in the foreseeable future.
Anyone can play Devil's Advocate and make one language look better than another from some point of view, but the fact is, different languages have their different pluses and minuses. I'm sure Ruby and Python have their pluses, but I don't see them being used NEARLY as much as Java. And take into consideration that Ruby has been around just as long as Java and Python has 4 years on both languages. If they were going to kick Java's ass, it would have happened by now.
I suspect the article is wishful thinking (though I can't read it 'cause the site didn't survive this post). I don't know why people have to make such a big deal about this stuff anyway. Languages evolve and new languages and paradigms will be created in the future. Computer programming is still in its infancy. There's a good possibility that 20-30 years down the road, none of these languages will be around. They may be completely replaced by some far more powerful paradigm we can't even imagine yet.
These kinds of predictions are old and pointless.
What's wrong with Java? Sure I can't slap together a web 2.0 site in 1 day like I could with .net 3.0 or Ruby, but they can't enable a high availability transactional based middle ware system. Java has so many great uses beyond simple web apps, it will always have a place in the enterprise and mobile devices.
You may find my appearance and demeanor foolish, but it is you who plays the fool.
A good programming language allows you to
solve your programming
problem with a minimum of effort.
Solving your problem means a lot if different things.
In my opinion, software that forms the foundation of other software should be strongly typed. Maintenance becomes a nightmare without such typing.
For end-programmer applications, I would think that anything that allows you to be done as quickly as possible is best.
No exception. If any of them were any good, there wouldn't be so many. They suck primarily because the computer itself is fundamentally flawed [blogspot.com]. Computer science has shot itself in the foot and now that parallel programming is all the rage, the computer industry is paying the consequences. It's time for all of you old computer geeks to retire. You messed up big time. There is a better way to design and program computers. Now is the time for the industry to wake up and stop listening to failed ideas.
Will someone please tag this article as a troll?
Some privacy policy Slashdot.
The trend line for Java, C and C++ is down.
The trend line for Visual Basic is up.
It looks like the VB line will intersect the Java line some time around 2015. Then, obviously, Visual Basic will be considered a better language than Java because it is higher on the graph.
How is the article's author going to explain that?
From the initial take, the intent of the article could easily be construed to say Java will die. But I thought was interesting that it would be from old age, not from some challenger language.
In many regards, concerning its lifetime, C has been/will be around for a very long time too... Which, I think, is probably one of the signs of a good language. Because if it was so horrible/people could not get their stuff done reliably, no one would use it.
Languages tend to be popular, in my opinion, as a result of functionality. I use Delphi which had a huge following the first years of its development. C++ has always had a strong following also, both due to the enormous amount of free instructions and components available on the web. There is almost nothing that I have not been able to do with Delphi because of the vast amount of information with examples in news groups. Java is not an easy language to learn. I have found that even trying to use examples that have been modified don't work.
I am not a developer. I don't know all the insides of Java, C#, C++, Python or Ruby. Yet, I have to use these languages and other tools on a daily basis to make a living as somebody who works in the field of integration and system engineering. Programming languages for me are just like tools. I would like to use something that is easy to learn and that gets a job done. That's why I hate C++ and that is why I see Python and Ruby pushing Java out at least in many areas where performance and ability to multi-thread are not the top priorities.
Please spare me the inner details of every language and pros and cos and what is pure object oriented and what is not. I get paid to accomplish things and not to debate about the purity of a programming language. In the environment where you have to make two applications and throw one away, Python really shines. It is a great language for prototypes. It is easy to learn, relatively fast for what I need to do and it can be hooked up with Java or C++ without too many issues. The way I think about it, a language is like a tool. Many years ago everything had to be done by hand and then we developed power tools. I know some purists who love to build furniture and other objects using old school approach (no nails, just glue and hand work). Good for them. I like to use the latest tools that are proven to make my work easier. I don't doubt that Java will be alive and well many years from now, but it is very refreshing to have other high-level alternatives.
Consider a much earlier example of a math-like language: APL. It allowed concise programs and elegant expression (especially of mathematical ideas, like matrices); it ran in the then-mainstream environment (IBM mainframes); and, it was sponsored by the industry's 800-pound gorilla. And it was the best language for creating write-only programs that I have ever encountered -- think Perl with an extra helping of math and a non-standard character set thrown in. The worst programming assignment I ever had (although I did complete it successfully) was debugging and fixing a financial modeling package written in APL. My take on it was that the programmers who had written it originally fell mainly into two categories:
- Those who were confused by the syntax and concepts
- Those who used the syntax in a contest to see who could be "cutest"
Neither is really what you want going on in an important enterprise-level project."heeeeey ruby" "heeeeey ruby on rails" "heeeeeey web 2.0" and other similar stuff ....
/. for those 'new cool up and coming' languages and stuff, i have been churning out a lot of estores, service and small business sites that used php/mysql as foundation. directly php that is, nothing that has 'development libraries', or 'framework' or anything else. oscommerce, vbulletin, nuke and phpbb versions.
in the last 2 years all those stampede was being made in
the importance of that is, people use these stuff to run their business. and they are happy with it. they are cheap, they are easy to use, they are easy to get, easy and cheap to find developers for, easy for everything, all at once. all these factors come into play for their choice. eventually one or two people come up with requests for development on some nifty up-and-coming 'framework' 'script' or 'platform', but in 1-2 months' time i find them coming back again, this time for migrating their 'up-and-coming' framework store to oscommerce. oscommerce, for example is like microsoft windows now, established, widely used, strong base, strong community, developers, everything and whatnot.
let me tell you, they do not know anything about ruby. they dont know about web 2.0. all they want and need is to have something to run their business on. they dont care about the 'amenities' jumping to another framework will bring them either. they want reliably well established and well known stuff.
the thing is, regardless how much we programmers, developers rant and rave and get excited about 'new' stuff here, praise them or shun them, the market's choice dictates what is going to stay and what is not. and from what i see, market doesnt even know, or even care about ruby, or web 2.0, or any other nifty thing we have been discussing here. they want fast, cheap, reliable, well known and thats that. the only exception is big buck corps, but then again they can afford anything.
Read radical news here
Cached copy:
http://www.google.com/search?q=cache:cjG2pCd9RO8J:littletutorials.com/2008/05/28/13-reasons-java-die-old-age/
Adoption of languages and frameworks is more about being "good-enough" at the right time. The longer a "good-enough" solution stays in place, the more compelling a better solution has to be to unseat it.
Well, the top five languages in the TIOBE index shown on the page are,
It's hard not to turn this discussion into a war and I do believe that even from a qualitative perspective, this discussion is entirely subjective. Let me preface my comments by saying I work primarily in C#, Java, Ruby, and Python in my job, and previously was a C, C++, Fortran, and Assembly programmer. I know about a dozen more languages as well, so I feel I've at least had exposure to many languages to guage success from a developer's point of view. Generally, I think being good at a certain job/task makes a language successful. There is a corollary that one should pick the best tool for the job, not because it's the "best" language. C++ is successful because it was very fast at the time, had a lot of features people wanted, and was relatively easy to learn. Would I do a web page in C++ these days? Probably not.
If I had to pick a language to discuss and deem successful, it would be either Smalltalk or Lisp. Some people find either of those esoteric or "weird," but I rather enjoy writing code in both. Interestingly enough, in many respects neither language is particular successful in a commercial sense, but very much so for most implementations.
I'll stick to Smalltalk because it's a good example for this discussion. It's a case where popularity in my mind is not equal to success. Smalltalk works because it is simple (there are really only 6 keywords or so and not even really keywords at that) and is designed impeccably. If success is related to imitation and admiration, then Smalltalk is up there. Of course in itself, the language is derivative, but it's well-known enough to claim/steal credit for one of the best implementations of existing ideas. I have to laugh at other languages, especially Ruby, Python, C#, and Java as they are adding language features or libraries that emulate things that have existed in Smalltalk for 20+ years. That's rather laughable, but also an indicator of success.
As the Smalltalk saying goes, "Files? How quaint." The language just proves you can design something successful by simplifying and focusing on enabling people to design and use their brains. I feel like I can focus on code rather than language constraints. Smalltalk coding is like teaching them to farm rather than giving them food. There are obvious merits to both approaches. The fact that the language is still around 20+ years later and gaining momentum speaks volumes.
I think what makes it unsuccessful is that a lot of people have no idea it exists in the first place and how it really works. They might look at it and say, "yeah that looks something like Ruby, so what's the point." Usually I find it's lack of understanding of not only Smalltalk, but the fact that the development environment in many ways is the language. Most Smalltalk implementations simply don't have the problems in file-based languages like disorganized code, "too many classes," etc. So many of the plights in other languages don't happen in Smalltalk because of the design and that to me is success, regardless of the number of commercial installations.
Another issues that has halted the language's success in commercial spaces has been ugly UI. Until recently, most implementations have looked awful. Squeak used to look like a child's toy without customizations (still does to some degree, but there's 100s of customized images floating around the internet now). Visual Works looks like an ugly ms-app sometimes, but is a huge leap over the past. Gemstone Smalltalk has no real UI (but can use Squeak). The list goes on, but the point is that even in dev environments, eye candy has a big influence.
It gets even weirder when you look at Smalltalk and languages from the perspective of supporting products. Databases are probably the biggest, and Smalltalk can work with just about everything, but the simple support for the RDBMS is pitiful compared to most popular languages. Especially in recent years, a lot of that has to do with the Smalltalk view. In the Smalltalk world, it seems stupid not to use an object database at this poin
Bertrand Meyer
Object Oriented Software Construction, 2nd Ed., p. 881
Richard Stallman
GNU Coding Standards
Rob Pike
Notes on Programming in C
Linux Torvalds
Linux Kernel Coding Style
Patrick Lynch and Sarah Horton
Yale C/AIM Web Style Guide
Flaming Thunder http://www.flamingthunder.com/ is already starting to push Ruby and Python into old age.
class extended virtual theGreatEarthNovel::theProblemWithProgramming::theProblemWithProgrammingLanguages::theProblemWithJava tpwj{
...I really don't get it when people moan about java.
import inside here now system::ontology::basic::directions::fromAndTo::justToTestYourTyping::andYourNerves::To to;
towards::hardware::ui::screen::virtual::notMobile::notCLI where;
try::reallyHard::butItIsNP::4.times::atLeast:
system::interface::ui::utf::orLess::characters::ifFail(opticalRecognition) message;
message = "Java has no problems";
system::magic::lostMyYouth::expele::towards(to, where, message);
else:
system::core::shit::happens::throw::towards::withMessage("Whoops!");
}
"Reason number 2: Too much noise is distracting. Programmers are busy and learning 10 languages to the level where they can evaluate them and make an educated decision is too much effort."
okay, if you can't bother to learn more than 1 language, then you can't really call yourself a programmer.
If you can read this, I forgot to post anonymously.
I'll take any language that can let me write, read, and understand as fast as the speed of computers is progressing, i.e., exponentially.
I don't give a crap if language xxxxxxx is more efficient, more hardcore, etc. You know why?
Because I don't want to spend a year writing an application in C for efficiency and find out at the end that for a mere $1,000 I could have written the same thing in Python in a month and just bought a faster computer 11 months later.
YOUR time is linear, while the computer's is exponential. You'd be a fool to not take advantage of that and, frankly, type safety, efficiency, platform independence, programming style, power, etc. etc. can all go to hell. Just give me a beautiful language.
Wouldn't it depend on what you're using it for?
So one language may be great for developing and keeping a web server running, but that same language just might suck if you were trying to make a videogame with it. (And vice versa for the language the game is made in.)
And not only is this true for the software being made with it, but also the hardware you're using it on. Some languages just aren't appropriate if you need the program to run fast or on a portable device. And a programming language good at producing streamlined code may not be considered flexible enough for other uses.
The question is too generalized at the moment. It should be: "What makes a programming language successful for (such and such application)." And even then there probably isn't just one good answer.
I was on an old dial up bbs once having a fierce argument and was deep into a paragraph lambasting my foe, when a nearby thunderstorm injected about 4 lines of pure static garbage characters into my text, and the techy walked by, glanced at my screen and said "taking up perl?"
You almost always have to have first achieved mass mediocrity. Some prime examples are McDonalds, MS Windows and last but far from least, Disco.
Java stands apart from the crowd in it's mediocrity. It's a nice language, but it is mediocre. By my estimates, it should go far! Way farther than C/C++ ever hoped.
If for no other reason, even crappy programmers who shouldn't be programming in the first place can put out "okay" code. Those who can't understand pointers, not to mention, understand that a reference is hardly more than a pointer. In otherwords, it can even make crappy programmers mediocre.
-- Many men would appreciate a woman's mind more if they could fondle it
I've got three HSRP'd firewall clusters that don't work with the later versions of java installed on my admin machines. So I have pretty old java installs that I can't upgrade and other legacy issues as a result.
Here I am, full of pride and working regular hours because the HSRP works as promised and yet you get in a tight bind when trying to upgrade the nodes on high-availability systems.
I know the CLI cisco admins are spitting coffee out their noses right now, but in some cases the web gui is faster and easier than cli.
http://www.maxineudall.com/2010/02/should-economists-be-sued-for-malpractice.html
Let's look at what problem Java was created to solve: Java was designed to be C++ without memory problems. This is a big deal, because some estimates have it that over half of C and C++ bugs are related to either allocation / deallocation errors or buffer overruns. To solve this, Java got rid of malloc, free, and pointers (it also dispenses with those annoying C/C++ header files). The one unfortunate side effect is that Java cannot easily make nice with C and C++ - there's lots of hair involved.
Note that Java's original market was programmers familiar with C/C++. Note also that Java has not killed off C or C++. There are some applications where you need to take explicit control of allocation. For example, suppose you are processing video in realtime. You want to track objects through color frames. Each uncompressed frame needs nearly a meg of RAM, so you will allocate about 1.8 GB / minute. If a garbage collector fires up uncontrollably it can create delays that will mess up your processing. For this kind of memory intensive, performance intensive realtime job, you probably don't want Java.
Python does make nice with C/C++. Many fine C libraries have been wrapped in Python wrappers and made callable by Python. This makes Python into a kind of glue language (C# can do the same). You can use Python for things like GUI, parsing, lists, and string handling, and call your C++ routines for performance intensive tasks. Or you can do it the other way around, and embed Python in C++. So Python also markets itself to folks familiar with C/C++ and thus eats into Java's market.
Both Java and C++ are strongly typed, and this is essential for big projects. But for small programs written quickly, strong typing may just slow you down. If, for debugging, you want to change a function to return two ints and a string instead of just one int, in C++ or Java you have to write a class. In Python, you can just return a tuple - so easy! In addition to a glue language, you can treat Python as a scripting language - like Perl only more scaleable (and arguably more readable).
--- Often in error; never in doubt!
hands down, if your programming language doesn't have a GOTO statement, it is a miserable failure
intellectual property law is philosophically incoherent. it is your moral duty to ignore it or sabotage it
How does it feel to go through all the trouble of posting your flames on Slashdot only to be ignored by anyone who cares and laughed at by those who know you're incorrect?
I am completely confused as to how the author can even ask the question "Is COBOL a success?"
Is COBOL old? Certainly.
Is COBOL outdated? Yes.
Has COBOL since been replaced by better languages? Yep.
Would you be insane to start a new, large, application from scratch using COBOL? Of course.
But "Is COBOL a success?" Without doubt, yes. Countless millions (perhaps) billions of lines of production COBOL code are still in use. It is still the core behind many of the applications that run our day-to-day lives. These applications have been running for decades with downtime records that would put an average "Web 2.0" app to shame.
Certainly, IBM deserves a lot of credit for this, maintaining pure 100% backward compatibility for those apps for the last forty years or so, but some credit is due to the language itself.
SirWired
I love you.
I used Java to build my first web app because that is the language I learned in college. I also think Java is the language of choice at lot of universities.
I think you need to consider that there are a lot of new programmers entering the work force each year that have strong Java background.
20 GOTO 10
As you can clearly see,
BASIC is the Best Language of All Time
BASIC is the Best Language of All Time
BASIC is the Best Language of All Time
BASIC is the Best Language of All Time
BASIC is the Best Language of All Time
BASIC is the Best Language of All Time
I don't like Linux. This doesn't make me a troll.
Then it's obviously PHP, as it's the most installed setup at most ISPs/web hosting companies.
It doesn't matter if another language is better, faster or more secure, because if you don't use PHP then you are seriously limiting your hosting options.
Different languages in different paradigms for different uses and programmers. "Success" is not the right word here, most of all languages are successful in their own niche, while some others will not be that qualified but will fit in every project.
But that is just my opinion.
Am I eval()? - http://www.monst3r.com.br
I don't know what does, but I do know what does not.
Using the hash mark in the name of you language doesn't help. C + Hash says Cash to me.
What MS names a language Cash I can only assume that means my cash into their pockets.
Sun. Sun doesn't seem to help languages. Java has issues, most of all the VM. I mean
as a good method of making sure we use our clock cycles and memory 100%, 100% of the
time, sure that's nice, but what else does it do?
Naming a language "Visual Basic" doesn't help at all. It bring up images of people
working with virtual pre-school blocks. Also HyperCard. Sure it could have been the
web, if only they used the network...and Apple supported TCP/IP...and they thought
of the web idea before everyone else...Apple didn't have a bad case of Scalp&Colon
disease back then. But truthfully HyperCard lost because of it's name. It just bring
to mind the image of a playing card out of control(on Fox?).
-- Prepared at the direction of, or to be sent to Legal Counsel, in anticipation of litigation. Attorney Client Pri
I can't believe how many times I have heard java is going to die. I think this talk speaks more to the behavior of people than anything to do with technology. We just think that something has to die. In your daily life, as you cruise around, make bank transactions, call your insurance company, but stuff on amazon, etc, Java, C and C++ are doing 90% of the work. They are going NOWHERE.
Take *that* you young whippersnappers! If you want to program machines, you have to learn to think like 'em.
"My country, right or wrong; if right, to be kept right; and if wrong, to be set right." --Senator Carl Schurz (1872)
Am I the only person who thinks that this old ass language if one of the best? To me, python, ruby, and others are just ideas from lisp.
... what makes a me use a programming language is that someone is paying me to use it.
Beyond that I don't care much. (Well, there are limits, I refuse to do Perl, or Unix shell scripting.)
Regardless of the syntax or the name spaces or variable typing, if it does what you want or surprises you by doing more it will be successful. Another factor is if you have early successes, or good beginning documentation.
PHP, which I do use, does that for me, Ive had many a time times where something pretty complex turned out to be not a big deal using PHP, it just blows me away. Of course I migrated from FoxBase+/Mac so I had a huge leap in capacity, and added complexity (HTML, PHP and MySQL) but it hasn't failed me yet, and that what counts.
As far as my success comment, I tried PostgreSQL early on and it was good and all but I could not get understandable answers on ensuring setup was correct and I struggled with the syntax. Went back to MySQL as it just worked (might try later, but too busy now).
Though PHP works for me it may not work for others, it's not the nice drag and drop of Visual Studio nor is it the one size fits almost everybody of RoR, and those have their appeal as well, just not for what I do.
With the diversity of OSs nowadays I think the overall trend is in general for "cross-platform," not proprietary lock-in. With cross platform, you or people who use your stuff, can pick the platform best suited to their environment/skills/budget/security. MS dropping FoxBase then FoxPro on the Mac and Apple killing OS9 compatibility did it for me, I was on an obsoleted platform running on a dead-ended OS, never again.
"Enjoy what you're doing! If it becomes drudgery, you're doing it wrong!" - Jim Butterfield
The most important aspect of any language is how open it is to incorporating external technologies.
PHP is, by all accounts, a horrible language, but because it can wrap just about anything easily, it ends up being used a lot.
I think what makes a language successful has more to do with how it works outside itself. Ironically, that's why I dislike Java, its focus is java java java. Other languages seem to better facilitate interfacing. (Yes I know about and have used JNI, but other languages are typically better, IMHO.)
...truncated the title at "Suc..." and I was all raring to go with a rant about why programming languages suck. Looks like I got my knuckles all lined up for nothing. Oh well.
There was no #3. Trust me.
It's not a very good article. For one thing, measuring language use by search engine hits is silly. Just because it's the easiest way to get a number doesn't mean anything.
The current situation in programming languages isn't very good. It's been 52 years since Backus invented FORTRAN, and we still don't have it right. Let's look at what we've got.
So that's where we are. No really good hard-compiled language in wide use, and the major scripting languages each have some tragic flaw.
I think C syntax beat out Pascal syntax because C is both briefer and clearer, or just as clear. Particularly, I mean things like "{" and "}" instead of "begin" and "end" for blocks, which is shorter, and friendlier to non-English speakers. Same for "if () {} else {}" vs "if then begin end else begin end", and the extra bit of confusion by allowing "if then stmt;", and the twiddling around they did with that in Modula. Also, operators are richer in C. I don't recall for sure, but I think Pascal does have an equivalent for ++, a clunky function call "inc()". And Pascal has this useless distinction between a procedure and a function. On the other hand, I've never liked C's "switch" structure, especially the part about having to put break statements all over the place. Also, structures have at least one exception to a general rule. In the statement "for (int i=0; i != 9; i++) {}", i is not supposed to be in scope outside of the brackets of the "for" structure, which goes against the simple rule that a variable is in scope from where it is declared to the close of the block it was declared in. But some compilers will incorrectly accept this. gcc did up to about version 2.7. Finally, maybe C's biggest advantage is being the native language the most popular OSes are written in, making it the easiest language to call system libraries from.
Perl is in decline? I'm guessing Perl 6 will reverse that, if they can ever get it out the door. For me, the biggest improvement from Perl 5 to Perl 6 is the ability to just call on external library functions. If I understand Perl 6 correctly, you need only do the Perl 6 equivalent of "#include " and then you can call. In Perl 5, it's a huge pain, and may not work. For each function, you have to tell Perl in a special sublanguage called XS all the details of exactly how many parameters there are, how big each parameter is, the types (great fun if they're massive structures), and order. A reason for this is that such info cannot be gleaned from the library, it is generally only available in a C header file, which Perl 5 cannot comprehend. Or perhaps you try SWIG, and get 100K of generated source code so you can call one lousy function. Many of the Perl modules are nothing more than wrappers on common libraries, where someone else has gone through all the pain of figuring out the XS. Again, what counts here is brevity that doesn't sacrifice clarity. It's critical that a language be brief and clear on the all important interfacing with system libraries.
I wonder if Java is drowning in libraries. Knowing the language doesn't make you a Java expert, you have to know all kinds of libraries. By comparison, C has a relatively small set of core libraries, with stdlib, stdio, and math. One book under 500 pages can cover them all. If you want to do GUIs in C, you can pick from a bewildering number of GUI libraries, from xlib to KDE or GNOME, but you don't have to know any of those libraries to be considered a C expert. Java, though... you'd better keep up with the latest in GUIs, sockets, and such to be considered an expert.
As for C++, streaming was a disaster. iostream is slower, and generally harder to use than stdio. Fortunately, coders can ignore iostream and just use stdio. Its OOP isn't too clean either, with templates and operator overloading. C++ does however integrate nearly seamlessly with C libraries, unlike Perl 5. I found it interesting though not surprising that C is more popular than C++.
A last word about brevity. The manual should be as small as possible, but also as complete as possible. K&R was somewhere between 200 and 300 pages. The Camel book is a little over 1000 pages. I have no idea whether there is a definitive book on Java, or how big such a book would have to be. Some documentation is more like a massive unknowable nest of hypertext the true size of which cannot be computed. Functional fans like to brag about the brevity, and will mention for instance that the specification for the Scheme dialect
Intellectual Property is a monopolistic, selfish, and defective concept. It is "tyranny over the mind of man"
Looks like the slashdot effect is in effect. Only 10 concurrent requests! Crappy webhost plan...
Another set of reasons why some languages survive and some don't may be the types of applications they can be used for.
The C and C++ tool set is *never* going away. You can't, in any practical sense, write an OS in java. C and C++ are *the* standard for writing system level software. Most all system software is written in one of them and they are tightly coupled. There is no other language currently or on the realistic horizon that can replace their functionality.
Java, on the other hand, is popular, but has plenty of practical competition, from C#, to perl, to even PHP. Hell, even visual basic has a VM environment.
As a system level guy, I have little use for Java, C#, perl, or the others except as needed for glue between system level code.
irb> puts 'but ruby is so easy'
...OR...
public class JavaRules {
public static void main(String[] args) {
System.out.println("no...java is better!");
}
}
$javac foo.java
$java foo
And they can't even afford a real web site with more than ten concurrent hits. Real authoritative.
I would say that Java is already successful. COBOL was successful. Ruby, jury is still out. PHP has been successful.
It is really useful.
Hmm. TFA's server must be running Ruby.
Original article: "I recommend to every programmer to look around from time to time and try to understand what is going on the language market." I know you only have a bachelor's degree, because: You: "...you wrote an article to show why Java sucks? Guess what, you have to learn Java like all of us did in order to be successful."
Original article: "...articles about the imminent dismissal of Java and its replacement with...
Go back to college and demand your money back. Your degree is worthless.
Sorry about that.
P.S. I get paid over $100,000 a year to fix what numerous young college kids mess up in our company, and engineer solutions so they don't screw it up in the future.
From the linked page: Maximum concurrency limit of 10 exceeded.Currently serving the following requests: /2008/05/28/13-reasons-java-die-old-age/ /2008/05/28/13-reasons-java-die-old-age/ /2008/05/28/13-reasons-java-die-old-age/ /2008/05/28/13-reasons-java-die-old-age/ /2008/05/28/13-reasons-java-die-old-age/ /2008/05/28/13-reasons-java-die-old-age/ /2008/05/28/13-reasons-java-die-old-age/ /2008/05/28/13-reasons-java-die-old-age/ /favicon.ico /2008/05/28/13-reasons-java-die-old-age/ /2008/05/28/13-reasons-java-die-old-age/ /2008/05/28/13-reasons-java-die-old-age/ /2008/05/28/13-reasons-java-die-old-age/ /2008/05/28/13-reasons-java-die-old-age/
If you are the owner of this website, you may need to upgrade to a more advanced plan.
Yup... pretty ironic
For those who can't access the article:
There's this neat website called "Google". It goes around on the Web and takes snapshots of webpages. Then it caches the snapshots so that you can do searches and find all kinds of neat stuff.
For example, if I go there and type "13-reasons-java-die-old-age", I can look at a really nice snapshot of the original article- no worries about the Slashdot effect, because they have a really powerful infrastructure! Check it out: http://www.google.com/search?q=cache:cjG2pCd9RO8J:littletutorials.com/2008/05/28/13-reasons-java-die-old-age/+13-reasons-java-die-old-age&hl=en&ct=clnk&cd=2&gl=us
return reduce(lambda b,c:(lambda x:(lambda r=sys.stdout.write(chr(x)):x)())(c+b), [32,40,29,7,0,3,-67,-12,87,-8,3,-6,-8,-67,-23])
Despite the suspiciousness of parent post, the link is a good one and not a trap.
I've tried a lot of languages and still keep
searching for a new faster, better, easier one...
but i keep going back to Tcl/Tk. It's amazing
how fast you can code something useful with it.
obviously we should use whatever fits the task
upon us... I would never code an fft on Tcl/Tk.
Any way, IMHO I think a mixture of high level
like tcl/tk python, ruby, etc... mixed with a low
level when needed (c, c++, even ASM!) is the way
to go.
my humble 2c
Python is very useful with C (or C++) as a quick way of building up GUI.
When you code the calculation heavy stuff in C but keep the rest in Python scripts the code is cleaner, flexible and easy to maintain/understand. Also you don't have to recompile it, most of the times (unless you gotta touch the core stuff).
I wouldn't use it alone, but a C/Python hybrid is better than Java.
Patents Drive Free Software as Hurricanes Drive Construction Industry
For example:
:) and the itertools package. Map et. al. need not be first class citizens any more.
[int(x) for x in '1 2 3 4 5 6'.split() if x in '135']
does a filter and map at the same time. And then there are the wonderful generators
Judging from C, it's making giving the programmer complete control. A lot of people want/need that.
Judging from PHP, it's taking everything including the kitchen sink and wrapping it into the interpreter, so that any schmoe with very little knowledge can whip out a web app quickly, without regard to security issues. A lot of people want that.
Judging from Basic, it's making it easy to learn. A lot of people want that, too.
I guess the ultimate answer is that a programming language is successful when it appeals to a need or a want in a significant section of people. But should that really be that hard to figure out?
Oh, you're not stuck, you're just unable to let go of the onion rings.
Not knowing what exactly "COSA" was, I did the sensible thing and wiki'd it.
Much to my surprise, it redirected me to an article on Sex Addicts Anonymous (I kid you not, try it yourself: wiki COSA).
Upon seeing this, I can't see how it will help computing at all. Hardcore programmers aren't supposed to get laid at all, let alone get laid so much it becomes a problem. But then maybe that IS the problem, maybe all the REAL programmers are off bonking so much, they don't have time to write a decent C++ library for perfect multithreading....
+1 IDisagreeSoHeMustBeATrollOrAnAstroturferOrAShill
Javadoc, reflection, String class pretty much cover all of what you just did. And they all offer features richer than the basic ones provided by Python.
I have used many, many languages from Java to Objective C to Scheme to Ruby to PHP. Python is the only modern one I specifically avoid. Sorry, had enough of whitespace dependent code with Fortran, it cramps my style.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
For example, C++ is a language that should be dead. It's got so many horribly insecure ways of doing things, worst of all the zero-terminated string. On a good number two comes all the array operations and such where you can read out of bounds until you crash and burn. Plus the countless opportunities you get to shoot yourself in the foot with pointer arithmetic without auto_ptr and other good practises. Why doesn't it die? Because the libraries evolve to fix things like this. Personally I use Qt so QString and QByteArray means I don't think I've ever written a buffer overflow into any of my applications. What's holding languages back are features you just can't implement through libraries, like new keywords or other fundamental constructs. C++ misses a few I'd very much like to see, but we'll see. I think older languages will persist much longer than people think, even the flawed ones.
Live today, because you never know what tomorrow brings
When I click on the provided link I get..... Maximum concurrency limit of 10 exceeded.Currently serving the following requests: /2008/05/28/13-reasons-java-die-old-age/ /2008/05/28/13-reasons-java-die-old-age/ /2008/05/28/13-reasons-java-die-old-age/ /2008/05/28/13-reasons-java-die-old-age/ /2008/05/28/13-reasons-java-die-old-age/ /2008/05/28/13-reasons-java-die-old-age/ /2008/05/28/13-reasons-java-die-old-age/ /favicon.ico /2008/05/28/13-reasons-java-die-old-age/ /2008/05/28/13-reasons-java-die-old-age/ /favicon.ico /2008/05/28/13-reasons-java-die-old-age/ /2008/05/28/13-reasons-java-die-old-age/
If you are the owner of this website, you may need to upgrade to a more advanced plan.
has been Slashdotted!
But then maybe that IS the problem, maybe all the REAL programmers are off bonking so much, they don't have time to write a decent C++ library for perfect multithreading....
Like I said, opinions are like assholes. Maybe you should call Intel and Microsoft and tell them that you solved their multithreading parallel programming problem and that there is no need for them to keep funding Berkely and the University of Illinois at UC. Tell them to give you the money instead.
All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
What's purple and commutes? An Abelian grape.
Ok, I'm going to chime in on this. What makes a good programming language is Strong Typing, Bounds Checking, strong compiler time checks and easy maintainability. One of my favorite languages was Ada, back in the 80's, because it made it very difficult to write bad code. I also used a version of GCC called EGCC which did the same sorts of checks and added run time checks, but it also never caught on. Coming from a Quality Assurance background, Ada satisfies the Maintainability, Portability and Reliability requirements. I was very happy to program in it after coming off Pascal and Modula-2. Marc
Nice list, but I would add 'scalability'. An app might perform like the bejeezus for ten people. Everyone likes it, so more people start using it. Can you support hundreds, thousands, tens of thousands of simultaneous users? Can your app leverage multiple cores? Multiple independent servers?
I think that most folks who claim their favorite language of the day is "easy" typically aren't concerning themselves with very large deployments. Try deploying your application to a half dozen multi-cpu multi-core servers working in coordinated fashion with each other and multiple databases and you might rethink your definition of "easy".
I agree w/ the pp's point that there are necessary trade-offs between various languages. My pet peeve are the inexperienced programmers who have never had to confront problem X (e.g. scalability) who nonetheless blithely assert the superiority of their chosen language. Talking trash is fine, but when you see this ignorance translated into actual projects, that people pay money for, that are poorly constructed around someone's favorite programming idiom, then there's a real problem.
Can we say COBOL is a successful language?
If you don't know the answer, you're too young to ask the question. Yes, the language that still runs the majority of the world's transactions is successful. Infoweek or Computerworld or one of those trade rags recently ran an article in which they noted that on a daily basis, there are an order of magnitude more transactions run through COBOL programs than what Google handles.
Dumbest. Question. Ever.
Advice: on VPS providers
-compiles to native code
-type interference
-minimal syntax
-multi paradigms
-batteries included
-great name
That would be my perfect language. I'd call it Perfect Python and "just" add OCamls type interference and native code to Python3k.
Also to add another quote since i saw the Knuth one already:
There are only two kinds of languages: the ones people complain about and the ones nobody uses.
-Bjarne Stroustrup
Most of my code is written for and used by me. For embedded/dsp stuff, I use C. For almost everything else, I use Python.
... No, I think that's why we quit trying to code everything in assembly iirc.
The reason I started using Python was that one of Sun's programmers wrote a memo saying that Java wasn't actually that good for what they were doing. He suggested Python as viable alternative. (I'm not sure the memo was 100% authentic.) http://developers.slashdot.org/developers/03/02/09/1347215.shtml?tid=108
One of the things I like best about Python is that it is very easy to write self-documenting code. I can pick up something I wrote a year ago and quickly come up to speed. The parent article makes no reference to code maintenance and ease of documentation. Does that mean that serious programmers don't care about things like readable code. Hmm
Surely, uptime and bandwidth.
/2008/05/28/13-reasons-java-die-old-age/
/2008/05/28/13-reasons-java-die-old-age/
/2008/05/28/13-reasons-java-die-old-age/
/2008/05/28/13-reasons-java-die-old-age/
/2008/05/28/13-reasons-java-die-old-age/
/2008/05/28/13-reasons-java-die-old-age/
/2008/05/28/13-reasons-java-die-old-age/
/2008/05/28/13-reasons-java-die-old-age/
/2008/05/28/13-reasons-java-die-old-age/
/favicon.ico
/2008/05/28/13-reasons-java-die-old-age/
/2008/05/28/13-reasons-java-die-old-age/
/2008/05/28/13-reasons-java-die-old-age/
/
/2008/05/28/13-reasons-java-die-old-age/
/2008/05/28/13-reasons-java-die-old-age/
Maximum concurrency limit of 10 exceeded.Currently serving the following requests:
If you are the owner of this website, you may need to upgrade to a more advanced plan.
It's hard for me to take such an article seriously if the guy can't even host a website properly.
really... the reason Java is so popular is because all Universities use it to teach programming. The student are lazy and when they come out and play in reality they stick to what they know...
My favourite language for quick&dirty app making is Actionscript/flash. No other language comes close in speedyness... You have a vector based paint & sound editing program that can read photoshop files & import just about anything from avi movies to mp3's right next to your code, powered by a nice library... and your app can run in a web page or as standalone on practically all platforms.
So if someone is about to make a new language, check out the flash system and improve on it - Actionscript sure has it's illnesses.
As usual, any 'discussion' regarding programming languages on /. degrades into the following argument:
"A Screwdriver is more useful than a Hammer"
"No way! A Hammer is more useful than a Screwdriver"
In no particular order:
1) Development speed
2) High number of areas the language works well for
3) Low barrier to entry (ease to learn, expense and ease of setting up an initial dev environment to evaluate the language, community support...)
4) Available (cheap) Libraries
5) Industry Buzz
Many languages already have common commands/function - eg print split substr. I'd like to see a standards body codify this. This way switching languages would be easier since they'd share more in common.
Programmers will always use whichever languages they are most comfortable with for as long as they continue to be supported. As long as either a good compiler or an efficient runtime engine exists for output to whatever OS is needed, it makes no sense to switch out to a less familiar language unnecessarily based solely on it's popularity. (Especially where deadlines are concerned...)
However, there is something to be said of using widely known and understood programming languages versus obscure or dying languages in instances where continuous support for a piece of code is required on a regular basis. If more than one person has to be involved, you're better off staying with a mainstream language for the sake of the code's own longevity, even at the cost of time lost to cracking open a language reference every so often.
8==8 Bones 8==8
A lot of noise comes up about these various flash in the pan languages periodicallly, but if you look at a chart of language uses, even python that has been around for 10 years or more has only a few percentage points marketshare.
Meanwhile, Java is the most widely used programming language ever, at around 20%.
http://radar.oreilly.com/archives/2006/08/programming-language-trends.html
Whereas C and C++ hover around the 10 or 20% range.
I use python for some small utilities, and in fact I do expect python's usage to increase over time. However, expecting java or c++ to die, is like expecting English and French to die, and some Esperanto to take over.
It doesn't even *matter* that much if there's some language out there that's so much better than C++ or Java (which is debatable, but functional programming fanatics will scream so loudly about it so I'm not going to bother to argue the point), but that fact that such a vast volume of existing code is written in c++ and java, and there are so many tools and libraries written to support c++ and java development, makes it a *huge mistake* to start some kinds of large software development projects in some other languages, where all of these things will need to be written from scratch at enormous expense.
Projects written in non mainstream languages tend to either fall into a specific program domain the language was designed for, or tend to be very small scale, and usually both. There are very few good *general purpose* langauges that scale up and have good library and tool support. Read: There are *two* of them.... well, three if you consider c#, which I don't, because it is proprietary.
And I think the jury is still out on Java. It's just such a mess even without goto's .
The fact that this site has already tipped over is a good indication of the merits this article must have. Too bad I can't read it. Maximum concurrency limit of 10 exceeded.Currently serving the following requests:
If you are the owner of this website, you may need to upgrade to a more advanced plan.
I am always doing that which I can not do, in order that I may learn how to do it. - Pablo Picasso
1. Small, simple associative arrays. foreach helps too. I've found IronPython at least can do that:
arr = Hashtable()
arr['foo'] = 'bar'
2. Small, simple, self-contained regular expressions, with variable replacement. I haven't seen another language yet that can do this in one command:
$str =~ s/(foo|bar)/$arr{$1}/g;
3. Small, simple standard I/O. Many languages write to STDOUT easily. Few read from STDIN *or* a file this easily:
"while(<>) { &foobar $_; }"
Fewer still let you slurp STDIN, too:
"{local $/; $_ = <>;}"
(T>t && O(n)--) == sqrt(666)
I expect that in the future, the more popular languages:
1) will be disigned to run on multiple platforms
2) will be designed to develop multi-platform apps
3) will be designed to develop browser based apps
Just my WAG.
Tcl "antiquated, primitive and ugly???!?!?" Tcl is a thing of beauty. It's C bindings are unsurpassed in cleanliness. It's event-loop is a joy to behold. You can write some really great things in Tcl.
You could write your example just as easily like this:
l = [int(x.strip()) for x in l.strip().split(',')]
This version is arguably *easier* to read than your map-and lambda-based example. Map and filter are pretty much superseded by list and generator comprehensions (in fact, generator comprehensions allow for transparent lazy evaluation and are heavily used in good Python frameworks). reduce() is easy to provide on your own if you really need it, since functions are fist-class objects in Python, but even so I agree with Guido that explicit accumulation loops are easier to read than most reduce() expressions.
The only thing that I could conceivably miss are lambda functions. They do occassionally make for tighter and more readable code, but locally defined closures serve the same purpose, so again, there is no loss of expressiveness.
Fast, cheap, good. Pick any two!
It's cheap and fast, but it's not good.
It's good and cheap but it's not fast
it's good and fast but it's not cheap.
I got the same wiki about sex addiction. After looking at his crackpot site I found out that this miracle called COSA is just a fancy name for graphical programming and data-driven languages (basically what LabView does.) Or what a schematic diagram does.
Guy clearly never used a schematic diagram or he'd know how painful they are compared to doing the same thing in a normal language like VHDL. Need to add an extra input to one of your functions? UH OH!! Time to tear up all your connectors and sit for 1/2 hour redrawing lines. Same thing would take 5s (literally) in VHDL.
Hopefully, the hospital this guy escaped from finds him and returns him to his cell.
This is such a joke that sometimes I feel like I shouldn't even bother to respond.
FACT:
Java is far and away the best platform for developing almost all serious applications today, for anyone who doesn't want to sell their soul to Microsoft. Here is why (* Indicates a feature not available in any other programming language.):
1. Platform independence
2. Strongly typed
3. Good interface implementation separation
4. Application server independence*
5. Database independence without changing an API*.
6. High-performance
7. Security
8. Distributed Transaction Bindings across multiple resources*.
9. Still the standard for messaging.
10. Can run on all kinds of devices (phone, pda, smartcard, etc.)
11. Runs on more devices than any other programming language in the world.
12. World's best memory management.
13. Cross-Platform native interface (i.e. JNI)
14. More open source applications written in Java than in any other language.
The script kiddies can babble all they want. None of them have ever had to maintain an application in the real world. If they had, they would know that writing large applications in a scripting language is a bad idea. I've yet to meet a Ruby, PERL, or PHP advocate who I would consider to be a good software developer.
Scripting languages have their place and there are definitely some cool apps written in Python (e.g. portage), but there isn't any valid reason to use Ruby, even if you are the most dogmatic fan of the ActiveRecord anti-pattern.
Most people have no concept of what it would take to replace Java and all of the features that Java has. Scripting languages are (at best) still several decades away from getting to where Java is now. In fifty years from now Java will still be the language of choice. You could make a better argument for replacing C, but then why bother? Why not stop being a loser and build something useful instead of tearing down the leader all of the time? The answer of course is that advocates of using scripting languages for serious software development are sexual impotents who can't create anything and they view real creators with hatred and jealousy. If you want to understand why they keep bringing this point up in spite of the obvious superiority of the Java platform, you should read the Mass Psychology of Fascism.
I've done polymorphic functions in Fortran77 with the VAX extensions (widely available) of %LOC and %REF.
Change will come from young programmers and start-ups that don't have much invested in terms of development tools and accumulated knowledge related to the old dominant languages....
over years, leaders will spawn from this group and they will control the thoughts (salaries) of the rest of us mortal programmers, but until then...
I for one welcome our current corporate Java sipping overlords!
The language has to start out exposing lots of functionality of the machine it's to program. Its syntax has to be the most consistent, so new functionality and techniques are more easily learned on the fly. But that's just the entry fee.
The more existing code there is to "just use" (by calling it, simply and easily), the further ahead the language will pull in the competition. The easier it is to get that code, the more that existing code will count. The more documentation and people who answer questions about using the code, the more the code available will get used well.
And that's why I love Perl. It does everything, really everything, but not necessarily all at once. Most programming problems have already been solved in Perl, and usually in as many ways as there are to do it. And there's so many people who can answer the questions, and already have in googlable pages, that it's pretty reliable to get up to speed to do something, and master it quickly - if the programmer is any good.
Now if I could just store my Perl programs' call graph in a relational DB instead of a flat file, and flip the view between flowchart and lexical subroutines/modules, Perl would be nearly flawless. If it could import other languages like Java, Ruby, Python and C/C++, and output concise, efficient Perl to edit, then spit back efficiently revised code in the original language, it would be perfect.
--
make install -not war
This comment is fully compliant with RFC 527.
Java can do this *without class extension* with what are called interceptors. These can be invoked either just before a method is called, just after, or both. You can log, perform timing measurements, or just about anything else. In addition, the class doesn't even have to be annotated with the logging data. Most environments will allow you to specify interceptors without changing your class files or a single line in source code. This means you can add logging without re-compiling or even unpacking your production code.
As for your precious Rails, two words: EJB 3.0. Entity beans don't need to extend from any other class -- although they can if you want them to. You can specify many-to-one, many-to-many, and other relationships with simple annotations. You can ensure that fields are not null and maximum length. Even beyond that, you can make your bean in Groovy, taking advantage of EJB 3's annotations while writing even more succinct code. All of this while still having access to the complete Java API.
If Ruby on Rails works for you, good for you. Keep using it. But it's got nothing that other frameworks on other languages don't have. Python and Django come to mind. Drupal on PHP as well (although I hate PHP with a passion).
- I don't need to go outside, my CRT tan'll do me just fine.
It is a sad fact that many sites that promote JAVA are written in PHP: www.JavaWorld.com www.eclipse.org www.netbeans.org www.myeclipse.com Does this make PHP better, I think not, but it does show that JAVA is a pain to put something up and it is easier, faster and robust enough to program it in PHP.
Wonder which one of the upcoming successful languages his blog was written in...
No, lambda defines an anonymous function with closure. It's simply amazing, and the listing above does it no justice at all, mostly due to the broken way that Python handles lambdas. I'd tell you to check out lambda calculus, but it comes across as hard maths (because, to a degree, it is), but really, it's fantastically simple.
Say you wanted to iterate over a list of numbers, squaring the result, and then adding up the total. This could be done with
Ignore the dashes, I don't know how to indent inside one of those bastards. What this does is take list and maps the lambda to each item (which squares them), returning a list containing all the squares to reduce, which then applies the + operator to all of the items in that list, satisfying our requirement. Three very simple lines in Lisp, a shitload of lines in C.
Do demonstrate closure, let's take map, and make a function that takes a list and adds a number to every item, and then returns the resulting list.
See how we just created a function on the fly, that refers to variables defined locally, but outside the lambda? We can return a lambda from a function that refers to local bindings inside that function as well, if we want. Hell, we can do what we like, lambdas are just objects like anything else. This is closure.
Those two properties, together, are incredibly powerful. It's fantastically easy to make abstractions that are simply impossible in a language without them, unless you're prepared to put up with lots of boilerplate and obfuscation.
Honestly, before I met this fellow, I was wedded to OOP. Now I'm not so sure. I can do OOP with lambdas, but the other way round? Messy, very messy.
How dare you be so modest!! You conceited bastard!!
Given the current trends in processor architecture, a programming language is going to succeed if it will be amenable to effective automatic parallelization (by a compiler).
The server the article is sitting on seems a little overwhelmed. Is there a mirror somewhere?
I love dynamic languages as much as the next guy, but there is one major item that I think make Java shine: explicit typing in the interfaces. No seriously, hear me out.
One of the great things about languages like Python is that you can shove just about anything anywhere provided the method signatures and properties match what's being executed. But what about when you didn't write the code? Plone (for example) has gotten much better, but when developing for it, it was often a PITA to find out what features were available from the return value of a given function or what features you should be putting into an object. Yes, I know, the documentation for that CMS has improved greatly in the last couple of years, but I got burned a few years back. And I blame the language.
With Java and interfaces, the objects and values passed to and fro are all documented by design. Javadoc, as often as people like to malign it, is so much better than nothing at all and worlds better than competing code documentation generators for languages like Python, Ruby, or Perl.
"Just look at the Python object definition," you say? The problem is that coders tend to mutate the object during runtime, adding *public* properties and methods on those objects. In addition, there are often methods and properties that are completely useless to the given job at hand. Are they needed in a given instance? You cannot know by looking at the object definition. You need a published interface for that, and that's what Java's interfaces do.
At less than five thousand lines of code, any language would work except maybe for Brainfuck, but that's a whole other can of worms. Once your codebase grows and, more importantly, gets more people involved in its development, documentation becomes all the more important. No, Javadoc isn't the "end all, be all" solution for project documentation by a long shot, but a hell of a lot better than nothing, and without explicit interface definitions, no automated documentation engine will help one bit with real problems.
- I don't need to go outside, my CRT tan'll do me just fine.
There was some item above I was replying to when I decided to make a larger post...here's the item I was responding it:
It should read only :
map(lambda x: int(x.strip), input.split(","))
But this is easier than you think in java, or perl, or any other language that has regular expressions.
List results = new ArrayList ();
Matcher matcher = Pattern.compile("([^,]+)").matcher(args[0]);
while (matcher.find()) results.add(Integer.parseInt(matcher.group(1).trim()));
Granted, the java version is 3 times the amount of code than the most expressive python version. But it's still not a lot of code, in fact, it's quite concise. And it's a lot more optimizable -- and more strict.
But both of these examples suck, really. Because if you're looking for numbers -- your regular expression should match numbers, and not just try to blindly parse the data as an integer.
And here's the part that really matters
Anyway, I think ruby, python and friends are growing in popularity not because they increase productivity, but because people suck. After all, those ruby folks who hate java also hate XML, and XML is nothing more than a collection of super fantastic technologies built ontop of a common document format where a single parser and parsing framework can be used to represent a myriad of types of data -- how cool is that?
And like any tool, it's only as good as it's user, which precludes that the user using the tool must be using the right tool for the right job, which all too often is not the case regardless of the language. I think the entire world of software engineering would benefit from forgetting about the related philosophical wars related to programming languages, tools, and frameworks and just learn how to use as many of them as possible. Learn as much about them all as possible. And start trying to chose your language, framework, and libraries based on how they solve the particular problem each and every application faces -- which is always specific to the application and it's purpose.
If we chose tools using this pragmatic approach, rather than buying into any given framework, language or library regardless of the problem we would actually have a better cognative ability as an over-all community to be more productive in developing tools, languages and frameworks that meet the needs of specific problems and do that well, and would thus increase our over-all effectiveness as an entire industry.
Of course, that's probably not going to happen.
I used Emacs with Fortran, and that worked OK because it had a good custom mode to control column indenting to the exact degree required. But with python, code behavior is controlled by whitespace in infinite variability - good editors can help, but none of it matters if you've indented something wrong and don't pick up on it, how is the editor supposed to know what is right and what is not? To me braces simply are more readable as far as grouping, AND allow for greater expressivity in coding (as sometimes code is more readable when left flat or indented oddly). It reduces too much flexibility for far too little gain (especially funny that you mention using modern editors since real editors do things like insert brace pairs for you as needed eliminating any potential benefit you got getting rid of them).
I've used many modern IDE's, I tried a few different things with Python and nothing made it tolerable. So I finished what I had to do there, have never looked back, and have been the happier for it.
It seems to me as I touched on before, that you may well not be familiar enough with modern editors and IDE's that do the heavy lifting for you if you are so bothered by code that requires braces.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Your disclaimer is relevant, since you never got to experience most of Sun's big mistakes. Some of them will never go away, like the fact that some of the original library writers didn't understand the difference between byte streams and character streams. But all in all Java has a certain maturity it lacked when Sun was overselling it as the solution to all our problems.
But that's not why Java is in no danger of dying. Like any other software technology, programming languages are subject to lockin, that combination of cultural habits and legacy installations that keeps software around long after it's. Languages seem to be more subject to lockin than other technologies: unless it's a total failure right out of the gate, it soon develops a culture that maintains it, and a big body of software that must be maintained, and is too expensive to rewrite in a more modern language.
Consider FORTRAN. It was the very first high-level language (1953) and is full of design mistakes that reflect a total ignorance of artificial linguistics and compiler design theory by its inventors. (Not the designers' fault, these fields hadn't been invented yet.) And yet it remains the language for heavy-duty numerical processing. A lot of hard science and engineering grad schools rebel when told to learn it, but learn it they do.
Ironic story: I was working for Sun's Java org in 1998, when a corporate reshuffle caused our group to be given responsibility for maintaining Sun's FORTRAN compiler. Everybody's response was: What? Why the heck do we even have a FORTRAN compiler? Answer, the people who buy high-end computers for science and engineering won't even look at your platform if it doesn't have a FORTRAN compiler.
So Java (and FORTAN) will live forever. And centuries from now, newbie programmers will be wondering about those weird classes that are used to handle standard input and output.
Perhaps we have different definitions of "high-performance computing". Doing a fluid-dynamics simulation on a 100+ CPU cluster is high-performance computing. I took a class where they taught it it with C or Fortran and MPI (which has a really awful API, by the way).
Perhaps you mean real-time computing? Java might be up to that in some cases.
(T>t && O(n)--) == sqrt(666)
I'm curious... where can I download an actual functional implementation of this miracle of CS?
Miracles don't come cheap. If they did, Intel and Microsoft would not invest tens of millions in research labs at major universities around the globe (not to mention their own labs) to come up with one. Fork up a few millions dollars and your wish will be granted.
One of the reasons that Java became so popular was that it was new during a time that business was making enormous investments in IT. That time has passed, and business is less likely to invest in new languages, tools, etc, regardless of their merits.
If all you are worried about in C is stdio, stdlib, and math, then comparing that to the entire Java API is hardly fair. In that case, you could tell people to simply limit themselves to java.lang, java.io, and java.util. With just those three packages, Java is simpler to use and faster to learn.
Seemingly as a counterexample, you list off the dizzying array of GUI libraries available for C as proof of its superiority. I consider them to be a gross liability. Not only do you have to learn a GUI library, you have to learn a few to see which one would work the best. Also, picking a GUI library commonly locks you into a certain niche. While GTK+ is making inroads on Windows, it still lags in display performance and has poor integration with the host system if that system is not X Window-based. Qt on Windows or Mac? Definitely not my first choice.
So in expertise, you're right. A C "expert" does not need to know GUIs or databases to be considered an expert. Your assertion that a Java "expert" does need to know these things in all circumstances doesn't diminish Java, it simply means that you are holding the two against different metrics. There are quite a few Java coders out there that don't know AWT/Swing, and yet they are quite expert at server-side work (aka no GUI). I know Java game developers that can barely spell SQL let alone know the intricacies of JDBC or the java.sql and javax.sql packages. Some Java "experts" know the Java class file definition format by heart, while other "experts" do not and yet others limp along with tools like ASM.
You cannot really claim that Java is "drowning" while C's thousands of redundant and competing libraries for GUIs, databases, RPC, networking I/O, file I/O, cryptography, etc. -- with all of their wildly different and often times inconsistent APIs -- are somehow an improvement. That's simply deluded. Java has its faults, but "drowning" in libraries is not one of them.
Take some time coding for ODBC before talking about C's simplicity and utility again. C for most tasks is like using a hacksaw to put in a screw. No, there's nothing wrong with a hacksaw or with the screw. But don't try to ridicule someone for owning a screwdriver just because you can't cut metal easily with a screwdriver.
- I don't need to go outside, my CRT tan'll do me just fine.
Are you saying that such an implementation already exists and simply costs a godawful lot of money, or that it doesn't yet exist, and may never, but my coughing up a couple mill might just speed it along?
This comment is fully compliant with RFC 527.
Python et.al. are all languages that we who were there in the 80's remember with a combined horror/amusement when we had to write programs in Basic.
You have got to be kidding me.
This is a mistake on the order of "Cats are mortal. Aristotle is mortal. Therefore, Aristotle is a cat."
I'm not a particularly big user of Python, but I know enough to know the comparison with Basic is pretty shallow. There's an interpreter, and there's divergence from C syntax. I think that's about it. And there's all kinds of stuff in Python, Perl, Ruby, and even *PHP* that you could never dream of doing in any Basic I saw during the 1980s.
The lack of type-safe variables,
Type safety. Okay. You're one of those people. You're hereby sentenced to read all of Steve Yegge's blog posts for a year.
Alternatively, you're welcome to cite studies indicating higher productivity for type safe languages.
the possibility to write unreadable code
Which language have you found it impossible to write unreadable code in?
hunt for bugs that are caused because two files are incompatible.
Right. Like there exists a language that addresses this problem.
Interpreting languages has been tried before,and they are never working for large projects that shall live for a long time and has to be maintained by a lot of different programmers.
"Implementations with feature X have failed, therefore any implementation with feature X will fail." That sword can be wielded equally well against compiled "type safe" languages.
The fact that a language has an interpreter that implements it really doesn't have much to do with whether or not it can be compiled. Python can be compiled to Java class files, for instance, and probably a few other targets I don't know about. So can Javascript. Probably Ruby, too.
And as for large, sustainable projects You're posting on a system that's over 10 years old that's built in Perl. You've probably bought books or something else from a bigger site that uses it too. I've worked on a system that predates Slashdot that had a codebase that was 10% Perl and it's still going strong. This is to say nothing of highly visible examples of development in PHP of all things.
I have nothing against compiling when the situation demands it, and I can respect the fact that automatic tools for catching certain kinds of mistakes are helpful. That's not really a function of type safety, however. Ask Perl or PHP (and probably the others) to warn you if you've misspelled a variable or done other "bad" things with it, and they will, for example. But moreover, it's been a long time since most of the mistakes in my programming had anything to do with whether or not I fed the right variable the right type of primitive or reference, and I suspect the same is true of most experienced programmers.
Tweet, tweet.
Unfortunately, I wasn't born with a silver spoon in my mouth. Nobody can design and create a new CPU, operating system and a set of graphical dev tools in their spare time. Otherwise, we would not be having this conversation.
Labview and schematic hardware diagrams already exist. Cosa is nothing new or innovative.
A language with the cyntacks of C and the string-handling floo'n'C of Visual Basic -- oh, call it "Flamingo" -- that's kewl.
Hmmm... I seem to have found Argument, I was looking for Abuse... I'll try down the hall.
Labview and schematic hardware diagrams already exist. Cosa is nothing new or innovative.
Labview is data flow visual programming language that uses threads and a script language, AFAIK. COSA is a thread-less, control flow software construction and OS model in the tradition of synchronous reactive languages. Nobody is claiming that COSA is new although several aspects of it are. In fact, the COSA site/blog repeatedly emphasizes that the parallelism of COSA is not rocket science and has been around ever since programmers began to use 2 buffers and a loop to simulate parallelism in such applications as neural networks, cellular automata, video games and VHDL. Notice that threads are not needed and thus none of the problems associated with multithreading exists in COSA. What is new is the claim that this form of parallelism is what computing should have been from the start and that it is the answer to every problem that plagues the computer industry from unreliability and low productivity to parallel programming and multicore processor design. Read the COSA Saga for more.
Depends I suppose. There are multiple worlds at play here. In one corner, there are the new kids just coming into programming, those on small teams, web developers, thrill seekers. They are looking for languages that offer minimal keystrokes, neat features, quick prototyping (rails!), minimal configuration, etc.
For these people, maintainability isn't really even a remote consideration. For them the critical measurement seems to be the ratio of:
(functionality * fun cleaver features) / (keystrokes * prototype dev time)
They often get bogged down in their own code after the first few releases, but the people who started the project and chose the language are often off to another by this time, and if not they rarely even recognize the additional time spent to repair something later. (and to tell you the truth, if you used prototype development speed to sell the project and delivered the initial prototype and the customer bought it, there is a valid argument that they did the right thing even if it moved time and problems to later in the project cycle)
Another very large (and very quiet) group is more interested in a formula like this:
(Maintainability * Stability * Consistency * Comprehensibility) / (cleaver features ^ 2)
Note that there is absolutely no concern for how much you type here. Typing speed has no relationship whatsoever for how long it takes a large project to come out--it's an inverse relationship in fact. Having to learn something new just to save a few keystrokes is a huge negative (multiply learning time by the 500 people on your team, it becomes like a manyear per feature easily)
This group is huge--it's virtually every team I've worked with, and, of the ones I've known, maybe 2% twitter, blog, read blogs or listen to podcasts. They are not involved in the community, they just work and go home to their families. They are typically comfortable with Unix and A few read
They are generally developing in pre java-6, and often pre java-5. Sometimes because they have to, but often because of stability and huge retesting requirements to ceritfy a new development tool.
In my realm they are almost always Java or C++, although the latter is getting more rare. I'm sure in windows they are almost all using C#.
They usually aren't interested in learning about other languages or complicating the one they are using (although they will use the features if available).
This group ranges from uncreative programmers who struggle with concepts like OO or Generics or (in some cases) pointers and boolean math to are excellent all-around programmers; and many used to be in the first group.
Most are just good programmers that want to go home at 5:00 and spend the night with their families instead of jumping straight on the computer to learn a new technology.
Personally I think this latter group is quiet enough that the industry writers, bloggers and podcasters don't realize they exist, but I'd guess that they are at least 70% of the programmers out there.
If it wasn't for Java and C#, they would probably be using ADA or C++. Ruby and Python would never be considered.
A better way to look at the situation would be to ask yourself, "In properly formatted code, what purpose do braces serve?"
If you consider this a while, you may decide that the answer is "None.".
"Not an actor, but he plays one on TV."
s = re.sub(r'(foo|bar)', lambda m: arr[m.group(0)], s)
This particular example fits Perl's chunking a little better. For the other side of the story, consider
$str =~ s/($foo[bar]/$arr{$1}/g;
which no real person understands. (What kind of variable is 'foo'? Is 'bar' are bareword? ...)
3. Small, simple standard I/O. Many languages write to STDOUT easily. Few read from STDIN *or* a file this easily: "while(<>) { &foobar $_; }" for line in fileinput.input(): foobar(line) Fewer still let you slurp STDIN, too: "{local $/; $_ = <>;}" That's either sys.stdin.readline(), sys.stdin.read(), or sys.stdin.readlines(). My Perl is rusty from lack of use."Not an actor, but he plays one on TV."
"Not an actor, but he plays one on TV."
I think I wrote my last Basic in 1983. Take my word for it, Python may have it's problems, but it's nothing like Basic.
"Not an actor, but he plays one on TV."
I hope that if I ever write something like this, someone will point out to me how clueless I sound. :-)
"Not an actor, but he plays one on TV."
Not every big library is bloated. It's only bloat if it has a poor size to functionality ratio.
For example libc is small, but it does not include XML parsing, HTTP support, SHA1 and MD5 sums, the ability to read compressed files etc. Sure there are libraries for that, but you have to pick and add them yourself. So libc is small not because it is amazingly efficient, but because it is limited in scope.
Personally, I like big standard libraries like Java and Python have. You pay for it in the initial install, but once that is in place, your application has access to a huge amount of functionality without having to add a lot of external dependencies.
Easier to code, easier to read, easier to maintain.
You type a lot less code to get things done, due to a mixture of dynamic typing, significant whitespace and a huge number of well designed, readable, high-level libraries. You pay a potential performance hit for all the sweet abstraction, but you worry about lower level optimisations in the rare applications/places where it matters. In practice this saves a huge amount of time.
What's more, the basic paradigm is actually the same as the C/C++/Java set, so it's very easy to learn if you're working from these languages. One thing I agree with in the article is that people are extremely resistant to taking up a new programming paradigm, for example a functional or logical programming approach.
I think scala has the potential to be the next Java. It is very modern but still has a C like syntax. Scala programs can be much more terse and expressive than Java. Scala has closures, much more powerful static analysis, and so on. The strictness of the type checking makes most variable declarations redundant.
James Gosling is on record saying that scala would be a good replacement for Java.
It compiles down to the Java VM.
The next big thing will be powerful like python & ruby, but will be strongly typed. Programmers prefer strongly typed: it catches bugs at compilation time and it is easier to write IDE's for them with autocomplete and such.
You're mistaken about the meaning of "dynamic typing." To put it simplistically: a dynamic type system is one where the type of the object or value bound to an identifier can only be known at runtime; or, in other terms, any variable may be set to any object of any type. Static typing, conversely, is when the types of the values bound to the identifiers is known at compilation time.
Python doesn't have the ability to "create new identifiers implicitly" any more or any less than C. In both languages, the implementation can statically analyze the code at each block to determine which identifiers are used in that block, and generate code that preallocates them in a stack frame. In both cases, which identifiers are used in each function can be determined from static analysis of the code. To make it dead simple: the Python parser, when parsing a function, can enumerate every single variable used in that function, just as well as a C parser can do the same for a C function.
A third example that's "in between" C and Python: OCaml is statically typed like C, but most identifiers are introduced without type declarations, like in Python. This is because OCaml has type inference; it can figure out the type of (nearly) all expressions and identifiers at compilation time.
And yet a fourth example, just to make the concept of static vs. dynamic typing more subtle: Java's type system has both static and dynamic components. Each identifier in a Java program must have a declared type, but all identifiers may be bound at runtime to objects of a subtype of the declared type. The declared type of the identifier provides a compilation-time guarantee that the values of the identifier will belong to a set of types; still, the objects must carry around type tags, and many operations require checking the tagged type of the objects at runtime.
Are you adequate?
Successful is not necessarily "good"by academic or theoretical means. Needed things:
1) A application niche, which is not fully occupied yet, where this language brings an unique advantage. E.g. perl (unify shell scripts with sed/awk). E.g Python (lighweight scripting in applications, with suitable syntax for easy (but solid) construction of iterations. Java (Cross-Plattform distribution). etc...
2) Easy to learn. usually this means either orthogonality in the features in the language (python, tcl) or a vast collection of the languages it is going to replace (perl). Usually new languages are accepted and used if they make life in some aspect easier in the very moment.
3) Supported by some larger organization or by an active community. A good head programmer reacting on bugs, feature requests and weigthing them off.
4) Usually: free implementations are needed. Or at least a good students program.
The key to understanding that code is to understand the <tt>reduce</tt> function. How many times have you written loops that look like this?
:= init_value := operation(value, result)
define do_thing_to_list(list) {
result
for ( value in list ) {
result
}
return result
}
I think it's a really safe bet that you write loops like that all the time. Well, reduce is just a higher-order function that abstracts that exact pattern. To sum a list of numbers, you just reduce over it with addition as the operation, and 0 as the init_value. To get the product of a list of numbers, same thing, but with multiplication and one. To concatenate a list of strings, you reduce it with the string append function and the empty list. The pattern is pervasive, and abstracting it makes code easier to understand.
GP's example is deliberately obfuscated, because in good code you just don't use reduce to do character-per-character I/O where the string of characters to output is expressed as a constant list of integers offsets that tell you how to calculate each character's ASCII code as an offset of the previous one. That is just an obfuscated way of printing a constant string.
Are you adequate?
Eliminating pervasive null pointer exceptions is a trivial language design problem. It's as simple as this: (a) a variable of type Foo is never allowed to be null; (b) if somebody needs a nullable variable that may point to a Foo, then that variable must be declared with a different type: nullable Foo; (c) provide type conversions between plain and nullable types. It's trivial for the compiler to reject programs where a plain Foo variable can ever be assigned null. After you have that property, you have a compile-time guarantee that NPEs can only happen when converting from a nullable Foo to a plain Foo.
Are you adequate?
I've also mostly developed in C (on embedded systems), among other languages (Verilog on FPGAs, for example). At work, I chose Ruby (could have chosen Python, but found Ruby more expressive). I would have considered Java more seriously if the company I worked had more than one development engineer (me) and had a more rigorous engineering style (at the moment, virtually none). So I'm sort of hacking on the fly. It's a large app, for me, possibly the largest scope for anything I've undertaken before. But I could not have done it in C/C++/Java - customers don't know what they want, so much pie in the sky features they desire. With Ruby I've been able to meet deadlines and even implement their crazy ideas without as much pain as I would have had with Java. So there you go. Java can thrive in properly engineered, bureaucratic apps with the resources to support that deveopment style. Ruby thrives in a more ad-hoc, rapid development. You may even consider it a prototyping language (in fact, I have done that once: knocked up a prototype web interface for an embedded project for the customer to confirm what they wanted. Then it took two months to do the same thing in C). If you can't see the merits (and pitfalls) of where dynamic languages are useful, you need to play with them more ;-)
wanna-be "oldies look-alike"
try to get respect by knowing old stuff
You don't seem to be very clear on the differences between strong vs. weak type systems, and static vs. dynamic types.
Python is strongly typed. In every place where a Python program can have a type error, the result is defined: some sort of exception is raised immediately, and can be handled regularly through the exception handling system, or to propagate uncaught and kill your program immediately and in a clean fashion.
C is weakly typed. Many kinds of type error can happen at runtime that will leave your program in an undefined state, which may continue indefinitely. E.g., you can do pointer arithmetic and read data from random locations in memory, and interpret it as any type you want instead of what it's supposed to be.
Python is a dynamically typed language. A valid Python program may not contain enough information to infer the type of the values that are assigned to its variables at runtime; or, in other words, any variable may be assigned any value of any type, values in Python must be tagged with their types at runtime, and Python runtime systems need to check the types of arguments at runtime are compatible with the types of the operations applied to them.
C is a statically typed language. The C compiler must be able to determine, at compilation time, the type of every variable, and every expression must type-check for a program to be valid. The way C ensures this is by requiring type declarations on every variable and function. However, that's not essential; languages like OCaml and Haskell are smart enough to infer the types of most of your variables and functions without declarations.
Now, having said all that, let's quote you:
The main problem with this statement here is that you're not specifying what you mean by "context" here. There are two kinds of context that could be relevant: (a) compilation context; (b) runtime context. As it turns out, Python (because of dynamic typing) is allowed to use (b) to figure out the type. However, a language like OCaml can also "figure out the type by context," in the very different sense that it can analyze the program well enough at compilation to figure out that the variables are bound to ints, without your telling it. (And to make it more complicated: an implementation of a dynamically typed language is not required to check types at runtime in every case. A technique used by optimizing compilers for dynamically typed languages is to perform incomplete type inference on programs, figure out the types of variables as best as possible, and use this information to remove runtime type checks where the compiler can prove that they will always succeed. See this blog post for examples of people who've tried to do this for Python in various ways.)
The phrase "multiply an Int by a String" turns out to be ambiguous. Most of the people who responded to you thought about it in terms of syntax: "foo" * 7. The thing is that Python overloads the * operator, and dispatches it to different concrete operations, depending on the type of the arguments. What Python does do is, when applying a concrete operation, throw the type errors.
But also, that is not what the term "duck typing" means. Read your own link. What you're mentioning is just plain old dynamic typing--raise a type error at runtime when the tagged type of the arguments does not match the type required by the operation.
Are you adequate?
Perl.
"Go ahead, take a bit of the apple. There is more than one way to do it."
Next thing you know there are two naked Perl programmers standing around, who quite sensibly made the decision to cover up because "naked Perl programmer" is a scary, scary concept.
Help poke pirates in the eyepatch, arr.
Because I took the time to learn Perl.
How about /@foo[bar]/? What are the possibilities?
That depends what $foo contains. What if it ended with a single backslash?
What if $foo's value ended in a single backslash?? Would that matter here?
Obviously I'm not very knowledgeable about Perl, but I believe my larger point is being made here.
"Not an actor, but he plays one on TV."
I don't see you saying anything about what those "good ideas" are... maybe you don't have any yourself?
I've just started a new project at work. I was told what it needed to do, and left to fill in the blanks myself.
My boss suggested I have a look at a system that did some of the things we want to do. It's clearly not the answer to our problem, but does some interesting things with python and twisted. A bit more digging suggested django as a web application framework. So that's how I'm doing it: python, with twisted to talk to stuff on the network and django to serve up a web-based user interface.
I've worked with tomcat and java server pages, but wanted to try something new. Preferably solving a real problem. See if experience had come up with newer, better ways to solve the old problems. So far, it looks good.
At least for me python is more successful than java, because it was my choice when starting a new project. If nothing else, I've sexed up my resume a bit. :-)
...laura
Marketing
If enithin kan gow rong it whil. (Murfey)
Many languages are popular because they were the first (or the first usable) language to fill a niche.
... where uniformity across all web-clients was particularly important (that is why vbscript never made it on the client side).
... all show the signs of competing for the C (and C++) programmer mindshare. They are not aimed at functional programmers (unless Javascript subtly is).
... first occupier of a niche, building on existing skills, but extending that power into new areas ... that is popularity.
Look at the longevity of Cobol and Fortran - they started the business language and scientific language niches. They still run heaps of applications - they still have some momentum, decades after they were first mooted as languages.
PHP took out the server-side web page niche; Javascript took out the client-side web niche
Secondly, many languages built on the popularity of the existing languages. Java is more popular than (say) lisp/scheme/etc - regardless of how wonderful they are - because it built on top of people's C skills, and was an incremental change, rather than an entire new way of thinking.
Look at Java, Javascript, PHP, C#, Python
So
I am anarch of all I survey.
You have completely neglected Ruby, which leads me to think that maybe you do not know much about it.
.NET languages invariably have been.
The article accused it of having syntax borrowed from Perl, but that is highly debatable. Ruby borrows much of the good from many of the interpreted languages available today, without carrying over much of the bad, and adds a few really slick tricks of its own. Overall, that makes a pretty damned good mix.
None of the objections you raise about the other languages above apply to Ruby today. So... don't you think that deserves attention?
It is a much higher-level language than C or C++, with easy to use syntax and none of the memory leaks that make C and C++ so awful so often.
It is not grossly bloated as C# and other
There are many excellent Ruby libraries (plugins and "gems"), and Ruby can easily import just about any C-language library out there. Score a big one for Ruby! Existing work keeps on working, and that eliminates any advantage C might have had other than raw speed.
It is a dynamically typed language, and so does not suffer from many of the strict limitations of Java. Libraries have already been addressed.
MAJOR plus: Ruby "mixins" have the advantages of both single- and multiple-inheritance for objects, without the headaches of either.
Like Perl, the Ruby syntax is terse, but unlike Perl, it is elegant and quite readable.
Matlab is NOT a "general-purpose" language. It might have been expanded from its roots to encompass the minimum Turing-machine, but that does not mean it is suitable as such. In any case, Ruby can import the C-language libraries (already written) that will do most of what MatLab does now.
Javascript also meets the minimum standards of a general-purpose language, but... let's get real. That's not what it's for, and if you are using it for that then you are missing the boat.
Admittedly, as a dynamic language nobody has yet managed to compile it adequately, so it must be interpreted. But that is the same limitation shared with all high-level dynamic languages. Flexibility and functionality come at a price.
An old good friend of mine who died in his 90's last year and over the course of his life worked on every computer he could get his hands on (I have seen a small fraction that he still has) told me that a successful programming language is one that you can learn, not use for 20 years, and then come back to and still remember how to use it. If it passes this test, it is as easy to use as a spoken language, and that makes it successful.
How does one measure success?
The most successful language I know would have to be befunge93. It set out to be difficult if not impossible to compile and was an outstanding success. The facts that it's used to develop exactly 0 projects on Sourceforge and that there are no compilers are testament to this.
I don't therefore I'm not.
self.it's self.got self.a self.better self.object self.model self.than self.Java
Nobody can design and create a new CPU, operating system and a set of graphical dev tools in their spare time.
Maybe you underestimate the human spirit?
Don't forget having quality, accessible implementations available. Everyone hated Javascript for a real long time because the only implementations available were bad, and locked up inside browsers which didn't really work as good development tools.
...loaded with flames. Even I the levelheaded one started to get hot when he complained about python indenting (it makes your code more readable dammit!) .
But I refuse to bite any more...except I though indenting was stupid too but now i seeeeee.
Nevermind these arguments are pointless...but the decline of perl is obvious. I couldn't even read my own code after 2 weeks.
and so on.
I'm guessing that you're Louis Slavain. You say that the computing industry needs to listen to you, but you're hard on the ears. That's not going to warrant you much success. Academia will be much more likely to discuss your proposals if you patiently listen to criticism and defend against it without engaging in personal attacks. Don't respond to the laughter or harsh words of others with harsh words of your own; professionals will not respect you unless you can maintain professionalism even when your opponents don't. You can support your ideas intensely without being uncomfortably intense on your audience. If you channel your personal drive into productivity rather than ranting, you will find followers much more quickly.
You do have some interesting ideas. I think that many problems in computing can be answered by some of the reactive models that you are developing for fine-grained parallelism, but the days of algorithms and functions are not numbered. You might also want to investigate large-scale asynchronous systems whose individual modules are only locally synchronous; to me, it seems like some of your ideas can be compared to the way that nature works on the scale of chemical reactions and particle interactions, which might be synchronized locally on very small scales (e.g. "Planck time") and exhibit some large-scale emergent synchronization but don't indicate any general dependency on nor tendency toward large-scale synchronization.
Yes, time "travel" seems an unlikely possibility. I would suggest you study the philosophical writings of Peter van Inwagen; he has written a number of responses to the ideas presented by David Lewis about the nature of time and relativity.
I would also encourage you to implement more examples of COSA systems that achieve useful goals, then start writing introductions to COSA for people coming from the algorithmic and functional points of view. In actuality, COSA may have more in common with functions (although not necessarily Functional Programming as it is generally taught) than you think. Have you ever conducted an extensive survey of the difference in approach in Scheme versus Lisp? Lambda functions and tail-recursion can often be easily optimized to collapse complex, nested Scheme code into a straightforward iterative sequence; in a similar way, similar transformations may show some classes of functions to be readily changeable to COSA systems. Mature Lisp systems often exploit modularity to automatically implement some coarse-grained parallelism, which is another interesting transformation worth examining.
--TheOrangeSquid Is it any wonder things seem so awry? We swim in a sea of confusion and don't have to think to survive
Someone mentioned COBOL and wondered if it was 'successful' or not; well I believe it was. Just look at the lines of code as a guide. Opinions differ on languages, mostly with bias towards your 'first' one! Personally I always believed PL/I was the best of all languages, it combined the best of COBOL, FORTRAN (Formula Translation for you young pups) and assembly level coding. It was all things to all people and became very popular in the Banking and Scientific circles. Unfortunately, IBM released it before it was really ready for 'prime time' and the compiler errors created a 'bad feeling' with a lot of programmers (back in the day when programmers made their own decisions). Anyway, I'm an old fart and don't believe we have made much if any progress. Just try to read some of the code sets created today. Most are unstructured and unfathomable as to any real base logic flow. I don't care which one you select, there is no real training with basic program logic flow. Most programmers today are 'self taught', which is admirable, but do you want a 'self taught' surgeon to take out your appendix or do a valve replacement on your heart? Most companies rely on these 'self trained' programmers and typically get what they pay for. I wrote an article on this that can be viewed at: http://www.msc-inc.net/Documents/wrong_turn_in_computing.htm. Cheers, Skip Stein Management Systems Consulting, Inc. 800.856.3193
Skip Stein Free Agent Management Systems Consulting, Inc. http://www.msc-inc.net www.linkedin.com/in/skipstein
Make a typing mistake in C and your programs crash at best and behave strangely and unpredictable at worst. At least in Python you will get a human readable exception.
Why is it that people keep churning out articles on why language x is better than Java and will someday displace it as the language of choice? Specifically everybody thinks their scripting language of choice is better. Certainly scripting languages have advantages, but I still prefer strongly typed languages for enterprise applications.
I couldn't imagine what our current app would be like to maintain if it was written in Ruby or Python. I'm sure somebody will respond and tell me how much cleaner the code would look and how it would be 1/3 smaller, etc. but smaller isn't necessarily better. Years ago we did away with using line of code counts to evaluate programmer productivity and learned to value quality over quantity. Some companies still consider good design and maintainability to be better than churning out huge amounts of code.
Java certainly isn't perfect but then again neither is any programming language. Personally I enjoy programming in Java, and despite its flaws, there isn't another language I'm really interested in learning right now, except maybe Scala. The only scripting language that has caught my eye is Groovy, mainly because it is basically Java syntax.
What I don't understand is how COSA is any simpler to program in than any other programming language. I just don't follow why using a graphical language is any more or less helpful than flow charts.
Maybe COSA is good because it forces people to use flow charts... but I don't see how it brings programming "to the masses."
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]