Giới thiệu trên HN: Một ngôn ngữ trực quan mới cho giáo dục lập trình trẻ em

 (pickcode.io)
4 điểm bởi GN⁺ 2023-11-23 | 1 bình luận | Chia sẻ qua WhatsApp
  • Pickcode là một IDE trực tuyến dành cho các lớp khoa học máy tính ở trung học cơ sở và trung học phổ thông, hướng tới một nền tảng đơn giản, ổn định giúp giáo viên giảm thời gian dành cho việc vận hành lớp học
  • Các tính năng quản lý lớp học cốt lõi gồm hỗ trợ Chromebook, theo dõi bài làm của học sinh, cộng tác thời gian thực và xem lịch sử mã nguồn
  • Giáo viên có thể tùy chỉnh và sắp xếp tài liệu bài học và bài tập; Pickcode nêu rõ rằng nền tảng này không có tính năng hỗ trợ viết mã bằng AI
  • Có đánh giá từ giáo viên rằng công cụ này đã giúp học sinh dễ tiếp cận hơn và làm việc độc lập hơn trong các lớp Java, Web Development, Python và AP Computer Science Principles
  • Vì đây là công cụ tập trung vào việc tạo lớp học và quản lý học sinh hơn là một IDE chuyên nghiệp phức tạp, có thể xem đây là một lựa chọn giúp giảm xao nhãng trong môi trường lớp học

IDE trực tuyến được thiết kế cho lớp học

  • Pickcode là một IDE trực tuyến dành cho lớp CS ở trung học cơ sở và trung học phổ thông
  • Nhấn mạnh là một nền tảng đơn giản và ổn định giúp giáo viên tiết kiệm thời gian vận hành lớp học
  • Cung cấp các lối vào cơ bản như bắt đầu sử dụng, đăng nhập và trang gói giá

Tính năng vận hành lớp học và phản hồi từ giáo viên

  • Các tính năng chính của Pickcode được thiết kế xoay quanh việc tiến hành bài học và kiểm tra bài làm của học sinh
    • Hoạt động trên Chromebook
    • Có thể theo dõi bài làm của học sinh
    • Hỗ trợ cộng tác thời gian thực
    • Có thể xem lịch sử mã nguồn
    • Có thể tùy chỉnh tài liệu bài học
    • Có thể sắp xếp bài tập
    • Không có tính năng hỗ trợ viết mã bằng AI
  • Giáo viên đánh giá giao diện đơn giản nhưng có khả năng mở rộng, và được học sinh ở nhiều độ tuổi yêu thích
  • Có các trường hợp sử dụng trong các lớp Java, Web Development, Python và AP Computer Science Principles
  • Phản hồi cho biết công cụ này giúp học sinh sử dụng dễ dàng hơn, theo dõi công việc và tiến hành độc lập
  • Cũng có đánh giá rằng đội ngũ hỗ trợ phản hồi nhanh, hữu ích, và nhiều đề xuất đã được triển khai

Bài viết liên quan

1 bình luận

 
GN⁺ 2023-11-23
Ý kiến trên Hacker News

  • Tôi tự hỏi liệu có lý do chính đáng nào để bắt buộc dùng các từ khóa var, set, call hay không. BASIC không có những thứ đó, và theo ký ức mờ nhạt của tôi khi lần đầu học lập trình lúc nhỏ, các từ khóa như vậy có lẽ là độ phức tạp không cần thiết
    Ví dụ trong LOGO chỉ cần viết forward 10, left 90, nhưng call paint.forward(10), call paint.left(90) thì cảm giác quá mức và rườm rà

    • Các từ khóa được đưa vào để mỗi dòng dễ đọc thành lời hơn. Đặc biệt trong set x = 7, từ khóa làm rõ rằng bạn đang muốn thay đổi biến hay đang khẳng định sự bằng nhau
      Về mặt kỹ thuật, trong ngữ cảnh chương trình vẽ, cũng có thể biến forward() thành một phương thức cấp cao nhất, nhưng chúng tôi quyết định làm theo hướng hướng đối tượng hơn một chút để chuẩn bị cho lúc học sinh chuyển sang engine game 2D và điều khiển nhiều sprite
    • Ở đây tên gọi có vẻ hơi kém trực quan. forward và left trông giống như hướng di chuyển, nên đặc biệt dễ nhầm khi muốn “di chuyển” họa sĩ sang bên trái
      Thực tế forward là vẽ/di chuyển, còn left là xoay ngược chiều kim đồng hồ và cũng nhận đối số âm, nên call paint.draw(10), call paint.rotate(90) hoặc rotate("up") có vẻ dễ hiểu hơn
    • Nói ra chắc lộ tuổi mất, nhưng BASIC đầu tiên tôi học có lệnh gosub để gọi subroutine
      Nhân tiện, vì nghe nói các BASIC đời đầu là như vậy nên tôi cũng đánh số link bắt đầu từ 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 tôi từng dùng có LET X=10
    • Ấn tượng đầu tiên của tôi cũng vậy. Dù cả ngày tôi xem những đoạn code phức tạp hơn nhiều, nhưng nếu thử nghĩ từ góc nhìn của trẻ nhỏ, tôi nghĩ các nhiễu không cần thiết như thế này có thể khiến các em hiểu nhầm khá nhiều

  • Tôi đang giới thiệu Godot cho một đứa trẻ 10 tuổi. Trong 6 tháng qua cháu đã làm game bằng Scratch và thích Scratch, nhưng cũng bực bội với các giới hạn của nó
    Tôi cứ nghĩ cháu sẽ thích hơn nếu dùng một ngôn ngữ script thật sự, nhưng ngay khi bắt đầu dùng GDScript thì cháu nhanh chóng nản vì lượng phải gõ. Tay còn nhỏ nên khó học gõ 10 ngón, và việc gõ tên biến cùng lời gọi phương thức mất quá nhiều thời gian
    Cái này trông có vẻ là một điểm cân bằng rất phù hợp nên tôi sẽ thử xem

    • Giới hạn về tốc độ gõ là một điểm rất hay, và kỳ lạ là tôi chưa từng nghĩ đến
      Tôi đang có vài buổi học Python rất nhẹ với con 3 tuổi, và vẫn thắc mắc vì sao tiến độ lại chậm so với mức độ hiểu của bé. Giờ mới nhận ra chỉ riêng việc gõ ngoặc và dấu nháy thôi cũng đã mất nhiều thời gian
      Tôi thích dự án này và mong được dùng thử. Tôi đang dần chuyển sang suy nghĩ rằng lập trình cho trẻ em thì càng nhiều càng tốt. Cho các em tiếp xúc với việc lựa chọn giữa nhiều ngôn ngữ và quy trình làm việc khác nhau cũng có vẻ tốt
    • Tôi thắc mắc vì sao không dùng bàn phím cỡ trẻ em
    • Trải nghiệm của tôi cũng tương tự. Tôi giới thiệu Scratch cho con trai lúc 8 tuổi, và 2 năm sau, hiện giờ cháu đang làm những game cao cấp hơn tôi tưởng nhiều
      Nhưng khi tôi cho cháu xem một ngôn ngữ lập trình “thật”, cháu nói mọi thứ đó đều có thể làm bằng Scratch, mà không cần phải gõ nhiều như vậy
      Chúng tôi cũng thử GameMaker cùng nhau và tạo ra những kết quả rất hay, nhưng chỉ cần tôi quay đi một lát là cháu lại quay về dự án Scratch của mình. Đôi khi tôi tự hỏi liệu có phải sẽ tốt hơn nếu ngay từ đầu cháu bắt đầu bằng code như tôi ngày xưa không ;-)
    • Tôi cảm thấy giới hạn của Scratch nằm ở chỗ trẻ không thấy rõ cách quản lý độ phức tạp khi chương trình trở nên quá lớn
      Tuy vậy, chỉ cần chỉ ra vấn đề và hỏi xem có thể làm gì, trẻ sẽ bắt đầu suy nghĩ về vấn đề đó và tìm ra nhiều cách khả thi trong Scratch. Ví dụ như chia chương trình thành nhiều đối tượng hoặc agent
      Scratch mạnh hơn rất nhiều so với ấn tượng ban đầu hoặc chương trình đầu tiên mà nó gợi ra
    • GDScript là một ngôn ngữ tốt đến đáng ngạc nhiên. Ở nhiều mặt nó tốt hơn Python, chẳng hạn như có var và const

  • Chúc mừng Pickcode ra mắt. Mức độ hoàn thiện chi tiết rất tốt và có thể thấy nó được làm rất có tâm
    Tôi nghĩ trong lĩnh vực lập trình trực quan nhằm giúp người không phải lập trình viên tiếp cận lập trình dễ hơn, ít nhất có hai luồng
    Một số nỗ lực dùng giao diện trực quan để giảm gánh nặng học cú pháp, nhưng không che giấu tính chất mệnh lệnh hay nhu cầu tư duy thuật toán. Về cơ bản có thể xem đó là IDE với mức độ tiếp cận khác, và tôi nghĩ Pickcode cùng Scratch thuộc nhóm này
    Nhánh còn lại khám phá các mô hình lập trình khác có thể tương đối phù hợp với ẩn dụ trực quan. Nó cũng dẫn dắt người dùng tới một lối tư duy khác với lập trình mệnh lệnh. Node-RED là một ví dụ hay về việc khám phá lập trình dựa trên luồng, vốn là họ hàng gần với lập trình phản ứng hàm. LabVIEW cũng là họ hàng gần dựa trên luồng dữ liệu, nhưng có nhiều yếu tố kiểu ma thuật hơn. Thực chất đó là các giá trị mặc định khá thông minh và cách đặt tên biến nội bộ. Tôi cũng nghĩ đến Apple Automator
    Tôi không cho rằng bên nào nhất thiết tốt hơn hay tệ hơn, nhưng khi nhìn vào các ngôn ngữ trực quan, việc nghĩ đến sự phân biệt giữa mệnh lệnh và phản ứng rất hữu ích vì nó làm trải nghiệm người dùng cuối khác đi rất nhiều

    • Tôi nhớ việc dạy workshop về ngôn ngữ hàm như Elm cho người mới bắt đầu lại dễ hơn dạy cho chuyên gia. Vì đầu óc người mới chưa bị một kiểu tư duy mệnh lệnh kiểu C nào đó làm ô nhiễm

  • Điểm “trải nghiệm chỉnh sửa mã được cấu trúc hoàn toàn, và thay vì gõ thì chọn từ menu” thật sự rất hay
    Ước gì có một thứ như vậy cho lập trình viên trưởng thành, tức một trình chỉnh sửa có cấu trúc đa dụng có thể dùng cho nhiều ngôn ngữ lập trình. Khi lập trình, ý định nảy ra đầu tiên là mang tính ngữ nghĩa. Kiểu như định nghĩa một hàm ở đây, kiểm tra một điều kiện ở kia
    Vậy thì tôi không hiểu vì sao không truyền trực tiếp ý định ngữ nghĩa đó cho trình chỉnh sửa. Tại sao trước hết phải tuần tự hóa ý định thành chuỗi, rồi để trình chỉnh sửa phân tích cú pháp lại theo cách dễ phát sinh lỗi? Như vậy tạo chỗ cho những lỗi cú pháp ngớ ngẩn như lỗi gõ nhầm, ngoặc không khớp, lỗi độ ưu tiên toán tử xen vào; chẳng phải chỉ còn lỗi ngữ nghĩa thì tốt hơn sao
    Một trình chỉnh sửa như vậy cũng không nhất thiết phải khó dùng với bàn phím. Tương tự như Excel không hề khó dùng với bàn phím. Có lẽ nó cũng có thể hoạt động theo kiểu bộ gõ ngôn ngữ Đông Á: nhập trong “cửa sổ tổ hợp” rồi chọn trong “cửa sổ ứng viên” để chèn vào

    • Đã có rất nhiều thử nghiệm như vậy. Nó không hẳn là “ý tưởng chưa ai từng nghĩ tới”, mà gần với “ý tưởng rất nhiều người đã nghĩ tới và thử, nhưng lập tức gặp vấn đề lớn” hơn
      Theo tôi hiểu, vấn đề lớn trong trường hợp này là người ta dễ muốn đặt ràng buộc rằng mọi trạng thái trung gian mà mã đi qua đều phải hợp lệ về mặt ngữ nghĩa. Nhìn bề ngoài thì hấp dẫn, nhưng trong thực tế lại trở thành một ràng buộc chí mạng. Ngay cả người giỏi cũng thường nghĩ theo cách hơi lỏng lẻo rồi sửa mã sau, kể cả ở cấp độ từng dòng. Việc bắt buộc lúc nào cũng phải hợp lệ 100% lệch rất xa với cách tư duy thực tế
      Tôi có xu hướng xem sự lệch pha này là căn bản. Tôi không biết liệu có dù chỉ một số rất nhỏ con người suy nghĩ theo cách đó hay không. Nghe nói ngay cả các nhà toán học chuyên nghiệp trong công việc thực tế cũng thường nghĩ vượt trước rồi mới lấp phần chặt chẽ sau. Nếu họ còn không tiến từng bước một cách nghiêm ngặt, thì ai sẽ làm vậy
      Lập trình đã ổn định quanh tự động hoàn thành hiểu ngữ nghĩa và gợi ý, và rất có thể đó không phải là kết quả của sự lười biếng đơn thuần mà là điểm tối ưu thực tế
      Nếu ai đó kiên trì đẩy đến cùng thì vấn đề có thể được giải quyết, nhưng tôi muốn nói rằng dù ở đây có quả ngọt, thì cũng không phải loại quả treo thấp dễ hái
      Như saurik đã nói, thế giới Lisp dùng Emacs là thứ gần với điều này nhất, nhưng dù vậy vẫn có thể làm bất cứ gì mình muốn. Chỉ là có nhiều công cụ giúp làm việc theo hướng ngữ nghĩa hơn, chứ không có gì bị cưỡng ép tuyệt đối
    • Tôi nghĩ những thứ như vậy cũng khá nhiều. Có Scratch hoặc họ hàng của nó là Snap(https://snap.berkeley.edu/snap/snap.html), trình chỉnh sửa luồng trực quan cho React(https://app.flowhub.io/#project/c111454c9fd2f74d37d1e8a4e739...), và những thứ tương tự như https://retejs.org/
    • Bạn nói muốn thứ như vậy cho lập trình viên trưởng thành, nhưng Blythe Omnis 7 đã có từ năm 1996 hoặc trước đó. Đó là một nền tảng/giải pháp RAD hỗ trợ cả Windows lẫn Macintosh
      Tôi đã kiếm được việc vì khi ấy tôi là ứng viên duy nhất từng nghe nói đến phần mềm đó. Nhờ đã đọc một bài ngắn trên tạp chí
      https://en.wikipedia.org/wiki/Omnis_Studio
      Cách lập trình bằng cách bấm vào danh sách thả xuống và popup không được thiết kế tốt cho lắm. Chương trình trông như một danh sách, và khi muốn chỉnh một dòng thì một hộp thoại modal hiện ra, chỉ cho sửa đúng dòng đó. Tất nhiên là không có IntelliSense hay hoàn thành mã
      Chỉ nghĩ đến thôi đã thấy PTSD trỗi dậy, đến mức cần rượu hoặc thuốc lá
    • Ví dụ, https://github.com/nocode-js/sequential-workflow-designer được thiết kế theo kiểu này. Bạn lập trình logic bằng cách đặt các hành động đã định nghĩa sẵn theo đúng thứ tự, và lập trình ở mức cao
    • Tôi hiểu là những người làm Lisp bằng Emacs có trải nghiệm kiểu này. Vì họ có thể suy nghĩ và làm việc bằng form, chứ không chỉ là văn bản thuần

  • Một trong những tính năng tôi thích nhất ở Scratch là không thể tạo lỗi cú pháp. Các khối hoặc khớp vào nhau, hoặc không khớp, chỉ có hai khả năng. Vì vậy tôi nghĩ trẻ em có thể bắt đầu và chơi dễ hơn mà không cần giải thích riêng hay học kèm
    Sau khi làm theo vài bước đầu của hướng dẫn hình vuông, tôi tự bấm thử linh tinh, và nó tạo ra call math paint.forward() dẫn đến lỗi cú pháp. Dĩ nhiên dòng đó là rác, nhưng tôi không tìm ra lệnh math phải hoạt động thế nào. Có lẽ nếu theo tiếp hướng dẫn thì sẽ được giải thích, nhưng tôi nghĩ khả năng khám phá cũng quan trọng

    • Scratch không tạo lỗi cú pháp, nhưng cũng không phàn nàn khi thứ gì đó lệch khỏi vị trí. Ví dụ, khi thao tác với các khối mà một khối bị rơi ra, chương trình vẫn chạy nhưng không hoạt động đúng
      Khi có nhiều khối, chúng cũng có thể chồng lên nhau nên khá khó phát hiện. Cũng có vấn đề quên đối số của khối. Dù vậy nó vẫn chạy nhưng không hoạt động
      Lập trình trực quan rõ ràng tốt hơn cho trẻ em, nhưng tôi nghĩ cần một cách tiếp cận nghiêm ngặt hơn Scratch và khả năng gỡ lỗi tốt hơn
    • Một ưu điểm khác của Scratch, chính xác hơn là của các khối, là có thể điều chỉnh khá dễ cho ngôn ngữ mới. Chúng tôi đã dùng các khối để khách hàng IoT thiết lập cho thiết bị phản ứng với sự kiện và gửi sự kiện đến thiết bị khác; tất cả những thứ này được chuyển thành cấu hình JSON để tải lên

  • Trông thật sự tốt. Nó làm tôi nhớ đến thời Khan Academy làm phiên bản dựa trên khối của trình chỉnh sửa ProcessingJS
    UI hơi thô và khó bảo trì nên cuối cùng đã dừng, nhưng cái này trông khá mượt. Tôi thích việc nó cung cấp thêm nhiều con đường để lập trình viên mới bước vào lập trình có kiểu. Tôi cũng nghĩ phần lớn block coding cách quá xa mã thực tế

    • Có lẽ UI chỉnh sửa dạng khối như thế này nên có thể được tự động sinh ra từ mô tả trừu tượng của ngữ pháp, kiểu như thứ mà parser tree-sitter dùng
      Đôi khi kiểu chỉnh sửa dựa trên khối này khi kết hợp với kiểm tra kiểu cũng cho phép lấp các “lỗ” một cách thông minh dựa trên truy vấn. Có lẽ có thể thấy rõ nhất trong các trình chỉnh sửa cho ngôn ngữ hàm thuần như Agda

  • Gợi nhớ đến BASIC của ZX81. Không gõ từ khóa, mà trên bàn phím đặc biệt có các phím riêng cho từng từ khóa
    Trình biên tập nhạy theo ngữ cảnh; nói cách khác, chính người dùng là bộ phân tích từ vựng do parser dẫn dắt. Thời đó, việc nhận ra liệu mình đang nhập từ/số hay đang nhập từ khóa, và đó là loại từ khóa nào, cảm giác hơi như ma thuật. Thật ra, phần quan trọng về mặt giáo dục là tôi đã hiểu điều đó
    Điều quan trọng trên ZX81 là tiết kiệm bộ nhớ bằng cách lưu token thay vì biểu diễn dạng văn bản. RAM chỉ có 1KB, và trong đó còn bao gồm cả bộ nhớ hiển thị. Cũng không có GPU riêng. Nhờ phân tích cú pháp ngay khi nhập, có lẽ việc thực thi cũng nhanh hơn

  • Trang web được trau chuốt rất tốt, nhưng tôi không hoàn toàn đồng ý với mục tiêu. Đây là một IDE ấn tượng, nhưng có lẽ tôi sẽ tập trung vào một tập con của Python hơn là một ngôn ngữ mới
    Nếu không, nó có thể bị bỏ qua vì Scratch dễ dạy hơn, còn Python hữu ích hơn để học. Trường hợp trước là ở các trường có giáo viên là lập trình viên, trường hợp sau là với các phụ huynh lập trình viên dạy con
    Là một nhà phát triển phần mềm, tôi từng giúp vợ trong các lớp lập trình ở tiểu học/mẫu giáo, nên cũng hiểu phần nào các vấn đề trong lĩnh vực này

    • Tôi tò mò liệu có lựa chọn thay thế nào tương ứng với “tập con của Python” không. Sẽ khá thú vị nếu có một cây cầu tự nhiên dẫn sang lập trình “thật”

  • Các bài liên quan:
    Show HN: Pickcode – A new way to introduce programming to kids - https://news.ycombinator.com/item?id=33562193 - tháng 11 năm 2022, 14 bình luận
    Show HN: PickCode – An educational coding environment for students after Scratch - https://news.ycombinator.com/item?id=32230329 - tháng 7 năm 2022, 32 bình luận
    Show HN: Pickcode – A graphical code editor for education - https://news.ycombinator.com/item?id=31426331 - tháng 5 năm 2022, 4 bình luận
    Đăng lại sau khoảng 1 năm thì ổn, còn các liên kết tới những thread trước là dành cho độc giả muốn tìm hiểu thêm

  • Tôi đang làm một ý tưởng tương tự theo hướng lập trình âm nhạc:
    https://glicol.org
    Sẽ hay hơn nếu ngay trên landing page có sẵn vài ví dụ
    Khi thử làm bài học thì bị kẹt; gợi ý nằm bên phải nhưng không nổi bật lắm. Có thể bố trí lại giống Svelte Tutorial(https://learn.svelte.dev/tutorial/welcome-to-svelte)
    Tôi chưa chắc về cú pháp. Không biết bạn đã cân nhắc dùng LOGO chưa