HN परिचय: बच्चों की coding शिक्षा के लिए एक नई visual language

 (pickcode.io)
4 पॉइंट द्वारा GN⁺ 2023-11-23 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Pickcode मध्य और उच्च विद्यालयों की computer science classes के लिए एक online IDE है, जिसका लक्ष्य शिक्षकों का class management में लगने वाला समय घटाने वाला एक सरल और स्थिर platform बनना है
  • Chromebook support, student work monitoring, real-time collaboration, और code history देखना इसके मुख्य class management features हैं
  • शिक्षक class materials और assignments को customize करके व्यवस्थित कर सकते हैं, और Pickcode साफ़ तौर पर बताता है कि इसमें AI code assistance feature नहीं है
  • शिक्षकों की राय है कि Java, Web Development, Python, और AP Computer Science Principles classes में इसने छात्रों को अधिक आसानी से शुरुआत करने और स्वतंत्र रूप से काम करने में मदद की है
  • जटिल professional IDEs की तुलना में यह class creation और student management पर केंद्रित tool है, इसलिए classroom environment में distractions कम करने वाला विकल्प माना जा सकता है

Classroom के लिए बना online IDE

  • Pickcode मध्य और उच्च विद्यालयों की CS classes के लिए एक online IDE है
  • यह शिक्षकों का class management time बचाने के लिए सरल और स्थिर platform पर जोर देता है
  • यह get started, login, और pricing pages तक जाने वाला basic entry path देता है

Class management features और शिक्षकों की प्रतिक्रिया

  • Pickcode के प्रमुख features class चलाने और students का काम देखने पर केंद्रित हैं
    • Chromebook पर काम करता है
    • छात्रों के काम को monitor किया जा सकता है
    • real-time collaboration support करता है
    • code history देखी जा सकती है
    • class materials customize किए जा सकते हैं
    • assignments व्यवस्थित किए जा सकते हैं
    • AI code assistance feature नहीं है
  • शिक्षकों का कहना है कि interface सरल है, लेकिन scalable है, और अलग-अलग उम्र के students इसे पसंद करते हैं
  • Java, Web Development, Python, और AP Computer Science Principles classes में इसके उपयोग के उदाहरण हैं
  • प्रतिक्रियाओं में यह भी शामिल है कि इससे छात्रों को tool का उपयोग अधिक आसानी से करने, अपना काम track करने, और स्वतंत्र रूप से आगे बढ़ने में मदद मिली
  • support team के बारे में भी राय है कि वह तेज़ और मददगार है, और दिए गए कई suggestions लागू किए गए हैं

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2023-11-23
Hacker News की टिप्पणियाँ

  • मुझे यह जानने की जिज्ञासा है कि var, set, call keywords को अनिवार्य करने का कोई ठोस कारण है या नहीं। BASIC में ऐसा कुछ नहीं था, और बचपन में पहली बार programming सीखने की धुंधली यादों के आधार पर कहूँ तो ये अनावश्यक जटिलता लगतीं
    उदाहरण के लिए LOGO में बस forward 10, left 90 लिखना होता था, लेकिन call paint.forward(10), call paint.left(90) ज़्यादा भरा हुआ और शोरगुल जैसा लगता है

    • keywords इसलिए जोड़े गए हैं ताकि हर line को ज़ोर से पढ़ना आसान हो। खासकर set x = 7 में keyword साफ़ कर देता है कि हम variable बदलना चाहते हैं या equality assert कर रहे हैं
      तकनीकी रूप से drawing program के context में forward() को top-level method बनाया जा सकता था, लेकिन बाद में जब छात्र 2D game engine पर जाएँगे और कई sprites को control करेंगे, उसे ध्यान में रखते हुए हमने इसे थोड़ा ज़्यादा object-oriented बनाने का फैसला किया
    • यहाँ naming थोड़ी कम intuitive लगती है। forward और left movement direction जैसे लगते हैं, इसलिए खासकर जब painter को “बाएँ ले जाना” हो तो भ्रम हो सकता है
      असल में forward drawing/movement है और left negative argument भी लेने वाला counterclockwise rotation है, इसलिए call paint.draw(10), call paint.rotate(90) या rotate("up") ज़्यादा सहज लगता है
    • यह बात शायद मेरी उम्र बता दे, लेकिन मैंने जो BASIC सबसे पहले सीखी थी उसमें subroutine call के लिए gosub command था
      वैसे, सुना है शुरुआती BASICs में ऐसा ही था, इसलिए मैंने link numbering भी 1 से शुरू रखी :)
      [1] https://picaxe.com/basic-commands/program-flow-control/gosub...
      [2] https://alandix.com/blog/2021/07/27/a-brief-history-of-array...
    • जिस Basic का मैं इस्तेमाल करता था उसमें LET X=10 था
    • मेरी पहली प्रतिक्रिया भी यही थी। मैं दिन भर इससे कहीं ज़्यादा जटिल code देखता हूँ, लेकिन अगर छोटे बच्चे के नज़रिए से सोचें तो ऐसा अनावश्यक शोर काफ़ी गलतफ़हमी पैदा कर सकता है

  • मैं एक 10 साल के बच्चे को Godot से परिचित करा रहा हूँ। पिछले 6 महीनों से वह Scratch में game बना रहा है और उसे Scratch पसंद है, लेकिन उसकी सीमाओं से वह परेशान भी हुआ है
    मुझे लगा था कि असली script language इस्तेमाल करने पर उसे और मज़ा आएगा, लेकिन GDScript शुरू करते ही typing की मात्रा से वह जल्दी निराश हो गया। उसके हाथ छोटे हैं, इसलिए touch typing सीखना मुश्किल है, और variable names तथा method calls टाइप करने में बहुत समय लगता है
    यह एकदम सही संतुलन जैसा लग रहा है, इसलिए इसे देखने वाला हूँ

    • typing speed की सीमा वाकई बहुत अच्छा point है, और अजीब बात है कि मैंने इस बारे में कभी सोचा ही नहीं था
      मैं अपने 3 साल के बच्चे के साथ बहुत हल्की Python class कर रहा हूँ, और समझ नहीं आता था कि उसकी समझ के मुकाबले प्रगति इतनी धीमी क्यों है। अब समझ आया कि parentheses और quotes जैसी चीज़ें टाइप करने में ही बहुत समय लग रहा था
      यह project मुझे पसंद आया, और इसे आज़माने का इंतज़ार है। बच्चों की programming के मामले में मेरा झुकाव अब जितनी ज़्यादा, उतना अच्छा की तरफ़ हो रहा है। कई languages और workflows में से चुनने वाली dynamics से उन्हें परिचित कराना अच्छा हो सकता है
    • बच्चों के आकार वाला keyboard इस्तेमाल न करने की वजह जानना चाहता हूँ
    • मेरा अनुभव भी ऐसा ही है। मैंने अपने बेटे को 8 साल की उम्र में Scratch से परिचित कराया था, और अब 2 साल बाद वह उम्मीद से कहीं ज़्यादा उन्नत games बना रहा है
      लेकिन जब मैं उसे “real” programming language दिखाता हूँ, तो वह कहता है कि यह सब Scratch में भी किया जा सकता है और इतना typing करने की कोई ज़रूरत नहीं
      हमने GameMaker भी साथ में आज़माया और अच्छे नतीजे बनाए, लेकिन जैसे ही मैं थोड़ी देर के लिए मुड़ता हूँ, वह फिर अपने Scratch project पर लौट जाता है। कभी-कभी सोचता हूँ कि क्या मेरे पुराने दिनों की तरह शुरू से code से शुरू करना बेहतर होता ;-)
    • मुझे लगा कि Scratch की सीमा यह है कि जब program बहुत बड़ा हो जाता है तो उसकी जटिलता को कैसे manage करें, यह बच्चे के लिए साफ़ नहीं होता
      फिर भी, सिर्फ़ समस्या की तरफ़ इशारा करके और पूछकर कि इसके बारे में क्या किया जा सकता है, बच्चा उस समस्या पर सोचना शुरू कर देता है और Scratch के भीतर संभव अलग-अलग तरीके ढूँढ लेता है। उदाहरण के लिए program को कई objects या agents में बाँटना
      Scratch, first impression या पहले program से जो संकेत मिलता है, उससे कहीं ज़्यादा शक्तिशाली है
    • GDScript हैरान करने वाली हद तक अच्छी language है। कई मायनों में Python से बेहतर, और इसमें var और const जैसी चीज़ें हैं

  • Pickcode launch के लिए बधाई। details का polish अच्छा है, और साफ़ दिखता है कि इसे ध्यान से बनाया गया है
    मेरे हिसाब से non-developers के लिए programming को ज़्यादा accessible बनाने वाली visual programming में कम से कम दो धाराएँ हैं
    कुछ प्रयास visual interface के ज़रिए syntax सीखने का बोझ कम करते हैं, लेकिन imperative nature या algorithmic thinking की ज़रूरत को छिपाते नहीं। असल में इन्हें अलग accessibility level वाले IDE की तरह देखा जा सकता है, और मेरे विचार से Pickcode और Scratch इसी श्रेणी में आते हैं
    दूसरी धारा ऐसे अलग programming paradigms की खोज करती है जो visual metaphor के साथ कुछ हद तक अच्छी तरह मेल खाते हैं। यह users को भी imperative programming से अलग सोचने के लिए प्रेरित करती है। Node-RED flow-based programming की खोज का अच्छा उदाहरण है, जो functional reactive programming का क़रीबी रिश्तेदार है। LabVIEW भी dataflow-based क़रीबी रिश्तेदार है, बस उसमें थोड़ा ज़्यादा जादुईपन है। असल में यह काफ़ी smart defaults और internal variable naming है। Apple Automator भी याद आता है
    मैं यह नहीं कहूँगा कि कोई एक तरीका ज़रूर बेहतर या बदतर है, लेकिन visual languages को देखते समय imperative और reactive के बीच का अंतर सोचना उपयोगी है, क्योंकि इससे end-user experience में बड़ा फ़र्क पड़ता है

    • मुझे याद है कि Elm जैसी functional language पर beginner workshops पढ़ाना, experts को पढ़ाने की तुलना में उल्टा आसान था। शायद इसलिए कि beginners का दिमाग़ अभी किसी imperative C-जैसी सोच से दूषित नहीं हुआ होता

  • “कोड एडिटिंग का अनुभव पूरी तरह structured है, और typing की जगह menu से चयन किया जाता है” — यह बात बहुत शानदार है
    काश वयस्क programmers के लिए भी ऐसा कुछ होता, यानी एक general-purpose structural editor जिसे कई programming languages के साथ इस्तेमाल किया जा सके। Programming करते समय जो इरादा सबसे पहले दिमाग में आता है, वह semantic होता है। जैसे यहाँ function define करना है, वहाँ condition check करनी है
    तो फिर यह समझ नहीं आता कि उस semantic intent को सीधे editor तक क्यों न पहुँचाया जाए। पहले उस इरादे को string में serialize क्यों किया जाए, और फिर editor उसे दोबारा ऐसे parse करे जहाँ गलती होने की संभावना ज़्यादा हो। टाइपो, parentheses mismatch, operator precedence errors जैसी बेवकूफ़ी भरी syntax errors के लिए जगह बनती है; बेहतर तो यह होगा कि सिर्फ semantic errors ही बचें
    ऐसा editor ज़रूरी नहीं कि keyboard के लिए unfriendly ही हो। यह कुछ वैसा हो सकता है जैसे Excel keyboard के लिए unfriendly नहीं है। शायद East Asian language input methods की तरह “composition window” में input लेकर “candidate window” से चुनकर insert करने के तरीके से भी यह काम कर सकता है

    • ऐसे बहुत से प्रयास हो चुके हैं। यह “ऐसा आइडिया जिसके बारे में किसी ने कभी सोचा ही नहीं” से ज़्यादा “ऐसा आइडिया जिसके बारे में बहुत लोगों ने सोचा और कोशिश की, लेकिन तुरंत बड़ी समस्या से टकरा गए” जैसा है
      मेरी समझ में इस मामले की बड़ी समस्या यह है कि आप यह constraint लगाना चाहते हैं कि code जिन भी intermediate states से गुज़रे, वे सभी semantically valid हों। ऊपर से यह आकर्षक लगता है, लेकिन व्यवहार में यह घातक constraint बन जाता है। बहुत प्रतिभाशाली लोग भी पहले थोड़ा ढीला-ढाला सोचते हैं और बाद में code ठीक करते हैं, यहाँ तक कि एक-एक line के स्तर पर भी। हर समय 100% valid रहने की मजबूरी इंसानी सोच के असली तरीके से काफ़ी अलग है
      मैं इस mismatch को बुनियादी मानता हूँ। पता नहीं कितने लोग वास्तव में इस तरह सोचते हैं। पेशेवर गणितज्ञ भी, ऐसा सुना है, असली काम में पहले आगे निकलकर सोचते हैं और बाद में rigor भरते हैं। अगर वे भी हर कदम पर सख़्ती से आगे नहीं बढ़ते, तो फिर कौन बढ़ता होगा
      Programming ने आखिरकार semantic-aware autocomplete और suggestions पर ठिकाना पाया है, और यह सिर्फ आलस का नतीजा नहीं बल्कि शायद असली optimum है
      हो सकता है कोई इसे अंत तक ले जाकर समस्या सुलझा दे, लेकिन अगर यहाँ कोई फल लटका भी है, तो वह low-hanging fruit नहीं है
      जैसा saurik ने कहा, Emacs इस्तेमाल करने वाली Lisp दुनिया शायद इसके सबसे करीब आती है, लेकिन वहाँ भी आप जो चाहें कर सकते हैं। बस ऐसे tools ज़्यादा हैं जो आपको semantic तरीके से काम करने में मदद करते हैं; कुछ भी पूर्णतः enforce नहीं होता
    • लगता है ऐसे काफ़ी उदाहरण हैं। Scratch या उसका रिश्तेदार Snap(https://snap.berkeley.edu/snap/snap.html), React के लिए visual flow editor(https://app.flowhub.io/#project/c111454c9fd2f74d37d1e8a4e739...), और इसी तरह का https://retejs.org/
    • आपने कहा कि वयस्क programmers के लिए भी ऐसा कुछ चाहिए, लेकिन Blythe Omnis 7 1996 में या उससे पहले ही मौजूद था। यह Windows और Macintosh दोनों को support करने वाला RAD platform/solution था
      मुझे नौकरी इसलिए मिली क्योंकि मैं उस software का नाम सुनने वाला इकलौता applicant था। वजह बस इतनी थी कि मैंने किसी magazine में उसके बारे में एक छोटा-सा लेख पढ़ लिया था
      https://en.wikipedia.org/wiki/Omnis_Studio
      dropdown lists और popups पर click करके programming करने का उसका तरीका बहुत अच्छी तरह design नहीं किया गया था। Program किसी list जैसा दिखता था, और जब आप एक line edit करना चाहते, तो एक modal dialog खुलता था जिसमें सिर्फ वही एक line बदली जा सकती थी। IntelliSense या code completion तो थे ही नहीं
      यह सोचकर ही PTSD जैसा महसूस होने लगता है; लगता है शराब या सिगरेट की ज़रूरत पड़ जाएगी
    • उदाहरण के लिए https://github.com/nocode-js/sequential-workflow-designer इसी तरह design किया गया है। इसमें pre-defined actions को सही क्रम में रखकर logic program किया जाता है, और आप high level पर programming करते हैं
    • मेरी समझ से Emacs के साथ Lisp इस्तेमाल करने वाले लोगों को ऐसा अनुभव मिलता है। क्योंकि वे सिर्फ plain text नहीं, बल्कि forms के रूप में सोच और काम कर सकते हैं

  • Scratch की मेरी सबसे पसंदीदा खूबियों में से एक यह है कि इसमें syntax error बनाई ही नहीं जा सकती। Blocks या तो फिट होते हैं, या नहीं होते। इसलिए बच्चों के लिए बिना अलग से समझाए या tutoring के भी जल्दी शुरू करना और खेलना आसान हो जाता है
    मैंने rectangle tutorial के शुरुआती कुछ steps follow करने के बाद इधर-उधर click करके खुद आज़माया, और call math paint.forward() बन गया जिससे syntax error आ गई। जाहिर है वह line बेकार है, लेकिन मैं यह समझ ही नहीं पाया कि math command को कैसे काम करना चाहिए। आगे tutorial में शायद यह समझाया जाता हो, लेकिन मेरे हिसाब से discoverability भी महत्वपूर्ण है

    • Scratch syntax errors तो नहीं बनने देता, लेकिन अगर कुछ अपनी जगह से हट जाए तो वह शिकायत भी नहीं करता। उदाहरण के लिए blocks के साथ छेड़छाड़ करते हुए अगर कोई block अलग होकर गिर जाए, तो program फिर भी चलेगा लेकिन सही तरह काम नहीं करेगा
      Blocks ज़्यादा हो जाएँ तो वे एक-दूसरे के ऊपर भी चढ़ सकते हैं, जिससे समस्या ढूँढना काफ़ी मुश्किल हो जाता है। Block arguments छूट जाने की दिक्कत भी होती है। तब भी program चल जाता है, लेकिन काम नहीं करता
      Visual programming बच्चों के लिए निश्चित रूप से बेहतर है, लेकिन मुझे लगता है कि Scratch से भी ज़्यादा सख़्त approach और बेहतर debugging capability की ज़रूरत है
    • Scratch, या अधिक सटीक रूप से कहें तो blocks का एक और फ़ायदा यह है कि उन्हें नई language के अनुसार काफ़ी आसानी से ढाला जा सकता है। हमने IoT customers के लिए blocks का इस्तेमाल किया था ताकि वे devices को events पर react करने और दूसरे devices को events भेजने के लिए configure कर सकें, और यह सब upload होने वाली JSON configuration में बदल जाता था

  • यह सच में बहुत अच्छा दिखता है। Khan Academy में ProcessingJS editor का block-based version बनाया जा रहा था, उसकी याद आ गई
    UI थोड़ा भद्दा था और maintain करना मुश्किल था, इसलिए आखिरकार उसे छोड़ दिया गया, लेकिन यह काफ़ी smooth लग रहा है। यह बात अच्छी लगी कि यह नए programmers को typed programming की ओर आने के और रास्ते देता है। मुझे यह भी लगता है कि ज़्यादातर block coding असली code से बहुत दूर चली जाती है

    • लगता है ऐसे block editor UI को tree-sitter parser में इस्तेमाल होने वाले grammar के abstract description से अपने-आप generate किया जा सकना चाहिए
      कभी-कभी ऐसे block-based editors को type checking के साथ जोड़ दिया जाता है, ताकि “holes” को समझदारी से query-based तरीके से भरा जा सके। शायद यह Agda जैसी pure functional languages के editors में सबसे साफ़ दिखाई देता है

  • ZX81 का BASIC याद आ गया। कीवर्ड टाइप नहीं करने पड़ते थे; खास कीबोर्ड पर हर कीवर्ड के लिए एक key होती थी
    एडिटर context-sensitive था, या दूसरे शब्दों में कहें तो parser-चालित lexical analyzer खुद user ही था। उस समय यह थोड़ा जादू जैसा लगता था कि यह समझ लेता था कि आप शब्द/संख्या डालना चाहते हैं या कीवर्ड, और किस तरह का कीवर्ड। सच तो यह है कि शैक्षिक रूप से अहम बात यह थी कि मुझे यह पता था
    ZX81 में महत्वपूर्ण बात यह थी कि text representation की जगह token store करके memory बचाई जाती थी। RAM 1KB थी, और उसी में display memory भी शामिल थी। अलग GPU भी नहीं था। input के समय parsing होने की वजह से execution भी शायद तेज़ होता होगा

  • साइट बहुत अच्छी तरह polished है, लेकिन मैं इसके लक्ष्य से पूरी तरह सहमत नहीं हूँ। यह एक प्रभावशाली IDE है, लेकिन नई भाषा की बजाय शायद Python के subset पर ध्यान देना बेहतर होता
    नहीं तो इसे इस वजह से नज़रअंदाज़ किया जा सकता है कि Scratch सिखाना आसान है, और Python सीखना ज़्यादा उपयोगी। पहला उन स्कूलों पर लागू होता है जहाँ developer-teacher हैं, और दूसरा उन programmer parents पर जो अपने बच्चों को सिखाते हैं
    एक software developer के रूप में मैंने अपनी पत्नी की elementary school/kindergarten programming classes में मदद की है, इसलिए इस क्षेत्र की समस्याओं के बारे में कुछ हद तक जानता हूँ

    • सोच रहा हूँ कि क्या “Python के subset” जैसा कोई विकल्प मौजूद है। अगर “real” programming तक ले जाने वाला कोई स्वाभाविक पुल हो, तो वह दिलचस्प होगा

  • संबंधित पोस्ट:
    Show HN: Pickcode – A new way to introduce programming to kids - https://news.ycombinator.com/item?id=33562193 - नवंबर 2022, 14 comments
    Show HN: PickCode – An educational coding environment for students after Scratch - https://news.ycombinator.com/item?id=32230329 - जुलाई 2022, 32 comments
    Show HN: Pickcode – A graphical code editor for education - https://news.ycombinator.com/item?id=31426331 - मई 2022, 4 comments
    दोबारा पोस्ट करना लगभग एक साल बाद ठीक है, और पिछली thread links उन पाठकों के लिए हैं जो और जानना चाहते हैं

  • मैं music programming की दिशा में मिलता-जुलता कॉन्सेप्ट बना रहा हूँ:
    https://glicol.org
    अच्छा होगा अगर landing page पर सीधे कुछ examples हों
    इसे आज़माते समय मैं अटक गया, और hint दाईं तरफ है, लेकिन बहुत नज़र नहीं आती। शायद इसे Svelte Tutorial(https://learn.svelte.dev/tutorial/welcome-to-svelte) की तरह rearrange किया जा सकता है
    syntax को लेकर भरोसा नहीं है। सोच रहा हूँ कि क्या आपने LOGO इस्तेमाल करने पर भी विचार किया था