Об обучении программированию [2]

[netch]

Начало было тут

Пока искал аргументы - набрёл на вот такое:

Ну что вы, за полгода, если есть желание и хоть какая-то предрасположенность к логике, можно стать неплохим кодировщиком. Я по э-почте обучил 300 человек, попадались очень талантливые.

Надо уточнить границы "хоть какой-то" предрасположенности, но результат сам по себе 1) практический, 2) высочайший.

UPD: Обсуждение резко ушло куда-то не туда, куда я ожидал:) Мне пофиг, насколько у него "дельфийский стиль" или какие у него знания просто о существовании Lisp, Haskell и многих других страшных слов.
Потому что процедурное программирование - не худшее направление:) И если человек реально умеет привлечь и обучить - это 1) само по себе полезно, 2) может быть перенесено и на другие направления, при адекватной адаптации методики.

Comments

[netch]

> Лисп - язык простейший.

Лисп сложнее Эрланга и, пожалуй, сравним с Хаскелем.

> Программист на дельфи за неделю в хаскеле программы писать не начнёт. Как не начнёт он их писать и в ерланге.

Я всё-таки не понимаю, почему такое предвзятое отношение к Delphi.
По крайней мере в случае Erlang, мне кажется, нормальный процедурный программист должен написать что-то простое, но уже работающее, максимум через три дня.

[murkt.livejournal.com]

> По крайней мере в случае Erlang, мне кажется, нормальный процедурный программист должен написать что-то простое, но уже работающее, максимум через три дня.
Претензия к цитате состояла не в том, что любой язык можно освоить за неделю-месяц, а в том, что базовые возможности всех языков на 90% одинаковы и записывается всё с небольшими отличиями.

[netch]

Ты в курсе назначения такого понятия, как "универсальное множество"?

[murkt.livejournal.com]

«Универсальное множество – совокупность всех мыслимых элементов какого-нибудь типа определяемого классом решаемых проблем.»

[netch]

Ну вот для него в данном случае в универсальном множестве нет языков кроме тех, что он сам явно назвал.

[filonov.livejournal.com]

Но это, к сожалению, характеризует его а не множества.

[p1r4nh4.livejournal.com]

> Лисп сложнее Эрланга и, пожалуй, сравним с Хаскелем.

Да ну? В лиспе можно писать в обычном императивном стиле, со всеми (setq a (+ 2 3)), в ерланге такое не прокатит. Потому если ты программировал на дельфи, стартануть на лиспе будет проще.

Лисп с хаскелем точно не сравним, там одни монады чего стоят. И клёвая система типов, которая после убогих int/char кажется чем-то невероятным. И т.д.

> По крайней мере в случае Erlang, мне кажется, нормальный процедурный программист должен написать что-то простое, но уже работающее, максимум через три дня.

Что это - что-то простое? Парсер логов? :-) Парсер логов, думаю, напишет с доками и такой-то матерью. Но сколько матов будет и какой будет код? :-)

[netch]

> Да ну? В лиспе можно писать в обычном императивном стиле, со всеми (setq a (+ 2 3)), в ерланге такое не прокатит. Потому если ты программировал на дельфи, стартануть на лиспе будет проще.

Неправда.

Process Dictionary
Each process has a local store called the "Process Dictionary". The following BIFs are used to manipulate the process dictionary:

    * get() returns the entire process dictionary.
    * get(Key) returns the item associated with Key (Key is any Erlang data structure), or, returns the special atom undefined if no value is associated with Key.
    * put(Key, Value) associate Value with Key. Returns the old value associated with Key, or, undefined if no such association exists.
    * erase() erases the entire process dictionary. Returns the entire process diction before it was erased.
    * erase(Key) erases the value associated with Key. Returns the old value associated with Key, or, undefined if no such association exists.
    * get_keys(Value) returns a list of all keys whose associated value is Value. 

Note that using the Process Dictionary:

    * Destroys referencial transparency
    * Makes debugging difficult
    * Survives Catch/Throw 

So:

    * Use with care
    * Do not over use - try the clean version first 

И точно так же, как это не разрешается в нормальном стиле - там же тебе не разрешат никакие setq.

> Лисп с хаскелем точно не сравним, там одни монады чего стоят. И клёвая система типов, которая после убогих int/char кажется чем-то невероятным. И т.д.

У Лиспа (в нормальной реализации) своих хитростей достаточно.

> Что это - что-то простое? Парсер логов? :-) Парсер логов, думаю, напишет с доками и такой-то матерью. Но сколько матов будет и какой будет код? :-)

Про парсер логов я не говорил. А вот простенький, например, сетевой демон по отдаче картинок - занефиг.

[p1r4nh4.livejournal.com]

> И точно так же, как это не разрешается в нормальном стиле - там же тебе не разрешат никакие setq.

Сорри, не понял. Ты в том смысле, что get/put есть? Но это не будет слишком понятно из туториала по ерлангу вообще, а по лиспу - другое дело. :-)

> У Лиспа (в нормальной реализации) своих хитростей достаточно.

Кто ж против? :-) Но у лиспа система типов - список, список, список. :-) А у хаскеля всё ж чуть иначе...

[netch]

> Ты в том смысле, что get/put есть? Но это не будет слишком понятно из туториала по ерлангу вообще, а по лиспу - другое дело. :-)

Это смотря какой туториал. Исторически, действительно, многие писались именно так.

> А у хаскеля всё ж чуть иначе...

Тогда речь надо вести не об общей сложности, а о пороге вхождения для написания некоторой типичной функциональности, большей чем hello world, но меньшей чем реальная большая программа.

[kouzdra.livejournal.com]

Там дело не в хитростях. Haskell - чистый ФЯ и там просто приходится ломать привычные абстракции. Все практически. В этом смысле лучше для переучивания ML - там хотя бы постепенно можно.

Собственно дело именно в этом, а не в "сложности языка". Lisp в этом смысле вполне себе императивный язык.

PS: При всей моей нелюбви к ООП - оно тоже от процедурных языков отличается именно тем, что совсем другой набор абстракций.