Login
Как это работает?
21.02.10 00:53
Очень сравнимые вещи - введение функциональщины в C# и уёбище рассчитанное на VB-дураков. Если хотите проводить аналогии, сравнивйте вещи из одной категории, а не тёплое с мягким.
80/20 правило знаете? Вот, по моему опыту с рассуждениями на форуме про производительность это правило становится верным с цифрами 99/1. Угу. Давайте, не будем про производительность, в 99% случаев все эти рассуждения не стоят ломаного гроша. Потому, что начинаются теоретезирования про то, что на ассемблере программы были раньше маленькими, что виртуальные функции в С++ имеют оверхэд на косвенный вызов, и тому подобную чепуху. Будет проблема, будет оптимизация. Я уверен, takeWhile разворачиваетсся в банльный цикл с проверкой условия, а лямбда стоит почти столько же, сколько и "обычный" метод.
Мурр, срез это массив, итератор это объект перебирающий последовательность. Что за дурацкое сравнение разных вещей? У вас вообще отсутствует воображение, вы считаете, наличие массивов в языке лишним? Давайте их уберём, а чё, есть же ArrayList и его производные.
А выкиньте концепцию итератора вабще и не пользуйтесь ею, а то это чисто функциональная фишка. Гудбай IEnumarable, foreach и тому подобное. Также выкидывайте анонимные методы и их развитие - лямбды, с появлением окторых писанина банальных (в смысле тех, которые содержат простой код) колбэков космически сократилась. Пишите километры никому ненужного кода с полным оформлением делегатов. Чтобы чистота не пострадала.
Борьба с ветряными мельницами. LINQ это не синоним выставления наружу алгоритма, LINQ это красивый описательный способ получения выборки данных, а отсутствие LINQ это многословная имплементации низкоуровнего алгоритма перебора последовательности и заворачивание этого в объект, иначе будет мусор. LINQ используется ровно на том же месте, где используется вручную написанный итератор с кодом создающий объект.
Да, вот, что-то и для разработки дорогой поделки время разработки играет существенную роль всегда.
in Antwort Murr_0005 20.02.10 22:10
В ответ на:
С этим не согласится сложно. Примерно то же заявлялось при выпуске Аксесса - SQL по месту и оптимизация на системном уровне. Оказалось, однако, что задачу, состоящую из более 10-ка форм, сопровождать практически невозможно.
С этим не согласится сложно. Примерно то же заявлялось при выпуске Аксесса - SQL по месту и оптимизация на системном уровне. Оказалось, однако, что задачу, состоящую из более 10-ка форм, сопровождать практически невозможно.
Очень сравнимые вещи - введение функциональщины в C# и уёбище рассчитанное на VB-дураков. Если хотите проводить аналогии, сравнивйте вещи из одной категории, а не тёплое с мягким.
В ответ на:
Помимо этого надо думать об том где и как применять и какой оверхед времени исполнения будет.
Место применения, как Я понимаю, как раз внутри объекта... где, в принципе, не слишком существенно что именно используется.
Ибо как только сие начинает применяться произвольно, то вылазят проблемы где их не надо.
Помимо этого надо думать об том где и как применять и какой оверхед времени исполнения будет.
Место применения, как Я понимаю, как раз внутри объекта... где, в принципе, не слишком существенно что именно используется.
Ибо как только сие начинает применяться произвольно, то вылазят проблемы где их не надо.
80/20 правило знаете? Вот, по моему опыту с рассуждениями на форуме про производительность это правило становится верным с цифрами 99/1. Угу. Давайте, не будем про производительность, в 99% случаев все эти рассуждения не стоят ломаного гроша. Потому, что начинаются теоретезирования про то, что на ассемблере программы были раньше маленькими, что виртуальные функции в С++ имеют оверхэд на косвенный вызов, и тому подобную чепуху. Будет проблема, будет оптимизация. Я уверен, takeWhile разворачиваетсся в банльный цикл с проверкой условия, а лямбда стоит почти столько же, сколько и "обычный" метод.
В ответ на:
Тем хуже. Ибо если возвращается массив, то хотелось бы иметь его во врапированном виде с корректными индексерами. Если этого нет, то итератор более приемлем.
Тем хуже. Ибо если возвращается массив, то хотелось бы иметь его во врапированном виде с корректными индексерами. Если этого нет, то итератор более приемлем.
Мурр, срез это массив, итератор это объект перебирающий последовательность. Что за дурацкое сравнение разных вещей? У вас вообще отсутствует воображение, вы считаете, наличие массивов в языке лишним? Давайте их уберём, а чё, есть же ArrayList и его производные.
В ответ на:
LINQ же предлагает смешивать Функциональный и Объектный подходы в одном и том же решении
LINQ же предлагает смешивать Функциональный и Объектный подходы в одном и том же решении
А выкиньте концепцию итератора вабще и не пользуйтесь ею, а то это чисто функциональная фишка. Гудбай IEnumarable, foreach и тому подобное. Также выкидывайте анонимные методы и их развитие - лямбды, с появлением окторых писанина банальных (в смысле тех, которые содержат простой код) колбэков космически сократилась. Пишите километры никому ненужного кода с полным оформлением делегатов. Чтобы чистота не пострадала.
В ответ на:
НО Я категорически против применения того же LINQ "поверх" объекта, где он, в основном, и будет применяться.
НО Я категорически против применения того же LINQ "поверх" объекта, где он, в основном, и будет применяться.
Борьба с ветряными мельницами. LINQ это не синоним выставления наружу алгоритма, LINQ это красивый описательный способ получения выборки данных, а отсутствие LINQ это многословная имплементации низкоуровнего алгоритма перебора последовательности и заворачивание этого в объект, иначе будет мусор. LINQ используется ровно на том же месте, где используется вручную написанный итератор с кодом создающий объект.
В ответ на:
Другое дело, что для разработки дешевой поделки основную роль играет не сопровождение, а разработка - чем быстрее, тем лучше.
Другое дело, что для разработки дешевой поделки основную роль играет не сопровождение, а разработка - чем быстрее, тем лучше.
Да, вот, что-то и для разработки дорогой поделки время разработки играет существенную роль всегда.
Dropbox - средство синхронизации и бэкапа файлов.
21.02.10 01:38
in Antwort voxel3d 21.02.10 00:53
сравнивйте вещи из одной категории
-----
Я, вообще-то, сравниваю вещи абсолютно сопостовимые. Единственно - тебе не
понятно какие. Поясню. Я сравниваю твой восторг от наличия LINQ с восторгом
моего шефа в момент выхода Аксесса. Да и аргументы - практически совпадают.
Единственное - тогда ругалась связка - ОДБС-БиТреев, а сейчас - Аксесс...
З.Ы. На Аксессе тоже можно писать в псевдоООП, но никто этого не делает. И
Я полагаю, что это создаст те же проблемы при применении LINQ.
Я уверен, takeWhile разворачиваетсся в банльный цикл
------
Вопрос в том, где и когда это происходит. Внутри объекта меня это утраивает.
вы считаете, наличие массивов в языке лишним?
------
Я считаю, что прямое использоване масивов не есть правильный стиль разработки.
Сущности должны быть выделены и типизированы. Внутренняя имплементация -
уже не вопрос - через массив, через лист, через хэш-табле - как надо.
Пишите километры
-----
Размер кода меня уже давно волнует очень мало.
По секрету скажу - последнее время и производительность беспокоит лишь на
уровне того, что об ней надо помнить.
Что меня сегодгня интересует - как описать всю задачу в виде расширяемого
набора интерфейсов и автоматически построить схему трансформации из некоторого
описания в имплементацию этих интерфейсов.
Гудбай IEnumarable, foreach и тому подобное.
-----
Ты можешь и удивиться - foreach вне объекта есть вещь не хорошая...
LINQ используется ровно на том же месте
-----
Ты не объяснишь, почему у меня стойкое впечатление, что он будет использоваться
гораздо шире? И это применение опустит его на уровень SQL в Аксессе...
для разработки дорогой поделки время разработки играет существенную роль всегда.
-----
Не передергивай в пустую - речь про соотношение разработка/поддержка.
-----
Я, вообще-то, сравниваю вещи абсолютно сопостовимые. Единственно - тебе не
понятно какие. Поясню. Я сравниваю твой восторг от наличия LINQ с восторгом
моего шефа в момент выхода Аксесса. Да и аргументы - практически совпадают.
Единственное - тогда ругалась связка - ОДБС-БиТреев, а сейчас - Аксесс...
З.Ы. На Аксессе тоже можно писать в псевдоООП, но никто этого не делает. И
Я полагаю, что это создаст те же проблемы при применении LINQ.
Я уверен, takeWhile разворачиваетсся в банльный цикл
------
Вопрос в том, где и когда это происходит. Внутри объекта меня это утраивает.
вы считаете, наличие массивов в языке лишним?
------
Я считаю, что прямое использоване масивов не есть правильный стиль разработки.
Сущности должны быть выделены и типизированы. Внутренняя имплементация -
уже не вопрос - через массив, через лист, через хэш-табле - как надо.
Пишите километры
-----
Размер кода меня уже давно волнует очень мало.
По секрету скажу - последнее время и производительность беспокоит лишь на
уровне того, что об ней надо помнить.
Что меня сегодгня интересует - как описать всю задачу в виде расширяемого
набора интерфейсов и автоматически построить схему трансформации из некоторого
описания в имплементацию этих интерфейсов.
Гудбай IEnumarable, foreach и тому подобное.
-----
Ты можешь и удивиться - foreach вне объекта есть вещь не хорошая...
LINQ используется ровно на том же месте
-----
Ты не объяснишь, почему у меня стойкое впечатление, что он будет использоваться
гораздо шире? И это применение опустит его на уровень SQL в Аксессе...
для разработки дорогой поделки время разработки играет существенную роль всегда.
-----
Не передергивай в пустую - речь про соотношение разработка/поддержка.
NEW 21.02.10 12:18
in Antwort Murr_0005 20.02.10 18:59, Zuletzt geändert 21.02.10 12:20 (Mmmaloy)
Я опять немножко не понял
---
Имел ввиду, что автоматически-генерируемое поле, можно всегда подменить своим руками-генерируемым полем
Вписать в них функциональность = отказаться от автоматической проперти
---
На интерфейс класса это никак не повлияет
Это полиси в компании.
---
Это прямое пренебрежение одним из соглашений ООП - инкапсуляцией.
Был бы статический метод
---
И да и нет. Что первое в голову приходит, это паттерн Commands, когда в команде(инстанция объекта) вызывается метод bool CanExecute(Object Param).
Организация управления - достаточно тривиальная
---
Все зависит от дизайна. Здесь ничего конкретного не могу утверждать, нужны конкретные примеры.
Годик назад повозился с потоками. Результат говорит, что если есть готовность использовать потоки - надо их использовать.
---
Я тоже возился с потоками достаточно плотно. Мой опыт говорит, что их по возможности следует избегать. Все опять же зависит от дизайна, который должен оставаться максимально простым.
---
Имел ввиду, что автоматически-генерируемое поле, можно всегда подменить своим руками-генерируемым полем
Вписать в них функциональность = отказаться от автоматической проперти
---
На интерфейс класса это никак не повлияет
Это полиси в компании.
---
Это прямое пренебрежение одним из соглашений ООП - инкапсуляцией.
Был бы статический метод
---
И да и нет. Что первое в голову приходит, это паттерн Commands, когда в команде(инстанция объекта) вызывается метод bool CanExecute(Object Param).
Организация управления - достаточно тривиальная
---
Все зависит от дизайна. Здесь ничего конкретного не могу утверждать, нужны конкретные примеры.
Годик назад повозился с потоками. Результат говорит, что если есть готовность использовать потоки - надо их использовать.
---
Я тоже возился с потоками достаточно плотно. Мой опыт говорит, что их по возможности следует избегать. Все опять же зависит от дизайна, который должен оставаться максимально простым.
NEW 21.02.10 13:24
in Antwort Mmmaloy 21.02.10 12:18
можно всегда подменить
-----
Так же можно "сделать правильно" изначально.
На интерфейс класса это никак не повлияет
-----
Не, не повлияет. Правда, в случае если будет заменена часть определений, в коде будут использованы два метода определения полей, что не есть плюс для кода.
первое в голову приходит, это паттерн
-----
+1 - так далеко Я не заходил...
который должен оставаться максимально простым
-----
Это - да. Любое вынесение в поток будет усложнением. Тем не мение - как только появляются вычисления, которые не укладываются в заданное время реакции - пора вводить потоки.
-----
Так же можно "сделать правильно" изначально.
На интерфейс класса это никак не повлияет
-----
Не, не повлияет. Правда, в случае если будет заменена часть определений, в коде будут использованы два метода определения полей, что не есть плюс для кода.
первое в голову приходит, это паттерн
-----
+1 - так далеко Я не заходил...
который должен оставаться максимально простым
-----
Это - да. Любое вынесение в поток будет усложнением. Тем не мение - как только появляются вычисления, которые не укладываются в заданное время реакции - пора вводить потоки.