Komut Dosyası Dillerinin Genç Programcılar Üzerindeki Etkileri Nelerdir? [kapalı]


18

Geçen gün öğretmenlerimden biriyle görüştüm.

Daha basit kodlama dillerinin (Python veya Ruby gibi) genç programcılar üzerindeki etkisini tartıştık .

Komut dosyası dillerinin özensiz kodlama teknikleri oluşturduğunu, çünkü yeni başlayanlar "kaputun altında" neler olup bittiğini anlamadığını savundu. Ayrıca, komut dosyası dillerinin programcının verimlilik, bellek yönetimi, operasyonel karmaşıklık vb.

Daha düşük seviyeli dillerin bazı insanlar için çok fazla olabileceğini ve programlama tutkusu geliştirmeden önce vazgeçebileceklerini iddia ettim. İlk programlama dilimi (C) öğrenmeye başladığımda, işaretçilerden vazgeçtim ve vazgeçtim çünkü kavramlar çok zordu (savunmamda sadece 14 yaşındaydım). Java olmasaydı, programcı olamazdım! Eğer daha basit bir dille başlasaydım ve sonra derine inmiş olsaydım, vazgeçmeyeceğimi ve C ile başladığım kadar öğrendiğimi hissediyorum.

Sınıf, her iki tarafın da tam olarak keşfedilmesinden önce sona erdi.


Bu noktaya kadar yeni başlayanların senaryo dilleriyle başlayıp sonra derin kazmaları gerektiğini vaaz ediyorum; ama bu tartışmadan sonra, bunun yanlış düşünme olup olmadığını merak etmeye başladım.

Peki, betik dillerinin genç programcılar üzerinde ne gibi etkileri vardır?



4
Otomatik şanzımanlı bir araba sürmeyi öğrendim. Daha sonra, manuel şanzımanlı bir tane aldım. Öğrenmek biraz zaman aldı ve debriyajı öğrenmek ve diğer her şeyle birlikte değiştirmek zorunda olmadığım için kendimi şanslı hissettim.
David Thornley

2
@ Tek Kişilik: Doğru. Her nasılsa xkcd.com/326 düşünmek zorunda kaldım ...


4
Şahsen ben düşük sonra yüksek program öğrenmek için doğal olmadığını düşünüyorum. Sürünmeyi, sonra yürümeyi, koşmayı, konuşmayı ve yazmayı öğreniyoruz. Üniversitede doğal düzenin tersine çevrilmesi için mantığın ne olduğundan emin değilim. Genellikle insanların "benim için zor olsaydı senin için zor kalması gerekir" sonucunu çıkarırım. Joel bile bunu söyledi. Sanırım döngü hiç bitmeyecek.
P.Brian.Mackey

Yanıtlar:


26

Katılmıyorum. İlk olarak, betik dilleri daha yüksek bir soyutlama düzeyindedir ve bununla ilgili yanlış bir şey yoktur. Başlangıçta kişi sadece ilkeleri öğrenmeye çalışıyor. Aslında, daha düşük seviyeli bir dil seçmenin kötü kodlamayı teşvik edebileceğini söyleyebilirim, çünkü bunları anlayabilmeden önce bazı ayrıntılarla uğraşmak zorunda. Bunun yerine daha basit bir dil ile baştan itibaren temiz ve özlü kod yazmaya başlayabilirsiniz.

İkincisi, bu dillerde öğrenilecek çok şey var. Dili öğrenmeye gelince, C'nin Python'dan daha kolay olduğunu söyleyebilirim. Kişi işaretçilerle uğraşmak veya iplerle ilgilenmek zorundadır, ancak Python'da öğrenilecek çok daha fazla kavram vardır. Anlamalar, nesne yönelimi, yansıma, büyü yöntemleri, birinci sınıf fonksiyonlar, lambdalar, yineleyiciler ve jeneratörler, metasınıflar: bunların hepsi dilin bir parçasıdır.

Python ile başlamanın programlama ve daha yumuşak bir öğrenme eğrisi ile çok daha fazla şey öğrenmeye izin verdiğini düşünüyorum. Daha düşük seviyeli bir dilin daha az soyutlaması olabilir - bu yüzden öğrenmesi için daha az genel kavramlar - ve yeni başlayanı onsuz yapmak isteyebileceği ayrıntılarla boğabilir.


1
+1 olsa da, C'nin öğrenmesinin herhangi bir anlamda Python'dan daha kolay olduğunu düşünmüyorum. Belki de genel olarak öğrenilecek daha az kavram vardır, ancak Python ile aynı zamanda daha fazla şey öğreneceksiniz. Ve elbette, C çok kolaysa, her zaman C ++ vardır, size hem yüksek hem de düşük seviyeli dillerin karmaşıklıklarını öğretir. ;)
Martin

+1, bu benim düşüncemdi! Keşke bunu
dersten

22

Nereden başladığınız önemli değil. Başladıktan sonra nereye gittiğiniz önemli .

BASIC, gezegendeki en zarif dil olmayabilir, ancak prosedürel programlamanın temellerini kapsar ve başlamak için bu yeterlidir.

BASIC ile başladım. Ben vermedi kalmak orada.


Mükemmel cevap için +1 - orijinal sorunun ne kadar yanlış yerleştirildiğini açıkça gösterir! (Tamamen tesadüf olarak BASIC ile de başladım ;-)
Péter Török

5
Kaç kişi orada kalıyor beni şaşırtıyor ..: o /
Gary Willoughby

1
Mükemmel cevap. Kısa, doğru ve noktaya. BASIC ile de başladım.
Michael Riley - AKA Gunny

11

Öğretmeniniz doğrudur, ancak sonuçlarının kötü şeyler olduğunu varsayar.

Dil öğrenmeyi bilgisayarların nasıl çalıştığını öğrenmek için tamamen akademik bir etkinlik olarak görürseniz, o zaman doğrudur. Onlara işleri halletmenin bir yolu olarak bakarsanız, haklısınız demektir.


6
Seninle aynı fikirde değilim. Sonuçları olan sonucu cehalettir, çünkü kötü şeyler. Bu, sonunda bir şeyin kırılacağı ve sorunun anladığınızdan daha düşük bir soyutlama düzeyinde olacağı anlamına gelir ve böylece nasıl düzelteceğiniz hakkında hiçbir fikriniz olmaz. Bu her zaman kötü bir şeydir.
Mason Wheeler

6
Seninle aynı fikirdeyim. Kaputun altında neler olup bittiğini bilmemenin sonuçları, donanım nüansı konusunda endişe duymadan derin bir basitlik ve ifadenin doğrudanlığıdır. Daha düşük soyutlama seviyeleri, uygulama geliştiricileri değil dil tasarımcıları içindir.
S.Lott

1
@Mason: Kesinlikle. Bir zamanlar gerçekten kaputun altında neler olup bittiğine dair bir fikirleri olmayan ve üretim sistemlerinin iyi performans göstermesini veya güvenilir bir şekilde çalışmasını sağlayamayan bir programcı ekibinin kıçını koruyan çok önemli miktarda para kazandım. (Bir zamanlar bu tür işler berbat olduğu için. Hayat çok kısa!)
William Pietri

1
@Mason - Söylediklerinize katılıyorum, profesyonelce programlayacaksanız bu bilgiye sahip olmanız önemlidir. İşaretçiler, ayrık yapılar ve lambda hesabı hakkındaki bilgimi son derece değerli buldum. Ekip üyelerimin bu becerilere sahip olmadığı takımlara takıldım ve sonunda aşırı karmaşık veya çok hatalı kodlar oluşturdular. sadece daha iyi bilmedikleri için. Görünüşe göre bazen kolejler CS öğrencilerine çok fazla süt ve yeterli et vermez, ancak kapak tarafında, başlangıç ​​programcılarının etini beslerse, bırakılma riskini taşırlar.
joe_coolish

1
@Joe: Joel'e göre, başa çıkamayanları bırakma bütün mesele. Ve sadece bir bilgisayar programcısı değil , aynı zamanda bir bilgisayar kullanıcısı olarak, düzenli olarak sadece sadece yetersiz bırakan kodlayıcılar tarafından oluşturulduğunu tahmin edebileceğim korkunç programlarla çalışmak zorunda olan biri, gerçekten "onları bırakma" bitinin daha başarılı olmasını dilerdim!
Mason Wheeler

5

"Komut dosyası dili" son derece modası geçmiş veya en iyi etki alanına özgü diller sınıfına uyan korkunç bir kelime. Öğretmeniniz, yeterince anlamadığı her şeyi açıkça bir kötülük eksenine hizalar.

Makul bir ayrım, yüksek seviyeli diller ile düşük seviyeli diller arasında veya gerçekten dikey olan statik ve dinamik olarak yazılmış diller arasındadır.

Assembler düşük seviyeli dinamik olarak yazılır (türlerden bahsetmek herhangi bir anlam ifade ediyorsa) C düşük seviyeli statik yazılır, Ruby yüksek seviyeli dinamik yazılır, Haskell yüksek seviyeli statik yazılır. Java ne yüksek ne de düşük düzeyde statik olarak yazılmıştır, C ++ hem yüksek hem de düşük düzeyde statik olarak yazılmıştır. Ve bunun gibi.

Tartışma sadece bir giriş seviyesi programcısı için hangi paradigmaların daha uygun olduğu olabilir.
Düşük seviyeli programlamanın muhtemelen bir tane olmadığına ikna oldum. 90'lı yılların başlarında, onunla makul zamanda ilginç sonuçlar elde edebileceğiniz bir zaman olabilirdi.
Ancak programlama tutkuyla beslenir. Tutku ödüller ile beslenir. Bu nedenle, giriş seviyesi programcıları ödüllendirme araçlarıyla başlamalıdır. Düşük seviyeli araçlar artık ödüllendirici değildir, çünkü size aynı sonucu zamanın bir kısmında elde eden yüksek seviyeli araçlardan oluşan geniş bir deniz vardır.

İnsan düşüncesi soyuttur. Dünyayı anlamayı öğrendikçe, bunu çok kaba taneli soyutlamalar ile yapıyoruz ve gerektiğinde ayrıntıya giriyoruz.
Bir çocuğun çevresini anlaması için ona matematik, sonra fizik, sonra kimya, sonra biyoloji, sonra tarih, sosyoloji ve felsefe öğretmeyeceksiniz. Dünyayla başa çıkmak için çok basit bir model veriyorsunuz ve kendi başına geçmesi çok uzun sürüyor, gençken size sonsuzca sorular soruyor ve daha sonra otoritenizi tamamen reddediyorsunuz.

Biz böyle düşünüyoruz. İnsan beyni sadece sınırlı miktarda bilgi "birimi" işleyebilir, ancak soyutluk derecesi bilginin nicelendirilmesinde çok az önemlidir. Örneğin: '34 * 75 'ifadesini bize okumak bizim için hesaplamaktan daha kolaydır, oysa bilgisayarlar için bunun tersi de geçerlidir. Bir grup siyah pikseli kıvrımlı bir çizgiye tanımak (ve böylece soyutlamak), daha sonra bireysel bir basamak olarak tanınabilen (ve yine de soyutlanabilen) muazzam bir iştir.
Büyükannem bir dosya açma fikrini anlıyor. Ancak bu seviyenin altında bir anlayışı yok. Ve açıkçası, bunu önce donanımın ve işletim sisteminin iç işleyişini ve neyin olmadığını inceleyerek öğrenmek zorunda olsaydı, oraya asla ulaşamazdı.

Dışarıda bir şeyleri aşırı karmaşıklaştıran birçok insan var, çünkü asla net, özlü ve dolayısıyla zarif çözümler açısından düşünülmeleri öğretilmiyordu, ancak değiştirilebilir düşük seviyeli detaylarla uğraşmak ve bunlara karşı sorunları çözmek için çok fazla zaman harcadılar. İnsanlara bilgisayar gibi düşünmeyi öğretmek, programlamaya mümkün olan en kötü yaklaşımdır.
Programlamanın değeri, bir soruna çözüm bulmaktır. Kod olarak ifade etmek gerçekten daha sıkıcı, mekanik bir iştir ve sadece uygun olan her şeyle yapılmalıdır.

Oh, ve işaretçileri anlamadığınız için endişelenmeyin. Aynı yaşta aynı sorunu yaşadım. Buradaki sorun aynı zamanda soyutlama eksikliğidir. Klasik olarak bazı C kitaplarından işaretçiler hakkında bilgi sahibi olursunuz ve bunları anlamak için uğraşırken, bu, bellek ayırma ve böylece yığın ve yığın bellek ve benzeri ile el ele gider. Göstergelerin arkasındaki soyut kavram dolaylıdır. Bir dizini belirli bir dizinin içinde tutan bir değişken sadece (aslında belirli dizinin adres alanınız olduğu C'de aynıdır) ve bunun için işaretçi aritmetiğine ihtiyacınız yoktur.
Bu sadece açıklamak içindir ki, yüksek düzeyde soyutlamalar seçmenin işleri kavramasını çok daha kolay hale getirir.

EDIT: ve söz konusu olduğunda, statik olarak yazılan dilleri tercih ederim. Bence giriş seviyesi programcılar tür kavramını (soyut olan) açıkça anlamalıdırlar.


3

Python hakkında basit bir şey yok. Unicode ve meta programlamaya bir göz atın.


Python'un çok karmaşık ve ÇOK güçlü olabileceğini kabul ediyorum. Ancak Python'da temeller (dize manipülasyonu, dizi manipülasyonu vb.) C'den çok daha kolaydır.
joe_coolish

1
Python'un başlaması çok kolaydır ve birçok günlük görev, örneğin sistem dillerinden daha basit bir büyüklük sırasıdır. Hayır, bir bütün olarak dil, kanlı detayları ve gelişmiş özellikleri basit değildir (bu, oyuncak olmayan tüm diller için geçerlidir). Ama soru bu değildi.

1
O zaman neden filecontent.lower () içindeki searchstring.lower (): çalışmıyor? Python2.7 ile pencerelerde tfs UTF-16LE sql dosyasındaki bom nedeniyle. Eğlenceli değildi. işe yaradı. birkaç saat sürdü. string.find () da çalışmıyor ... Argghhh!
Christopher Mahan

1
Unicode'un C'de işlenmesi nasıl daha kolaydır?
dan04

3

Başka, çok daha derin bir sorun görüyorum.

Birleştirilmiş diller, birini türlere dikkat etmeye, türlerde düşünmeye zorlamaz. Fark etmeden birbirine dönüştürülen bazı dizeler ve sayılarla küçük komut dosyalarına sahip olduğum sürece bu iyi ve iyi. Ama bunun kırılacağı gün gelecek. Aniden, program kırılacak ve her hızlı düzeltme tekrar kırılmasına neden olacaktır.

Veya acemi wannabe programcısı, bir tuples listesi yerine bir listeye ihtiyaç duyacağını, ancak "bunun nasıl yapılacağı" konusunda en ufak bir fikre sahip olmayacağını ve mutlak çaresizlik olduğunu gösteren yığın akışı hakkında sorular soracağını anlıyor.


6
Ancak Python ve Ruby güçlü bir şekilde yazılmıştır. Bu, dinamik olarak yazılmaya diktir . Dizeler ve numaralar yok örtülü birbirine dönüştürmek.
dsimcha

3
@dsimcha: Evet - Peki @Ingo'nun söylediklerini nasıl çürütüyor?
Jim G.Nis

1
Çünkü bu soru çoğunlukla Ruby ve Python ile ilgilidir. Ruby ve Python'un zayıf yazıldığını düşündüğünü ima ettiğini düşündüm, bu yaygın bir yanlış anlamadır.
dsimcha

1
@ davidk01 - bu benim açımdan: değerlerin istesek de istemesek de türleri var. Ancak dinamik olarak yazılan (bu terim sizi daha çok memnun ediyorsa) dillerde değişkenler yoktur. Bunun yerine, Unitype'in birçok varyantını ayırt etmek için çalışma zamanında tür denetimi yapılır.
Ingo

2
@Ingo: En azından statik yazım eksikliğinin (aslında isteğe bağlı statik yazım, hata kontrolü veya performans amaçları için kullanılabilir) bir fayda olduğunu düşünen Common Lisp kullanıcılarını bulabildim, bu da gelişimi hızlandırdı ve statik yazmanın önleyeceği hatalar pratikte bulunması ve düzeltilmesi zor olmamıştır. Ben şu ya da bu şekilde görüşten başka bir şey görmedim.
David Thornley

2

Halen resmi öğretim ve mentorluğun başlangıç ​​kodu kalitesinde dil seçiminden çok daha büyük bir faktör olduğunu savunuyorum. Ancak, yeni başlayanlar için bir ilk dil seçmek zorunda kalsaydım, kendi kendini yetiştiren programcılar için python ve üniversite eğitimi için C ++ seçerdim.

Nedeni, resmi bir öğretimle, faydalı bir şey yapmadan yıllar önce güçlü bir teorik temel oluşturmak için küçük, önemsiz programlarla başlayabilirsiniz. Ben zaman göze eğer sipariş ideal olduğunu düşünüyorum, ve C ++ derleyici hataları ve dersler arasındaki bölümleme hataları ile ilgili temel kavrama olmadığını size bildirmek için çok yardım verir.

Bu temel ilkelerden bazıları, kendi kendine öğretilip öğretilmeyeceğinizi öğrenmek için, kemerinizin altında deneyim kazanana kadar gerçekten zordur. Ayrıca, genellikle mümkün olan en kısa zamanda bir şeyi faydalı hale getirmeniz gerekir ve bu yaklaşımla hiçbir zaman minimumdan daha fazlasını öğrenmeme riskiniz olsa da, gerektiğinde teorik temelleri kazanabilirsiniz. Bu yüzden python gibi bir dil öneriyorum.


2

Bunu üniversitede başka şekilde gördük ve bence yararlı. * Alçak seviyeden başladık. İşaretçiler, bellek yönetimi, karakter dizileri ... Evet, C ile başladık. Aynı algoritmalar ile: ilk önce bağlantılı bir liste, karma, ağaç ... ve ancak sonra standart kütüphaneleri kullanın.

Bundan sonra Java, C # veya perl gibi daha güçlü dillere geçtik. Ama kemerin altında neler olup bittiğini bilmek avantajıyla.

Bu işe yaraşırken, senaryo dillerinden daha düşük bir dile geçmenin de iyi olduğuna inanıyorum. Hem yüksek hem de düşük seviyeli bir dili bilmek, neler olup bittiğini anlamaya devam ederken, yüksek seviyeli bir dilin kullanım kolaylığına sahip olmanızı sağlar. Onları öğrenme sırası daha az önemlidir.


1

Betik dilleri programcıları özensiz yapmaz. Sorunlu etki alanını (örneğin programın hizmet verdiği işletme) anlamada netliğin olmaması, özensizliğe neden olan şeydir.

Eski demişler, "Sen her dilde COBOL yazabilir.", Ben her veri tipi zaman şüpheli rağmen aynı görünüyor programın temel yönleri, COBOL- önemli bir özelliktir ne olduğunu görmek için, o zaman zorlaşmaktadır leştirilmesi.


1
Şüphelenmeden önce deneyin. Temel fark bunun bir nerede umurunda kalmamasıdır Fooya Barya olabildiğince sürece bir şey bambaşka .frobnicate()o iki şekilde de. Açık arabirimler olmadan.

Gündelik işim Ruby on Rails ile dinamik dillere oldukça aşinayım. Ve evet, bu dinamik dil topluluğu içinde önemli bir kongre. Genel olarak, buna 'ördek yazma' denir. Araştırma literatüründe, bunlara yapısal türler denir ve size '' quackable type '' ın neye benzediğini gösteren bazı sözdizimi kuralları vardır. Sadece bu değil, onları tanıyabilen ve programınızın ördeklere nezaketle davrandığını doğrulayan tip sistemleri de vardır.
Farley Knight

Yapısal türleri biliyorum ve onları oldukça düzgün bir fikir olarak görüyorum. Ancak bunları kullanan tek bir olgun, uzaktan yaygın olarak kullanılan (O'Caml düzeyi kullanıcı tabanı iyi bir başlangıç ​​olacaktır) bir dil olmadığından, bunları dinamik yazmaya pratik bir alternatif olarak görmüyorum. Üzücü ama gerçek.

Yaygın olarak kullanılan diller bilmez, ancak bu, kendi tür sisteminizi yaygın olarak kullanılan bir sisteme önyüklemekten alıkoymaz. Eminim dinamik diller için tür çıkarımı gibi şeyler hakkında makaleler görmüşsünüzdür.
Farley Knight

Yine, ben ve yandaki adam tarafından kullanılan bir şeyi pratik bir alternatif olarak görmüyorum . Bir programcının kütüphaneler, kararlı sözdizimi, kalıplama, vb.

1

Ben betik dili iddia ediyorum yok özensiz teknikleri teşvik ediyoruz. (Bu, dillerin kötü olduğunu söylemediğini , sadece bu dillerde büyük kod tabanlarını korumak zor olduğunu unutmayın) Ancak, buradaki diğer cevaplardan farklı nedenlerle düşünüyorum.

Bir programcının bir bütün olarak programlama konusunda temel bir anlayışa sahip olması gereken herhangi bir dili kullanmayı düşünüyorum. Vektörler, ağaçlar ve karma tablolar gibi kavramları anlamadılarsa hiçbir yerde etkili olmayacaklardır. Bunları uygulayabilmeleri gerekmiyor, ancak özelliklerini bilmeleri gerekiyor.

Sloppyness'in devreye girdiğini düşündüğüm yer programlama becerisi değil, yeniden kullanılabilir bileşenler yaratması gerektiğinde. Bu diller, kod birimleri veya kütüphanelerin istemcileri üzerindeki kısıtlamaları zorunlu kılma mekanizmaları arasında iyi arabirimler tanımlamanızı gerektirmez. Bu dillerde iyi tekrar kullanılabilir bileşenler yapmak imkansız değil, sadece çok daha zor.

Komut dosyası yazma dillerinin acemi programcıya cazibesi vardır, çünkü daha kısa sürede daha fazla "tek seferlik" iş yapmalarını sağlar, ancak aynı programcılar bakım programlaması yapmaya başladığında genellikle bu dillerle ilgili hızlı problemleri vardır.

Senaryo dillerinin kötü olduğunu söylemiyorum - bundan çok uzak. Ancak muazzam (birkaç milyon satır) kod tabanını korumayı zorlaştırırlar (bu, kodlama dillerinde yapılan bu tür kod tabanlarını görmemenizin nedenlerinden biridir). Nispeten küçük veya bir kerelik çözümlere ihtiyacınız olduğunda, daha kısa sürede ve daha az kodla (ve daha az kod neredeyse her zaman daha iyidir) çok daha fazlasını başarabilmenizi sağlar.

Her iş için en iyi aracın olmadığını unutmayın. Durum için en uygun aracı seçin. Herhangi bir araçta olduğu gibi programlama dilleri için de geçerlidir.


0

Öğretmeninizle birlikteyim, ama aynı zamanda @Singletoned ile de öğretmeninizin sonuçları (örneğin, performans bilgisi yok) kötü olduğunu varsayarsa.

C ile başlamak, betik dillerinden başlamaktan daha iyi olduğunu düşünüyorum. Bir öğretmen olarak, tüm von Neumann mimari şeyine (ALU, kayıtlar, bellek, giriş / çıkış bağlantı noktaları, ...) odaklanacağım, doğrudan işaretçilere geçeceğim (üzgünüm, bu gerçekten önemli bir kavram [serbest bırakmamak) VM dillerindeki referanslar (yani, işaretçiler) birincil bellek sızıntısı kaynağıdır)), bazı veri yapılarını (ağaç, bağlantılı liste, karma 1 ) vurun ve sonra ... başka bir şeye soyutlama düzeyi getirin (OO, fonksiyonel programlama, bir şey - güçlü statik yazım kuralları , yo \ m /, bu yüzden "betik dilleri"> :().

1 Hmm, belki de öğretmeninizle performansla ilgili konularda hemfikirim.


Özensiz programlama bir bellek sızıntısı kaynağıdır ve insanlara dosya tanıtıcıları gibi kaynakları izlemeyi öğretmek çok fazla zaman almaz. Hafıza sızıntısı olan sayısız C programı var, bu yüzden insanlara mümkün olan en kısa sürede işaretçiler hakkında ne öğrettiğinizden emin değilim.
davidk01

Bu doğru, ama ... (a) temelleri anlamak bazı kötü kodlara yol açıyor (hack-til-it-right veya özensiz programlama yoluyla) ve (b) işaretçilerin neden hala alakalı olduğunu motive etmeye çalışıyordum , değil C'nin bellek sızıntıları açısından çöp toplanan dillerden daha iyi olduğunu iddia etmek. En kısa zamanda işaretçiler elde etmek amacı böylece C heck alabilirsiniz
JohnL4

0

Bence en iyisi modüler bir dille başlamak ve daha karmaşık şeylere gitmek, günlerimde Pascal ve COBOL ile başladık ve alt rutinlerin, kontrol akış değişkenlerinin vb ne anlama geldiğini anlamaya çalıştık. Sadece Pascal ile rahat olduktan sonra C / C ++ gibi dillere geçme ve genç programcıya ek olan diğer tüm teknikleri öğrenme arzum bile vardı.


0

İkiniz de haklısınız.

Betik dilleri, acemi geliştiricilerin gerçekten neler olduğunu anlamasını kesinlikle zorlaştırır. (Veritabanları, çerçeveler ve kütüphaneler de öyle. Ah, tarayıcılar, sunucular, ağlar ve dosya sistemleri.) Genç geliştiricilerle görüştüğümde, bilgisayarların gerçekte ne kadar az çalıştıklarını ve kargoya ne kadar eğilimli olduklarını bildiğimden sık sık şaşkına dönüyorum. -kült programlama.

Öte yandan, röportajlarda aradığım bir numaralı şey mükemmel bir anlayış değil, bir şeyler yapmayı seviyorlar. Başladığımda, bir şey yapan bir bilgisayar oldukça etkileyiciydi, bu yüzden küçük Apple Basic ve 6502 montajcı işlerim gerçekten harika görünüyordu. Ama bu günlerde bilgisayarlar çok şaşırtıcı şeyler yapıyor, bu yüzden insanların bağlanmalarını gerektiriyorsa, insanların oldukça yüksek bir seviyede başlamasının iyi olduğunu düşünüyorum.

Temel olarak, sonunda derin sular için grev sürece havuzun sığ ucunda başlamak için ok düşünüyorum.


0

İlk olarak, farklı bir şekilde daha yüksek bir soyutlama seviyesiyle başlıyorum. Şu anda Python öneriyoruz. Komut dosyası dilini ilk dil olarak seçmenin en önemli nedeni, çalışan bir şeyi kolayca bir araya getirebilmenizdir. Joe'nun sorusunda belirttiği gibi, programcı olurken bir numaralı şey, devam etmek ve daha derine inmek için motivasyona sahip olmanızdır. Bu motivasyon, çalışan ve kullanışlı bir yazılım oluşturabildiğinizde kazanılır.

Soyutlama (yüksek seviye) ve altta yatan uygulamayı (düşük seviye) anlama noktalarının yanı sıra kaçırılan üçüncü bir nokta daha vardır. Günümüzde iyi bir programcı olabilmek için yukarıdaki iki noktanın her ikisinde de ustalaşmalısınız. Ayrıca, sürekli olarak yeni teknolojilere ve bakış açılarına bakmanız, yetkinliğiniz için kritik öneme sahiptir. Hangi soyutlama seviyesinden başlarsanız başlasın, sürekli gelişmeli ve mevcut yöntemlerini sormalısın.

Başlangıçtan itibaren, programlama dillerinin sadece işi yapmak için bir araç olduğu açıkça belirtilmelidir. Belirli bir görev için doğru aracı seçmek çok önemlidir. Yeni başlayan bir programcı için yüksek seviyeli bir betik dilinin bu noktayı vurgulamaya yardımcı olacağını düşünüyorum. Daha yüksek bir dil, daha geniş bir bakış açısı kazandıracak ve programcıyı daha derine inmeye teşvik edecektir.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.