Assasin писал(а):
и я Вас тоже ни к чему не призываюAssasin писал(а):
У меня претензия к твоему методу ведения работ: не надо учить людей плохо работатьAssasin писал(а):
Если бы мы внедряли это по шагам (сначала уже готовое решение, а потом дополнительные оптимизации всего и вся) - то все эти 6 лет MathParse успешно служил бы обществуОказалось, что это я виноват, что Assasin не доделал MathParseEx.
Да, идея была продуктивная.
Только ее еще довести надо было. А это несколько сложнее, чем понты про правильность кидать.
Работать головой всегда сложнее, чем языком.
Да, Ваш первый вариант давал некоторые разы.
А у меня хватило ума показать Вам как из этого выжать ЕЩЕ (к Вашему выигрышу) порядок по быстродействию.
Выжать из идеи все, на что она способна.
Вы подумали-подумали, и признали это "неправильным". И отказались от продолжения проекта.
Вот так было на самом деле.
И все это написано здесь (и не 6 лет, 3.5 года назад)
А виноват оказался я.
Assasin, кончай гнать пургу. Твоя цель была - быстродействие. Ты отказался от ее достижения.
А я просто пользуюсь своей версией (которую законченной не считаю).
Нет, не 6 лет. Но больше 3-х.
И также не считаю, что к ней можно прийти от твоей "методом добавления фич".
Сравни два кода, и покажи последовательность этих фич.
НЕ ПОКАЖЕШЬ.
Assasin писал(а):
Почему? Чтобы понять, что такое на самом деле PArray, как с ним правильно работать и как нельзя, нужно прочитать весь код, использующий эту переменную (в отличие от моего типа, используемого в MathParseEx, который достаточно было прочитать один раз и быстро понять, благо он очень короткий). В Вашем случае в каждый такой кусок кода придется вникнуть и запомнить контекст, чтобы потом не дай бог где-то нечайно не ошибиться со списком корректных операций над PArray в данной конкретной строчке.Про тип PArray все понятно в пределах одной процедуры (например, в _work_doFilter0 это PStrList).
Про твой тип я уже сказал - он понятен только для тебя, потому что ты его придумал.
Получается, что твоя читаемость - крайне субъективна. И вот ради этого субъективного качества ты готов жертвовать быстродействием.
Т.е., потребности себя любимого ты ставишь выше потребности пользователя. Это ему, а не тебе - нужно быстродействие.
Поставить приоритеты наоборот -- это ведь не для IT-шника.
Да, читаемость - очень важное качество. Только: сначала пользователь, а потом ты, любимый.
Вы, Assasin, не поняли самого главного в работе.
Все одновременно сделать невозможно. Потому, действительно, добавляешь одну фичу, потом другую, потом третью, и т.д..
Главное здесь в том, что когда добавляешь первую, ты должен точно понимать в чем будет заключаться последняя.
Тогда это будет просто работа по плану. И все добавляемые фичи должны подчиняться этому общему плану.
Именно этот план Вы называете сворачиванием гор. У Вас такое впечатление сложилось, оказывается.
А когда работаешь без плана, или еще интересней: план меняется в процессе добавления под нужды очередной фичи -- это будет Шанхай.
Горячо Вами любимый. И который рано или поздно упадет.
И Вы сделали вывод, что это шанхаестроение - самый эффективный метод. Из того, что не справились с MathParseEx.
А мой метод (планирование работы) - это "сворачивание гор" по Вашему.
И на основании этой шизы в Вашей голове Вы мне претензии выставляете.
DIXI
Поиск
Друзья
Администрация