Про развитие уже и комментировать не буду: я уже написал все, что думаю по поводу этого “развития”, как Вы его именуете. Развитие - это вот про PascalABC.NET. Это - развитие.
Про “чего там не хватает”. Я где-то писал, что там МНЕ чего-то не хватает? Это Вы решили, что мне там чего-то не хватает. Чего не хватает в Паскале уровня fpc уже многократно писано. Я отреагировал на Вашу фразу про активное развитие" - и только.
Это обычная фраза. Пишут типа active, alive, under development, dead. А по уровню активности, там тоже достаточно активно люди работают. Я не понимаю, зачем все эти жаркие споры. Если честно, я и PascalABC.NET опасаюсь активно пользоваться в том числе и из-за этих холиваров. Там же есть вещи, которым можно поучиться. Но я как раз не рекламный агент, так что не собираюсь кого-то рекламировать.
Понял
Дело здесь не в .NET, просто другие Паскали уже не поддерживаются разработчиками много лет. Кроме того, использовать те реализации для профессиональной работы крайне сложно.
Проверки делаются при вызове индексного свойства this[int i]. Это происходит независимо от Вашего желания.
Я уже сказал, что Вы правы. Про указатели я говорил с точки зрения программы, а не микросхемы. И я сказал об этом.
Согласен.
Вот если для работы, то только PascalABC.NET.
Учиться на чём-либо кроме PascalABC.NET - глупо.
Если речь о первом языке - по-моему эффективнее только волшебная палочка. В свое время весьма понравилась вот эта статья. Ее объем немал, но как С-подобные языки уродуют мышление новичков, рассказано весьма наглядно.
Так я же с Вами согласился))
Есть разные подходы. Например, весьма успешный подход демонстрирует Liquid Haskell. Это, фактически, плагин к компилятору, подключающий солвер. Те, кто не используют LH, платят 0. Те, кто хотят refinement types, платят то, что необходимо. По-моему, это не противоречит «эффективности» компилятора.
Как вы смотрите на то, чтобы позволить такой синтаксис для автоматической распаковки кортежа в a, b:
begin
var S := Seq((1, 'A'), (2, 'B'), (3, 'C'));
foreach var (a, b) in S do
Writeln(a, b);
foreach var pair in S do
Writeln(pair.Item1, pair.Item2);
end.
?
А также, считаете ли Вы нужным добавить оператор ?? ?
А что такое оператор ?? ?
Да, на всё положительно смотрю. Руки нужны. Без оператора ?? оператор ?. не закончен.
Частенько возникает ситуация, которую приходится некрасиво решать. Например, при селекции по Where ставить DefautIfEmpty, но все дефолты дают обычно ноль, что устраивает совсем не всегда.Простой пример: последовательность содержит члены с разными знаками, надо найти сумму членов, удовлетворяющих некоторому условию. Получили ноль. Этот ноль - он потому что в выборку ничего не попало, или попало, но так удачно сумма пришла в ноль?
C-подобные языки, или только С? Я чет в статье вижу сугубо упоминание чистого С, и большая часть аргументов совершенно неактуальна для, например, C# или Java. Да даже для С++.
Нет массивов? Их есть у нас! Нет адекватно определенных типов, вместо которых константы? Их есть у нас! Амперсанды и указатели? В C# и Java в общем случае отсутствуют, в современных редакциях C++ можно писать абсолютно без них, а знания об итераторах можно сократить до std::begin() и std::end(). Насчет передачи параметров по ссылке - почитал, вижу аргумент, но чем отличается int& param от var param: integer - не понимаю, хоть убейте. А в Java/C# и так ссылочная модель. Модульность? С++ слегка хромает, C# и Java - поддерживают полностью.
Хаки, применяемые в С, во всех этих языках попросту не нужны - есть гораздо более иллюстративные методы для того же копирования строк. Описание побочных эффектов и прочего - претензия скорее к программистам, чем к языку. Да и на кой черт использовать while (*c++=*k++); когда есть strcpy() - лично мне неясно.
В пример “плохого влияния С-подобных языков” приведена статья, которая описывает давно известные проблемы чистого С, для остальных же С-подобных единственным актуальным аргументом остается только небольшое количество “ссылок наперед”, причем код по ним писать и не надо - автогенерация на старте проекта делает все необходимые действия, достаточно лишь сказать “писать здесь”. Возраст ей 8 лет, и приводить ее сейчас достаточно неуместно.
Я не говорю, что на этих языках надо учить. Говорю лишь, что не стоит ненависть к ним возводить в бессмысленный абсолют из-за наследия двадцатилетней давности, которое уже давно потеряло актуальность.
P.S. Чет меня прям забомбило с такого… Прошу простить.
Да там и для того времени есть пара моментов не совсем правильных. К примеру там приводиться пример с “Hello, world!”, первые две строчки объяснили самым заумным способом из возможных, назвав его “правильным”. Вот только этот “правильный” способ повествования на лету даже опытным программистом, и тут проблема не в C. Потом ещё добавили что объясняя термины можно забыться во времени. Вот только это проблема учителя. Объяснить в 2 словах, не ссылаясь на то что ещё не учили, должен уметь каждый учитель.
Да нет, способы объяснения там как раз корректные, к этому претензий нет. Основная претензия к тому, что по этой гребенке равняют все ЯП, у которых вместо begin/end фигурные скобки в качестве операторов начала/конца блока, а это некорректно.
Там на сайте лежит книжка того-же автора по C++ - посмотрите предисловие для учителей. Я в своё время разбирался с его реализацией LISP на C++, так что думаю он в теме. Я кстати тоже, задумался, какое отношение его к C#.
У Вас, видимо, “гнев праведный замутил очи”. Нет там нигде ненависти, есть суждение (я и его разделяю), что С-подобные языки не годятся для обучения в качестве ПЕРВОГО языка программирования. Более того, там же сказано, что С обязателен к изучению профессиональными программистами. Где Вы там ненависть-то углядели…
Итак, у меня есть несколько предложений к разработчикам, касающихся производительности кода. Итак, я предлагаю ввести директиву, позволяющую отключать проверку индексов статических массивов, причём как одномерных, так и многомерных. Как я понял, платформа .NET Framework не имеет встроенных статических массивов, то есть в платформе их не может быть в явном виде. Из этого следует, что статический массив является конструкцией конкретного языка(в нашем случае-Паскаля) и генерируется компилятором в допустимом виде. Следовательно, статический массив может быть определён и обработан по разному в каждом языке, и он может быть представлен как набор переменных, либо одномерный массив, что может повысить эффективность работы программы. Второе - та же директива, но для динамических массивов разной размерности. На уровне компилятора можно организовать замену стандартного обращения к элементам массивов по индексным свойствам на обращение по указателями, что избавляет как минимум от проверки индексатора(ов) и ощутимо повышает эффективность кода.
Есть и ещё одно предложение. Можно ли сделать работу с указателями в явном виде? То есть не описывать синоним указателя, вводя таким образом лишние имена, а писать в коде непосредственно указатель в стандартном паскалевском виде. Например, сейчас код для работы с указателями выглядит так:
Type PByte = ^Byte;
Begin
Var Variable: Byte;
Var P: PByte := @Variable;
End.
А я предлагаю сделать так:
Begin
Var Variable: Byte;
Var P: ^Byte := @Variable;
End.
Это ведь стандартная запись практически во всех Паскалях, к тому же, более удобная и короткая.
Ну, это как раз компилируется. Это при приведении типо нельзя так делать, то есть это:
Begin
Var Variable: Byte;
Var P := ^Byte(@Variable);
End.
Не откомпилируется потому что тип к которому приводите должен быть цельным именем.
Текущая реализация не использует индексаторы типа this[i]. Ошибка IndexOutOfRangeException вызывается инструкцией ldelem. Её наверное можно заменить на полдюжины инструкций воспроизводящих Ваш трюк, но это как-то сложновато будет выглядеть.
Институт математики, механики и компьютерных наук ЮФУ, 2005–2021