Верно. Что касается PascalABC.NET - у него есть PABCSystem, встроенный, что даёт ему некоторое преимущество (в обучении - заметно особенно). Даже если у нас в ReadMe.md расписано как ABCNET устанавливать, то новичок на психологическом уровне не захочет это делать - он не будет понимать что он делает и будет страх большой сделать что-то не так, хотя всё просто. Именно поэтому библиотека наша не совсем для новичков.
А не новички уйдут на C#. PascalАВС.NЕТ - это как разгонная ступень у ракеты. Отработала - и сброс в атмосферу.
1 лайк
Там и будут пользоваться. Хотя, мы советуем ещё и NumPy (есть его порт на NET). И для Python - само собой разумеется. Выбирают - пускай сами.
Пайтон? Для серьезной работы - скриптовый язык? Да уж. У меня больше к Вам нет вопросов и комментариев.
1 лайк
Я на нём не писал ничего серьёзного, так что критиковать и расхваливать - у меня нет возможности и знаний. Мои познания ограничиваются основами в нём. Но, единственное что могу сказать - непривычно, ошибки во время выполнения - не удобно - особенно после языков со статической типизацией.
Одна из лучших IDE для него:
Проект, в котором Python используется:
Хватит называть меня тестировщиком. Я бэкэндер. Основная разница в том, что я не ищу все дыры, какие только могу. Я пишу свои программы и репорчу то, что увижу по пути. Ну и поиск минимального кода, мягко говоря, не приносит мне никакого удовольствия.
1 лайк
Тогда - не знаю кто будет заниматься поиском минимального кода. В любом случае - не наша ответственность уже, ибо проблема не на стороне нашего проекта.
Кроме того, Вас никто не заставляет искать минимальный код разработчикам PascalABC.NET. Это - Ваше решение, которое руководитель проекта по достоинству оценил, но это не означает, что так должен делать каждый, кто находит проблему в этом проекте. Нет формального правила, где было бы сказано. Это не обязанность. И Вы даже не обладаете правами обязывать это делать кого-то где бы то ни было. Это - open-source проект. Мы, например, не обязываем для нас искать минимальный код (чтобы устранить проблемы на стороне библиотеке).
“Ваш продукт - ваша проблема”? Как говорится, я не подстрекатель, но будь я на месте разработчиков - ответил бы Вам тем же.
1 лайк
Было сказано - мы тестируем только свои проекты. Если ошибка находится на стороне компилятора какого-либо языка, а не нашего проекта, то исправлением её - занимаются разработчики и тестировщики этого языка.
Мы не заставляем для нас ничего тестировать в плане наших продуктах для поиска ошибок в них. Это - наша ответственность. Поэтому - нам достаточно примера ошибки, если будет при использовании той же ABCNET. Если ошибка в ней - она будет исправлена. Со стороны пользователя не будет требоваться поиска минимального кода - это уже наша задача. А его - ждать когда будет исправлено.
Безусловно, к исправлению Вас никто и не пустит. Но речь о локализации ошибки, которая вылезла в ВАШЕМ проекте. Почему кто-то должен копаться в ваших кодах?
1 лайк
Ну вот как по мне - я бы просто их нафик выкинул из PascalАВС.NЕТ, ибо как долботня с ними есть, а пользуются единицы. И да, ну не нравится вам PascalАВС.NЕТ (а мы всё помним, если что) - не пользуйтесь!
1 лайк
Замечу, разве, что в самом языке они мне не пригождались, за исключением случаев написания примеров к собственной библиотеке. Это - 1-2 примера на всю их массу.
Вот и я о том. Украшательство, отнимающее силы и время.
Находить минимальный код своего кода и минимальный код чужого кода - это 2 совершенно разных типа приключений.
Вас никто и не заставляет делать минимальный код. Но ещё раз посмотрите на issue которую кинули, на её давность и состояние. Никто не захочет браться за то, что мешает только 1 проекту, когда даже минимальный код не удосужились предоставить, есть множество более важных задач.
Мы и не требуем (!), чтобы брались. Мы только сообщаем. Требовать здесь могут только @Admin и @ibond.
В данном случае - проблема на стороне компилятора, поэтому - это поиск минимального кода для PascalABC.NET. Точнее - помощь стороннему (для нас) проекту за просто так. Это - вне наших обязанностей, повторюсь. Даже если бы (представим) помощь была бы платна и мы бы за это получали, то мы бы подумали, браться ли за это или нет.
Конкретно нам (разработчикам) - не мешает. Мы пишем в Visual Studio. Пользователям - может мешать. Именно поэтому и было сообщено об ошибке. Кроме того, вложенные типы не только у нас есть, поэтому мешать может (при использовании) не только пользователям нашего проекта. Это ещё поднимает значимость этого сообщения. Если говорить о процессе работы с ошибками в нашей команде - пользователь сообщает об ошибке, мы выясняем её корень и если он в нашей библиотеке - правим, иначе - уведомляем разработчиков соответствующего продукта об этой проблеме, сообщаем это пользователю и завершаем свою работу на данной ошибкой. Мне понятно нежелание малых команд что-то искать, когда дополнительных ресурсов нет, но этот подход нашей команде чужд. Взялись за проект - делаем, чтобы было удобно пользователям, такой уж путь избрали мы себе. Кроме того, мы сами в каком-то смысле пользователи своего же творения, так что мы делаем жизнь удобней и себе.
А по моему речь шла про partial класс в подключаемой к паскалю библиотеке, а не про partial классы в паскале.
В любом случае. Мы можем поменять архитектуру библиотеки и “скрыть” проблему от её появления здесь. К примеру, вынести классы вложенные в отдельное пространство имён, вместо их вкладывания в другие классы. Всё равно сейчас сильно меняем библиотеку. Но каждый раз мы так делать не сможем. Это может повреждать обратную совместимость из-за переделывания библиотеки. Кроме того, такой вариант не всегда возможен без последствий.
Благодаря нашим нешуточным усилиям он туда попадёт. В следующий раз.
Какое время - такие и песни…
10 - 11 классы Информатика 15+8 б
Нужно написать программу на Python о распространении коронавируса. Что-то типа статистики и симуляции дальнейших событий. Например: в день заражаются 200 человек, через 3 дня будет заражённых столько-то и процент смертности такой-то…
Sou116 7 минут назад
1 лайк
Институт математики, механики и компьютерных наук ЮФУ, 2005–2021