Java'nın birincil odağı nedir? Yeni özellikler edinmek neden bu kadar uzun sürüyor?


11

JDK8'deki lambda ifadeleri, uzantı yöntemleri ve yeni akış API'si gibi yeni özellikleri araştırıyorum.

Açıkçası, bu özelliklerin hiçbiri programlama dünyasında yeni değildir ve bu neden şimdiye kadar tüm bunları Java'da aldığını merak ediyordu.

Lisp (1958), SML (1973), Haskell (1990), Python (1991), JavaScript (1994), Ruby (1995), Scala (2003), C # (2007) ve Lisp'ten 55 yıl sonra lambda ifadelerimiz vardı ve hemen hemen herkes, Java'da (2013).

Ve SIC'deki (1996) akışları okumuştum .

Neden şimdi merak ediyorum? Kanıtlar, diğer dillerle rekabet etmenin motivasyon olmadığını göstermektedir.

Java'nın bu sürümündeki tüm havalı yeni özelliklerin, paralelliğin uygulanmasının bir yan ürünü olduğu anlaşılıyor. Lambdalarımız var çünkü paralel algoritmalar yazmayı daha basit hale getiriyorlar ve lambda ifadelerinin gerektirdiği değişikliklere vb.

Öyleyse sorum şu: Java'nın bu yayınındaki ana konunun aslında paralellik olduğunu güvenli bir şekilde doğrulayabilir miyiz? Ya da şu ana kadar kitaptaki en eski numaraların Java'da görünmesinin diğer nedenlerini haklı gösterebilir miyiz?


4
Tüm bunlar, Java'nın zamanın gerisinde kalmasına dair bir alev taşıdır.
Michael K

5
The evidence suggests- lütfen araştırmanızı paylaşın.

2
Yok Java veya JVM veya JRE ya özelliklerinden hiç yeni. Ve özelliklerin kombinasyonu bile yeni değil, Eiffel 1985'te bunlara sahipti (GC, OO, tip güvenliği, hatta Java'nın 2003'e kadar alamadığı Generics). Aslında, çok Java'nın bir ekspres hedefi tasarımcıların olmuştur değil yeni bir şey tanıtmak.
Jörg W Mittag

2
@MichaelK - Bunun alev savaşına dönüşebileceğini kabul ediyorum. Bu aynı zamanda Sun'ın zorlu tarihiyle ilgili geçerli bir cevaba dönüşebilir; Oracle'ın Sun ve Java'yı edinmesi; ve şu anda Java kullananların dili nasıl kullanmaya çalıştıkları. Umarım cevaplar bu sorunun yapıcı yönlerine odaklanır.

@MichaelT: Umarım bir alev savaşına dönüşmez ve bazı ilginç fikirler ortaya çıkabilir. Örneğin, sürekli olarak gelişmeyen bir dilin zamanın gerisinde olduğunu varsayıyoruz. IMO bu doğru değildir çünkü dil gelişiminin doğrusal olduğunu varsayar (popüler hale gelen tüm yeni özelliklerin iyi olduğunu ve tüm modern diller tarafından benimsenmesi gerektiğini). Ancak bir dilin koruyucuları, yeni bir özelliğin dilin geri kalanına uymadığına karar verebilir. Ayrıca, kesinlikle zamanın gerisinde olmayan standartlaştırılmış, istikrarlı diller olduğunu düşünün (örneğin Common Lisp).
Giorgio

Yanıtlar:


12

Java ilk kez tasarlandığında anonim işlevlerin dışarıda bırakılması uygun görülmüştür. İki sebep düşünebilirim (ancak resmi olanlardan farklı olabilirler):

  1. Java, işlevleri olmayan bir nesne yönelimli dil olarak tasarlanmıştır, bu nedenle işlevsiz bir dilde anonim işlevlere sahip olmak çok doğal değildi. Ya da en azından bu, dilin tasarımını çok etkilerdi.
  2. Anonim işlevler, Java'nın çekmek istediği programcı topluluklarında popüler değildi (C, C ++, Pascal?). Şimdi bile, birçok Java programcısı bu özellikleri oldukça egzotik buluyor gibi görünüyor (ancak bu muhtemelen Java 8 ile çok hızlı değişecektir).

İlerleyen yıllarda, Robert Harvey'in açıkladığı gibi, Sun'ın politikası her zaman Java'yı geriye dönük olarak uyumlu ve çok kararlı tutmaktı.

Öte yandan, diğer rakip diller ortaya çıkmıştır (en önemlisi, Java klonu olarak doğan ve daha sonra kendi geliştirme yönünü alan C #).

Rakip diller Java'yı iki nedenden dolayı baskı altına aldı:

Etkileyici güç

Yeni özellikler, belirli programlama deyimlerinin yazılmasını kolaylaştırarak dili programcılar için daha çekici hale getirebilir. Normalde bir dil tarafından sağlanan özellikler kümesi, ifade gücü, dil karmaşıklığı, tasarım tutarlılığı arasında bir uzlaşmadır: daha fazla özellik eklemek, bir dili daha etkileyici ama aynı zamanda daha karmaşık ve ustalaşması zor hale getirir.

Her neyse, son birkaç yıldır Java'nın rakipleri Java'nın sahip olmadığı birçok yeni özellik ekledi ve bu bir avantaj olarak düşünülebilir.

yutturmaca

Evet, maalesef bu, teknoloji seçiminde bir faktör, en azından günlük deneyimimde bir programcı olarak görebildiğim kadarıyla: ekibin çoğu üyesi nasıl kullanılacağını bilmese bile, bir aracın belirli bir özelliği olmalı ve Bunu kullanabilenlerin çoğu zaman buna ihtiyacı yoktur.

Hype, belirli bir proje için platforma karar veren yöneticiler gibi teknik olmayan insanlar için daha da önemli olabilir. Yöneticiler bazen sadece lambda, paralellik, çok çekirdekli, fonksiyonel programlama, bulut bilişim gibi bazı anahtar kelimeleri hatırlar ... Eğer seçim teknolojimizin listenin her bir öğesinde yeşil bir işaret varsa, o zaman günceliz.

Yani IMO bir süredir Java arasında

  • dil istikrarı ve tasarım sadeliğinin orijinal politikası, bir yandan büyük bir kod tabanı ve geliştirici topluluğu ve
  • Java programcılarını, önce C # ve sonra Scala, Clojure, F # çekebilecek rakip dillerin baskısı (farkında olduğumları adlandırıyorum, başkaları olabilir).

Sonunda Oracle, Java'yı daha rekabetçi hale getirmek için yükseltmeye karar verdi. Bence, yeni özellikler özellikle C # 'a geçmeye cazip gelebilecek ve Scala ve Clojure gibi diğer dilleri Java'dan çok farklı gören Java programcılarına hitap ediyor. Öte yandan, fonksiyonel programlama konusunda deneyim sahibi olan ve hala JVM'yi kullanmak isteyen geliştiriciler muhtemelen Scala, Clojure veya başka bir dile geçmiştir.

Bu yüzden yeni Java 8 özellikleri Java'yı bir dil olarak daha güçlü hale getirecek ve beyan edilen odak eşzamanlı ve paralel programlama olacak, ancak yükseltme, pazarlama yönlerini de ele alıyor gibi görünüyor (Oracle Java'nın baş mimarı Mark Reinhold, "Bazıları Lambda ifadelerinin eklenmesi sadece havalı çocuklara ayak uydurmaktır ve bununla ilgili bazı gerçekler vardır, ancak asıl sebep çok çekirdekli işlemcilerdir; bunları ele almanın en iyi yolu Lambda'dır ", bu makaleye bakın ).

Yani, evet, birçok (hepsi) Java 8 özelliği zaten iyi biliniyordu, ancak bir dile bir özellik eklendiğinde neden ve ne zaman pek çok faktöre bağlıdır: hedef kitle, mevcut topluluk, mevcut kod tabanı, rakipler, pazarlama vb.

DÜZENLE

"... SIC'deki (1996) akışları okumuştum" ile ilgili kısa bir not: akışları uygulamak için Java 8 lambdas'a ihtiyacınız mı var? Aslında bunları isimsiz iç sınıflar kullanarak uygulayabilirsiniz.


+1 Ve keşke size daha fazla puan verebilsem çünkü bu soruya verilen en iyi cevap bu.
edalorzo

Cevabınıza dayanarak Mark Reinhold'un ilginç bir makale bulduğumu söylediklerini araştırdım. Bunu daha sonra başvurmak üzere cevabınızla birlikte göndereceğim: Mark Reinhold'dan Java için kapanışlar .
edalorzo

Ve bu makale aslında bir diğeri için Java için kapanışları ifade ediyor .
edalorzo

1
Gönderdiğiniz bağlantıdan bu ibm.com/developerworks/java/library/j-jtp03048/index.html#4.0 , Java'nın anonim iç sınıflar kullanabileceğini söyleyerek buldum , ancak bunlar çok ayrıntılı. Yine de, Java 8'in kapatılması sadece anonim iç sınıflar için sözdizimsel şeker değildir. Şimdi Java'nın iki (semantik olarak) farklı kapatma türü olacak: anonim iç sınıflar ve lambda ifadeleri.
Giorgio

11

Java zaman içinde odağı değiştirdi. İlk başta "güçlü kompleks" C ++ 'a tepki olarak basit ve güçlü bir dil olarak tasarlanmıştır. C ++ 'da olan bazı özellikler, operatör aşırı yüklenmesi, şablonlar, numaralandırmalar, C döneminin çok karmaşık olduğu ya da kalıntılarının ve OOP'un popülaritesinin zirvesinde olduğu gibi kasıtlı olarak dışarıda bırakıldı, her şey tek bir nesne haline getirildi. paradigma dünya görüşü. Şu anda Lambdas, Java 1.1'de anonim / iç sınıfların tanıtılmasından bu yana basitçe "gerekli değil" olarak kabul edildi. Sözdiziminin çok daha ayrıntılı olması neredeyse bir özellik olarak kabul edildi .

Java kamuoyunu bulduktan sonra, Java tasarım hataları derslerinden öğrenilen ve bir dizi yeni dil özelliği başlatan C # Microsoft'un tanıtımına kadar değişme teşviki yoktu. Geriye dönük uyumluluk nedeniyle kısıtlanmamışlardı. Java kavramlarının C # yarışması tehlikesini fark ettiğini ve Java 5'i jenerikler, numaralandırmalar vb.İle serbest bıraktığını düşünüyorum.

Lamdaların Java'ya dahil edilmesi o zamandan beri tartışılmaktadır ve sadece fonksiyonel programlama için mevcut eğilim tarafından daha da kötüleşmiştir. Ancak bunun gibi şeyler doğru yapmak için yavaştır ve ilk seferinde doğru olmak zorundadır. Benim düşünceme göre Java, jenerikleri tip silme ile destekledi, çünkü geriye dönük uyumluluk bunu sözdizimsel şekerden daha fazlası olarak uygulamak için bir neden olarak kabul edildi. Kapaklar daha ayrıntılı olarak düşünülmüş, ortaya çıkıyor ve sadece sözdizimsel şekerden daha fazlası olacak.

Sonuç olarak, Java 8'in ana konusu nedir? Bir dil versiyonunun bir konusu olduğunu düşünmüyorum. C ++ 11 olarak, Java 8'in varoluş nedeni, daha fazla programcının şimdi aldığı şeyleri dilde tanıtarak rekabete ayak uydurmaktır. Lisp, 1958'den beri lambda'ya sahip olabilir, popülaritesi on yıllardır yayılmıştır ve sadece son zamanlarda fonksiyonel programlama "ana akım" programlama için ciddiye alınmıştır (daha iyi bir kelime eksikliği nedeniyle).


"Lisp, 1958'den beri lambda'ya sahip olabilir, popülaritesi on yıllardır yayılmıştır ve sadece son zamanlarda fonksiyonel programlama" ana akım "programlama" için ciddi olarak düşünülmüştür: Bir dilin popülaritesi, etkinliği için iyi bir gösterge gibi görünmemektedir. Fonksiyonel programlama yıllardır savunulmaktadır, ancak sektördeki çoğu insan, araştırmacıların doktora tezlerini yazmak için oynamaktan hoşlandığı şeyler olarak düşünmektedir. Şimdi aniden sanayi uyanıyor ve bir şans veriyor, belki şimdi OOP ana akım olduğu için bir sonraki büyük şeyi arıyorlar.
Giorgio

1
Kapanışların Java'ya orijinal olarak dahil edilmemesinin nedeni: Kapanış Tartışmalarını Anlama . James Gossling şöyle dedi: "Kapanışlar, zaman baskısı nedeniyle her şeyden çok Java dışında kaldı. Java'nın ilk günlerinde kapanma eksikliği oldukça acı vericiydi ve bu nedenle iç sınıflar doğdu: kaçınmaya çalışan rahatsız edici bir uzlaşma Ancak birçok tasarım konusunda normal olduğu gibi, basitleştirmeler de herhangi bir problemi gerçekten çözmedi, sadece taşıdılar. "
edalorzo

"Lamdaların Java'ya dahil edilmesi o zamandan beri tartışılıyor ve sadece fonksiyonel programlama için mevcut eğilim tarafından daha da kötüleşti.": Bazı topluluklarda (C ++, Java, ...) "lambdas kullanmak" genellikle " işlevsel programlama yapıyor ".
Giorgio

8

Açıkçası, bu özelliklerin hiçbiri programlama dünyasında yeni değildir ve bu neden şimdiye kadar tüm bunları Java'da aldığını merak ediyordu.

Çünkü Java, "komite tarafından tasarım" a benzer bir süreçte yüksek görünürlüklü paydaşları içeren bir onay sürecinden geçmek zorundadır ve bu süreç zaman alır, hepsi bu.

Diğer dillerle karşılaştırdığınızda ya hayırsever bir diktatör ya da birlikte çalışan ve kurumsal çıkarlara bağlı olmayan küçük bir dil tasarımcıları komitesi bulacaksınız.

Bunu geriye dönük olarak uyumlu kalması gereken milyonlarca satırlık Java kodu kod tabanı ile birleştirin ve buzul hızında değiştirmek için tüm malzemelere sahipsiniz.


1
OTOH, ayrıca gerçekten güçlü ve yaygın olarak kabul gören standartlar için bileşenlere sahipsiniz. Örneğin, JPA'nın, everye web çerçevesinin kendi yarı değerli ORM'sine sahip olduğu PHP'nin durumuyla kontrastı.
Michael Borgwardt

Yanılıyor olabilirim, ancak anlayışım Haskell'in aynı zamanda bir "komite tasarımı" dili ve son teknoloji bir dil olduğudur. Belki de Java'yı engelleyen şey bu değil mi?
Andres

@AndresF. Evet, ama Haskell komitesinde büyük, yekpare şirketlerin olmadığını hayal ediyorum. Ayrıca yorumlarda konuşma bakınız burada .
Robert Harvey

1

Bir programlama dilinin en önemli amacının kullanılması olduğunu söyleyebilirim; şu anda C ve Java'nın lambda ifadeleri yoktur ve bunlar en çok kullanılan dillerdir (örneğin TIOBE'ye göre).

Ve soruyu cevaplamak için Java'nın işletmeye hitap ettiğini düşünüyorum; bu alanda işler çok istikrarlı ve güvenilir olmalıdır; örneğin Java 7 neredeyse 2 yıldır ortaya çıktı henüz Java 7 doğrudan herhangi bir proje bilmiyorum. Ayrıca bir başka önemli şey geriye dönük uyumluluk olan işletme için çok önemlidir.


Sana katılıyorum (+1): Java'ya çok değer veriyorum (dil olarak ve onun büyük ekosistemi için) ama Java 6'da dili dondurmayı daha uygun bulurdum. Öğrenmeye çaba göstermeyeceğim Java 7 veya 8 zorlanmadıkça (Java 7 veya 8'in bir zorunluluk olduğu çok ilginç bir proje), zamanımı Scala ve Clojure öğrenmek için harcıyorum.
Giorgio
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.