Ниша PascalABC.NET

Вот… 17 числа еще одна всероссийская школьная олимпиада.

PascalABC.NET вроде бы включен, но…

Ну это ещё что! Дельфи вообще какая-то 2.4.4. указана. Это что ли Delphi 2 от 1996 года?

Я уже высказывал предположение, что это делается намеренно неким лобби. Иначе пишущие на PascalABС.NET остальных “уделают” в разы. А так программа благополучно зарубится по синтаксису - и все дела.

GCC/++ 4.9.0 - release date April 22, 2014. Это что же, вместо компилятора С++ поставили такое сушеное говно? =3

Delphi 2 - промолчу

Python 3.4.3 - release date February 25th, 2015. Аналогично. Сейчас уже версия 3.7.0 выползла.

Haskell 4.7.1. - это что вообще за зверь такой? GHC нынче восьмой версии в интернетах!

Нет, не в лобби дело. Дело в том, что тем, кто занимается этой самой олимпиадой, влом переставлять компиляторы на компах, на которых олимпиада проходить будет в очном виде, да на системах проверки… Что было - то и взяли. Если уж компилятор С++ вышел трехсполовинойлетней давности (тот, по поводу которого Вы утверждали о наличии для него многочисленного лобби) - о чем тут говорить.

Проблема тута стоит в том, что версия 3.1, указанная в документе, попросту в интернетах (по крайней мере, на официальном сайте) не доступна. Значит, нужно или их таки выкладывать (по такому принципу), или форсить сверху необходимость выкладывать дистрибутивы самим зачинателям олимпиады.

Из всего перечисленного софта PascalABС.NET со временем меняется быстрее всего. Либо использовать только какие-то базовые вещи, либо быть готовым, что не откомпилируется. Посмотрите на сайте, сколько изменений сделано за один последний год. Ни один из тех прочих языков так сильно не полируется.

Да, на офф сайте нет, но никто не отменял гитхаб, у которого можно отматывать коммиты))) Там не только 3.1, там все версии и все билды можно получить, даже те что на сайт не попадали…

Но да, это не отменяет ничего что вы сказали…

Меняется, конечно. Проблема тут в том, что следить за десятками выходящих за месяц версий желания не будет ни у кого, кроме энтузиастов с этого форума, что неоднократно подтверждается появляющимися тут вопросами про PascalABC, сдохший добрый десяток лет назад.

Решением тут было бы формирование Stable/Nightly версий, которые обновляются в соответствии с некоторым графиком. Скажем, Nightly сразу после появления некоторых фич, а Stable - с поднятием мажорной/минорной версии (в зависимости от объема изменений), и не чаще чем один раз в полгода. В таком случае можно было бы (согласно обсуждаемой темы):

  1. снять необходимость с организаторов олимпиад лезть на офсайт проверять версии раз в неделю
  2. иметь официальную возможность сказать всяким баговоенам вроде того же Молдована, что он сидит на нестабильной версии, и свои пожелания по части багов может засунуть себе куда поглубже

Из добавившейся работы по данному вопросу - один раз в полгода формировать набор хорошо оттестированного функционала и мержить его в ветку Stable, оставляя все недотестированные и только появившиеся фичи в Nightly. Не то, чтоб очень много. Документацию делать только на Stable, желающие сидеть на Nightly (т.е., предположительно, более опытные) вполне обойдутся changelog’ами на гитхабе. Можно даже ссылку на Nightly на сайте не держать - лишь сказать, что последняя нестабильная версия доступна для скачивания в репозитарии.

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

Я сейчас не хочу сказать, что Паскаль полон багов и дырок - нет. Вопрос именно в отношении к моделям rolling vs fixed release. Я вот дома у себя archlinux держу, который обновляется так же, как и Паскаль - быстрее даже. Но подумаю 25 раз перед тем, как воткнуть эту операционную систему на прод. По вышеописанным причинам. К продукту со моделью обновлений rolling release недоверие по умолчанию.

1 лайк

Уже пытались обсуждать. предлагать. Ответ разработчиков всегда одинаков: никаких бета-версий нет, самое последнее обновление - актуальная версия продукта, по всем прочим нет смысла ни хранить, ни обсуждать. Возможно это связано с малочисленностью команды, потому что на поддержку нескольких версий нужны приличные трудозатраты.

Согласен конечно.

Нужно пофиксить многочисленные накопившиеся баги в лямбдах, накопившиеся к этому моменту. И тогда уже переходить на эту модель.

И срезы для матриц сделать. (Кто о чем, а вшивый - о бане)

1 лайк

Трудозатраты нужны, когда возникает более сложная схема:

  • Nightly - текущая последняя нестабильная версия, последний коммит
  • Stable - фиксированный набор функциональности, но есть багфиксы

За счет необходимости внесения багфиксов в Stable в такой схеме, кодовая база двух веток может изрядно разъезжаться - особенно, если в Nightly произведен рефакторинг кода, или избрана новая концепция работы. Это приводит к необходимости тянуть две версии кода вместо одной. Я же предлагаю изначально собирать в Stable только гарантированно откатанный код, и фиксировать его полностью.

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

Это несколько затормозит развитие стабильной версии на фоне Nightly, но при этом напряга не добавит абсолютно - помимо необходимости раз в N месяцев заниматься выбором готовых к релизу фич.

1 лайк

Да, но если на сайте две версии, их нужно поддерживать обе. Ведь если сейчас ,когда задается вопрос не по последней версии, навстречу сразу летит “А Вы обновились?” А так надо у себя держать вторую версию (не так уж они и хорошо на одном компьютере уживаются!) и осуществлять поддержу по обоим. Я вот об этой трудоемкости.

Nuff said.

Обсуждение Nightly-версий так и вовсе выпилить с форума, и отправить на мороз гитхаб.

VirtualBox!

Присоединился недавно, но не могу не добавить своего мнения. Случилось так, что в институте в 0х годах нам преподавали Турбо Паскаль, и с интерфейсом в те годы было туго. Но не смотря на это, на олимпиадах по программированию мне удавалось занимать места сверху. Затем был перерыв в 20 лет, занимался конструкторской деятельностью. В это время пробовал delphi, vs, arduino. Не срослось. А вот, сейчас, понадобилось срочно создавать специализированное прикладное ПО и я натолкнулся на pascalabc.net. И поперло. Сейчас я уже готов сертифицировать этот продукт и узаконить в эксплуатацию на работе. Видимо, для старой школы, в текущих реалиях, pascalabc является хорошим выбором.

3 лайка

Спасибо. Ниша, несомненно, есть.

От старой школы, наверное, остались begin - end и :=

Интересно, насколько используете возможности PascalABC.NET.

И - что значит сертифицировать продукт?

Из возможностей пока прочувствовал: библиотеку с математикой: vector, spline; Без конструктора форм удалось освоить интерфес и обработку событий; очень помогает бесконечные переменные типа string, он же text на формах. Под сертификацией понимаю комплекс мер, предназначенных для обеспечения безопасности использования данного программного продукта на производстве. Станки гидроабразивной резки ЧПУ. Оборудование дорогое. Для использования дополнительного ПО необходимо подтвердить надёжность и безопасность используемых алгоритмов и решений.

2 лайка

Понятно. Очень интересно.

Я так понимаю, нужно именно GUI-приложение и какие-то математические алгоритмы?

А как компьютер будет управлять этим процессом? Будет ли взаимодействие со станком - или просто какие-то расчеты?

1 лайк

В задачи входит компенсация кривизны листа по предварительным измерениям щупом, выполнение наклонных резов с заданным угом(формирование фасок), компенсация разности теоретической и практической толщины листа. Дополнительные функции. Результат: откорректированная УП. От станка забираю таблицу измерений, готовлю ему отдельную УП для измерений.

1 лайк