В движке требуется использование protected полей в классе предке и использование полей protected в yield функции,что пока не работает (это не великие идеи).
Как я понял,Вы намекаете на то, чтобы писать в этой среде надо ломать иногда концепции ООП, что неправильно.
Да ни на что я не намекаю. Движки я не делал, я делал библиотеку численных методов, реализуя её в ООП-концепции средствами PascalABC.NET. Обошелся без “protected полей в классе предке и yield”. Вы, видимо, делаете что-то такое, чего нельзя реализовать кроме как указанным Вами способом. Не буду спорить, я не видел Вашего проекта, Вот только раньше вообще ООП не было, а все равно писали…
В ней, кстати говоря, надо стандартизировать код, привести его к общему стилю, если захотите можете это сделать. Это так, совет. И спасибо разработчикам за исправленный баг.
Прошу в этой теме говорить об ошибках PascalABC.NET или о кажущихся таковыми. С примерами кода. Если установлено, что это - ошибка, то прошу вносить в Issue чтобы появлялась вероятность исправления. Мы исправляем баги в Issue по мере возможности.
Прошу постороннее обсуждение свести к минимуму
А давайте его удалим или куда-то перенесем, если нельзя удалить?
Наглое вранье. Проект уже давно не сырой. А всякие максималисты, которым кто-то почему-то что-то должен, пусть идут лесом
В тестирование входят только баги которые были исправлены. То есть оно сделано чтоб не добавлять исправленные баги. А новые фичи тестируются только пользователями паскаля…
Но разве разработчикам не следует ли тестировать для начала самим новые фичи? Лучше если разработчики выявят баг и исправят его, зачем “демонстрировать” баги?
На мой взгляд, основная проблема этого проекта – отсутствие деления на стабильную и нестабильные ветки.
Стабильная ветка должна иметь четко оговоренный минимальный срок поддержки (напр., 12 мес.) и включать в себя только консервативные багфиксы из текущей нестабильной ветки, находящейся в активной разработке. А все новые фичи, модули и рискованные багфиксы (в т.ч. нарушающие бинарную совместимость, семантику, интерфейсы и прочие задокументированные соглашения) не должны её затрагивать никоим образом.
Стабильность / нестабильность любого релиза должна также визуально отражаться в нумерации версий (напр., 3.2.x – стабильная ветка, 3.3.x - нестабильная альфа/бетка/RC, 3.4 – след. стабильная, и т.д.). После выделения временной ветки под релиз-кандидат должен наступать мораторий на добавление любых новых фич – только консервативные или критические багфиксы + минимальное время на стабилизацию и обкатку активными членами сообщества (скажем, за 1-2 мес. до объявления очередного финального стабильного релиза). Примерно то же самое – для временной ветки под бетку, только подольше (напр., 3-4 мес.), чтобы было время не только отладить код, но и отразить все изменения в офиц. документации, написать тесты/примеры/туториалы.
Т.е. примерно 6-8 мес. активно пекутся новые фичи для нового релиза (можно даже без публичных билдов, а только для доверенных тестеров/контрибуторов), затем форк на публичную бетку – активный фидбек/доводка/доки, потом “мягкая” заморозка фич в RC + стабилизация/полировка перед финальной подачей.
Кроме того, все официальные билды дистрибутивов на сайте должны иметь четкие ссылки на последний коммит, которому они соответствуют. Сейчас номер и дата билда не имеет строгой связи с состоянием исходников.
Все коммиты должны быть атомарными и иметь короткий, но понятный комментарий (не только основным разработчикам, но и любым “внешним” контрибуторам/тестерам и прочим опытным членам сообщества). Непрозрачные слияния накопленных за период изменений (мёржды) с любой веткой должны быть исключены.
Все новые хотелки/баги/фичи должны время от времени анализироваться и помечаться соответств. тэгами и признаками будущих/текущих версий на гитхабе, то же самое – для критических багов, чтобы разработчики и члены сообщества могли эффективнее взаимодействовать и прозрачно расставлять приоритеты по проблемам/задачам проекта.
Любые принципиальные вопросы, такие как общее направление развития проекта, его цели и задачи должны более открыто обсуждаться с сообществом, а не постулироваться жестко, категорично и пост-фактум (в стиле – весь код открытый, кому что-то не нравится – форкайте и пилите дальше сами, мы вам ничем не обязаны). Проекту жизненно необходимы новые силы, ресурсы и идеи, но они никогда не появятся при таком подходе к работе с коммъюнити.
В общем, ничего необычного, просто нужен более-менее полноценный и открытый проект- и релиз-менеджмент. В настоящий же момент проект хоть и формально открытый, но по методу управления – сугубо проприетарный, я бы даже сказал – авторитарный. Это у многих довольно быстро отбивает всякое желание активно ему помогать и иногда приводит к открытым конфликтам/непониманию даже среди активных и опытных участников.
Чего уж там говорить про перспективы замены ТурбоПаскаля, стандартизацию и появление полноценных учебников и массовое внедрение в учебные заведения (особенно школы) – пока что шансы равны 0. Да и узнаваемость среди мирового IT-сообщества, даже закоренелых паскалистов, несмотря на все очевидные достоинства и прогрессивные фичи – также ноль… (с) “Абидно, слюшай!”
P.S. Не сочтите это за неблагодарность по отношению к авторам, просто накипело за пару-тройку лет, как говорится, “за державу обидно!”.
Всё что Вы пишете - хорошо и правильно. Но нуждается в больших ресурсах и в большом сообществе разработчиков. Я согласен про новые силы и ресурсы. Но если эти силы будут заключаться в “а давайте вы сделаете то”, то это не годится - силы у нас маленькие. Про положительную помощь кроме поиска багов я не слышал с момента выкладывания проекта на Github.
Про “Форкайте и пилите сами” я никогда не говорил - никто не позволит добавлять в проект неконтролируемый код. Но я и не видел сколько-нибудь значимых попыток исправить хотя бы один Issue сторонними разработчиками.
Про перспективы замены Турбо-Паскаля в школах - эта замена де факто уже произошла. Турбо-Паскали используются в очень малом проценте случаев в школе сейчас, поэтому говорить про какие-то странные перспективы того, что уже произошло - это непонимание происходящего. Про написание новых учебников для школ - этот процесс абсолютно ничего не имеет с развитием проекта - проект может быть как угодно замечательный, а учебника ни одного не будет написано и наоборот.
Ещё раз - в школы PascalABC.NET фактически внедрён. То, что Вы пишете - про 0 вероятность - это параллельный мир.
Про 6-8 месяцев… Если внимательно посмотреть на последний год в Что нового, то можно утверждать, что в основном это - исправление багов. Вообще, новые языковые фичи добавлялись достаточно давно. Так что эту рекомендацию я отношу к тем самым советам “Вы делайте, а мы будем говорить, что не так”.
Комьюнити кстати пока весьма незначительный - здесь на форуме отмечено максимум 10 человек. И непонимание - да - оно существует. В основном между нашими возможностями и вашими желаниями. И скажем в трактовке того, что считать “активной помощью”.
Вот эта фраза конечно характерна своим “должны”: “Все новые хотелки/баги/фичи должны время от времени анализироваться и помечаться соответств. тэгами и признаками будущих/текущих версий на гитхабе, то же самое – для критических багов, чтобы разработчики и члены сообщества могли эффективнее взаимодействовать и прозрачно расставлять приоритеты по проблемам/задачам проекта”. Всего на Githubе около 30 открытых Issue (посмотрите кстати сколько закрыто) - если бы мы могли их быстро устранить, то давно устранили бы. Из этих ISSUE собственно серьёзных багов языка (не оболочки, не Intellisense, а языка) - 4 штуки. Какие там приоритеты должны расставляться в этих четырёх багах? Их просто надо исправить и всё.
Все что ты сказал - верно. Полностью поддерживаю. Желание писать на PascalABC.Net оно существует, но по мере наталкивания на множество багов, оно стремительно начинает падать…
На практике мы позиционируем Паскаль для другого - не для низкоуровневой работы с памятью
Я никогда не поверю, что разработчики не хотят добавлять или модернизировать те конструкции языка, которые позволяют оптимизировать приложение. 
Кстати, я не предлагал превратить Паскаль в Ассемблер.
А что мешает это сделать? Понятное дело, что такие уловки не предназначены для совсем начинающих, но это ведь не повод отказываться от этого. Вы могли бы привести код, как правильно это делать(может, я и правда ошибаюсь)?
Разработчики уже неоднократно высказывались на тему, чтО им мешает сделать то-то и то-то.
И чтобы им поверить, достаточно взглянуть на количество открытых issue, которое за последние полгода, похоже, ни разу не опустилось хотя бы до 20. И некоторые из них висят годами 
Ну не может пара человек с саперными лопатками разгрести все то гуано, которое десятки людей набрасывают совковыми лопатами. Неужели это так сложно понять?
Нет, на самом деле опускало, вроде ближе к новому году… Но это было быстро исправлено)))
Если посмотреть на открытые Issue, то можно увидеть следующее. Из 40 штук:
Всё это явно не стыкуется с той якобы удручающей картиной, которая рисуется здесь на форуме.
Причём, некоторые дошли до того, что вместо того чтобы задать вопрос на форуме, они открывают Issue на гитхабе.
Вот лично меня они волнуют достаточно сильно. Потому что на их базе уже столько всего выскакивало, просто я не писал об этом на форуме, считая что причина уже описана.
Да и баги в Intellisense - тоже не подарок, когда пишешь что-то в условиях цейтнота.
Институт математики, механики и компьютерных наук ЮФУ, 2005–2021