Java vs C# C++ C

[KRHN]

Sonuçta byte farkı var. Assembly'de yazı yazdırsak bile C kadar büyük bir boyuta ulaşmaz.

Muhtemelen daha az olur byte farkı lakin 1000-2000 byte farklar değil bunlar. Ufak farklar ve programa neredeyse etki etmeyecek şeyler.

 

[Epistomoloji]

Muhtemelen daha az olur byte farkı lakin 1000-2000 byte farklar değil bunlar. Ufak farklar ve programa neredeyse etki etmeyecek şeyler.

Fakat bakarsanız c ve pascalda aynı işlem yapılıyor, boyut farkını görüyorsunuz.

 

[Life Hunter]

3-5 şeyi tek seferde yapmak demek o 3-5 şeyin tamamını kullanmadan yapmaktır, söyleyin bana. Java da bir yazı Print ederken neyini değiştirebiliyorsunuz, durun ben söyleyeyim ne yazacağını. Lakin Assembly'de değiştirdiğiniz şeylere bakarsanız kendiniz göreceksiniz.[DOUBLEPOST=1437320686,1437320593][/DOUBLEPOST]
Orada mevcut Assembly kodu herhangi bir yazı yazdırmıyor, dikkatinizi çekerim. Zaten performans için Assembly'i öneriyorum fakat o kadar bayt farkı olması pek mümkün değil.

Uygulama yazacak biri neden print ederken bir şeyleri değiştirme ihtiyacı duysun? sistem programlamada kullanılır bu. Uygulama yapacak biri neden bunlara ihtiyaç duysun?

 

[Soketçi]

Görüşlerimi birkaç bölüme ayırarak paylaşacağım. Öncelikle şunu söylemeliyim ki C#, Java ve C/C++ aynı kefede tartışılmaz. C# vs Java olur, C/C++ ayrı bir konu olarak tartışılır. Bu noktada da 2 farklı tartışma var burada, "C# vs Java" ve "High-Level (VM Diller) vs Low-Level".

Konuda gördüğüm ve direk komik bulduğum şu mesaja hemen değineyim, "Hız ve performans dolayısıyla C++ daha iyidir". Bu küçük çocuğun "Bugatti Veyron benim favori arabamdır" demesiyle farksızdır bu söylem. Çünkü bunu söyleyebilecek kişi öncelikle performans ve hız ihtiyacına sahip olmalıdır. Bu da ya bir sistemin core'unu yazıyorsa, ya bir motor/fw geliştiriyorsa ya da embedded yazıyorsa (vb..) olur. Bunun dışında sırf performans ve hız istiyorum diyerek Windows'ta form uygulamasını C# yerine C++'ta hazırlamak bana göre "ahmaklık"tır. Programcının işi çözüm üretmektir, mükemmeliyeti yakalamak değil. Bu nedenle dil seçiminin izleyeceği yollar sorun>çözüm>çözüm için ihtiyaçlar>seçim olmalıdır. Buna da: dosya yükleme sistemi (sorun/ihtiyaç), tcp üzerinden dosya aktarımı yapan uygulama (çözüm), file I/O-socket-forms destekli dil (çözüm için ihtiyaçlar), C# veya Java (seçim) örnek verilebilir.

Ayrıca şahsen C# ve C kullanan birisiyim ve Java/C++'la çok nadiren ilgileniyorum. Bunu söylerken birileri gibi onları kullanamadığımdan, bilmediğimden veya alışamadığımdan böyle bir seçim yapmıyorum. Zaten C# ve Java temelde çok benzer diller. Rahatlıkla Java'da programlama yapabiliyorum, ayrıca uzun süre C++'ta 3D grafik motoru ve fizik motoru da yazdım (buna oyun motoru diyebiliriz) ki sadece küpler çizmekten daha ileriydi bu motorun yaptıkları (GLSL shader'lar, engine API'ı vs). Ve bu deneyimlerden sonra şu noktadayım, eğer high-level bir proje yapacaksam direk C# seçiyorum çünkü Java'ya göre üstün ve gelecekte de en güçlü dil olacak bir dildir (bunu ayrıca tartışabiliriz). Lakin low-level (ki burada az şey sayacağım) yazacağım bazı durumlar olduğunda da C kullanıyorum, bunlara da high-performance socket'lar, protokoller ve serializer'ları örnek verebilirim. C++ bana göre arada kalmış bir dildir. Çünkü low-level'da OOP ihtiyacı bile doğsa C'de function pointer ve struct'lar kullanarak ihtiyacımı rahatlıkla karşılayabiliyorum, high-level işlemlerde de C# C++'a göre daha productive bir dil. Bu nedenle önerimdir ki yapacağınız projeye, programa göre dil seçin. Ben öyle yapıyorum, kafam rahat.

Bu bölümdeki özetim de şudur: programcının işi dil fanatizmi yapmak değil, çözüm üretmek olmalıdır.

 

[EminGny]

Takan olmadığı için 2. kez soruyorum *

sa yazdığım zaman as diyen bi programı farklı dillerde yazın[DOUBLEPOST=1437323863,1437322948][/DOUBLEPOST]Takan olmadığı için 2. kez soruyorum *

sa yazdığım zaman as diyen bi programı farklı dillerde yazın

 

[TheRedstoneEngineer]

Takan olmadığı için 2. kez soruyorum *

sa yazdığım zaman as diyen bi programı farklı dillerde yazın[DOUBLEPOST=1437323863,1437322948][/DOUBLEPOST]Takan olmadığı için 2. kez soruyorum *

sa yazdığım zaman as diyen bi programı farklı dillerde yazın

VB.NET:

Private Sub ButtonSa(...)
MsgBox("AS!")
End Sub

C#

private void buttonSa(...)
{
MessageBox.Show("AS");
}

TAB'ları atmakla uğraşmadım, ... belirttiğim yerler çok uzun üşendim.

 

[KRHN]

Uygulama yazacak biri neden print ederken bir şeyleri değiştirme ihtiyacı duysun? sistem programlamada kullanılır bu. Uygulama yapacak biri neden bunlara ihtiyaç duysun?

Print sadece bir örnek, yazının karakter fontunu, rengini daha benim bile tahmin edemediğim şeyler. Bir de düşün, bu sadece Print ederken. Mesela bir Socket girişi oluştururken veya oraya giriş yaparken?[DOUBLEPOST=1437324419,1437324395][/DOUBLEPOST]

Fakat bakarsanız c ve pascalda aynı işlem yapılıyor, boyut farkını görüyorsunuz.

Ne yazık ki Pascal pek bildiğim bir dil değil, çalışma methoduna göre dillerin boyutu farklılık gösterir.

 

[Life Hunter]

Print sadece bir örnek, yazının karakter fontunu, rengini daha benim bile tahmin edemediğim şeyler. Bir de düşün, bu sadece Print ederken. Mesela bir Socket girişi oluştururken veya oraya giriş yaparken?[DOUBLEPOST=1437324419,1437324395][/DOUBLEPOST]
Ne yazık ki Pascal pek bildiğim bir dil değil, çalışma methoduna göre dillerin boyutu farklılık gösterir.

@Soketçi durumu iyi anlatmış. Ama tekrar söylüyorum, "Uygulama" yapan birinin bu tür şeyleri bilmesine gerek yoktur. Sistem programlamaya girer hepsi.

 

[Soketçi]

Ayrıca @KRHN adlı arkadaşımız da kendisini çok açıkça belli ediyor. Ufak bir analizle şunları söyleyebilirim;
1. Assembly ilah seviyesinde abartılacak bir değildir, C compiler'larında /S parametresiyle rahatça ASM kodlarını görebilirsin. Yazılması ve okunması zor olduğu, ASM'nin zor olduğu anlamına gelmez. Ayrıca ASM tek biçimde yazılan bir dil de değildir, her işlemci mimarisi/yayıncısı farklı ASM dillerine sahiptir fakat genel olarak birbirlerine çok yakındırlar (çünkü kullanılacak method'lar vs ortak sayılır). C'nin ortaya çıkması da ASM'deki farklılıkları ortadan kaldırmak, yazım/okuma zorluklarını gidermek ve evrensel (ve portable) bir dil sunmaktır.
2. Yabancılar görse çok güler muhabbetini de direkt olarak "yabancı hayranı, özenti" zihniyetine vuruyorum. Evet, ben de İngilizce kullanıyorum, ben de evrensel forumları daha yararlı buluyorum fakat bu onların bize gülebileceği anlamına gelmez. Bak burada şimdi ben sana gülüyorum.
3. Her dil aynı binary çıktısı vermez. Makine dili derken ASM anlıyorsan onu da vermez, ha yok ben binary anlıyorum diyorsan o zaten değil. Makine dili olayını şöyle açıklayayım sana, 0 ve 1'lerden oluşan makine dili binary'dir, mov/eax'lardan oluşan makine dili de 8086 ASM'sidir vs. ki bunlar farklı şeylerdir. Konuya dönecek olursam da, C#'ta yazdığın şu kod: "using System; class Program { static void Main() { Console.WriteLine("Hello World"); } }" ile C/C++'ta yazdığın şu program "[HASHTAG]#include[/HASHTAG] <stdio.h> int main() { printf("Hello World"); return 0; }" aynı ASM kodlarına çevirilmez. Sadece printf ve Console.WriteLine bile çevirilmez. Farklı kütüphaneleri, farklı call'ları ve farklı method'ları vardır her birinin. Eğer C# temelde C'de yazılsaydı belki benzerliği olabilirdi fakat Delphi'ye benzetilerek yazılan C#'ın ASM'si emin ol daha farklı. Bunu anlaman için şöyle açıklayayım, aynı artırma method'unu şu varyasyonlarla yazabilirsin: "i++, ++i, i += 1, i = i+1" ve bu 4 kod parçası da farklı ASM kodlarına çevirilir. Bunu bile farklı yapıyorken, tutup da JIT'in derlediği (veya .Net Core'daki Roslyn'in) binary ile GCC'nin (en çok bilinen C compiler'ı) çıkardığı aynı veya çok benzerdir demek tamamen bilgisizlik, havaya boş atış yapmaktır.
4. En iyi dil ASM'dir: kesinlikle hayır. En iyi dil, geliştiriciye işini en kolay yoldan ve en hızlı şekilde yaptıran dildir. Çözüme ne kadar hızlı varıyorsan o kadar iyisin demektir, programlama sorunlara çözüm getirmek için vardır. Saf bilgi yoğunluğuyla mantıksal yargılar sunmak için değil. Burda programlamanın ne kadar da "yararlı ise iyidir/doğrudur" felsefesi güttüğünü görebilirsin.
5. Debugging olarak C++ daha iyidir: Kesinlikle tam tersine C# daha verimli ve daha iyidir. Çünkü her exception System.Exception class'ından türetilir (derive) ve .Net Fw kodu VM'de çalıştırdığı için crash oluşturacak bir durum olsa bile bunu exception'a çevirip fırlatır. Şimdiye kadar aranızda "segmentation fault (seg_fault)" alan var mı bilmiyorum fakat bu hatanın zilyonlarca sebebi olabiliyor. Ayrıca C/C++'ta crash sonrası elinizde bırakın exception'ı dump bile kalmıyor. Sadece kendiniz her kodun başına log atarsanız birşeyler görebiliyorsunuz. Bu nedenledir ki en kolay ve en hızlı debugging C#'ta yapılır.
6. C#'ta 1000 kodda yaptığını C++'ta 1 kodda (veya 1000 kodda yaparsın): Tam tersine C# daha high-level bir dil olduğu için genelde C#'ın wrapping'i C++'takilere göre daha geniştir. Ayrıca .Net kütüphanesinde ihtiyacınız olabilecek (neredeyse tüm) pek çok class'lar hazır bulunur. Hani LINQ'i duyanınız var mıdır veya multi-threading/multi-tasking yapanınız var mıdır bilmem ama C++'ta yazacağınız 300-500 satırlık class'ların sadece keyword (bkz: async-await) olarak C#'ta yeraldığını öğrenmelisiniz

Ayrıca günümüzde karşılaşabileceğimiz pek çok sorunun da çözümü yine C#/Java gibi dillerle yapılmaktadır. Bunun sebebi yine basittir, çünkü high-level diller low-level dillere göre daha kısa yoldan size aynı şeyi yapar. Akıllı geliştirici de o kısa yolları kullanır, gidip tekerleği yeniden icat etmez. Ayrıca işletim sistemlerinin ASM ve C'de yazılmasının en başlıca sebepleri arasında immediate control gelir. Yani sizin tahmin ettiğiniz gibi hız ve performans günümüzde en sonda gelen etkenlerdir. Bugün i7'de 8 milyar transistör var, 15-20 yıl önce 2-3 milyonluk microişlemciler olsaydı haklı olabilirdiriniz ama maalesef diyorum İşletim sistemi yazmakla uğraşan hiç var mı onu da görmedim şu konu altında fakat direk C'de işletim sistemi yazmaya başlamıyorsunuz. Önce kendinize bir bootloader kodluyorsunuz (ki bu işin en zor kısımlarından biri, direk sector okumalar vs), sonra C'deki bazı kütüphaneleri/method'ları ASM'de yazıyorsunuz ve ondan sonra o geçirdiğiniz methodları/kütüphaneleri artık C üzerinden kullanabiliyorsunuz. Hemen bu noktada direk C'de il2cpp gibi bir sistem yazıp C# da kullanabilirsiniz ve C#'la da tüm işletim sistemini kodlayabilirsiniz fakat pek çok sıkıntı meydana gelir. Anlık olarak memory'ye müdahale edemezsiniz, eğer collections kütüphanesini kullanırsanız sadece pointer değişimiyle yapabileceğiniz array/stack/queue/vb işlemlerini gereksiz yere yeni instance veya copy oluşturarak yaparsınız ki bir işletim sistemi saniyede milyonlarca collections kullandığı için o işletim sistemi heralde 1-2 TB (abartıyorum) memory isteyecektir. Tabi bunları C#'ta yine yapabilirsiniz unsafe kodlarla fakat unsafe kodlarla C#'ın yapısını bertaraf etmektense kolayca C (ve ileri düzey OOP için) diline geçiyorsunuz.

Özetle yeniden bir önceki post'umda dediğim şeye değiniyorum: Geliştiricinin işi çözüm üretmektir, saf bilgi mükemmeliyeti yakalamak değil![DOUBLEPOST=1437325406,1437325083][/DOUBLEPOST]

Print sadece bir örnek, yazının karakter fontunu, rengini daha benim bile tahmin edemediğim şeyler. Bir de düşün, bu sadece Print ederken. Mesela bir Socket girişi oluştururken veya oraya giriş yaparken?[DOUBLEPOST=1437324419,1437324395][/DOUBLEPOST]
Ne yazık ki Pascal pek bildiğim bir dil değil, çalışma methoduna göre dillerin boyutu farklılık gösterir.

Öyle bir örnek verdin ki bu bile tezini çürütmek için yeterli. C#'ta socket yazıyorum ve C ile C# arasındaki socket API arasında neredeyse hiç fark yok Heralde hiç socket yazmamışsın

 

[KRHN]

Ayrıca @KRHN adlı arkadaşımız da kendisini çok açıkça belli ediyor. Ufak bir analizle şunları söyleyebilirim;
1. Assembly ilah seviyesinde abartılacak bir değildir, C compiler'larında /S parametresiyle rahatça ASM kodlarını görebilirsin. Yazılması ve okunması zor olduğu, ASM'nin zor olduğu anlamına gelmez. Ayrıca ASM tek biçimde yazılan bir dil de değildir, her işlemci mimarisi/yayıncısı farklı ASM dillerine sahiptir fakat genel olarak birbirlerine çok yakındırlar (çünkü kullanılacak method'lar vs ortak sayılır). C'nin ortaya çıkması da ASM'deki farklılıkları ortadan kaldırmak, yazım/okuma zorluklarını gidermek ve evrensel (ve portable) bir dil sunmaktır.
2. Yabancılar görse çok güler muhabbetini de direkt olarak "yabancı hayranı, özenti" zihniyetine vuruyorum. Evet, ben de İngilizce kullanıyorum, ben de evrensel forumları daha yararlı buluyorum fakat bu onların bize gülebileceği anlamına gelmez. Bak burada şimdi ben sana gülüyorum.
3. Her dil aynı binary çıktısı vermez. Makine dili derken ASM anlıyorsan onu da vermez, ha yok ben binary anlıyorum diyorsan o zaten değil. Makine dili olayını şöyle açıklayayım sana, 0 ve 1'lerden oluşan makine dili binary'dir, mov/eax'lardan oluşan makine dili de 8086 ASM'sidir vs. ki bunlar farklı şeylerdir. Konuya dönecek olursam da, C#'ta yazdığın şu kod: "using System; class Program { static void Main() { Console.WriteLine("Hello World"); } }" ile C/C++'ta yazdığın şu program "[HASHTAG]#include[/HASHTAG] <stdio.h> int main() { printf("Hello World"); return 0; }" aynı ASM kodlarına çevirilmez. Sadece printf ve Console.WriteLine bile çevirilmez. Farklı kütüphaneleri, farklı call'ları ve farklı method'ları vardır her birinin. Eğer C# temelde C'de yazılsaydı belki benzerliği olabilirdi fakat Delphi'ye benzetilerek yazılan C#'ın ASM'si emin ol daha farklı. Bunu anlaman için şöyle açıklayayım, aynı artırma method'unu şu varyasyonlarla yazabilirsin: "i++, ++i, i += 1, i = i+1" ve bu 4 kod parçası da farklı ASM kodlarına çevirilir. Bunu bile farklı yapıyorken, tutup da JIT'in derlediği (veya .Net Core'daki Roslyn'in) binary ile GCC'nin (en çok bilinen C compiler'ı) çıkardığı aynı veya çok benzerdir demek tamamen bilgisizlik, havaya boş atış yapmaktır.
4. En iyi dil ASM'dir: kesinlikle hayır. En iyi dil, geliştiriciye işini en kolay yoldan ve en hızlı şekilde yaptıran dildir. Çözüme ne kadar hızlı varıyorsan o kadar iyisin demektir, programlama sorunlara çözüm getirmek için vardır. Saf bilgi yoğunluğuyla mantıksal yargılar sunmak için değil. Burda programlamanın ne kadar da "yararlı ise iyidir/doğrudur" felsefesi güttüğünü görebilirsin.
5. Debugging olarak C++ daha iyidir: Kesinlikle tam tersine C# daha verimli ve daha iyidir. Çünkü her exception System.Exception class'ından türetilir (derive) ve .Net Fw kodu VM'de çalıştırdığı için crash oluşturacak bir durum olsa bile bunu exception'a çevirip fırlatır. Şimdiye kadar aranızda "segmentation fault (seg_fault)" alan var mı bilmiyorum fakat bu hatanın zilyonlarca sebebi olabiliyor. Ayrıca C/C++'ta crash sonrası elinizde bırakın exception'ı dump bile kalmıyor. Sadece kendiniz her kodun başına log atarsanız birşeyler görebiliyorsunuz. Bu nedenledir ki en kolay ve en hızlı debugging C#'ta yapılır.
6. C#'ta 1000 kodda yaptığını C++'ta 1 kodda (veya 1000 kodda yaparsın): Tam tersine C# daha high-level bir dil olduğu için genelde C#'ın wrapping'i C++'takilere göre daha geniştir. Ayrıca .Net kütüphanesinde ihtiyacınız olabilecek (neredeyse tüm) pek çok class'lar hazır bulunur. Hani LINQ'i duyanınız var mıdır veya multi-threading/multi-tasking yapanınız var mıdır bilmem ama C++'ta yazacağınız 300-500 satırlık class'ların sadece keyword (bkz: async-await) olarak C#'ta yeraldığını öğrenmelisiniz

Ayrıca günümüzde karşılaşabileceğimiz pek çok sorunun da çözümü yine C#/Java gibi dillerle yapılmaktadır. Bunun sebebi yine basittir, çünkü high-level diller low-level dillere göre daha kısa yoldan size aynı şeyi yapar. Akıllı geliştirici de o kısa yolları kullanır, gidip tekerleği yeniden icat etmez. Ayrıca işletim sistemlerinin ASM ve C'de yazılmasının en başlıca sebepleri arasında immediate control gelir. Yani sizin tahmin ettiğiniz gibi hız ve performans günümüzde en sonda gelen etkenlerdir. Bugün i7'de 8 milyar transistör var, 15-20 yıl önce 2-3 milyonluk microişlemciler olsaydı haklı olabilirdiriniz ama maalesef diyorum İşletim sistemi yazmakla uğraşan hiç var mı onu da görmedim şu konu altında fakat direk C'de işletim sistemi yazmaya başlamıyorsunuz. Önce kendinize bir bootloader kodluyorsunuz (ki bu işin en zor kısımlarından biri, direk sector okumalar vs), sonra C'deki bazı kütüphaneleri/method'ları ASM'de yazıyorsunuz ve ondan sonra o geçirdiğiniz methodları/kütüphaneleri artık C üzerinden kullanabiliyorsunuz. Hemen bu noktada direk C'de il2cpp gibi bir sistem yazıp C# da kullanabilirsiniz ve C#'la da tüm işletim sistemini kodlayabilirsiniz fakat pek çok sıkıntı meydana gelir. Anlık olarak memory'ye müdahale edemezsiniz, eğer collections kütüphanesini kullanırsanız sadece pointer değişimiyle yapabileceğiniz array/stack/queue/vb işlemlerini gereksiz yere yeni instance veya copy oluşturarak yaparsınız ki bir işletim sistemi saniyede milyonlarca collections kullandığı için o işletim sistemi heralde 1-2 TB (abartıyorum) memory isteyecektir. Tabi bunları C#'ta yine yapabilirsiniz unsafe kodlarla fakat unsafe kodlarla C#'ın yapısını bertaraf etmektense kolayca C (ve ileri düzey OOP için) diline geçiyorsunuz.

Özetle yeniden bir önceki post'umda dediğim şeye değiniyorum: Geliştiricinin işi çözüm üretmektir, saf bilgi mükemmeliyeti yakalamak değil![DOUBLEPOST=1437325406,1437325083][/DOUBLEPOST]
Öyle bir örnek verdin ki bu bile tezini çürütmek için yeterli. C#'ta socket yazıyorum ve C ile C# arasındaki socket API arasında neredeyse hiç fark yok Heralde hiç socket yazmamışsın

Önceki mesajı görmemişim, ben diyorum ki makine diline en yakın dil en fazla düzenleme yapabildiğin dildir. Sonuçta Java da, C# da makine diline çevirilip yazılıyor. Assembly de aynı şekilde çalışıyor, lakin düşük seviyeli bir dil. Burada bir sorun yok ki çözüm arayalım, bilgilerimiz hakkında tartışıyoruz. Keşke farklı bir hesap açmaya zahmet etmeseydiniz zira burada kavga etmiyoruz, tartışıyoruz. Burada diller karşılaştırılmış, hangi dilin öğrenilmesi basit, hangisi şu proje için diye değil. Düşük seviyeli yazılım dilleri her zaman yüksek seviyeli yazılım dillerinin yaptıklarını yapabilirler, lakin yüksek seviyeli dillerin yapamadığı özellikler olabilir. Bu 3 dil arasından en mantıklı seçim C olacaktır. Üstelik Socketler ile verdiğim örnek C# ile C arasında yaptığım bir kıyaslama değil, C# ile Assembly arasında yaptığım bir kıyaslama.

 

[Soketçi]

Önceki mesajı görmemişim, ben diyorum ki makine diline en yakın dil en fazla düzenleme yapabildiğin dildir. Sonuçta Java da, C# da makine diline çevirilip yazılıyor. Assembly de aynı şekilde çalışıyor, lakin düşük seviyeli bir dil. Burada bir sorun yok ki çözüm arayalım, bilgilerimiz hakkında tartışıyoruz. Keşke farklı bir hesap açmaya zahmet etmeseydiniz zira burada kavga etmiyoruz, tartışıyoruz. Burada diller karşılaştırılmış, hangi dilin öğrenilmesi basit, hangisi şu proje için diye değil. Düşük seviyeli yazılım dilleri her zaman yüksek seviyeli yazılım dillerini yapabilirler, lakin yüksek seviyeli dillerin yapamadığı özellikler olabilir. Bu 3 dil arasından en mantıklı seçim C olacaktır. Üstelik Socketler ile verdiğim örnek C# ile C arasında yaptığım bir kıyaslama değil, C# ile Assembly arasında yaptığım bir kıyaslama.

.Net Native haricindeki hiçbir C# Fw'si kodu direk binary'ye compile etmez. Mono/.Net paket IL binary'ler oluşturur ve çalıştırılmak istendiğinde JIT compile eder ve kodlar VM'de çalıştırılır. .Net native ise direk binary çıkarır ve herhangi bir Fw ihtiyacı kalmadan (VM'siz) kodunuz çalıştırılır. Ayrıca farklı bir hesap açmadım yeni kayıt oldum. Kavga ettiğim falan da yok, yanlış yönlendirme ve yanlış bilgiye tahammülüm yok o kadar. Birde bunu gerçekmiş gibi anlatıp araya birkaç süslü örnek katılarak gösteriş yapılması da beni iyice alevlendiriyor ne yaparsın. Diller karşılaştırmasında öğrenim kolaylığı diyorsan C#/Java, C/C++'a göre daha kolay öğrenilir. C++'taki C++11/14 STL'sinin sadece konularının (öğrenmeden) okuması bile 1 yılını alır. Proje olarak da günümüzde en çok high-level solution'lar gerektiren sorunlar ortaya çıkar ki yine C#/Java daha sık kullanılır. Düşük seviyeli diller teknik olarak high-level dillerin işlerini yapabilseler bile aynı kodu tekrar tekrar yazmak gereksizdir ve high-level'a doğru yönelim buradan ortaya çıkmıştır. Bu nedenle yine en popüler seçim Java/C# olmalıdır. Java vs C# konusunu da tartışmaya açarsak C#'ı savunmaya başlayabilirim

 

[blade20090999]

Arkama Yaslandım İzliyorum :sinsi:

@Soketçi "C#'ı savunmaya başlayabilirim " Microsoft EveryWhere
Kurumsal Yazılım Geliştirmede C# ve Java Savaşı, IDE'lerin Önemi

Linki görebilmek için üye olmanız gerekiyor. Giriş yap veya üye ol.

 

[Soketçi]

Arkama Yaslandım İzliyorum :sinsi:

@Soketçi "C#'ı savunmaya başlayabilirim " Microsoft EveryWhere

Aslında Microsoft'un sevdiğim çok az ürünü var. XBOX'ı sevmiyorum, Office programlarını sevmiyorum, Windows'u sevmiyorum, DirectX'i sevmiyorum (OpenGL kodluyorum her zaman) fakat bunların yanında bir C#'ı, bir Visual Studio'yu, bir .Net'i hiçbirşeye değişmem. Arada fark var

Edit: Ayrıca paylaştığın makalede de eleman sırf tartışma ortamı oluşmasın diye bildiklerini anlatıp yine ikisi de olabilir demiş, bence korkaklık yapmış. Günümüzde bu konuları güncel yazacak birisi bir tarafı haklı bulsun da görelim bakalım neymiş

 

[KRHN]

.Net Native haricindeki hiçbir C# Fw'si kodu direk binary'ye compile etmez. Mono/.Net paket IL binary'ler oluşturur ve çalıştırılmak istendiğinde JIT compile eder ve kodlar VM'de çalıştırılır. .Net native ise direk binary çıkarır ve herhangi bir Fw ihtiyacı kalmadan (VM'siz) kodunuz çalıştırılır. Ayrıca farklı bir hesap açmadım yeni kayıt oldum. Kavga ettiğim falan da yok, yanlış yönlendirme ve yanlış bilgiye tahammülüm yok o kadar. Birde bunu gerçekmiş gibi anlatıp araya birkaç süslü örnek katılarak gösteriş yapılması da beni iyice alevlendiriyor ne yaparsın. Diller karşılaştırmasında öğrenim kolaylığı diyorsan C#/Java, C/C++'a göre daha kolay öğrenilir. C++'taki C++11/14 STL'sinin sadece konularının (öğrenmeden) okuması bile 1 yılını alır. Proje olarak da günümüzde en çok high-level solution'lar gerektiren sorunlar ortaya çıkar ki yine C#/Java daha sık kullanılır. Düşük seviyeli diller teknik olarak high-level dillerin işlerini yapabilseler bile aynı kodu tekrar tekrar yazmak gereksizdir ve high-level'a doğru yönelim buradan ortaya çıkmıştır. Bu nedenle yine en popüler seçim Java/C# olmalıdır. Java vs C# konusunu da tartışmaya açarsak C#'ı savunmaya başlayabilirim

Kolaylık ve kullanıcı dostu olan tabi ki Java ve C#'tır lakin sadece ufak projelerde. Kaç tane Java ile yapılmış oyun biliyorsunuz, veya işletim sistemi. Veya C# ile yapılmış bir işletim sistemi. Kendi kendinize sorun, o kadar basit diller varken neden C++, C seçilmiş. Hatta ufak ve ince işleri Assembly ile yazılmış diye. Popülerlik veya kolaylık demek bir dilin iyi olduğunu kesinlikle göstermez.

 

[blade20090999]

Visual Studio kesinlikle c# 'ı sevmemi sağlayan şey