У меня есть знакомый дрктор физмат-наук, который (когда его спрашивают о том, как он вообще понимает математику?) говорит, что не понимает что там вообще сложного, так как в основе всего лежит четыре простых действия: +, -, *, /, а иногда даже цифры для удобства отбрасывают.
1 лайк
Мой любимый Dieselpunk!
Регулярные выражения изменили мою жизнь! Читаю книгу Джеффри Фридла…
Одумайтесь! Regex это то что используют, когда задачу надо лишь бы как решить. Он не эффективен и по скорости, и по памяти, и, особенно - по читаемости готового кода.
И чтоб его понять - надо не книги на 1.3к покупать, а потыкаться в каком то графическом редакторе. Сам этим пользовался когда учился: https://regexr.com
И усвоится быстрее, и врать никто в лицо не будет, со своей эффективностью…
Вы обо мне хорошо думаете…
Только-только начал погружаться в тему и тут на тебе! А какие ещё есть инструменты для работы с таблицами данных (сведение, разведение, сортировка и прочее)?
Хорошая ссылка. Спасибо.
Регулярные выражения - это только разборка символьной строки по совокупности некоторых правил. Не более того. Но ядро сделано на С/С++ (не знаю точно, на чем именно), поэтому при сложных правилах написать разборку даже схожей эффективности - это не для слабонервных.
Я пользуюсь вот этим ресурсом
Уникальный фильм! Как это удалось Карелу Земану сделать в эпоху, когда компьютерной графики не было в помине?
Regex это спецификация. Это значит что у него нет единого ядра, есть только правила реализации. Regex из .Net написан на .Net . То есть на C#.
И даже если бы он был написан на C++ - он слишком много всего пытается предусмотреть. Обычно методов строк .IndexOf, .SubString и .Remove - хватает с головой. И кода оказывается не на много больше. Зато на много читабельнее.
Из примеров - вот, к примеру, недавно писал:
А при чём тут вообще Regex? К примеру, если таблица в формате csv, что наиболее ожидаемо если вы писали это в текстовом файле:
begin
var lns := ReadLines('inp.csv.txt');
var table := lns.Select(l->l.Split(';').ConvertAll(v->v.Trim));
// сортируем по первому столбику
// а если значения первого одинаковые - по второму
table := table.OrderBy(l->l[0]).ThenBy(l->l[1]);
WriteLines('otp.csv.txt', table.Select(l->l.JoinToString('; ')));
end.
1 лайк
Уважаемые коллеги, после объяснения про лямбда-выражения, я не могу не спросить: В чём принципиальная разница между процедурой и функцией?
Почему вот это функция
function ReadAllText(path: string): string;
А вот это процедура?
procedure Reset(f: Text);
У функции есть возвращаемое значение, а у процедуры нет.
Ну, в наш век - процедуры прочти нигде не нужны. Обычно если функция не возвращает ничего нового, как методы .Print - она возвращает исходный объект, к которому была применена.
Это позволяет писать так:
begin
'abc'.Println.Substring(1).Println;
end.
Конечно, выражение 'abc' простое, но если бы оно было большим и сложным - факт что .Println возвращает строку, которую вывело - сильно сократил бы код. Обычно потому что не надо вводить дополнительную переменную.
Вот такой стиль кода, в виде башни вместо тонны отдельных строк и кучи переменных - называется функциональным программированием и является одним из самых современных и часто используемых стилей.
Типы Text/TextFile и file of T морально устарели, поэтому большинство туториалов предполагают использование не просто процедур, но ещё и глобальных подпрограмм вместо методов.
Мама дорогая…
И процедура и функция - это именованные действия с параметрами. Функция дополнительно может возвращать ОДНО значение так, что можно использовать вызов функции в выражении. Например:
var a := Корень(2) + Корень(3):
Просто человек в глубине души остался верен идеологии С/С++, где вместо процедур функция с void. Ну, Вы же помните: “Эллипс - это круг, вписанный в прямоугольник” 
Если они не лямбда-процедуры и не лямбда-функции, которые тоже действия с параметрами, только безымянные.
Не вырывайте из контекста. Конечно, если взять без остальной части параграфа - звучит странно.
Это не личное отношение, они не отвечают современным стандартам. О которых, опять же, говорилось в контексте.
Это откуда вообще взято? Хватит приписывать мне любовь к C# и C++.
Само разделение на procedure и function более читабельно, чем жуть из C# и C++, где у них общий синтаксис сразу и со свойствами и полями, лишь бы поменьше буковок ставить.
Я сказал только то, что в качественном коде процедурами будут только всякие внутренние вещи вроде Finalize. А в интерфейсе большинство вещей будут функциями. Если не возвращающими новое значение - возвращающими исходное.
Если язык не функциональный, то зачем, например, при выводе чего-либо возвращать это в качестве результата? Если я вращаю матрицу относительно ее диагонали на месте, зачем мне возвращать ее в качестве значения? Чтобы написать a := RotateDiag(a) ?
Чтобы написать:
a.RotateDiag
.RotateAnotherWay
.RotateAnotherWay2
.Println;
Ну, это самое простое что можно придумать.
С теми же лямбдами:
a->a.RotateDiag
Вместо:
a->
begin
RotateDiag(a);
Result := a;
end
Тут уже большая разница читабельности.
А вообще то, конкретно в данном примере - правильнее возвращать вообще новую матрицу. Это сделает невозможным совершить некоторые баги. В основном те, где в 2 разных местах имеется ссылка на общую матрицу, и изменение одной - неожиданно меняет другую.
Конечно, это всё не применяется к случаю, когда нужна заоблачная производительность. Но части кода, которые написаны по принципу “скорость > читабельность” - не должны попадать в интерфейс “как есть”. То есть это попадает под:
Я же ясно написал:
Ну как не функциональный, если на главной странице:
PascalABC.NET – мультипарадигменный язык. На нём можно писать программы в разных стилях: процедурном, объектном, объектно-ориентированном, функциональном, а также сочетать эти стили, что позволяет формировать различные образовательные траектории в зависимости от уровня и возраста обучаемых.
ИМО - написание в процедурном стиле в PascalABC.Net - это написание в стиле FreePascal, с небольшими вставками современного функционала. Что выглядит ещё уродливее, чем если писать на чистом FreePascal.
Вы сейчас себе же противоречите. Приводите цитату о мультипарадигменности, допускающей несколько стилей, из которых функциональный лишь один - и тут же спрашиваете “Ну как не функциональный”.
Речь о том, что если при программировании не используется функциональная парадигма, то обычно нужны и процедуры, и функции.
Не забываем о школьниках, хорошо?
Институт математики, механики и компьютерных наук ЮФУ, 2005–2021