Кроме того, что оно так же сокращает запись? Мне кажется, как минимум, тогда надо сделать, чтобы inc и dec “возвращали” значения. К примеру в C++ я часто использую примерно такое:
ar[n++] = ...;
вместо Pascal’евского:
ar[n] := ...;
inc(n);
Манера возвращать значения по любому поводу - это “сишная” манера, она не присуща Паскалю. У меня уже начинает складываться ощущение, что Вы все время пытаетесь нормальный паскалевский синтаксис превратить в сишную мешанину, - в то самое, почему в школах С-образные языки изучать противопоказано. Ну нравится Вам С - и слава богу, пишите на нем! К чему все это “… в С++ я часто использую…” ? А я знаете сколько всего “часто использую” в других языках? Если бы возможность была все “хорошее” в одном языке собрать, его бы уже давно написали и все на нем работали. Одно дело - сказать, что не хватает какого-то механизма в языке, каких-то возможностей, и уж совсем другое - предлагать вводить параллельные средства для оперирования уже имеющимся в языке, только записанном иначе.
Вы абсолютно не правы. Языки программирования, как и обычные, подвержены взаимоассимиляции. Это логичный этап в развитии. Рано или поздно останется один основной язык, включающий в себя все лучшее от предыдущих. За это мне и нравится эта среда(ABC .NET) - она уже объединяет многое из других языков. “Если бы возможность была все “хорошее” в одном языке собрать, его бы уже давно написали…” - вообще-то так и создаются “новые” языки программирования. Объединяют все лучшее от предшественников и вводят свое, пока и их не заменят на что-то другое. И да, я не предлагаю вводить параллельные средства, а предлагаю вообще заменить их. Как уже здесь обсуждалось просто добавить возможность включать поддержку старых версий.
1 лайк
Нет. Но Inc использовать не надо. Следует использовать
a += 1
А да, еще одна отличная конструкция которой не было в оригинальном Паскале, за что вам большое спасибо. Я почему спрашивал-то о СИшных инкременте и декременте, их можно использовать как сдвоенную операцию:
ar[n++] = ...
Как бы и значение n получили и увеличили его на единицу.
По своему двухлетнему опыту разработки на Java могу сказать - такая вот вложенность действий “я же могу зато тыщу дел сразу в одной строке сделать” позволяет потом получить незабываемые впечатления при отладке, если в этой одной строке что-то пошло не так. Возможно в C/С++ c этим проще, но в java уж как есть. возможно в этих сдвоенных строенных и так далее операциях и есть плюсы, но мне при их виде хочется громко кричать НУ_ПОЖАЛУЙСТА_НЕ_НАДО. Однозначно не рекомендую вкладывать операции, так стоит делать только если у вас в голове интерпретатор правильной версии рассматриваемого языка установлен и вы там можете программу запустить.
В принципе согласен. Отладку вложенные действия усложняют, хотя и не так уж сильно. Строку найти будет не сложно в любом случае, а уж ее можно будет и разбить для дебага. Вообще, меня этот вопрос заинтересовал по той простой причине, что при переносе кода с C# на Pascal я встретил как раз такую операцию, где переменную, используемую в качестве индекса массива еще и увеличили мимоходом. Хотелось перенести код, чтобы он как можно более сильно походил визуально на оригинальный C#, но inc не возвращает значения переменной. Не критично, короче это все, скорее очередной заскок перфекционизма.
Да, вот в IDE PascalABC.NET отладчик не пооператорный, а построчный. И при “синдроме одной строки” по F8 проделывается такая чертова уйма вещей, что и не отследить. И бьешь строку “по точкам” на отдельные…
Ну мы вот на работе пользуемся JDeveloper для разработки, логгер стандартный, если что-то где-то упало - лезешь в логи, смотришь - ага, вот такая строчка, Nullpointer например. Лезешь в код, а там в этой строчке восьмикилометровый монстр с “точками” в котором помимо пары основных запросов к базе уйма подзапросов и граничных проверок на полсотни переменных почти, и Null может быть где угодно. А на масштабный рефакторинг времени нет, приходится пока переделывать тоько там где оно сейчас упало.
В новой версии появились мягкие срезы вида a?[1:8:2] без контроля выхода за границы. Напоминаю, что срезы работают для массивов, списков и строк
1 лайк
Бог ты мой, майн готт, май год, матка боска… Сбылось!!!
begin
var s:='1234567890';
Writeln(s?[-3:20])
end.
Это очень правильное решение. Если пользователь сильно хочет прострелить себе ногу, не надо ему категорически мешать. Пусть ставит знак вопроса… )))) Если без шуток - часто надо бывает, чтобы не контролировалась граница и это означало “пока не закончатся данные”.
А по версии образовалась потребность с матрицами. Есть у школьников целый класс задач на двумерные массивы. В большинстве своем он сводится к “найти” или “найти и заменить”. Найти просят либо значение, либо местоположение (значение в последнем случае при необходимости легко выдается по местоположению). Находить нужно максимумы, минимумы, а также значения, удовлетворяющие некоему предикату. При этом значение может быть одно, может быть и не одно. Ах да, еще бывает ввод элементов матрицы с клавиатуры…
Конечно, традиционные циклы позволяют просто и понятно все эти проблемы решать. Но уж если функциональное программирование - так пусть оно таковым остается до конца. При поиске одного (первого встреченного) значения я сейчас поступаю так:
// PascalABC.NET 3.2, сборка 1374 от 10.01.2017
// Внимание! Если программа не работает, обновите версию!
begin
var m:=ReadInteger('Количество строк в массиве:');
var n:=ReadInteger('Количество столбцов в массиве:');
Writeln('*** Исходный массив [',m,',',n,'] ***');
var a:=MatrRandom(m,n,-50,50);
a.Println(4); Writeln(4*a.ColCount*'-');
var b:=a.Rows.SelectMany(x->x).ToArray; // в одномерный построчно
b. // вот тут у Intellisence "крыша отъезжает"
// и получить после точки подсказку невозможно.
// ну да не суть, все же текст приведу ниже полностью
end.
Преодолевая упорное молчание Intellisence, все же набираю текст до конца:
// PascalABC.NET 3.2, сборка 1374 от 10.01.2017
// Внимание! Если программа не работает, обновите версию!
begin
var m:=ReadInteger('Количество строк в массиве:');
var n:=ReadInteger('Количество столбцов в массиве:');
Writeln('*** Исходный массив [',m,',',n,'] ***');
var a:=MatrRandom(m,n,-50,50);
a.Println(4); Writeln(4*a.ColCount*'-');
var b:=a.Rows.SelectMany(x->x).ToArray; // в одномерный построчно
var icond:=b.FindIndex(x->x>40); // собственно, условие поиска
var i:=icond div n; // строка
var j:=icond mod n; // столбец
Writeln('a[',i+1,',',j+1,']=',a[i,j])
end.
Количество строк в массиве: 4
Количество столбцов в массиве: 7
*** Исходный массив [4,7] ***
-33 -30 -13 -48 8 -47 -50
34 43 -9 -8 -25 -12 28
38 -36 34 -7 -36 -45 23
4 -45 1 36 -16 50 4
----------------------------
a[2,2]=43
Хочется иметь функцию преобразования между одномерным и двумерным массивом, хочется уметь “рассыпать” двумерный массив в список <значение><строка><столбец> и наоборот, собирать из такого списка двумерный массив. Клавиатурный ввод хочется, типа MatrReadInteger. Ну и поиски, чтобы потом можно по их результатам замену делать, т.е. поиск должен возвращать опять же кортеж <значение><строка><столбец>
Вот такие хотелки…
Олимпиады по информатике в Москве, 2016/17 учебный год (https://olympiads.ru/moscow/2016-17/soft.shtml)
“Оптимальный” перечень сред разработки PascalABC.Net Code::Blocks с компилятором MinGW gcc/g++ Python 3.4 и среда Wing IDE 101 5.1.12
PascalABC.NET Сайт: pascalabc.net Версия: 3.2 Источник для установки: http://pascalabc.net/ssyilki-dlya-skachivaniya
“Процесс пошел” ?
1 лайк
Прочитал ветвь дискуссии до этого места. В начале, как частный преподаватель который готовит учеников к ЕГЭ горячо поддерживал RAlex’а. Аргументы приведенные в вашей презентации рациональны. Среда действительно популярная, красивая, удобная, компактная. Успехи, достигнутые вами в завоевании ниши школьного обучения велики, но могут быть потеряны если среда станет непригодной для подготовки к ЕГЭ. Может быть for var i:= это то чем следует пожертвовать хотя бы на некоторое время ради сохранения совместимости.
Вот тут уже я не понял. Да, я возражал, но лишь против того, чтобы конструкция for var i:= была СИНТАКСИЧЕСКИ ОБЯЗАТЕЛЬНОЙ. Сейчас речи об этом не идет - кто как хочет, тот так и пишет.
И по ЕГЭ. В методических материалах ФИПИ для комиссий в части информатики сказано, что при написании программы ученик может использовать любой язык программирования при условии указания его названия и требуемой версии, а также разрешено оформлять решение на естественном языке. Проблема проверки решения - это проблема комиссии. С учетом приведенного выше я не могу понять, каким образом ДОБАВОЧНЫЕ синтаксические конструкции PascalABC,NET могут даже хоть как-то повлиять на подготовку к ЕГЭ, не говоря о том, чтобы сделать среду “непригодной”. Разве только они добавят работы школьным учителям и репетиторам? “Но это уже совсем другая история…” (с)
Честно сказать, мы ничего особенного не делали - среда стала сильно популярной примерно 2 года назад - я это вижу по существенно возросшему количеству скачиваний. Но мы не ставили задачу обеспечить популярность среды.
А писать for i Вы по-прежнему можете - обратная совместимость со стандартным Паскалем есть.
А вот скажите как специалист по подготовке школьников: что будет, если школьник на ЕГЭ для вычисления суммы квадратов первых n чисел напишет так:
var s := Range(1,10).Sum(x->x*x);
?
Наверное зависит от конкретного проверяющего эксперта. Большинство из них без сомнения люди адекватные и вовсе не звери. К тому же, если стоит версия среды, то на апелляции в любом случае можно будет доказать корректность данной строки. Вот только вопрос, сколько учащихся захотят рисковать и делать сложнее, а потом выходить на апелляцию когда можно сделать проще по проверенной схеме.
Можно понять и проверяющего - он видит знакомое начало намекающее на паскаль, а потом что то для него новое. Не все хотят и не у всех есть силы учиться, особенно если это не приносит дохода. В жизни и так много места для работы и мало для отдыха, поэтому осваивать новые конструкции и возможности и прочее хочется далеко не всем.
По моему мнению в языке наблюдается как будто бы движение в сторону питона. Минус данной стратегии (говорю как человек который так или иначе писал много на чем включая паскаль, си, php, js, python) в том, что думаешь не над решением и оптимизации задачи а над тем как построить языковую конструкцию, что бы выглядело красиво да еще и работало правильно.
Кстати, по статистике за 2016 год число предложений о работе для питона снизилось а вот для “кандового” php существенно выросло (см. тут https://habrahabr.ru/company/hh/blog/318450/) . Так что красота строки и “всё в одном” зачастую усложняет вхождение и не всегда помогают в решении реальных задач. Тем более если говорить о школьниках у которых вхождение с нуля.
.Удобные штуки конечно приятны, например var a := ArrRandom(n);
1 лайк
А по-моему тут явное движение к С#, да и сами авторы этого не скрывают. Из Питона взято не так уж и много, основу все же дала библиотека .NET. Питон - это довольно неудачный язык: пропал один непечатаемый символ табуляции - и ты почти покойник. Чтобы на Питоне что-то реально можно было сделать, его поставили на немного иные рельсы (Ruby on Rails).
Красиво - это перфекционизм. Большое зло для программиста, работающего в коллективной упряжке. Его себе только “прима-балерины” могут позволить. Если, конечно, мы о реальной работе говорим на какого-то дядю, который нас содержит. А что плохого в том. чтобы коротко записать обращение к готовому методу? Да, надо кое к чему привыкнуть, но ведь и программировать в традиционных технологиях Вы тоже не за сутки научились. Что до “все в строку” - ну этого никто делать не заставляет. Позволяет синтаксис - и ладно. Кто может и хочет - пользуется.
Меньше года назад при слове “Паскаль” я начинал “шипеть и плеваться”. Как все поменялось… Надо только было заставить себя сломать стереотип.
Есть явное движение в сторону «Питона с типами». Для школьников это намного более полезно, чем просто Питон или старый Паскаль. Что бы там ни думали проверяющие ЕГЭ.
2 лайка
Институт математики, механики и компьютерных наук ЮФУ, 2005–2021