BASIC'e maruz kalmanın aklını parçalayabileceğini düşünüyor musun? [kapalı]

BASIC'e daha önce maruz kalmış olan öğrencilere iyi programlama öğretmek neredeyse imkansız: Potansiyel programcılar olarak yenilenme umudunun ötesinde zihinsel olarak sakatlanırlar

- Edsger W. Dijkstra

Dijkstra'ya derin saygı duyuyorum ama söylediği / yazdığı her şeye katılmıyorum. 35 yıl önce Dartmouth BASIC uygulaması hakkında yazılan linkli kağıt üzerine yapılan bu alıntıya özellikle katılmıyorum .

İş arkadaşlarımın veya arkadaşlarımın programcılarının çoğu BASIC ile başladı, aşağıdaki soruların çoğu programcının BASIC'de programlama konusunda ilk deneyimlerini yaşadıklarını gösteren cevapları var. AFAIK, birçok iyi programcı BASIC programlamaya başladı.

Kaynaklarla dolu makinelerde çalışan Visual Basic veya BASIC'in diğer "modern" lehçelerinden bahsetmiyorum. Eskiden BASIC'in "oyuncak" bilgisayarda çalıştığı hakkında konuşuyorum, programcının bilgisayardan yalnızca birkaç yüz tanesi olduğundan, bir miktar bayttan tasarruf etmek için bir dize olarak hesaplanması gerekmeyen küçük sayıları kaydetme konusunda endişelenmek zorunda kalması ya da bilgisayarlı goto'yu daha güçlü bir özellik bulunmadığı ve programcının bir şeyler yapmadan ve programcıyı yaratıcı olmaya zorlamadan önce çok fazla düşünmesini gerektiren birçok şey kullanması gerekir.

Sınırlı kaynaklara sahip bir makinede eski zaman BASIC ile ilgili deneyiminiz varsa (bugün basit bir mikro denetleyicinin 1975’teki bir bilgisayardan çok daha fazla kaynağa sahip olduğunu aklınızda bulunduruyorsanız, BASIC’in daha iyi çözümler bulma konusunda aklınıza yardımcı olduğunu düşünüyor musunuz? Bir mühendis veya BASIC gibi sizi programlamanın karanlık tarafına sürüklüyor ve zihinsel olarak sakatlıyor mu?

Acemi programcının tüm yanlış işlemleri yapabildiği ve programın büyük bir problem yaşamadan çalıştığı kaynaklarla dolu bir bilgisayarda çalışan bir programlama dilini öğrenmek iyi midir? Yoksa programcının nerede yanlış gidemediğini öğrenmek daha mı iyi?

BASIC hakkında daha iyi / daha kötü bir programcı olmanıza yardımcı olduğu konusunda neler söyleyebilirsiniz?

Eski BASIC'e 2KB (sanal) bir makinede çalışan bir programlayıcıya öğretir misiniz?

Tabii, sadece BASIC'e maruz kalmak kötü. Belki de modern BASIC'in çok yardımcı olmadığı fikrini siz paylaşıyorsunuz çünkü modern BASIC, diğer programlama dillerinde olduğu gibi, programcının daha derin düşünmemesini sağlayan imkanlar sunuyor.

Ek bilgi: Neden BASIC?

Alıntı sırasında popüler olan Temel Bilgiler, 20 yıl önce sahip olduklarımızdan çok farklıydı. (Bunları "modern" lehçeleriniz arasında mı sayıyorsunuz?;)

Döngüleri, alt yordamları, yerel değişkenleri ve (Dijkstra ve Knuth'un büyük destekçileri olan) Yapısal Programlamanın vurguladığı her şeyi unutun. GOTO'n vardı ve hoşuna gitti .

Bu bağlamda, yalnızca küresel değişkenleri bilen, kendi alt yordamlarını icat eden (parametreler ve dönüş değerleri için daha fazla küresel değişken kullanan!) Programcılar ve spagetti GOTO'ların gerçekten sakat kaldığını yazdı.

Bugün 30 ya da daha genç biriyseniz ve Temel ilk dilinizse, Dijkstra'nın bahsettiği dil değildi. Daha yaşlı olsanız ve ilk Temel'inizde bu özelliklerden bazıları olsa bile, Murph'un yorumunda olduğu gibi, Dijkstra'nın bahsettiği dil ile aynı olmayabilir.

Soruyu daha önce hiç bilmediğim bağlamla güncellediniz:

• Dijkstra'nın teklifi 1975'ten.

• 6. versiyona kadar ayrı ayrı derlenebilecek prosedürleriniz yoktu, ki bu da GOTO’dan uzaklaşmaya odaklanmanın başlangıcını gösteriyor .

• “1976'da Steve Garland , sürüm 6 çıktısını üreten bir ön derleyici olan Dartmouth SBASIC'i oluşturmak için yapısal programlama özellikleri ekledi ...” ^{[ Wikipedia ]} Alıntı içeriği, şu anda kontrol yapıları olarak bildiklerimizden ve çoğu kullanıcının ... Zaman ikinci veya en son sürümle daha yakından tanışmış olabilirdi - yani Garland'ın sürümünden önceki iki sürüm, v5 ve daha önce ayrı olarak derlenebilen prosedürler.

• GOSUB / RETURN hala sadece "basit alt yordamları" idare ediyor.

• "Değişken isimleri A - Z, A0 - A9, B0 - B9, ..., Z0 - Z9 arasında sınırlandı ve maksimum 286 olası farklı değişken verdi." ... ve hepsi küresel.

_{Bir erkek, işinde bir şeyler yiyip içmek ve tatmin bulmaktan daha iyisini yapamaz.}

Her şeyden önce BASIC öğrendim (sanırım cebir hariç). Aklımı ciddi şekilde çarpıtmadıysa, izleyen 18 yılı nasıl açıklayacağımdan emin değilim.

Bu, ne olmuş yani? Dijkstra uzun süredir BASIC'e uzun süre maruz kalmamdan dolayı bana bir şey öğretmekte zorlanıyor olabilir, ancak uzun süredir bir yeraltı çam kutusuna maruz kalmasından dolayı bana bir şey öğretmekte zorlanıyordu . Ve bu faktörler kaldırılmış olsa bile, hala hiçbir zaman ciddi bir CS öğrencisi, ciddi bir matematik öğrencisi veya başka bir disiplinde ciddi bir öğrenci olamadım. Benim gibi biri ve Dijkstra'nın programcısı gibi görmek istemediği uçurum, neredeyse farkedilmeyecek kadar büyük ...

Ve yine de programlıyoruz. Biz COBOL ve tüm geri kalan denedi, FORTRAN ile çeviriyorlardı BASIC üzerinde dişlidir kim, biz de bir sevinç ve belki iken, bu küçük makinelere olan ilgisine bulundu tamamen zıt ilk olarak alana Sn Edsger çekti olandan, hayır daha az bir çağrı, ömür boyu süren bir emeğin temeli.

... ya Sadece bir sakat bir zihin neyi belki bu olur ki ...

Sizi inciten BASIC değil, kendinizi diğer dillere maruz bırakmamak . Monoglot "programcılar" değildir.

BASIC, yapısal bir bakış açısından, montajcı veya COBOL'den daha kötü değildi. O zamanlar, şu anda sahip olduğumuz Algol kökenli dillerin bolluğu yoktu, Pascal çoğu insanın makul kontrol yapılarına sahip olması gereken ilk giriş oldu (ve Pascal kontrol yapılarına düşkün olan ben değilim).

BASIC, insanlara kalıcı olarak zarar vermek için yeterli olsaydı, diğer erken diller de vardı ve bu nedenle bugün kullandığımız tüm dilleri geliştirecek kadar zarar görmemiş insanlar olmazdı.

Dijkstra'nın daha sonra iyi programlayıcı olmayan ve asla olmayacak, BASIC'te bazı şeyler yapmayı öğrenen insanlarla uğraşıyor olması mümkün. Bu, ifadeye koyabileceğim en hayırlı yorum.

BASIC ile TRS-80 ve Apple II derslerinde öğrendim ve kendimi iyi bir programcı olarak görüyorum. Şahsen temel olarak BASIC öğrenerek imha edilmemesine neden olduğunu düşündüğüm iki özellik

1. Daha az çabayla istediklerimi başarmanın daha iyi yollarını öğrenmeye çalıştım, bu da diğer dilleri ve bu dillerdeki onları güçlü kılan özelliklerin öğrenilmesine neden oldu ve
2. BASIC ile ilgili sorunları bir dil olarak, özellikle de alt yordamların bulunmadığını gördüm (her ne kadar şu anda yaptığım sorunları net bir şekilde tanımlamak için deneyimim olmamasına rağmen).

BASIC'in saf prosedüründen sonra nesne yönelimli programlamayı öğrenmenin bir süre mücadele olduğunu itiraf edeceğim, ancak bunun BASIC ile gerçekten ilişkili olup olmadığını bilmiyorum, çünkü o zamana kadar adil bir miktarda C öğrenmiştim. .

Ben de Dijkstra ile aynı fikirde değilim. İkinci dili öğrenmek daha zor bir şey çünkü paradigmalar BASIC değil.

BASIC 1985 yılında TK (Sinclair benzeri) adlı kişisel bir bilgisayardaki ilk dilimdi. Çok sınırlı bir kaynak makinesiydi. O zaman, eğlenmek için onaltılık bir editör kullanan bir kitaptan bir BASIC derleyicisini yazdım. Bir Z80 kitabı satın aldım ve bundan sonra 8 bit makine dilini öğrendim. BASIC bu konuda bana çok yardımcı oldu.

C ve Pascal'ı öğrendikten sonra 8080/6 için Assembly ile oynadım. MSX-BASIC, MS-DOS zamanlarında Quick Basic ... VB, Delphi, Windows zamanlarında bazı Java ...

Bugün ilerlemiş bir çalışma (4gl), .net (C # / VB), php ve kendimi bir cyclops gibi hissetmiyorum. :O)

Sekiz yaşındayken bir elma klonunda basic ile başladım.

Bazı OOP fikirlerinin (qbasic, visual basic, vb.) Aktarıldığı daha sonraki basic versiyonları bile Sekizde anlam ifade etmeyecekti.

Erken başlayan programlamaya başlamak, program akışındaki sorunla ilgili düşünebilmemin nedenlerinden biri ve bu sektörde çok fazla insanın iyi yapamayacağı bir şey.

Ben erken bir başlangıç ​​genellikle yararlı olduğunu düşünüyorum ve küçük olanlarla uğraşırken ÇOK BASİT bir dil gereklidir.

Kilometreniz değişebilir ...

Bence dünyadaki çoğu BASIC örneğine maruz kalmak , programcıların beynini tahrip eden şey, dilin kendisi değil. MSDN’yi tarayan ve istisna işlemenin gerekli olduğunu veya bu IDisposabletürlerin gerçekten atılması gerekmediğini düşünmeyen C # programcısı gibi .

Sorunları kendi dillerinde tanımlayamıyorsa ve yalnızca kendileri için çalışamıyor, aynı zamanda sorunu çözmek için inşa edilmiş başka bir tane bulabilirse, herkes bir problem yaşayacak.

Ve GOTO sadece satır numaralandırması yoksa kötüdür;)

Şu anda, oğluma kendi basit oyunlarını yazmasını öğretmek için BASIC kullanıyorum. Hiç kullanmadım, operatörüme PowerBuilder ve PowerScript ile başladım ve C / C ++ 'a ve sonra Delphi'ye atladım. Bugün hemen hemen tüm dilleri kullanıyorum ve çok hızlı adapte oluyorum çünkü tüm dillerin temeli aynı, farklı işaretler, operatörler ve sembollerle aynı matematiksel formüller. Bu da oğluma öğrettiğim şey ve bu yüzden C ++ kodunu zaten okuyabilir ve açıklayabilir. Oğlum 12 btw.

BASIC , meclis dilinde düşünmeninGOTO yolunu öğretmek için harika bir yoldur . Kişinin aklını parçalara ayırmaz, sadece aklını karbon bazlı sinapslardan uzaklaştırır ve silikon bazlı transistörlere yaklaştırır.

Bununla birlikte, BASIC'i LOGO ile karşılaştıralım. BASIC, küçük çocukları programlamadan uzaklaştırabilir, çünkü basit bir eğlenceli program yazmak için tek yapmanız gereken, bir derginin basılı olduğu çok uzun bir programı kopyalamaya devam etmektir, oysa LOGO ile bir liner çok etkileyici grafikler çizebilir. Çocukları çekmek için çok önemlidir.

Temel iyi - eğlenceli ve oldukça basit 2d grafikleri eğlenceli yapabilir ve ne olmasın ... 10 ya da 12 yaşlarındayken daha fazla öğrenmekle ilgilenen eğlenceli bir dil olduğunu öğrendim (ya da öğrenmeye çalışıyorum). bilgisayarlar hakkında ...

Tanıdığım en iyi programcılardan bazıları, Temel programlamaya erken maruz kaldılar. Bu biraz daha "somut" ve bu nedenle düşük seviyeli makinenin gerçekte birçok yeni dilden daha iyi çalışabileceği konusunda daha iyi bir his sağlıyor (örn., Bir araya getirici HLL tanıtımı).

Dijkstra'nın teklifi, akademisyenlerin teknik özelliklere göre tasarlanmış iyi yapılandırılmış programları doğru bir şekilde düzeltmeye yöneldikleri bir dönemden geliyor. Ancak, büyük bir kısmı endüstrisinin gidiş yolu bu değildi. Bunun yerine, çok sayıda web 2.0 dönemi programcısı, kodun ispatlanması için matematiksel olarak zorlayıcı özelliklerin çoğunun olmadığı bir şeyi prototip etmeye çalışıyor, çünkü bu özelliğin rekabetçi kalması için çok hızlı bir şekilde evrimleşiyor.

Bu nedenle, Temel'de programlamanın bazen metodolojide bir miktar temizlik yapıldığında teşvik ettiği hack-and-slash deneme-yanılma programlama yöntemleri, RAD düşüncesinin yararlı bir öncüsüdür.

İPad'de çalışan en az 5 Temel tercüman olduğunu ve böylece dili en yeni cihazlarda bile kullanılabilir kıldığımı belirterek sona ereceğim.

Bence, bu alıntı 35 yaşındayken, programlama dillerinde mevcut olan soyutlama eksikliği ve söylendiği zaman, iyi gelişmeniz için bilmeniz gerekenler ile ilgisi var.

BASIC gibi bir dile sahip olmanız, size düşük seviyede programlamanın nasıl yapıldığını, geçmişte olduğundan çok daha gerekli bir şeyi öğretiyor ve size programlamanın gerçekte olduğundan daha basit olduğu izlenimini veriyor.

3 yıldan beri VZ200, C64 ve Apple] [e BASIC, 15 yaşındayken 'makine kodunu' öğrenmeye çalıştığımı açıkça hatırlıyorum.

Ancak bu günlerde, bunlar hakkında tam bir zekâlıyım ve ismimde BASIC ile herhangi bir dilde beni mutlu bir şekilde çalışırken bulamazsınız ('Aptal Fisher Price Language' gibi monitör ifadelerinde bağırmaya başladım. Yine de, dikkatsiz kaşlı kaşlılıklarımı reddediyorlar), CPU'nun mekaniğini soyutlayan dillerle üretken şeyler yapmanın, 35 yıl öncesine (veya 25 yıl önce, kendi kişisel deneyimim ve örneğime göre) daha kolay olduğunu kabul ediyorum.

montaj kodunu Speer Micro-LINC bilgisayarlarına ön paneldeki bir 8 anahtar seti ile birer birer bayt yükleyenler ve bunları 1972'de PDP kasetlerine depolayanlar için Dijkstra'nın görkemli bir twit olduğunu iddia edeceğim. Basic ile ilgili hor gördüğü her şey, üzerinde çalıştığım montajcı maçaları hakkında doğruydu; henüz kendim ve binlerce kişi daha montajcıya maruz kaldıktan sonra Basic ve Fortran ve Cobol ve C vb.

1990'ların başında GW-BASIC ile programlamaya başladım. Aklım sakatlanmadı. Pascal, C, C ++, Java, C # ve Python gibi daha iyi dillere geçtim.

Bugün bir BASIC programı yazamadım; Satır sayıları açısından nasıl düşüneceğimi unuttum. Bu bir problem değil.

Ancak BASIC deneyimim, ana dili (MIPS) öğrenmek zorunda kaldığım üniversitedeki Bilgisayar Mimarisi kursunda bana çok yardımcı oldu. Assembly dili kontrol akış TEMEL en çok benzer: atlar = GOTO, dalları = IF... GOTO, jal(çağrı) ... jr(ret) = GOSUB... RETURN. İhtiyacınız olan tüm kontrol akışı bu!

Acemi programcının tüm yanlış işlemleri yapabildiği ve programın büyük bir problem yaşamadan çalıştığı kaynaklarla dolu bir bilgisayarda çalışan bir programlama dilini öğrenmek iyi midir? Yoksa programcının nerede yanlış gidemediğini öğrenmek daha mı iyi?

Sınırlı kaynaklara sahip bir bilgisayarda öğrenmenin daha iyi olduğunu söyleyebilirim. "Programcı yanlış gidemez" diye değil, "serinlik" eşiğinden daha düşük olduğu için değil. Bir acemi programcı, PC için nasıl harika bir first person shooter yapılacağını bilemeyebilir. Ancak TI-89'ları için harika bir Pac Man oyunu yazıp, donanımı tüm potansiyelleriyle kullanabiliyorlardı. Ve bu bir güç hissi.