.
Я программист не очень профессиональный, знаю только Delphi, но нашёл себе нишу, в которой востребована креативность. И создалось ощущение, что мой стиль программирования вообще относительно часто принят у дельфистов. Грубо говоря, под C++ написано много библиотек, а под Delphi мало, и это убивает Delphi; с другой стороны, Delphi в целом более правильный и удобный ЯП, позволяющий писать сложные алгоритмы с меньшим количеством ошибок. Отсюда предположение, что сишниками становятся программисты, которым проще найти библиотеки, изучить документацию и так далее; а дельфистами становятся те, кому проще изобрести велосипед а не искать готовое. У меня это выражено в крайней степени.
"Ты должен сделать добро из зла, потому что его больше не из чего сделать". АБ Стругацкие.
Здравствуйте, Khimik, Вы писали: K>Я программист не очень профессиональный, знаю только Delphi, но нашёл себе нишу, в которой востребована креативность. И создалось ощущение, что мой стиль программирования вообще относительно часто принят у дельфистов. Грубо говоря, под C++ написано много библиотек, а под Delphi мало, и это убивает Delphi; с другой стороны, Delphi в целом более правильный и удобный ЯП, позволяющий писать сложные алгоритмы с меньшим количеством ошибок. Отсюда предположение, что сишниками становятся программисты, которым проще найти библиотеки, изучить документацию и так далее; а дельфистами становятся те, кому проще изобрести велосипед а не искать готовое. У меня это выражено в крайней степени.
Вы угадали с точностью до ровно наоборот.
Популярность Delphi исторически была связана с тем, что это не просто Object Pascal, а RAD-среда, которая оптимизирована для быстрого создания виндового UI.
Поэтому за время, которое нужно было C++ программисту для компиляции сэмпла "окно с тремя табами", Delphi-программист нашлёпывал форму с табами, меню, датагридом и привязкой к базе на Paradox, и успевал всё это запустить.
При этом минимальные изменения типа "а давайте мы контент с табов 'Настройки' и 'Предпочтения' перенесём на один таб 'Опции', и расположим в виде двух окошек со сплиттером между ними" могли программиста на Watcom C++ занять на неделю, а на Delphi делались за несколько минут.
Характерным отличием Delphi от основного конкурента — VB с его ActiveX-компонентами — было то, что компоненты Delphi писались на том же Delphi. Программисту на VB, который упёрся в ограничения компонента ActiveX, ничего не оставалось сделать, как признать задачу неразрешимой. Ну, либо осваивать целиком совершенно другой язык и среду разработки, чтобы навелосипедить свой собственный ActiveX.
В теории, такое отличие Delphi должно было стимулировать "формошлёпов" осваивать компонентостроение и писать переиспользуемый код. Тем более, что вся VCL поставлялась в исходниках, и при желании можно было в отладчике пошагово посмотреть, как работает любой из коробочных компонентов.
Однако на практике невыносимая лёгкость формошлёпства привела к тому, что подавляющее большинство Delphi-программистов и знать не хотели, как там оно устроено под капотом. Как тут по соседству написали: есть компонент — есть решение, нет компонента — нет решения.
Исключения из этого, конечно, же, случались (а иначе кто бы написал все эти 100500 библиотек компонентов в дополнение к стандартной палитре), но статистически они были совершенно незначимы.
Далее, выбор Хейльсбергом Object Pascal в качестве языка сыграл с пользователями Delphi дурную шутку. Паскаль сам по себе прекрасно подходит для изучения алгоритмов; а вот писать на нём повторно используемые алгоритмы практически невозможно. Отсутствие обобщённых типов и перегрузки операторов приводило к тому, что алгоритм сортировки писал себе примерно каждый (либо сводил всё к существующим решениям).
В целом, по сравнению с примерно любым современным языком, Delphi очень сильно мешает писать сложные алгоритмы с меньшим количеством ошибок. Тупо нет нужных средств декомпозиции алгоритмов.
В сочетании с RAD-особенностями это и привело к знаменитому качеству типичного дельфийского кода, где вся бизнес-логика написана в обработчиках типа Button1Click, а если есть два похожих сценария — то один из другого сделан просто копипастой с заменой пары строчек.
Альтернативные языки повышали порог вхождения в индустрию. С одной стороны, это затрудняло написание приложений (особенно если приложение по природе своей — это фронт-енд к какой-нибудь реляционке); с другой стороны, "нашлёпанные" без понимания сути вещей приложения просто не взлетали. Да, в до-MFC-шную эпоху виндовое приложение на С++ должно было вручную выгребать сообщения из очереди; с другой стороны — автор такого приложения был вынужден знать матчасть и понимать, как именно два клика превращаются в двойной клик.
Поэтому там, где дельфийский программист на вопрос "а можно сделать, чтобы хелп показывался по тройному клику на кнопку?", уверенно отвечал "нет" (потому что у кнопки нет события OnTripleClick), плюсовый программист просто делал свою реализацию детектирования тройного клика.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, vsb, Вы писали:
vsb>И в Go до недавнего времени и в Java до 5 версии не было генериков. И ничего — через interface{} / Object прекрасно все алгоритмы писались.
Просто Go не предназначен для алгоритмов. Не предназначен — и всё. И про "прекрасно" на Java можете мне не рассказывать. Там вся прекрасность связана с тем, что "нуачо вы хотели, это же Java. Если хотите перформанс — берите плюсы".
vsb>Я больше скажу — ни в Go, ни в Java у меня не было никакой необходимости писать какие-то обобщённые алгоритмы.
Отож. Ни одному паскалисту и в голову не придёт жаловаться на отсутствие замыканий, ФВП, или там генериков.
А вот у меня во времена оные потребность в коллекциях была. И мы честно пилили хешмапу int->TObject и string->TObject путём копипейста.
vsb>И я даже ещё больше скажу. Крамольную вещь. Те, кто любят писать обобщённые алгоритмы, как правило, тратят время впустую на ментальную гимнастику вместо того, чтобы решать проблемы.
Категорически с вами не согласен. Любители писать обобщённые алгоритмы вкладывают своё время в написание обобщённых алгоритмов.
Благодаря этому потребители потом могут просто взять готовый алгоритм и начать его использовать. Если язык не позволяет написать обобщённый алгоритм, то его никто так и не напишет.
Вот, Khimik до сих пор учится сортировать массивы чисел с плавающей запятой — потому, что в классическом до-дженериковом Delphi нет никакого способа отсортировать такой массив.
vsb>По остальным пунктам в целом согласен, но главная проблема Delphi это то, что её не смогли адекватно развивать. Уж не знаю, кто конкретно был в этом виноват, но если бы за Delphi стоял Microsoft с нормальным финансированием, а не какие-то неизвестные компании, пытающиеся урвать хоть что-то перед очередной перепродажей, если бы тот же Хейлсберг её продолжал развивать, скорей всего с ней всё было бы хорошо.
Основная проблема Delphi — падение спроса, сокращение выручки, банкротство компании. Финал.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Khimik, Вы писали:
K>Я программист не очень профессиональный...
Я сам не очень профессиональный, но большинство знакомых мне языков (думаю, с десяток наберется) в своей базе позволяют реализовать практически любые свои алгоритмические фантазии примерно с одинаковым количеством ошибок. Просто где-то писанины больше, где-то меньше. Делфи (ну и билдер, конечно тоже) прекрасный язык и платформа (были лет 20 назад точно, сейчас — хз) и прекрасно интегрируется с сишными либами через DLL.
. K>Я программист не очень профессиональный, знаю только Delphi, но нашёл себе нишу, в которой востребована креативность.
Не забываем подчеркнуть свою исключительность
K>И создалось ощущение, что мой стиль программирования вообще относительно часто принят у дельфистов.
Да-да, это не я пишу говнокод, это просто так принято
K>Грубо говоря, под C++ написано много библиотек, а под Delphi мало, и это убивает Delphi;
Потому что у Дельфи язык — говно
K>с другой стороны, Delphi в целом более правильный и удобный ЯП, позволяющий писать сложные алгоритмы с меньшим количеством ошибок.
То-то ты сортировку который день сделать не можешь
K>Отсюда предположение, что сишниками становятся программисты, которым проще найти библиотеки, изучить документацию и так далее; а дельфистами становятся те, кому проще изобрести велосипед а не искать готовое.
Репрезентативная выборка из одного человека. Можно начинать делать вселенского масштаба выводы.
На самом деле это конечно же не так.
Когда я работал на Дельфях, стандартный алгоритм решения проблемы у коллег был такой: 1) Ищем родной компонент для решения проблемы. Если компонент найден, проблема решена. 2) Ищем сторонний компонент для решения проблемы. Если компонент найден, проблема решена. 3) Компонент не найден — проблема не имеет решения.
Сишники и плюсовики как раз не любят искать готовое и читать документацию. Именно поэтому для C/C++ так много библиотек. Да вот тот же Линукс родился потому, что человеку не хотелось готового.
K>У меня это выражено в крайней степени.
Да, ещё раз не забываем подчеркнуть свою исключительность. Не то, что всякое сишное быдло, которое даже в "научные" разделы форума не заглядывает.
Здравствуйте, Sinclair, Вы писали:
S>На более-менее любом современном языке это будет весьма простой генератор/итератор, за которым .filter(...).map(...).reduce(...).
Это называется "библиотечная поддержка".
За этими filter/map/reduce кто-то попердолился и скрываются кучи кода.
А уж написать это в строку или в столбик значения не имеет.
Здравствуйте, Sinclair, Вы писали:
S> Далее, выбор Хейльсбергом Object Pascal в качестве языка сыграл с пользователями Delphi дурную шутку. Паскаль сам по себе прекрасно подходит для изучения алгоритмов; а вот писать на нём повторно используемые алгоритмы практически невозможно. Отсутствие обобщённых типов и перегрузки операторов приводило к тому, что алгоритм сортировки писал себе примерно каждый (либо сводил всё к существующим решениям).
Это, конечно, глупость несусветная. Особенно про перегрузку операторов (запахло костыльным дженерик-мафом ). Например, дженерики появились в дельфях всего на три года позже, чем в шарпе. А во времена турбовижн алгоритмы кастомизировались — та-да-м — процедурными типами!
S> В целом, по сравнению с примерно любым современным языком, Delphi очень сильно мешает писать сложные алгоритмы с меньшим количеством ошибок. Тупо нет нужных средств декомпозиции алгоритмов.
S> В сочетании с RAD-особенностями это и привело к знаменитому качеству типичного дельфийского кода, где вся бизнес-логика написана в обработчиках типа Button1Click
Штука втом, что это поведение демонстрируют все человеческие особи у которых такая возможность есть, независимо от используемого языка. Просто потому что могут (да, как тот кот, что яйца лижет). И ленивы. И шарписты так фигачат с винформсами и сисиплюсники с кутей и жабщики, когда пилят под ведро (только там это все усугубляется еще ручной работой). В общем, ха. Три раза.
Короче. Самым убойным аргументом против паскаля является... У них там begin/end!
Здравствуйте, пффф, Вы писали:
п> K>Грубо говоря, под C++ написано много библиотек, а под Delphi мало, и это убивает Delphi;
п> Потому что у Дельфи язык — говно
Только Марти мог пи3дануть такую #уйню. Спалился, окончательно. Реверс, это точно он!
Здравствуйте, SergeyIT, Вы писали:
П>>Я работал и решал задачи, а коллеги искали компоненты.
SIT>Ну прям про студентов нынешних (не всех). SIT>А кто создавал компоненты? У вас таких не было?
Компоненты у нас не создавали.
Нетривиальные задачи решал я на плюсах (в C++ билдере, чтобы остальным можно было пользоваться).
SIT>ЗЫ SIT>Многое, конечно, зависит от задач.
И от дельфистов. В основной массе это просто формошлёпы
SIT>Когда-то работал с Дельфи, решал задачи, искал копоненты редко, создавал свои... В одной фирме был едиственным Дельфи разработчиком (из 20-50 программистов на С++). Не помню, чтобы находили баги в моих прогах, SIT>(кроме 1 случая — в окне один контрол на 1 пиксел сдвинут оказался)
Никто не говорит, что на Дельфях можно делать хорошие вещи. Вопрос в том, сколько людей могут это.
SIT>И по прошлому опыту — не вижу особой разницы на чем писать на Паскале или С++. Перейдя на линукс, использовал как Лазарус, так и QTCreator.
Дельфи как система — очень хороша была. Тут спору нет. А вот язык, который был взят там за базу — Паскаль — полный отстой. Да, на нём можно тоже что-то делать. Ценой невероятных усилий, по сравнению с плюсами.
Здравствуйте, Sinclair, Вы писали:
R>> S>Возможно, на современном Delphi ситуация как-то поменялась; в том, который был актуален во времена расцвета его популярности, всё это суровая правда.
Чуть лучше, чем в условном Delphi7. Но всё равно плохо. 2 главные проблемы
1)
Нет аналога yield return. Итераторы откровенно задолбаешся писать.
2) очень громоздкий синтаксис анонимных функций.
Delphi
Positions.Sum(function (APos: TSmetaPosition): Currency begin Result := APos.Price; end)
vs
C#
Positions.Sum(pos => pos.Price)
Еще нет аналогов extension методов для интерфейсов/дженерик типов (хотя например для НЕ дженерик классов есть). Но это хоть криво-косо но можно решить типами-обертками
Здравствуйте, Sinclair, Вы писали:
S>Далее, выбор Хейльсбергом Object Pascal в качестве языка сыграл с пользователями Delphi дурную шутку. Паскаль сам по себе прекрасно подходит для изучения алгоритмов; а вот писать на нём повторно используемые алгоритмы практически невозможно. Отсутствие обобщённых типов и перегрузки операторов приводило к тому, что алгоритм сортировки писал себе примерно каждый (либо сводил всё к существующим решениям). S>В целом, по сравнению с примерно любым современным языком, Delphi очень сильно мешает писать сложные алгоритмы с меньшим количеством ошибок. Тупо нет нужных средств декомпозиции алгоритмов.
И в Go до недавнего времени и в Java до 5 версии не было генериков. И ничего — через interface{} / Object прекрасно все алгоритмы писались.
Я больше скажу — ни в Go, ни в Java у меня не было никакой необходимости писать какие-то обобщённые алгоритмы.
И я даже ещё больше скажу. Крамольную вещь. Те, кто любят писать обобщённые алгоритмы, как правило, тратят время впустую на ментальную гимнастику вместо того, чтобы решать проблемы. Поэтому ругать конкретно Pascal считаю некорректным. Нормальный язык, никак не ограничивающий программиста. И во многих отношениях на порядок лучше того же С++.
По остальным пунктам в целом согласен, но главная проблема Delphi это то, что её не смогли адекватно развивать. Уж не знаю, кто конкретно был в этом виноват, но если бы за Delphi стоял Microsoft с нормальным финансированием, а не какие-то неизвестные компании, пытающиеся урвать хоть что-то перед очередной перепродажей, если бы тот же Хейлсберг её продолжал развивать, скорей всего с ней всё было бы хорошо.
Здравствуйте, Sinclair, Вы писали: S>Здравствуйте, rudzuk, Вы писали: R>>Это, конечно, глупость несусветная. Особенно про перегрузку операторов (запахло костыльным дженерик-мафом ). S>При чём тут женерик-маф? Я на Delphi оттрубил своё по полной программе, так что пишу с полной ответственностью. S>Банально никаких коллекций на Delpgi не было, кроме TList. S>Сделать простую штуку типа "отсортировать список по пользовательскому критерию" — боль, ужас, унижение.
тут жопа только в бестолковом примере, писанном кем — то не знающим языка.
Нужно применять адекватные классы, в данном случае есть класс TStringList, любимый формоклепателями.
Там сортировка вызывается 1 строчкой.
Это если говорить о додженериковом языке. S>Ага. Расскажите мне, во сколько строк кода запишется на Object Pascal какая-нибудь банальщина типа "обойти граф, заданный моей объектной моделью, в глубину, отфильтровав по параметру, частично заданному пользователем, и собрать некую агрегатную величину". Ну там — берём AST программы, ищем узлы-референсы, заимпортированные из модуля X, для них считаем сумму условной вычислительной сложности.
типа такого (код из нашего комплекса)?
class function TMatchAPI.outside(aNB: TNB; aMode: TOutsideMode): RArray<TNB>;
var
lCEs: RArray<TCE>;
lRules: TCEFetchRules;
begin
Result := RArray<TNB>.init;
if TCEAPI.globalId(aNB) <> '' then
begin
Result.add(aNB);
exit;
end;
lRules.init;
lRules := lRules +
TCERules.reducerExtraTerminals +
function(aTerminal: TCIMTopologyTerminal): TFetchAction
begin
Result := faContinue;
if isBreakObject(aTerminal.Element, aMode) then
Result := faBreakAndFetch;
end;
lRules := lRules +
function (aFrom: TCIMTopologyTerminal; var aTo: RArray<TCIMTopologyTerminal>): Boolean
var
lNewTo: RArray<TCIMTopologyTerminal>;
begin
Result := True;
lNewTo :=
aTo.filter(
function (aT: TCIMTopologyTerminal): Boolean
begin
Result := isBreakObject(aT.Element, aMode);
end
);
if lNewTo.count > 0 then
begin
aTo := lNewTo;
exit;
end;
lNewTo :=
aTo.filter(
function (aT: TCIMTopologyTerminal): Boolean
var
lCandle: TCE;
begin
lCandle := TCEAPI.candleLine(aT.Element);
Result := (lCandle <> nil) and (lCandle.terminalsS.map<TCE>(TCEAPI.connectedCE).count = 1) and isBreakObject(lCandle, aMode);
end
);
if lNewTo.count > 0 then
begin
aTo := lNewTo;
exit;
end;
end;
Result :=
TRStream<TNB>.just(aNB)
.map(TCEAPI.extractReducers)
.map<TCE>(TCEAPI.ce)
.map<TNB>(
procedure (aCE: TCE; var aMap: TProc<TNB>)
begin
TCEAPI.iterateTopology(aCE, lRules)
.map<TNB>(
procedure (aCE: TCE; var aMap: TProc<TNB>)
var
lNB: TNB;
begin
if aCe.IsChildOrEqual(ttcTransformerWinding) then
lNB := TCEAPI.grpFromWinding(aCe as TTransformerWinding)
else
lNB := aCE;
if isNodeObject(aCE) and ((aMode = omNearest) or (TCEAPI.globalId(lNB) <> '')) then
aMap(lNB);
end)
.forEach(aMap);
end
)
.distinct()
.toArray();
end;
Ненавижу такое написание.
1. Не поддается отладке отладчиком.
2. сложно профилировать. сложно найти "бутылочное горлышко" производительности.
3. сложно рефакторить, сложно определяется на каждом этапе какая там структура данных на выходе.
4. нереально повторно использовать код, записать похожие алгоритмы.
5. перегружает компилятор. S>На более-менее любом современном языке это будет весьма простой генератор/итератор, за которым .filter(...).map(...).reduce(...). S>На Delphi остаётся только пердолиться с "процедурными типами" и/или Visitor Pattern. R>> S>Возможно, на современном Delphi ситуация как-то поменялась; в том, который был актуален во времена расцвета его популярности, всё это суровая правда.
S>Тут нужно учитывать, что Delphi (бесплатный) был распространён в бывших странах СССР. S>Но вот на западе где нужно было ещё и платить, его популярность была не высокой. S>Вот Хейлсберг сделал C# практически клоном из Delphi (кроме метаклассов). И его популярность одна из самых высоких, а развитие самое высокое.
да, денежный вопрос тоже имеет значение. Зачем платить за Delphi, когда MS бесплатно подобное раздает
Здравствуйте, swame, Вы писали:
s> тут жопа только в бестолковом примере, писанном кем — то не знающим языка. s> Нужно применять адекватные классы, в данном случае есть класс TStringList, любимый формоклепателями. s> Там сортировка вызывается 1 строчкой.
Неа. Речь шла о пользовательском критерие сортировки, а он может быть любым. Со стринглистом такое не прокатит, если метод сравнения не перекрыть.
...
s> Ненавижу такое написание.
+100500
s> 5. перегружает компилятор.
Проблема компилятора, если корректный код его перегружает Справедливости ради.
Здравствуйте, rudzuk, Вы писали:
R>Неа. Речь шла о пользовательском критерие сортировки, а он может быть любым. Со стринглистом такое не прокатит, если метод сравнения не перекрыть.
Ну и коллекции так-то бывают не только строк.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
S>class function TMatchAPI.outside(aNB: TNB; aMode: TOutsideMode): RArray<TNB>;
S>var
S> lCEs: RArray<TCE>;
S> lRules: TCEFetchRules;
S>begin
S> Result := RArray<TNB>.init;
S> if TCEAPI.globalId(aNB) <> '' then
S> begin
S> Result.add(aNB);
S> exit;
S> end;
S> lRules.init;
S> lRules := lRules +
S> TCERules.reducerExtraTerminals +
S> function(aTerminal: TCIMTopologyTerminal): TFetchAction
S> begin
S> Result := faContinue;
S> if isBreakObject(aTerminal.Element, aMode) then
S> Result := faBreakAndFetch;
S> end;
S> lRules := lRules +
S> function (aFrom: TCIMTopologyTerminal; var aTo: RArray<TCIMTopologyTerminal>): Boolean
S> var
S> lNewTo: RArray<TCIMTopologyTerminal>;
S> begin
S> Result := True;
S> lNewTo :=
S> aTo.filter(
S> function (aT: TCIMTopologyTerminal): Boolean
S> begin
S> Result := isBreakObject(aT.Element, aMode);
S> end
S> );
S> if lNewTo.count > 0 then
S> begin
S> aTo := lNewTo;
S> exit;
S> end;
S> lNewTo :=
S> aTo.filter(
S> function (aT: TCIMTopologyTerminal): Boolean
S> var
S> lCandle: TCE;
S> begin
S> lCandle := TCEAPI.candleLine(aT.Element);
S> Result := (lCandle <> nil) and (lCandle.terminalsS.map<TCE>(TCEAPI.connectedCE).count = 1) and isBreakObject(lCandle, aMode);
S> end
S> );
S> if lNewTo.count > 0 then
S> begin
S> aTo := lNewTo;
S> exit;
S> end;
S> end;
S> Result :=
S> TRStream<TNB>.just(aNB)
S> .map(TCEAPI.extractReducers)
S> .map<TCE>(TCEAPI.ce)
S> .map<TNB>(
S> procedure (aCE: TCE; var aMap: TProc<TNB>)
S> begin
S> TCEAPI.iterateTopology(aCE, lRules)
S> .map<TNB>(
S> procedure (aCE: TCE; var aMap: TProc<TNB>)
S> var
S> lNB: TNB;
S> begin
S> if aCe.IsChildOrEqual(ttcTransformerWinding) then
S> lNB := TCEAPI.grpFromWinding(aCe as TTransformerWinding)
S> else
S> lNB := aCE;
S> if isNodeObject(aCE) and ((aMode = omNearest) or (TCEAPI.globalId(lNB) <> '')) then
S> aMap(lNB);
S> end)
S> .forEach(aMap);
S> end
S> )
S> .distinct()
S> .toArray();
S>end;
S>
Да, что-то в этом роде. S>Ненавижу такое написание.
Ну, так видно же, что оно противоестественно для языка. S>1. Не поддается отладке отладчиком.
Значит, такой отладчик. На шарпе или там тайпскрипте всё прекрасно поддаётся. S>2. сложно профилировать. сложно найти "бутылочное горлышко" производительности.
Нет ничего сложного. Если профайлер вменяемый, то он покажет, какое из замыканий вызывается чрезмерно часто. Можно будет понять, как перейти от O(N2) к O(N) S>3. сложно рефакторить, сложно определяется на каждом этапе какая там структура данных на выходе.
Рефакторить как раз очень легко. Не очень понятно, что такое "структура данных". Если речь о типе элемента коллекции, то его хорошо видно по сигнатуре функции (и IDE подсказывает, где там что). Если речь про саму коллекцию — так их там и нет, это же ленивые итераторы. Если где-то нужно применить энергичность, то она делается вручную вставкой в конвеер операции типа .ToArray(), .ToList(), ToDictionary(...) или ещё какой-нибудь трансформации, которую можно придумать совершенно отдельно от вашего конкретного конвеера. S>4. нереально повторно использовать код, записать похожие алгоритмы.
Всё ровно наоборот. Если ваш код переписать на нормальный язык, то останется только существенная для понимания часть. А вся логика итерирования будет спрятана под капот.
Впрочем, для эксперимента можете переписать ваш же пример на "традиционный" Паскаль, безо всех этих новомодностей с генериками, .map, .filter и прочим.
Станет ли он дружелюбнее к рефакторингу и/или записи "похожих алгоритмов"? S>5. перегружает компилятор.
Это я оставлю на совести авторов компилятора. Тот же шарп или тайпскрипт компилируют код в функциональном стиле со скоростью мысли — то есть ничуть не медленнее Delphi. S>>На более-менее любом современном языке это будет весьма простой генератор/итератор, за которым .filter(...).map(...).reduce(...). S>>На Delphi остаётся только пердолиться с "процедурными типами" и/или Visitor Pattern. S>>Возможно, на современном Delphi ситуация как-то поменялась; в том, который был актуален во времена расцвета его популярности, всё это суровая правда.
Вижу, что на современном Delphi стало ещё хуже.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, akasoft, Вы писали:
S>>На более-менее любом современном языке это будет весьма простой генератор/итератор, за которым .filter(...).map(...).reduce(...). A>Это называется "библиотечная поддержка". A>За этими filter/map/reduce кто-то попердолился и скрываются кучи кода.
Там ещё скрывается проверка и вывод типов, лямбды и прочие монады.
A>А уж написать это в строку или в столбик значения не имеет.
Теоретически, совершенно верно. А как дело доходит до практики, то ВНЕЗАПНО:
1. Не поддается отладке отладчиком.
2. сложно профилировать. сложно найти "бутылочное горлышко" производительности.
3. сложно рефакторить, сложно определяется на каждом этапе какая там структура данных на выходе.
4. нереально повторно использовать код, записать похожие алгоритмы.
5. перегружает компилятор.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, rudzuk, Вы писали:
R>Здравствуйте, swame, Вы писали:
s>> И какой же ты сделал вывод о моем опыте?
R>А какой вывод я могу сделать, кроме того, что тебе больше ничего не требовалось? Такой и сделал.
s>> А тебе какие еще сортировки строк приходилось делать?
R>Например, сортировать игнорируя несколько первых или последних символов, по подстроке, короче.
ТО, где такое может понадобиться, как я себе представляю, я бы скорее распарсил эти строки в какие-то структуры по смыслу,
и сортировал бы уже структуры по нужным критериям. а это уже не сортировка строк.
Случай, где нужно сортировать такие строки в чистом виде, не представляю.
s>> Это не ты говорил. И он же начал про сортировку строк. Не я.
R>Sinclair говорил о сортировке по пользовательскому критерию, а не про сортировку строк. Если на пример посмотришь, то увидишь, что сортируются там не строки, хоть и по строкам
Обвинять язык на основе какого-то говнокода, который показывает как не надо делать, при том что есть несколько способов сделать это правильно, как-то странно.
Здравствуйте, пффф, Вы писали:
п> R>Представь себе... Имена файлов с расширениями, например.
п> Таки это лучше сначала на компоненты разобрать, а потом сортировать.
Не нужно мне ничего разбирать, ни на какие компоненты
п> Если при каждом сравнении извлекать часть, и потом её сравнивать, результат к пенсии получишь
Поэтому не нужно так делать Можно сравнивать ничего не извлекая.
Здравствуйте, пффф, Вы писали:
п> R>Даже если делать "в лоб" и искать от начала строки, то на миллион поисков по имени файла длинной 15 символов + точка + 3 символа на расширение затрачивается всего около 30 мсек. на древнем железе.
п> Надо искать не "в лоб", а с конца строки.
Ты умница. Внимательно читал. Жаль, что не все понял.
п> И надо ещё искать положение разделителя частей пути.
А кто сказал, что имя файла включает полный путь? Оставь свои выдумки.
п> Или файл будет какой-нибудь .tar.bz с двойным расширением.
А вот это уж вопрос интерпретации, что считать расширением. Потому что, например, файл system.sysutils.pas имеет одно расширение.
п> И теперь умножаем это на удвоенное количество сравнений при сортировке (удвоенное — потому что для обоих операндов надо искать). У твоих пользователей появляется реальный шанс не дожить до получения результата.
30 мсек. на 1млн. поисков самым неоптимальным способом. Але.
п> R>Если же подойти к вопросу творчески, сразу проверить FileName[Length(FileName) — 3] = '.' , и если это не точка то искать начиная с конца, то времени будет затрачено и того меньше.
п> Ха-ха, у тебя расширения имени файла всегда только трёхсимвольные?
864817 — общее количество файлов на моей рабочей винде.
520468 — количество файлов с трехсимвольным расширением.
Итого, 60% файлов имеют трехсимвольное расширение. Вот и подумай.
п> И да, ожидания не прематурные, а вполне реальные. Я делал много разных сортировок строк, в том числе и сортировка строк с учетом числовых значений в этих строках. И да, предварительное извлечение всей необходимой для сортировки информации очень сказывается на производительности.
Да нет, ты именно прематурщик в чистом виде. Напридумывал условий, сам с собой поспорил, сам себя убедил. Без цифр, без замеров, без ничего. И весь такой прошаренный, оптимальный весь. Это у сишников болезнь такая, я в курсе. А как до дела доходит, так начинается игра в догонялки в коричневых штанах
Здравствуйте, пффф, Вы писали:
п> R>Итого, 60% файлов имеют трехсимвольное расширение. Вот и подумай.
п> Выкинуть или неправильно обработать 40% исходных данных — это надо постараться
Что, читал, но у тебя не получилось? Пытайся еще. Старайся лучше.
п> R>Да нет, ты именно прематурщик в чистом виде. Напридумывал условий, сам с собой поспорил, сам себя убедил. Без цифр, без замеров, без ничего. И весь такой прошаренный, оптимальный весь. Это у сишников болезнь такая, я в курсе. А как до дела доходит, так начинается игра в догонялки в коричневых штанах
п> То-то на дельфях ваших ничего годного так и не написали в значимом количестве. У вас на реальных данных всё просто не работает. Ну, это конечно если вы не используете готовые компоненты. Компоненты обычно пишут люди достаточно квалифицированные. А вот то, что дельфисты пишут сами — это полный трешак.
На наших дельфях процессинги ОПСОСов работают, а ты иди утечки памяти ищи, оптимальный оптимизатор.
Здравствуйте, rudzuk, Вы писали:
R>Здравствуйте, Sinclair, Вы писали:
S>> Не вполне понятно, что будет написано в декларации. В комментарии упомянуто, что нужно придерживаться некоторой конвенции именования, но я не понимаю, какой. R>
R>TGAdvancedList = class(TGList)
R>
Ага, то есть там типа просто делается двойная подстановка, и они ожидают получить на выходе что-то типа
unit AdvancedListInteger;
interface
uses
Classes;
type
TAdvancedListIndex = Integer; // specified to some exact type
TAdvancedListItem = Integer; // specified to some exact type
TListIndex = TAdvancedListIndex;
TListItem = TAdvancedListItem;
// TGList<TListIndex, TListItem> = class
TGList = class
Items: array[TListIndex] of TListItem;
procedure Add(Item: TListItem);
end;
// TGAdvancedList<TAdvancedListIndex, TAdvancedListItem> = class(TGList)
TGAdvancedList = class(TGList)
Capacity: TAdvancedListIndex;
end;
// TAdvancedListInteger<Integer, Integer> = class
TAdvancedListInteger = class(TGAdvancedList)
// Additional fields and methods can be added hereend;
implementation
procedure TGList.Add(Item: TListItem);
begin
SetLength(Items, Length(Items) + 1);
Items[Length(Items) - 1] := Item;
end;
end.
R>Там еще ошибка с декларацией поля Items, которое объявлено статическим массивом, но задумано, как динамический.
Спасибо. Да, выглядит как относительно работоспособный трюк. Хотя и несколько, гм, неудобный в повседневном использовании. Ах, если бы вы показали его мне году эдак в 97м!
В принципе, идеального языка не придумали — в шарпе мы аналогичных обстоятельствах применяем T4. Ну, то есть конкретно такой код унижаться не заставляет, но если хочется сделать, скажем, набор типов-генериков, которые отличаются только количеством аргументов, то лучший споссоб — примерно тот же, что и ваш.
(Всякие interface IResult<T> { T[] GetResult()}, interface IResult<T1, T1> { (T1[], T2[]) GetResult()} и т.п)
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
. K>Я программист не очень профессиональный, знаю только Delphi
Это вообще не важно.
K> Грубо говоря, под C++ написано много библиотек
При желание их можно использовать из delphi
K>с другой стороны, Delphi в целом более правильный и удобный ЯП
К сожалению правильных и удобных нет. Везде есть компромиссы.
K>позволяющий писать сложные алгоритмы с меньшим количеством ошибок.
Ошибки можно делать даже не в алгоритмах, а в предположениях на которых строится алгоритм и от яп это никак не зависит.
K>Отсюда предположение, что сишниками становятся программисты, которым проще найти библиотеки, изучить документацию и так далее
Это вы еще js, python, perl, php, java,... не видели где есть огромные централизованные репозитории с библиотеками которые устанавливаются лёгким движением.
K>а дельфистами становятся те, кому проще изобрести велосипед а не искать готовое.
Что бы изобрести некоторые велосипеды надо иметь уровень знаний не доступный большинству программистов. Поэтому народ не заморачивается и встраивает библиотеки из fortran-а в python
Здравствуйте, SergeyIT, Вы писали:
П>>Когда я работал на Дельфях, стандартный алгоритм решения проблемы у коллег был такой...
SIT>Так ты работал или коллеги?
Я работал и решал задачи, а коллеги искали компоненты.
Здравствуйте, пффф, Вы писали:
П>Я работал и решал задачи, а коллеги искали компоненты.
Ну прям про студентов нынешних (не всех).
А кто создавал компоненты? У вас таких не было?
ЗЫ
Многое, конечно, зависит от задач.
Когда-то работал с Дельфи, решал задачи, искал копоненты редко, создавал свои... В одной фирме был едиственным Дельфи разработчиком (из 20-50 программистов на С++). Не помню, чтобы находили баги в моих прогах,
(кроме 1 случая — в окне один контрол на 1 пиксел сдвинут оказался)
И по прошлому опыту — не вижу особой разницы на чем писать на Паскале или С++. Перейдя на линукс, использовал как Лазарус, так и QTCreator.
Здравствуйте, rudzuk, Вы писали:
R>Это, конечно, глупость несусветная. Особенно про перегрузку операторов (запахло костыльным дженерик-мафом ).
При чём тут женерик-маф? Я на Delphi оттрубил своё по полной программе, так что пишу с полной ответственностью.
Банально никаких коллекций на Delpgi не было, кроме TList.
Сделать простую штуку типа "отсортировать список по пользовательскому критерию" — боль, ужас, унижение.
R>Например, дженерики появились в дельфях всего на три года позже, чем в шарпе.
И на 20 лет позже, чем в C++.
R>А во времена турбовижн алгоритмы кастомизировались — та-да-м — процедурными типами!
Ага. Расскажите мне, во сколько строк кода запишется на Object Pascal какая-нибудь банальщина типа "обойти граф, заданный моей объектной моделью, в глубину, отфильтровав по параметру, частично заданному пользователем, и собрать некую агрегатную величину". Ну там — берём AST программы, ищем узлы-референсы, заимпортированные из модуля X, для них считаем сумму условной вычислительной сложности.
На более-менее любом современном языке это будет весьма простой генератор/итератор, за которым .filter(...).map(...).reduce(...).
На Delphi остаётся только пердолиться с "процедурными типами" и/или Visitor Pattern.
R>
Возможно, на современном Delphi ситуация как-то поменялась; в том, который был актуален во времена расцвета его популярности, всё это суровая правда.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
S>Альтернативные языки повышали порог вхождения в индустрию. С одной стороны, это затрудняло написание приложений (особенно если приложение по природе своей — это фронт-енд к какой-нибудь реляционке); с другой стороны, "нашлёпанные" без понимания сути вещей приложения просто не взлетали. Да, в до-MFC-шную эпоху виндовое приложение на С++ должно было вручную выгребать сообщения из очереди; с другой стороны — автор такого приложения был вынужден знать матчасть и понимать, как именно два клика превращаются в двойной клик.
И как же? Я вот не знаю, как формируется WM_LBUTTONDBLCLK.
Это потому, что начинал с Дельфи?
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, T4r4sB, Вы писали: TB>И как же? Я вот не знаю, как формируется WM_LBUTTONDBLCLK.
Да очень просто. При каждом клике запоминается его место и время. И проверяется, что если предыдущий был в течение GetDoubleClickTime и внутри прямоугольника размером SM_CXDOUBLECLK and SM_CYDOUBLECLK относительно нынешнего, то в дополнение к WM_LBUTTONCLICK нужно сгенерировать WM_LBUTTONDBLCLK TB> Это потому, что начинал с Дельфи?
Возможно.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
vsb>>По остальным пунктам в целом согласен, но главная проблема Delphi это то, что её не смогли адекватно развивать. Уж не знаю, кто конкретно был в этом виноват, но если бы за Delphi стоял Microsoft с нормальным финансированием, а не какие-то неизвестные компании, пытающиеся урвать хоть что-то перед очередной перепродажей, если бы тот же Хейлсберг её продолжал развивать, скорей всего с ней всё было бы хорошо.
S>Основная проблема Delphi — падение спроса, сокращение выручки, банкротство компании. Финал.
Тут нужно учитывать, что Delphi (бесплатный) был распространён в бывших странах СССР.
Но вот на западе где нужно было ещё и платить, его популярность была не высокой.
Вот Хейлсберг сделал C# практически клоном из Delphi (кроме метаклассов). И его популярность одна из самых высоких, а развитие самое высокое.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Sinclair, Вы писали:
S> R>Это, конечно, глупость несусветная. Особенно про перегрузку операторов (запахло костыльным дженерик-мафом ).
S> При чём тут женерик-маф? Я на Delphi оттрубил своё по полной программе, так что пишу с полной ответственностью.
При том же, причем тут перегрузка операторов для обобщенного алгоритма сортировки
S> Банально никаких коллекций на Delpgi не было, кроме TList.
Не знаю, как и что ты оттрубил, но в Delphi был модуль Contnrs с коллекциями: стек, очередь, хэш-таблицы и др. Он точно был уже в Delphi 5 (возможно и раньше, но проверять лениво).
S> Сделать простую штуку типа "отсортировать список по пользовательскому критерию" — боль, ужас, унижение.
Это, как раз, пример использования процедурного типа. Хорошее решение. В дженериковых версиях все проще:
begin
var l := TList<string>.Create(['3', '2', '1']);
// default
l.Sort;
// custom
l.Sort(TComparer<string>.Construct(
function(const Left, Right : string) : Integer
begin
Result := CompareText(Left, Right);
end));
for var s in l do
WriteLn(s);
end.
S> R>Например, дженерики появились в дельфях всего на три года позже, чем в шарпе.
S> И на 20 лет позже, чем в C++.
Так Delphi и моложе плюсов, почти на двадцать...
S> Ага. Расскажите мне, во сколько строк кода запишется на Object Pascal какая-нибудь банальщина типа "обойти граф, заданный моей объектной моделью, в глубину, отфильтровав по параметру, частично заданному пользователем, и собрать некую агрегатную величину". Ну там — берём AST программы, ищем узлы-референсы, заимпортированные из модуля X, для них считаем сумму условной вычислительной сложности.
S> На более-менее любом современном языке это будет весьма простой генератор/итератор, за которым .filter(...).map(...).reduce(...). S> На Delphi остаётся только пердолиться с "процедурными типами" и/или Visitor Pattern.
На Delphi это делается ничуть не сложнее Энумераторы были еще в D2005.
Здравствуйте, rudzuk, Вы писали:
R>Так Delphi и моложе плюсов, почти на двадцать...
На 10. Или на пять, если за начало принять ТурбоПаскаль с ООП и TurboVision
Здравствуйте, pagid_, Вы писали:
p> R>Так Delphi и моложе плюсов, почти на двадцать...
p> На 10. Или на пять, если за начало принять ТурбоПаскаль с ООП и TurboVision
Точно. Чего-то с модулем вычислений случилось Ну ладно. Заместить шаблоны в паскале можно было включаемыми файлами {$include template.pas} (пример на fpc)
Здравствуйте, Serginio1, Вы писали:
S>Здравствуйте, Khimik, Вы писали:
S>Я бывший дельфист перешел и перешел на C#. С Учетом продвижения Native AOT то это полная замена.
И скоро AOT будет доступен для WinForms/WPF ?? Мы ж о замене дельфи говорим, то есть не про всякие серверы, а про формошлепство
S>>Я бывший дельфист перешел и перешел на C#. С Учетом продвижения Native AOT то это полная замена. J>И скоро AOT будет доступен для WinForms/WPF ?? Мы ж о замене дельфи говорим, то есть не про всякие серверы, а про формошлепство
Ну аналог WPF это MAUI. У него есть поддержка AOT. Проблем конечно с Native AOT много, но потихоньку движется.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, пффф, Вы писали:
П>Дельфи как система — очень хороша была. Тут спору нет. А вот язык, который был взят там за базу — Паскаль — полный отстой. Да, на нём можно тоже что-то делать. Ценой невероятных усилий, по сравнению с плюсами.
C++, наверно, и вправду сильно улучшился, вроде и для проблемы нестрогой типизации появилось решение, не говоря уж о стандарте, хотя казалось когда-то, что не за ним будущее. Но неужели pascal хуже, чем python и javascript, которые нынче почти всё остальное вытеснили, скажем, среди мобильных приложений нужно выискивать проекты, сделанные не на cordova. Pascal хоть статическую строгую типизацию вроде как имеет, а по части синтаксиса вообще извращения нынче в моде, даже в swift наворотили такого, что теперь, видимо, полноценного компилятора не будет.
Здравствуйте, Ilya81, Вы писали:
П>>Дельфи как система — очень хороша была. Тут спору нет. А вот язык, который был взят там за базу — Паскаль — полный отстой. Да, на нём можно тоже что-то делать. Ценой невероятных усилий, по сравнению с плюсами.
I>C++, наверно, и вправду сильно улучшился, вроде и для проблемы нестрогой типизации появилось решение, не говоря уж о стандарте, хотя казалось когда-то, что не за ним будущее. Но неужели pascal хуже, чем python и javascript, которые нынче почти всё остальное вытеснили, скажем, среди мобильных приложений нужно выискивать проекты, сделанные не на cordova. Pascal хоть статическую строгую типизацию вроде как имеет, а по части синтаксиса вообще извращения нынче в моде, даже в swift наворотили такого, что теперь, видимо, полноценного компилятора не будет.
Паскаль многословен. Может, для обучения это и хорошо, но в реальной работе это мешает. А когда я на нем работал, и возможности языка были ниже плинтуса. Сейчас, говорят, какие-то дженерики завезли. Но поезд давно ушел.
И никто не говорит, что python или javascript хороши. Именно поэтому в питон добавили аннотации типов, а для жиэс вообще отдельный тайпскрипт сделали
Здравствуйте, пффф, Вы писали:
П>И никто не говорит, что python или javascript хороши. Именно поэтому в питон добавили аннотации типов, а для жиэс вообще отдельный тайпскрипт сделали
Да уж, typescript — хоть какое-то спасение при взаимодействии с модулями, которые на javascript сделаны. А уж если это web-сраница, то такими будут почти все. Вот уж где самому нужно всё реализоввать — это если захотелось применить webassembly — он, видимо, не приживётся уже никогда.
Здравствуйте, Sinclair, Вы писали:
S>Просто Go не предназначен для алгоритмов. Не предназначен — и всё.
Это почему же? Для каких-таких "алгоритмов" не предназначен? Я вот вижу у него богатую библиотечную поддержку. Всю жизнь думал, что языки программирования — они все "для алгоритмов".
Здравствуйте, rudzuk, Вы писали:
R>Здравствуйте, swame, Вы писали:
s>> тут жопа только в бестолковом примере, писанном кем — то не знающим языка. s>> Нужно применять адекватные классы, в данном случае есть класс TStringList, любимый формоклепателями. s>> Там сортировка вызывается 1 строчкой.
R>Неа. Речь шла о пользовательском критерие сортировки, а он может быть любым. Со стринглистом такое не прокатит, если метод сравнения не перекрыть.
За 40 лет программирования мне понадобилось ровно 2 вида сортировки строк:
1. по алфавиту
2. по числовым, там где строки имеют одинаковое начало и сисловые части, типа 10 должно следовать после 9.
Второй вариант лежит у меня в виде единственной библиотечной функции, которая подключается 1 строчкой везде, где нужна.
Так что нытье про сложную и уродливую реализацию сортировки в Delphi не катит.
R>...
s>> 5. перегружает компилятор.
R>Проблема компилятора, если корректный код его перегружает Справедливости ради.
Это не-из за того, что компилятор плохой, а потому что такой код в принципе требуют намного более сложных структур при компиляции,
это время компиляции и память.
код который я привел генерирует 4-5 уровней вложенностей дженерики, и занимает на два порядка больше памяти в мап- файле по сравнению с обычным.
Здравствуйте, swame, Вы писали:
s> R>Неа. Речь шла о пользовательском критерие сортировки, а он может быть любым. Со стринглистом такое не прокатит, если метод сравнения не перекрыть.
s> За 40 лет программирования мне понадобилось ровно 2 вида сортировки строк: s> 1. по алфавиту s> 2. по числовым, там где строки имеют одинаковое начало и сисловые части, типа 10 должно следовать после 9. s> Второй вариант лежит у меня в виде единственной библиотечной функции, которая подключается 1 строчкой везде, где нужна.
Это говорит только о твоем опыте. Можно всю жизнь пилить круды и считать, что кроме грида людям ничего другого не нужно Ну и для твоего второго примера стринглист придется, таки, наследовать и вот это вот все.
s> Так что нытье про сложную и уродливую реализацию сортировки в Delphi не катит.
Я и не говорил, что она уродливая или сложная (однако, было бы лучше, если бы по дефолту использовался стабильный алгоритм). Я сказал, что стринглист хреновый пример.
s> R>Проблема компилятора, если корректный код его перегружает Справедливости ради.
s> Это не-из за того, что компилятор плохой, а потому что такие структуры в принципе требуют намного более сложных структур при компиляции, s> это время компиляции и память.
Если компилятор падает с out of memory, ему, таки, пора бы уже стать 64-битным. Так, мысли вслух.
s> код который я привел генерирует 4-5 уровней вложенностей дженерики, и занимает на два порядка больше памяти в мап- файле по сравнению с обычным.
В сто раз? Ну ок. В чем проблема, если код компилируется? Ну подольше, ничего страшного.
Здравствуйте, rudzuk, Вы писали:
R>Здравствуйте, swame, Вы писали:
s>> R>Неа. Речь шла о пользовательском критерие сортировки, а он может быть любым. Со стринглистом такое не прокатит, если метод сравнения не перекрыть.
s>> За 40 лет программирования мне понадобилось ровно 2 вида сортировки строк: s>> 1. по алфавиту s>> 2. по числовым, там где строки имеют одинаковое начало и сисловые части, типа 10 должно следовать после 9. s>> Второй вариант лежит у меня в виде единственной библиотечной функции, которая подключается 1 строчкой везде, где нужна.
R>Это говорит только о твоем опыте. Можно всю жизнь пилить круды и считать, что кроме грида людям ничего другого не нужно Ну и для твоего второго примера стринглист придется, таки, наследовать и вот это вот все.
И какой же ты сделал вывод о моем опыте?
А тебе какие еще сортировки строк приходилось делать?
s>> Так что нытье про сложную и уродливую реализацию сортировки в Delphi не катит.
R>Я и не говорил, что она уродливая или сложная (однако, было бы лучше, если бы по дефолту использовался стабильный алгоритм). Я сказал, что стринглист хреновый пример.
Это не ты говорил. И он же начал про сортировку строк. Не я.
s>> R>Проблема компилятора, если корректный код его перегружает Справедливости ради.
s>> Это не-из за того, что компилятор плохой, а потому что такие структуры в принципе требуют намного более сложных структур при компиляции, s>> это время компиляции и память.
R>Если компилятор падает с out of memory, ему, таки, пора бы уже стать 64-битным. Так, мысли вслух.
Согласен. НО я свои программы пытаюсь обуздывать в расходе памяти и продолжаю держать 32-битную версию основной, хотя там часто идет работа с десятками миллионов объектов.
Компилятор дельфи 32-битного кода мне как-то больше нравится, работает лучше и быстрей.
s>> код который я привел генерирует 4-5 уровней вложенностей дженерики, и занимает на два порядка больше памяти в мап- файле по сравнению с обычным.
R>В сто раз? Ну ок. В чем проблема, если код компилируется? Ну подольше, ничего страшного.
код такого стиля как я привел занимает едва ли 1%, но тратит процентов 30 времени компиляции, а память занимаемая при компиляции растет взрывообразно, под delphi 10 у нас уже не компилится, под delphi 11 на пределе — он чуть экономичней. В общем ничего хорошего. Так что я такой стиль запретил.
Здравствуйте, swame, Вы писали:
s> И какой же ты сделал вывод о моем опыте?
А какой вывод я могу сделать, кроме того, что тебе больше ничего не требовалось? Такой и сделал.
s> А тебе какие еще сортировки строк приходилось делать?
Например, сортировать игнорируя несколько первых или последних символов, по подстроке, короче.
s> Это не ты говорил. И он же начал про сортировку строк. Не я.
Sinclair говорил о сортировке по пользовательскому критерию, а не про сортировку строк. Если на пример посмотришь, то увидишь, что сортируются там не строки, хоть и по строкам
Здравствуйте, swame, Вы писали:
s> Случай, где нужно сортировать такие строки в чистом виде, не представляю.
Представь себе... Имена файлов с расширениями, например.
s> R>Sinclair говорил о сортировке по пользовательскому критерию, а не про сортировку строк. Если на пример посмотришь, то увидишь, что сортируются там не строки, хоть и по строкам
s> Обвинять язык на основе какого-то говнокода, который показывает как не надо делать, при том что есть несколько способов сделать это правильно, как-то странно.
Пардон муа, но этот "какой-то говнокод", это официальная дока. И это хорошее решение, если не рассматривать дженерики.
Здравствуйте, swame, Вы писали: S>За 40 лет программирования мне понадобилось ровно 2 вида сортировки строк:
Повторюсь: сортировать бывает нужно не только строки. S>1. по алфавиту S>2. по числовым, там где строки имеют одинаковое начало и сисловые части, типа 10 должно следовать после 9.
Вам повезло — попались непридирчивые заказчики. А как насчёт отсортировать строки по "похожести" на заданный образец (дистанция Левенштейна)?
Как насчёт case-sensitive vs case-insensitive? Как насчёт понизить приоритет whitespace, чтобы при сортировке "Иванов А.А." шёл рядом с "Иванов А. А." и с " Иванов А."?
Что будем делать с альтернативными представлениями Unicode? Ну, то есть вы же в курсе, что буква "ё" может быть как одним code point, так и двумя — и крайне желательно, чтобы оба варианта шли в выводе сортировки рядом друг с другом. S>Второй вариант лежит у меня в виде единственной библиотечной функции, которая подключается 1 строчкой везде, где нужна. S>Так что нытье про сложную и уродливую реализацию сортировки в Delphi не катит.
Давайте посмотрим на сигнатуру вашей библиотечной функции. Ну, чтобы понять, насколько она проста и неуродлива в использовании. Она же, наверное, подходит для всего — для TStringList, для array of string,
а также для любой массивоподобной коллекции элементов произвольного типа (object там или class), у которого есть произвольное строковое свойство, по которому и будем сортировать, да?
S>Это не-из за того, что компилятор плохой, а потому что такой код в принципе требуют намного более сложных структур при компиляции, S>это время компиляции и память. S>код который я привел генерирует 4-5 уровней вложенностей дженерики, и занимает на два порядка больше памяти в мап- файле по сравнению с обычным.
Стоимость памяти пренебрежимо мала по сравнению с зарплатой программистов. Так что пока компилятор пережёвывает такие структуры достаточно быстро, чтобы не нарушать цикл разработки, на потребление памяти можно смело забить.
Из строготипизированных языков с поддержкой таких штук я имел опыт с C#. Так вот — такой примитив его вообще не напрягает. Проект среднего размера собирается единицы секунд (и это на вполне себе средненькой машине разработчика, а не на выделенном сборочном сервере). Если Delphi делает это заметно медленнее (что было бы странно), то это как раз и порождает вопросы к языку, а не к подходу.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, akasoft, Вы писали: A>Это почему же? Для каких-таких "алгоритмов" не предназначен?
Ровно для обобщённых. Обобщённые алгоритмы можно писать либо без типов (все языки с динамикой, плюс языки с дырками в системе типов вроде Pointer или void *), либо на генериках, либо никак.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, akasoft, Вы писали: A>Это называется "библиотечная поддержка".
Чтобы она появилась, потребовалась для начала поддержка в языке.
На K&R С вы не напишете ничего подобного filter/map/reduce никаким библиотечным способом. A>За этими filter/map/reduce кто-то попердолился и скрываются кучи кода.
Хороший язык предоставляет пологую кривую трудозатрат/выигрыша. Простейшая реализация filter/map/reduce на более-менее любом современном языке никакой кучи кода не требует:
public static IEnumerable<T> Where<T>(IEnumerable<T> source, Predicate<T> predicate)
{
foreach(var item in source)
if(predicate(item))
yield return item
}
public static IEnumerable<R> Select<T, R>(IEnumerable<T> source, Func<T, R> selector)
{
foreach(var item in source)
yield return selector(item)
}
public static A Reduce<T, A>(IEnumerable<T> source, Func<A, T, A> aggregate, A startValue)
{
foreach(var item in source)
startValue = aggregate(startValue, item);
return startValue;
}
И только если нас не устраивает производительность вот такой универсальной реализации, мы захотим делать её специализации. И, опять же, хороший язык даст нам это сделать не ломая прикладной код.
То есть на том конце, где библиотека потребляется, код так и останется таким, как был:
var a = [4, 8, 15, 16, 23, 42];
var b = a.Where(e => e % 2 == 0).Select(e => e * 3).Reduce((a, e) => a * e % 13);
A>А уж написать это в строку или в столбик значения не имеет.
Значение имеет то, насколько легко пишется и читается такой код. Пример на Delphi читается ужасно, не правда ли?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S> Обобщённые алгоритмы можно писать либо без типов (все языки с динамикой, плюс языки с дырками в системе типов вроде Pointer или void *), либо на генериках, либо никак.
Здравствуйте, rudzuk, Вы писали:
s>> Случай, где нужно сортировать такие строки в чистом виде, не представляю.
R>Представь себе... Имена файлов с расширениями, например.
Таки это лучше сначала на компоненты разобрать, а потом сортировать. Если при каждом сравнении извлекать часть, и потом её сравнивать, результат к пенсии получишь
Здравствуйте, rudzuk, Вы писали: R>Давал уже ссылку: https://wiki.freepascal.org/Templates R>Можно писать обобщенно, типобезопасно и без дженериков. Эта возможность была даже турбо-паскале.
Я думал, вы шутите.
Во-первых, там в коде — явный косяк в секции inheritance. TAdvancedListInteger не содержит метода Add.
Во-вторых, обобщённый код — это совсем не то же самое, что и шаблоны препроцессора. В частности, вся инстанциация делается руками. Это — крайне неудобно по сравнению со штатными генериками, где достаточно передать значение нужного типа туда, где оно ожидается.
Грубо говоря там, где у меня будет функция вида List<T> WrapByList<T>(T item), позволяющая писать WrapByLisT(42), WrapByList("hello") и т.п., в "кодогенерённом" коде придётся писать IntList.Create(42), StringList.Create(42). Невозможно написать обобщённую функцию L Sort<L, K, T>(L list, Func<T, K> keySelector) where L: IList<T>, where K: IComparable<K> и передавать в неё произвольную коллекцию — придётся её специализировать для каждой комбинации типов.
Ну, то есть это лучше, чем совсем ничего, но всё ещё существенно хуже, чем существующий уровень техники.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, rudzuk, Вы писали:
п>> Таки это лучше сначала на компоненты разобрать, а потом сортировать.
R>Не нужно мне ничего разбирать, ни на какие компоненты
п>> Если при каждом сравнении извлекать часть, и потом её сравнивать, результат к пенсии получишь
R>Поэтому не нужно так делать Можно сравнивать ничего не извлекая.
Здравствуйте, Sinclair, Вы писали:
S> Во-первых, там в коде — явный косяк в секции inheritance. TAdvancedListInteger не содержит метода Add.
Просто пропустили наследование в TGAdvancedList. В комментарии оно есть, а в декларации пропущено.
S> Во-вторых, обобщённый код — это совсем не то же самое, что и шаблоны препроцессора. В частности, вся инстанциация делается руками. Это — крайне неудобно по сравнению со штатными генериками, где достаточно передать значение нужного типа туда, где оно ожидается.
Здравствуйте, пффф, Вы писали:
п> п>> Если при каждом сравнении извлекать часть, и потом её сравнивать, результат к пенсии получишь
п> R>Поэтому не нужно так делать Можно сравнивать ничего не извлекая.
Ты же знаешь, что у строк есть индексный доступ? Ну?
Здравствуйте, rudzuk, Вы писали:
п>> R>Поэтому не нужно так делать Можно сравнивать ничего не извлекая.
R>Ты же знаешь, что у строк есть индексный доступ? Ну?
Здравствуйте, пффф, Вы писали:
п> п>> R>Поэтому не нужно так делать Можно сравнивать ничего не извлекая.
п> R>Ты же знаешь, что у строк есть индексный доступ? Ну?
п> И?
Здравствуйте, rudzuk, Вы писали:
п>> п>> R>Поэтому не нужно так делать Можно сравнивать ничего не извлекая.
п>> R>Ты же знаешь, что у строк есть индексный доступ? Ну?
п>> И?
R>Чего и? Напряги мозгу.
Хочу от тебя узнать правильный ответ, самому не додуматься
Здравствуйте, пффф, Вы писали:
п> п>> п>> R>Поэтому не нужно так делать Можно сравнивать ничего не извлекая.
п> п>> R>Ты же знаешь, что у строк есть индексный доступ? Ну?
п> п>> И?
п> R>Чего и? Напряги мозгу.
п> Хочу от тебя узнать правильный ответ, самому не додуматься
Сравниваем максимум три символа с указанных позиций ничего не извлекая:
Здравствуйте, rudzuk, Вы писали:
п>> R>Чего и? Напряги мозгу.
п>> Хочу от тебя узнать правильный ответ, самому не додуматься
R>Сравниваем максимум три символа с указанных позиций ничего не извлекая: R>
Для получения символа в строке есть специальные функции, прикинь. Даже если делать "в лоб" и искать от начала строки, то на миллион поисков по имени файла длинной 15 символов + точка + 3 символа на расширение затрачивается всего около 30 мсек. на древнем железе. Если же подойти к вопросу творчески, сразу проверить FileName[Length(FileName) — 3] = '.' , и если это не точка то искать начиная с конца, то времени будет затрачено и того меньше. Короче, не парь меня своими прематурными переживаниями в вечер воскресения ночь понедельника.
Здравствуйте, rudzuk, Вы писали:
п>> Откуда нам известны lExtPos, rExtPos?
R>Для получения символа в строке есть специальные функции, прикинь.
R>Даже если делать "в лоб" и искать от начала строки, то на миллион поисков по имени файла длинной 15 символов + точка + 3 символа на расширение затрачивается всего около 30 мсек. на древнем железе.
Надо искать не "в лоб", а с конца строки. А это ещё один удар по производительности.
И надо ещё искать положение разделителя частей пути. Потому что, внезапно, файлы могут не иметь расширения, а каталоги — как раз иметь. Или файл будет какой-нибудь .tar.bz с двойным расширением.
И теперь умножаем это на удвоенное количество сравнений при сортировке (удвоенное — потому что для обоих операндов надо искать). У твоих пользователей появляется реальный шанс не дожить до получения результата.
R>Если же подойти к вопросу творчески, сразу проверить FileName[Length(FileName) — 3] = '.' , и если это не точка то искать начиная с конца, то времени будет затрачено и того меньше.
Ха-ха, у тебя расширения имени файла всегда только трёхсимвольные?
R>Короче, не парь меня своими прематурными переживаниями в вечер воскресения ночь понедельника.
Мне жалко пользователей твоего софта.
И да, ожидания не прематурные, а вполне реальные. Я делал много разных сортировок строк, в том числе и сортировка строк с учетом числовых значений в этих строках. И да, предварительное извлечение всей необходимой для сортировки информации очень сказывается на производительности.
А реально ли извлекать части из сортируемых строк, делать ли для них что-то типа string_view или сохранять индексы — это дело десятое.
Это не я прематурщик, это ты — тяпляпщик.
R>Итого, 60% файлов имеют трехсимвольное расширение. Вот и подумай.
Выкинуть или неправильно обработать 40% исходных данных — это надо постараться
R>Да нет, ты именно прематурщик в чистом виде. Напридумывал условий, сам с собой поспорил, сам себя убедил. Без цифр, без замеров, без ничего. И весь такой прошаренный, оптимальный весь. Это у сишников болезнь такая, я в курсе. А как до дела доходит, так начинается игра в догонялки в коричневых штанах
То-то на дельфях ваших ничего годного так и не написали в значимом количестве. У вас на реальных данных всё просто не работает. Ну, это конечно если вы не используете готовые компоненты. Компоненты обычно пишут люди достаточно квалифицированные. А вот то, что дельфисты пишут сами — это полный трешак.
ЗЫ Да, ЗеБат я видел, я даже Дос Навигатор видел. И Миднайт Командер тоже видел. Это топ уровень дельфячников
Здравствуйте, rudzuk, Вы писали: R>Просто пропустили наследование в TGAdvancedList. В комментарии оно есть, а в декларации пропущено.
Не вполне понятно, что будет написано в декларации. В комментарии упомянуто, что нужно придерживаться некоторой конвенции именования, но я не понимаю, какой. R>Да, но когда генериков нет это хороший вариант.
С этим я не спорю.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, пффф, Вы писали: П>Таки это лучше сначала на компоненты разобрать, а потом сортировать. Если при каждом сравнении извлекать часть, и потом её сравнивать, результат к пенсии получишь
Вообще-то, всё как раз наоборот.
"Разбор на компоненты" означает выделение памяти. Оно стоит дорого, что в нативном коде, что в среде с GС. В первом варианте мы сразу получаем штраф за выделение/освобождение, во втором — увеличиваем нагрузку на GC.
Лучший способ сортировки — это когда у нас есть специализированная функция, реализующая некоторый алгоритм сортировки (скорее всего — частично заинлайненная, чтобы в "листьевые" вызовы вообще не были вызовами). В эту функцию сразу должен быть встроен предикат сравнения с zero-copy. Никаких многкратных проходов вида "вот тут я разбираю path на запчасти", "а вот тут я из него выделяю нужный мне компонент", "а вот теперь я сортирую результат вот таким алгоритмом" не надо — если, конечно, хочется получить результат до пенсии.
В стародавние времена такое писали руками и очень гордились вылизанностью "до такта".
Но такой подход крайне трудоёмок, и в него тяжело вносить правки (т.к. логика сравнений и логика выбора элементов для сравнения перемешаны).
Поэтому хочется собирать этот алгоритм из кусочков, а всё это встраивание и оптимизацию делегировать компилятору, который не устаёт и не ошибается.
Наилучшие результаты тут будут у C++, который умеет инлайнить примерно всё, включая замыкания. Поэтому на нём компактно написанный код превратится в отлично оптимизированный целевой код без лишних копирований.
Неплохие результаты будут у Java, которая умеет делать спекулятивный инлайнинг и escape-analysis, при условии, что рассматриваемый код влезает в ограничения JIT.
Приемлемые результаты будут у C#, где отсутствие escape analysis компенсируется наличием value-типов, но идиотский дизайн делегатов мешает JIT-у оптимизироваться.
Достижение сравнимого с C++ результата возможно в библиотеках, которые злоупотребляют ленивостью и порождают байт-код самостоятельно.
Но самый стрёмный результат будет как раз на наивно-нативных языках вроде Pascal, где программист будет действовать именно так, как вы написали — перекладывать данные из одной структуры в другую.
Асимптотика, конечно, будет та же самая, но на мало-мальски сложной задаче код сольёт приличным реализациям в разы.
Ещё заметнее разница будет там, где возможен ранний выход — например, если мы делаем не сортировку или агрегацию, а поиск.
Тогда энергичная трансформация данных сделает лишнюю работу, которая будет выброшена на следующем этапе конвеера вычислений.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S> Не вполне понятно, что будет написано в декларации. В комментарии упомянуто, что нужно придерживаться некоторой конвенции именования, но я не понимаю, какой.
TGAdvancedList = class(TGList)
Там еще ошибка с декларацией поля Items, которое объявлено статическим массивом, но задумано, как динамический.
Здравствуйте, pva, Вы писали:
K>>Делфи (ну и билдер, конечно тоже) прекрасный язык и платформа (были лет 20 назад точно, сейчас — хз) и прекрасно интегрируется с сишными либами через DLL.
Скажу больше, удавалось (не без полухакеского подхода) писать Dll-ки на VC++ для использования в Delphi, именно с экспортом сишных классов в паскаль. Не просто экспортируемых функций.
Здравствуйте, Maniacal, Вы писали:
M>Здравствуйте, pva, Вы писали:
K>>>Делфи (ну и билдер, конечно тоже) прекрасный язык и платформа (были лет 20 назад точно, сейчас — хз) и прекрасно интегрируется с сишными либами через DLL.
M>Скажу больше, удавалось (не без полухакеского подхода) писать Dll-ки на VC++ для использования в Delphi, именно с экспортом сишных классов в паскаль. Не просто экспортируемых функций.
C использование интерфейсов (без COM даже) не должно быть каких-то сложностей если понимаешь что делаешь.
Здравствуйте, swame, Вы писали:
S>C использование интерфейсов (без COM даже) не должно быть каких-то сложностей если понимаешь что делаешь.
на стеке у VC++ один лишний параметр добавляется, так что пришлось колдовать. Уже точно не помню, но, вроде, возвращаемый функцией параметр для Дельфи это первый параметр функции на VC++ (смотрю сейчас свои старые исходники)
Здравствуйте, пффф, Вы писали:
П>ЗЫ Да, ЗеБат я видел, я даже Дос Навигатор видел. И Миднайт Командер тоже видел. Это топ уровень дельфячников
Дак в Дос Навигаторе встроенный асм чуть менее, чем везде. Но зато у него многозадачность есть. Поиск файлов одновременно с текстовым редактором работает.
Здравствуйте, Maniacal, Вы писали:
M>Здравствуйте, swame, Вы писали:
S>>C использование интерфейсов (без COM даже) не должно быть каких-то сложностей если понимаешь что делаешь.
M>на стеке у VC++ один лишний параметр добавляется, так что пришлось колдовать. Уже точно не помню, но, вроде, возвращаемый функцией параметр для Дельфи это первый параметр функции на VC++ (смотрю сейчас свои старые исходники)
Здравствуйте, vsb, Вы писали:
vsb>Здравствуйте, Sinclair, Вы писали:
S>>Далее, выбор Хейльсбергом Object Pascal в качестве языка сыграл с пользователями Delphi дурную шутку. Паскаль сам по себе прекрасно подходит для изучения алгоритмов; а вот писать на нём повторно используемые алгоритмы практически невозможно. Отсутствие обобщённых типов и перегрузки операторов приводило к тому, что алгоритм сортировки писал себе примерно каждый (либо сводил всё к существующим решениям). S>>В целом, по сравнению с примерно любым современным языком, Delphi очень сильно мешает писать сложные алгоритмы с меньшим количеством ошибок. Тупо нет нужных средств декомпозиции алгоритмов.
Все средства есть. мало людей которые умеют декомпозировать, т.к. из за низкого порога входа пришли формоклепатели и "DBA".
vsb>И в Go до недавнего времени и в Java до 5 версии не было генериков. И ничего — через interface{} / Object прекрасно все алгоритмы писались.
interface это уже обобщение начального уровня.
vsb>Я больше скажу — ни в Go, ни в Java у меня не было никакой необходимости писать какие-то обобщённые алгоритмы.
vsb>И я даже ещё больше скажу. Крамольную вещь. Те, кто любят писать обобщённые алгоритмы, как правило, тратят время впустую на ментальную гимнастику вместо того, чтобы решать проблемы. Поэтому ругать конкретно Pascal считаю некорректным. Нормальный язык, никак не ограничивающий программиста. И во многих отношениях на порядок лучше того же С++.
В простых программах можно обойтись без обобщений.
В сложных без них не обойтись.
Если смог написать большую программу "без обобщений" и гигантского дублирования кода то молодец, но обобщения там все равно есть.
Здравствуйте, swame, Вы писали:
M>>на стеке у VC++ один лишний параметр добавляется, так что пришлось колдовать. Уже точно не помню, но, вроде, возвращаемый функцией параметр для Дельфи это первый параметр функции на VC++ (смотрю сейчас свои старые исходники)
S>https://www.gunsmoker.ru/2019/06/developing-DLL-API.html
Да я уже навелосипедировал. Одно дело писать нормальные функции для экспорта, другое __cdecl VC++ в __stdcall Delphi преобразовывать.
На простейшем примере
В Дельфи это для импорта
function AttrAsObject(psAttr : PAttribute) : IObject; stdcall; external'Object.dll';
Справедливости ради.
Ну ладно. Заместить шаблоны в паскале можно было включаемыми файлами {$include template.pas} (пример на fpc)
