Нет. Я сам оболдел. Там даже не просто на английском было, а была ссылка на внешний сайт на английском.
Ладно, довольно офтопиков.
Я не предлагаю полностью отказаться от поддержки конструкций Турбо Паскаля – для школ и многих начальных курсов программирования (не с IT специализацией) его обычно вполне достаточно. Речь идет скорее о не самых удачных/ненужных (с точки зрения совместимости/идеологии .NET и современных языковых тенденций) нюансах реализации и синтаксиса диалекта Object Pascal, реализованного в TP/BP и Delfi.
ООП в обычных школах на информатике не проходят, насколько я знаю (на доп. занятиях или в спец. классах – дело другое). На ОГЭ/ЕГЭ также нет никакого ООП. Так зачем тянуть изо всех сил эту совместимость?
То же самое касается уже устаревших расширений и функциональности самого PABC.NET – нашли опытным путем более красивый/читабельный/удобный синтаксис – упрощайте компилятор, вырезайте старый в следующей мажорной версии. Только делайте это постепенно (ну, кроме может быть самых простейших и очевидных случаев, типа ситуаций с ;), дайте людям время на обкатку нового решения – скажем то, что в 3.5+ объявлено устаревшим/нерекомендуемым, в версии 4.x – уже ошибка. Причем в некоторых случаях (напр., как выше) синтаксис нужно не упрощать, а делать более строгим и единообразным – язык должен быть элегантным, но не запутанным! И при этом четко описанным.
З.Ы. Кстати, что касается именно Delfi – кто-нибудь может мне объяснить зачем до сих пор изучать в ВУЗах специфические особенности не, скажем, общедоступного Фри Паскаля/Лазаруса, а малораспространенного уже на практике и дорогого коммерческого продукта? В чем профит для студентов? В изучении латыни сейчас гораздо больше смысла.
2 лайка
Соглашусь. Из того, что изучается в учебных заведениях: консольный ввод-вывод. Он есть. Статические массивы, строки, простые типы - это всё есть. А что ещё? А ничего! Эту совместимость сломать - это ещё постараться надо. А вот вся остальная байда из Дельфи - в топку!
Никто их не отвлекает и не заставляет, им просто предлагают что-то новое время от времени. Хотя они сами выбирают чем именно заняться. Паттерны, тайп-классы и многие другие нетривиальные “модные” фишки они вводят в язык исключительно по собственной инициативе – чисто из академического интереса, частенько отдавая реализацию в руки своим подопечным: старшекурсникам или магистрантам.
Старый PABC не был неудачным и “умер” не от того, что в нем чего-то не хватало школам, а просто потому что он надоел самим разработчикам, его банально забросили, когда лично потеряли к нему интерес и увлеклись возможностями только-только появившейся тогда платформы .NET, бесплатно предлагавшей им доступ к огромному пласту новых возможностей и концепций для своих изысканий и экспериментов. А школы впоследствии просто механически переключились на новую среду, а не на новый синтаксис и модные плюшки (как и в случае с уходом от TP), т.е. это никак не изменило их программы обучения школьников.
Кстати, я особо не пользовался PABC, но покрутил его немного и, могу сказать, моё первое впечатление – он гораздо лучше документирован, стабилен и вылизан для применения в школах (в смысле качества самой среды). Новое же поколение, к сожалению, уже потеряло свой фокус начального обучения и развивается как-то сумбурно, торопясь вводить все новые специфические возможности (зачастую вообще формально не документируя их никак!) и оставляя при этом массу недоработок на потом.
Глеб, перестаньте уже называть Delphi “допотопным” и “мертворожденным”, он вполне себе развит, живет, поддерживается и развивается. Просто в силу разных обстоятельств (как внутренних, так и внешних, но только не слабости самого языка и RAD-среды!) его лучшие времена уже прошли и его былая популярность угасла – осталась только относительно небольшая коммерческая ниша (по сравнению с C#, Java и C++). Но мода приходит и уходит, и кто знает, может быть, если они изменят свою маркетинговую политику, они еще поймают свою волну ренессанса.
Турбо Паскаль тоже никогда не был “убогим” и “мертворожденным” – это был весьма продвинутый и суперпопулярный продукт для своего времени. Надо отдать ему должное, если бы не он – Паскаль вообще бы не дожил до нынешних времен ни в каком виде! Умер бы себе тихонько в 80-х, как Алгол и Модула…
То же самое касается и FP/Lazarus – они здравствуют и продолжают развиваться потихоньку, что даже удивительно с учетом их крайне ограниченных инженерных ресурсов и отсутствия поддержки со стороны крупных компаний. Есть еще активно развивающийся CodeTyphon Studio на их основе, со своими доработками и массой интегрированных сторонних компонентов, большинство из которых не только поддерживается, но и развивается дальше (а также время от времени появляются новые).
Причем все эти продукты – не учебно-экспериментальные, а промышленные и до сих пор реально используются в серьезных проектах и даже новых разработках.
3 лайка
@spectatorBH, спасибо за пост - он поднимает глубокие проблемы. То, что Вы пишете, частично соответствует действительности.
Мы начинали когда Turbo Pascal школьники уже отказывались использовать из-за синего экрана и глюков при работе под windows. А нам надо было на чем-то учить школьников.
FP тогда был очень нестабильным. Среда FP у меня до сих пор беспричинно вылетает. Python выстрелил потом, да и его преимущества для начального обучения раздуты.
Нет, не был. Он был написан на пиратской версии Delphi и был интерпретатором. Не было никаких подсказок по коду, которые мы получили почти автоматом в NET за счет reflection.
Это вот очень странное мнение. Мне интересно, почему так воспринимается. Дело в том, что первая версия PascalABC.NET была точной копией PascalABC, даже справка была той же самой, но немного переделанной. И работала не как интерпретатор, а со скоростью машинного кода.
Это тоже интересно и это - странное мнение. Действительно, можно взять допустим pattern Matching - да, его пока нет в справке, это правда. Но это пожалуй и всё.
По поводу фокуса начального обучения - он сместился за эти 15 лет. Новомодные фичи 15 лет назад стали общим местом. Чтобы перевести целое в строку, мы пишем a.ToString. Процедуры и их последовательности могут храниться в переменных:
procedure PL := Paint + Left;
Кортежи воспринимаются школьниками как нечто естественное и простое:
(a,b) := (1,2);
Массивы создаются на лету короткими функциями:
var a := Arr(1,2,3);
Все типы автовыводятся:
var a := Arr(Arr(1,2,3),Arr(4,5));
Это немного другой мир. Сейчас - держаться за идеалы революции 17 года - сейчас выглядит странновато.
А сумбур - мне кажется, что он возникает у старых учителей, которые привыкли к турбо-паскалю 80 года и ЛЮБЫЕ новшества воспринимают как сумбур в обучении.
Ну и про недоработки пожалуйста расскажите - было бы очень интересно - не для примера, а по пунктам если можно. Потому что я не вижу существенных недоработок.
2 лайка
А исходники ABC можно увидеть?
Если это вопрос для меня, то существенных недоработок я не вижу. Я имел ввиду отсутствие некоторых полезных конструкций и оптимизации.
У меня лично сумбур был от недостаточно упорядоченной документации по некоторым вещам. Например по последовательностям, по классам коллекций и их методам. По лямдам. Все разбросано и неупорядоченно. Приходится искать что это и откуда ноги растут. Что-то есть в справке. Чего нет в справке, возможно, есть в презентациях. Чего нет (или нехватает) в презентациях, возможно, есть в ваших видео-лекциях по переподготовке преподавателей. А чего нет в ваших видео-лекциях… Понятно, время нужно да и желание все это упорядочить. А в остальном мне нравится. Очень много чего можно делать быстро и кода меньше, чем в старом паскале.
3 лайка
type
r1=record
s:set of byte;
end;
r2=record
s:set of byte := [2..3];
end;
begin
var f1:file of r1;//ok
var f2:file of r2;//Ошибка: Типизированый файл не может содержать элементы такого типа
end.
Это нормально? Или ошибка?
В GraphWPF нету эвента закрытия формы. Это так задумано? Как ещё можно поставить код на выполнение при завершении приложения? Мне вот понадобилось удаление файла туда поставить, когда я делал игру-пример для блочный файлов.
Здравствуйте. Объясните, пожалуйста, логику?
type
a = class
public
x, y: Integer;
end;
function GetPtr<a>(a_obj: a): ^a := @a_obj;
begin
var a_obj := new a();
a_obj.x := 10;
a_obj.y := 20;
var a_obj_ptr := @a_obj;
//var a_obj_ptr := GetPtr(a_obj);
//var a_obj_ptr: ^a := @a_obj;
println(^a_obj_ptr);
end.
Из двух закоментаренных вариантов первый с функцией GetPtr легитимен, а следующий - нет (ошибка: указатели на ссылочные типы недопустимы). Я так понимаю из-за указания типа ^a для переменной (где a - класс т.е. ссылочный тип), хотя для типа возвращаемого значения для функции GetPtr, оказывается допустимым. Этот вопрос, я задаю для справки, чтобы узнать что так и должно быть (ну или почти), но я очень не хотел бы чтобы это оказался “грязным хаком” и вы ограничили подобную возможность (которая существует для возвращаемого значения функции или для переменной для которой тип выводится автоматически).
1 лайк
И ещё замечание: не шаблонный вариант функции недопустим (та же ошибка).
У меня это не компилируется:
println(^a_obj_ptr);
^ надо ставить после переменной а не перед. До недавнего времени разрешало перед, но в последнем билде это уже не работает.
По теме:
В основном я с вами согласен, но в шаблонной подпрограмме лучше не запрещать это, больше проблем появится. А вот то - что оператор @ даёт вызвать для переменной ссылочного типа - это скорее всего неправильно.
Указатели на ссылочные типы недопустимы. Потому что сборщик мусора может двинуть их в любой момент.
Похоже на грязный хак
Записи не запрещены внутри generic-подпрограмм, но работа с ними не представляется возможной.
Принимает тип записи, помещенный в generic-процедуру или функцию, за подпрограмму :
procedure P<T>(); // Без <T> все нормально.
type
TRecord = record
end;
begin
end;
begin
end.
Undefined FileName(0) : Вложенные подпрограммы запрещены внутри generic-подпрограмм
А зачем оно Вам нужно?
Суть в том, что это либо должно выдавать адекватную ошибку, либо компилироваться. Решения два: разрешение объявления типов записей в generic-подпрограммах, либо их полный запрет в таких случаях.
А чем ошибка неадекватная? Там вроде по-русски сказано, что
У меня не подпрограмма внутри, а тип записи.
Институт математики, механики и компьютерных наук ЮФУ, 2005–2021