The advantages of Java is that it easily serves as a lingua franca - everyone can read a Java program and understand what is going on. User defined macros destroy that property. Every installation or project can (and will) define its own set of macros, that make their programs unreadable for everyone else. Programming languages are cultural artifacts, and their success (i.e., widespread adoption) is critically dependent on cultural factors as well as technical ones. .. Most Java developers are happy to have dedicated, narrowly focused solutions that are tailored to a specific problem. I am keenly aware of the drawbacks of such an approach, but I don't see it changing very quickly.
Does this mean lesser power in abstraction and dumbing down programmers in an attempt to get a wider audience for your language (aka Language For the Masses - LFM) ? Paul Graham, in one of his rants against OO, mentions about the pack-programming world of discipline-imposing languages being oriented to social packs.
Do you think we are going through a change in the Java Culture and that Sun has changed its position on LFM over the last couple of years ? And how much it has got to do with the Ruby (r)evolution ? We have had the whole slew of features in Java 5 and now we are talking about adding on closures in the language and tail calls and tuples in the VM ..
6 comments:
I'd say that the overall Java culture isn't changing, but the fringes of it are. The few Java programmers I know socially aren't aware of generics, nevermind closures.
Gilad Bracha makes a good point badly. Java allows you to write a mini-language by defining your own classes and methods - you can end up with things like persons.sortBy(age).printTo(file), etc. That kind of API is great, but possible to screw up. All you need to do is include some bad names:
customers.remove(olderThanTenYears).printTo(file)
In some programmer's heads, remove will actually remove old customers. In others it will act as a filter, producing a new list with only the customers newer than 10 years old. That kind of thing gives bugs.
Macros are subject to the same problem that classes and methods are - badly named macros can be very confusing, perhaps more so than badly named classes and methods. I think that a typical novice programmer would use macros badly, but I also think that is a good thing - because once they have learned how to use macros badly, they can spot their own problems and move on to using them well. Macros used well add more to a language than classes and methods can.
In short, Java plus macros would make it harder for a company to use novice programmers, but would give more rewards once those programmers had improved.
Personally I think the programmer is more important than the company.
Caveat: Smalltalkers apparently don't miss macros - perhaps using Smalltalk for a while would make me revert some of the above points.
Ricky -
Do I get a strawman argument in your comment ? It is possible to design mini-languages in Java using classes, methods, fluent-interfaces. But we will always miss the elegance that higher order functions have brought to functional languages. DSLs are possible , to some extent in Java, but I prefer to call those DSLs fluent apis (as Apache Camel provides today). Java is surely not the best language to build DSLs. Any advanced language feature can be misused by a poor programmer, and macros are no exception. Sometime back Neal Ford blogged about open classes in Ruby, which also suffers from that apparent drawback of the strawman argument. To prevent such misuse u need to have policing from within the language, which Java and most statically typed languages do. Not that there is anything wrong with it! The huge community of Java is partially due to this Java Culture. I was just wondering if movements like Ruby has anything to do with the introduction of some of the exotic features in the Java platform.
Debasish,
I think you said the same thing as me in that comment. I would err on the side of giving programmers freedom of expression, because with some training they'll produce better code that way, and be happier.
By the way, if you are going to implement such shackles, you can do it through source analysis - it doesn't have to be part of the language you're using. That lets you turn it off easily when you realise it's retarded, too.
The main problem I see is that Java has already been tainted with generics and @tags that render code unreadable.
Try to understand some code using generics and you will see what I mean...
What is it?
Also what is this?
@doIt
void m1()
If we continue to add functionality to something that is already complex, I bet we are going to end with a langauge as complex as C++, in which you can now receive pairs of objects from a function.
I mean, come on!
C++ is a serious language or is it an scripting language?
I think we are confusing things here.
When you are doing some scripting it is ok to fail. The system underneath is prepared and has been designed for script writers to write sloppy code.
That is not true for C++ programmers.
And yet the syntac of pair in C++ makes me code more, makes the program more confusing, and is equivalent to retrofit C++ with "you no longer need to declare variables".
Non sense!!!
Because you can do that in perl or Awk doesn't mean you need to do the same in C++.
Yet compiler writers seem to have feature envy and try to pack and cram the languages we love with the features of languages we are trying to avoid.
I think something changed. Now is acknowledged it's good to integrate with the native(s). Java in Open Office, Java and gnome or on the windows desktop, COM objects and Adobe Reader, flash driven by java, 3D bindings etc.
At last, java culture looked out of its borders.
情趣用品,情趣用品,情趣用品,情趣用品,情趣,情趣,情趣,情趣,按摩棒,震動按摩棒,微調按摩棒,情趣按摩棒,逼真按摩棒,G點,跳蛋,跳蛋,跳蛋,性感內衣,飛機杯,充氣娃娃,情趣娃娃,角色扮演,性感睡衣,SM,潤滑液,威而柔,香水,精油,芳香精油,自慰套,自慰,性感吊帶襪,吊帶襪,情趣用品加盟AIO交友愛情館,情人歡愉用品,美女視訊,情色交友,視訊交友,辣妹視訊,美女交友,嘟嘟成人網,成人網站,A片,A片下載,免費A片,免費A片下載愛情公寓,情色,舊情人,情色貼圖,情色文學,情色交友,色情聊天室,色情小說,一葉情貼圖片區,情色小說,色情,色情遊戲,情色視訊,情色電影,aio交友愛情館,色情a片,一夜情,辣妹視訊,視訊聊天室,免費視訊聊天,免費視訊,視訊,視訊美女,美女視訊,視訊交友,視訊聊天,免費視訊聊天室,情人視訊網,影音視訊聊天室,視訊交友90739,成人影片,成人交友,美女交友,微風成人,嘟嘟成人網,成人貼圖,成人電影,A片,豆豆聊天室,聊天室,UT聊天室,尋夢園聊天室,男同志聊天室,UT男同志聊天室,聊天室尋夢園,080聊天室,080苗栗人聊天室,6K聊天室,女同志聊天室,小高聊天室,上班族聊天室,080中部人聊天室,同志聊天室,聊天室交友,中部人聊天室,成人聊天室,一夜情聊天室,情色聊天室,寄情築園小遊戲情境坊歡愉用品,情境坊歡愉用品,情趣用品,成人網站,情人節禮物,情人節,AIO交友愛情館,情色,情色貼圖,情色文學,情色交友,色情聊天室,色情小說,七夕情人節,色情,情色電影,色情網站,辣妹視訊,視訊聊天室,情色視訊,免費視訊聊天,美女視訊,視訊美女,美女交友,美女,情色交友,成人交友,自拍,本土自拍,情人視訊網,視訊交友90739,生日禮物,情色論壇,正妹牆,免費A片下載,AV女優,成人影片,色情A片,成人論壇,情趣,免費成人影片,成人電影,成人影城,愛情公寓,成人影片,保險套,舊情人,微風成人,成人,成人遊戲,成人光碟,色情遊戲,跳蛋,按摩棒,一夜情,男同志聊天室,肛交,口交,性交,援交,免費視訊交友,視訊交友,一葉情貼圖片區,性愛,視訊,視訊聊天,A片,A片下載,免費A片,嘟嘟成人網,寄情築園小遊戲,女同志聊天室,免費視訊聊天室,一夜情聊天室,聊天室
Post a Comment