Ошибки PascalABC.NET


#1831

Да, я смотрел их, но там что - очень не понятное на английском языке. Кстати, по поводу предыдущего вопроса, PatternMathing отсутствует в C. Да и добавили его по инициативе разработчиков.


#1832

Вай дод! Шайтан порылся однако? Зачем на форуме российского вуза правила на английском? Вы, наверно, что-то путаете…


#1833

Нет. Я сам оболдел. Там даже не просто на английском было, а была ссылка на внешний сайт на английском.


#1834

Ладно, довольно офтопиков.


#1835

Я не предлагаю полностью отказаться от поддержки конструкций Турбо Паскаля – для школ и многих начальных курсов программирования (не с IT специализацией) его обычно вполне достаточно. Речь идет скорее о не самых удачных/ненужных (с точки зрения совместимости/идеологии .NET и современных языковых тенденций) нюансах реализации и синтаксиса диалекта Object Pascal, реализованного в TP/BP и Delfi.

ООП в обычных школах на информатике не проходят, насколько я знаю (на доп. занятиях или в спец. классах – дело другое). На ОГЭ/ЕГЭ также нет никакого ООП. Так зачем тянуть изо всех сил эту совместимость?

То же самое касается уже устаревших расширений и функциональности самого PABC.NET – нашли опытным путем более красивый/читабельный/удобный синтаксис – упрощайте компилятор, вырезайте старый в следующей мажорной версии. Только делайте это постепенно (ну, кроме может быть самых простейших и очевидных случаев, типа ситуаций с ;), дайте людям время на обкатку нового решения – скажем то, что в 3.5+ объявлено устаревшим/нерекомендуемым, в версии 4.x – уже ошибка. Причем в некоторых случаях (напр., как выше) синтаксис нужно не упрощать, а делать более строгим и единообразным – язык должен быть элегантным, но не запутанным! И при этом четко описанным.

З.Ы. Кстати, что касается именно Delfi – кто-нибудь может мне объяснить зачем до сих пор изучать в ВУЗах специфические особенности не, скажем, общедоступного Фри Паскаля/Лазаруса, а малораспространенного уже на практике и дорогого коммерческого продукта? В чем профит для студентов? В изучении латыни сейчас гораздо больше смысла.


#1836

Соглашусь. Из того, что изучается в учебных заведениях: консольный ввод-вывод. Он есть. Статические массивы, строки, простые типы - это всё есть. А что ещё? А ничего! Эту совместимость сломать - это ещё постараться надо. А вот вся остальная байда из Дельфи - в топку!


#1837

Никто их не отвлекает и не заставляет, им просто предлагают что-то новое время от времени. Хотя они сами выбирают чем именно заняться. Паттерны, тайп-классы и многие другие нетривиальные “модные” фишки они вводят в язык исключительно по собственной инициативе – чисто из академического интереса, частенько отдавая реализацию в руки своим подопечным: старшекурсникам или магистрантам.

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

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

Глеб, перестаньте уже называть Delphi “допотопным” и “мертворожденным”, он вполне себе развит, живет, поддерживается и развивается. Просто в силу разных обстоятельств (как внутренних, так и внешних, но только не слабости самого языка и RAD-среды!) его лучшие времена уже прошли и его былая популярность угасла – осталась только относительно небольшая коммерческая ниша (по сравнению с C#, Java и C++). Но мода приходит и уходит, и кто знает, может быть, если они изменят свою маркетинговую политику, они еще поймают свою волну ренессанса.

Турбо Паскаль тоже никогда не был “убогим” и “мертворожденным” – это был весьма продвинутый и суперпопулярный продукт для своего времени. Надо отдать ему должное, если бы не он – Паскаль вообще бы не дожил до нынешних времен ни в каком виде! Умер бы себе тихонько в 80-х, как Алгол и Модула…

То же самое касается и FP/Lazarus – они здравствуют и продолжают развиваться потихоньку, что даже удивительно с учетом их крайне ограниченных инженерных ресурсов и отсутствия поддержки со стороны крупных компаний. Есть еще активно развивающийся CodeTyphon Studio на их основе, со своими доработками и массой интегрированных сторонних компонентов, большинство из которых не только поддерживается, но и развивается дальше (а также время от времени появляются новые).

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


#1838

Сообщение перенесено в тему Болталка PascalABC.NET


#1839

@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 года и ЛЮБЫЕ новшества воспринимают как сумбур в обучении.

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


#1840

А исходники ABC можно увидеть?

Если это вопрос для меня, то существенных недоработок я не вижу. Я имел ввиду отсутствие некоторых полезных конструкций и оптимизации.


#1841

У меня лично сумбур был от недостаточно упорядоченной документации по некоторым вещам. Например по последовательностям, по классам коллекций и их методам. По лямдам. Все разбросано и неупорядоченно. Приходится искать что это и откуда ноги растут. Что-то есть в справке. Чего нет в справке, возможно, есть в презентациях. Чего нет (или нехватает) в презентациях, возможно, есть в ваших видео-лекциях по переподготовке преподавателей. А чего нет в ваших видео-лекциях… Понятно, время нужно да и желание все это упорядочить. А в остальном мне нравится. Очень много чего можно делать быстро и кода меньше, чем в старом паскале.


#1842
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.

Это нормально? Или ошибка?


#1843

В GraphWPF нету эвента закрытия формы. Это так задумано? Как ещё можно поставить код на выполнение при завершении приложения? Мне вот понадобилось удаление файла туда поставить, когда я делал игру-пример для блочный файлов.


#1844

Здравствуйте. Объясните, пожалуйста, логику?

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, оказывается допустимым. Этот вопрос, я задаю для справки, чтобы узнать что так и должно быть (ну или почти), но я очень не хотел бы чтобы это оказался “грязным хаком” и вы ограничили подобную возможность (которая существует для возвращаемого значения функции или для переменной для которой тип выводится автоматически).


#1845

И ещё замечание: не шаблонный вариант функции недопустим (та же ошибка).


#1846

У меня это не компилируется:

      println(^a_obj_ptr);

^ надо ставить после переменной а не перед. До недавнего времени разрешало перед, но в последнем билде это уже не работает.

По теме:
В основном я с вами согласен, но в шаблонной подпрограмме лучше не запрещать это, больше проблем появится. А вот то - что оператор @ даёт вызвать для переменной ссылочного типа - это скорее всего неправильно.


#1847

Указатели на ссылочные типы недопустимы. Потому что сборщик мусора может двинуть их в любой момент.

Похоже на грязный хак


#1848

Записи не запрещены внутри generic-подпрограмм, но работа с ними не представляется возможной.

Принимает тип записи, помещенный в generic-процедуру или функцию, за подпрограмму :

procedure P<T>(); // Без <T> все нормально.

  type
    TRecord = record
    end;

begin
end;

begin
end.

image

Undefined FileName(0) : Вложенные подпрограммы запрещены внутри generic-подпрограмм


#1849

А зачем оно Вам нужно?


#1850

Суть в том, что это либо должно выдавать адекватную ошибку, либо компилироваться. Решения два: разрешение объявления типов записей в generic-подпрограммах, либо их полный запрет в таких случаях.