Сообщение Re[5]: Delphi и велосипедирование от 25.06.2024 5:01
Изменено 25.06.2024 7:15 Sinclair
Re[5]: Delphi и велосипедирование
Здравствуйте, swame, Вы писали:
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 стало ещё хуже.
S>
| типа такого (код из нашего комплекса)? | |
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 стало ещё хуже.
Re[5]: Delphi и велосипедирование
Здравствуйте, swame, Вы писали:
Да, что-то в этом роде.
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 стало ещё хуже.
| типа такого (код из нашего комплекса)? | |
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 стало ещё хуже.