Замечания и предложения


#608

Про развитие уже и комментировать не буду: я уже написал все, что думаю по поводу этого “развития”, как Вы его именуете. Развитие - это вот про PascalABC.NET. Это - развитие.

Про “чего там не хватает”. Я где-то писал, что там МНЕ чего-то не хватает? Это Вы решили, что мне там чего-то не хватает. Чего не хватает в Паскале уровня fpc уже многократно писано. Я отреагировал на Вашу фразу про активное развитие" - и только.


#609

Это обычная фраза. Пишут типа active, alive, under development, dead. А по уровню активности, там тоже достаточно активно люди работают. Я не понимаю, зачем все эти жаркие споры. Если честно, я и PascalABC.NET опасаюсь активно пользоваться в том числе и из-за этих холиваров. Там же есть вещи, которым можно поучиться. Но я как раз не рекламный агент, так что не собираюсь кого-то рекламировать.


#610

Понял

Дело здесь не в .NET, просто другие Паскали уже не поддерживаются разработчиками много лет. Кроме того, использовать те реализации для профессиональной работы крайне сложно.

Проверки делаются при вызове индексного свойства this[int i]. Это происходит независимо от Вашего желания.

Я уже сказал, что Вы правы. Про указатели я говорил с точки зрения программы, а не микросхемы. И я сказал об этом.

Согласен.

Вот если для работы, то только PascalABC.NET.

Учиться на чём-либо кроме PascalABC.NET - глупо.


#611

Если речь о первом языке - по-моему эффективнее только волшебная палочка. В свое время весьма понравилась вот эта статья. Ее объем немал, но как С-подобные языки уродуют мышление новичков, рассказано весьма наглядно.


#612

Я же не предлагаю изучать C-подобные языки, я предлагаю PascalABC.NET.


#613

Так я же с Вами согласился))


#614

Есть разные подходы. Например, весьма успешный подход демонстрирует Liquid Haskell. Это, фактически, плагин к компилятору, подключающий солвер. Те, кто не используют LH, платят 0. Те, кто хотят refinement types, платят то, что необходимо. По-моему, это не противоречит «эффективности» компилятора.


#615

Как вы смотрите на то, чтобы позволить такой синтаксис для автоматической распаковки кортежа в 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.

?

А также, считаете ли Вы нужным добавить оператор ?? ?


#616

А что такое оператор ?? ?


#617

?? Operator (C# Reference)


#618

Да, на всё положительно смотрю. Руки нужны. Без оператора ?? оператор ?. не закончен.


#619

Частенько возникает ситуация, которую приходится некрасиво решать. Например, при селекции по Where ставить DefautIfEmpty, но все дефолты дают обычно ноль, что устраивает совсем не всегда.Простой пример: последовательность содержит члены с разными знаками, надо найти сумму членов, удовлетворяющих некоторому условию. Получили ноль. Этот ноль - он потому что в выборку ничего не попало, или попало, но так удачно сумма пришла в ноль?


#620

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. Чет меня прям забомбило с такого… Прошу простить.


#621

Да там и для того времени есть пара моментов не совсем правильных. К примеру там приводиться пример с “Hello, world!”, первые две строчки объяснили самым заумным способом из возможных, назвав его “правильным”. Вот только этот “правильный” способ повествования на лету даже опытным программистом, и тут проблема не в C. Потом ещё добавили что объясняя термины можно забыться во времени. Вот только это проблема учителя. Объяснить в 2 словах, не ссылаясь на то что ещё не учили, должен уметь каждый учитель.


#622

Да нет, способы объяснения там как раз корректные, к этому претензий нет. Основная претензия к тому, что по этой гребенке равняют все ЯП, у которых вместо begin/end фигурные скобки в качестве операторов начала/конца блока, а это некорректно.


#623

Там на сайте лежит книжка того-же автора по C++ - посмотрите предисловие для учителей. Я в своё время разбирался с его реализацией LISP на C++, так что думаю он в теме. Я кстати тоже, задумался, какое отношение его к C#.


#624

У Вас, видимо, “гнев праведный замутил очи”. Нет там нигде ненависти, есть суждение (я и его разделяю), что С-подобные языки не годятся для обучения в качестве ПЕРВОГО языка программирования. Более того, там же сказано, что С обязателен к изучению профессиональными программистами. Где Вы там ненависть-то углядели…


#625

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

Есть и ещё одно предложение. Можно ли сделать работу с указателями в явном виде? То есть не описывать синоним указателя, вводя таким образом лишние имена, а писать в коде непосредственно указатель в стандартном паскалевском виде. Например, сейчас код для работы с указателями выглядит так:

Type PByte = ^Byte;
Begin
  Var Variable: Byte;
  Var P: PByte := @Variable;
End.

А я предлагаю сделать так:

Begin
  Var Variable: Byte;
  Var P: ^Byte := @Variable;
End.

Это ведь стандартная запись практически во всех Паскалях, к тому же, более удобная и короткая.


#626

Ну, это как раз компилируется. Это при приведении типо нельзя так делать, то есть это:

Begin
  Var Variable: Byte;
  Var P := ^Byte(@Variable);
End.

Не откомпилируется потому что тип к которому приводите должен быть цельным именем.


#627

Текущая реализация не использует индексаторы типа this[i]. Ошибка IndexOutOfRangeException вызывается инструкцией ldelem. Её наверное можно заменить на полдюжины инструкций воспроизводящих Ваш трюк, но это как-то сложновато будет выглядеть.