Убей луче систему "образования" у которой несмотря на медленное, но верное приближение второй половины 21го века, в учебных планах курсов программирования _в_лучем_случае_ трупопасцаль под дос :(. Под лисп всехнахЪ, инше хаскель какой-нибудь! В хаскеле есь гото?
Паскакаль на самом деле хороший язык для _обучения_ программированию (я тоже с него начинал), хоть сейчас его и полностью забыл (вовремя свалил на си). Хотя лучше было б начинать с Modula-2 ;)
А можно было б и хаскель... думаю в те времена он был бы мне понятнее...
Анекдот такой был.
Препод говорит студенту, что, мол, у тебя за имена переменных в программе - N1, N2, N3... Имена должны быть длинные, мнемонические!
На следующем занятии студент показывает программу:
ДЛИННЫЙ_МНЕМОНИЧЕСКИЙ_ИДЕНТИФИКАТОР_НОМЕР_1 = 0;
ДЛИННЫЙ_МНЕМОНИЧЕСКИЙ_ИДЕНТИФИКАТОР_НОМЕР_2 = 0;
ДЛИННЫЙ_МНЕМОНИЧЕСКИЙ_ИДЕНТИФИКАТОР_НОМЕР_3 = 0;
Это зачёт! Я вот не могу понять, почему у нас почти не один препод не заставляет студентов выбирать нормальные названия переменных. Вместо этого говорят, чтоб комментарии писали что-чё значит. ууу нинавижу...
Хотя я конечно предпологаю почему у них нет волшебной кнопочки M-/
> Вместо этого говорят, чтоб комментарии писали что-чё значит.
ну мне, допустим, так удобней некоторые методы реализовывать... Т.е. ты в мат. модели используешь всякие m и n и иже с ним, и для униформности такие же имена юзаешь и в коде. + комменты, какая буква что обозначает, чтобы в случае утери мат. модели не пришлось бочку пива покупать "на разобрацца"...
Тогда уж и мат модель с вменяимыми именами составляй. Я стараюсь делать, так потомучто память дырявая, часто путаешь, где м где н, хотябы трёхбуквенные имена пытаюсь делать, если на бумажке пишу.
> Паскакаль на самом деле хороший язык для _обучения_ программированию
Паскаль самый ужастный язык для _обучения_ программированию: в нём введены лишние сущности, с целью упростить но на самом деле всё усложняющие. Например, работа с файлами. Везде open, а в нём почему-то assign, и затем всякие reset, append, и другое. Зачем язык должен громоздить такие большие формальные отличия в принципиально одинаковых действиях? Или замысловатое форматирование вывода типа write (x:5:2);. Я смогу сделать функцию, умеющую принимать параметры в такой форме средствами паскаля? Как? Как тогда объяснять обучаемым, как эта функция работает изнутри??? Презабавные правила, когда нужен ;, а когда мешает. Странно завуалированное различие в передаче параметра по ссылке и по значению. В трупопаскале ещё и полное игнорирование стандартного процесса линковки. Это, и многое другое, навязывает некоторые "догмы", которые сильно мешают обучению другим языкам и наречиям. Нет уж, следует отличать обучение системному и прикладному программированиям. Для одного луче с всёодно ништо нету, а для другого выбор велик весьма, и самый скверный - именно пасцаль.
по-моему, для обучения лучше схема в виде mit-scheme... Минимальный синтаксис и окружение заставят учеников выражать в коде свои мысли, а не заморачиваться на синтаксисе и окружении до поры до времени...
В принципе, для основ алгоритмизации ничего, кроме русского языка, и не надо. Будут алгоритмы шлепать на псевдокоде. А потом уже можно переходить к реализациям на конкретных языках программирования.
http://www.squeakland.org/ - вот так в принципе
и надо начинать учить..
Хорошая, простая, красивая вещь,
элементарно понятная для самых мелких детишек
и одновременно востребованная банками и биржами..
Плюс к этому - язык которому тихо завидует java.
Yes, this is it, the ROT-13 program I wrote in INTERCAL because I couldn't get my Pascal to compile on Unix and I didn't know C yet. It's been described on alt.folklore.computers as "4 pages of completely indecipherable code".
Все правильно, человек должен в первую очередь выражать алгоритм на
родном языке. Даже псевдокод не нужен. А кодить нужно учить отдельно,
задав четкие спецификации, оставив совсем немного для фантазии.
Это в корне неправильно. Составить алгоритм 1) луче и проще на языке, приспособленном для составления алгоритма 2) на машинном языке или наречии можно проверить, что оный алгритм работает как следует, ибо не достигшие просветления склонны называть алгоритмом запутанный и тёмный путь своих подобных клубку копошашихся червей мыслей, но компьютер подобно мечу карающему обрушит гнев на их нечестивые проги и судом неподкупным и беспристрастным отделит праведное от злого.
Если человек не может объяснить четко и ясно, как работает алгоритм, он
и не сможет написать нормальный код к нему. Кроме того, как правило
разработка ведется не в "одно рыло" и умение объяснить и документировать
алгоритм/код очень важно. Два зайца.
С другой стороны, если дать возможность необученному человеку сходу
писать код к своим алгоритмам, то он будет жертвовать красотой (и
эффективностью) кода ради того, чтобы выразить свои мысли на "неродном"
языке. Получится "лишь бы работало."
Это было бы правильно, если бы меж человечьим языком и языком программирование не было бы принципиальной разницы. На деле, любой язык наиболее чётко выражает некоторую предметную область, выразить которую на другом в принципе возможно, но весьма проблематично. Почитай например Ю. Цезаря в оригинале и обрати внимание, как в сравнительно простом и логичном латинском наречии выражается направление и стороны света. Також и тут: человек может именно объяснить, как работает алгоритм другому человеку, но без должного изучения языка программирования не в состоянии будет объяснить его же компу. Потому что объяснения суть разные.
> чтобы выразить свои мысли на "неродном" языке.
Такое возможно только в случае, если человек плохо понимает предметную область, охватываемую языком описания кода, а значит и языком программирования. А хороший для обучения язык программирования должен помочь освоиться с ней, но не заметать пыль под ковёр, подобно пасцалю.
>А почему уж тогда сразу не в двоичном коде на перфокартах?
Не стоит сравнивать лошадь с пони. Ассемблер язык машины => неограниченные (конечно ограниченные в полном понимании, но только возможностями конфигурации компьютера) возможности (думаю это не надо разжевывать).
А ты всё-таки ражжуй, что принципиально низя сделать на с, но можно на асм? Ну, кроме некоторого уменьшения размера бинарников _на_прстых_алгоритмах_ и намного большей вероятности появления жутких с превеликим трудом изловимых багов?
> А ты всё-таки ражжуй, что принципиально низя сделать на с, но можно на асм?
1) самомодифицирующийся код
2) вызов функции, принимающей параметры нестандартным образом (в регистрах например)
3) код бут-сектора
...да мало ли еще чего
> 1) самомодифицирующийся код
Лехко:
int a () {
return 2;
}
int b () {
return 3;
}
int main (int argc, char * argv []) {
int (* z) ();
z = a;
printf ("%i\n", z ());
z = b;
printf ("%i\n", z ());
return 0;
}
токмо ЗАЧЕМ???
> 2) вызов функции, принимающей параметры нестандартным образом
>(в регистрах например)
Лехко, есь библиотеки под разные платформы с функциями таковой
надобности и возможнось ассембленых вставок и даже
"расширения" для некоторых реализаций, которые нахъ ибо
ломают совместимось и кроссплатворменнось.
Посему фтопку таковые функции.
> 3) код бут-сектора
Причём тут вообще с или асм? open ("/dev/hda", O_LARGEFILE) итд итп.
Ты правда думаеш что всякое fdisk на асме писано???
> ...да мало ли еще чего
Ну видать мало, если ничё путного в пример не привёл.
> Лехко:
>
> int a () {
поскипано.
Мда... Ты не знаешь что такое самомодифицирующийся код.
> Лехко, есь библиотеки под разные платформы с функциями таковой
> надобности и возможнось ассембленых вставок и даже
^^^^^^^^^^^^^^^^^^^^^
вот ты говоришь "возможнось ассембленых". Т.е. ты согласен, что без ассемблера здесь никак? О чем тогла спор?
> Причём тут вообще с или асм? open ("/dev/hda", O_LARGEFILE) итд итп.
> Ты правда думаеш что всякое fdisk на асме писано???
Ты не понял. Я говорил про тот код, который лежит в бут-секторе. Которому BIOS передает управлние после POST.