Java Ekosisteminde Neden Visual Studio Gibi 'Monolitik' ve Native Bir IDE Yok?

AssemblyMilitanı · Dün 05:44

Selamlar, Java geliştirme ortamlarını (IntelliJ, Eclipse, NetBeans) Visual Studio (C++/C#) ile kıyasladığımda büyük bir felsefe farkı görüyorum. Visual Studio; derleyici, hata ayıklayıcı, profil oluşturucu ve çerçeve entegrasyonu konusunda işletim sistemiyle tam uyumlu, "monolitik" ve aşırı optimize bir dev gibi hissettiriyor.

Java tarafında ise hangi IDE'yi kullanırsak kullanalım; oluşturma sistemlerinin (Maven/Gradle), farklı JDK sürümlerinin ve çerçevelerin IDE'ye sonradan "yama" yapılmış gibi durması beni rahatsız ediyor. Java dünyasında her şeyin bu kadar ayrık olması, bir noktadan sonra "çerçeve cehennemine" ve yapılandırma yorgunluğuna yol açıyor.

Sizce Java için sadece kod yazmaya değil, tüm ekosisteme (düşük seviyeli analizden dağıtıma kadar) tam hükmeden, Visual Studio kalibresinde "yerli" bir IDE gerekli mi? Yoksa Java'nın doğası gereği bu parçalı yapıya mahkum muyuz?

xgravity · Dün 10:06

İyi de VS'de arkada dotnet.exe'yi kullanıyor ve sürekli bilgileri ondan çekiyordur yani. dotnet paket indirir, onları çözer. Zaten .Net SDK, JDK'nın geliştirilmiş çakması, dotnet ise gradle veya maven çakması ağla.

Ayrıca IntelliJ ne güzel onlarca farklı yazılımı, birbiriyle entegre edip konuşturuyorsun. Yazılımcı olduğunu hissediyorsun

.

bitwise · Dün 15:03

Herhangi isletim sisteminde gelistirilebilecek ve herhangi bir isletim sistemine deploy edilebilecek Java gibi multi-paradigm, GP dillerin IDE'lerinin de OS agnostik olmasi gerekiyor.

Fazla framework, build sistemi, JDK olmasi pozitif bir sey. Ayni JVM versiyonu icin farkli implementorlarin bulunmasi da pozitif bir sey. JDK Comparison

Sonucta enterprise ihtiyaclari karsilayacak yazilim gelistiriyoruz ve her yazilim birden fazla component in bir arada uyumlu calisacak sekilde engineer edilmesiyle calisiyor. Elbette farkli ihtiyaca gore build tool, lib, framework, VM, GC, versiyon, infra tercih edilebilir olacak.

Dogru olan bu. Microsoft gibi bir firmanin kendi urunlerine destek vermeyi oncelikli kilmasi nedeniyle bazel gibi bir nimeti .NET projelerinde kullanamiyor insanlar. Halbuki kotlin, go, java dunyasinda kutur kutur build aliyoruz.

xgravity · Dün 15:20

bitwise dedi:
Herhangi isletim sisteminde gelistirilebilecek ve herhangi bir isletim sistemine deploy edilebilecek Java gibi multi-paradigm, GP dillerin IDE'lerinin de OS agnostik olmasi gerekiyor.

Fazla framework, build sistemi, JDK olmasi pozitif bir sey. Ayni JVM versiyonu icin farkli implementorlarin bulunmasi da pozitif bir sey. JDK Comparison

Sonucta enterprise ihtiyaclari karsilayacak yazilim gelistiriyoruz ve her yazilim birden fazla component in bir arada uyumlu calisacak sekilde engineer edilmesiyle calisiyor. Elbette farkli ihtiyaca gore build tool, lib, framework, VM, GC, versiyon, infra tercih edilebilir olacak.

Dogru olan bu. Microsoft gibi bir firmanin kendi urunlerine destek vermeyi oncelikli kilmasi nedeniyle bazel gibi bir nimeti .NET projelerinde kullanamiyor insanlar. Halbuki kotlin, go, java dunyasinda kutur kutur build aliyoruz.

Hocam anlamadım ama Java daha iyi diyorsunuz siz de

.

bitwise · Dün 18:14

xgravity dedi:
Hocam anlamadım ama Java daha iyi diyorsunuz siz de .

Bence C# burun farkiyla daha guzel bir dil. Ama Microsoft bu farki gecersiz kiliyor. Kotlin varken ikisini de tercih etmem

xgravity · Dün 18:29

bitwise dedi:
Bence C# burun farkiyla daha guzel bir dil. Ama Microsoft bu farki gecersiz kiliyor. Kotlin varken ikisini de tercih etmem

Ben Java derken aslında tüm ekosistemi seviyorum yani. Kotlin'de Java ekosisteminde sayılır. Çünkü bytecode'u çevirdiğin zaman Java Class'a dönüşmüş halde duruyor.

Ama Kotlin'de kafamı karıştıran çok şey var ya da farklı bir programlama bakış açısı lazım.

AssemblyMilitanı · 52 dakika önce

@xgravity @bitwise

Java'nın C#'tan daha iyi olduğunu düşünüyorum ve sizin cevaplarınızı okudukça şu gerçek daha da netleşiyor: Java gibi devasa bir gücün, Visual Studio gibi "her şeye tam hükmeden" bütünleşik bir ana kumanda merkezine sahip olmaması aslında Java'nın potansiyelini prangalıyor.
C# dünyasında Visual Studio, bir geliştiricinin ihtiyaç duyacağı her şeyi (derleyici, bellek analizi, paket yönetimi) tek bir gövdede, işletim sistemiyle tam uyumlu bir "katedral" gibi sunuyor. Java tarafında ise biz hala "özgürlük" adı altında parçaları birleştirmekle uğraşıyoruz. İşte bu yüzden Java'nın C#'tan üstün olan o devasa ekosistemine, Visual Studio kalibresinde bir IDE'nin neden şart olduğunu şu üç noktada özetleyebiliriz:

1. Entegrasyon Bir Lüks Değil, İhtiyaçtır

Java'da Maven, Gradle, farklı JDK'lar ve profiler araçları IDE'ye sonradan eklenmiş "eklentiler" gibi davranıyor. Visual Studio'da ise bu araçlar yazılımın omurgasıdır. Java'nın C#'tan daha güçlü olan çoklu platform (multi-platform) yapısı, IDE'nin bu kadar "parçalı" durmasını gerektirmez. Aksine, bu kadar karmaşık bir dünyayı yönetmek için "yerli" (native) hissiyatı veren, her çarkı birbiriyle mükemmel dönen bir yapı şarttır.

2. Düşük Seviyeli Analizde "Yamalı" Çözümler Yorgunluk Veriyor

C# geliştiricisi, Visual Studio içerisinde işlemciyi ve belleği en ince ayrıntısına kadar izlerken bunu "doğal bir özellik" olarak kullanıyor. Java'da ise en iyi IDE olan IntelliJ bile bazı düşük seviyeli analizlerde bizi harici araçlara veya karmaşık konfigürasyonlara yönlendiriyor. Java'nın çalışma zamanı (Runtime) C#'tan daha köklü olsa da, bu gücü izleyecek "tam teşekküllü" bir kumanda paneli olmayınca, o güç bazen elimizde patlıyor.

3. Konfigürasyon Yorgunluğu Mühendisliğin Önüne Geçiyor

Java'nın esnekliği harika; ancak bu esneklik, geliştiricinin vaktini "neden bu kütüphane IDE ile düzgün senkronize olmuyor?" sorusuyla harcamasına neden olmamalı. Visual Studio tarzı, her şeyi içinde barındıran ve hatasız çalışan bir yapı olsaydı; Java geliştiricileri yapılandırma (configuration) ile değil, sadece "yüksek mühendislik" ile ilgilenirdi.

Java Ekosisteminde Neden Visual Studio Gibi 'Monolitik' ve Native Bir IDE Yok?

Ayrıntılı düzenleme

AssemblyMilitanı

Zeptopat

xgravity

Centipat

bitwise

Gigapat

xgravity

Centipat

bitwise

Gigapat

xgravity

Centipat

AssemblyMilitanı

Zeptopat

1. Entegrasyon Bir Lüks Değil, İhtiyaçtır

2. Düşük Seviyeli Analizde "Yamalı" Çözümler Yorgunluk Veriyor

3. Konfigürasyon Yorgunluğu Mühendisliğin Önüne Geçiyor

Benzer konular

Bu konuyu görüntüleyen kullanıcılar

Technopat Haberler

Yeni konular

Yeni mesajlar

Gizliliğinize önem veriyoruz

Java Ekosisteminde Neden Visual Studio Gibi 'Monolitik' ve Native Bir IDE Yok?

Zeptopat

Centipat

Gigapat

Centipat

Gigapat

Centipat

Zeptopat

1. Entegrasyon Bir Lüks Değil, İhtiyaçtır​

2. Düşük Seviyeli Analizde "Yamalı" Çözümler Yorgunluk Veriyor​

3. Konfigürasyon Yorgunluğu Mühendisliğin Önüne Geçiyor​

Benzer konular

Bu konuyu görüntüleyen kullanıcılar

Technopat Haberler

Gizliliğinize önem veriyoruz

1. Entegrasyon Bir Lüks Değil, İhtiyaçtır

2. Düşük Seviyeli Analizde "Yamalı" Çözümler Yorgunluk Veriyor

3. Konfigürasyon Yorgunluğu Mühendisliğin Önüne Geçiyor