Araçlara aşırı güvenmek, tembel olduğunuzu ima ediyor mu? [kapalı]

Üniversitede C ++ 'da programlamaya başladım ve çok sevdim Gelecek dönemde VB6'ya geçtik ve bundan nefret ettim.

Neler olup bittiğini anlayamadım, bir düğmeyi forma sürükleyin ve ide kodu sizin için yazar.

VB'nin çalışma şeklinden nefret etmeme rağmen, aynı şeyi C ++ 'da yapmaktan daha hızlı ve kolay olduğunu iddia edemem, bu yüzden neden popüler bir dil olduğunu görebiliyorum.

Şimdi VB geliştiricilerini sadece C ++ 'dan daha kolay olduğunu söylerken tembel olarak çağırmıyorum ve bu eğilimi C # gibi bir çok yeni dilin takip ettiğini fark ettim.

Bu, daha fazla işletme hızlı sonuç almak istedikçe daha fazla insanın bu şekilde programlanacağını ve er ya da geç, şimdi programlama olarak adlandırdığımız hiçbir şeyin olmayacağını düşünmemi sağlıyor. Gelecekteki programcılar bilgisayara ne istediklerini söyleyecek ve derleyici star trek'teki gibi onlar için programı yazacaktır.

Bu sadece bir küçük programcının bilinçli bir görüşü mü yoksa programcılar daha temkinli ve daha az yetkin mi?

EDIT: Bir çok cevap, tekerleği neden icat ettiğini söylüyor ve ben buna katılıyorum, ancak uygun tekerlekler varken insanlar tekerleğin nasıl yapıldığını öğrenmek için can sıkmıyorlar. Herhangi bir dilde hemen hemen her şeyi nasıl yapabilirim google ve hata ayıklama geldiğinde dillerin yarısı sizin için bu kadar çok şey yapmadan hatayı düzeltmek için orada kod ne yaptığını hiçbir fikrim yok.

Bu şekilde, programcıların tembelleşip daha az yetkin hale geldiği teorisine katlanıyorum, çünkü hiç kimse, işlerin böyle olmadıkça nasıl çalıştığını umursamıyor.

Hayır, geliştiriciler daha temkinli veya daha az yetkin değil. Evet, gerçek gelişim için, bildiğiniz anlamında giderek azalan bir ihtiyaç vardır. Ve evet, bu çok fazla, çünkü işletmeler hızlı sonuç almak istiyor ve neden olmasınlar?

Ancak, bir son nokta var. Bazı geliştiricilere her zaman ihtiyaç duyulacaktır.

Farklı projeler arasında birçok gereksinim aynıdır. Bahsettiğin tek UI kodu. Kullanıcı arabirimlerinin çoğu belirli bir alan kümesinden oluşur - metin kutusu, onay kutusu, radyo, seçim vb. - ve bunları sıfırdan tekrar tekrar geliştirmenin hiçbir anlamı yoktur. Bu yüzden soyutlama katmanları tüm bu kazan plakası kodunu almak için konur.

Aynı şekilde, genellikle bu işlemden başka bir şey olmayan veri katmanını, Bunu Ekle, Bunu Sil, Bunu Değiştir ve aynı verilerin çok sayıda farklı görünümleri. Neden tekrar tekrar yazmaya devam ettin? ORM'leri icat edelim.

Geliştirmeniz gereken tek şey, geliştirdiğiniz işletmeye özgü koddur.

Ancak her zaman bu benzersizlik olacaktır - olmadığı yerde, bir iş fırsatı vardır - ve her zaman insanların kod yazması için bir ihtiyaç olacaktır.

Tüm bunlar, kod geliştirmekten çok geliştirici olmanın çok fazla olduğunu da aklınızda tutuyor. İster saf bir montajda kodlama yapıyor olun, ister içerik odaklı bir site yapmak için Drupal bileşenlerini bir araya getiriyorsanız, işletme gereksinimini bilgisayarın anlayacağı bir şeye dönüştürüyorsunuz.

Bir yazılım geliştiricisi olmanın en önemli kısmı, iş gereksinimini bilgisayara açıklamak için yeterince iyi anlayabilmektir.

Bir şeyleri bilgisayara açıklamak için hangi dili kullandığınız önemli değil, sadece sizin için önemli. Ve bu zor bir iştir, bu konuda tembel bir şey yoktur.

Tamirci tembel ve daha az yetkin mi çünkü hidrolik bir anahtar kullanıyor ?

Resim iki adam, diyelim ki Brad ve Pete. Her ikisi de günlük olarak lastik değiştiren iki garajda çalışıyor. Brad akıllı bir adam, daha iyi araçlar kullanmanın işini daha iyi ve daha hızlı yapabileceğini biliyor. Hidrolik anahtarın kullanılması, daha fazla lastik değiştirmesine yardımcı olur. Müşteriler daha kısa bir sırada bekliyorlar - herkes mutlu. Bard ayrıca bu anahtarın bazen çok büyük olduğunu ve farklı vidalarla ona yardımcı olamayacağını da biliyor.

Öte yandan, Pete hidrolik anahtarın küfür olduğunu ve Brad'in “gerçek bir mekanik” olmadığını söylüyor. Tabii ki Pete Brad'in yaptığı şeyin yarısını yapabilir, ama bunu “doğru şekilde” yapıyor.

Şimdi, hangi garaj müşterilerini seçeceğini düşünüyorsunuz? Biri 20 dakika veya 40 dakika bekleten biri.

Programlamaya oldukça benzer. C ++ iyi bir dildir ve amacına sahiptir (çoğunlukla performans). C # gibi diller hakkında sevdiğim şey, bir soruna odaklanabildiğim, C ++ 'nın belirsiz derleyici uyarıları, tanımsız davranışlar ve benzeri şeylerden hoşlandığı tüm gürültü olmadan algoritmayı düşünmek. Gelişmek gittikçe daha da karmaşıklaşıyor, eski günlerde ana bilgisayar ve ilk PC'lerde, ancak insan beyni aynı kalıyor - neredeyse aptalca. Bir uygulama bulutta çalışabilir, mobil, masaüstünde çok fazla bağımlılık, güvenlik sorunu ve diğer sorunlar var. Daha karmaşık sorunlara odaklanmak ve bunları çözmek için daha iyi bir araca sahip olmak istiyorum.

İşi bitirmek için daha iyi araçlar kullanın; bunun yanlış bir yanı yok.

Peki şimdi programlamaya ne diyoruz?

Diyorsun:

Gelecekteki programcılar bilgisayara ne istediklerini söyleyecek ve derleyici star trek'teki gibi onlar için programı yazacaktır.

sadece bir deney yapın: Star Trek'i izleyin ve bilgisayarın biraz 'zarif' yapması için verilen emirleri yorumlamaya çalışın.

• Çay, earl grey, sıcak -> çok fazla buhar.
• Çay, earl grey, 60 santigrat derece -> bir su birikintisi ve buhar bulutu
• earl grey, 60 santigrat derece -> bir su birikintisi
• earl grey, 60 santigrat derece, bir bardağa -> içinde bir damlası olan bir bardak
• earl grey, 60 santigrat derece, 0.2 litre, bir kap içinde. -> Sonunda (tamam, daha fazla nitpick olabilir)

Programlama: 'Hafıza kullanımı, işaretçiler, vb.

Ancak, benim görüşüme göre, hepsinin 'tesadüfi karmaşıklık' olduğunu ve programcı olarak asıl Mesele, 'Makinelerin inşa edilmesini sağlamak, birinin görevi başarmak için tesadüfi problemleri yeterince anlamasını sağlayarak' ve bu tanımla konuşan bir kişi. Bir star trek bilgisayar ile bir programcı olması gerekir (yani şimdiki gibi aynı erdemlere sahip).

Programcılar tembelleşmiyorlar. Programcılar her zaman tembel olmuştur. Tembel olmak işin temel doğasının bir parçasıdır. Sorun, insanların tembel olmanın olumsuz olduğunu varsaymalarıdır."Tembel" bir programcı olmak bir erdemdir.

Eski atasözünü hatırlayın, "Daha akıllı, daha zor değil." Bu programcıların temel itici gücüdür.

İlk bilgisayarları yapan ve programlayan adamlar yapmazlardı çünkü çok çalışmayı sevdiler, AVOID'e yaptılar da zor işi. (elle yapılan hesaplama sayfalarını yapıyor)

'Tembel' olmak, programcıların program yapmasının temel nedenlerinden biridir. Bu yüzden yeni ve her zaman daha yüksek seviyeli diller yazıyoruz, daha iyi ve daha iyi hata ayıklayıcıları ve IDE'ler, kabuk yazıp kodlar yazıyoruz ...

Bir programcı bir soruna bakar, yaptığı ve yaptığı her şeyi düşünür;

"Bunu otomatikleştirebilir miyim?" , "Bu ne kadar zaman alır?" , "Bu bana ne kadar zaman kazandırır?"

Bunu yapıyoruz çünkü tembeliz, çok daha eğlenceli şeyler yapabilirken tekrarlayıcı ve sıkıcı bir iş yapmak istemiyoruz.

Eğer programcılar tembel olmasaydı, o zaman hiçbir programcı tek bir dil veya derleyici yazma gereği duymazdı.

Bir programcının “tembel” olduğu nosyonuna gelince, çünkü “bir şeylere bakmak” zorunda kalıyor, öyleyse ne, kimin umrunda. Belirli bir dilin her bir nüansını öğrenmenin (ve asla bir şey aramanıza gerek kalmamayı) öğrenmenin daha fazla işe yaradığı varsayımı, o zaman ihtiyacınız olduğunda ihtiyacınız olan şeyi bulmak ve kullanmak yanlıştır. Ayrıca, şeyleri arama süreci öğrenme sürecidir ve bunun gibi sitelerin varlığının nedeni de budur.

Birisi zor programlama çalışması istiyorsa, ondan hex'e bazı ham makine kodlarını el koduna koymalarını söylerdim. Bunu yaptın mı? Daha sert bir şey ister misin? Şimdi git hata ayıkla.

Öncelikle, örneğin çöp toplayıcı tembelli dilleri kullanan insanları arayan kişiler, otomatik şanzıman tembelli araba kullanan insanları çağırıyor. IMO biraz saçma.

Yetkinlik gelince, programlama eskisi gibi daha popüler ve eşitlikçi bir iştir. Yani evet, bilgi sahibi olmayan birçok yeni insan var. Ancak, birdenbire daha az yetkin programcılar olduğu anlamına gelmez. Aslında daha var. Sadece çan eğrisinin yanlış tarafına bakıyorsun.

"Evet, bilgisiz düşünülmüş genç programcılar tembel ve daha az yetkin hale geldi" demeye cazip geliyorum, ancak ciddi bir cevap deneyelim:

Birçok şey kolaylaştı, ama bizden daha çok bekleniyor. Şu anda genellikle iyi yapılmış GUI uygulamalarında (sekmeli görünümler, düzenlenebilir ve sıralanabilir ızgaralar, Excel dışa aktarma vb.) Bulunan birçok özelliğe sahip bir web uygulaması oluşturuyorum. Kullandığım araçlar (ExtJS vb.) Böyle bir uygulama oluşturmayı oldukça ucuz hale getiriyor.

On yıl önce, böyle bir uygulamanın oluşturulması neredeyse imkansız, en azından çok pahalı olurdu. Ancak on yıl önce, HTML tablosu içeren basit bir HTML formu müşteriler için yeterli olurdu. Bugün, aynı çabayla, daha iyi (en azından daha güzel) sonuçlar elde etmek mümkün ve müşteriler bunları almayı bekliyor!

Genel olarak, bugünün bir yazılım geliştiricisinin 20 yıl önce bir yazılım geliştiriciden daha fazla dil bilmesi gerekir. O zamanlar, C ve SQL gibi bir şey yeterliydi. Bugün aynı projede JavaScript, HTML, Groovy, Java, SQL kullanıyorum.

Programcılar bazı yönlerden daha az yetkin ve tembelleşiyorlar, ancak diğerlerinde daha da yetkin oluyorlar, ancak C ++ / VB bölünmesi aklımdaki sebep veya semptom olmasa da.

Bir GUI oluşturucusunu kullanmak tembel değildir, sadece farklıdır, eldeki iş için araçlar hakkındadır. Eğer bir assembler programcısı tembel bir C ++ programcısı çağırırsa, bunun üzerine saçmalık diyecektiniz (haklı olarak) ve aynısı C ++ ve VB için de geçerli. VB, bazı kontrollerin pahasına hızlı bir şekilde bazı şeyler yapmanızı sağlar. Kodlamaya başlamanın önündeki engeller kesinlikle daha düşüktür ancak bu tembellikten çok farklı bir şeydir - sadece farklı şeyler öğrenir ve bunları farklı şekillerde uygularsınız. VB programcıları C ++ programcılarının verimsiz olmalarından daha tembel değil, sadece farklı şekillerde çalışıyor ve üretiyorlar.

Daha geniş bir noktada, genellikle programcıların eğitimi şimdi olduğundan çok daha iyidir. Örneğin kaynak kontrolü kullanmama fikri, 10 ya da 20 yıl önce bu kadar doğru olmazdı, hemen hemen herkes için oldukça iğrenç. Benzer şekilde, otomatik birim testleri, sürekli entegrasyon ve benzeri şeyleri anlama ve kullanma olasılıkları daha yüksektir, bu nedenle bu anlamda olduklarından daha yetkinler.

Fakat değiştiğini düşündüğüm şey, insanların artık eskisi gibi nasıl çözüleceğini bilmediği ve bunun çoğu ana dilde doğru olduğu anlamına geliyor. Şu anda herhangi bir soruna anında yanıt Google ve bu harika ve zamanın% 95'inde çalışıyor olsa da, ne zaman yapılacağı konusunda hiçbir fikri olmayan çok sayıda programcı görüyorum.

Temelleri anlamadıklarından değil (anlamıyorlar ama bu aslında o kadar önemli değil), sorunları temelden çözebilecekleri bir şekilde çözemezler. sarhoş olmak.

Google’dan başka seçeneğiniz yoktu. Kaynakların takımındı, erişebileceğin birkaç düzine fiziksel kitap ve beynindi. Bu, bir sorun bulduğunuzda, şansınızı ilk müdürlere yakın bir şeyden kendiniz çözdüğünüz anlamına gelir, bu yüzden ya bu konuda oldukça iyi ya da hızlı bir şekilde işsizsiniz.

Ve bu, hangi dili kullandığınızdan bağımsız olarak doğruydu. VB yüksek seviyededir ve çok fazla gizler ancak bu, sorun çözme konusunda, aslında çalışmak için daha çok ihtiyaç duyduğunuz anlamına gelir. Eğer bir şey işe yaramadıysa, daha yaratıcı olmalısınız ve daha az kontrolünüz olduğu için daha çok çalışmalısınız. Bir VB programcısı olarak (ve deneyimlerden söz ediyorum) C ++ 'dan daha az şey bilmiyorsunuz, sadece farklı şeyler biliyordunuz ama ikiniz de problemleri nasıl çözeceğinizi biliyordunuz.

Ancak, bugünlerde programcıların önemli bir eleştirisi olarak görmek muhtemelen zor, yeteneklerini geliştirmiyorlar, çünkü onlara ihtiyaç duymuyorlar, ancak gerektiğinde becerileri alanlara göre zayıf bir durum.

Profilinizden 23 yaşında olduğunuzu not ediyorum. Dişlerimi takmama izin verin ve size uzun zamandır bunu yapan iki yaşından birinden bir bakış açısı vereyim:

Bir ağınız varsa, hesaplama gücü, depolama ve ağ bant genişliğinden başlayarak, her şeyden çok daha azının olması eskidendi. Bu kıtlıklar, mantıklı olabileceğiniz şeylere sınır koyar ve başınızı her yere sarmayı çok kolaylaştırır. Bugün çalıştırdığımız yazılım, 25 veya 30 yıl önce çalıştığım işlerden çok daha fazla yetenekli ve bu yetenekler çok daha fazlası olduğu anlamına geliyor. Bu, bir kişinin yapması gereken her şeyi ince taneli bir anlayışla bir araya getirmeyi zorlaştırıyor. Bunun bir kısmı işlerin karmaşıklığı artırmaya devam edeceği ve bir kısmının yaşın yan etkileri ile ilgisi olduğu gerçeğiyle ilgili.

Bilgi işlem ekosistemi biyolojik sistemlere çok benziyor: insanlar tek hücreli organizmalardan daha karmaşık ve bir şey yapmanın iyi olacağını düşünürsek bir kısmı uzmanlaşmamız gerekiyor. Beyin hücrelerim zeki şeylerde çok iyidir, ancak böbreğime batırılırsa ve böbrek şeyler yapması bekleniyorsa kaybolur. Benzer şekilde, dijital sinyal işlemcileri yazma konusunda iyi olan adam tam metin indekslemenin nasıl çalıştığını bilmiyor olabilir, çünkü bu onun uzmanlığı değil. Ancak her ikisi de biraz gelişebilir ve gerektiğinde anlamayı öğrenebilir, ancak kendinizi ne kadar yayabileceğiniz ve hala ne yaptığınızda etkili olabileceğiniz konusunda sınırlamalar vardır.

... hiç kimse hiçbir şeyin, işe yaramayana kadar nasıl çalıştığını umursamıyor.

Yapacak bir işiniz olduğunda, sıklıkla kullandığınız bir aracın (kütüphane, RDBMS, tüm alt sistemler vb.) Olması gerektiği gibi çalıştığına inanmanız gerekir. Tecrübe getiren şeylerden biri, aletlerinizdeki hataları ortadan kaldırmak için kaçacağınız tavşan deliklerini seçme, problemi çözme ve daha sonra yaptıklarınıza geri dönme yeteneğidir.

Şimdi VB geliştiricilerini sadece C ++ 'dan daha kolay olduğunu söylerken tembel olarak çağırmıyorum ve bu eğilimi C # gibi bir çok yeni dilin takip ettiğini fark ettim.

Hepsi bu bakış açısı meselesi. C ++ 'ın ortaya çıktığını görmek üzereydim ve bu eğilimi de takip ediyor. C ++ işleri C'den daha kolay, C ise montajdan çok daha kolay, montajı elle yapmaktan daha kolay. Çok fazla montaj yazan ve sıfırdan elle birkaç şey toplayan biri olarak, bu sizi bir C ++ programcısı olarak “daha ​​kolay” yoldan üç adım aşağı indirecektir.

Uzun süredir sakladığım bir şey:

Visual Basic Dilinin en güçlü yönlerinden biri, bir aceminin çok faydalı şeyleri oldukça hızlı bir şekilde yapmayı öğrenebilmesidir.

Visual Basic Programcılarının en zayıf noktalarından biri, çok sayıda faydalı şeyi oldukça hızlı bir şekilde yapmayı öğrenecekleri ve ardından bir şey öğrenmeyi bırakacaklarıdır.

İlk alıştırmayı programlamayı öğrettiğimde, sınıfın ilk günü NOTEPAD'da bir uygulamanın nasıl kurulacağını ve VCC ya da VBC kullanarak nasıl derleneceğini öğretti. Evet, bunlar (programcılar olarak) günlük olarak yapamadığımız şeylerdir, ancak "F6" ya bastığımızda neler olduğunu anlamamız gerekir.

Programcılar (genellikle) araçlarımızdan daha fazla yararlanmayı beklediğimiz kadar “tembel” olamazlar. Günde 10.000 kez "get / set" yazmaya gerek yok, Visual Studio ve Code Smith ve Resharper gibi diğer araçların benim için zaten yapmam gerektiğini bildiğim şeyi yapmak için çalıştığını düşünüyorum. "yeni" şeyler nasıl yapılır. Bu beni tembellik etmez, bu da beni "inovatif" yapıyor.

Profesyonel bir geliştirici olarak, tekerleği yeniden icat etmek için 'zaman kaybetmek' olmamalıyız, ancak kullanacağımız tekerleği yapmanın ne işe yaradığını açıkça anlamalıyız. Bunlar, öğrenci geliştiricileri olarak öğrenmemiz gereken şeylerdir (ama ne yazık ki, çoğu zaman değil). Bir geliştirici bazı "kara kutu" teknolojisini anlamıyorsa, bu onları gerçekten daha az "yetkin" yapar. Çoğu geliştirici yalnızca bir ODBC sürücüsünün nasıl çalıştığını “temelde anlar”, sadece ne yaptığını anlar. Bir şanzımanın uzman bir sürücü olmak için nasıl çalıştığını bilmek zorunda mıyım? Ben söylemezdim. Bunu bilmek beni daha yetkin bir araç sahibi yapıyor mu, evet.

Hızlı Uygulama Geliştirme İhtiyacı (zorunlu wiki bağlantısı: http://en.wikipedia.org/wiki/Rapid_application_development) ), geliştiricilerin daha az kod yazması ve daha yeni geliştiricilerin daha az anlaması gerektiği anlamına gelir çünkü bir uygulamanın nasıl uygulanacağını anlamalarına gerek yoktur. odaklanacak daha yüksek bir seviyeye sahip oldukları için bağlantılı liste.

Yakalayamam, öldüremem, cildim, kasabım ve eti tedavi edemem ve alt kattaki kafedeki adamın yapabileceğinden şüpheliyim, ama hala pastırma sandviçimi ondan alıyorum; işaretçiler (benim gibi!)

Büyük bilimsel disiplinlerin, diğer devlerin omuzlarında duran devlerin örnekleri olduğu söylenir. Yazılım endüstrisinin, diğer cücelerin parmak uçlarında duran cücelere bir örnek olduğu da söylenmiştir.
- Alan Cooper

İyi bir yazılım geliştirici, tekerleği yeniden icat eden değil. Kendisinden önce yapılmış araçları kullanabiliyor. Yüzlerce kez yazılmış, aynı eski sıkıcı şeyleri yeniden yazmak için zaman harcamaz, çabuk yorucu hale gelir ve muhtemelen zaten daha yüksek kalitede bir sürümde var olur.
Onlara zaten yuvarlak taş diskleri olan bir dil verirseniz, tekerleklerin yeniden icat edilmesi için çok fazla zaman harcamama ihtimali yüksektir. Şimdiye dek C'ye yazılan her string kopya rutini için bir kuruş varsa, muhtemelen tüm yazılım endüstrisini satın alabilirim.

Tembellik aslında bir programcının üç büyük erdeminden biridir. Bahsettiğiniz araçlar, fazlalık ve sıkıntıyı azaltmak ve böylece verimliliği ve motivasyonu artırmak için iyi programcılar için iyi programcılar tarafından oluşturulmuştur. Bu tür araçlar aslında yeni başlayanlar üzerinde olumsuz etkilere neden olabilir , çünkü basitleştirdikleri programlama yönünün daha derinden anlaşılmasını engellerler.

Hayır. Sadece yaşlanıyorsun.

Şaka yapmamak, deneyimlediğiniz şey geliştiriciler için bir tür geçiş hakkıdır. Ilk üst düzey diller meclis takviyesi beri beri olmuştur. O zamanlar tüm ASM programcılarının aynı şeyden şikayet ettiğini duymuş olacaktınız. Bundan 5 yıl sonra, tüm Ruby on Rails geliştiricileri, başka bir yeni araç ürününün insanları ne kadar tembel hale getirdiğinden şikayet edecek.

Bu geri çekilme, makineler hepimizi yok edinceye kadar tekrarlanacak: "X teknolojisi, geliştiricileri her zaman kullandığım Z teknolojisinden daha tembel ve daha kötü hale getiriyor mu?"

İyi haber şu ki, derleyiciler uzun bir yol kat etse de, insanlar hala montaj ve C'ye ve diğer tüm eski bölümlere ihtiyaç duyuyorlar. Bu alanda olmak istiyorsanız, beceri setinizi güncellemenizi öneririm.

Tecrübelerime göre, evet ve hayır, fakat bu dillerin hatası değil; geliştiricilerin kendileri de suçtur. Bir şeyleri doğru yapmak, kendilerini geliştirmek ya da gerçekten yıllarca yaptıkları saçmalıklardan başka bir şey yapmaktan başka bir şey yapmayan birçok geliştiriciyle çalıştım. Bu insanları iyileştirmeye çalışmak bir tuğla duvarla konuşmak gibidir - geçmişte kullanmadıkları hiçbir şeyi bilmezler ya da üretkenliklerini artırabilecek bir şeyle "şansını denemek" için tamamen isteksizdirler. .

Daha gelişmiş diller sorun değil, bu mesleği sürekli gelişen bir zanaat olarak görmeyen programcılar. Yeni olan her şeyin yakından farkında olmanız veya her yeni grup kavisine atlamanız gerekmez, ancak en azından yaptığınız işte daha iyi olmaya çalışmalısınız .

Somut bir örnek için: Ben bir ticaret geliştiricisiyim. Yetkili bir .NET geliştiricisinin LINQ, Entity Framework, WPF, MVC ve benzeri şeylerin farkında olmasını beklerdim ; onu kullanmak zorunda değiller ya da işyerinde zorlamak zorunda değiller, ama en azından "Bu var" lafı anlamak çok sık gördüğüm mutlak ipuçsuzluğundan daha iyi.

Şu an sadece 4 yıldan beri kodlama yapıyorum ve bu neredeyse tamamen c # oldu. Kolej ve Uni'deyken C ++ 'ı öğrendim, ancak şu anda fazla bir şey yapamam.

Dolayısıyla GUI gelişimi için tembel olarak görülebilir, ancak daha sonra uygulamanın kendisinin mantığını geliştirmeye o kısmı kodlamaya daha az odaklanabileceğinizi göremezsiniz.

belki de daha az yetkin olmak yerine, odağı hareket ettiriyorlar, muhtemelen iletişim ve dağıtık sistemlere, örneğin bulut bilişim ve SOA'ya doğru. Yine de, bu aynı zamanda bir ara programcının da benzer düşünceleri olabilir.

Programlama işlerine girişin önündeki engelin her yıl daha da azalmakta olduğu doğrudur. Örneğin, uzmanlık alanı esas olarak yazılım olmayan mühendisler ve sanatçılar komut dilleri kullanarak kod yazabiliyorlar.

Bu, eğer genişliği düşünürseniz, yeterlilik seviyesinin gerçekten arttığı anlamına gelir. Sanatçıların programlayabildiği, artık sanatsal becerilere sahip daha fazla programcı olduğu anlamına geliyor.

“Programcı” ile “gerçek programcı” arasında bir fark vardır. Lütfen HTML'yi bir programlama dili olarak adlandırmayın, ancak birçok "HTML programcısı" vardır. Her biriniz (programcılar / geliştiriciler) meslektaşlarınızla bir deneyim yaşayabilirsiniz - sadece "İnterneti kapatın (aslında arama motorlarını kullanmalarına izin vermeyin)", ve çok çeşitli "programcıların" oturacağını göreceksiniz işsiz. Ne yapabilirler ki, örneğin, metin içinde arama yapmak istiyorlarsa, ''% language_name% 'içinde metin arayarak' 'aramaları gerektiğini biliyorlar mı? Buna cevap veremezler - Boyer-Moore ve Knuth-Morris-Pratt algoritmalarındaki farklar nelerdir?

Bu yüzden, IMO, programlama, 'STL' ve diğer önemli şeylerle en az bir programlama dili kadar iyi tanımak, problemleri çözmek demektir. Programlama bir sanattır, bir tür yaşamdır, bu herkes tarafından yapılabilecek bir şey değildir.

İhtiyaç duyduğumdan daha fazla alay için üzgünüm ama bence bu makale benden daha iyi

Yanlış mıyım?

UPD: Asıl ve önemli olan, algoritmalar, veri yapıları vb. Gibi temel bilgilerdir. Günümüzün yanlışlıkla kaldırılması durumunda kaç kişi kütüphaneleri / standart işlevler / vb. Uygulayabilir? IMO, programcı gelişmiş / hata ayıklanmış 'yabancı' kodunu kullanmalı (kütüphaneler / çerçeveler / vb.), Ancak tekerleği her zaman yeniden icat edebilmelidir!

VB'nin kullanımı kolay olması ve bu nedenle VB'yi seçtiği tembel programcıların:

VB'nin kullanımı kolay olmanın büyük bir efsanesi olduğunu düşünüyorum. Bu efsane aslında biraz gerçekti: 1991-1994 yıllarında dinozorların yeryüzünde yürüdüğü günlerde, VB ve Delphi civarında sadece iki gerçek RAD aracı vardı. Oldukça benzerdiler, ancak NOT NOT: Delphi ve VB'nin kullanımı da aynı derecede kolaydı! Aralarındaki tek fark, VB'nin tamamen mantıksız sözdizimine sahip olması ve inanılmaz derecede halsiz programlar üretmesiydi.

C / C ++ GUI MFC veya ham Win API ile yazılmıştır. Bu yüzden VB kullanmak Microsoft alternatifinden kesinlikle daha kolaydı. Sonra söylenti değirmeni böyle gitti:

• VB, Microsoft C / C ++ / Win API'sinden daha kolaydır. ->
• VB kullanımı daha kolaydır. ->
• VB kullanımı kolaydır. ->
• VB en kolay olanıdır.

Pascal'ın aklı başında ve mantıklı bir dil olduğu için Delphi her zaman eşit derecede kolay olsa da bu söylenti yaşadı.

Ardından 90'ların sonunda Borland, Delphi: C ++ Builder ile aynı C ++ değerine sahip. Şimdi 3 eşit derecede kolay araç vardı. Bu süre zarfında, VB'yi kullanmak için kalan birkaç rasyonel argüman öldü. Oysa efsane hala yaşadı. "VB en kolay olanıdır".

Sonra Java geldi ve bunun için birkaç RAD aracı vardı (ve J ++ adı verilen Microsoft fiasco sürümü için). Oysa VB efsanesi yaşadı.

Daha sonra Microsoft, RAD'yi C ++ için de destekledi ve ayrıca C # ile geldi ve hepsini .NET adında tek bir büyük goo haline getirdi. VB efsanesi hala yaşadığından, eski VB geliştiricilerini C ++ veya C # yerine VB.NET kullanmaları için kandırdılar. VB.NET daha önceki VB sürümleriyle uyumlu değildi.

Bugün, VB tamamen yedekli bir dildir. RAD aracı diğer RAD araçlarından daha kolay değildir. Dil sözdizimi düpedüz korkunç, o kadar kötü ki aslında kötü program tasarımını ve kötü programlama uygulamasını teşvik ediyor.

“Programlama” başlığı altında toplanmış çok çeşitli aktiviteler ve ölçeğin “teknisyeni” sonunda yer alan çok sayıda çalışan vardır. PHP'de bir web sitesi oluşturmak için belirli bir sorunu çözmek için derleyiciler yazabilme veya bir dizi algoritma arasından seçim yapma yeteneğine bile ihtiyacınız yok. Endüstri / toplum, söz konusu web sitelerini (görünüşte) üreten birçok insana ve ayrıca daha zor problemler için çalışan belirli sayıda programcıya ihtiyaç duyar. Bu ikinci grup tembel ya da beceriksiz değil, bir bütün olarak, ya da uçaklarımız alevler içinde inecek, rasgele miktarda nakit sağlayan ATM'ler, ölümcül radyasyon sağlayan X Ray makineleri, finansal piyasalar yükseliyor vb. Bu sonuncusu hakkında :-)

Bunun bir yanı diğer tüm cevapların sadece göze çarpan olduğunu düşünüyorum, bunun sadece düşük seviyeli dillerden yüksek seviyeli dillere giden genelleştirilmiş bir eğilim olduğudur.

Evet, yazılım endüstrisi, düşük seviyeli dillerden yüksek seviyeli dillere doğru kaymaktadır, her zaman daha iyi araçlar ürettiğimiz sürece bunu yapmaya devam edecektir. Evet, bugünün standartlarına göre temel olan işleri yapmak için çok çalışmak zorunda olduğunuz için tembelleşmek olarak kabul edilebilir. Ama daha az yetkin diyemeyeceğim. Yetkinlik sadece uygulamadan tasarıma geçiyor.

Düşük Seviye Biraz öznel, ancak düşük seviyede donanıma daha yakın çalışıyorsunuz. El tutma ve niyet varsayımları daha azdır. Temel araçlar sunulur ve yapılması gerekenler programlayıcıya bırakılır. Tabii ki ilk önce düşük seviyeli diller geldi ve genellikle eski muhafızların araçlarıydı çünkü yüksek seviyeli diller başladıklarında yoktu. Her zaman bazı düşük seviyeli gelişme olacak. Ancak mecliste bir web sitesi yapmazdım.

Yüksek seviye amaç, temel işlevleri otomatikleştirmek ve programlamayı kolaylaştırmaktır. Yeni programcılar için girişe çıtayı düşürür, işleri daha hızlı yapar ve genellikle bir genel giderle verileri nasıl temsil ettiğimizi ve işlediğimizi standartlaştırır. Bir dize düşünün. İlk günlerde biri muhtemelen az önce 1-26 kullandı ve sadece 5 bit kullandı ve sadece kelimelerinin ne kadar olduğunu bilmek zorunda kaldı. Sonra ascii standardı geliştirildi ve sonlandırıcı karakterli C dizeleri vardı. Artık arabellek taşmalarını ve kaçış karakterlerine izin vermeyen özel alt türleri önlemek için işleri yapan nesnelerimiz var. Veya bir döngü. Bir "for" döngüsü, bir "while" döngüsünden çok daha yüksek bir seviyeye gelir. Ve bir "süre" döngüsü gerçekten GOTO'yu çağırmanın yapılandırılmış bir yolunun temsilidir.

Ayrıca,

Gelecekteki programcılar bilgisayara ne istediklerini söyleyecek ve derleyici star trek'teki gibi onlar için programı yazacaktır.

Geleceğe Hoşgeldiniz! Derleyiciler böyle yapar. Eski günlerde insanlar makine kodunu elle yazmak zorunda kaldılar. Şimdi bunu otomatikleştirdik ve bilgisayara sadece makine kodunu bizim için nasıl yazdığını anlattık.

Sanırım program boyunca ne kadar para ödeyeceğine dair görüşünü kaybettiğin bir yer boyunca.

Verilebilecekler Kod değil, çalışan bir yazılımdır.

Elle kesilen kırlangıçların bir şekilde içine giren tüm el işçiliği nedeniyle ekstra değer verdiği yerlerde mobilya yapmıyoruz.

Bilgisayardaki iş sorunlarını çözmek için para alıyoruz). Aynı ürünü daha az parayla daha kısa sürede teslim ederseniz o zaman C ++ programlarının inşa etmek için daha karmaşık oldukları için üstün olduğu iddiasını düşürmek zorunda olduğumuzu düşünüyorum.

(Çekirdek program geliştiricileri / geliştirici sayısı) oranı düşüyor çünkü:

• Araçlar kolaylaşıyor, bu aynı problem için daha küçük yeteneklerin gerekli olduğu anlamına geliyor

• İnsanlar BT teknolojilerine alışmaya başladı, bunun için özelleştirilmiş araçlar için para harcamaya daha istekli

• Bilgisayar Bilimi edebiyatı katlanarak büyüyor, uzmanlık ve iş bölümü artıyor, bu yüzden her şeyden bahseden "Aristoteles" insanı yok (aslında soyutlama katmanları nedeniyle her şeyi bilmeleri gerekmiyor)

• Daha fazla iş teklif edildi, filtre gevşetildi

• Her yaşam döngüsünde daha fazla otomasyona ihtiyaç var, talep artıyor ve arz yeterli değil

• Nüfusa geliştirici oranı artıyor.

  Böylece insanlar daha temkinli ve daha az yetkin değiller, ortalama düşüş, çünkü hesaplama şimdi daha açık bir alan.

Birçok cevap neden tekerleği icat ettiğini söylüyor ve ben buna katılıyorum, ancak tekerlekler varken insanlar tekerleğin nasıl yapıldığını öğrenmek için can sıkıcı değiller.

Her nasılsa, tekerleklerin hala bir şekilde yapılmış olduğu gerçeğiyle, tüm amacınızı baltalıyorsunuz. Amacınızı anlıyorum ama herhangi bir disiplinde, bunu devam ettirmek için düşük seviyeli şeyler ile ilgilenen yeterince insan olduğunu gördüm. Örneğin, GUI oluşturmak için Qt kullanıyorum. Bu araç sihirle gelmedi, insanlar düşük seviyeli şeyler ve yaptığım şeyler arasındaki bağlantıyı geliştirdiler. Daha az insan düşük seviyeli şeyleri anlıyor mu, evet. Daha az sayıda insan kendi yemeğini öldürebilir veya kendi arabasını tamir edebilir, ancak toplum hayatta kalmayı başarır.

1940'lardan önce bilgisayarlar çok zorlu devrelerdi. Sonra Von Neuman depolanan hafıza konumları için bir fikir buldu. MIT'deki programcıların ticaretini çok kolay bir hale getireceğini düşündüğünden eminim. Sonra montaj geldi, sonra FORTRAN, sonra ada, sonra C, sonra c ++, sonra java ve benzeri geldi. Mesele şu ki bir dilin amacı daha fazla ve daha fazla soyutlamaya izin vermek. Bu her zaman amaç olmuştur ve bu c ++ 'nın yakalanmasının ardından java'nın nedenidir. En büyük eteğim, Üniversitelerin artık öğrencilere bilgisayarlar hakkında hiçbir şey öğretmedikleridir. Kendi c # leri gibi c ++ 'ı bilmiyorlarsa c # programcıları işe almıyorum. Niye ya? Kötü bir programcı olmak çok kolaydır çünkü dil ne kadar soyut olursa o kadar soyut olur. İşaretçiler, bellek yönetimi, dinamik ciltleme vb. . içlerinden ve dışından C # 'yı kod tabanımıza katkıda bulunmalarına güvendiğim seviyeye kadar anlamadılar. Ayrıca, Visual Studio'yu kullanmalarına izin vermeden önce, dosyalar üzerinde mücadele etmelerini sağlarım. Bu, C # 'yı ve iyi bir IDE'yi seviyorum, ancak doğru bir şekilde anlaşıldıklarında araçlar kadar iyidirler. Bence bir soyutlama, soyutlanmış olan özellikleri anladığınızda en faydalı olanıdır - bu çok eski bir fikir, bkz.

Bence giriş seviyesi geliştiricileri için iyi bir uygulama, Windows API kullanarak birkaç uygulama yazmalarını sağlamaktır. Sonra, bitirdikten sonra, her formun jenerik pencere sınıfınızdan miras aldığı yerde nesne yönelimli olmasını sağlayın. Olay döngüsünü kapsamalarını ve form sınıflarına geri dönen bazı işlev işaretleyicileri koymalarını sağlayın. Öyleyse iyi bir iş diyelim, Microsoft bunu zaten sizin için yaptı. System.Windows.Forms. İyi eğlenceler.

Web geliştiricileri olacaklarsa, POST, GET vb. Bilgileri anlamaları için birkaç CGI programı yazmalarını sağlayın ve ardından sayfayı komut dosyası haline getirin. ASP.NET ve PHP'yi çok daha mantıklı kılar.

Bir ağda daha düşük seviyeli bir şey üzerinde çalışıyorlarsa, bunları zaten yapmış olan kütüphanelere tanıtmadan önce soketleri kullanarak birkaç uygulama yazmalarını sağlayın.

Bunun uzun vadede üretkenliği arttırdığını buldum, çünkü onlara kendi sorunlarını çözecek araçları ve doğru sezgileri veriyor.

Üniversitelerin bunu yapması gerekiyordu ama bizim yapmamız gerekmiyor.

Bununla birlikte, üniversiteden çıkmaya değer programcılar bulmanın daha da zorlaştığına katılıyorum, çünkü özyinelemeli algoritmalar ve bağlantılı listeler yazmaya zorlanarak çıkarılmadıkları için. Ayrıca, genellikle yalnızca Java veya .NET kursları olmuşlardır ve bu nedenle çalışma biçimleri hakkında hiçbir şey anlamıyorlar. Yine de, soyutlama düzgün kullanıldığında oldukça faydalıdır.

(..) er ya da geç, şimdi programlama dediğimiz şey diye bir şey olmayacak

Bu noktaya katılmıyorum.
Bilincin ne olduğunu bilmeden programcı iş güvenlidir.

Bu nasıl "düşünme makineleri" şu anda görünüyor:

- Konuyu değiştirmeyi bırak!
- Aşkımızın özel olduğunu düşündüm.
- Konuyu değiştirmeyi bırak!
- Konuyu değiştirmiyorum.
-Sen! Ne hakkında konuştuğumuzu anlama konusundaki yetersizliğiniz hakkında konuşmaya çalışıyorum.
-Hayır, yakın bile değil. En sevdiğim beatles şarkı evrenin karşısında. seninki nedir?

Sadece bu noktayı anlamayan programcıların mahkum olduğuna inanıyorum.

Örn Dehumanizer`s cevap:

Buna cevap veremezler - Boyer-Moore ve Knuth-Morris-Pratt algoritmalarındaki farklar nelerdir.

Ve "bu nokta" ile demek istediğim - bilgisayarı en iyi olduklarından çıkarmaya çalışmak yanlış - algoritmalar. Bunun yerine, programcının bağlamı olan ve çözmeye çalıştığımız sorunları anlatan bir bilgisayara yardımcı olması gerekiyordu.

Araçların kendileri sorunları çözmezler, sadece (bazen) programcıları daha verimli hale getirirler.

Şöyle ki: "silahlar öldürmez, insanlar öldürür".

Kesinlikle hayır. Tecrübelerime göre, doğru geliştirme araçlarını kullanmak kaliteden ödün vermeden hızlı uygulama geliştirmeye izin verir. Aslında, “araçlara güvenmemiz” nedeniyle kalitenin çoğunun arttığını iddia ediyorum. Ayrıca, geliştirme araçları öğrenme eğrisini azaltabilir ve programlamaya daha fazla insan getirebilir. Bu, elbette, daha birçok acemi programcı olduğu için bir dezavantajı var, ama sonuçta, yaratıcı süreçte yardımcı oluyor ve teknolojiyi ileriye doğru itiyor.

Araçlara aşırı güvenmek, tembel olduğunuzu ima ediyor mu?

Genel olarak, 'Hayır'; ama büyük bir uyarı var.

Üniversitede C ++ 'da programlamaya başladım ve çok sevdim Gelecek dönemde VB6'ya geçtik ve bundan nefret ettim.

Neler olup bittiğini anlayamadım, bir düğmeyi forma sürükleyin ve ide kodu sizin için yazar.

Evet kesinlikle. Uni'deki deneyiminiz, bahsettiğim ihlale hitap ediyor.

Aracınızın hangi sorunu çözdüğünü bilmiyorsanız veya aracınızın kendine ait sorunları olduğunda sorun gidermekte yetersizsiniz, o zaman bu büyük bir kırmızı bayrak. Bu durum illa ki tembellik anlamına gelmez, ancak muhtemelen deneyimsizlik anlamına gelir.

Bence 2 çeşit programcı var. İşi bitirmek için belki de son başvuru tarihi nedeniyle veya daha verimli olmak için programlayan programcılar var. Tembel olduklarını söyleyebilirim. Bir bilgisayarın ne yaptığını "nasıl" veya bir programın ne yaptığını "nasıl" ilgilenmediklerini düşünüyorum.

O zaman benim gibi tutkulu programcılar var. Tutkulu programcılar, benim gibi, CPU'da tam olarak ne olduğunu bilmek isterler. Tıpkı iyi bir psikoloğun insan kafasında neler olup bittiğini anlamaya çalıştığı gibi, prolog uzmanı da kendim gibi CPU'nun içinde neler olup bittiğini bilmek ister. Böylece bir programı öğreniyoruz, inceliyoruz ve analiz ediyoruz ve bir programın nasıl çalıştığını anlamaya çalışmak için Reflektör ve sökücüler gibi araçları kullanıyoruz.

İşlerin değişeceğine dair sessiz bir umudum var. CPU'lar dikey olarak ölçeklenmiyor, çok, sadece yatay olarak ve ARM vb. Yakın gelecekte kaynak kısıtlı olacak.

Sürükle ve bırak olmayan programlamaya olan talebin azalması ve daha ilginç işler görmemiz oldukça olası.