?

Log in

No account? Create an account

Previous Entry | Next Entry

ushastyi пишет:
…популярность и быстрый рост Джавы во многом обусловлена ее социальностью — легко научиться что-то программировать. В сравнении с внешне похожим, но куда более сложным С++, в умелых руках способным творить чудесные программы и системы.

Социальность не всегда значит хорошо. Если меня спрашивают, а такое порой случается, то в качестве языков для обучения студентов я всегда рекомендую именно асоциальные языки. Их сложность и строгость гарантируют, что человеку придется напрягать мозги и разбираться, а это безвозвратно, к счастью, не проходит. Впоследствии другие языки покажутся простыми.
Три раза дададада!!! Учеба, кстати, в отличие от работы (и научной, и инженерной), есть процесс индивидуальный, или, в этих терминах, асоциальный. Если вам предстоит обучаться вычислительной математике, учитесь программированию на функциональном, асоциальном языке. Второй язык уже может быть любым.

Tags:

Comments

fregimus
Dec. 16th, 2011 08:14 am (UTC)
Боже упаси!
_aristeo
Dec. 16th, 2011 08:16 am (UTC)
Почему же?
fregimus
Dec. 16th, 2011 08:19 am (UTC)
На самом деле просто потому, что я так считаю. Не думаю, что я смогу найти логические аргументы, способные убедить в том, о чем я говорю. Исключительно опыт.
thedeemon
Dec. 16th, 2011 04:15 pm (UTC)
Практика школьная и университетская говорит, что нормально вполне. Хотя сам язык плохому учит местами.
taras_
Dec. 16th, 2011 05:13 pm (UTC)
А можно несколько примеров "плохого". А то я как раз студентов на Паскале учу. Хотелось бы просветиться.
thedeemon
Dec. 16th, 2011 05:45 pm (UTC)
Из того, что сразу всплывает в памяти:
1. Описание переменных в отдельном разделе до кода функции/программы. В гайдлайнах к другим языкам сейчас обычно рекомендуют минимизировать расстояние между описанием переменной и ее использованием, так меньше ошибок и оптимальней код. Плюс рекомендуют не использовать переменные повторно без нужды, так опять же меньше ошибок. Паскалевский же подход подталкивает к переиспользованию переменных.
Конечно, если разбивать код на множество мелких процедурок, это не очень актуально, но такую культуру еще надо освоить и не лениться применять, что для школьников/студентов нетипично.

2. Явное разделение на процедуры и функции. Это лишняя сущность, бесполезное синтаксическое излишество.
taras_
Dec. 16th, 2011 05:56 pm (UTC)
Спасибо. По 1-му пункту - осознал, просветился ))

2-е, по-моему, не так важно. Тем более, что все равно надо делать выбор - передавать результат как значение или писать в параметры, переданные по ссылке.

Если еще что-нибудь вспомните, буду благодарен.
pphantom
Dec. 17th, 2011 10:13 am (UTC)
Первое утверждение весьма спорно. Объявление переменных "на ходу", возможно, и способствует уменьшению числа ошибок при неаккуратном написании программы, но совершенно точно делает код менее оптимальным. Динамическое выделение/чистка памяти мелкими порциями - это очень дорого. О повторном использовании переменных сейчас редко вспоминают - памяти обычно достаточно много, чтобы в большинстве случаев это не было проблемой.

По поводу разделения на процедуры и функции - возможно, но это в самом худшем случае именно излишество. Т.е. нечто, чем можно не пользоваться, если не хочется.
thedeemon
Dec. 17th, 2011 10:36 am (UTC)
>совершенно точно делает код менее оптимальным.

Как же это? Они ж на стеке, и "выделение/освобождение" происходит у компилятора в голове - переназначением смещений стека именам. Для самой программы это вообще бесплатно. Разве что в некоторых экзотических реализациях, вроде SML/NJ, где фреймы в куче выделяются, там да, чем больше фреймов, тем медленнее.

Повторное использование переменных может легко получаться, если есть несколько циклов или простых операций, для которых естественно иметь переменные с простыми именами. Захотел цикл по i, а она уже в этой процедуре использовалась выше. Делать i2? Фактически, речь об экономии не машинной памяти, а человеческой.

Разделение на процедуры и функции плохо само по себе тем, что создает у новичка представление, будто это концептуально разные вещи. А это уже "плохому учить".
pphantom
Dec. 17th, 2011 10:54 am (UTC)
Если объем небольшой, то тогда это действительно стек (в большинстве реализаций). Но точно тот же самый результат получится и в том случае, если переменная будет объявлена где-то в начале функции/процедуры. Т.е. в этом случае разница просто отсутствует.

Повторное использование счетчиков цикла - да. Но эта особенность именно в таком виде именно в Паскале и сохранилась. В большинстве более современных языков, в которых описание переменных отделено от собственно кода, есть дополнительные средства выхода из этой ситуации.

А вот разделение на процедуры и функции часто оказывается удобным. Это "одно и то же" в первую очередь с точки зрения машинной реализации (а также языков-потомков C, по той же самой причине), но не во всех случаях без исключения.
thedeemon
Dec. 17th, 2011 03:40 pm (UTC)
Как же разница отсутствует. Вот есть у нас функция, внутри которой три цикла один после другого. Внутри циклов используются свои переменные. В паскале мы должны описать их отдельно и они займут каждая свою память. А в Си-подобных языках переменные будут описаны внутри циклов, при выходе из одного цикла его переменные "перестанут существовать" и переменные следующего будут размещены физически на их месте. Памяти будет потрачено меньше, регистров распределять надо будет на меньшее число переменных, и кэш сработает лучше, все это ведет к лучшей производительности.

Процедуры и функции - одно и то же не столько с т.з. реализации, сколько в теории типов. Недаром в функциональных языках есть тип unit и его значение (). Функция из целого в целое имеет тип Int -> Int, целочисленная функция "без аргументов" имеет тип unit -> Int, процедура с целым аргументом - unit -> Int, процедура без аргументов - unit -> unit. Всякая функция что-то принимает и что-то возвращает, процедура отличается лишь типом возвращаемого значения.
(no subject) - thedeemon - Dec. 17th, 2011 03:43 pm (UTC) - Expand
(no subject) - pphantom - Dec. 17th, 2011 04:19 pm (UTC) - Expand
(no subject) - thedeemon - Dec. 17th, 2011 04:43 pm (UTC) - Expand
(no subject) - pphantom - Dec. 17th, 2011 05:08 pm (UTC) - Expand
fregimus
Dec. 17th, 2011 11:39 am (UTC)
Нет, это утверждение неверно в корне. В функциональных языках вовсе нет переменных, есть связывание имен, и имя декларируется в момент связывания. Это отнюдь не означает, что функциональные языки принципиально менее эффективно реализуются на современной архитектуре.

Да и выделение памяти малыми кусочками (хотя в большинстве случаев компиляторы действительно используют стек) — самая оптимальная стратегия в системах со сборкой мусора с поколениями.
pphantom
Dec. 17th, 2011 11:43 am (UTC)
Возможно, и не означает, но хотелось бы увидеть конкретную реализацию - не менее эффективную. :)

Да - для систем со сборкой мусора. Только сам по себе GC - штука, достаточно сильно снижающая эффективность кода.
(no subject) - fregimus - Dec. 18th, 2011 05:45 am (UTC) - Expand
(no subject) - pphantom - Dec. 18th, 2011 10:58 am (UTC) - Expand
fregimus
Dec. 17th, 2011 11:47 am (UTC)
Тут вот в чем неприятность. Когда человека учат программированию, конкретный язык создает некоторые понятия — верные и неверные — которые впоследствии непроизвольно распространяются на любое программирование вообще. Мне кажется, что любой процедурный язык привносит такой багаж концепций, от которого потом трудно избавиться. Функциональные языки в этом смысле проще, ближе к математике. Из того, что я видел, у меня складывается уверенность, что обучавшийся на ФЯ может писать с легкостью на процедурных языках, а вот обратная дорога дается невероятными усилиями по выворачиванию мозгов в правильном направлении. Первый язык все-таки должен быть функциональным.
thedeemon
Dec. 17th, 2011 03:29 pm (UTC)
Паскаль он ведь по уровню и устройству примерно как Си с другим синтаксисом, с ними человек учится, что есть выделение памяти, и как устроены в памяти всякие списки и деревья, изучает классические алгоритмы. Это очень полезное знание и понимание. А ФЯ эти низкоуровневые вещи обычно скрывают, и иные классические алгоритмы на них и вовсе не ложатся без извращений. Я не знаю, хорошо ли изучать такие высокоуровневые языки, не изучив более низкоуровневых. Мне кажется, изучая язык, полезно представлять во что именно он транслируется, как именно работает. Я вижу, что тысячи людей начинали с паскаля в школах и институтах, и потом те, кому было интересно, успешно осваивали и ФЯ. А обратных примеров я не видел еще, просто негде было увидеть.