Haskell for Kids

[eng. Vassil Ognyanov Keremidchiev]

Здравейте!

Какво мислите за идеята да се учи програмиране за деца 3-5ти клас с Haskell или друг функционален език?

Пример:

http://cdsmith.wordpress.com/2011/08/16/haskell-for-kids-week-1/

Според мен би било по-добре да се започне от пред назад, а не обратното. Т.е. с функционални езици и после на императивни, като пораснат. 

[Stefan Kanev]

Ще съм кратък, ако има нужда, кажете - ще разясня.

Аз мисля, че няма значение. Или по-точно - зависи на какво искаш да ги научиш.

Ако ще ги учиш да кодят мъничко и практически, езика е Python. Или нещо в тоя дух. Един модел и толкова - да тракат.

Ако обаче искаш да направиш от тях ерудирани програмисти - не мисля, че има голямо значение откъде ще започнеш. Както е трудно да си избиеш императивния модел като учиш функционалния, така е вярно и обратното. Ако ще учат всички модели, не мисля, че има огромно значение в какъв ред, стига да подбереш правилните езици (Smalltalk е добър първи език, предвид че е ОО; Java не е).

Иначе, мисля, че това да се учат хора на Haskell е супер яко, но неразвитите мозъци се мотивират от резултати, а не от математическа елегантност, така че зависи какво ще постигат.

2013/10/1 eng. Vassil Ognyanov Keremidchiev <var...@gmail.com>

--
You received this message because you are subscribed to the Google Groups "Polyglot Quine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to polyglot-quin...@googlegroups.com.
To post to this group, send email to polyglo...@googlegroups.com.
Visit this group at http://groups.google.com/group/polyglot-quine.
For more options, visit https://groups.google.com/groups/opt_out.

[Veselin Georgiev]

Съгласен съм със Стефан, че неразвитите мозъци се мотивират от
резултати. Личното ми мнение е, че първият език трябва да е такъв, на
който можеш да напишеш игра или вирус. Мен това поне ме вълнуваше като
келеш :)

По-здрави,
Веско

2013/10/1 Stefan Kanev <stefan...@gmail.com>:

[Boyko Bantchev]

Ето друг пример пряко по зададения от Васил въпрос: чудесен малък
функционален език с графични възможности:

http://www.cs.ox.ac.uk/geomlab

Предназначен е тъкмо за деца, но го харесват и възрастни лаици в
програмирането, вкл. хуманитари. Преди време аз самият си поиграх
доста с него и изпитах голямо удоволствие! Дори направих някои
надстройки – в езика има недокументирани средства за това.

Какво му е ценното на GeomLab?
Езикът е малък и прост, но полезен: има си анонимни функции, локални
определения и closures, определения чрез съпоставяне по образец, а
построяването на рисунки (фигури) става конструктивно, чрез операции
„сложи до“, „сложи над“, „завърти“ и „обърни“. Това според мен е
огромно предимство пред подхода с изрично задаване на координати и
размери, вкл. и в цитирания от Васил пример с Haskell и Gloss.
Освен това всичко се върши в проста интегрирана среда – където са
определенията, там е и изпълнението – а реализацията е съвсем малка по
обем и върви навсякъде, където има JVM (програмата е писана на Java).

Следното пък е реализация на GeomLab чрез Flex:

http://nrich.maths.org/5631

[Boyko Bantchev]

Може да се забележи, че в цитираната от Васил разработка за (и с) деца
не е много уместно да се говори за програмиране на Хаскел. Къде там
има Хаскел, какъв Хаскел има? На практика – никакъв. Всичко се
излива в преки обръщения към геометричните функции, и то с аргументи-
константи. Не виждам пресмятане на зависимости или др.под. Затова
примерът не ни дава възможност да съдим как децата се справят или
харесват какъвто и да е модел на функционално програмиране. GeomLab,
който споменах в предния пост, би бил много по-информативен в това
отношение: създаването на сложни фигури там подтиква към рекурентни
(индуктивни) определения, а допуска и прилагане на функции от висок
ред. За съжаление там пък няма данни дали и с какви деца е работено
и какви са резултатите от това.

Дали ф.пр. е изобщо пригодно за деца? Аз имам такава хипотеза: ако
езикът набляга на пресмятания с изрази и получаваните стойности са
лесно наблюдаеми, то да – защото този модел е вече познат на децата
чрез училищната алгебра и само трябва да се доразвие. Тук не са
нужни никакви заклинания като include, import, main, class и пр.
пустословие. Никакви променливи, които наистина се променят, никакви
„цикли“, а още по-малко – описания на типове. Минимум средства за
програмно четене и писане – нали имаме диалогова среда, тя върши тази
работа. Изобщо възможно най-малко нови понятия. Типово строг език е
по-скоро вреден, отколкото полезен. Трябва да има обаче една-две
прости и нагледни, но практични структури за образуване на сложни
стойности – например списък, но още по-добре симетрична редица с
разнородно съдържание.

Много интересно е (и напълно неясно за мен) доколко отрано децата
биха могли да възприемат характерните за функционалното програмиране
абстракции – функции-стойности, локални определения, частично
прилагане (напр. (/5) – „функцията, която дели на 5“), образуване
на функции чрез пресмятане (напр. „f, после g“ – композиция).
Мога само да споделя наблюдение, че тези неща изглеждат неразбираеми
за някои мои (непрограмиращи) колеги математици. Но може би пък за
свежи мозъци да е по-лесно, знам ли. Май и по света липсва опит в
това отношение.

Като се говори за деца, важното е да разбират и да им е интересно
това, което ще правят. Спомена се писане на игри. Може би става,
но сигурно ще е все по-трудно да се мотивират за това, защото е сложно
и защото имат пред очите си свръхнапреднали примери, които няма как да
наближат със собствени сили.

И накрая, да се говори за евентуална професионална ориентация при деца
4-5кл. – и с оглед на това да се избира на какво да се учат – е твърде
преждевременно.

[Krasimir Angelov]

На 02 октомври 2013, 10:04, Boyko Bantchev <boy...@gmail.com> написа:
>
> http://www.cs.ox.ac.uk/geomlab
>

Много вдъхновяващо! Не бях го виждал преди, но определено е нещо с
което бих започнал да занимавам 4-5 годишно дете.

Бях попадал също на това:

http://scratch.mit.edu/

простичък визуален език за правене на игри. Подходящ е за деца, но не
е функционален. GeomLab ми се струва по-елегантен и изчистен.

[Boyko Bantchev]

> Бях попадал също на това:
> http://scratch.mit.edu/
> простичък визуален език за правене на игри. Подходящ е за деца, но не
> е функционален. GeomLab ми се струва по-елегантен и изчистен.

Среди за визуално правене на „игри“ или подобни има доста, например:

StarLogo TNG http://education.mit.edu/starlogo-tng
Alice http://alice.org
Blockly http://google-blockly.googlecode.com
Sugar http://sugarlabs.org
Kodu http://research.microsoft.com/en-us/projects/kodu
Stagecast http://stagecast.com
eToys http://squeakland.org
Waterbear http://waterbearlang.com/garden.html?plugin=javascript

Повечето от тях и външно, и по същество приличат на Scratch, както
лесно се забелязва. Обаче претенцията, че обучават на програмиране,
е спорна, за мен дори неоснователна.

Както казваш, Scratch е нефункциомален език. Бих добавил
нефункционален и в по-общия смисъл на думата: не функционира :)
Няма процедури, да не говорим за рекурсия, няма структурни стойности,
изобщо няма определяни от потребителя строителни блокове.

Подобен и надстроен над Scratch визуален език е
BYOB¹ (http://byob.berkeley.edu) – сега виждам, че вече преименуван на
Snap! – който обаче си има и процедури, вкл. от висок ред, и списъци,
и потребителски блокове, и изобщо се държи като език.

Така или инак, моите симпатии са на страната на писмените езици за
програмиране. Да ме прощават визуалните езици, но за очите ми
писмените са по-красиви.

—————————————————————
¹ BYOB (Snap!) е проектиран от Брайън Харви, светла глава в обучението
по програмиране за деца, автор на знаменитото UCB Logo и на страхотен
тритомен учебник по програмиране за всякакви възрасти чрез този език.
(Учебникът сега е свободно достъпен.)

[Krasimir Angelov]

На 02 октомври 2013, 18:46, Boyko Bantchev <boy...@gmail.com> написа:
> Както казваш, Scratch е нефункциомален език. Бих добавил
> нефункционален и в по-общия смисъл на думата: не функционира :)
> Няма процедури, да не говорим за рекурсия, няма структурни стойности,
> изобщо няма определяни от потребителя строителни блокове.

Вярно. Сега се сещам, че трябваше да правя разни въртели и copy+paste
за да направя каквото искам.

[Slavomir Kaslev]

2013/10/1 eng. Vassil Ognyanov Keremidchiev <var...@gmail.com>

Според мен би било по-добре да се започне от пред назад, а не обратното. Т.е. с функционални езици и после на императивни, като пораснат. 

Когато това се случи, това ще е края на всички императивни езици. Никой няма да пише на императивен език като порасне. По-скоро ще code-gen-ват C++ или на каквото им трябва за резултатния софтуер от не-императивен език (Хаскел, визуален, или др.). Както в момента никой не пише "high-performance" JavaScript код на ръка, а компилират от C++ до asm.js чрез Emscripten.

--
Slavomir Kaslev

[Stefan Kanev]

Аз започвам да имам все по-дълбоки съмнения за това откъде трябва да се започне. Правят ми впечатление две неща.

Първо, всички фенове на функционалните езици, които познавам, са започнали с императивни и то, императивни от ниско ниво (например C). Докато не мога да съдя за дидактичния аспект на императивните езици, струва ми се че контраста между двете е важен за grok-ването на това колко яки са функционалните.

Второ, напоследък се занимавам мъничко с алгоритми и ми става интересно до каква степен функционалните езици са приложими за преподаване на алгоритми. Докато определено голяма част от анализа може да се направи с функционален език, струва ми се че императивния е много по-интуитивен.

С други думи, струва ми се, че ученето на императивни езици е имало много важна роля в това повечето от нас да започнат да разбират програмирането, но сме много склонни да не я забелязваме.

Някой друг има ли същото усещане? :)

2013/12/17 Slavomir Kaslev <slavomi...@gmail.com>

--

[Veselin Georgiev]

Напълно съгласен съм. Банчев беше постнал тук навремето една статия на Александреску - където беше даден като пример хаскелифицираният вариант на quicksort, който пропуска основната иновация на Хоор. В частност, на Haskell много трудно може да се дефинира in-place partition-а на quicksort-а, което е всъщност фундаменталното за самия алгоритъм. И по-общо, дефект на функционалните езици е липсата на достатъчно внимание върху random access iterator-ите, като или просто ги няма, или се третират като второразредни граждани. А random-access операциите върху масиви са ключови за някои алгоритми.

[Iskren Chernev]

On Dec 17, 2013 12:19 AM, "Stefan Kanev" <stefan...@gmail.com> wrote:
>
> Аз започвам да имам все по-дълбоки съмнения за това откъде трябва да се започне. Правят ми впечатление две неща.

Мога да добавя -- всички добри програмисти които познавам знаят C, и (доста вероятно) са започнали с него.

Моето обяснение е, че всеки добър програмист трябва да знае целия stack, и ходенето нагоре по стека е винаги по-лесно, от колкото ходенето надолу. Липсва елемента на магията, който присъства при изучаването на езици от високо ниво: "тия неща са сложни, ние сме ги опаковали в тоя интерфейс, не го мисли -- работи". Ако не си писал на C нямаш желанието и контекста да разбереш как работят нещата всъщност.

Аз лично в момента много бих се замислил преди да напиша нещо на C (бих го написал на нещо друго). Мога да си представя какво желание имат останалите да го учат, при положение че функция от 10 реда на python, на C би отнела 500 (с имплементацията на хеш-таблица, динамични масиви и os примитиви за вход/изход). Поне мога да си представя как би изглеждало, ако не знаех C - не.

От друга страна ако си любопитен рано или късно стигаш до C, даже да не си започнал от там. Също не смятам, че от всеки може да стане добър програмист -- така че нека се учат масите на php и javascript, пък специалните кадри ще се проявят в последствие.

[Iskren Chernev]

Сега се сетих -- аз не съм почнал да пиша на C. Почнах на Turbo Basic
(ако може да се каже почване), после малко logo, по същото време
pascal, и след това C++ в пълни подробности (а не това осакатено нещо
дето се преподава в университета). Даже в първите си състезателни
години съм писал на паскал, струваше ми се че C/C++ e overkill. Не
мога да кажа кое точно ме накара да си променя мнението :)

Спомням си, как на първия урок по C в СМГ (това е било преди паскала,
но твърде кратко за да го броя за учене), когато обясняваха за типове
данни, аз постоянно си мислех: "Абе тоя език за нищо не става. На
basic пишеш a = 5 и то е integer, пишеш a = 5.5 и то е double, тия
типове в C имат ограничения (max_int < 2^15), докато basic няма (е --
тук под няма се разбира -- не съм знаел че има ;-))". Да не говорим,
че на basic се пише по-лесно, интерпретатора (тогава не съм знаел) е
по-малък (а не 20 дискети djgpp), няма нужда от компилация,
деклариране на променливи ...

С други думи, много трудно е да се осъзнае C, ако преди това главата
ти е "заразена" с разни други "силно експресивни" езици -- няма
контекст с който всичко това да се обясни. Може би въпроса за първи
език е същия като въпроса кога да се изучава теория на множествата.
Според Тинко Тинчев, трябва да е втори или трети курс. След като си
взел малко Анализ и Алгебра и имаш идея от формално доказателство и
математика, и преди мозъка ти да се е затлачил с подробности от високо
ниво. Аз нямам наблюдения върху това, но той преподава от десетки
години, и постоянно експериментира с програмата, така че бих казал че
има добра идея.

2013/12/17 Iskren Chernev <iskren....@gmail.com>:

[Stefan Kanev]

С други думи, много трудно е да се осъзнае C, ако преди това главата
ти е "заразена" с разни други "силно експресивни" езици -- няма
контекст с който всичко това да се обясни. Може би въпроса за първи
език е същия като въпроса кога да се изучава теория на множествата.
Според Тинко Тинчев, трябва да е втори или трети курс. След като си
взел малко Анализ и Алгебра и имаш идея от формално доказателство и
математика, и преди мозъка ти да се е затлачил с подробности от високо
ниво. Аз нямам наблюдения върху това, но той преподава от десетки
години, и постоянно експериментира с програмата, така че бих казал че
има добра идея.

Откривам нещо вярно в това. Сега си играя да пиша прости неща на C и откривам, че всичките ми познания за абстракции, изразни средства и писане на четим код са ключови да го направя адекватно. Когато учих C за първи кода ми вероятно е бил много по-голяма каша, докато сега мога да приложа познание натрупано от други места и то по относително идиоматичен C начин.

[Krasimir Angelov]

На 17 декември 2013 г., 9:18, Stefan Kanev <stefan...@gmail.com> написа:
> Първо, всички фенове на функционалните езици, които познавам, са започнали с
> императивни и то, императивни от ниско ниво (например C). Докато не мога да
> съдя за дидактичния аспект на императивните езици, струва ми се че контраста
> между двете е важен за grok-ването на това колко яки са функционалните.

Дори когато пиша на Haskell, ако искам кода да върви бързо трябва да
имам представа как той ще се изпълнява. За осъзнаването на това трябва
да знам как работи виртуалната машина на Haskell, какво прави
компилатора и как работи самия хардуер. Познаването на всички нива е
изключително важно. При мен първият език беше вградения Бейсик в
Правец 8C, и след това асемблер. Нямам представа как щеше да е ако бях
почнал с Haskell. Вероятно с него щях да си остана, но щях да съм
изпуснал много от това което знам.

[Slavomir Kaslev]

2013/12/17 Krasimir Angelov <kr.an...@gmail.com>

Дори когато пиша на Haskell, ако искам кода да върви бързо трябва да

имам представа как той ще се изпълнява. За осъзнаването на това трябва
да знам как работи виртуалната машина на Haskell, какво прави
компилатора и как работи самия хардуер.

Защо не IO monad? Или monad transformers, или др.

-- 

Slavomir Kaslev

[Krasimir Angelov]

На 17 декември 2013 г., 11:52, Slavomir Kaslev
<slavomi...@gmail.com> написа:

> Защо не IO monad? Или monad transformers, или др.

Какво имаш предвид?

[Slavomir Kaslev]

Ако искаш бързина, защо не пишеш C еквивалент в IO monad Haskell? Тогава знаеш как ще се изпълни кода, и не е нужно да знаеш как стека под теб работи.

--
Slavomir Kaslev

[Slavomir Kaslev]

2013/12/17 Stefan Kanev <stefan...@gmail.com>

Много добре казано. Напомня ми за един стар спор относно обектно-ориентираното програмиране. Тогава аз твърдях, че C е напълно достатъчен и адекватен език. 

--
Slavomir Kaslev

[Slavomir Kaslev]

2013/12/17 Veselin Georgiev <anr...@gmail.com>

Напълно съгласен съм. Банчев беше постнал тук навремето една статия на Александреску - където беше даден като пример хаскелифицираният вариант на quicksort, който пропуска основната иновация на Хоор. В частност, на Haskell много трудно може да се дефинира in-place partition-а на quicksort-а, което е всъщност фундаменталното за самия алгоритъм. И по-общо, дефект на функционалните езици е липсата на достатъчно внимание върху random access iterator-ите, като или просто ги няма, или се третират като второразредни граждани. А random-access операциите върху масиви са ключови за някои алгоритми.

Версията QuickSort със списъци на Haskell е отвратителна. Аз си мислех наскоро, че може да се напише директно както е на C, в do-notation под IO monada. Обаче, е по-интересно, ако абстрахираш IO и мислиш само за операциите които се прилагат върху вектора. Може да го напишеш в Writer-State монада и само да пазиш какви размени са се случили. В резултат получаваш директно пермутацията, която трябва да приложиш върху вектора. Естествено, това са празни приказаки без код; трябва да си поиграя.

--
Slavomir Kaslev

[Slavomir Kaslev]

2013/12/17 Slavomir Kaslev <slavomi...@gmail.com>

2013/12/17 Veselin Georgiev <anr...@gmail.com>

Напълно съгласен съм. Банчев беше постнал тук навремето една статия на Александреску - където беше даден като пример хаскелифицираният вариант на quicksort, който пропуска основната иновация на Хоор. В частност, на Haskell много трудно може да се дефинира in-place partition-а на quicksort-а, което е всъщност фундаменталното за самия алгоритъм. И по-общо, дефект на функционалните езици е липсата на достатъчно внимание върху random access iterator-ите, като или просто ги няма, или се третират като второразредни граждани. А random-access операциите върху масиви са ключови за някои алгоритми.

Версията QuickSort със списъци на Haskell е отвратителна. Аз си мислех наскоро, че може да се напише директно както е на C, в do-notation под IO monada. Обаче, е по-интересно, ако абстрахираш IO и мислиш само за операциите които се прилагат върху вектора. Може да го напишеш в Writer-State монада и само да пазиш какви размени са се случили. В резултат получаваш директно пермутацията, която трябва да приложиш върху вектора. Естествено, това са празни приказаки без код; трябва да си поиграя.

Има и друг чист функционален начин да напишеш QuickSort на Haskell. Строиш двоично дърво за търсене и правиш DFS. Като време, прави доказуемо същите операции като QuickSort (наскоро гледах курса на Седжуик по алгоритми). Като памет, ти трябва дърво и още един списък/вектор.

Проблема на Haskell е, че езика е достатъчно експресивен да изразиш идеята на алгоритъма. Иначе има много начини да го напишеш.

 

--
Slavomir Kaslev

[Slavomir Kaslev]

Имаше едно есе (което гугъл вече не помни) "Python is an acceptable Lisp.". Според мен "Haskell is an acceptable C". Можеш да правиш всичко, което можеш на C (ако ти се наложи, не дай боже). Плюс логически доказана типова система, алгебрични типове и generic programming (вместо откачената типова система на C++). От долу в стека имаш опция (май вече по подразбиране) за LLVM.

Но си мисля, че the sweet spot е не IO monad, a Writer monad и генерация на код. Всички искат HTML5, но на никой не му се пише JavaScript.

--
Slavomir Kaslev

[Krasimir Angelov]

На 17 декември 2013 г., 12:37, Slavomir Kaslev
<slavomi...@gmail.com> написа:

> Ако искаш бързина, защо не пишеш C еквивалент в IO monad Haskell? Тогава
> знаеш как ще се изпълни кода, и не е нужно да знаеш как стека под теб
> работи.

Ами не мисля, че IO монадата ще направи кода автоматично по-бърз.
Примерно IORef въобще не е като променливa на C. Това е указател към
клетка която може да се променя. Освен това всички клетки са навързани
в списък който събирача на боклук трябва да обходи за да си свърши
работата. Като цяло прекаляването с IORef и подобните му прави кода
грозен без да го прави по-ефективен. Много по-добре е да пишеш чист
функционален код, но в случаите когато кода е критичен трябва да си
внимателен с реализацията.

Иначе да, ползвам и C. В момента имаме компилатор написан на Haskell и
runtime написан на C. Предишната версия на runtime-а беше също на
Haskell.

[Slavomir Kaslev]

2013/12/17 Krasimir Angelov <kr.an...@gmail.com>

На 17 декември 2013 г., 12:37, Slavomir Kaslev
<slavomi...@gmail.com> написа:

> Ако искаш бързина, защо не пишеш C еквивалент в IO monad Haskell? Тогава
> знаеш как ще се изпълни кода, и не е нужно да знаеш как стека под теб
> работи.

Ами не мисля, че IO монадата ще направи кода автоматично по-бърз.
Примерно IORef въобще не е като променливa на C. Това е указател към
клетка която може да се променя. Освен това всички клетки са навързани
в списък който събирача на боклук трябва да обходи за да си свърши
работата. Като цяло прекаляването с IORef и подобните му прави кода
грозен без да го прави по-ефективен. Много по-добре е да пишеш чист
функционален код, но в случаите когато кода е критичен трябва да си
внимателен с реализацията.

Аз имах предвид, asm.js тип C. Алокираш си един голям вектор и си смяташ в него. Зависи какво смяташ де. За мен CPU bound код е нещо като обръщане на матрици, диференциални уравнения, трасиране на лъчи или нещо подобно.

 

Иначе да, ползвам и C. В момента имаме компилатор написан на Haskell и
runtime написан на C. Предишната версия на runtime-а беше също на
Haskell.

--
You received this message because you are subscribed to the Google Groups "Polyglot Quine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to polyglot-quin...@googlegroups.com.
To post to this group, send email to polyglo...@googlegroups.com.
Visit this group at http://groups.google.com/group/polyglot-quine.
For more options, visit https://groups.google.com/groups/opt_out.

--
Slavomir Kaslev

[Krasimir Angelov]

На 17 декември 2013 г., 13:31, Slavomir Kaslev
<slavomi...@gmail.com> написа:

> Аз имах предвид, asm.js тип C. Алокираш си един голям вектор и си смяташ в
> него. Зависи какво смяташ де. За мен CPU bound код е нещо като обръщане на
> матрици, диференциални уравнения, трасиране на лъчи или нещо подобно.

Ами понякога и това е решение зависи от задачата.

[Slavomir Kaslev]

Btw, според мен има конспирация, че за всеки алгоритъм, който ползва random access to memory има чисто конструктивен/фунцкионален алгоритъм като случая с QuickSort. И конспирацията всъщност идва от това, че зад всеки алгоритъм има теорема, че работи (трябва да може да докажеш, че работи, за да публикуваш). Обаче, поради Curry-Howard, зад тази теорема, стои Haskell програма.

Един вид, подозирам, че всички алгоритми са функционални дълбоко в себе си, но ние ги знаеме и преподаваме в императивна форма.

--
Slavomir Kaslev

[Nikolay Bachiyski]

2013/12/17 Stefan Kanev <stefan...@gmail.com>
> …

> С други думи, струва ми се, че ученето на императивни езици е имало много важна роля в това повечето от нас да започнат да разбират програмирането, но сме много склонни да не я забелязваме.
>
> Някой друг има ли същото усещане? :)

Нямаме база за сравнение, за да може каквото и усещане да имаме да има какъвто и да е шанс за валидност. Винаги каквото учим първо, особено в по-ранна възраст, оставя сериозен отпечатък върху компютърогледа ни.

Но въпросът с какво е най-добре да се започне е много интересен.

Императивните езици са много по-добър способ да разберем как работят компютрите на физическо ниво. Инструкции, разклоняване, съответно и повечето алгоритми са по-добре разбираеми. Функционалните пък са много по-удобни за обучение по дизайн на програми и осъзнаването що е това абстракция.

В крайна сметка всичко се свежда до два много основни и важни въпроса:

* На какво искаме да научим някого

* Как да подходим – top-down или bottom-up

Негласно дотук считаме, че трябва да се научи всичко – и ефективен код близо да машината, и алгоритми, и абстракции, и миене на чинии, и дизайн на програми. Това покрива първия въпрос.

Преди няколко месеца трябваше да науча трима души на основите на програмирането за десетина часа разпределени в няколко дни. Някак напълно естествено ми се получи алтерниране на top-down и bottom-up. В единия случай сглобавяха дребни логчески парчета в по-голяма програма или алгоритъм (C → Функ.). В другия случай им показвах готовия резултат и седнахме да мислим как най-общо искаме да работи и попълвахме дупките с някаква позната или непозната имплементация (Функ. → C). Така разбраха някакви основни идеи на абстракцията без да отиваме твърде далеч от машината и от имплементацията.

Ако екстраполираме това до глобалното учене на програмиране трябва да можем да редуваме нивото на абстракция на материала използвайки изразните ни средства, били те императивен език от ниско ниво или функционален от високо ниво. Лошото е, че и в двата случая изразните ни средства са специализирани и да научим сложни абстракции в C или qsort в haskell е като да орем нива с тротинетка. Много зор и накрая всичко ще ни боли, а може и да не сме изорали.

Колкото повече мисля, толкова повече за първи език ми харесват езиците, които могат от всичко по малко. Хем дажем нещо императивно, хем да скрием нещо зад някоя абстракция, хем да имплементираме in-place врътката на qsort, хем да можем да върнем една фукнция без да ни се оплете мозъка във void-ове и звездички.

Ако не започнем да подготвяме от рано ученика за различните нива на абстракция ще стигнем до текущото положение, в което хората в тази група сме едни от малкото късметлии, които са успели да имат и достъп и да са положили усилието да си усучат мозъка и да разбират и от машинни езици, и от алгоритми, и от дизайн на големи програми.

 

[Slavomir Kaslev]

Наскоро си говорехме с главореза за има ли най-добър език, не само за програмиране, но и за математика. Моето мнение е, че това е въпрос без смисъл. Какво ако най-добрия език е визуален, геометричен, вместо (както сме свикнали за езици) символен, алгебричен?

2013/12/17 Nikolay Bachiyski <nbach...@gmail.com>

--

You received this message because you are subscribed to the Google Groups "Polyglot Quine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to polyglot-quin...@googlegroups.com.
To post to this group, send email to polyglo...@googlegroups.com.
Visit this group at http://groups.google.com/group/polyglot-quine.
For more options, visit https://groups.google.com/groups/opt_out.

--
Slavomir Kaslev

[Slavomir Kaslev]

David Hestenes беше казал "Algebra without geometry is blind, geometry without algebra is dumb.". Аз се замислям напоследък много за геометричен език за програмиране, на едновременно може да видиш алгебрата отдолу, докато "пишеш". Брет Виктор беше правил нещо подобно в една от презентациите си, но не докрай.

2013/12/17 Slavomir Kaslev <slavomi...@gmail.com>

--
Slavomir Kaslev

[Boyko Bantchev]

> Какво ако най-добрия език е визуален, геометричен, вместо (както сме
> свикнали за езици) символен, алгебричен?

Не съм сигурен какво се има предвид в случая, но във всеки случай да
отбележа, че класическата геометрия, ако се разбира като разсъждение
по чертеж, е ужасно слаба откъм вярност, точност и строгост и е силно
подвеждащ език. Затова съм скептичен за приложимостта ѝ в област като
програмирането, където тези свойства са от първостепенна важност.

Учебниците и др. текстове по елементарна геометрия са пълни с грешки.
Например теоремата на Чева е и формулирана, и „доказвана“ с груби
грешки почти навсякъде: като се почне от Уикипедия, мине се през
енциклопедията mathworld.com и се продължи с работите на безспорни
светила като Coxeter, Pedoe и Шарыгин.

[Iskren Chernev]

2013/12/17 Boyko Bantchev <boy...@gmail.com>:

> Учебниците и др. текстове по елементарна геометрия са пълни с грешки.
> Например теоремата на Чева е и формулирана, и „доказвана“ с груби
> грешки почти навсякъде: като се почне от Уикипедия, мине се през
> енциклопедията mathworld.com и се продължи с работите на безспорни
> светила като Coxeter, Pedoe и Шарыгин.

Стана ми интересно. Може ли малко по-подробно?

[Slavomir Kaslev]

2013/12/17 Boyko Bantchev <boy...@gmail.com>

> Какво ако най-добрия език е визуален, геометричен, вместо (както сме
> свикнали за езици) символен, алгебричен?

Не съм сигурен какво се има предвид в случая, но във всеки случай да
отбележа, че класическата геометрия, ако се разбира като разсъждение
по чертеж, е ужасно слаба откъм вярност, точност и строгост и е силно
подвеждащ език.  Затова съм скептичен за приложимостта ѝ в област като
програмирането, където тези свойства са от първостепенна важност.

Аз имам нещо много конкретно пред вид. Геометрията е синтетична, не класическа.

 

Учебниците и др. текстове по елементарна геометрия са пълни с грешки.
Например теоремата на Чева е и формулирана, и „доказвана“ с груби
грешки почти навсякъде: като се почне от Уикипедия, мине се през
енциклопедията mathworld.com и се продължи с работите на безспорни
светила като Coxeter, Pedoe и Шарыгин.

--
You received this message because you are subscribed to the Google Groups "Polyglot Quine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to polyglot-quin...@googlegroups.com.
To post to this group, send email to polyglo...@googlegroups.com.
Visit this group at http://groups.google.com/group/polyglot-quine.
For more options, visit https://groups.google.com/groups/opt_out.

--
Slavomir Kaslev

[Marin Petrov]

2013/12/17 Iskren Chernev <iskren....@gmail.com>

И аз щях да питам за същото.

 

--
M  a  r  i  n       P  e  t  r  o  v
_________________________
                 Character       T D
                 Blue  Sky  Studios
                 http://scroll-lock.eu

[cutthroat]

17 декември 2013, вторник, 22:59:17 UTC+1, Slavomir Kaslev написа:

Аз имам нещо много конкретно пред вид. Геометрията е синтетична, не класическа.

Ах, надушвам конспиратори-аксиоматизатори!

[Boyko Bantchev]

> Стана ми интересно. Може ли малко по-подробно?

Една типична грешка е в обратната посока на теоремата: че ако е
изпълнено равенството, то чевианите (правите през върховете на
∆-ка) се пресичат или са успоредни. Вместо това често се твърди,
че непременно се пресичат.

После, в доказването на тази обратна част тръгват от противното
така: нека пресечницата на чевианите през A и B е X; тогава правата
CX пресича AB в Y и т.н. Това са още две грешки: не е ясно дали
чевианите през A и B изобщо се пресичат, както и (ако X все пак
съществува) дали наистина CX пресича AB.

Освен това, често условието се формулира със знаменатели, примерно
(AC₁/C₁B)(BA₁/A₁C)(CB₁/B₁A)=1, но при това за чевианите се казва
само, че пресичат съответните страни – а трябва да се уточни, че не
минават през върховете.
(Всъщност те биха могли и да минават, но тогава трябва условието да
се запише примерно като AC₁·BA₁·CB₁ = C₁B·A₁C·B₁A и да се направят
още една-две уговорки.)

Да добавя и обикновено мътния начин, по който се уточнява, че
отношенията или отсечките са ориентирани, и какво именно значи
ориентацията. Това често даже не се и споменава, подразбирайки
само положителни стойности.

За споменатите геометри имам предвид книгите Introduction to geometry
(Coxeter, има превод и на български: „Вечната геометрия“), Geometry –
a comprehensive course (Pedoe) и една статия на Шарыгин от сп. Квант
(1976), посветена тъкмо на теоремите на Менелай и Чева.

[Boyko Bantchev]

Докато си говорим с какво е уместно да се започва обучението по
програмиране за деца, министерството предложи проект, в който
информатика (не само програмиране) изобщо няма да се учи в училище,
а т.нар. „информационни технологии“ (т.е. цъкане на майкрософт уърд
и ексел) ще има по 1 час седмично. Това е – ликвидиране на
информатиката в училище. Тя в повечето страни отдавна е ликвидирана,
явно искат същото и от нас. Изобщо е най-добре да ни няма, но каквито
останат, не бива да знаят много повече от това как да пазаруват.

Надявам се, че това все пак няма да мине, но натискът е налице и ще
продължи, и с постепенни намаления на часовете ще се стигне пак до
ликвидиране.

[Krasimir Angelov]

Ами да прост народ лесно се управлява. Не им трябва на децата да знаят много.

[Slavomir Kaslev]

2013/12/18 Boyko Bantchev <boy...@gmail.com>

Трагедия. В щатите нещата са наобратно http://www.youtube.com/watch?v=6XvmhE1J9PY

Искат всеки да може да пише или разбира код. Откъде идва натиска?  

 

--
You received this message because you are subscribed to the Google Groups "Polyglot Quine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to polyglot-quin...@googlegroups.com.
To post to this group, send email to polyglo...@googlegroups.com.
Visit this group at http://groups.google.com/group/polyglot-quine.
For more options, visit https://groups.google.com/groups/opt_out.

--
Slavomir Kaslev

[Hristo Deshev]

Здравейте,

> 2013/12/18 Boyko Bantchev <boy...@gmail.com <mailto:boy...@gmail.com>>

>
> Докато си говорим с какво е уместно да се започва обучението по
> програмиране за деца, министерството предложи проект, в който
> информатика (не само програмиране) изобщо няма да се учи в училище,
> а т.нар. „информационни технологии“ (т.е. цъкане на майкрософт уърд
> и ексел) ще има по 1 час седмично. Това е – ликвидиране на
> информатиката в училище. Тя в повечето страни отдавна е ликвидирана,
> явно искат същото и от нас. Изобщо е най-добре да ни няма, но каквито
> останат, не бива да знаят много повече от това как да пазаруват.

Това е и лоша и добра новина. Нашите деца ще разбират от информатика,
нали. Поне моите възнамерявам да ги науча на достатъчно програмиране, за
да бъдат опасни. :-)

> On 12/19/2013 08:58 AM, Slavomir Kaslev wrote:
> Трагедия. В щатите нещата са наобратно
> http://www.youtube.com/watch?v=6XvmhE1J9PY
> Искат всеки да може да пише или разбира код. Откъде идва натиска?

И в 'murica нещата не са розови. Ако на някой му се рови по темата,
знам, че има книга [1], която разказва историята за лошите образователни
реформи в щатите през последните 100+ години.

(слагам станиолената шапчица)

Тенденцията за цялостно скапване на образованието е световна. Не знам
дали е глобална конспирация на контрол на населението или е просто
лобистка схема за стимулиране на пазара на частните училища, които уж
гарантират по-добро образование. То няма и голямо значение щом
резултатите са едни и същи.

(свалям станиолената шапчица)

[1] http://deliberatedumbingdown.com

Поздрави,
Христо

[Boyko Bantchev]

Обама си приказва пожелателни приказки, но дали наистина тенденцията
в училищата е такава? Тук пише друго:
http://www.exploringcs.org/resources/cs-statistics .

В много т.нар. развити страни програмиране в училище не се учи или
е избираемо и не се търси особено. Доколкото изобщо се учи нещо
свързано с информатика, то са някакви силно размити ИКТ – общология,
а не програмиране. Ето един поглед върху нещата в Обединеното
Кралство:
http://royalsociety.org/education/policy/computing-in-schools/report

Упадъкът на образованието и в частност това по информатика е
отдавнашен и всъщност ние сме от последните засегнати. Сега, глупаво
приравнявайки програмите си с тези на „Европата“, наваксваме в темпа
и равнището на изоставане. Арнолд пише, че в Щатите поддържането на
ниско образователно равнище е целенасочена политика – нещо, което са
му казали самите американци. Нужни са потребители, а мислещите хора
трябва да са малко, елит. Същият процес явно върви не само там.

За да е ясно, че слушайки менторите си вървим надолу, погледнете ги
тях къде са. Някои от вас са участвали в олимпиади по информатика
и имат медали оттам. Те най-добре знаят, че повечето страни и в
частност _всички_ от Западна Европа _винаги_ са ни дишали праха в
това отношение. Разгледайте резултатите от Международната Олимпиада
по Информатика (световно първенство за ученици) тук:
http://ioi.snarknews.info
Избира се по години – гледайте разделите „Country results“ и „Results“.
Англичани, френци, немци и пр. никога не са могли да се мерят с нашите
и все още не могат.

[Marin Petrov]

2013/12/19 Boyko Bantchev <boy...@gmail.com>

Обама си приказва пожелателни приказки, но дали наистина тенденцията
в училищата е такава?  Тук пише друго:
  http://www.exploringcs.org/resources/cs-statistics .

Не само, че пише ами и съм се убедил в това. Тук децата учат големи глупости по принцип и родителите на българските деца се виждат в голям ужас и не искат да ги пращат на "училище".

Упадъкът на образованието и в частност това по информатика е
отдавнашен и всъщност ние сме от последните засегнати.  Сега, глупаво
приравнявайки програмите си с тези на „Европата“, наваксваме в темпа
и равнището на изоставане.  Арнолд пише, че в Щатите поддържането на
ниско образователно равнище е целенасочена политика – нещо, което са
му казали самите американци.  Нужни са потребители, а мислещите хора
трябва да са малко, елит.  Същият процес явно върви не само там.

Да, напълно съм съгласен и с това. Отдавна го наблюдавам. Дори откакто бях ученик ми правеше впечатление и с неудоволствие ходех на училище понякога , а после пък си прекъснах и университетското образование поради подобни причини.

Обучението е една от темите, които дълбоко ме вълнуват и са ме вълнували винаги. Моето мнение е, че формата на обучение, което училището предлага не е подходяща за съвременното общество. Може би е било подходящо в средновековието, но сега съвсем не е адекватно. В допълнение на това пък стандартите се налагат от хора , които нямат представа от обучение, но пък имат малко представа от икономика и брутен вътрешен продукт. Естествено може сами да си направим изводи каква е целта на подобно "обучение".

Интересно е, че един от първите въпроси на колегите ми от Корея след като разберат, че съм от България  е "Как така имате толкова добри програмисти?" На това може би вие може да отговорите. Аз нямам подобно обучение.

[Krasimir Angelov]

На 19 декември 2013 г., 22:14, Marin Petrov <petrov...@gmail.com> написа:
> Не само, че пише ами и съм се убедил в това. Тук децата учат големи глупости
> по принцип и родителите на българските деца се виждат в голям ужас и не
> искат да ги пращат на "училище".

Макар все още да нямам преки наблюдения от училищата съм чувал подобни
неща и за Швеция. Дори в университета съм останал с впечатлението, че
много от младите капацитети идват от Азия или поне от източна европа.
Например в моя екип сме осем души от които само двама шведи. Това ме
кара да се чудя какво е най-добре за едно дете. Да пратя дъщеря си
обратно в България ми се струва като наказание, а и скоро българското
образование също ще бъде тотално прецакано.

[Marin Petrov]

2013/12/20 Krasimir Angelov <kr.an...@gmail.com>

Макар все още да нямам преки наблюдения от училищата съм чувал подобни
неща и за Швеция. Дори в университета съм останал с впечатлението, че
много от младите капацитети идват от Азия или поне от източна европа.
Например в моя екип сме осем души от които само двама шведи. Това ме
кара да се чудя какво е най-добре за едно дете. Да пратя дъщеря си
обратно в България ми се струва като наказание, а и скоро българското
образование също ще бъде тотално прецакано.

Не, че имам деца все още , но съм в постоянна дилема за същото. Имам приятели българи, които пращат децата си на училище само за да може децата им да си играят, а пък ги обучават сами вкъщи. Не мисля, че това е решението също, но според тях е един от по-добрите варианти. Да ги пратиш обратно в България също не е решение. Аз гледам нещата малко от  по-анархo-либерална гледна точка и си мисля, че има вариант в който група хора с добри познания в различни области се събират и правят "комуна" , "група" за обучение като си обучават децата взаимно. Ако аз съм се занимавал цял живот с изкуство, а т и с информатика защо да не преподаваме на децата ни вместо да ги пращаме да учат подобни неща на мноооого по-ниско ниво ? Един ден аз ще им преподавам дизайн, друг ден ти ще им преподаваш информатика, приятел биолог ще им преподава биология и т.н. Общо взето "танто за танто". Да не говорим, че цената за обучение тук е ненормална и никога не бих платил толкова за нещо, което и сам мога да си науча. Аз съм много интровертен и асоциален обаче и не ми трябват външни хора. Когато става въпрос за деца обаче, те трябва да се насърчават да общуват с други деца според мен. Така, че просто да си обучаваш детето сам вкъщи не върви. Ще стане много асоциално според мен. Аз до скоро си мислех, че MOOC вариантите на обучение биха допринесли за прогреса в сферата на обучение, но според мен те не решават много проблеми, дори водят до още. Даже Себастиан Трун казва, че не работят: http://slate.me/192hD7S . Съжалявам, че разводних малко темата.

[Krasimir Angelov]

Ето нещо по темата от Dijkstra:

http://www.cs.utexas.edu/users/EWD/OtherDocs/To%20the%20Budget%20Council%20concerning%20Haskell.pdf

[Stefan Kanev]

On 08/01/14, Krasimir Angelov wrote:
> Ето нещо по темата от Dijkstra:
>
> http://www.cs.utexas.edu/users/EWD/OtherDocs/To%20the%20Budget%20Council%20concerning%20Haskell.pdf

Почти по темата. Все пак, г-н Д[еаи]йкстра допуска, че студентите имат
някакъв опит с императивни езици (the programming vehicle of their high
school days). Допълнително, говори за програмирането в университет,
което сериозно се различава от програмирането, на което искаш да научиш
някой с практическа (или recreational) цел.

С други думи, напълно съгласен съм, че Haskell е добър първи език за
университет, но продължавам да си мисля, че е изключително лош първи
език за нещо друго.

Уви, все още не съм убеден кой е подходящия първи език, но колкото
повече си мисля, толкова по-склонен съм да кажа "PHP", ако учиш хората
на уеб. Думи, които не съм вярвал, че някога ще напиша :)

Благодаря за линка.

П.П.: Как точно е успял да генерира този "PDF" е отвъд мен.

[Krasimir Angelov]

На 8 януари 2014 г., 14:26, Stefan Kanev <stefan...@gmail.com> написа:
> Почти по темата. Все пак, г-н Д[еаи]йкстра допуска, че студентите имат
> някакъв опит с императивни езици (the programming vehicle of their high
> school days). Допълнително, говори за програмирането в университет,
> което сериозно се различава от програмирането, на което искаш да научиш
> някой с практическа (или recreational) цел.

Вярно!

[Boyko Bantchev]

> г-н Д[еаи]йкстра

Съвсем еднозначно Дейкстра – другите варианти са много откъснати от
действителността.

> Уви, все още не съм убеден кой е подходящия първи език, но колкото
> повече си мисля, толкова по-склонен съм да кажа "PHP", ако учиш хората
> на уеб. Думи, които не съм вярвал, че някога ще напиша :)

„Първи език“ е доста неопределено. Може да става дума за най-различни
възрасти, интереси на обучаваните и цели на обучението. Според това
вероятно и езиците ще бъдат различно пригодни.

Колкото до уеб и PHP в този контекст, нещата наистина са спорни. Дали
изобщо уебпрограмирането е подходяща област за начинаещи (от какъвто и
да е вид) в програмирането? А и каква методологична стойност има
конкретно езикът PHP за разбирането на това що е уебпрограмиране?
(Наблягам на думите „методологична“ и „разбиране“ – не става дума дали
PHP е практичен инструмент за пролетариите в одимените уебцехове по
сървърния бряг.)

> Как точно е успял да генерира този "PDF" е отвъд мен.

Защо в кавички и какво му е странното? Някой го е сканирал и готово.
Цялото писмено наследство на Дейкстра стои точно в такъв вид на
същия сайт, където е и горната записка.

Макар и изключителен информатик и програмист, Дейкстра никога не е
печатал на компютър. В ранните му години комповете не са и ставали за
това. Тогава той е пишел статии, записки, доклади и др. на пишеща
машина. После мина на ръкопис (много изящен) и ксерокс за размножаване.
Огромната част от работите му са точно такива. За разпространяване:
никаква ел. поща, само обикновена. Горната записка е от предпоследната
година от живота му и най-вероятно е натракана не от него, а от някоя
секретарка по ръкописна чернова.

[Stefan Kanev]

On 08/01/14, Boyko Bantchev wrote:
> > г-н Д[еаи]йкстра
>
> Съвсем еднозначно Дейкстра – другите варианти са много откъснати от
> действителността.

:)

> > Уви, все още не съм убеден кой е подходящия първи език, но колкото
> > повече си мисля, толкова по-склонен съм да кажа "PHP", ако учиш хората
> > на уеб. Думи, които не съм вярвал, че някога ще напиша :)
>
> „Първи език“ е доста неопределено. Може да става дума за най-различни
> възрасти, интереси на обучаваните и цели на обучението. Според това
> вероятно и езиците ще бъдат различно пригодни.
>
> Колкото до уеб и PHP в този контекст, нещата наистина са спорни. Дали
> изобщо уебпрограмирането е подходяща област за начинаещи (от какъвто и
> да е вид) в програмирането? А и каква методологична стойност има
> конкретно езикът PHP за разбирането на това що е уебпрограмиране?
> (Наблягам на думите „методологична“ и „разбиране“ – не става дума дали
> PHP е практичен инструмент за пролетариите в одимените уебцехове по
> сървърния бряг.)

С радост ще обясня какво имам предвид.

Първо, не визирам въобще, че намирането на работа е фактор. Всъщност,
ще се радвам хората да престанат да пишат на PHP и никой да не може да
си намери работа на него (макар че това би обезмислило някои неща
по-долу).

Забелязал съм, че две неща са доста важни, когато учиш (или поне аз уча)
нови неща. Първото е приложимост. Много по-ефективно уча неща, които
мога да приложа веднага (например поредната JavaScript библиотека),
отклкото неща, които трудно мога да приложа (например глава 2 от
Concrete Mathematics - суми). Причината вероятно е психологическа и не
ми се дълбае там. Второто е, че колкото по-малко нива на абстракция има
и колкото повече контекст ми трябва, толкова по-трудно е да науча нещо.
Например, в Scheme една функция е (define (twice a) (+ a a)), което е
лесно смилаемо, докато в Java е статичен метод в клас, което е по-трудно
смилаемо, ако не знаеш какво е клас (или статичен метод).

След това, много хора тръгват към програмирането от уеб. Това е
нормално, тъй като "живеят" в уеба и искам да могат да правят някакви
неща в него (я да споделят нещо с приятели, я да си направят малък
инструмен, я да си пипнат блога). Често преди да стигнат до това имат
някакви познания по "front-end" - HTML, малко CSS - но не и от
"лепилото", което свързва тези неща (езика, който ги генерира).

В това отношение, PHP е страхотен по ред причини. Първо, огромната част
от PHP програмистите са точно такива (хора с нула предишен опит и
основно уебаджии) - в community-то има много ресурси, които таргетират
точно такива истории. Документацията на PHP е като за идиоти,
коментарите там покриват един тон особености, които за по-опитните са
очевидни и прочее. Също така, нивото на абстракция е нулево. В
повечето аналогични езици (Python, Ruby, Perl) ще ти трябва или да
понаучиш нещо за CGI или да ползваш framework (в днешно време библиотеки
като Sinatra улесняват така, но пак го има тоя момент). В PHP просто
добавяш "динамичната" част от страницата с PHP код и си в играта. Също,
deployment-а е много лесен - можеш да хвърлиш нещо на shared hosting с
лекота.

Ако вкараш една база данни също става забавно. Ще се научиш да си
правиш заявките сам и ще понаучиш СУБД-та, докато в аналогичния
Ruby/Python случай несъмнено ще се набиеш в някакъв framework, в който
ще има абстракция, която ще скрива (лошо) неща, които не трябва да бъдат
скрити преди да си ги разбрал добре.

Тези два фактора - (1) лесно се постигат практически резултати и (2)
екосистемата е доста проста за схващане - ми се струват изключително
критични в процеса на учене.

Разбира се, PHP има тон проблеми, но дори това може да бъде завъртяно
като позитив - ще можеш да оцениш абстракции като класове, анонимни
функции и типове системи по-добре, след като си се борил с твой код, в
който те биха могли да бъдат полезни.

Това са впечатления, които съм натрупал покрай RailsGirls тази година.
Може би не става ясно, но предполагам известна степен на самоубочение,
както и известно познанство на уеб, преди да се хвърлиш там. Мога да го
дефинирам по-ясно, но съм заобиколен от хора, които попадат в тази
категория. За тях бих препоръчал PHP без да се замисля.

Как да ги науча да "кодят адекватно", след като съм ги научил да "правят
неща" е въпрос, който бих решил по-късно.

По никакъв начин не предполагам, че PHP трябва да се учи в университет,
още повече като въведение в програмирането. Езика е откровенно ужасен и
трябва да умре. Но в момента има разни "soft" фактори от екосистемата,
които много помагат.

Също, смятам че възможността да създаваш практически използваеми неща
възможно най-скоро е изключително силен инструмент когато учиш нещо.

Това са ми размислите по темата.

> > Как точно е успял да генерира този "PDF" е отвъд мен.
>
> Защо в кавички и какво му е странното? Някой го е сканирал и готово.
> Цялото писмено наследство на Дейкстра стои точно в такъв вид на
> същия сайт, където е и горната записка.
>
> Макар и изключителен информатик и програмист, Дейкстра никога не е
> печатал на компютър. В ранните му години комповете не са и ставали за
> това. Тогава той е пишел статии, записки, доклади и др. на пишеща
> машина. После мина на ръкопис (много изящен) и ксерокс за размножаване.
> Огромната част от работите му са точно такива. За разпространяване:
> никаква ел. поща, само обикновена. Горната записка е от предпоследната
> година от живота му и най-вероятно е натракана не от него, а от някоя
> секретарка по ръкописна чернова.

О, това не го знаех. Полезна trivia, благодаря.

--
Stefan Kanev ¦ @skanev ¦ http://skanev.com/
In computing, invariants are ephemeral.

[Boyko Bantchev]

Още едно мнение по темата.

„Обучението по програмиране не е в духа на съвременното образование.
Нима е забавно да съставяш планове, да дисциплинираш мисленето си,
да обръщаш внимание на подробностите и да се учиш на самокритичност?“
– Алън Пърлис, преди няколко десетки години