Re[36]: Являются ли макросы свидетельством недостаточной выр
От: Klapaucius  
Дата: 06.08.07 16:02
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Это не "эрудиция", это плохая память, коллега . Все-таки, в 31 год тяжело вспомнить детали угребищного языка, на котором писал много, но в школе. Я с тех пор настолько много чему научился, что мне не стыдно забыть $ перед строковой переменной, а смешно .


Завидую. А мне вот становиться невыносимо стыдно всякий раз, как я что-нибудь забываю.

G>Однако, что такое динамическая и статическая типизация я помню хорошо. Отличие между ними, мой хорошо эрудированный и плохо знающий матчасть коллега, состоит не в полиморфизме, а в том, в какой момент проверяются типы. До выполнения (статически) или во время выполнения (динамически).


Все верно.

G>Все бейсики, как интерпретируемые языки, кроме некоторых исключений-компиляторов, проверяли типы в динамике...


А с чего Вы взяли, что Basic — интерпретируемый язык? Интерпретируемый язык или нет — зависит от его дизайна. Язык, который проектировали как статически типизированный можно компилировать и интерпретировать — но при интерпретации пользоваться бенефитами динамической типизации практически нельзя — дизайном не предусмотрена-с. Язык, который проектируется как язык с динамической типизацией — можно интерпретировать со всеми бенефитами динамики, но компилировать практически невозможно. Опять-таки дизайн.
Basic — язык, который относится к первым, а не ко вторым. Так что правильнее сказать Все бейсики, как компилируемые языки, проверяли типы при компиляции, за исключением скриптов-диалектов. От того, что есть интерпретатор Haskell и OCaml, они ведь динамическими не становяться?
Речь шла об индустриальных динамических языках. Я вспомнил Smalltalk и незаслуженно забыл про Erlang. Но уж бейсик то точно из другой оперы. Все индустриальные GP бейсики — компиляторы.
... << RSDN@Home 1.2.0 alpha rev. 655>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[47]: Являются ли макросы свидетельством недостаточной выр
От: mkizub Литва http://symade.tigris.org
Дата: 06.08.07 16:03
Оценка:
Здравствуйте, AndrewVK, Вы писали:

M>>Процедурный подход безусловно мощнее, поскольку декларативный ограничен набором известных ему операций.


AVK>Какое то у тебя узкое понимание декларативности. ФП это тоже декларативный подход.


Не вижу противоречий. Мое понимание включает в себя FP, пока ты определяешь функцию — ты в рамках декларативности.
Когда компилятор, на основе твоих определений, строит последовательность действий, необходимых для вычисления значения этой функции — это уже императив.
Разумеется, последовательность действий для вычисления значения функции может быть разной (в зависимости от алгоритма используемого компилятором),
в этом смысле ФП декларативен.
SOP & SymADE: http://symade.tigris.org , блог http://mkizub.livejournal.com
Re[33]: Являются ли макросы свидетельством недостаточной выр
От: Gaperton http://gaperton.livejournal.com
Дата: 06.08.07 16:08
Оценка:
Здравствуйте, Klapaucius, Вы писали:

K>>> Все дело в том, что таким исследованиям неоткуда взяться. Самый дальний родственник нынешнего Template Haskell и Nemerle — это, наверное, MetaML — а по нему и статей старее 1998-го года нет. Мне, как физику, совершенно непонятно, как могут плоды исследования 1998-го года быть опробированы в 1970-м.

G>>Вам как физику может быть вообще многое непонятно, так же как например мне, получившему образование computer science & applied math не понятны вопросы биологии и химии. То, что вам что-то непонятно — не может являться ни аргументом, ни серьезным вызовом computer science.

K>Позвольте несогласиться с Вами. Возможность опробировать методику за треть столетия до появления первых научных работ, в которых она разрабатывается это серьезный вызов скорее физике, а не computer science.


Предлагаю вам не соглашаться со мной предметно. От абстрактных разговоров о "методиках" я устал.

G>>и не генерируют код, как они делали в далеких 70-х, да?

K>Зло не в том, что код генерируется. Это как раз добро. Зло в том, какой код генерируется и как он генерируется. А зависит это от гигиеничности, метаязыка, доступности информации о типах, et cetera.

Зло не в том, какой код генерируется, ине в том, как он генерируется. Предлагаю вам прежде чем со мной спорить, ознакомится с моей позицией. Это — вежливо. Вы по крайней мере будете понимать, что я говорю, почему и о чем.

K>Вы лучше вот что скажите, я так понимаю, что Вам не нравится в основном изменения синтаксиса? Если так, то как Вы относитесь к тому, что в некоторых языках есть штатные средства вроде определения произвольных операторов (Prolog, Haskell, Scala...) и неявного создания замыканий как в Scala (по понятным причинам в Haskell можно и без этого обойтись)? Такие средства позволяют изменять синтаксис также как и макросы — но "гражданскими" средствами, никак особо не выделенными.


Вот эту ветку прочтите пожалуйста, там все написано. Это сообщение, и ниже по треду.
http://rsdn.ru/forum/message/2604188.1.aspx
Автор: Gaperton
Дата: 30.07.07
Re[37]: Являются ли макросы свидетельством недостаточной выр
От: Gaperton http://gaperton.livejournal.com
Дата: 06.08.07 16:28
Оценка: +1
Здравствуйте, Klapaucius, Вы писали:

G>>Это не "эрудиция", это плохая память, коллега . Все-таки, в 31 год тяжело вспомнить детали угребищного языка, на котором писал много, но в школе. Я с тех пор настолько много чему научился, что мне не стыдно забыть $ перед строковой переменной, а смешно .


K>Завидую. А мне вот становиться невыносимо стыдно всякий раз, как я что-нибудь забываю.


А мне нет, особенно если это бейсик 80-х годов. Надо будет — вспомню, я в себя верю. Но надеюсь, ЭТОГО мне вспоминать не понадобится.

G>>Все бейсики, как интерпретируемые языки, кроме некоторых исключений-компиляторов, проверяли типы в динамике...


K>А с чего Вы взяли, что Basic — интерпретируемый язык? Интерпретируемый язык или нет — зависит от его дизайна. Язык, который проектировали как статически типизированный можно компилировать и интерпретировать — но при интерпретации пользоваться бенефитами динамической типизации практически нельзя — дизайном не предусмотрена-с. Язык, который проектируется как язык с динамической типизацией — можно интерпретировать со всеми бенефитами динамики, но компилировать практически невозможно. Опять-таки дизайн.

K>Basic — язык, который относится к первым, а не ко вторым. Так что правильнее сказать Все бейсики, как компилируемые языки, проверяли типы при компиляции, за исключением скриптов-диалектов. От того, что есть интерпретатор Haskell и OCaml, они ведь динамическими не становяться?

Бейсик — с момента своего появления был интерпритируемым языком, и оставался таковым очень долго. Также, не было его единого стандарта — это не единый язык, а куча диалектов. Его сильно расширенные диалекты, далеко ушедшие от "бейсиков", проверявшие типы статически, появвлись только в конце 80-х начале 90-х. Турбо Бейсик, по моему, один из первых.

K>Речь шла об индустриальных динамических языках. Я вспомнил Smalltalk и незаслуженно забыл про Erlang. Но уж бейсик то точно из другой оперы. Все индустриальные GP бейсики — компиляторы.


Да ладно, предлагаю замять для ясности.
Re[38]: Являются ли макросы свидетельством недостаточной выр
От: konsoletyper Россия https://github.com/konsoletyper
Дата: 06.08.07 17:02
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Были там целочисленные значения у переменных, были. Плавающая запятая эмулировалась программно, и работала крайне медленно. Поэтому, интерпретатор различал целые числа и плавающие в динамике, несмотря на то, что этих постфиксов-префиксов (не помню уже) там не было. Так вел себя любой бейсик для слабых процов без аппаратной плавающей запятой, таких как Z80.


Я прекрасно знаю архитектуру Z80. Там любая перменная описывалась 5 байтами и все операции с ней делались через калькулятор (который по сути набор функций для расчётов с floating point). Был там способ закодировать целочисленное число, с которым калькулятор работал быстрее (кажется, для этого было специальное значение экспонены, которая, кстати, была целиком в 1-м байте). Этот калькулятор умел делать неявное приведение при необходимости. Так вот, всё это было именно на уровне калькулятора. С точки зрения бэйсика это был один "численный" тип. Кстати, учитывая то, что строки так же обрабатывались через калькулятор, то можно сказать, что в спектрумовском бэйсике был всего один базовый тип. Но это, конечно, не серьёзно.

K>>Таким же макаром я могу доказать, что и Хаскель — динамически типизированный. А всего-то и нужно, что написать интерпретатор, который не проверяет типы заранее, а добавляет метки типов ко всем объектам. Ах да, забыл, это даст нехороший побочный эффект! Все функции станут обладать свойством "type polymorphism"! Ну ничего, можно и этот недостаток залатать, если подумать как.


G>Таким макаром ты ничего доказать не можешь. В хаскеле есть декларации типов, а семантика стандарта предполагает статическую проверку. В бейсике ничего подобного нет. Там даже DIM — объявление массива не является декларацией — это конструктор массива, работающий в динамике — семантика такая.


Я могу написать интерпретатор Хаскелля, который типы вычисляет в рантайме, а не в компайлтайме, но при этом целиком соотв. семантике языка. Согласно твоей терминологии, Хаскелль будет динамически-типизированным. А вот, например, с Python, Perl, Ruby или PHP ничего подобного не выйдет. Так вот, внимание! Для старомодного бэйсика МОЖНО написать компилятор, выполняющим статические проверки типов! Вот отсюда я и делаю вывод, что на самом деле, бэйсик является стат. типизированным. Хотя, в случае бэйсика тяжело говорить о какой-либо типизации, как и в случае Лиспа.
... << RSDN@Home 1.2.0 alpha rev. 672>>
Re[37]: Являются ли макросы свидетельством недостаточной выр
От: konsoletyper Россия https://github.com/konsoletyper
Дата: 06.08.07 17:02
Оценка:
Здравствуйте, Klapaucius, Вы писали:

K>Впрочем, мне не особенно интересно участвовать во флейме по BASIC. Того что он начнется я вообще не ожидал. А вот еще один индустриальный динамический язык я все же забыл упомянуть. Erlang.


Кажется, мы говорили про индустрию 70-х. Так что всё в порядке, Erlang не в счёт.
... << RSDN@Home 1.2.0 alpha rev. 672>>
Re[29]: Являются ли макросы свидетельством недостаточной выр
От: WolfHound  
Дата: 06.08.07 17:03
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Гут. Ты все почти разрюхал.

Да ничего вы не разрюхали.

G> Именно так и надо делать для преобразований половины его цветовых пространств — у него там половина цветовых пространств переводятся друг в друга матричным преобразованием.

У меня есть несколько кластеров с линейными преобразованиями внутри кластера.

G> Судя по всему — именно здесь он вместо простого перемножения матриц макросами разворачивает формулы , по кратчайшему пути через граф определенных ручками преобразований. Жуть.

По другому НЕЛЬЗЯ.

G>Вторая половина приводится к гражданским пространствам типа RGB нелинейно,

К сведеню: RGB бывают разные.
И очень важно использовать именно тот RGB который нужен.
Иначе полезут артефакты.
Причем хорошо видно их только на специально подготовленных изображениях.
А на обычных фотографиях просто видно что что-то не так но вот что именно хз.

G>т.е. в терминах матричного линейного преобразования не описывается. Что тоже не проблема — при нашем с тобой подходе любое преобразование делается в два хода — из нелинейного в линейное, потом обратно в нелинейное.

Угу... с потерями эффективности, а иногда и точности.

G>Это устраняет необходимость в макроанализе страшного графа допустимых переходов между пространствами.

Не устраняет.
Ибо у меня есть много мест где можно срезать углы.
Причем искать руками все эти "срезы" у меня нет ни малейшего жилания. Да и времени это занимает много.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[41]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 06.08.07 17:52
Оценка: +2
Здравствуйте, GlebZ, Вы писали:

GZ>вторая запись не менее визуальна чем первая. И в такой записи, запросы вполне можно собирать.


К Хейлсбергу и Коробкину.

GZ>>>На фоне генерации грида и работы с бд — выигрыш будет очень незначительным.

IT>>Точно? Проверял или сам догадался?
GZ>Нет. Догадался.

Я так и знал.

GZ>Опять. Трансформация OQL-подобных запросов в SQL — не является ресурсоемкой задачей.(если конечно в Microsoft не напортачили )


Линк не шустр. Думаю, проблема не только в генерации SQL. Скорее всего проблема комплексная. Здесь посчитали задачу нересурсоёмкой, там догадались, что выигрыш будет незначительным и вот тебе результат. А потом мы удивляемся, почему 4 гига памяти и 4 ядра в процессоре не могут справиться с нашими задачами.

В общем, я твою точку зрения понял. Я её не разделяю.

IT>>Какая разница. Имея свои макросы я такую проблему решу быстро и эффективно.

GZ>Если ты сможешь выйти за рамки LINQ2SQL — то безусловно.

Мне не нужно выходить за эти рамки. Я вообще в них даже входить не собираюсь, если ты не понял.

GZ>А тут вопрос не декларатива/императива. Это всего лишь вопрос использования инструмента. А как ты его оформишь декларативно(с помощью макросов или без оных) или императивно — это твое личное дело.


Ещё раз посылаю тебя к Хейлсбергу. К Боксу тоже зайди.

GZ>>>Ага. Посему и удивился твоему утверждению про pass-through.

IT>>Ты можешь мне привести неубиваемые преимущества pass-through кода?
GZ>ООП.

ООП не может быть преимуществом сам по себе. Это тоже самое что сказать, что преимущество гвоздя в том, что он забивается молотком.

GZ>LINQ2SQL — можно считать заменителем или хелпером для DAL.


Ты вообще в курсе для чего нужен DAL?

GZ>Бизнес-логику полностью на нем не сделаешь.


Её вообще не надо делать. Напомню что такое pass-through:

class UI
{
  void OnLoad()
  {
    binder.List = BusinessLogic.GetCustomerList();
  }
}

class BusinessLogic
{
  List<Customer> GetCustomerList()
  {
    return DataAccessor.GetCustomerList();
  }
}

class DataAccessor
{
  List<Customer> GetCustomerList()
  {
    return ExecuteList<Customer>("SELECT * FROM Customer");
  }
}

Всё это теперь заменяется на:

class UI
{
  void OnLoad()
  {
    binder.List = from c in Customer select c;
  }
}

Можно для лучшей наглядности замешать сюда ещё и ad-hoc запрос.

Теперь сформулируем вопрос по-другому. Что тебе реально даст оставление двух таких pass-through методов в данном случае, учитывая что вся логика здесь диктуется UI? Только пожалуйста без ООП и прочей чуши. Лучше давай оперировать такими понятиями как сопровождаемость.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[38]: Являются ли макросы свидетельством недостаточной выр
От: Константин Л. Франция  
Дата: 06.08.07 19:10
Оценка:
Здравствуйте, IT, Вы писали:

IT>Здравствуйте, Константин Л., Вы писали:


IT>>>Для написания более сложных вещей желательно иметь полное представление.

КЛ>>Для изучения которого нужно потратить полгода.

IT>Откуда такие точные разведданные?


дык, посмотри на VladD2. Народ реально с ними парится.

IT>>>- обезъянкам будет трудно;

КЛ>>само собой, ведь другие обезьянки такого нахреначат...

IT>Именно. Те, кто нас с тобой считают обезъянками именно так и думают.


Только тут мы с тобой по разные стороны
Re[39]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 06.08.07 19:19
Оценка: :)
Здравствуйте, Константин Л., Вы писали:

IT>>Именно. Те, кто нас с тобой считают обезъянками именно так и думают.


КЛ>Только тут мы с тобой по разные стороны


По разные стороны чего? А... понял. Ты считаешь, что Хейлсберг вполне заслуженно считает нас с тобой обезъянками. Так?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[42]: Являются ли макросы свидетельством недостаточной выр
От: Cyberax Марс  
Дата: 07.08.07 05:46
Оценка:
Здравствуйте, IT, Вы писали:

IT>
IT>class UI
IT>{
IT>  void OnLoad()
IT>  {
IT>    binder.List = from c in Customer select c;
IT>  }
IT>}
IT>

IT>Можно для лучшей наглядности замешать сюда ещё и ad-hoc запрос.
Так кто мешает-то?

class UI
{
  void OnLoad()
  {
    binder.List = myMapper.select("from c in Customer select c").list();
  }
}

Нужно только сделать соответствующий mapper.
Sapienti sat!
Re[20]: Являются ли макросы свидетельством недостаточной выр
От: night beast СССР  
Дата: 07.08.07 06:29
Оценка:
Здравствуйте, Klapaucius, Вы писали:

K>>>Правильно ли я понял, что предлагается писать вручную реализации для всех возможных выражений.

E>>Нет. Не правильно. Но вы, я вижу, больше математик, чем программист. Может быть, что-то и не допоняли.

K>Что Вы! Я не просто "больше математик, чем программист" — я вообще не программист, а физик. Образования программиста я не получал.

K>И хотя некоторые физики не любят, когда их называют математиками, мне все равно очень приятно, спасибо.

Дорогой друг.
Мы очень рады что вы вообще не программист, но раз уж влезли в дискуссию, то потрудитесь изучить инструмент о котором рассуждаете.

Задачи на expression templates уже много лет не являются проблемой для С++ кодеров.
Если у вас с этим сложности, то почитайте документацию. Ссылки были озвучены.

Реализовывать в 1001 раз линейную алгебру для вас никто не будет.
Re[44]: Являются ли макросы свидетельством недостаточной выр
От: Sinclair Россия https://github.com/evilguest/
Дата: 07.08.07 06:40
Оценка: +2
Здравствуйте, IT, Вы писали:
IT>Едет, но хреново. На самом деле, при наличии макросов большинство выкрутасов хибернейта и биэлтулкита нафиг не нужны. Тот же маппинг как понятие появился исключительно благодаря лени разработчиков и нежеланию постоянно писать кучу тупого кода. Макросами эта задача решается влёт. Особенно зная контекст выполнения. Можно, кстати, попытаться вообще обойтись без создания объектов. Если отложить запрос до момента рендеринга, то мапить можно DataReader непосредственно в response стрим.
Ай, как хорошо сказал!
Вот тут, кстати, недалеко обсуждали мегастроки в хаскеле.
Я по диагонали статью прочел — она всё ж не шибко популярная, не то что Лукьяненко — но суть в целом уловил.
Там парни не то чтобы строки придумали — это ерунда. Они придумали способ редуцировать алгоритмы на строках и списках. Ленивость во всей красе.
Пример на пальцах: допустим, есть задача отфильтровать строку, оставив только заглавные гласные буквы. Одним из способов решения будет цепочка из двух фильтров — один для заглавных, другой для гласных.
Косяк в том, что
а) по строке придется пробегать два раза, а это не то же самое, что один раз, но медленнее — из-за кэша
б) неленивый алгоритм породит промежуточную строку, которая нафиг не нужна.

Умный программист напишет сразу фильтр с обоими предикатами, и обойдется одним проходом и без временного объекта.
Умный компилятор/рантайм сведет цепочку к оптимальному преобразованию.

Ты говоришь ровно о том же: если у нас есть цепочка мапперов DataReader->DTO->BO->XML->HTML, то самым оптимальным будет свернуть это всё в один маппер, который проджитится, заоптимизируется, и будет работать практически без выделения мусора и оптимально по кэшу. Сие и есть наша самая заветная мечта.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[40]: Являются ли макросы свидетельством недостаточной выр
От: Sinclair Россия https://github.com/evilguest/
Дата: 07.08.07 06:40
Оценка:
Здравствуйте, IT, Вы писали:
IT>Когда нам требуется построить запрос динамически, то синтаксис линка идёт в сад.
Как это в сад?
IT>Например, у нас есть несколько полей для задания фильтра. Если поле пустое, то мы по нему не фильтруем, если в нём есть какое-то значение, то мы его включаем в фильтр.
if (StartDate != null)
  q = q.where(p => p.StartDate >= StartDate)

Поэтому то линк и рулит.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[43]: Являются ли макросы свидетельством недостаточной выр
От: Sinclair Россия https://github.com/evilguest/
Дата: 07.08.07 06:40
Оценка: +2 :))
Здравствуйте, Cyberax, Вы писали:

C>
C>class UI
C>{
C>  void OnLoad()
C>  {
C>    binder.List = myMapper.select("from c in Customer select c").list();
C>  }
C>}
C>

C>Нужно только сделать соответствующий mapper.

Это мне напоминает Единую Теорию Поля. Скорее всего, Уравнение Всего имеет вот такой вид:
#A = 0;

где A — это некоторый вектор-потенциал, а # — какой-то дифференциальный оператор.
Осталось узнать, что за вектор и что за оператор. И этой фигней народ мается уже восемьдесят лет.
Так же и с маппером — примерно года с 95 если не раньше, народ пытается сделать маппер. Только они всё больше выходят какие-то на диво несоответствующие.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[42]: Являются ли макросы свидетельством недостаточной выр
От: GlebZ Россия  
Дата: 07.08.07 07:56
Оценка:
Здравствуйте, IT, Вы писали:

GZ>>вторая запись не менее визуальна чем первая. И в такой записи, запросы вполне можно собирать.

IT>К Хейлсбергу и Коробкину.
Нет. В контексте предыдущего обсуждения, я привел это как макрос который ограничивает функциональность.

GZ>>>>На фоне генерации грида и работы с бд — выигрыш будет очень незначительным.

IT>>>Точно? Проверял или сам догадался?
GZ>>Нет. Догадался.
IT>Я так и знал.

Факты в виде цифр есть?

GZ>>Опять. Трансформация OQL-подобных запросов в SQL — не является ресурсоемкой задачей.(если конечно в Microsoft не напортачили )

IT>Линк не шустр. Думаю, проблема не только в генерации SQL. Скорее всего проблема комплексная. Здесь посчитали задачу нересурсоёмкой, там догадались, что выигрыш будет незначительным и вот тебе результат. А потом мы удивляемся, почему 4 гига памяти и 4 ядра в процессоре не могут справиться с нашими задачами.
Искренне надеюсь что они внемлют твоему мнению и проведут нагрузочное тестирование. Пока что мы имеем только бету.

IT>В общем, я твою точку зрения понял. Я её не разделяю.

А по моему, нет. Я против такого термина как pass-through как плюса подхода LINQ2SQL. Также, я не особо верю что макросы, как аналогичный функционал, спасут мир и будут концептуально лучше чем LINQ2SQL.

IT>ООП не может быть преимуществом сам по себе. Это тоже самое что сказать, что преимущество гвоздя в том, что он забивается молотком.

ООП — это преимущество перед гипотетическими макросами. Его подводные камни — известны. И как писать сопровождаемый код вполне известно.

GZ>>LINQ2SQL — можно считать заменителем или хелпером для DAL.

IT>Ты вообще в курсе для чего нужен DAL?
Получение(изменение) данных, и трансформация из модели источника к логической модели и наоборот.

IT>
IT>class UI
IT>{
IT>  void OnLoad()
IT>  {
IT>    binder.List = from c in Customer select c;
IT>  }
IT>}
IT>

Пример достойный example или простейшего проекта.
IT>Можно для лучшей наглядности замешать сюда ещё и ad-hoc запрос.
Можешь показать как?

IT>Теперь сформулируем вопрос по-другому. Что тебе реально даст оставление двух таких pass-through методов в данном случае, учитывая что вся логика здесь диктуется UI?

Логика по любому диктуется UI. Если пользователь не чуствует работу той, или иной функции — то эта функция не нужна.
IT>Только пожалуйста без ООП и прочей чуши. Лучше давай оперировать такими понятиями как сопровождаемость.
OK. Кое что, ты уже описал. Нужно вставлять кэширование, секьюрити, логгирование и e.t.c. И желательно, чтобы вызовы были в одном слое, а посему — даже во избежание бардака стоит делать pass-thought когда оных функциональностей нет. Одни и те-же вызовы могут использоваться в различных прецедентах, в том числе которые могут быть написаны после оной итерации. В ситуации бардака, стоимость внесения изменений увеличивается. Ежели оные объекты еще публикуются через API (то есть должны быть отчуждаемы), то все совсем плохо. Но что совсем плохо — проект без выделенного слоя становится не тестируемым. А посему — LINQ2SQL может быть заменой(хедпером) DAL, но не более того. В остальном он сопровождаемых решений не дает.
Re[48]: Являются ли макросы свидетельством недостаточной выр
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 07.08.07 08:39
Оценка:
Здравствуйте, mkizub, Вы писали:

M>Здравствуйте, AndrewVK, Вы писали:


M>>>Процедурный подход безусловно мощнее, поскольку декларативный ограничен набором известных ему операций.


AVK>>Какое то у тебя узкое понимание декларативности. ФП это тоже декларативный подход.


M>Не вижу противоречий. Мое понимание включает в себя FP, пока ты определяешь функцию — ты в рамках декларативности.

M>Когда компилятор, на основе твоих определений, строит последовательность действий, необходимых для вычисления значения этой функции — это уже императив.

Ну и что? Исходный то код декларативен.

M>Разумеется, последовательность действий для вычисления значения функции может быть разной (в зависимости от алгоритма используемого компилятором),

M>в этом смысле ФП декларативен.

ФП декларативен в любых смыслах.
... << RSDN@Home 1.2.0 alpha rev. 688>>
AVK Blog
Re[45]: Являются ли макросы свидетельством недостаточной выр
От: deniok Россия  
Дата: 07.08.07 08:52
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Умный программист напишет сразу фильтр с обоими предикатами, и обойдется одним проходом и без временного объекта.

S>Умный компилятор/рантайм сведет цепочку к оптимальному преобразованию.

S>Ты говоришь ровно о том же: если у нас есть цепочка мапперов DataReader->DTO->BO->XML->HTML, то самым оптимальным будет свернуть это всё в один маппер, который проджитится, заоптимизируется, и будет работать практически без выделения мусора и оптимально по кэшу. Сие и есть наша самая заветная мечта.


Отлично пояснил!

Если бы все шаги DataReader->DTO->BO->XML->HTML были чистыми и ленивыми, то указание (в любой форме!) фильтрации на HTML стороне автоматически доехало бы до DataReader'а.
Re[39]: Являются ли макросы свидетельством недостаточной выр
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 07.08.07 09:00
Оценка:
Здравствуйте, konsoletyper, Вы писали:

K>Я могу написать интерпретатор Хаскелля, который типы вычисляет в рантайме, а не в компайлтайме, но при этом целиком соотв. семантике языка. Согласно твоей терминологии, Хаскелль будет динамически-типизированным.


Будет. Вот, к примеру, сиквел (возьмем SQL'92 для определенности) — динамически типизированный язык (это не значит что в нем типов нет!). Но совсем небольшой коррекции семантики и соответствующего компилятора хватает, чтобы сделать его статически типизированным. Сам язык при этом практически не меняется.
... << RSDN@Home 1.2.0 alpha rev. 688>>
AVK Blog
Re[44]: Являются ли макросы свидетельством недостаточной выр
От: Cyberax Марс  
Дата: 07.08.07 09:16
Оценка:
Здравствуйте, Sinclair, Вы писали:

C>>Нужно только сделать соответствующий mapper.

S>
S>Это мне напоминает Единую Теорию Поля. Скорее всего, Уравнение Всего имеет вот такой вид:
S>
S>#A = 0;
S>

S>где A — это некоторый вектор-потенциал, а # — какой-то дифференциальный оператор.
S>Осталось узнать, что за вектор и что за оператор. И этой фигней народ мается уже восемьдесят лет.
S>Так же и с маппером — примерно года с 95 если не раньше, народ пытается сделать маппер. Только они всё больше выходят какие-то на диво несоответствующие.
Почему-то, .NET-программисты страдают "туннельным видением" — все не-MS-технологии они просто не замечают. Удобные mapper'ы в виде iBatis'а и Hibernate работают в Java уже который год. И ничего, никакой LINQ не нужен.
Sapienti sat!
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.