Ошибки компилятора PascalABC.Net

Среда PascalABC.NET
#85

А что имеется? Ограничение или возможность?

#86

Ограничние.

#87

Ну так а зачем оно в Паскале?

#88

Вся моя точка зрения изложена в Issue и в сообщениях выше. :slight_smile: Абсолютно вся.

И, все-же, я согласен с @spectatorBH, что ограничение на конкретный тип может служить в некотором роде заготовкой.

<личное мнение>Наверное, моя точка зрения несколько противоречива.</личное мнение>

В общем подытожу:

  • За запрет: конструкция не очень полезна; так сделано в C# (менее значимый аргумент)
  • Против запрета: возможная обратная совместимость (возможно, это уже использовалось); пример, приведённый @spectatorBH
#89

Знаете, тут уже когда-то, то ли для совместимости, то ли для восстановления какой-то мутной логики, предлагали запретить автообнуление переменных. Если бы это сделали, огромная база кода стала бы недействительной и потребовала бы достаточно объёмного исправления. Это я к тому, что запретить можно всегда и это не так сложно, а вот исправлять последствия можно очень долго.

#90

По сути, ваша претензия тут – избыточность функционала в некотором очень редком частном случае (шаблонный параметр размерного типа эквивалентен нешаблонной подпрограмме с этим явным типом параметра).

Контраргументы:

  1. это уже реализовано давно;
  2. это никому не мешает;
  3. это может быть реальная (т.е. иногда полезная на практике), хоть и весьма мало распространенная, ситуация применения – напр., в процессе отладки;
  4. это ничему принципиально не противоречит (логике, синтаксису, канонам…);
  5. С#, как и любой другой ЯП, не может являться бесспорным эталоном или догматичным примером в любой ситуации;
  6. некоторая избыточность свойственна любому практическому ЯП.
2 лайка
#91

Да, Вы кратко и точно выразили мою точку зрения. Если у Вас есть пример языка, в котором также как в C#, или как в PascalABC.Net, можете привести его сюда. Это будет аргументом либо контраргументом моей точки зрения.

#92

Ограничение ограничения == возможность. :slight_smile:

1 лайк
#93

Давайте на этом завершим обсуждение. Уже много беседовали. :slight_smile: Тем более, все, кто участвовал в беседе уже высказались.

1 лайк
#94

Некоторые споры настолько бесполезны, что со временем становятся просто забавными и превращаются в спорт :slight_smile:

#95

Не могли такое предлагать, не компилятор “обнуляет”, а .NET-среда так инициализирует.

#96

Это понятно, но предлагали заставить явно обнулять переменные.

#97

Зачем еще раз обнулять обнуленное? Если Вы на меня намекаете, я не предлагал компилятор “заставлять” что-то там делать, я говорил о том, что если программист пишет код, полагаеясь на автообнуление - то это дерьмовый код.

#98

Я не намекаю на Вас. Я говорю о том, что хотели заставить программиста обнулять переменную.

#99

Что значит “заставить”? Как можно программиста заставить что-то делать, если он не хочет? Еще раз, я писал о том, что если не инициализировать переменную, считая, что раз она автоматически обнуляется, то и славно - это дерьмокод. Завтра мелкомягкие выпустят вместо дотнета какой-нибудь “комманет”, где не будет автообнуления и что - программы все переделывать?

#100

Ошибка компилятора с лёгкостью заставляет это делать. Но вот если в .NET это делает JIT, то зачем усложнять свой код?

#101

Вот пока Вы так думаете, нормального программиста из Вас не получится. Помните слова мадам Простаковой у Фонвизина: “Зачем географию учить, коль извозчик довезет?”. Это примерно то же.

#102

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

#103

Вы неверно приоритеты расставляете. Код должен быть для начала надежным. А гарантированная инициализация переменных - одно из непременных условий надежности кода. А Вы на среду полагаетесь. Завтра среда изменится - и что дальше?

#104

Проблемы надо решать по мере их поступления. Я понял, почему Вы любите Фортран - он не меняется, код на нём можно запустить в любой версии. Но не все пишут на Фортране.