Совсем недавно, кстати, рассказывая про алгоритм Краута разложения квадратной матрицы в произведение двух треугольных, столкнулся с недостатком языка Паскаль. Схема алгоритма там такая:
procedure UnsymDet (...; var fail: Boolean
( Read more... )
Ты, видимо, пропустил самый первый пост из этой серии: "Писать код ≠ программировать". Я учу не языку. А программы - это "алгоритмы + структуры данных", как писал классик. Коммерческие средства получают популярность по разным причинам, и их качество часто бывает не на первом месте. Поэтому я считаю, что начинать обучение на основе коммерческого языка - плохая идея. Поэтому четвертому Фортрану отдам дань только в исторической справке (хотя некоторым понадобится разбираться и в нем, но не на этапе школьного обучения, разумеется).
В те времена, когда Вирт придумывал Паскаль, основными коммерческими языками были как раз Фортран и Алгол-60, а так же очень специфический Кобол. И на них можно писать хорошие программы, но сначала хорошему программированию нужно научиться. Дейкстра в Нидерландах, Вирт в Швейцарии и, как ни странно, Ершов в СССР в разное время пришли к выводу, что коммерческие инструменты для обучения не годятся. А когда ты уже умеешь, освоить коммерческий язык труда не составит, но ты уже не вывалишь на нем несопровождаемое говно.
TP7.0 не подходит для обучения по той же причине, по которой раньше не подходил PL/1, а сейчас не подходит C++: он слишком сложен и непоследователен. Вместо составления алгоритмов и анализа их применимости и эффективности, вместо выбора подходящих структур для представления данных задачи ученик заучивает разнообразные средства языка. И находит, что это намного проще, чем составлять алгоритмы. Он выучивает язык и думает, что умеет программировать. В итоге получается кадр, который не может решить несложную производственную задачу (реальный пример у меня на работе в прошлом году), потому что "не нашел подходящий фреймворк" (что бы это ни значило), но отлично знает "Пайтон" и "Пи-Эйч-Пи Файв"!
Поэтому создание учебного языка Паскаль в том виде, как он был позже стандартизирован, - это правильно. Хотя, как я отметил, первый блин был не лишен недостатков, например, отсутствие оператора выхода из середины процедуры (есть и другие, позже частично исправленные). Но "лечение" этих недостатков заменой учебного языка на коммерческий, на мой взгляд, окажется хуже самой болезни.
Кстати, плохая пригодность учебного Паскаля к промышленному программированию не помешала Кернигану и Плоджеру написать на нем набор полезных утилит - "Software Tools in Pascal". Потому что они умели.
Ты, видимо, пропустил самый первый пост из этой серии: "Писать код ≠ программировать". Я учу не языку. А программы - это "алгоритмы + структуры данных", как писал классик. Коммерческие средства получают популярность по разным причинам, и их качество часто бывает не на первом месте. Поэтому я считаю, что начинать обучение на основе коммерческого языка - плохая идея. Поэтому четвертому Фортрану отдам дань только в исторической справке (хотя некоторым понадобится разбираться и в нем, но не на этапе школьного обучения, разумеется).
В те времена, когда Вирт придумывал Паскаль, основными коммерческими языками были как раз Фортран и Алгол-60, а так же очень специфический Кобол. И на них можно писать хорошие программы, но сначала хорошему программированию нужно научиться. Дейкстра в Нидерландах, Вирт в Швейцарии и, как ни странно, Ершов в СССР в разное время пришли к выводу, что коммерческие инструменты для обучения не годятся. А когда ты уже умеешь, освоить коммерческий язык труда не составит, но ты уже не вывалишь на нем несопровождаемое говно.
TP7.0 не подходит для обучения по той же причине, по которой раньше не подходил PL/1, а сейчас не подходит C++: он слишком сложен и непоследователен. Вместо составления алгоритмов и анализа их применимости и эффективности, вместо выбора подходящих структур для представления данных задачи ученик заучивает разнообразные средства языка. И находит, что это намного проще, чем составлять алгоритмы. Он выучивает язык и думает, что умеет программировать. В итоге получается кадр, который не может решить несложную производственную задачу (реальный пример у меня на работе в прошлом году), потому что "не нашел подходящий фреймворк" (что бы это ни значило), но отлично знает "Пайтон" и "Пи-Эйч-Пи Файв"!
Поэтому создание учебного языка Паскаль в том виде, как он был позже стандартизирован, - это правильно. Хотя, как я отметил, первый блин был не лишен недостатков, например, отсутствие оператора выхода из середины процедуры (есть и другие, позже частично исправленные). Но "лечение" этих недостатков заменой учебного языка на коммерческий, на мой взгляд, окажется хуже самой болезни.
Кстати, плохая пригодность учебного Паскаля к промышленному программированию не помешала Кернигану и Плоджеру написать на нем набор полезных утилит - "Software Tools in Pascal". Потому что они умели.
Reply
Leave a comment