Şu anki (2013) Google Code Jam yarışmasında, C ++ ve Java insanlarına 200+ kod satırı alan ve Python çalışanlarına kıyasla aynı sorunu yalnızca 40 satır kod kullanan bir sorun yaşandı.

Python, C ++ ve Java ile doğrudan karşılaştırılabilir değildir, ancak ayrıntıdaki farkın, algoritmanın verimliliğini etkileyebileceğini düşündüm.

Dil seçimine göre doğru algoritmayı bilmek ne kadar önemlidir? Mükemmel bir şekilde uygulanan bir Python programı C ++ veya Java ile daha iyi bir şekilde uygulanabilir mi (aynı algoritmayı kullanarak) ve bunun belirli programlama dillerinin doğal ayrıntılarıyla bir ilişkisi var mı?

Açıkçası, bu soruyu Google Code Jam gibi bir şey bağlamında düşünürseniz, algoritmik problemleri çözmeniz gerektiğinde algoritmik düşünme açıkça daha önemlidir.

Ancak günlük hayatta, soruyu beyaza göre daha az siyah yapan, milyonlarca başka faktörün de göz önüne alınması gerekir.

Sadece bir karşı örnek: Java'da 200 satıra daha ihtiyacınız varsa, ancak şirketinizdeki herkes Java biliyorsa, bu önemli bir şey değil. 5 satır Python veya başka bir dilde yazabilseydiniz, ancak o dili bilen şirkette tek kişi siz olabilirsiniz - bu büyük bir mesele. Aslında bu kadar büyük bir anlaşma, bunu yapmanıza bile izin verilmeyecek ve bunun yerine Java'da yazmanız gerekecek.

Bir zanaatkarın bakış açısına göre, her zaman iş için doğru araçla yaklaşmaya çalışırız, ancak tam oradaki kelime o kadar zordur ki, kolaylıkla yanlış anlaşılabilir.

Aksine, şirketlerdeki algoritmik düşüncenin neredeyse bulunmadığını gördüm. Sadece birkaç seçilmiş insan buna sahipken, ortalama joe genellikle döngülerin, aramaların, vb. Çalışma zamanı karmaşıklığını tahmin etmekte zorlanıyor.

Bununla birlikte, algoritmik yarışmalar açısından, kişisel deneyimlerim bunlarda birkaç yıl boyunca rekabet etmekten, bana tek bir dilde kalmanız gerektiğini açıkça söylüyor. Hız önemli bir faktördür ve zaman sınırındaki sorunları çözmeye adamanız gerektiğinde aletlerinizle zaman kaybetmeyi göze alamazsınız. Ayrıca düşünmeden 200 satır Java kodu yazmanın, çok fazla düşünmeyi gerektiren 50 satırlık karmaşık python kodu elde etmekten çok daha hızlı olduğunu, ancak her ikisinin de aynı sorunu çözdüğünü de düşünün.

Son olarak, algoritmik rekabet kodu ve şirket üretim kodu arasındaki temel farklılıkları anladığınızdan emin olun. Bir üründe asla kabul etmeyeceğim korkunç bir kod yazan fantastik algoritmik kodlayıcılar gördüm.

Yarışmaların dışında bile algoritmik düşünmenin belirli bir dil için her numarayı bilmekten daha önemli olduğunu savunuyorum.

Elbette, çalıştığınız dili olabildiğince iyi bilmek istersiniz, ancak diller gelir ve gider, algoritmalar açısından soyut düşünme yeteneği oldukça aktarılabilir bir beceridir.

Örnek olarak: Doğru hatırlıyorsam, bir süre önce burada bir programcının FizzBuzz'ı bir röportajda başarısızlığa uğratmaktan şikayet ettiğini ve Java'nın modulo operatörü hakkındaki bilgi eksikliğini suçladığı Programcılar hakkında bir yazı vardı. Bu sonuç yanlıştır - modulo'nun nasıl çalıştığıyla ilgili bilgi eksikliği, kendini adanmış bir modulo operatörünün yokluğunda bile, problem hakkında algoritmik olarak düşünmesini ve çözmemesini sağladı. Daha da ileri giderek: Java'nın bir Tree sınıfı var - peki, ileride bu sınıfı uygulamayan bir dille çalışmak zorundaysanız? Yine, sorun hakkında düşünebilme becerisi dile özgü ayrıntılara dayanıyor.

Örneklerin basit olduğunu itiraf ediyorum, ancak bu noktayı ortaya koymaya yardımcı oluyorlar.

Dil önemlidir.

DARPA ve ABD Donanması, yaklaşık 20 yıl önce bir çatışmada deneme yaptılar . Karanlık at kaçak galibi Haskell oldu. Ada ve C ++ her ikisi de temsil edildi; Java değildi.

Aynı dönemde Pratt & Whitney , jet motoru denetleyici projeleri üzerinde zaman çizelgesi ve hata izleyici verilerine bakarak bir veri madenciliği çalışması yaptı. Ada'nın programcı verimliliğini iki katına çıkardığını ve kullandıkları diğer dilin kusur yoğunluğunun 1 / 4'ünü bulduğunu keşfettiler.

Atari, FORTH'i video oyunları geliştirmek için kullanırdı ve FORTH'u kullandıkları gerçeği çok özeldi.

Paul Graham'ın LISP'yi kullanma konusundaki yorumları iyi bilinmektedir. Erann Gat'ın JPL'deki LISP ile ilgili yorumları , bilinmemekle birlikte, aynı derecede uyumludur .

Boeing 777 aviyonik yazılım hemen hemen tüm Ada olduğunu. Büyük bir taşeronun orta akışta başlaması gerekmesine rağmen, deneyimleri çok iyiydi.

Dil önemlidir.

Bazı noktalar:

• En üst pozisyonlar, C ++ / C / Java olma eğilimindedir; fark, onunla diğer dil arasındaki kaç kod satırı olduğuna bakılmaksızın. Bu, en üst kodlayıcıların, muhtemelen ham hızlarından ötürü diğerlerinin üzerinde bu dilleri seçme eğiliminde olmasıyla ilgili daha fazla olabilir.
  Ne yazık ki, programlama dilini Google Code Jam'de kolayca göremiyorsunuz, ancak bazılarının en iyisini indirdim ve hatırladığım kadarıyla bunlar çoğunlukla C / C ++. TopCoder (popüler bir çevrimiçi programlama yarışması barındırma sitesi) çoğunlukla benzer sonuçlara sahiptir.

• Oldukça düşük seviyede olduklarından, ham çalışma süresi açısından kolayca C / C ++ 'ı yenemeyeceğinize eminim (ve Java’lar çok geride kalmaz ). Deneyimlerime göre, dinamik olarak yazılmış diller, statik olarak yazılmış dillerden çok daha yavaş olma eğilimindedir. En uygun çözüm bazı dillerde yeterince hızlı olmayabilir, ancak bu genel bir kural olmamalıdır.

• Doğru algoritma hayatidir. Baştan itibaren tüm problemleri (ayrıntılı olarak) nasıl çözeceğinizi biliyorsanız ve iyi, hızlı bir kodlayıcıysanız, hangi dili kodladığınızdan bağımsız olarak (o dilde en uygun çözümü varsayarak) kazanırsınız. yeterince hızlı).

• Düz hat sayısı o kadar büyük değil. Yeterli programlama deneyimine sahip olduğunuzda, 10 dakikalık 10 satır veya 200 satırlık programlama harcayabileceğinizi bileceksiniz, bunların hepsi satırların ne kadar karmaşık olduğuna bağlı. Ayrıca, yüzlerce kez benzer bir kod kodladıysanız, bu kadar çabuk bir şekilde bunu yapabileceksiniz. Makroların en iyi C / C ++ kodlayıcılarının kodlama zamanlarını optimize etmek için sıklıkla kullandıklarını da belirtmeyin.

• Frank, iyi bir noktaya değinir - (programlama yarışmalarının dışında), tüm kod üsleri C veya neyse, şirketinize yönelik Python'da kodlama yapamazsınız, dillerine uymanız gerekir.

• Diller arasında geçiş yapmak oldukça kolaydır, yıllarca süren algoritmik düşünme bilgisini geliştirmek kolay değildir. Diyelim ki neredeyse her mükemmel programcının bir hafta içinde başka bir (belli belirsiz) dile geçebileceğini iddia ediyorum. Belki o dilde programlama yarışmalarını kazanacak kadar iyi olmayabilir (2 hafta daha verin), ancak temel bilgileri aşağılayacaktır.

Aynı mantık C ++ 'ta daha iyi uygulanabilir mi? Tabii ki, daha iyi bir şekilde daha hızlı ve daha verimli bellek demek istiyorsan. Sorun, bunun için gereken çabanın önemli ölçüde daha yüksek olmasıdır. Ayrıca, teorik olarak hala daha düşük seviyelere inebilir ve daha uzun sürecek olan saf C veya hatta ASM'de uygulayabilirsiniz, ancak daha da optimize edilmiş bir kodunuz olabilir.

Tabii ki, Code Jam veya TopCoder gibi yarışmalarda, 40 satır vs 200 satır olduğu için bu bir biggie değil. Öte yandan, bu rekabet türünde en önemli şey algoritmanın zaman / mekan karmaşıklığıdır. Gerçek hayatta uygulama yaparken YMMV, bu tür yarışmalarda en yavaş dilde yazılmış O (n) algoritması her zaman en hızlı dilde yazılmış O (n²) 'yi yenecektir . Özellikle de en kötü senaryo olan çoklu test olacak.

Ancak yarışmalar dışında, eğer gerçek hayattaki büyük projelerden bahsediyorsak, o zaman artık 40 satır vs 200 satır değil. Büyük projelerde büyük kod tabanı sorun olmaya başlar. Hangi noktada almak için:

C ++ ile Python?

Saf Python yavaş. Bu nedenle, standart Python tercümanı (CPython) C'ye yazılmıştır. Pratik olarak hepsi, yüksek derecede optimize edilmiş olarak yazılmış yerleşik fonksiyonlara sahip olan Python, C kütüphaneleriyle ( ctypes veya yerel cpython modülleri olarak ) ve C ++ kütüphaneleriyle birlikte kolayca kullanılabilir. aracılığıyla Boost :: Python . Bu yolla, yüksek seviye mantığınızı esnek bir dil olan Python'a yazabilirsiniz, hızlı prototipleme ve uyarlama imkanı sağlar (bu, algoritmanızı geliştirerek ve geliştirerek daha fazla zaman geçirebileceğiniz anlamına gelir). OTOH, düşük seviyeli kütüphane işlevlerinizi C veya C ++ modülünde yazabilirsiniz. Böyle bir yaklaşımın en iyi örneği Python kütüphanesi olan SciPy'dir, ancak kaputun altında ATLAS, LAPACK, Intels MKL veya AMD'nin ACML'si gibi yüksek derecede optimize edilmiş sayısal kütüphaneler kullanır.

Bence insanların halkla “programlama dilleri” olarak düşündükleri aslında üç ayrı şeydir:

1. Dil türü ve sözdizimi
2. Dil IDE
3. Bir dil için mevcut kütüphaneler

Örneğin, bir kişi bir tartışmada C # yaptığında, dil sözdizimi hakkında konuştuğunu düşünebilirsiniz (1), ancak tartışmanın .net framework'ü (3) içereceği% 95 kesindir. Yeni bir dil tasarlamıyorsanız, yalıtmak (1) ve yok saymak (2) ve (3) zor ve genellikle anlamsızdır. Bunun sebebi IDE ve standart kütüphane “rahatlık faktörleri”, belli bir aracı kullanma deneyimini doğrudan etkileyen şeyler.

Son birkaç yıldır ben de Google Code Jam'e katıldım. İlk kez C ++ 'ı seçtim çünkü girişi okumak için iyi bir desteğe sahip. Örneğin, C ++ 'da standart bir girişten üç tam sayı okumak aşağıdaki gibidir:

int n, h, w;
cin >> n >> h >> w;

C # iken aynı şuna benzer:

int n, h, w;
string[] tokens = Console.ReadLine().Split(' ');
n = int.Parse(tokens[0]);
h = int.Parse(tokens[1]);
w = int.Parse(tokens[2]);

Bu basit bir işlevsellik için çok daha zihinsel bir yük. Çok satırlı girişle C # 'da işler daha da karmaşıklaşıyor. Belki de o zamanlar daha iyi bir yol bulamadım. Her neyse, ilk turu geçemedim çünkü turun bitiminden önce düzeltemediğim bir böcek vardı. İronik olarak giriş okuma yöntemi hatayı şaşırttı. Sorun basitti, girdi 32 bit tamsayı için çok büyük bir sayı içeriyordu. C # ' int.Parse(string)bir istisna ama C ++ dosya giriş akışı belirli bir hata bayrağını ayarlamak ve bir sorun olması masum geliştirici habersiz hale sessizce başarısız olur.

Her iki örnek de, kütüphanenin dil sözdizimi yerine nasıl kullanıldığını göstermektedir. Birincisi ayrıntı düzeyini ve diğeri güvenilirliğini gösterir. Birçok kitaplık birden fazla dile taşınır ve bazı diller kendileri için özel olarak oluşturulmamış kitaplıkları kullanabilir (bkz. @ Vartec'in C kitaplıkları ile Python hakkındaki cevabı).

Bunu sarmak için, doğru algoritmayı bilmek yardımcı olur. Kodlama yarışmalarında, özellikle uygulama zamanı ve hafıza gibi kaynaklar bilerek sınırlı olduğunda çok önemlidir. Uygulama geliştirmede memnuniyetle karşılanır, ancak genellikle çok önemli değildir. Bakım kolaylığı burada daha önemlidir. Doğru tasarım desenleri uygulayarak, iyi mimariye, okunabilir kodlara ve ilgili dokümantasyona sahip olarak elde edilebilir ve bu yöntemlerin tümü büyük ölçüde kurum içi ve üçüncü şahıs kütüphanelerine dayanır. Bu yüzden, ne tür tekerleklerin icat edildiğini ve kendiminkine göre nasıl uyduklarını bilmek daha önemli buluyorum.

Zamanlamalı programlama yarışmalarında yarışmak istiyorsanız, yarışmada izin verilen en etkileyici dili öğrenmelisiniz. Perl muhtemelen en iyisi olur, bunu Ruby veya Python izlerdi. Yine de algoritmalarla iyi bir tesise ihtiyacınız olacak, ama en azından böyle bir şey yazarken tıkanmayacaksınız.

Integer prev = b.get(k)
if (prev == null) prev = 0
Integer v = a.get(k);
if (v == null) v = 0;
b.put(prev + v);

yerine

b[k] += a[k]

Birkaç kütüphaneyi öğrenmek konusunda endişelenmeyin. Hepsi çok benzer ve belgeler çevrimiçi. Daha anlamlı dillerde akıcı olmak, sizi daha az anlamlı dillerde daha iyi (ama muhtemelen sinir bozucu) bir programcı yapacaktır. Tersi doğru değil.

NB

200 kod satırı ve 40 kod satırı arasındaki fark çok büyük ve 200.000 satırlık bir program ile 40.000 satırlık bir program arasındaki fark çok daha büyük. O zaman beş kişilik bir ekiple bir menajer ile bir veya iki kişilik bir ekip arasındaki fark bu.

Herhangi bir programlama dilinde herhangi bir algoritma uygulanabilir. Sonuçta, önemli olan sözdizimi değil. Ancak Python gibi yüksek seviyeli bir dil kullanmanın kendi avantajları vardır. Daha az iş ve daha az kodlama. Bu yüzden Python'da bir algoritma uygulamak için C gibi düşük seviyeli bir dilde gerekenden daha az satıra ihtiyacınız olacaktır.

Python, kütüphanesinde yerleşik olan veri yapılarının çoğuna sahiptir. Fakat C'de sıfırdan başlamalı ve hepsini inşa etmek için bir yapı kullanmalıyız. Elbette, yüksek ve düşük seviyeli diller arasında farklılıklar vardır, ancak dil, herhangi bir algoritma uygulamanızı engellememelidir.

"40 LoC - 200 LoC" örneğini ileri sürerken, "iyi, toplam LoC’nin sadece beşte biri yazmanın daha hızlı olması ve böylece daha iyi olması gerektiğini" söylemesinin cazip gelebileceğini düşünüyorum.

En az LoC için optimizasyon yapmak bence neredeyse hiç iyi bir fikir değildir. Evet, yazılan her LoC hatalar için bir potansiyeldir ve asla etcetc yazdıklarınızı asla hata ayıklamak zorunda kalmazsınız. Mesele şu ki, okunabilirlik ve ayrışma için optimize edilmiş. Bir 1k LoC modülü yazmak yerine, 20 satırlık büyük bir regex kullanarak bir sorunu çözmeniz farketmez. Regex, opak bir duvar, son derece hatalara açık, anlaşılması zor, kabusunu değiştirilemez şekillerde değiştirmeden değiştirmek için kabus gibi olacak.

Herhangi bir değer katmayan tek parça ve ayrıntılardan kurtulmak her şey yolunda ve iyidir, ancak diğer yandan, Java veya C # gibi bir şey kullanmak, tasarım desenleri ve yeniden yazma gibi araçlar hakkında bilgi sahibi olmak, kodu yeniden yapılandırmada çok esneklik sağlar , zamanla temizleme, işleri parçalama vs.

Çok açıklayıcı bir karşılaştırma: Ben sadece "işleri halletmek" 20k bir python uygulaması yerine strateji desen, fabrikalar vb "overkill" şeyler ile dolu test kaplı decoedled C # kodu, 100k LoC olurdu. 5 kat daha fazla kod yazsanız da her gün mimari kazanır.

Bazı çalışma türlerinin bazı dillerde daha kolay ve daha uygun olduğuna tamamen katılıyorum, ancak hangi araçlara ve gereksinimlerin ne olduğuna (ve yakın gelecekte olabilir) dayalı olarak dilinizi seçmeye daha fazla inanıyorum.