Hangi programlama dili bulmak zor en az hata üretir? [kapalı]

54

Sizce, ortalama bir programcının bulması zor hataların en az olduğu özellikleri çıkarmasına hangi dilde izin verir? Bu elbette çok geniş bir soru ve ben çok geniş ve genel cevaplar ve bilgeliklerle ilgileniyorum.

Şahsen Java ve C # programlarında garip hatalar aramak için çok az zaman harcadığımı fark ederken, C ++ kodu kendine özgü yinelenen hatalara sahipken Python / benzerlerinin derleyici tarafından algılanacak kendi ortak ve saçma hatalara sahip olduğunu gördüm. Diğer dillerde

Ayrıca bu konuda işlevsel dilleri düşünmeyi zor buluyorum, çünkü tamamen işlevsel kodda yazılmış büyük ve karmaşık bir program görmedim. Girişiniz lütfen.

Düzenleme: Bulunması zor olan hatanın tamamen rasgele netleştirilmesi: Çoğaltılması 15 dakikadan fazla veya sebebini bulup düzeltmek için 1 saatten fazla sürüyor.

Bu bir kopya ise beni affet, ama bu konuda hiçbir şey bulamadım.

— revs Magnus Wolffelt
kaynak

10

Bu konuyla ilgili bir araştırma yapmak istiyorum! Sadece "benim anekdot delillerim, tanıdığım tek dilin kral olduğunu gösteriyor" değil, büyük projelerden kaynaklanan böcek oranlarını vb.

— Frank Shearar

@Frank .. eğer bir çok zamanınız varsa (ve ben bir çok zaman demek istedim), binlerce kod deposundaki hataları düzeltmek için yamaları tanımlamanız şartıyla, ohloh dışında bazı istatistikleri çıkarabilirsiniz.

— Tim Post

Sadece yorumlara izin verilen. Başka talimat yok :)

— Victor Hurdugaci

4

"Bulması zor" un açıklığa kavuşturulması gerektiğini düşünüyorum. Sorunuz ve cevapların çoğu, "bulması zor" ifadesini "derleyici tarafından yakalanmadı" ile eşdeğer olarak tanımlamaktadır. Python'dan derleyici tarafından algılanabilecek aptalca böceklerden bahsettiniz. Yeterince adil. Ancak bu saçma böcekler genellikle bulmak zor değil. Kesinlikle, hafızanın çok kısa sürede boşaltılmasından kaynaklanan C ++ böcekleriyle aynı kategoride değiller.

— Winston Ewert

@ Winston Katılıyorum.

— Magnus Wolffelt

58

Dilin tip sistemi ne kadar güçlü olursa, derleme zamanında böcekler o kadar fazla yakalanır.

Aşağıdaki şekil, iyi bilinen bazı programlama dillerini, tür sistemlerinin güç, basitlik ve güvenliği açısından karşılaştırmaktadır. [ Kaynak ]

alt metin

* Güvensiz yapıları kullanabilme becerisinde faktoring.

C #, "güvensiz" anahtar kelime ve ilgili işaretçi makineleri nedeniyle güvensiz satır içine doldurulur. Ancak, bunları bir tür satır içi yabancı işlev mekanizması olarak düşünmek istiyorsanız, C # gökyüzüne çarpmaktan çekinmeyin.

Haskell '98'i saf olarak işaretledim, ancak GHC Haskell, güvensiz * işlev ailesi nedeniyle saf değil. Güvensiz * özelliğini devre dışı bırakırsanız, GHC Haskell'i buna göre yukarı kaldırın.

— kayıp
kaynak

8

Bu harika!

7

Common Lisp'i grafikte bulamadım: (let ((itbe '())) ... )...

— duros

7

Ne? PHP için sol tarafta boşluk kalmadı mı?

— pestaa

7

C # güvenli işaretçilere izin verir : tüm işaretçi aritmetiği kontrol edilir. Bu nedenle, Java ile orada olması gerektiğine inanıyorum.

— Alex ten Brink,

11

@missingfaktor: Bence C # iyi durumda değil. C #, daha güvenli programlama stillerine izin verir ve bunları teşvik eder. İzin verdiği en kötü şey tarafından ölçülmemelidir.

— back2dos,

20

Bence Haskell, bazı yaygın hata kaynaklarından kaçınmanıza yardımcı olur:

tamamen işlevseldir: işlevler (istemeden) yan etkilere sahip olamaz ve bu çok çekirdekli programlamayı kolaylaştırabilir ve hataya daha az eğilimli hale getirir
şiddetle yazılmıştır: örneğin, bool, char, int ve float değerlerini kazara karıştırmazsınız
statik olarak yazılmıştır: derleme zamanında birçok programlama hatası yakalanır
nulldeğer türü tanımlarının bir parçası değildir: bu sayede milyar dolarlık hatadan kaçınırsınız.
kendi hatalı, hatalı uygulamalarınızı yazmak yerine tekrar kullanabileceğiniz hazır üst düzey fonksiyonlar vardır.
çöp toplayıcısına sahiptir: bellek hataları neredeyse ortadan kalkar (tembel değerlendirme stratejisi nedeniyle "alan sızıntıları" hariç)

— LennyProgrammers
kaynak

11

Bunu reddetmeyeceğim, ancak bu kritere uymadığı için çekiciyim. "Ortalama programcının özellikleri çıktısına" asgari hata sayımıyla izin vermesi gerekiyordu, ancak ortalama bir programcının, açıkça söylemek gerekirse, Haskell'in başlarını ya da kuyruklarını başaramıyor.

— Mason Wheeler

5

Birçok iyi nokta, ancak bazı hata sınıflarını kaldırırken (istenmeyen yan etkiler, beklenmedik tip dönüşümler) Haskell yepyeni bir hata sınıfı ekler: boşluk sızıntısı. (Aynı zamanda bir olmasına rağmen null, orada undefinedher tür hizmetin bir üyesi olduğu,.)

— j_random_hacker

5

@Mason: Eğer yazmazsan, int içinde hata bulamazsın :)

— Michael K

2

Sanırım bedava bir öğle yemeği diye bir şey yoktur - bulması kolay hatalar ya da yazması kolay bir kod olabilir ama ikisini birden değil :)

— Benjol

6

@Mason tam olarak bir “ortalama programcı” nedir? Soru, “hangi programlama dili ...” ile başlar, “hangileri C, C ++ ve java ...”;)

— Agos

18

Geleneksel olarak böcek bulmak en zor olanı, çok iş parçacıklı uygulamalarda olduğu gibi yarış koşullarıdır.

çoğaltmak neredeyse imkansız
çok ince olabilir

Dolayısıyla paralizmi sizin için mümkün olduğunca çok ve müdahalesiz yöneten dillere ihtiyacınız var. Bunlar henüz ana akım değil. Java bazılarını yapar, ancak sizi zor kısımdan çıkarır.

Anladığım kadarıyla, işlevsel bir dile ihtiyacın var, çünkü "hiçbir yan etkisi" ilk önce iki kurşun noktasını ortadan kaldıran şey. Haskell'i verimli bir multi-thread dili yapmak için şeffaf bir şekilde çalışmaların sürdüğünü gördüm ve Fortress'in sıfırdan etkili bir paralel dil olacak şekilde tasarlandığına inanıyorum.

Düzenleme: Java'da Executorssert parçaların daha da üstesinden gelir. Bireysel görevlerin Callablearayüze uymasını sağlamanız gerekir .

— kullanıcı1249
kaynak

5

++ Yarış koşulları. Onu tekrar söyleyebilirsin.

— Mike Dunlavey

Evet. Genel olarak paralel hesaplamanın, dil yardımı ile bile zor olduğunu unutmayın. (Ortak Lisp makroları, birçok dil desteğine rağmen zordur, çünkü yaptıkları çok güçlüdür. Aynı müdür.)

— David Thornley

Peki ya Erlang?

— Malfist

@Malfist, Erlang hakkında bunu cevaplayacak kadar bilgim yok. Belki gerçekten bilmek istersen bir soru sormalısın?

2

Erlang, çok iş parçacıklı kullanımı basit ve güvenli hale getirmek için tasarlanmış işlevsel bir programlamadır. Değişkenleri paylaşmazsınız, mesajları iletirsiniz. Bu wikipedia sayfasını okuyun.

— Malfist

13

Ada, çalışma zamanı yerine derleme zamanında yakalanabilecek şekilde tasarlanmıştır. Bunun anlamı Ada’da bir programın Java’da yazacağına göre derlemesinin 10x daha uzun sürmesidir, ancak derleme yaparken programın tüm sınıflarının kendilerini göstermeyeceğinden emin olabilirsiniz. Çalıştırmak.

— Mark Pim
kaynak

7

Ada’nın derleyicide diğer dillerin göz ardı ettiği şeyleri yakaladığını doğru bir şekilde fark etmek için +1. -1, bunun bir Ada programının derlenmesinin 10x daha uzun sürdüğü iddiası için. Ada, DESIGNS adlı programcıyı ödüllendiriyor !!! kodunu, kim DÜŞÜN !!! Delice yazmaya başlamadan önce ne yaptığı hakkında. Ada'da savunma çalışması için üretim programlaması yapan kişisel deneyimim, Ada kodunu C / C ++ veya FORTRAN'a göre almaktan daha uzun sürmemesiydi, ancak Ada kodu daha sonradan daha az sorun yaşadı. Pratt & Whitney benzer bir şey fark etti.

— John R. Strohm

1

@ john r strohm, anladığım kadarıyla, derleyicinin kodu derleme zamanı değil, kodu derlenebilir hale getirme zamanından bahsetmiyor.

— Malfist

oh kodu derlenebilir hale getirme konusunda anlaştılar. Programcıların nitelemeyle ilgili dili öğrendiği pek çok cinsiyetçi yorumu hatırlıyorum. Genelde Şey çizgileri boyunca, bir kadının peşinden bir dil yazarsanız ...

— Michael Shaw

@Plalemy, eğer tekneler kadınlara isimlendirilebiliyorsa (görünüşe göre ABD taşıyıcıları hariç) programlama dilleri de olabilir. Aksine "USS Ronald Reagan" yerine "Ada" ismini aldı :)

1

Bir kez öğrenme eğrisini aştığımda, Ada kodunu yazmakta oldukça hızlı oldum - tasarıma bakarak çok fazla zaman harcadıktan sonra. Ada kesinlikle bir bilgisayar korsanının dili DEĞİLDİR. Bugünlerde Java'da çalışıyorum ve şu anki projelerimde gördüğüm bazı şeyler aslında Ada'yı biraz özlememi sağlıyor (bunu söyleyeceğimi asla düşünmedim).

— James Adam

7

İlk olarak bir tanım: bulması zor bir hata, anladığım kadarıyla çoğaltılabilecek bir hatadır ancak sebebi bulmak zordur.

Muhtemelen en önemli yönü darlık dediğim şeydir , yani bir böcek kaçışını ne kadar uzaklaştırabilir, bir hatanın potansiyel olarak etkileyebileceği kapsamın büyüklüğüdür. C gibi dillerde bir hata, örneğin negatif bir dizi indeksi veya başlatılmamış bir gösterici, programın her yerindeki her şeyi tam anlamıyla etkileyebilir, bu yüzden en kötü durumda, sorunun kaynağını bulmak için her yerde her şeyi kontrol etmeniz gerekir .

Bu bağlamda iyi diller, erişim değiştiricileri desteklemekte ve onları atlamayı zor veya imkansız kılacak şekilde uygulamaktadır. İyi diller, global değişkenlere sahip olmayı çok kolaylaştırmak yerine değişkenlerinizin kapsamını sınırlamanızı teşvik eder (örneğin, "açıkça belirtilmeyen her şey varsayılan tür ve değere sahip genel bir değişkendir").

İkinci önemli husus ise eşzamanlılıktır . Yarış koşullarının çoğaltılması genellikle zordur ve bu nedenle bulunması zordur. İyi diller, kullanımı kolay senkronizasyon mekanizmaları sunar ve standart lib'leri gerektiğinde iş parçacığı güvenlidir.

Bu zaten listemi tamamlar; Güçlü yazma gibi diğer şeyler derleme zamanında böcekleri yakalamaya yardımcı olur, ancak bu böceklerin daha sonra bulması zor olmaz.

Bunları göz önünde bulundurarak, Java ve C # ve JVM ve .net dünyasındaki diğer birçok dilin bulunmasının zor olduğu hataları önlemek için uygun olduğunu söyleyebilirim.

— user281377
kaynak

Manuel kilitleme, "kullanımı kolay bir senkronizasyon mekanizması" gibi görünebilir, ancak gerçekten sadece "kullanımı basit ama bu kilitlenmeyi takip ederken eğlenceli zamanlar geçiriyorsunuz". Ve, pek çok dilde Oyuncu-tabanlı eşzamanlılık yapabilirsiniz.

— Frank Shearar

Frank: en azından kilitleme yeterince basit, böylece herkes günlerce harcamadan bunu yapabilir, hangi API'nin kullanılacağını

— çözebilir

Öyleyse, “herkesin yapabildiği kadar basit” bir eşzamanlılık çözümünün, okul öncesi çocuklara masa testereleri vermek gibi bir bakış açısı var.

— David Thornley,

@David: Niyetimizi anlıyorum, ancak çoğu durumda basit bir çözüm gerçekten gerekli. Örneğin, paylaşılan bir kaynak kullanması gereken (örneğin veritabanı bağlantısı) yalnızca birkaç kullanıcı tarafından kullanılan bir sunucu uygulamasını düşünün. Senkronizasyon olmadan, yarış koşulları her zaman ve sonra gerçekleşir; ancak tüm veritabanı erişim işlemlerini senkronize (bağlantı) bir {} bloğa koymak tam olarak roket bilimi değildir.

— user281377,

+1 Bu tanım için "bir hatanın potansiyel olarak etkileyebileceği kapsam ne kadar büyük". Yanlış veri türündeki bir nesnenin kendini bir hata olarak göstermeden önce kodda çok ileri gittiği (ördek yazması sayesinde) dinamik dilleri olan çok kötü hatalar yaşadım.

— Giorgio

7

Excel en çok kullanılan DSL olduğundan, Excel ile gideceğim. (elbette VBA hariç)

Tasarıya uyar:

Çoğaltılması her zaman kolaydır (işte bir elektronik tablo - işe yaramaz)
Bu hatayı bulmak oldukça kolay, çünkü tamamen "işlevsel" - yanlış olan hücreyle başlayın ve tüm bağımlılıklarını geri alın.

— Scott Whitlock
kaynak

Bu, bulması kolay hatalar eklemediğiniz sürece doğru olabilir.

— mouviciel

+1 Excel veri olduğu için biraz arsız bir dil değil. Bana iyi bir kahkaha

— recursion.ninja

2

@awashburn - oh, bilmiyorum. Bence bir dil olarak nitelendiriliyor. Her hücre bir "değişken" dir. Her değişken bildirimli olarak değişmez ( 123veya gibi ABC) veya bir işlev ( =SUM(A2:A5)) olarak ayarlanır . Excel daha sonra tüm değişkenleri değerlendirir, bağımlılıkları çözmek için hangi sırayı çözdüğünü vb. Belirler. Kesinlikle sadece veri değildir.

— Scott Whitlock

2

İfademi geri çekiyorum, Excel'in Turing Tamamlandı ... Tamamen rahatsız edici bir şey öğrendim ...

— recursion.ninja

1

“... gerçek [Lisp] ustası tüm verilerin kod olduğunu fark eder.” Belki de bu, Excel için de geçerlidir. blogs.msdn.com/b/sriram/archive/2006/01/15/lisp-is-sin.aspx

— James Mishra

7

Bu zor bir sorudur, çünkü çoğu hata dilin kendisinin hatası değildir - bunun yerine geliştiricilerin dili nasıl kullandıklarına dair hata yapma hatasıdır.

Dil özelliklerinin hata olasılığını etkileyen birkaç yönü olduğuna inanıyorum:

Etkileşim - REPL'li dinamik diller, çalışan programlar ve daha küçük kod / test çevrimleriyle etkileşimi / deneyi teşvik eder. Yinelemenin temiz basit çözümler bulmak ve hataları tespit etmek / ortadan kaldırmak için iyi bir yol olduğunu düşünüyorsanız, bu etkileşimli dilleri destekleyecektir.
Etkileyicilik - Kod daha kısaysa ve daha az kazan / kazan karmaşıklığı varsa, hata / mantık hataları görmek daha kolaydır.
Tip güvenliği - derleme süresi ne kadar fazla kontrol edilirse, derleyici tarafından o kadar fazla böcek yakalanır, bu nedenle genel güvenlik türü iyi bir şeydir. Bununla birlikte, bunlar genellikle hata bulmak zor değildir - tamamen dinamik bir dilde bile, bir veri yapısındaki yanlış tür genellikle çok açık bir çalışma zamanı hatasına neden olur ve TDD bu tür hataları hemen hemen her zaman alır.
Taklit edilebilirlik - bir çok zor hata, değişken durumun karmaşık etkileşimlerinden kaynaklanmaktadır. Değişmezliği vurgulayan diller (Haskell, Clojure, Erlang) değişkenliği engellemenin çok büyük bir avantajı var.
İşlevsel programlama - kod yazmaya işlevsel yaklaşımlar, karmaşık etki dizileri / etkileşimler dizisine sahip nesne yönelimli koddan daha "kesin olarak doğru" olma eğilimindedir. Tecrübelerim, FP'nin zor böcekleri önlemeye yardımcı olduğu - şu anda bunu destekleyemediğim bir yerde bazı akademik araştırmalar olduğuna inanıyorum.
Eşzamanlılık desteği - eşzamanlılık sorunlarının tespit edilmesi ve hata ayıklanması özellikle bu nedenle bu kadar önemlidir. Manuel kilitleme gerektiren her şey sonuçta başarısızlığa mahkumdur (ve bu hemen hemen eşzamanlılığa yönelik her nesne yönelimli yaklaşımı içerir ). Bu konuda bildiğim en iyi dil Clojure - yeni, güvenilir ve birleştirilebilir bir eşzamanlılık çerçevesi elde etmek için yazılım işlem belleğini değişken veri yapılarıyla birleştiren eşzamanlılık yönetimi konusunda benzersiz bir yaklaşıma sahip. Daha fazla bilgi için http://www.infoq.com/presentations/Value-Identity-State-Rich-Hickey adresini ziyaret edin .

— mikera
kaynak

Benim gibi, işlevsel programlamanın tutkulu destekçisi olan insanlar bu cevabı takdir ediyor. Anlatım arkadaşındır.

— Sridhar Sarnobat

1

Şimdiye kadarki en iyi cevap! Sanırım bu, aşağıdaki iki hata sıklığı analizi ile destekleniyor: kasıtlı - software.com/safety-rank-part-2 ve macbeth.cs.ucdavis.edu/lang_study.pdf . Her ikisi de ne kadar saf, ne kadar işlevsel, ne kadar anlamlı ve dilin o kadar az böceğe sahip olduğunu gösteriyor. Benzer şekilde, ikisi de Clojure ve Ruby'nin Güvenlik kuralından kaçtığını gösteriyor, muhtemelen Etkileşim'in belirttiğiniz gibi eşit bir etkiye sahip olduğunu gösteriyor.

— Didier A.,

@DidierA. ne yazık ki ucdavis bağlantısı koptu (wbm arşivi olmadan) - Sanırım şimdi güncel bir bağlantıyı işaret eden Prem Devanbu sayfasından aldım: Github'da Büyük Programlama Dilleri ve Kod Kalitesi Çalışması

— icc97

5

Bir dil ne kadar güçlü olursa, kendi ayağınızı vurmanız o kadar az seçenek demektir.

Java ve C # gibi yüksek seviyeli diller, C ++ gibi düşük seviyeli dillerden daha az hata üretecektir.

Java'nın C # 'dan daha güvenli olduğuna inanıyorum. Java yapay olarak sınırlıdır, böylece ileri düzeyde bilgisi olmayan ortalama bir programcı ustalaşıp kararlı programlar üretebilir.

— user8685
kaynak

4

+1 "Bir dil ne kadar güçlü olursa, o kadar az seçenek kendi ayağınızı vurmanıza neden olur."

— Michael K,

Missingfaktor'dan gelen çizelge, C # ve C ++ 'nın orada kendini vurabildiği kadar eşit derecede "dayanıyor" olduğunu gösteriyor gibi görünüyor ve Java'yı bunun üstüne çıkardı. Tabii ki, tablonun bu bölümüne katılıyorum. Bazı C # çekimi yapmak için çemberin içinden geçmek zorundasınız.

— Jesse C. Dilimleyici

6

Güvenlik ve güç ters orantılı değildir (bu düşündüğünüz gibi görünüyor ;-) Örneğin Haskell, ÇOK güçlü ve henüz kendinizi ayağınıza çekmek için çok az yol var.

— missingfaktor

3

Dil zayıfsa, daha büyük bir ayağa ihtiyacınız var.

7

@missingfaktor, bunun sebebi kendinizi ayağınıza vurmanın bir yan etkisi olması.

3

Sizce, ortalama bir programcının bulması zor hataların en az olduğu özellikleri çıkarmasına hangi dilde izin verir?

Bence Delphi. Pascal'ı temel alan dil, ortalama bir programcının (veya hatta deneyimsiz kodlayıcıların) kolayca toplayabilmesi için yeterince basit ve sezgiseldir ve zengin araç ve kütüphane desteği, çoğu hata bulmayı kolaylaştırır.

Güçlü yazım ve birçok yaygın hatayı yakalayan katı bir derleyici.
Yaygın hataları teşvik etmeyen sezgisel sözdizimi. ( if (alert = RED) {LaunchNukes;}Örneğin , "Dünyanın Son Böceği" derlenmeyecektir.)
Genel C ++ OOP hatalarının çoğunu ortadan kaldıran iyi tasarlanmış bir nesne modeli.
Dilde yerleşik sınır denetimi ve aralık denetimi , güvenlik sorunları olasılığını önemli ölçüde azaltır.
Muhtemelen insanoğlunun bildiği en hızlı derleyicidir, bu da üretkenliğinizi arttırır ve bir inşaat beklerken düşünce treninizi kaybetmenizi zorlaştırır.
Hata ayıklayıcı Visual Studio'nun hata ayıklayıcısı, büyüdüğü zamanki gibi olmak ister.
Doğrudan bellek yöneticisine yerleşik sızıntı izleme, bellek bulma ve düzeltmeyi önemsiz kılar.
Kendi büyük olasılıkla buggy uygulamalarınızı oluşturmak zorunda kalmadan ortak görevleri yerine getirmek için önceden oluşturulmuş ve önceden test edilmiş yöntemler sunan geniş, olgun standart bir kitaplık.
Sorunların izlenmesini kolaylaştırmak için güçlü bir kayıt sistemi ve bir profiler gibi kullanışlı araçlarla birlikte gelir.
Güçlü bir üçüncü taraf eşzamanlılık kütüphanesi de dahil olmak üzere standart kütüphanede bulunmayan ortak sorunlara güçlü topluluk desteği .

— Mason Wheeler
kaynak

Ben dönerken bir Delphi jokey değilim, ama Pascal kökleri var dan benim başka bir şey, a la C / C ++ bir şey typecasting izin ne zaman gitti:var I: Integer; Pointer(I)^ := $00;

— Jesse C. Dilimleme

1

@Jesse: Belki, ama bunu pragmatizm için gerekli bir imtiyaz olarak görüyorum. Kernighan, neden Pascal'ın en sevdiğim programlama dili olmadığını yazdığında birçok önemli noktaya değindi . Tipik tahminler birçok önemli düzeyde düşük seviyeli işlem yapılması için gereklidir. Ancak, Delphi'nin güçlü yönlerinden biri, kütüphanelerinin düşük düzeydeki ayrıntıları kapsama ve güvensiz işaretçi ve yazı tipi öğelerinin çoğunu gereksiz kılma şeklidir.

— Mason Wheeler

Gerekli olabileceği konusunda hemfikir değilim - ama Güçlü Yazma iddiası bununla bir şekilde reddedildi. Orijinal Pascal bu tür şenanlara izin vermedi ve bu yüzden kesinlikle yazılmıştı. Ancak Delphi'yi zayıf yazılmış olarak adlandırmak için şu ana kadar gitmedim - bu bir tür 'orta-iyi yazılmış'.

— Jesse C. Dilimleyici

1

@Jesse: Pascal'ın orijinal Wirth sürümü değişken kayıtlarına izin vermedi mi? IIRC sonunda, Borland ve diğerlerinin herkesin zaten yaptığı için daha basit hale getirmek için daha az yazı yazmak için karar vermelerine neden olacak şekilde güçlü yazı tiplerini altüst etmek için o kadar yaygın bir şekilde kullanıldılar ki.

— Mason Wheeler

en.wikipedia.org/wiki/Pascal_(programming_language)#Divisions ve en.wikipedia.org/wiki/Pascal_(programming_language)#Criticism yanı sıra pascal-central.com/ppl/chapter3.html görünüyor bunun bir parçasıydı belirtmek için 1983’deki ilk standart. 1974’e tarihlenen Wirth’ten bazı referanslar görüyorum. Bence sorunlu kısım bunun altüst edilmesine izin veriyordu (C'deki sendikalar gibi aynı hafızayı alan değişken alanlar). Basitçe bir kapsam belirleme mekanizması olarak kullanılmışlarsa ve bellek düzeni süperset için olsaydı, daha güçlü yazılırdı.

— Jesse C. Dilimleyici

2

Dikkate alınması gereken bir şey, zaman içinde dönüş.

Son beş yıldır, çoğunlukla java'da (JSF, Seam, vb.) Web uygulamaları geliştirdim. Son zamanlarda yeni bir iş buldum ve Perl'i (Catalyst ve Moose ile birlikte) kullanıyoruz.

Perl'de, Java'da olduğumdan çok daha üretkenim.

Derleme ve (sıcak) dağıtmaya gerek duymamak, bir nedendir. Ayrıca yazma kullanım durumlarının daha yinelemeli bir şekilde yapılabildiğinden daha kolay olduğunu düşünüyorum. Ve Java’daki çerçeveler, en azından katıldığım projeler için gereksiz karmaşık görünüyor.

Perl kodumdaki hataların sayısının Java kodumdaki hataların sayısıyla hemen hemen aynı olduğunu düşünüyorum, hatta daha da yüksek olabilir. Ancak bu hataları bulmak ve düzeltmek için daha kolay ve daha hızlı buluyorum.

— slu
kaynak

1

Belki de her programlama dili için statik ve dinamik kod analizi için kullanılabilir araçların sayısını araştırmak bir fikir verebilir. Bir dil için ne kadar fazla araç varsa, dilin kullanıcılar arasında çok popüler olması ya da bulunmasının zor olduğu yerlerde çok popüler olması daha olasıdır. Ancak Google’ın beni bu konuda yapılan herhangi bir çalışmaya yönlendirmesini sağlayamıyorum. Ayrıca C gibi bazı dillerin, altta yatan donanım hatalarının etrafında çalışmak için ve ayrıca yaşlandıkça donanımın aşınma ve yıpranma etrafında çalışmak için kullanılabileceği belirtilmelidir.

— vpit3833
kaynak

1

"yaşlandıkça donanımın aşınması ve yıpranması etrafında çalışmak" ...?

— j_random_hacker 13

Görev kritik makinelerde çalışan bazı Unix işletim sistemlerinin CPU, RAM ve diğer donanımların sağlığını kontrol ettiğini okudum. serverfault.com/questions/56192/… bu konuyu biraz derinlemesine tartışıyor. RAM modülündeki bazı hatlar zaman içinde hatalı hale gelirse, bu hatalı modüller işletim sistemi tarafından kullanılmayacak ve bunları mevcut toplam fiziksel bellekte rapor etmeyecektir. Bu tür şeyler başka donanımlarda da yapılabilir.

— vpit3833

Bu ilginç bir haberleşme ama burada bunun ne kadar alakalı olduğunu anlamıyorum. Ayrıca bağlantınızdaki hiçbir şey bu kendi kendini onarabilen Unix OS'lerden bahsetmiyor - sadece bir bilgisayarın donanımını stres testi yapmanın yollarından bahsediyor.

— j_random_hacker

1

Sadece programların hata kaynaklarını değil, donanım veya diğer dış faktörler olabileceği anlamına geldiğini söyledim.

— vpit3833

1

Dil hakkında konuşmak yerine, dil özellikleri hakkında konuşmaya ne dersiniz?

Java sizi istisnalar hakkında düşünmeye zorlar (fırlatır ...) ve bu istisnaları ya basmalı ya da ele almalısın. Bu, beni gerçekten hata durumlarını unutmama engelliyor mu, yoksa bu işleme gerek duymayan SystemException'dan kaynaklanan daha fazla istisna mı kullanıyorum?
beni ön ve son koşullar hakkında düşünmeye zorlayan "sözleşmeyle tasarım" (http://en.wikipedia.org/wiki/Design_by_contract). C # -4.0 ile şimdi mümkün olduğunu okudum.

— k3b
kaynak