BeğenFavori Paylaş
BeğenFavori Paylaş

#Swift'in neden değerli olduğu ile ilgili 7 sebep

No undefined or uninitialized variables.
No array-out-of-bounds errors.
No integer overflow errors.
Explicit handling of nil (null) values.
Automatic memory management.

Huzur varmış 😀

Generics, closures, tuples, multiple returns, iterators, built-in functional programming patterns, and more.

Bunlar da bayağı şenlendirmiştir ortalığı.

https://www.makeuseof.com/tag/reasons-learn-swift-language/

#swift #objectivec #apple #programming

7 Reasons the Swift Programming Language Is Worth Learning

You ought to learn the Swift programming language sooner rather than later if you don't want to be left behind. Here are some excellent reasons that may convince you.
BeğenFavori PaylaşYorum yap
  • JohnSmith @johnsmith

    Bu hatalaın oluşmasına sistem izin vermiyorsa, sonuç optimize değildir, programlama dili güçlü değildir, her durumda bu dilciği kullananlara programcı denilecekse C, C++ vb. gerçek dilleri kullananlara ne diyeceğiz? 🙂

    • arsenik @sha-2

      Valla beni hiç ilgilendirmez kimin kime ne dediği. Ben yazdığım kodda hata almamaya bakarım. Hayat bana güzel olur. Gerisi beni bağlamaz. 😀

    • ÖG @ozgurg

      @sha-2 Hatalı yazdığın kodu hataları göstermediği için hatalı yazmaya devam edersen ne olacak?

    • arsenik @sha-2

      @ozgurg Debugging ne güne duruyor 😀

    • arsenik @sha-2

      @ozgurg Kaldı ki zaten programcının zorlandığı noktalar derleme anı hatası değil çalışma anı hatasıdır. Derleme anı hataları illa ki çözülür. Ama mantıksal hatalar daha önemli ve daha problemlidir.

    • arsenik @sha-2

      @johnsmith Gerçek dil kavramını açmak lazım. Gerçek dilden kastınız nedir?

    • Ergin Bilgin @erginbilgin

      @johnsmith Ne açıdan optimize değil? Gayet optimize sonuçlar veriyor Swift. Ben C++'cı olarak mümkün oldukça Swift kullanmayı tercih ederim.

      @ozgurg Hatalı yazdığın kodda hata göstermeme gibi bir durum yok. Swift çoğu açıdan runtime'da sıkıntı yaratacak hatalara mahal vermemek için belli kurallara sahip. Aksine, runtime'da sıkıntı çıkartacak bir kodu yazmanıza izin vermiyor. Bu sizi sınırlıyor anlamına da gelmiyor. Sadece bazı şeyleri failsafe yazmaya zorluyor sizi. Mesela explicit handling of nil, yani optional olayı. Sizi null olma durumunu düşünerek programlamaya mecbur bırakıyor.

    • JohnSmith @johnsmith

      @erginbilgin @sha-2 Optimizasyon, otomatik vites, manuel vites farkı gibi. Ya da eskiden byte hatta bit hesabı yapılırmış, şimdi megabyte'a önem verilmiyor.

      Ben hangisi daha iyiyi tartışmıyorum. Ortada bir ödünleşme (tradeoff için yapılan compromise) olmak zorunda. Bir fonksiyon üzerinde 5 gün çalışılır, assembly ile elle optimize edilir, sonunda bir oturum boyunca 100 KiB ya da 0.001 saniye kar sağlayabilir. Çok zaman kritik bir proje için bu anlamlı olabilir ama o 5 günü başka şeyler üzerinde harcamak, *harcayabilmek*, çoğu proje için daha başka ve daha faydalı bir optimizasyon olabilir. Ama hem otomatik bellek yönetimi olsun, hem en az bellek harcasın, hem en hızlı olsun, hem daha az bug'a yol açsın, hem hiçbir yan etkisi olmasın derseniz, olmaz.

      Benim bakış açım şu: Bir 'programcı' C, C++ vb. bir dili kullanabiliyorsa, bir proje gerektirdiğinde ya da en azından hızlı geliştirme yapabilmek için isterse (kaldıysa) BASIC kullansın. AMA hiç C, C++ vb. bir dili kullanmayı bilmeden, öğren(e)memişken, sadece Java kullanabildiği için, Java'nın otomatik bellek yöneticisi arkasını topladığı için, Java kullanıyorsa, bu kişiye başka ad vermek lazım. O da programcı, bu da programcı olursa, aradaki fark belli olmuyor, aradaki fark belli olmasını isteyeceğimiz kadar büyük bir farktır.

    • Ergin Bilgin @erginbilgin

      @johnsmith Bazı şeyleri aşmayı kabullenmek gerek. Daha fazla kontrol her zaman en iyisi değildir. Zaten en iyi programcı dahil günümüzün otomatize sistemleri ile yarışmakta zorlanır. Teoride bu sistemler yanılgıya düşebilir ve programcının bunu manuel olarak daha iyi yapması mümkün olabilir ama gerçek hayatta ne kadar olan bir şey? Kaldı ki C++'da efektif olarak kaç kişi memory'yi tamamen manuel kontrol ediyor? Yine bir sürü yardımcı kullanılıyor. Buna rağmen C++ ve benzeri dillerde yazılmış yazılımlarda memory leak istatistikleri Swift gibi dillere kıyasla Dünya genelinde çok daha yüksek.

      İyi bir programcı zaten Swift in ARC (Automatic Reference Counting) sisteminin yanılacağı yeri bilir ve önlemini alır.

      Ve en nihayetinde diller dahil tüm araçların geliştiriciler tarafından, diğer geliştiricilere vakit kazandırmak amacıyla tasarlandıklarını unutmayalım. Dünyada bu seviyede çalışabilecek insan sayısı maalesef az. Dolayısıyla bu olmasa yazılım sektörü işleyemez.

      Ayrıca mesleği bir şeyleri otomatize etmek olan insanların en başta kendi işlerini otomatize etmesi ve kolaylaştırması en beklenebilecek şey.

      Eskiden oyun motoru konusunda bu muhabbet çok dönerdi. Oyun motoru kullanarak oyun yapanlara gerçek oyun geliştirici gözüyle bakılmazdı. Grafik programlamayı bilmeyenler kumda oynasın gözüyle bakılırdı. Ne oldu, günümüzde oyun motoru kullanmayıp sıfırdan yapacağım derseniz deli gözüyle bakılıyor, alay konusu dahi olabiliyorsunuz. Unity boşuna bu günlere gelmedi. Sloganı "Democratizing game development." olarak. 🙂

      Son olarak, önceki nesil nasıl yenilerin Assembly bilmemesini bir zayıflık olarak görmediyse, (Gören mutlaka olmuştur ama günümüzde durum ortada.) biz de yeni gelenlerin C++ gibi dilleri bilmemesini garipsememeliyiz. 🙂

    • JohnSmith @johnsmith

      @erginbilgin Doğru söylüyorsunuz, tartışılacak bir şey yok.

      Benim dediğim değişik yetileri olan kişileri değişik kelimelerle tanımlamanın daha doğru olacağı. Aynı şey programlama dilleri için de geçerli 🙂

    • Ergin Bilgin @erginbilgin

      @johnsmith Bizim sektörde en önemli şey CV malum. Zaten kimin ne olduğu CV'de, Twitter'ında LinkedIn'inde yazan şirkete, pozisyona göre belli oluyor. En tepeden, en alt seviyeye hemen herkese iş düşen geniş bir sektör sonuçta. 🙂

      Gerçi örneğin inşaat mühendisliği de çok farklı değil. 3 katlı apartmanı zor dikenler de, neredeyse 1 kilometrelik gökdeleni dikenler de aynı ünvana sahip. 😀

    • Papa Emeritus @pope

      Hocam bakış açısı yanlış bence. Üni'de 2 yıl C,C++ ile hardcore çalıştım fakat 3 aydır %80 swift kullanıyorum. Swift'le uzun süre takılınca dünya vermış diyorum. Direkt sonuca odaklanabiliyorum Swift'le belki en performanslısı olmuyor ama sonuç almam çok hızlı oluyor ki bence günümüzde programı hızlı bir şekilde çalışır hale getirmek en az performans kadar önemli. Birde Java'nın memory yönerimi ile swift'in ki arasında fark var. Java neredeyse tüm kontrolü alırken swift'te yazarken memory yönetimini az çok düşünmek zorundasınız. Fakat dediğiniz gibi C,C++ bilen biri için çocuk youncağı ondan her programcının C,C++ bilmesi lazım bencede.

  • Leopard @leopard

    Bende tam scrollamadım diyom swift değerlimi 😀 Berbat birşey çünkü Edit:Para aktarımı olan swiftten bahsettim

Bir fonksiyona sahip olmadan temel sebeplerinden biri o fonksiyonun tekrar kullanılırlığının olması.

Reuse is one of the main reasons for having a function. Take the printf() for instance. It's pretty complicated down there, parsing the format string and knowing how to actually output characters to a device and all that. Imagine if you have to rewrite all that code every single time you wanted to output a measly string to the console? No, no--far better to put the whole thing in a function and let you just call it repeatedly, see?

http://beej.us/guide/bgc/output/html/multipage/functions.html

#c #programming

BeğenFavori PaylaşYorum yap

#Programming
Oldukça güzel bir proje. Beta için başvurdum bakalım ne olucak 🙂

http://www.luna-lang.org

Luna. Hybrid-visual textual functional programming language.

Luna is a developer’s whiteboard on steroids. Design, prototype, develop and refactor any application simply by connecting visual elements together. Collaborate with co-workers, interactively fine...
BeğenFavori PaylaşYorum yap

#programlama #Programming #Java #JavaScript #akış

BeğenFavori PaylaşYorum yap