HN Tanıtımı: Çocuklara kodlama eğitimi için yeni bir görsel dil

 (pickcode.io)
4 puan yazan GN⁺ 2023-11-23 | 1 yorum | WhatsApp'ta paylaş
  • Pickcode, ortaokul ve lise bilgisayar bilimi dersleri için çevrimiçi bir IDE’dir; öğretmenlerin ders yönetimine harcadığı zamanı azaltan, basit ve kararlı bir platform olmayı hedefler
  • Chromebook desteği, öğrenci çalışmalarını izleme, gerçek zamanlı iş birliği ve kod geçmişini inceleme temel ders yönetimi özellikleridir
  • Öğretmenler ders materyallerini ve ödevleri özelleştirip düzenleyebilir; Pickcode ise yapay zeka kod yardımcısı özelliği bulunmadığını açıkça belirtir
  • Öğretmen değerlendirmelerine göre Java, Web Development, Python ve AP Computer Science Principles derslerinde öğrencilerin daha kolay erişmesine ve bağımsız çalışmasına yardımcı olmuştur
  • Karmaşık profesyonel IDE’ler yerine ders oluşturma ve öğrenci yönetimine odaklanan bir araç olduğundan, sınıf ortamında dikkat dağınıklığını azaltan bir seçenek olarak görülebilir

Sınıfa göre tasarlanmış çevrimiçi IDE

  • Pickcode, ortaokul ve lise CS dersleri için çevrimiçi bir IDE’dir
  • Öğretmenlerin ders yönetimi zamanından tasarruf etmesi için basit ve kararlı bir platform vurgusu yapar
  • Başlarken, giriş ve fiyatlandırma sayfalarına uzanan temel erişim yolları sunar

Ders yönetimi özellikleri ve öğretmen tepkileri

  • Pickcode’un başlıca özellikleri ders yürütme ve öğrenci çalışmalarını kontrol etmeye yöneliktir
    • Chromebook üzerinde çalışır
    • Öğrenci çalışmaları izlenebilir
    • Gerçek zamanlı iş birliğini destekler
    • Kod geçmişi incelenebilir
    • Ders materyalleri özelleştirilebilir
    • Ödevler düzenlenebilir
    • AI kod yardımcısı özelliği yoktur
  • Öğretmenler arayüzün basit ama ölçeklenebilir olduğunu ve farklı yaş gruplarındaki öğrenciler tarafından sevildiğini değerlendiriyor
  • Java, Web Development, Python ve AP Computer Science Principles derslerinde kullanım örnekleri bulunuyor
  • Öğrencilerin aracı daha kolay kullanmasına, çalışmalarını takip etmesine ve bağımsız ilerlemesine yardımcı olduğu yönünde geri bildirimler yer alıyor
  • Destek ekibinin hızlı yanıt verdiği ve yardımcı olduğu, önerilerin birçoğunun hayata geçirildiği yönünde değerlendirmeler de var

İlgili okumalar

1 yorum

 
GN⁺ 2023-11-23
Hacker News yorumları

  • var, set, call anahtar sözcüklerini mutlaka zorunlu kılmak için iyi bir neden olup olmadığını merak ediyorum. BASIC’te böyle şeyler yoktu; çocukken programlamayı ilk öğrendiğim zamana dair bulanık anılarımda, bu tür anahtar sözcükler gereksiz karmaşıklık gibi gelirdi
    Örneğin LOGO’da sadece forward 10, left 90 yazmak yeterliydi; call paint.forward(10), call paint.left(90) ise abartılı ve gürültülü hissettiriyor

    • Anahtar sözcükler, her satırı sözlü olarak okumayı kolaylaştırmak için kondu. Özellikle set x = 7 ifadesinde, bir değişkeni değiştirmek mi istediğinizi yoksa eşitliği mi iddia ettiğinizi anahtar sözcük netleştiriyor
      Teknik olarak çizim programı bağlamında forward() üst seviye bir metot yapılabilirdi, ama öğrenciler daha sonra 2D oyun motoruna geçip birden fazla sprite’ı kontrol ettiklerinde hazırlıklı olmaları için bunu biraz daha nesne yönelimli yapmaya karar verdik
    • Burada adlar bana biraz sezgisel gelmiyor. forward ve left hareket yönü gibi görünüyor; özellikle ressamı “sola hareket ettirmek” istediğinizde kafa karıştırıcı
      Aslında forward çizme/hareket etme, left ise negatif argüman da kabul eden saat yönünün tersine döndürme olduğundan, call paint.draw(10), call paint.rotate(90) ya da rotate("up") daha anlaşılır geliyor
    • Yaşımı ele veriyor olabilir ama ilk öğrendiğim BASIC’te alt yordam çağrısı için bir gosub komutu vardı
      Bu arada, erken dönem BASIC’lerde de öyleymiş diye bağlantı numaralarını da 1’den başlattım :)
      [1] https://picaxe.com/basic-commands/program-flow-control/gosub...
      [2] https://alandix.com/blog/2021/07/27/a-brief-history-of-array...
    • Benim kullandığım Basic’te LET X=10 vardı
    • Benim ilk izlenimim de aynıydı. Bütün gün çok daha karmaşık kodlara bakıyorum, ama küçük bir çocuğun açısından düşününce bu tür gereksiz gürültülerin epey yanlış anlaşılmaya yol açacağını düşünüyorum

  • 10 yaşındaki çocuğuma Godot’yu tanıtıyorum. Son 6 ay boyunca Scratch ile oyunlar yaptı ve Scratch’i seviyor, ama sınırlarından da bunaldı
    Gerçek bir betik dili kullanmayı daha çok seveceğini sanmıştım, fakat GDScript kullanmaya başlar başlamaz yazması gereken miktar yüzünden kısa sürede hayal kırıklığına uğradı. Elleri küçük olduğu için on parmak yazmayı öğrenmesi zor; değişken adlarını ve metot çağrılarını yazmak çok uzun sürüyor
    Bu tam iyi bir denge gibi görünüyor, o yüzden bakacağım

    • Yazma hızı kısıtı gerçekten çok iyi bir nokta ve garip şekilde bunu hiç düşünmemiştim
      3 yaşındaki çocuğumla çok hafif Python dersleri yapıyorum; anlama düzeyine kıyasla ilerlemenin neden yavaş olduğunu merak ediyordum. Şimdi fark ediyorum ki parantez ve tırnak işareti gibi şeyleri yazmak bile uzun sürüyormuş
      Bu projeyi sevdim ve denemeyi dört gözle bekliyorum. Çocuklar için programlama konusunda ne kadar çok olursa o kadar iyi diye düşünmeye başlıyorum. Birden fazla dil ve iş akışı arasından seçim yapma dinamiklerine maruz kalmaları da iyi olabilir
    • Çocuk boyutunda klavye kullanmamanızın nedenini merak ediyorum
    • Benim deneyimim de benzer. Oğluma 8 yaşındayken Scratch’i tanıttım; 2 yıl sonra, şu anda beklediğimden çok daha gelişmiş oyunlar yapıyor
      Ama ona “gerçek” bir programlama dili gösterdiğimde, bunların hepsini Scratch’te de yapabildiğini ve bu kadar çok yazmasına gerek olmadığını söylüyor
      GameMaker’ı da birlikte denedik ve güzel sonuçlar ürettik, ama kısa bir süre arkamı döner dönmez yine kendi Scratch projesine dönmüş oluyor. Bazen, eski ben gibi en baştan kodla başlaması daha mı iyi olurdu diye düşünüyorum ;-)
    • Scratch’in sınırının, program çok büyüdüğünde karmaşıklığın nasıl yönetileceğinin çocuk için net olmamasında olduğunu hissettim
      Yine de sorunu işaret edip ne yapılabileceğini sormak bile çocuğun o problemi düşünmesini ve Scratch içinde mümkün olan çeşitli yollar bulmasını sağlıyor. Örneğin programı birden fazla nesneye veya ajana bölmek gibi
      Scratch, ilk izleniminin ya da ilk programların ima ettiğinden çok daha güçlü
    • GDScript şaşırtıcı derecede iyi bir dil. Birçok açıdan Python’dan daha iyi; örneğin var ve const var

  • Pickcode’un çıkışını kutlarım. Ayrıntılardaki tamamlanmışlık iyi ve özenle yapıldığı belli
    Programlamayı geliştirici olmayanlar için daha erişilebilir kılmaya çalışan görsel programlama tarafında en az iki akım olduğunu düşünüyorum
    Bazı girişimler görsel arayüzle sözdizimi öğrenme yükünü azaltıyor, ama emirsel niteliği veya algoritmik düşünme gerekliliğini saklamıyor. Esasen erişilebilirlik seviyesi farklı bir IDE olarak görülebilir; Pickcode ve Scratch’in bu kategoriye girdiğini düşünüyorum
    Diğer taraf ise görsel metaforlara bir ölçüde daha iyi uyabilecek farklı programlama paradigmalarını araştırıyor. Kullanıcıyı da emirsel programlamadan farklı bir düşünme biçimine yöneltiyor. Node-RED, akış tabanlı programlamayı araştıran iyi bir örnek; bu da fonksiyonel reaktif programlamanın yakın akrabası. LabVIEW de veri akışı tabanlı yakın bir akraba, ama onda daha fazla sihirli unsur var. Aslında bunlar epey akıllı varsayılanlar ve dahili değişken adlandırma. Apple Automator da akla geliyor
    Birinin mutlaka diğerinden daha iyi ya da kötü olduğunu düşünmüyorum, ama görsel dillere bakarken emirsel ve reaktif ayrımını düşünmek, son kullanıcı deneyiminin büyük ölçüde farklılaşabileceğini görmek açısından faydalı

    • Yeni başlayanlara Elm gibi fonksiyonel bir dil atölyesi öğretmenin, uzmanlara öğretmekten daha kolay olduğunu hatırlıyorum. Çünkü yeni başlayanların zihni, bir tür emirsel C tarzı düşünceyle kirlenmemiş oluyor

  • “Kod düzenleme deneyiminin tamamen yapılandırılmış olması ve yazmak yerine menülerden seçim yapılması” çok hoş
    Yetişkin programcılar için de böyle bir şey, yani birden fazla programlama dilinde kullanılabilecek genel amaçlı bir yapısal düzenleyici olsa keşke. Programlama yaparken akla ilk gelen niyet semantiktir. Burada bir fonksiyon tanımlamak, şurada bir koşulu kontrol etmek gibi
    O zaman bu semantik niyeti neden doğrudan düzenleyiciye iletemediğimizi anlamıyorum. Neden önce niyeti bir karakter dizisine serileştirip, sonra düzenleyicinin bunu tekrar hataya açık bir şekilde parse etmesi gerekiyor? Yazım hataları, parantez uyumsuzlukları, operatör önceliği hataları gibi aptalca sözdizimi hatalarının araya girme ihtimali doğuyor; sadece semantik hataların kalması daha iyi olmaz mı?
    Böyle bir düzenleyicinin klavyeye mutlaka düşman olması da gerekmez. Excel’in klavyeye düşman olmamasına benzer. Doğu Asya dillerindeki giriş yöntemleri gibi “birleştirme penceresi”ne yazıp “aday penceresi”nden seçerek ekleme yöntemiyle de çalışabilir gibi geliyor

    • Böyle çok deneme oldu. Bu, “kimsenin aklına gelmemiş bir fikir”den çok, “çok sayıda insanın düşünüp denediği ama hemen büyük bir sorunla karşılaştığı bir fikir”e daha yakın
      Benim anladığım kadarıyla bu durumda büyük sorun, kodun geçtiği tüm ara durumların semantik olarak geçerli olması gerektiği kısıtını koyma isteği. Dışarıdan bakınca çekici, ama pratikte ölümcül bir kısıta dönüşüyor. Çok yetenekli insanlar bile önce biraz gevşek düşünür, sonra kodu düzeltir; bu tek satır düzeyinde bile böyledir. Her zaman %100 geçerli olma zorunluluğu, gerçek düşünme biçimiyle ciddi biçimde ters düşüyor
      Bu uyumsuzluğun temel olduğunu düşünüyorum. İnsanların çok küçük bir kısmı bile bu şekilde düşünüyor mu bilmiyorum. Profesyonel matematikçilerin bile gerçek çalışmalarında çoğu zaman önce ileri atlayıp düşündükleri, kesinliği sonra doldurdukları söylenir. Onlar bile adım adım katı biçimde ilerlemiyorsa, kim öyle yapar ki?
      Programlama anlamı bilen otomatik tamamlama ve öneriler etrafında yerleşti; bunun basit bir tembelliğin sonucu değil, gerçek optimum nokta olma ihtimali yüksek
      Birisi sonuna kadar zorlarsa sorun çözülebilir belki, ama burada meyve varsa bile alçakta asılı bir meyve değil demek isterim
      saurik’in dediği gibi, Emacs kullanan Lisp dünyası buna en yakın yer, ama yine de istediğiniz her şeyi yapabiliyorsunuz. Sadece daha semantik çalışmanıza yardımcı olan çok sayıda araç var; mutlak bir zorlama yok
    • Böyle şeyler epey fazla değil mi? Scratch ya da akrabası Snap(https://snap.berkeley.edu/snap/snap.html), React için görsel akış düzenleyicisi(https://app.flowhub.io/#project/c111454c9fd2f74d37d1e8a4e739...), benzeri https://retejs.org/ gibi şeyler var
    • Yetişkin programcılar için böyle bir şey istediğini söylemişsin; Blythe Omnis 7 1996’da ya da daha öncesinde zaten vardı. Hem Windows hem Macintosh destekleyen bir RAD platformu/çözümüydü
      O yazılımı duymuş olan tek aday olduğum için işi kapmıştım. Bir dergide kısa bir yazı okumuş olmam sayesinde
      https://en.wikipedia.org/wiki/Omnis_Studio
      Açılır listelere ve pop-up’lara tıklayarak programlama yöntemi pek iyi tasarlanmış sayılmazdı. Program liste gibi görünürdü; bir satırı düzenlemek istediğinizde modal bir iletişim kutusu açılır ve sadece o tek satırı değiştirebilirdiniz. IntelliSense ya da kod tamamlama elbette yoktu
      Düşününce bile PTSD’m tetikleniyor gibi; içkiye ya da sigaraya ihtiyaç duyacak hale geliyorum
    • Örneğin https://github.com/nocode-js/sequential-workflow-designer bu şekilde tasarlanmış. Önceden tanımlı eylemleri doğru sıraya yerleştirerek mantığı programlıyor ve yüksek seviyede programlama yapmış oluyorsunuz
    • Lisp’i Emacs ile kullananların böyle bir deneyim yaşadığını biliyorum. Çünkü düz metin olarak değil, formlar olarak düşünüp çalışabiliyorlar

  • Scratch’te en sevdiğim özelliklerden biri sözdizimi hatası oluşturamamak. Bloklar ya birbirine uyar ya da uymaz. Bu yüzden çocukların ayrı açıklama ya da özel ders olmadan daha kolay başlayıp oynayabildiğini düşünüyorum
    Kare eğitimindeki ilk birkaç adımı izledikten sonra şuna buna tıklayıp kendim denedim ve call math paint.forward() oluştu, bu da sözdizimi hatası verdi. Elbette o satır çöptü, ama math komutunun nasıl çalışması gerektiğini çözemedim. Eğitimi daha fazla izlersem açıklaması çıkacaktır, ama keşfedilebilirliğin de önemli olduğunu düşünüyorum

    • Scratch sözdizimi hatası oluşturmaz, ama bir şey yerinden çıktığında da şikâyet etmez. Örneğin blokları kurcalarken biri kopup ayrılırsa program çalışır ama doğru işlemez
      Blok sayısı artınca birbirlerinin üstüne de binebilirler; bunu bulmak epey zorlaşır. Blok argümanlarını eksik bırakma sorunu da var. Yine de çalışır ama işlev görmez
      Görsel programlama çocuklar için kesinlikle daha iyi, ama Scratch’ten daha sıkı bir yaklaşım ve daha iyi hata ayıklama becerisi gerektiğini düşünüyorum
    • Scratch’in, daha doğrusu blokların bir başka avantajı, yeni bir dile oldukça kolay uyarlanabilmesi. Biz IoT müşterilerinin cihazları olaylara tepki verecek ve başka cihazlara olay gönderecek şekilde ayarlaması için bloklar kullandık; bunların tamamı yüklenen JSON ayarlarına dönüştü

  • Gerçekten çok iyi görünüyor. Khan Academy’de ProcessingJS düzenleyicisinin blok tabanlı sürümünü yaptığımız zamanları hatırlattı
    UI biraz kaba saba ve bakımı zor olduğu için sonunda bıraktık, ama bu oldukça akıcı görünüyor. Yeni programcıların tipli programlamaya geçebilmesi için daha fazla yol sunması hoşuma gidiyor. Blok kodlamanın çoğunun gerçek koddan fazla uzak olduğunu da düşünüyorum

    • Bu tür blok düzenleme UI’larının, tree-sitter parser’larında kullanılan türden sözdiziminin soyut tanımından otomatik üretilebilmesi gerekiyor gibi geliyor
      Bazen bu tür blok tabanlı düzenleme tip denetimiyle birleşerek “boşlukların” sorgu temelli akıllı biçimde doldurulmasını da sağlayabiliyor. Muhtemelen en belirgin olarak Agda gibi saf fonksiyonel diller için düzenleyicilerde görülebilir

  • ZX81’in BASIC’ini hatırlatıyor. Anahtar sözcükleri yazmıyordunuz; özel klavyede her anahtar sözcük için bir tuş vardı.
    Düzenleyici bağlama duyarlıydı; başka bir deyişle, ayrıştırıcının yönlendirdiği sözcüksel analizci kullanıcının kendisiydi. O zamanlar bir sözcük/sayı mı girmek istediğinizi, yoksa bir anahtar sözcük mü girmek istediğinizi ve bunun ne tür bir anahtar sözcük olduğunu anlaması biraz sihir gibi geliyordu. Aslında eğitim açısından önemli olan kısım, benim bunu biliyor olmamdı.
    ZX81’de önemli olan şey, metin gösterimi yerine token saklayarak bellekten tasarruf etmesiydi. RAM 1 KB’tı ve buna ekran belleği de dahildi. Ayrı bir GPU da yoktu. Giriş sırasında ayrıştırma yapması, çalışmayı da muhtemelen hızlandırmıştır.

  • Site çok iyi cilalanmış, ancak hedefe tamamen katılmıyorum. Etkileyici bir IDE olsa da, yeni bir dil yerine Python’ın bir alt kümesine odaklanırdım gibi geliyor.
    Aksi halde Scratch’in öğretmesi daha kolay, Python’ın ise öğrenmesi daha faydalı olduğu gerekçesiyle göz ardı edilebilir. İlki, geliştirici olan öğretmenlerin bulunduğu okullar için; ikincisi ise çocuğuna eğitim veren programcı ebeveynler için geçerli.
    Bir yazılım geliştiricisi olarak eşimin ilkokul/anaokulu programlama derslerine yardım etmişliğim var, bu yüzden bu alandaki sorunları bir ölçüde biliyorum.

    • “Python’ın bir alt kümesi”ne karşılık gelen bir alternatif olup olmadığını merak ediyorum. “Gerçek” programlamaya doğal bir köprü varsa ilginç olurdu.

  • İlgili yazılar:
    Show HN: Pickcode – A new way to introduce programming to kids - https://news.ycombinator.com/item?id=33562193 - Kasım 2022, 14 yorum
    Show HN: PickCode – An educational coding environment for students after Scratch - https://news.ycombinator.com/item?id=32230329 - Temmuz 2022, 32 yorum
    Show HN: Pickcode – A graphical code editor for education - https://news.ycombinator.com/item?id=31426331 - Mayıs 2022, 4 yorum
    Yeniden paylaşım yaklaşık 1 yıl sonra sorun değil; önceki başlıkların bağlantıları da daha fazlasını merak eden okurlar için.

  • Benzer bir kavram üzerinde müzik programlama tarafında çalışıyorum:
    https://glicol.org
    Açılış sayfasında hemen birkaç örnek olsa iyi olurdu.
    Dersi denediğinizde takılıp kalıyorsunuz; ipuçları sağda, ama pek göze çarpmıyor. Svelte Tutorial(https://learn.svelte.dev/tutorial/welcome-to-svelte) gibi yeniden konumlandırılabilir.
    Sözdiziminden emin değilim. LOGO kullanmayı düşünüp düşünmediklerini merak ediyorum.