Да, и начинающим изучать язык это выносит мозг, Приходится или производить розыск каждого модуля - откуда его подключать, - или подключать всё сразу пресловутым “namespaсe std” и в чем тогда выигрыш?
Меня, к примеру, буквально “плющит и колбасит”, когда вместо паскалевского
begin Write(sin(readReal)) end.
приходится писать пяток строчек сишного кода.
Современный язык должен быть высокоуровневым, а не ассемблероподобным.
У меня только один вопрос тут: ЗАЧЕМ? Это же некоммерческий проект, его основное предназначение все же обучение и опробование технологий разработки компиляторов (пусть меня поправят разработчики), а не создание ПО для бортовых компьютеров.
То есть по вашему на паскале не нужно возможности для создания полноценных проектов, он должен остаться только для обучения? Бортовые компьюторы это слишком(и их недавно вроде стали делать механическими вместо электрических, чтоб не ломались, а они после создания уже не программируются), но я пишу полноценную игру на паскале и меня так устраивает, переучиваться желания нет.
Полноценные проекты средней сложности можно создавать и так (по утверждению разработчиков). А игры вообще бесконечно прожорливы (сейчас я временами играю в одной такой, занимающей более 30 Гб на жестком диске и пытающуюся грузится в 5 Гб оперативной памяти). Посему стоит ли говорить о смешном размере паскалевской библиотеки - это не мне решать. Но по мне - так это ерунда…
Я не считаю такую тенденцию хорошей… То что я могу поиграть в Космических Рейнжеров на макс. настройках и 600 фпс, но не могу запустить ни 1 из новых игр как минимум удручает. Я стараюсь сделать так чтоб у всех пошло(особенно у меня). А главное что различие лишь, ну макс, в 5% времени и том что надо будет напрячь мозг, а не пихать всё подряд. Вот и в этом случае, можно сделать такую мелочь как отключение PABCSystem директивой, если есть возможность не усложнять готовую программу - почему не воспользоваться?
Человек, имеющий какую-никакую голову тут же сообразит, что:
readReal - это что? Встроенная константа?:Функция без параметров? Если функция - как и откуда она читает? Файл? Как указать? Стандартный поток? А как ввести несколько? А с запятой или с точкой надо десятичный разделитель? Вот read - функция, описанная в стандарте, и с ней все понятно, а это - усложняющий сахар, каким бы “удобным” оно не казалось. Выглядит просто, но на деле создает больше вопросов, чем ответов.
Синусу надо отдать число в радианах. вводить с клавиатуры радианы - вводить что-то без перевода в них - глупость.Или readReal умеет сам переводить, когда знает, что подставляется в sin?
Не отделять скобки скоупа пробелами - ересь.
Боюсь представить, как с ума сойдет Intellisense, если все функции и объекты из, скажем, STL, свалить в одно пространство имен. А уж как пользователю будет удобно в таком выпадающем списке что-то искать… Такая стратегия работает, только если в языке максимум пара десятков встроенных функций, и никакого реального способа расширения возможностей.
То, что какой-то пример на языке выполняется в пару строчек, не значит, что язык не похож на ассемблер/прост в изучении. На Haskell, к примеру, факториал можно посчитать как product [1..N]. Безо всяких предварительных ласк. Будем, поди, считать, что он еще больше подходит начинающим?
Мне вот на первом курсе выносили мозг функции, которые читают из стандартного потока массивы без указания разделителя. И сейчас выносят.
Честно говоря, мне, как начинающему, было значительно проще запомнить, что read(X) всегда считает данные любого примитивного типа в нужную мне переменную из стандартного потока, вплоть до первого whitespace-символа, а чтение начнется после символа перевода строки, чем запомнить все эти readReal, readInteger, readRealArr, realIntegerArr, readOtherCrap, которые вместо навыков использования универсальных средств для достижения разных целей [то,что действительно требуется программисту для будущей работы] прививают навыки зазубривания функций стандартной библиотеки, дублирующих друг друга с точностью до типа переменной. Затем тут же вводится понятие обобщенных функций и классов, которые разом доказывают, почему это - глупо.
Простите, разработчики PABC.NET. Всегда считал, что это - лишнее в языке. А тут на хвост наступили
Как насчет, к примеру, переделать это по типу read(), readArr? Выглядеть будет поопрятней. А вышеупомянутый пример сократится до begin Write(sin(read)) end. за счет автовыведения типа.
Ну посмотрите хотя бы дотнетовский класс BinaryReader. Там тоже есть ReadInt32, ReadDouble. Названия говорят сами за себя. И не надо там ничего зазубривать. В крайнем случае интеллисенс подскажет.
А не надо демонстрировать “я тут такой умный, мне все умолчания пофигу” - и будет нормально. ReadReal и ReadInteger принимают с клавиатуры одно числовое значение. Да, это сахар. Кому не нравится - пишет
Read(x);```
вместо
```var x:=ReadInteger;```
Объяснить второе начинающему проще и быстрее, чем первое. Возможно, Вы - вундеркинд и Вам надо было "с горшка" давать C++, но поверьте, у меня полярных примеров куда больше.
[quote="JediKnight, post:332, topic:143"]
Синусу надо отдать число в радианах. вводить с клавиатуры радианы - вводить что-то без перевода в них - глупость.
[/quote]
Хех, нашли к чему придраться... ну давайте напишем Write(Sin(DegToRad(ReadReal)))
[quote="JediKnight, post:332, topic:143"]
Не отделять скобки скоупа пробелами - ересь.
[/quote]
Не выдавайте за абсолют свое частное мнение. Кроме того, использование слова "ересь" вне устной речи - проявление чудовищной безграмотности.
[quote="JediKnight, post:332, topic:143"]
Боюсь представить, как с ума сойдет Intellisense,
[/quote]
А Вы не бойтесь. В PascalABC.NET не сходит же. Intellisence - это контекстнозависимое средство, если что. Конечно, на дебильной С++ объектной модели ему будет потяжелее, но справится.
[quote="JediKnight, post:332, topic:143"]
То, что какой-то пример на языке выполняется в пару строчек, не значит, что язык не похож на ассемблер/прост в изучении.
[/quote]
Не значит. Но если помните, что писали разработчики, задумка языка была в том, что большинство задачек решать в несколько строчек, возможно, даже в одну. Вы забываете, что у этого языка своя ниша и упорно сравниваете его с С-подобными языками, ориентированными, в первую очередь, на системное программирование и в самую последнюю - на обучение.
[quote="JediKnight, post:332, topic:143"]
мне, как начинающему, было значительно проще запомнить, что read(X) всегда считает данные любого примитивного типа в нужную мне переменную из стандартного потока, вплоть до первого whitespace-символа, а чтение начнется после символа перевода строки,
[/quote]
Вы, как начинающий, даже слов таких не знали вначале... "Не надо маленьких дурить!" (с)
@JediKnight
ReadlnReal скорее не для новичков а для любителей, когда изучил основы языка, это даёт возможность протестировать мелочь не создавая программу на 500 строчек.
С другой стороны да, в других случаях это бесполезное нагромождение, и лишнее только мешает найти то что ищешь.
@ibondBinaryReader считывает не как read, а как говорит его название. Если бы у него не было этих функций - пришлось бы преобразовывать поинтерами или ещё как извращаться чтоб считать и записать число с плавающей запятой по байтам. У остальных Reader-ов в System.IO есть только функция read которая считывает integer или массив char. Функции как ReadlnReal нужны когда цель не эффективность, а простота при написании, но они полезны исключительно в таких случаях. Иначе получится как в джаве: “джава не эффективный по производительности язык” - говорят те кто используют его возможности по экономии на коде по максимуму.
BinaryReader - то, чему бы такой метод read() бы не разу не помешал - просто компилятору стоило бы определять, в переменную какого типа считываются данные. Не считаю достаточным аргументом. Правило “Если оно есть в до-диезе - значит, оно - истина” некорректно. Мне вот кажется, что этот язык настолько зафлужен различными фичами, сахаром, фреймворками, что ни один программист во всем мире неспособен успевать за новыми редакциями языка и студии. Хотя, в случае BinaryReader оно более-менее оправдано: если уж компилятор неспособен определить требуемый тип, то кто-то должен сообщить, как интерпретировать бинарные данные.
Вообще, есть у меня мысль, что повальное пожелание использовать var/auto и им подобных для автовыведения типа в левой части выражения крайне преувеличено в своем значении. Почему не наоборот, с использованием автовыведения типа шаблона [суть - активно использовать контекст для принятия решения о том, что же мы возвращаем. То, о чем я тут рассказываю с самого начала]? Ведь как же было бы прекрасно увидеть что-то в этом духе (синтаксис в стиле С++, но суть видна так или иначе):
Поступать тут можно двумя путями. Первый - требовать явной реализации read для типа, второй - выполнять reinterpret_cast на байты размером sizeof(T). count я бы сделал равным 1 по умолчанию, а возвращаемый тип - умеющий преобразовываться в initializer_list<T>, или же в T - в зависимости от контейнера-приемника.
Для всех вышеприведенных примеров я не вижу адекватного способа это сделать, кроме как пойти циклом по потоку. Можно еще readAllBytes() с BitConverter’ом - но это уже изврат.
2RAlex:
В ответ на мое упоминание языка Haskell и однострочный пример в нем вы мне говорите о моем сравнении PABC.NET с С-подобными языками? Прям не знаю, что и сказать… А вырывать фразы из контекста - нехорошо. А если фраза из контекста таки не вырвана - прошу погуглить, что же такое, этот хацкел… Хацкел для системного программирования… Мир рушится.
Меняем whitespace-символ на “пробел”, меняем “стандартный поток” на строку ввода, меняем “любой примитивный тип” на стандартные типы переменных в языке. Получаем то, что человек узнает на первом занятии.
Те, кому умолчания пофигу, и которые не беспокоятся особенно о том, как же оно внутри происходит, затем применяют std::sort к std::list, и удивляются, что же оно второй час сортируется… Задавать вопросы о том, как что-то работает - нормально, и отвечать приготовленными ответами вроде “а это не важно, там все нормально” - преступление со стороны учителя, убивающее у ученика какое-либо желание чем-то заниматься. Тот же вопрос с разделителем десятичным - вполне легитимный. Попишите .csv файл из практически любого современного языка, и обнаружите, что Excel его откроет некорректно, поскольку у него в локали запятые вместо точек. А как с этим побороться средствами языка? Это вот сейчас не важно, а если столкнулся бедный студентик/школьник?
Естественно, приведенный мной “анализ” вызова readReal гипертрофирован - например, вопрос о “константе/функции” можно выпиливать. Да и не только его. Только фраза “мне умолчания пофигу” намекает на то, что,по Вашему мнению, если учащийся не будет знать, как стрелять себе в ногу, то и выстрелить не сможет. К сожалению, жизнь показывает, что все не так просто.
Разве разработчикам паскаля (ABC.Net да и самому Вирту) не хотелось бы сделать свой язык программирования профессиональным (а он уже пригоден для коммерческих проектов)? Сравнение стремления рационализировать использование ресурсов с бортовым компьютером на мой взгляд некорректно. Например я пишу проект, коммерческий (игру, фоторедактор и т.п.), и хочу, чтобы он запускался вместе с ОС, а при нажатии клавиши, открывалось окно. Тут то эти “Зачем отключать PABCSystem” и “Это же всего лишь 20 кБ” будут серьёзной проблемой. Предложение Sun_Serega’и сделать директиву компилятора на отключение PABCSystem полностью поддерживаю и предлагаю разработчикам реализовать её.
Я не понял, Вы хотите при загрузке ОС повесить свою программу фоновым процессом, словно драйвер? А почему Вы считаете, что пользователи этого тоже захотят? Если ли гарантия, что вслед за желанием отключить PABCSystem не последует желаний отключить среду .NET, далее графическую оболочку Windows… ?
Поймите, я не против того, чтобы появлялись какие-то новые директивы, новые возможности… но хотелось бы после закрытия всех issues на GitHub, часть из которых висит уже более года.
Многие программы (в том числе и игры) находятся в автозапуске. Вас не пугает, например, антивирус или Проводник? Разумеется, если следовать вашей логике, это будет страшно. Если большинство программ писалось бы с таким подходом, компьютер до сих пор приветствовал бы вас зелёными буквами на чёрном фоне. На большее ему не хватило бы ресурсов! Отключение PABCSystem (именно добровольное отключение, а не удаление) будет большим шагом к тому, чтобы сделать Паскаль привлекательным для профессиональных программистов. Опять таки, не вижу смысла в модуле, в котором фактически хранится множество дубликатов одного и того-же (о чём уже говорили сверху). При этом всё его содержимое является загромождённым отражением возможностей платформы .NET. Не более того. Если Вам просто не хотелось бы видеть Паскаль профессиональным языком, то это не значит, что этого не хотят другие.