О языках программирования для обучения

[arseniiv]

Munin в сообщении #1290961 писал(а):

Про минусы хотелось бы знать заранее.

Я не знаю, но языка без минусов пока не изобрели. Особенно более-менее наколенного — пусть меня извинят, но языки, разрабатываемые специально для того, чтобы можно было писать код уровня продакшена, проверяются (сам дизайн языка и модулей и весь софт) намного тщательнее, там и ресурсов для этого обычно побольше (заинтересованность, размер команды и число предоставляющих патчи, если проект опенсорсный, и т. д.), а здесь этой цели явно нет (ну или ладно, не явно нет, а не очень есть). Стоит ожидать гейзенбагов со странными описаниями. (А в школе это могло бы смотреться умопомрачительно, но ученики, наверно, к этому моменту уже привыкли к состоянию дел.)

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

Munin в сообщении #1290961 писал(а):

Нет, меня пугают другие проблемы:
- большой и сложный для начального освоения framework, для совершения простейших вещей;
- большая и сложная, ориентированная на профессионалов, а не на обучающихся, документация.

Так его собственный функционал и документация вам поначалу никак не понадобятся, для этого хватит того, что реализовано средствами самого языка (конечно, компилируется оно, как я понимаю, в MSIL, но вряд ли вы собираетесь дизассемблировать).

Munin в сообщении #1290961 писал(а):

Сам факт, что перед тем, как садиться и писать, надо подумать.

Ну, я сравнивал не с совершенным отсутствием описаний, а с описаниями ближе к месту использования. Это тоже думать, притом, возможно, даже чуть больше — где слишком рано объявлять, где поздно.

Munin в сообщении #1290961 писал(а):

А это что?

Ну, это от batteries included, т. е. стандартных библиотек поставляется достаточно, чтобы делать кучу распространённых вещей, не обращаясь в репозиторий и не пиша своих велосипедов. Python так традиционно рекламируют, но это касается многих языков. Вот сам .NET — весьма такая батарея батареек. Хотя смотря какая версия, старые иногда неприятно удивляют.

Munin в сообщении #1290961 писал(а):

Про форматирование текста: хорошо бы обучающийся сам этому учился.

На наших средних уроках информатики о форматировании вообще не говорилось. А раз такое бывает, надо застраховаться в аргументации.

Munin в сообщении #1290961 писал(а):

(При обучении в классе, можно заставить разбираться в коде другого ученика :​-)

Ого, а после уроков будет свалка. (А вообще я не против.)

[gevaraweb]

arseniiv в сообщении #1290948 писал(а):

Есть языки, компилирующиеся в JS. Не обязательно есть кактус необработанным.

На Js вполне можно кодить. Школьнику изучать другой новый язык, чтобы компилировать его на Js, нет никакого смысла. Проще сразу изучить Js.

И ветер в обратную сторону куда сильнее. Есть серверный Js, развиваются среды, где можно создавать на этом языке (или точнее расширения Js ) мобильные и десктопные приложения.

[arseniiv]

Кстати, мне дали добро на форсинг хаскеля в теме.

Хаскель
• краткий;
• функциональный (pun intended);
• типизация статическая, но типы часто можно опускать почти везде;
• у него есть подмножество специально для детей (правда, не помню, не застряло ли там всё какое-то время назад; вы этого не читали);
• не имеет проблемы некоторых многословных языков со статическими методами вместо функций;
• имеет или не имеет отступозависимость и точки с запятой по желанию пишущего;
• отступозависимость учит аккуратному оформлению;
• вопреки некоторым мнениям, позволяет не очень сложно написать чистую функцию, модифицирующую какой-нибудь там массив императивно;
• имеет недорефакторенные числовые классы (ой, это минус, ну и ладно, он всего один), но позволяет переделать по-своему (!), и есть пара модулей с переразложением;
• инстансы и типоклассы на самом деле понятнее ООП;
• ещё 999+ плюсов (как в тетрисе).

(Оффтоп)

По крайней мере, я не скрываю, что это не целиком серьёзно.

-- Чт фев 08, 2018 01:30:50 --

gevaraweb в сообщении #1290970 писал(а):

На Js вполне можно кодить.

Вы ещё скажите, что он Тьюринг-полный. Да, конечно, можно, когда больше не на чем, я так в древние времена писал на VB6. Но когда есть, например, язык со статической типизацией, близкий к JS и компилирующийся в JS, почему не попробовать? (Попробовать предлагать для начала обучению программированию вместо JS.)

gevaraweb в сообщении #1290970 писал(а):

Школьнику изучать другой новый язык, чтобы компилировать его на Js, нет никакого смысла.

Так он и не увидит JS, если всё правильно организовать. В этом случае JS рассматривается как машинный язык.

gevaraweb в сообщении #1290970 писал(а):

И ветер в обратную сторону куда сильнее. Есть серверный Js, развиваются среды, где можно создавать на этом языке (или точнее расширения Js ) мобильные и десктопные приложения.

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

[Munin]

arseniiv в сообщении #1290979 писал(а):

Хаскель...
• функциональный (pun intended);

Это скорее минус. Не стоит учить клингонский как first second language.

arseniiv в сообщении #1290979 писал(а):

Хаскель...
• ...типы часто можно опускать почти везде;

Это тоже минус при обучении.

----------------

arseniiv в сообщении #1290966 писал(а):

Ну, это от batteries included... Python так традиционно рекламируют...

А, так вот почему на batteries java - гугель вернулся с тиной морской...

[Pphantom]

mustitz в сообщении #1290821 писал(а):

Лично я бы с удовольствием рассмотрел бы для обучения язык Ada, читай более строгий Pascal плюс сопрограммы, плюс пре-пост условия, плюс доказательство корректности. Стандарт Ada 2012 как по мне очень удачный.

Это было бы замечательно, но, к сожалению, очень высок стартовый уровень. Ученики разочаруются и разбегутся раньше, чем смогут написать первую программу.

[arseniiv]

Munin в сообщении #1290987 писал(а):

Это скорее минус. Не стоит учить клингонский как first second language.

А вы не думали, что репутация функциональных языков не очень соответствует действительности?

Кстати, сдаюсь, зачёркиваем хаскель и пишем Idris. Там лень и коданные маркируются особо, а ещё там зависимые типы — и можно доказывать корректность своих программ!

Munin в сообщении #1290987 писал(а):

Это тоже минус при обучении.

Можно не значит обязательно. Если учителю надо, чтобы типы были везде, он может следить за этим сам. И если хитрый ученик выведет типы компилятором и после этого впишет, то это тоже скажет о его уровне: или там хоть где-то получится бред (а ещё типы могут не сойтись всё равно, и это вполне вероятно даже без аннотаций), и можно будет спросить его, что он означает, и получить результат, или там будет всё прекрасно, и, опять же, можно спросить, почему там такой, а не иной тип, и удостовериться в том, что это понимается.

-- Чт фев 08, 2018 02:00:46 --

А ещё вот есть язык Nim. Паскаль оказал на него как раз значительное влияние, если присмотреться.

-- Чт фев 08, 2018 02:03:30 --

Кстати, почему Lua тоже не рассматривается? Вот тут уж язык для обучения восхитительный, минимальный вместе с библиотекой и притом со вполне современными средствами.

[Munin]

arseniiv в сообщении #1290995 писал(а):

А вы не думали, что репутация функциональных языков не очень соответствует действительности?

Я думаю, что соответствующие навыки не подходят на роль first acquired для обучающихся с нуля. Вообще же знакомство с функциональной парадигмой сегодня, пожалуй, must have, но не как первое. Пролог я бы тоже не предлагал как первый язык.

[arseniiv]

Munin в сообщении #1291004 писал(а):

Я думаю, что соответствующие навыки не подходят на роль first acquired для обучающихся с нуля.

А можно для статистики, насколько вы знакомы с каким-то из традиционных ML-подобных (т. е. никаких лиспов) функциональных языков?

Munin в сообщении #1291004 писал(а):

Пролог я бы тоже не предлагал как первый язык.

А вот тут я сильно предвзято даже не просто соглашусь, а даже буду ругать прологи (в основном, неконструктивно) все сразу.

[rockclimber]

arseniiv в сообщении #1290979 писал(а):

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

Javascript вообще на картинки богат - post1201153.html#p1201153. А кому мало картинок, тот обязательно получит удовольствие от того, что январь - это месяц номер ноль

[gevaraweb]

arseniiv в сообщении #1290979 писал(а):

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

Ну минусы есть, не спорю. Как-то в тупик меня ввел код на жс, который вытворял невесть что (

Используется синтаксис Javascript

<script>
var h = 0.1;
for ( var i = 0; i <= 1; i += h ) {
        document.write( i );
        document.write( "</br>" );
}
</script>

Тут я даже не знаю грамотного решения проблемы. Для ЧМ такое поведение языка очень некстати.

[B@R5uk]

arseniiv в сообщении #1290915 писал(а):

Вот строгое разделение на «место для переменных», «место для операторов» и т. д. — это часто хуже, чем объявление переменных прямо перед местом, где они непосредственно пригодятся (а когда блоки вложенные, удобство только добавляется).

Позволю себе не согласиться. Не знаю, когда это у меня пошло, но у меня есть практика стараться делать объявление переменных в начале каждой процедуры (наверное, всё-таки со школы — когда на Паскале программировал). Всякие аргументы типа "до переменных в большой программе не добраться, если они не на месте" — весьма сомнительны, так как в таких случаях очевидно, что текст программы разросся чрезмерно, и её надо бы прорезать на функции/классы/отдельные файлы (особенно это касается профессионального программирования). В то время как при описанной практике смотришь на заголовочную часть — и сразу становится понятно, какие у процедуры входные параметры и какие вспомогательные переменные.

[Xaositect]

B@R5uk в сообщении #1291173 писал(а):

Позволю себе не согласиться. Не знаю, когда это у меня пошло, но у меня есть практика стараться делать объявление переменных в начале каждой процедуры (наверное, всё-таки со школы — когда на Паскале программировал). Всякие аргументы типа "до переменных в большой программе не добраться, если они не на месте" — весьма сомнительны, так как в таких случаях очевидно, что текст программы разросся чрезмерно и её надо бы прорезать на функции/классы/отдельные файлы.

Основная проблема с этим состоит в том, что не всякий логически обособленный блок стоит оформлять в виде процедуры. Самый яркий пример - это счетчик цикла, который очень часто имеет смысл только внутри цикла, и объявление его на всю процедуру, а не на цикл, бессмысленно.

[B@R5uk]

Xaositect в сообщении #1291176 писал(а):

Самый яркий пример - это счетчик цикла

С этим согласен, иногда бывает желание определить его прямо в теле цикла. Я даже так и делаю. Иногда (когда других переменных в теле процедуры не объявляется). Потому что с другой стороны, я обзываю все счётчики циклов одной буквой, а остальные переменные — осмысленным именем (типа "iterationCounter"). Поэтому, если у меня несколько циклов, я смотрю на заголовок и вижу не только сам факт их наличия, но и глубину их вложенности по количеству переменных с именем в одну букву. Но это уже исключительно личные предпочтения.

И да, если в программе идёт подряд два и более циклов, то писать
for (int n = 0; size > n; ++n) {
вместо
for (n = 0; size > n; ++n) {
как-то лениво. Не то, чтобы нельзя было бы скопипастить, но как-то в глазах рябит от явно лишнего набора символов в тексте. Плюс перфекционизм подсказывает очевидную оптимизацию размера исходного кода.

[B@R5uk]

Я тут подумал и, кажется, понял, откуда у этого подхода с объявлением перед использованием ноги растут. Люди часто считают (неосознанно?) что определить = инициализировать. И во многих языках высокого уровня это действительно так (в которых нет явного объявления). Я не в коем случае не стану спорить, что инициализацию переменных необходимо делать непосредственно перед использованием, но смысловая нагрузка объявления и инициализации, на мой взгляд, разная.

[arseniiv]

B@R5uk в сообщении #1291181 писал(а):

Плюс перфекционизм подсказывает очевидную оптимизацию размера исходного кода.

Аяяй, это плохой критерий. Код не должен быть коротким безусловно.

B@R5uk в сообщении #1291217 писал(а):

Я тут подумал и, кажется, понял, откуда у этого подхода с объявлением перед использованием ноги растут. Люди часто считают (неосознанно?) что определить = инициализировать.

Не обязательно. Важно, что хороший язык не позволит использовать в блоке имя, объявленное не раньше, а позже места использования. Важно, что надо с меньшей вероятностью крутить код вверх (даже если процедура и маленькая, она может оказаться частично выше верха отображаемой области), чтобы вспомнить, чьё это имя и какой имеет тип и прочее. Важно, что дифф при изменениях в таком случае будет более вероятно сосредоточен в меньшем числе мест. И ещё я наверняка не всё вспомнил.