Re: Идеальный синтаксис (постановка задачи)
От: l33thaxor  
Дата: 12.02.11 00:20
Оценка: +1 :))) :))) :))) :)))

Хвилищевский ел клюкву, стараясь не морщиться. Он ждал, что все скажут: «Какая сила характера!» Но никто не сказал ничего.
— Даниил Хармс

Re[7]: Идеальный синтаксис (постановка задачи)
От: Undying Россия  
Дата: 16.02.11 15:50
Оценка: -2 :)
Здравствуйте, Ziaw, Вы писали:

Z>Функции виде CreateXxx это лишь одно из принятых соглашений (FactoryMethod).


Причем это соглашение полностью соответствует естественным языкам и здравому смыслу.

Z>Точно так же можно принять соглашение, что функция с именем Xxx() создает объект типа Xxx. Никаких препятствий для этого нет.


Только такое соглашение будет противоречить естественным языкам и здравому смыслу, соответственно увеличив порог вхождения и усложнив понимание.

Z>Более того, конструкторы должны вести ровно так же, как любые другие функции языка, оператор new этому мешает.


Вот, например, в C# можно написать _.Tuple(key, value), но надо писать new Tuple<TKey, TValue>(key, value). Но мешает записать new Tuple(key, value) вовсе не оператор new, а косность создателей C#. Сам по себе new ничему помешать не может.
Re: Идеальный синтаксис (постановка задачи)
От: Vaako Украина  
Дата: 12.02.11 10:10
Оценка: 13 (2)
Здравствуйте, DarkGray, Вы писали:

DG>примечание: синтаксис трактуется в узком смысле, как способ записи информации в виде текста (последовательности символов)


DG>Что такое информация?

DG>для лучшего понимания задачи синтаксиса, стоит немного отвлечься и разобраться что такое "информация".

DG>описание дается упрощенное, чтобы его можно было себе наглядно представить (всё тоже самое можно формально ввести с помощью той же теории категории, но это будет менее визуально представимо)


DG>в итоге, информация, в общем виде — это именованный граф термов c элементами самоподобия, где и вершины и ребра также могут являться графами


DG>Задача, проблемы и критерии лучшести синтаксиса

DG>Основная задача синтаксиса — представить информационный граф в виде текста.

DG>Основная проблема синтаксиса — с помощью линейной структуры текста и фиксированного набора символов(термов) передать графовую структуру информации и бесконечный набор термов


DG>Критерии лучшего синтаксиса:

DG>компактность,
DG>стабильность(контекстно-независимость),
DG>атомарность изменений,
DG>близость к текстам, которыми обмениваются между собой люди.

DG>Гипотеза: т.к. задача, проблемы и критерии хорошести синтаксиса фиксированные, то и задача выделения лучшего синтаксиса имеет одно решение (или конечный небольшой набор решений).

DG>


DG>продолжение следует...


Дискретизация логики вынуждает вас дробить цельно воспринимаемое на отдельные факты, явления, понятия и категории, проводя между ними искусственные границы.

Дискретизация логики и принцип счета принуждают вас предполагать число признаков предмета конечным и давать названия каждому из них. Отсюда появляется весьма сомнительная возможность отчленять одни признаки от других — прием, называемый вами абстрагированием. Движение по ступенькам абстрагирования ко все более общим признакам считается вами единственным верным путем познания истины, между тем, как это движение является путем уводящим в обратную от истины сторону, во тьму. Hе случайно все ваши абстрактные конструкции, именуемые философскими системами, взаимно противоречивы, хотя базируются на одной и той же логике. Шаг за шагом погружаясь во мрак по ступенькам абстракции, шаг за шагом теряя связь с реальным миром, философские системы постепенно утрачивают ориентировку и доходят до того, что в тупиковой точке этого движения, на бессмысленный вопрос о первенстве материи или духа, дают диаметрально противоположные ответы. Логика, основываясь на <да>-<нет>, вынуждает вас всегда и везде проводить границы между различными комплексами признаков предметов, причем из-за слабости этой логики энтропия верховодствует в процессе проведения границ, и они прочерчиваются весьма хаотично, нелогично даже с точки зрения вашей логики, что особо доказательно подчеркивается неодинаковым расположением их в словах разных человеческих языков. Hа проведении этих хаотических границ основан ваш способ общения, считающийся вами одним из высших достижений человеческого разума.
Идеальный синтаксис (постановка задачи)
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 11.02.11 22:29
Оценка: 5 (1) :)
примечание: синтаксис трактуется в узком смысле, как способ записи информации в виде текста (последовательности символов)

Что такое информация?
для лучшего понимания задачи синтаксиса, стоит немного отвлечься и разобраться что такое "информация".

описание дается упрощенное, чтобы его можно было себе наглядно представить (всё тоже самое можно формально ввести с помощью той же теории категории, но это будет менее визуально представимо)

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

в итоге, информация, в общем виде — это именованный граф термов c элементами самоподобия, где и вершины и ребра также могут являться графами

Задача, проблемы и критерии лучшести синтаксиса
Основная задача синтаксиса — представить информационный граф в виде текста.

Основная проблема синтаксиса — с помощью линейной структуры текста и фиксированного набора символов(термов) передать графовую структуру информации и бесконечный набор термов

Критерии лучшего синтаксиса:
компактность,
стабильность(контекстно-независимость),
атомарность изменений,
близость к текстам, которыми обмениваются между собой люди.

Гипотеза: т.к. задача, проблемы и критерии хорошести синтаксиса фиксированные, то и задача выделения лучшего синтаксиса имеет одно решение (или конечный небольшой набор решений).


Приемы используемые синтаксисом
Для решения своей задачи синтаксис использует определенный набор приемов.

Разрыв в структуре(информация — граф, а текст — линеен(список)) решается как:
а) граф представляется в виде дерева, а остальные связи вводятся маркировкой элементов дерева и "использованием" маркеров
b) дерево записывается с помощью скобочной записи

Разрыв между конечным числом символов и бесконечностью термов(например, чисел) решается как:
терм кодируется последовательностью символов. конец последовательности помечается спец. символом.

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

Большая часть дальнейших улучшений синтаксиса сводятся к борьбе со скобочной записью и борьбе с конфликтом между исходными термами и термами синтаксиса.(это в следующий раз)

продолжение следует...
Re[3]: Идеальный синтаксис (постановка задачи)
От: Silver_S Ниоткуда  
Дата: 12.02.11 17:52
Оценка: +2
Здравствуйте, DarkGray, Вы писали:

S_S>> Какой из вариантов лучше? :

S_S>>1) var v = new MyClass();
S_S>>2) var v = MyClass();
DG>имхо, второй.

Тут думаю мнения разделятся, new наверное не просто в наследство достался от С++ -> Java.
Второй вариант компактнее, и логично вроде все — конструктор это функция.
Но слишком уж специфическая семантика у этой функции.
Удобнее видеть костыли, подсказывающие что это конструктор, чтобы быстрее текст читался.

Если все такие специфические тонкости из ЯП повыкидывать, что останется — голый язык структур данных.
Голый XML, или S-выражения. Ну все согласятся — синтаксис замечательный, логичный стройный. Но писать программы на нем не будут.

Главная характеристика хорошего синтаксиса, ИМХО, высокая читабельность текста на нем.
Это в этом что ли пункте учтено? : "близость к текстам, которыми обмениваются между собой люди."
Re[4]: Идеальный синтаксис (постановка задачи)
От: Фанатик Ад http://vk.com/id10256428
Дата: 12.02.11 19:01
Оценка: :))
Здравствуйте, Курилка, Вы писали:


Ф>>никогда не понимал, зачем конструктору и деструктору иметь имя.


К>а Constructor и Destructor — это не имена?


Это больше похоже на ключевые слова.
Всё сказанное выше — личное мнение, если не указано обратное.
Re[6]: Идеальный синтаксис (постановка задачи)
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.02.11 06:49
Оценка: +2
Здравствуйте, Real 3L0, Вы писали:

R3>Ну, таким образом можно отказаться и от "var".


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

В случае же new ничего подобного не происходит. Но при этом нужен не хилый вывод типов (способный отличить свойсво, переменную и конструктор с одинаковыми именами).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Идеальный синтаксис (постановка задачи)
От: Ziaw Россия  
Дата: 15.02.11 17:52
Оценка: +2
Здравствуйте, Undying, Вы писали:

U>Вообще-то функции, которые создают объект, но не начинаются со слова Create


Функции виде CreateXxx это лишь одно из принятых соглашений (FactoryMethod). Точно так же можно принять соглашение, что функция с именем Xxx() создает объект типа Xxx. Никаких препятствий для этого нет.

Более того, конструкторы должны вести ровно так же, как любые другие функции языка, оператор new этому мешает.
Re[9]: Идеальный синтаксис (постановка задачи)
От: Undying Россия  
Дата: 16.02.11 15:53
Оценка: -2
Здравствуйте, DarkGray, Вы писали:

U>> Замени в этом коде создание таблицы на что-то чуть менее стандартное и понять что код делает будет невозможно.


DG>так замени и покажи, где появляется не однозначность.


Если тебе не понятно, что названия tr и td сами по себе не несут никакой смысловой нагрузки и соответственно не могут быть поняты без предварительного обучения, то показывать тебе что либо бесполезно, т.к. у тебя проблемы со здравым смыслом и элементарной логикой.
Re: Идеальный синтаксис (постановка задачи)
От: FR  
Дата: 12.02.11 06:52
Оценка: 1 (1)
Здравствуйте, DarkGray, Вы писали:

DG>Большая часть дальнейших улучшений синтаксиса сводятся к борьбе со скобочной записью и борьбе с конфликтом между исходными термами и термами синтаксиса.(это в следующий раз)


Если не бороться со скобками то идеальный синтаксис уже давно изобретен s-выражения и соответственно язык Lisp.
Другой вариант позволяющий описывать более сложные структуры меньшим количеством скобок — Refal.
Re[2]: Идеальный синтаксис (постановка задачи)
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 12.02.11 16:44
Оценка: -1
S_S> Какой из вариантов лучше? :
S_S>1) var v = new MyClass();
S_S>2) var v = MyClass();

имхо, второй.
Re[2]: Идеальный синтаксис (постановка задачи)
От: Фанатик Ад http://vk.com/id10256428
Дата: 12.02.11 17:31
Оценка: :)
Здравствуйте, Silver_S, Вы писали:

S_S> Какой из вариантов лучше? :

Вот такой:
var v : MyClass;
v = MyClass.Constructor();
...
v.Destructor();
-----------------------
никогда не понимал, зачем конструктору и деструктору иметь имя.
Всё сказанное выше — личное мнение, если не указано обратное.
Re[4]: Идеальный синтаксис (постановка задачи)
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.02.11 06:52
Оценка: +1
Здравствуйте, Курилка, Вы писали:

К>а Constructor и Destructor — это не имена?


А чем это будет отличаться от оператора new/delete?

Что до имен конструкторов, то в одном правильном языке они имеют имя this. Это очень удобно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Идеальный синтаксис (постановка задачи)
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 13.02.11 14:37
Оценка: :)
VD>

VD>информация — сведения об окружающем мире и протекающих в нем процессах, воспринимаемые человеком или специальным устройством.{см.С.И.Ожегов. "Словарь русского языка". Москва. 1990г.).


очень наивное неточное определение.

VD>Какие на фиг графы? Какие на фиг дуги? Информацию можно представлять как угодно и чем угодно. Вот поток битов — это самое что ни на есть привычное представление информации.


ага, а число — это поток цифр.

не путай — представление информации, и саму информацию.

VD>А уж для разговора о синтаксисе языков вообще не нужно говорить о информации.


говорить об инструмента, не говоря о цели — это чревато.

VD>Потом каких языков? Естественных? Языков программирования? Это очень разные вещи.


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

DG>>Основная задача синтаксиса — представить информационный граф в виде текста.


VD> то как интерпретируются символы (в широком смысле этого слова) в языке.


вот оно интерпретировалось-интерпретировалось, и что в результате?
а в результате интерпретации сначала строится AST — (и все доп. символы отваливаются — уходят скобки, кавычки, пробелы, сепараторы и т.д.)
а после того как в асте, резолвятся все ссылки — получается граф.
дальше который уже и обрабатывается.

VD>Синтаксис — это формат строения предложений и словосочетаний. Если говорить о синтаксисе ЯП, то это описание структуры программы, т.е.


структуру программы уж точно к синтаксису отношение не имеет.
структура уже определяется моделью языка.

если брать тот же xml — это хорошо видно.
xml описывает лишь кодирование информации с помощью символов (сама структура описывается где-то еще).

VD>Опять же. Какой на фиг граф? Зачем загонять себя в какие-то рамки?


это описание того, с чем приходится иметь дело.
для тебя описание атомов в виде таблицы менделеева тоже лишние рамки, которые мешают свободе творчества?


DG>>Основная проблема синтаксиса — с помощью линейной структуры текста и фиксированного набора символов(термов) передать графовую структуру информации и бесконечный набор термов


VD>Это скорее задача парсера. И опять же причем тут граф? Я конечно понимаю, что дерево это тоже вид графа. Но как-то дерево здесь лучше подходит. Или ты умудрился выразиться настолько сложно, что тебя нельзя понять.


парсер — это уже инструмент, который работает с данным синтаксисом.

например, xml — это язык, который описывает в первую очередь лишь синтаксическую часть.
и только видов парсеров xml — как грязи: sax, reader, dom

VD>Любитель ML-еподобных языков (Хаскель, ОКамл) скажет что лучше синтаксис вызова функций без скобок. Любитель С-подобных языков скажет обратное. И оба они будут правы. Тоже самое будет если сравнить отступный синтаксис и скобочный (Питон и С). Или Лисповый и С-ишный.


"скобки" всегда есть, если нужно выразить дерево, другое дело что они могут быть завуалированными, как, например, в питоне
в C-ишном синтаксисе — для скобочной записи используются весь спектр скобок: фигурные, круглые, квадратные, угловые.
в паскале — скобочная запись кодируется с begin/end, круглые, прямоугольные
в xml-е — скобки в виде тегов
в питоне — скобки заменяются на отступы
в lisp — только круглые скобки
в ml/haskell — остались только круглые скобки для записи мат. выражений, а деревянная структура программы передается с помощью набора ключевых слов (let, in, if/then и т.д.), т.е. здесь нет фиксирования на уровне синтаксиса единого способа задания дерева (имхо, это неудобно для чтения)


DG>>Разрыв в структуре(информация — граф, а текст — линеен(список)) решается как:

DG>>а) граф представляется в виде дерева, а остальные связи вводятся маркировкой элементов дерева и "использованием" маркеров

VD>Зачем связи для синтаксиса?


синтаксис нужен для передачи связей, а не "связи для синтаксиса"
Re[8]: Идеальный синтаксис (постановка задачи)
От: Ziaw Россия  
Дата: 13.02.11 20:37
Оценка: +1
Здравствуйте, Real 3L0, Вы писали:

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


R3>>>Ну, таким образом можно отказаться и от "var".

DG>>а как тогда понять что это есть объявление переменной?

R3>Объявление в тот момент, когда она первый раз встречается в тексте.


R3>Т.е. new несёт и визуальную помощь — помогает визуально выделить, что вот такая-то переменная теперь вот это вот означает.


R3>Сравни:

R3>
R3>Class1 cl = new Class1();
R3>cl.DoWork();
R3>cl = new Class2();
R3>cl.DoWork();
R3>

R3>и
R3>
R3>cl = Class1();
R3>cl.DoWork();
R3>cl = Class2();
R3>cl.DoWork();
R3>


R3>
R3>cl = FactoryMethod();
R3>cl.DoWork();
R3>cl = FactoryMethod2();
R3>cl.DoWork();
R3>
Re[5]: Идеальный синтаксис (постановка задачи)
От: Undying Россия  
Дата: 14.02.11 04:38
Оценка: -1
Здравствуйте, DarkGray, Вы писали:

DG>но я сейчас считаю, что особой разницы между функцией и конструктором нет с точки зрения вызова, поэтому new можно убрать из-за малой полезности.


Вообще-то функции, которые создают объект, но не начинаются со слова Create, называются функциями с побочными эффектами и являются приговором для читабельности кода. Видя вызов var v = MyClass() невозможно понять, что главной задачей этого вызова является создание нового экземпляра объекта, поэтому это кошмарный код.
Re[17]: Идеальный синтаксис (постановка задачи)
От: Курилка Россия http://kirya.narod.ru/
Дата: 15.02.11 11:26
Оценка: +1
Здравствуйте, DarkGray, Вы писали:

DG>например, во фразе:

DG>
DG>table().paint-to(color('green'))
DG>

DG>слово create лишнее, т.к. на самом деле никакой новый стол не создается, и новый цвет тем более(они уже все созданы реальным миром)
DG>
DG>createTable().paint-to(createColor('green'))
DG>


По-моему там и color — лишнее
Точней яб записал как:
table().color(green)

Правда, наверное, не всеми color воспринимается как глагол, поэтому, возможно стоит оставить paint-to (хотя корректность его меня смущает)
Re[8]: Идеальный синтаксис (постановка задачи)
От: FR  
Дата: 15.02.11 16:05
Оценка: +1
Здравствуйте, Real 3L0, Вы писали:


R3>Да, я про это и говорю. Но нужен не только вывод типов у компилятора, но нужна и память программисту — он должен помнить, что возвращает Class1(): инициализированный класс, или какой-то результат функции.

R3>Не знаю, на сколько это действительно важно.

От языка зависит, например в питоне во первых все объект и поэтому все что возвращают функции все-равно объекты, во вторых сами классы тоже первоклассные объекты, и функции могут возвращать не только объекты но и классы:
def create(cls):
    return cls()
    
    
def tst(cls):
    x = create(cls)
    print x, type(x)
    

tst(int)
tst(str)
tst(float)

0 <type 'int'>
 <type 'str'>
0.0 <type 'float'>

и из этой же первоклассности следует что классы не больше чем экземпляры метаклассов и вызов конструктора класса не более чем вызов оператора __call__ метакласса. И в такой модели оператор new совершенно излишен.
Re: Идеальный синтаксис (постановка задачи)
От: Mystic Украина http://mystic2000.newmail.ru
Дата: 17.02.11 10:40
Оценка: +1
Здравствуйте, DarkGray, Вы писали:

DG>Критерии лучшего синтаксиса:

DG>компактность,
DG>стабильность(контекстно-независимость),
DG>атомарность изменений,
DG>близость к текстам, которыми обмениваются между собой люди.

Устойчивость к опечаткам
Простота разбора
Re[2]: Идеальный синтаксис (постановка задачи)
От: Mystic Украина http://mystic2000.newmail.ru
Дата: 17.02.11 10:41
Оценка: +1
Здравствуйте, Mystic, Вы писали:

M>Устойчивость к опечаткам

M>Простота разбора
+ возможность хорошей диагностики ошибок
Re[20]: Идеальный синтаксис (постановка задачи)
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 17.02.11 18:34
Оценка: +1
U>Выделенное важно. User не readonly сущность, поэтому к ней эти рассуждения не применимы.

имхо, удобнее рассматривать, что user — это immutable сущность.
Re[21]: Идеальный синтаксис (постановка задачи)
От: Undying Россия  
Дата: 18.02.11 09:55
Оценка: -1
Здравствуйте, DarkGray, Вы писали:

U>>Выделенное важно. User не readonly сущность, поэтому к ней эти рассуждения не применимы.

DG>имхо, удобнее рассматривать, что user — это immutable сущность.

Мутабельность сущности определяется условием задачи. От того, что ты мутабельность сэмулируешь на иммутабельных объектах, мутабельность сущности никуда не денется.
Re[9]: Идеальный синтаксис (постановка задачи)
От: Jack128  
Дата: 18.02.11 10:03
Оценка: +1
Здравствуйте, Ziaw, Вы писали:


Z>Я кстати не очень понимаю, почему в C# сделали так как сделали, Хейлсберг в делфи использовал как конструкторы обычные статик методы.


Это не так, в дельфи конструкторы — это тоже отдельные сущности, и не везде, где можно юзать статические методы, можно юзать конструкторы.
Re[22]: Идеальный синтаксис (постановка задачи)
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 18.02.11 11:10
Оценка: +1
U>Мутабельность сущности определяется условием задачи. От того, что ты мутабельность сэмулируешь на иммутабельных объектах, мутабельность сущности никуда не денется.

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

стандартный пример, берем список одинаковых элементов
т.к. мир иммутабельный, то нет разницы между двумя следующими записями
var item = item(x:1);
var list = list(item, item, item);

и
var list = list(item(x:1), item(x:1), item(x:1));

рассмотрим операцию изменения:
list[0].x = 2;
т.к. в записи указан только первый элемент списка, то это означает, что изменится должен именно первый элемент списка, без изменения остальных

для первой записи списка такое изменение приведет к:
var item = item(x:1);
var list = list(item.patch(x:2), item, item);

для второй записи
var list = list(item(x:2), item(x:1), item(x:1));

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

зы
этот пример показывает, что если мир иммутабельный, то даже несмотря на операции изменяющие мир — нам не важно, создавались ли отдельные экземпляры или не создавались
Re[24]: Идеальный синтаксис (постановка задачи)
От: VladD2 Российская Империя www.nemerle.org
Дата: 21.02.11 01:48
Оценка: :)
Здравствуйте, Undying, Вы писали:

U>Если же мы используем мегаконцепцию эмуляция мутабельных сущностей...


У... как все запущено!

Undying, при всем моем к тебе уважении, не лезь в этот спор, а лучше потрать пару месяцев на освоение ФП.

Уверяю тебя ты быстро поймешь, что твоя голова была полна домыслов и заблуждений.

Объяснить тебе что-то в ходе спора не выйдет. Так что послушай меня. Не закрепляй свои заблуждения.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[26]: Идеальный синтаксис (постановка задачи)
От: VoidEx  
Дата: 22.02.11 12:54
Оценка: +1
Здравствуйте, Undying, Вы писали:

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


VE>>Не создаёт, а возвращает. Может, у неё таблица заранее созданных списков есть? Какую именно часть действия надо заключать в название? А если описание функции подразумевает возврат списка от 0 до N без раскрытия деталей, откуда именно она его берёт? Что тогда писать? ReturnListFrom0ToN?


U>В общем случае это будет FindOrCreate. Если создание не обладает побочными эффектами (т.е. создании при получении любым способом гарантируется), тогда Get.


По мне так это раскрытие деталей реализации.
Ибо можно назвать CreateListUsingForLoopFrom0toNAndCallingAddMethod.
А можно range.
Зависит от того, что является важным. Если мне не важно, как именно там получается список, то range (который может быть реализован через CreateListUsing...), когда будет важно — выберу конкретную реализацию.
Re[27]: Идеальный синтаксис (постановка задачи)
От: Undying Россия  
Дата: 22.02.11 16:57
Оценка: :)
Здравствуйте, VoidEx, Вы писали:

VE>Зависит от того, что является важным. Если мне не важно, как именно там получается список, то range (который может быть реализован через CreateListUsing...), когда будет важно — выберу конкретную реализацию.


Любые изменения состояния программы должны быть видны при чтении кода. Т.к. именно изменения состояния программы определяют сложность понимания кода. Создание объекта изменяет состояние программы, получение объекта — нет, соответственно эту разницу необходимо видеть из названия метода.

Исключениями являются те изменения состояния, которые не видимы извне, например, ленивая инициализация переменной (с точки зрения внешнего кода это нельзя отличить от создания переменной в конструкторе) или вызов автоматического кэша (с точки зрения внешнего кода это нельзя отличить от пересчета состояния кэша в момент изменения источника кэша). Для этих случаев название не должно содержать указание на изменение.
Re[10]: Идеальный синтаксис (постановка задачи)
От: VladD2 Российская Империя www.nemerle.org
Дата: 23.02.11 11:35
Оценка: :)
Здравствуйте, Undying, Вы писали:

U>Если тебе не понятно, что названия tr и td сами по себе не несут никакой смысловой нагрузки и соответственно не могут быть поняты без предварительного обучения, то показывать тебе что либо бесполезно, т.к. у тебя проблемы со здравым смыслом и элементарной логикой.


Это не у него проблемы со здравым смыслом, а у тебя проблемы с восприятием непривычного тебе.

А без предварительного обучения вообще ничего понять нельзя. Мне казалось, что смешно озвучивать такие банальные вещи, как — "Для того чтобы прочесть текст сначала нужно выучить алфавит". Все что нужно знать для восприятия примера — это то, что tr и td — это типы, и то что создание объекта не требует указания new.

Приведенный пример (с tr и td) — это классический дсл основанный на реинтерпретации базового синтаксиса. Я не знаю кому он может быть не понятен. Разве что ли тем кто не знаком с HTML-ем.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Идеальный синтаксис (постановка задачи)
От: VladD2 Российская Империя www.nemerle.org
Дата: 23.02.11 11:49
Оценка: :)
Здравствуйте, vdimas, Вы писали:

FR>>Хорошая кстати книга, но тяжелая, математики многовато, буду летом читать


V>А уточни плиз. Тоже интересно стало.


http://rsdn.ru/res/book/prog/FoundationsForPL.xml
Автор(ы):
Дж. Митчелл


Если Вы хотите написать или уже пишете свой язык программирования №1 в мире, то стоит заботать данную книгу. Книга большая, очень много математики, читается тяжело,
но создание языка программирования №1 — требует жертв. Книга представляет собой теоретическое введение в лямбда-исчисление (основу современных языков программирования).
Материал книги использовался при проведении 3-х семестровых курсов в Стэнфорде. Изучение книги позволяет при создании своего языка встать "на плечи гигантов" и переиспользовать опыт по выделению базовых абстракций из которых строятся языки программирования.


Книга очень похожа на Дракона своей бестолковостью. После того как описанные в ней концепции становятся понятны эту книгу становится возможно прочесть и понять. До того только кашу в голове разведешь. Результат мы тут все наблюдаем.

Потом она отражает один (и довольно ортодоксальный) взгляд на ЯП — взгляд с точки зрения теории типизированного лямда-исчисления.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Идеальный синтаксис (постановка задачи)
От: VladD2 Российская Империя www.nemerle.org
Дата: 23.02.11 11:51
Оценка: :)
Здравствуйте, night beast, Вы писали:

V>>Вот, правильную тему поднял. Я пытался как-то "на бумаге" рарабатывать ЯП, который был мне удобен. Брал некие популярные задачи. Под одни из них синтаксис заточишь — в других местах сценариях неудобно. А вводить в синтаксис case или first-letter conventions, как в Хаскеле или Фортран — как-то несовременно.


NB>и к чему в итоге пришел?


Сам не догадываешься? Пачка макулатуры .
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Идеальный синтаксис (постановка задачи)
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 12.02.11 10:41
Оценка:
FR>Если не бороться со скобками то идеальный синтаксис уже давно изобретен s-выражения и соответственно язык Lisp.

в нем дерево неименованное, что не хватает
и не зафиксирован синтаксис дать имя узлу, а потом на него сослаться.

s-выражение — умеет описывать лишь однородное(неименованное) дерево термов, а этого не достаточно.

xml в этом плане лучше:
a) дерево именованное,
b) есть фиксирование способа привязки к узлам имен, и отчасти как на это сослаться(через id, xlink и т.д.), но пользуются редко из-за большой громоздкости.

FR>Другой вариант позволяющий описывать более сложные структуры меньшим количеством скобок — Refal.


спасибо, посмотрю
Re: Идеальный синтаксис (постановка задачи)
От: batu Украина  
Дата: 12.02.11 10:46
Оценка:
Здравствуйте, DarkGray, Вы писали:

DG>примечание: синтаксис трактуется в узком смысле, как способ записи информации в виде текста (последовательности символов)


Ну, есть такой синтаксис. И что?
Re[3]: Идеальный синтаксис (постановка задачи)
От: FR  
Дата: 12.02.11 11:13
Оценка:
Здравствуйте, DarkGray, Вы писали:

DG>в нем дерево неименованное, что не хватает

DG>и не зафиксирован синтаксис дать имя узлу, а потом на него сослаться.

DG>s-выражение — умеет описывать лишь однородное(неименованное) дерево термов, а этого не достаточно.


Это, да но если рассматривать лисп как язык а не чисто s-выражения то там это все вполне нормально описывается.

DG>xml в этом плане лучше:

DG>a) дерево именованное,
DG>b) есть фиксирование способа привязки к узлам имен, и отчасти как на это сослаться(через id, xlink и т.д.), но пользуются редко из-за большой громоздкости.

Лучше http://en.wikipedia.org/wiki/YAML в отличии от XML вполне человекочитабелен.
Re[2]: Идеальный синтаксис (постановка задачи)
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 12.02.11 11:31
Оценка:
V>Дискретизация логики вынуждает вас дробить цельно воспринимаемое на отдельные факты, явления, понятия и категории, проводя между ними искусственные границы.

другого алгоритмизированного способа познания мира все равно нет. используя этот метод, стоит только соблюдать ТБ — и не возводить в ранк абсолюта введенные ради процесса познания границы.

зы
противоположный способ — помедитируйте, смотря в потолок, и понимание изучаемого объекта во всей его многогранности само на вас упадёт — работает лишь в сказках
Re[4]: Идеальный синтаксис (постановка задачи)
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 12.02.11 11:39
Оценка:
FR>Это, да но если рассматривать лисп как язык а не чисто s-выражения то там это все вполне нормально описывается.

через let? но это немножко не то, семантика другая
да и не все ссылки таким образом можно записать.

FR>Лучше http://en.wikipedia.org/wiki/YAML в отличии от XML вполне человекочитабелен.


в yaml-е есть плюсы и минусы.
из минусов — необходимо много знать, чтобы сгенерить валидный yaml без возможности аттак вида injection-s
имена объявлять и использовать можно, что плюс, но минус что все эти имена глобальны, что затрудняет описывание многих структур.

т.е. в yaml основной плюс — близость к текстам на ЕЯ
Re[5]: Идеальный синтаксис (постановка задачи)
От: FR  
Дата: 12.02.11 11:53
Оценка:
Здравствуйте, DarkGray, Вы писали:

FR>>Это, да но если рассматривать лисп как язык а не чисто s-выражения то там это все вполне нормально описывается.


DG>через let? но это немножко не то, семантика другая

DG>да и не все ссылки таким образом можно записать.

В принципе макросами можно задать свою семантику.
Re[6]: Идеальный синтаксис (постановка задачи)
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 12.02.11 12:06
Оценка:
FR>В принципе макросами можно задать свою семантику.

принцип "сделай сам" очень плох в данной ситуации, т.к. приводит к тому, что две разные программы не смогут договориться с друг другом.
Re: Идеальный синтаксис (постановка задачи)
От: Silver_S Ниоткуда  
Дата: 12.02.11 16:10
Оценка:
Здравствуйте, DarkGray, Вы писали:

DG>Критерии лучшего синтаксиса:

DG>компактность,
DG>стабильность(контекстно-независимость),
DG>атомарность изменений,
DG>близость к текстам, которыми обмениваются между собой люди.

Какой из вариантов лучше? :
1) var v = new MyClass();
2) var v = MyClass();
Re[3]: Идеальный синтаксис (постановка задачи)
От: Курилка Россия http://kirya.narod.ru/
Дата: 12.02.11 17:37
Оценка:
Здравствуйте, Фанатик, Вы писали:

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


S_S>> Какой из вариантов лучше? :

Ф>Вот такой:
Ф>var v : MyClass;
Ф>v = MyClass.Constructor();
Ф>...
Ф>v.Destructor();
Ф>-----------------------
Ф>никогда не понимал, зачем конструктору и деструктору иметь имя.

а Constructor и Destructor — это не имена?
Re[4]: Идеальный синтаксис (постановка задачи)
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 12.02.11 18:38
Оценка:
S_S>Главная характеристика хорошего синтаксиса, ИМХО, высокая читабельность текста на нем.
S_S>Это в этом что ли пункте учтено? : "близость к текстам, которыми обмениваются между собой люди."

то, что ты затронул это ближе к стабильности (контексто-независимости).
без new получается, что выражение F(..) — может быть функцией, а может быть конструктором — в зависимости от контекста.
неудобство такого прыганья критично — если функция и конструктор демонстрируют значительно разное поведение.

но я сейчас считаю, что особой разницы между функцией и конструктором нет с точки зрения вызова, поэтому new можно убрать из-за малой полезности.
Re[5]: Идеальный синтаксис (постановка задачи)
От: Real 3L0 Россия http://prikhodko.blogspot.com
Дата: 12.02.11 19:36
Оценка:
Здравствуйте, DarkGray, Вы писали:

DG>но я сейчас считаю, что особой разницы между функцией и конструктором нет с точки зрения вызова, поэтому new можно убрать из-за малой полезности.


Ну, таким образом можно отказаться и от "var".
Вселенная бесконечна как вширь, так и вглубь.
Re[5]: Идеальный синтаксис (постановка задачи)
От: hardcase Пират http://nemerle.org
Дата: 12.02.11 20:08
Оценка:
Здравствуйте, DarkGray, Вы писали:

DG>особой разницы между функцией и конструктором нет с точки зрения вызова, поэтому new можно убрать из-за малой полезности.


В одном замечательном языке так и поступили.
/* иЗвиНите зА неРовнЫй поЧерК */
Re[6]: Идеальный синтаксис (постановка задачи)
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 12.02.11 20:21
Оценка:
R3>Ну, таким образом можно отказаться и от "var".

а как тогда понять что это есть объявление переменной?
Re[7]: Идеальный синтаксис (постановка задачи)
От: Real 3L0 Россия http://prikhodko.blogspot.com
Дата: 12.02.11 20:45
Оценка:
Здравствуйте, DarkGray, Вы писали:

R3>>Ну, таким образом можно отказаться и от "var".

DG>а как тогда понять что это есть объявление переменной?

Объявление в тот момент, когда она первый раз встречается в тексте.

Т.е. new несёт и визуальную помощь — помогает визуально выделить, что вот такая-то переменная теперь вот это вот означает.

Сравни:
Class1 cl = new Class1();
cl.DoWork();
cl = new Class2();
cl.DoWork();

и
cl = Class1();
cl.DoWork();
cl = Class2();
cl.DoWork();
Вселенная бесконечна как вширь, так и вглубь.
Re[4]: Идеальный синтаксис (постановка задачи)
От: Фанатик Ад http://vk.com/id10256428
Дата: 12.02.11 21:17
Оценка:
Здравствуйте, Курилка, Вы писали:

Ф>>v = MyClass.Constructor();

Ф>>...
Ф>>v.Destructor();
Ф>>-----------------------
Ф>>никогда не понимал, зачем конструктору и деструктору иметь имя.

К>а Constructor и Destructor — это не имена?

Ф>>Это больше похоже на ключевые слова.
К>
Тем не менее мне эти слова нравятся.
Всё сказанное выше — личное мнение, если не указано обратное.
Re[5]: Идеальный синтаксис (постановка задачи)
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.02.11 06:46
Оценка:
Здравствуйте, DarkGray, Вы писали:

S_S>>Главная характеристика хорошего синтаксиса, ИМХО, высокая читабельность текста на нем.

S_S>>Это в этом что ли пункте учтено? : "близость к текстам, которыми обмениваются между собой люди."

DG>то, что ты затронул это ближе к стабильности (контексто-независимости).

DG>без new получается, что выражение F(..) — может быть функцией, а может быть конструктором — в зависимости от контекста.
DG>неудобство такого прыганья критично — если функция и конструктор демонстрируют значительно разное поведение.

DG>но я сейчас считаю, что особой разницы между функцией и конструктором нет с точки зрения вызова, поэтому new можно убрать из-за малой полезности.


В Немерле так и сделано. Особых проблем не замечено. Разве что с КодДомом некоторые проблемы есть, так как без типизации АСТ невозможно сгенерировать КодДом. Но так как в немерле без типизации много чего нельзя отличить, то это не существенно.

Ну, а в С++-подобных языках new используется по двум причинам. Плохой (или вообще отсутствующий) вывод типв и своеобразная семантика конструктора. Дизайнеры этих языков рассматривают конструктор как метод инициализирующий уже созданную структуру. Но это не более чем представление. Никто не мешает рассматривать конструктор как функцию даже в этих языках.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Идеальный синтаксис (постановка задачи)
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.02.11 06:55
Оценка:
Здравствуйте, FR, Вы писали:

FR>Если не бороться со скобками то идеальный синтаксис уже давно изобретен s-выражения и соответственно язык Lisp.


Я бы сказал, что это очень своеобразные идеалы. По сути у Лиспа вообще нет синтаксиса. В нем есть AST. И ты вынужден программировать в AST.

Плюс синтаксис лиспа рассчитан на динамическую типизации. Как только появляются типы, то все становится печальнее.

FR>Другой вариант позволяющий описывать более сложные структуры меньшим количеством скобок — Refal.


А как там это выглядит?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: Идеальный синтаксис (постановка задачи)
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.02.11 07:26
Оценка:
Здравствуйте, DarkGray, Вы писали:

DG>примечание: синтаксис трактуется в узком смысле, как способ записи информации в виде текста (последовательности символов)


Ужас! Запутал все к чертовой матери. Зачем вся эти философия?

DG>Что такое информация?


Да вот же она — лошадь — Василий Иванович (с)

информация — сведения об окружающем мире и протекающих в нем процессах, воспринимаемые человеком или специальным устройством.{см.С.И.Ожегов. "Словарь русского языка". Москва. 1990г.).


Какие на фиг графы? Какие на фиг дуги? Информацию можно представлять как угодно и чем угодно. Вот поток битов — это самое что ни на есть привычное представление информации.

А уж для разговора о синтаксисе языков вообще не нужно говорить о информации.

Потом каких языков? Естественных? Языков программирования? Это очень разные вещи.

DG>Задача, проблемы и критерии лучшести синтаксиса


Где ты взял это слово "лучшести"?

DG>Основная задача синтаксиса — представить информационный граф в виде текста.


Синтаксис — это формат строения предложений и словосочетаний. Если говорить о синтаксисе ЯП, то это описание структуры программы, т.е. то как интерпретируются символы (в широком смысле этого слова) в языке.

Опять же. Какой на фиг граф? Зачем загонять себя в какие-то рамки?

DG>Основная проблема синтаксиса — с помощью линейной структуры текста и фиксированного набора символов(термов) передать графовую структуру информации и бесконечный набор термов


Это скорее задача парсера. И опять же причем тут граф? Я конечно понимаю, что дерево это тоже вид графа. Но как-то дерево здесь лучше подходит. Или ты умудрился выразиться настолько сложно, что тебя нельзя понять.

DG>Критерии лучшего синтаксиса:

DG>компактность,
DG>стабильность(контекстно-независимость),
DG>атомарность изменений,
DG>близость к текстам, которыми обмениваются между собой люди.

Что за "атомарность изменений"? Что меняем и где?

Все критерии сомнительны. Все же хороший синтаксис — это:
1. Субъективный показатель.
2. Нечто большее нежели набор каких-то атрибутов.

Любитель ML-еподобных языков (Хаскель, ОКамл) скажет что лучше синтаксис вызова функций без скобок. Любитель С-подобных языков скажет обратное. И оба они будут правы. Тоже самое будет если сравнить отступный синтаксис и скобочный (Питон и С). Или Лисповый и С-ишный.

DG>Гипотеза: т.к. задача, проблемы и критерии хорошести синтаксиса фиксированные, то и задача выделения лучшего синтаксиса имеет одно решение (или конечный небольшой набор решений).

DG>


Не имеет. Твой фиксированный список — это самообман. Столько людей столько и мнений.

Все что мы можем сделать — это объединиться в некоторый коллектив и выработать для этого коллектива некоторый список синтаксических предпочтений.

DG>Приемы используемые синтаксисом

DG>Для решения своей задачи синтаксис использует определенный набор приемов.

Синтаксис — это не процесс, а декларация. Он не может использовать приемы.

DG>Разрыв в структуре(информация — граф, а текст — линеен(список)) решается как:

DG>а) граф представляется в виде дерева, а остальные связи вводятся маркировкой элементов дерева и "использованием" маркеров

Зачем связи для синтаксиса?

DG>b) дерево записывается с помощью скобочной записи


А почему не отступной? И какими скобками будем пользоваться?
Другими словами мы фанаты Лиспа или С?

DG>Разрыв между конечным числом символов и бесконечностью термов(например, чисел) решается как:

DG>терм кодируется последовательностью символов. конец последовательности помечается спец. символом.

Ужас какой! А зачем все это?

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


Ты пытаешься путем философствования изобрести AST? Или это ты в синтаксис хочешь напихать скобок и спец.символов-терминаторов? Что-то я ничего не пойму.

DG>Большая часть дальнейших улучшений синтаксиса сводятся к борьбе со скобочной записью и борьбе с конфликтом между исходными термами и термами синтаксиса.(это в следующий раз)


Абстрактная философия в народе зовущаяся фигней.

DG>продолжение следует...


А может не стоит?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Идеальный синтаксис (постановка задачи)
От: Mna 404 and heavy formation
Дата: 13.02.11 07:27
Оценка:
Здравствуйте, DarkGray, Вы писали:

R3>>Ну, таким образом можно отказаться и от "var".


DG>а как тогда понять что это есть объявление переменной?



Есть такой ЯП Python. и он работает.

Какой из вариантов лучше? :
1) var v = new MyClass();
2) v = MyClass()

вариант 2 — это на питоне.

Но вот одна "моя" недавняя бага имела возможной причиной то, что чисто визуально
создание объекта не было видно, не подсвечивалось, в то время как это должно было быть не
создание нового объекта а передача существующего, присваивание.

**

Возможные варианты:
* идеального синтаксиса нет — у каждого он свой. и это индивидуально.
* есть. и это Питон. )) потому что он лаконичный, но не до степени мозголомности K/J/Apl
Re[3]: Идеальный синтаксис (постановка задачи)
От: FR  
Дата: 13.02.11 07:52
Оценка:
Здравствуйте, VladD2, Вы писали:


FR>>Если не бороться со скобками то идеальный синтаксис уже давно изобретен s-выражения и соответственно язык Lisp.


VD>Я бы сказал, что это очень своеобразные идеалы. По сути у Лиспа вообще нет синтаксиса. В нем есть AST. И ты вынужден программировать в AST.


Это да, но любителей не останавливает

VD>Плюс синтаксис лиспа рассчитан на динамическую типизации. Как только появляются типы, то все становится печальнее.


Ну тот же QI вполне прилично выглядит, конечно и вывод типов
в этом неплохо помогает.

FR>>Другой вариант позволяющий описывать более сложные структуры меньшим количеством скобок — Refal.


VD>А как там это выглядит?


Примерно так (звездочки комментарии аналогичные //):

  * <Parse e.Arithm-expr>  ==  e.Tree
  * e.Tree  == s.Operation (e.Tree-1) e.Tree-2
  *         == s.Operand
  *         ==  empty

  Parse {
    e.Expr, <Last ('+-') e.Expr()>: e1 s.Op(e2) =
                     s.Op(<Parse e1>) <Parse e2>;
    e.Expr, <Last ('*/') e.Expr()>: e1 s.Op(e2)
          = s.Op(<Parse e1>) <Parse e2>;
     e1'^'e2 = '^'(<Parse e1>) <Parse e2>;
     s.Symb, <Type s.Symb>: 'F's.Symb = s.Symb;
     s.Symb, <Type s.Symb>: 'N's.Symb = s.Symb;
     (e.Expr) = <Parse e.Expr>;
      = ;
     e.Exp = 
        <Prout 'Syntax error.Cannot parse 'e.Exp>
        <BR 'compl=' Fail>;
         };


Дальше смотри тут.
Re[5]: Идеальный синтаксис (постановка задачи)
От: Курилка Россия http://kirya.narod.ru/
Дата: 13.02.11 07:53
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Курилка, Вы писали:


К>>а Constructor и Destructor — это не имена?


VD>А чем это будет отличаться от оператора new/delete?


VD>Что до имен конструкторов, то в одном правильном языке они имеют имя this. Это очень удобно.


Ты автору этих имён задай вопрос
Re[8]: Идеальный синтаксис (постановка задачи)
От: Real 3L0 Россия http://prikhodko.blogspot.com
Дата: 13.02.11 11:09
Оценка:
Здравствуйте, Mna, Вы писали:

Mna>Возможные варианты:

Mna>* идеального синтаксиса нет — у каждого он свой. и это индивидуально.
Mna>* есть. и это Питон. )) потому что он лаконичный, но не до степени мозголомности K/J/Apl

Я в силу своих возможностей веду исследовательский проект по созданию взаимодействия ("человек" или "компьютер") — ("человек" или "компьютер").
Хотя это, конечно, уровнем повыше, чем присвоение переменных, но вот, через некоторое время мне стали попадаться ситуации, когда "действие", которое должно быть выполнено с объектом, надо указывать в обязательном порядке. Ибо однозначно — неоднозначность.
Т.е. Питон в моём случае — плохой вариант.
Вселенная бесконечна как вширь, так и вглубь.
Re[4]: Идеальный синтаксис (постановка задачи)
От: Real 3L0 Россия http://prikhodko.blogspot.com
Дата: 13.02.11 11:12
Оценка:
Здравствуйте, FR, Вы писали:

FR>Ну тот же QI вполне прилично выглядит, конечно и вывод типов

FR>в этом неплохо помогает.

На Немерле похоже?
Вселенная бесконечна как вширь, так и вглубь.
Re[5]: Идеальный синтаксис (постановка задачи)
От: FR  
Дата: 13.02.11 11:24
Оценка:
Здравствуйте, Real 3L0, Вы писали:

R3>На Немерле похоже?


У обоих заимствованный из ML паттерн матчинг
Re[2]: Идеальный синтаксис (постановка задачи)
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 13.02.11 14:43
Оценка:
DG>>продолжение следует...

VD>А может не стоит?


стоит. надо же кому-то теорию программирования двигать, и повышать научную культуру российских разработчиков.
Re[5]: Идеальный синтаксис (постановка задачи)
От: Фанатик Ад http://vk.com/id10256428
Дата: 13.02.11 14:47
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Курилка, Вы писали:


К>>а Constructor и Destructor — это не имена?


VD>А чем это будет отличаться от оператора new/delete?


Внешним видом
Всё сказанное выше — личное мнение, если не указано обратное.
Re[3]: Идеальный синтаксис (постановка задачи)
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.02.11 17:49
Оценка:
Здравствуйте, DarkGray, Вы писали:

DG>>>продолжение следует...


VD>>А может не стоит?


DG>стоит. надо же кому-то теорию программирования двигать, и повышать научную культуру российских разработчиков.


Не обижайся, но то что ты деалешь — это профанация. К науке это отношения не имеет.

Я понимаю, что ты прочел интересную и умну книги и теперь в тебе бьет фонтан энтузиазма. Но говорить надо только если есть что сказать, а не только потому что хочется.

Естественно все ИМХО.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Идеальный синтаксис (постановка задачи)
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 13.02.11 18:53
Оценка:
VD>Я понимаю, что ты прочел интересную и умну книги и теперь в тебе бьет фонтан энтузиазма.

да-да, я прочел целую одну книгу
Re[5]: Идеальный синтаксис (постановка задачи)
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.02.11 19:00
Оценка:
Здравствуйте, DarkGray, Вы писали:

VD>>Я понимаю, что ты прочел интересную и умну книги и теперь в тебе бьет фонтан энтузиазма.


DG>да-да, я прочел целую одну книгу


Я про последнее время. Видно, что это тебя вдохновило. Но вот идей как-то не видно. Какая-то пустая философия. Читаешь и кроме недоумения (и возможно раздражения) ничего не испытываешь.

И вообще, может вместо никому не нужной теории (ее выше крыши) может лучше прикнуть к тем кто эту теорию реализует на практике? Ведь видно же что тебя интересуют наши разработки. В них науки больше чем в сотнях вумных книг. Увидишь на практике что важно, а что нет. А потому же сможешь и стройную теорию толкнуть.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Идеальный синтаксис (постановка задачи)
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 13.02.11 19:28
Оценка:
VD>И вообще, может вместо никому не нужной теории (ее выше крыши) может лучше прикнуть к тем кто эту теорию реализует на практике? Ведь видно же что тебя интересуют наши разработки.

конечно, интересует. мне интересно насколько хорошо в итоге получилось реализовать ту или иную идею.
и стоит или не стоит эту идею реализовывать в своей среде разработке. и если стоит — то также, лучше или совсем по другому.
Re[8]: Идеальный синтаксис (постановка задачи)
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 13.02.11 21:16
Оценка:
R3>Объявление в тот момент, когда она первый раз встречается в тексте.

так пойдет, если переменные имутабельны, и не могут переопределяться.
иначе, это не стойко к ошибкам, и не видно область видимости переменной.

R3>Т.е. new несёт и визуальную помощь — помогает визуально выделить, что вот такая-то переменная теперь вот это вот означает.


вообще переиспользование переменных зло, и я бы предпочел чтобы было:

если переменные запрещено переиспользовать на уровне языка
c1 = Class1();
c1.DoWork();

c2 = Class2();
c2.DoWork();


или так если допускается переиспользование
var c1 = Class1();
c1.DoWork();

var c2 = Class2();
c2.DoWork();
Re[9]: Идеальный синтаксис (постановка задачи)
От: Mna 404 and heavy formation
Дата: 14.02.11 01:13
Оценка:
Здравствуйте, Real 3L0, Вы писали:

Mna>>Возможные варианты >...Питон. потому что он лаконичный...


R3>Я в силу своих возможностей веду исследовательский проект по созданию взаимодействия ("человек" или "компьютер") — ("человек" или "компьютер").

R3>...через некоторое время мне стали попадаться ситуации, когда "действие", которое должно быть выполнено с объектом, надо указывать в обязательном порядке.
Действие указывать — кому надо, для чего надо?
Программно — если есть AST то сгенерировать действие — не проблема. Человеку — если заставлять писать явно, то это с моей точки зрения неэффективно через то, что нелаконично: языки развиваются в высокоуровневость через то что многие действия уходят в автоматически-генерируемые компилятором, а явное указание прямо противоположно этому. то есть в ряду явного указывания в самом начале находится ассемблер с которого всё началось.
а вот в сторону как бы поменьше указать, но чтоб однозначно было, и понятно было б — вот бы это я назвал хорошим или потенциально (как горизонт) идеальным синтаксисом.

R3> Ибо однозначно — неоднозначность.

R3>Т.е. Питон в моём случае — плохой вариант.
на вкус. "плохость" варианта проявляется при смене языков. если писать то с языком где new надо явно указывать, то где не надо, тогда проявится.
и опять же, парзер Python-а понимает, оно для него — однозначно.

Тут слабое звено — человек. И исключить этого нельзя. Попытка сверхоптимизировать приводит к злу чаще чем думают.
Например, сборщик мусора вроде улучшает уровень, а на самом деле снимает возможность (там где только GC) толково проектировать потребление памяти, и через то, что программисту якобы теперь не нужно об этом думать, потребление памяти, прораммами в целом, растет.
Re[8]: Идеальный синтаксис (постановка задачи)
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 14.02.11 01:25
Оценка:
R3>Т.е. new несёт и визуальную помощь — помогает визуально выделить, что вот такая-то переменная теперь вот это вот означает.

кстати, если вдаваться в историю, то:
сначала (в C++) было Class() для создания на стеке и new Class() для создание на хипе
потом (в C#/Java) на стеке создавать объекты стало невозможно, и осталось только new Class()
Re[7]: Идеальный синтаксис (постановка задачи)
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.02.11 02:29
Оценка:
Здравствуйте, DarkGray, Вы писали:

DG>конечно, интересует. мне интересно насколько хорошо в итоге получилось реализовать ту или иную идею.

DG>и стоит или не стоит эту идею реализовывать в своей среде разработке. и если стоит — то также, лучше или совсем по другому.

Что за среда?

Что касается идей, то они в огромной степини зависят от реализации. Интересные вещи вообще появляются на стыке. Вот был Pratt сто лет. И был PEG чуть меньше, но тоже не мало. А соединить их никто не додумался. Ведь на первый взгляд не совместимые вещи. Лексерный Пратт и безлексерный ПЕГ. А вот получилось, и похоже бенефиты будут потрясающие. В пору кандидатскую писать .
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Идеальный синтаксис (постановка задачи)
От: FR  
Дата: 14.02.11 06:00
Оценка:
Здравствуйте, DarkGray, Вы писали:

VD>>Я понимаю, что ты прочел интересную и умну книги и теперь в тебе бьет фонтан энтузиазма.


DG>да-да, я прочел целую одну книгу


Хорошая кстати книга, но тяжелая, математики многовато, буду летом читать
Re[6]: Идеальный синтаксис (постановка задачи)
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 14.02.11 10:08
Оценка:
U>Вообще-то функции, которые создают объект, но не начинаются со слова Create, называются функциями с побочными эффектами и являются приговором для читабельности кода.

побочными эффектами называют обычно что-то другое

U> Видя вызов var v = MyClass() невозможно понять, что главной задачей этого вызова является создание нового экземпляра объекта, поэтому это кошмарный код.


расскажи тогда, что является целью функции с названием MyClass, как не создание объекта класса MyClass?
создание объекта YourClass что ли? или деструкция объекта MyClass? что-то еще?

вот красивый код, зачем здесь еще всякие new? что они добавляют?
var table = table
(
  style:{class:'main'},
  tr(td('A'), td('B')),
  tr(td('1'), td('2')),
  tr(td('3'), td('4')),
);


зы
слово new еще важно в C++, т.к. там для каждого new необходимо обязательно вызвать симметричную функции delete.
но в языках с GC и этого нет.
Re[7]: Идеальный синтаксис (постановка задачи)
От: Undying Россия  
Дата: 14.02.11 10:20
Оценка:
Здравствуйте, DarkGray, Вы писали:

U>>Вообще-то функции, которые создают объект, но не начинаются со слова Create, называются функциями с побочными эффектами и являются приговором для читабельности кода.

DG>побочными эффектами называют обычно что-то другое

Это либо функция с побочным эффектом, либо функция, название которой не содержит информацию о выполняемом действии. И первое, и второе очень плохо.

U>> Видя вызов var v = MyClass() невозможно понять, что главной задачей этого вызова является создание нового экземпляра объекта, поэтому это кошмарный код.


DG>расскажи тогда, что является целью функции с названием MyClass, как не создание объекта класса MyClass?


Это просто функция с плохим (не самодокументирующимся) названием. Функция с плохим названием может делать все что угодно.

DG>создание объекта YourClass что ли? или деструкция объекта MyClass? что-то еще?


Я правильно понял, что если тебе нужен метод создающий объект, то ты сейчас пишешь не CreateSomeObject(), а SomeObject()?

DG>вот красивый код, зачем здесь еще всякие new? что они добавляют?


И как понять, что tr и td это конструкторы? А не некие функции, делающие что угодно?

DG>
DG>var table = table
DG>(
DG>  style:{class:'main'},
DG>  tr(td('A'), td('B')),
DG>  tr(td('1'), td('2')),
DG>  tr(td('3'), td('4')),
DG>);
DG>


Вообще это кошмарный код, т.к. имена в нем абсолютно нечитаемы. Замени в этом коде создание таблицы на что-то чуть менее стандартное и понять что код делает будет невозможно.
Re[8]: Идеальный синтаксис (постановка задачи)
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 14.02.11 10:33
Оценка:
DG>>расскажи тогда, что является целью функции с названием MyClass, как не создание объекта класса MyClass?

U>Это просто функция с плохим (не самодокументирующимся) названием. Функция с плохим названием может делать все что угодно.


ты не увиливай — ты расскажи что может делать функция с название Zzzz, где Zzz — это существительное.


DG>>создание объекта YourClass что ли? или деструкция объекта MyClass? что-то еще?


U>Я правильно понял, что если тебе нужен метод создающий объект, то ты сейчас пишешь не CreateSomeObject(), а SomeObject()?


DG>>вот красивый код, зачем здесь еще всякие new? что они добавляют?


U>И как понять, что tr и td это конструкторы? А не некие функции, делающие что угодно?


потому что tr и td — это существительные.
Re[8]: Идеальный синтаксис (постановка задачи)
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 14.02.11 10:36
Оценка:
U> Замени в этом коде создание таблицы на что-то чуть менее стандартное и понять что код делает будет невозможно.

так замени и покажи, где появляется не однозначность.
а так это всё голословность, и ретроградство.
Re[9]: Идеальный синтаксис (постановка задачи)
От: Undying Россия  
Дата: 14.02.11 10:38
Оценка:
Здравствуйте, DarkGray, Вы писали:

DG>ты не увиливай — ты расскажи что может делать функция с название Zzzz, где Zzz — это существительное.


Любая функция (конструктор в том числе) это действие, действие это глагол, соответственно функция не имеющая в названии глагола это не понятно что.

U>>Я правильно понял, что если тебе нужен метод создающий объект, то ты сейчас пишешь не CreateSomeObject(), а SomeObject()?


На этот вопрос почему не ответил?
Re[10]: Идеальный синтаксис (постановка задачи)
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 14.02.11 10:45
Оценка:
DG>>ты не увиливай — ты расскажи что может делать функция с название Zzzz, где Zzz — это существительное.

U>Любая функция (конструктор в том числе) это действие, действие это глагол, соответственно функция не имеющая в названии глагола это не понятно что.


т.е. ты в своем коде не используешь свойств?
это же тоже всё действия.
и в их названий — нет описания действий.

методы toString/fromString, наверное, тоже не используешь?
переписал их на расовополноценные — createString и createFromString?

U>>>Я правильно понял, что если тебе нужен метод создающий объект, то ты сейчас пишешь не CreateSomeObject(), а SomeObject()?


U>На этот вопрос почему не ответил?


потому что в шарпе так все равно нельзя
а в q# — да, и так экспериментирую
Re[7]: Идеальный синтаксис (постановка задачи)
От: Real 3L0 Россия http://prikhodko.blogspot.com
Дата: 14.02.11 10:53
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>В случае же new ничего подобного не происходит. Но при этом нужен не хилый вывод типов (способный отличить свойсво, переменную и конструктор с одинаковыми именами).


Да, я про это и говорю. Но нужен не только вывод типов у компилятора, но нужна и память программисту — он должен помнить, что возвращает Class1(): инициализированный класс, или какой-то результат функции.
Не знаю, на сколько это действительно важно.
Вселенная бесконечна как вширь, так и вглубь.
Re[10]: Идеальный синтаксис (постановка задачи)
От: Real 3L0 Россия http://prikhodko.blogspot.com
Дата: 14.02.11 11:15
Оценка:
Здравствуйте, Mna, Вы писали:

R3>>Я в силу своих возможностей веду исследовательский проект по созданию взаимодействия ("человек" или "компьютер") — ("человек" или "компьютер").

R3>>...через некоторое время мне стали попадаться ситуации, когда "действие", которое должно быть выполнено с объектом, надо указывать в обязательном порядке.
Mna>Действие указывать — кому надо, для чего надо?

Типа того — кому сделать, что сделать.

Mna>... Человеку — если заставлять писать явно, то это с моей точки зрения неэффективно через то, что нелаконично: языки развиваются в высокоуровневость через то что многие действия уходят в автоматически-генерируемые компилятором, а явное указание прямо противоположно этому. то есть в ряду явного указывания в самом начале находится ассемблер с которого всё началось.

Mna>а вот в сторону как бы поменьше указать, но чтоб однозначно было, и понятно было б — вот бы это я назвал хорошим или потенциально (как горизонт) идеальным синтаксисом.

Не получится. Например, даже вроде бы понятная команда "отправить сообщение", если вдуматься, содержит неоднозначности: "отправить" — как?, "сообщение" — что за сообщение?
Желание "поменьше указывать", я пока думаю реализовать через объединение команд, например, если было две команды "помыть посуду" и "налить воды", то после объединения получим одну команду "налить воды", которая будет уметь "мыть посуду, при отсутствии чистой посуды". Конечно, тут тоже появляются новые неопределённости, ибо "желания человеческие неисповедимы".
Вселенная бесконечна как вширь, так и вглубь.
Re[8]: Идеальный синтаксис (постановка задачи)
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 14.02.11 11:23
Оценка:
DG>>конечно, интересует. мне интересно насколько хорошо в итоге получилось реализовать ту или иную идею.
DG>>и стоит или не стоит эту идею реализовывать в своей среде разработке. и если стоит — то также, лучше или совсем по другому.

VD>Что за среда?


сверхцель — манипулирование идеями
локальная цель — иметь удобный инструмент для обработки информации


VD>Что касается идей, то они в огромной степини зависят от реализации.


скорее — они зависят от того, насколько их удалось скомбинировать с друг другом, а хорошая реализация уже закономерный результат этой комбинации

VD> Интересные вещи вообще появляются на стыке. Вот был Pratt сто лет. И был PEG чуть меньше


и здесь ты говоришь — именно про успехи комбинаций идей, а не про успехи реализации
Re[9]: Идеальный синтаксис (постановка задачи)
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.02.11 12:15
Оценка:
Здравствуйте, DarkGray, Вы писали:

DG>сверхцель — манипулирование идеями

DG>локальная цель — иметь удобный инструмент для обработки информации

У меня уже есть удобный инструмент для обработки информации. Называется Total Commander. Позволяет манипулировать идеями на раз. Передвигать их, удалять, добавлять...
Понимаешь к чему я клоню?

DG>скорее — они зависят от того, насколько их удалось скомбинировать с друг другом, а хорошая реализация уже закономерный результат этой комбинации


Так и есть, но это детали. Там еще море нюансов.

VD>> Интересные вещи вообще появляются на стыке. Вот был Pratt сто лет. И был PEG чуть меньше


DG>и здесь ты говоришь — именно про успехи комбинаций идей, а не про успехи реализации


Ага. Но без хорошей реализации это бы все было фигней. В начале проекта я сдалал малюсенькое предложение — предложил хранить и информацию об откате и позицию в одной переменной (все виданные мной реализации (кроме LPEG) хранили две разных переменных в лучшем случае). Мелочь, казалось бы, но без нее скорость была бы не той, так как алгоритм во много берет грубой силой (низкоуровневостью реализации).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: Идеальный синтаксис (постановка задачи)
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.02.11 12:21
Оценка:
Здравствуйте, Real 3L0, Вы писали:

R3>Да, я про это и говорю. Но нужен не только вывод типов у компилятора, но нужна и память программисту — он должен помнить, что возвращает Class1(): инициализированный класс, или какой-то результат функции.

R3>Не знаю, на сколько это действительно важно.

На самом деле не очень важно. По крайней мере ни одного замечания о неудобстве такого подхода не было. А вот экономия всего 4 символов, как не странно дает положительный эффект когда описываются ветвистые структуры данных.

В немерле на подобный выбор подтолкнуло наличие паттерн-матчинга. В ПМ объекты должны выглядеть так же как при их создании (они выражаются через конструкторы), и было бы странно использовать new при создании и не использовать в ПМ. А использование new в ПМ сделало бы код менее читаемым.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Идеальный синтаксис (постановка задачи)
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 14.02.11 12:29
Оценка:
VD> У меня уже есть удобный инструмент для обработки информации. Называется Total Commander. Позволяет манипулировать идеями на раз. Передвигать их, удалять, добавлять...

он не позволяет главное — комбинировать идеи, или другими словами одну идею трансформировать под действием другой идеи.



VD>В начале проекта я сдалал малюсенькое предложение — предложил хранить и информацию об откате и позицию в одной переменной (все виданные мной реализации (кроме LPEG) хранили две разных переменных в лучшем случае).


и это тоже есть идея
Re[10]: Идеальный синтаксис (постановка задачи)
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 14.02.11 12:30
Оценка:
VD>Ага. Но без хорошей реализации это бы все было фигней.

но теоретического предела все равно же и близко не удалось достичь.
значит где-то еще есть неоптимальности в реализации
Re[11]: Идеальный синтаксис (постановка задачи)
От: Undying Россия  
Дата: 14.02.11 12:38
Оценка:
Здравствуйте, DarkGray, Вы писали:

U>>Любая функция (конструктор в том числе) это действие, действие это глагол, соответственно функция не имеющая в названии глагола это не понятно что.


Соответственно я не понимаю, почему отсутствие действия означает создание. Понять это невозможно, это можно только запомнить, т.е. это неочевидно, а, значит, плохо.

DG>т.е. ты в своем коде не используешь свойств?

DG>это же тоже всё действия.

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

DG>методы toString/fromString, наверное, тоже не используешь?

DG>переписал их на расовополноценные — createString и createFromString?

Предлоги в, из подразумевают преобразование, даже в естественных языках. Соответственно аналогия не к месту, фраза "некоторый объект" никакого действия не подразумевает.

U>>>>Я правильно понял, что если тебе нужен метод создающий объект, то ты сейчас пишешь не CreateSomeObject(), а SomeObject()?


DG>потому что в шарпе так все равно нельзя

DG>а в q# — да, и так экспериментирую

В смысле? В шарпе нельзя написать DatabaseHlp.TableForImei() вместо DatabaseHlp.CreateTableForImei()?
Re[12]: Идеальный синтаксис (постановка задачи)
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 14.02.11 12:41
Оценка:
DG>>потому что в шарпе так все равно нельзя
DG>>а в q# — да, и так экспериментирую

U>В смысле? В шарпе нельзя написать DatabaseHlp.TableForImei() вместо DatabaseHlp.CreateTableForImei()?


да, можно.
только и первое, и второе — пример ужасного кода
Re[12]: Идеальный синтаксис (постановка задачи)
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 14.02.11 12:43
Оценка:
ты для начала ответь — что именно необходимо выносить в название функции?
Re[13]: Идеальный синтаксис (постановка задачи)
От: Undying Россия  
Дата: 14.02.11 12:54
Оценка:
Здравствуйте, DarkGray, Вы писали:

DG>ты для начала ответь — что именно необходимо выносить в название функции?


Действие, которое функция выполняет.
Re[14]: Идеальный синтаксис (постановка задачи)
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 14.02.11 13:02
Оценка:
DG>>ты для начала ответь — что именно необходимо выносить в название функции?

U>Действие, которое функция выполняет.


полный ответ, пожалуйста.
вот есть произвольная функция — что именно должно быть отражено в названии функции.
Re: Идеальный синтаксис (постановка задачи)
От: vdimas Россия  
Дата: 14.02.11 13:05
Оценка:
Здравствуйте, DarkGray, Вы писали:

Вот, правильную тему поднял. Я пытался как-то "на бумаге" рарабатывать ЯП, который был мне удобен. Брал некие популярные задачи. Под одни из них синтаксис заточишь — в других местах сценариях неудобно. А вводить в синтаксис case или first-letter conventions, как в Хаскеле или Фортран — как-то несовременно.
Re[8]: Идеальный синтаксис (постановка задачи)
От: vdimas Россия  
Дата: 14.02.11 13:09
Оценка:
Здравствуйте, Real 3L0, Вы писали:

R3>Да, я про это и говорю. Но нужен не только вывод типов у компилятора, но нужна и память программисту — он должен помнить, что возвращает Class1(): инициализированный класс, или какой-то результат функции.


А в чем принципиальная разница? Возвращается некое значение.
Тут более полезно разделить вызов ф-ии и процедуры (для императивных языков), например как в VB, тогда читабельность не страдает.
Re[2]: Идеальный синтаксис (постановка задачи)
От: night beast СССР  
Дата: 14.02.11 13:11
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Вот, правильную тему поднял. Я пытался как-то "на бумаге" рарабатывать ЯП, который был мне удобен. Брал некие популярные задачи. Под одни из них синтаксис заточишь — в других местах сценариях неудобно. А вводить в синтаксис case или first-letter conventions, как в Хаскеле или Фортран — как-то несовременно.


и к чему в итоге пришел?
Re[9]: Идеальный синтаксис (постановка задачи)
От: Real 3L0 Россия http://prikhodko.blogspot.com
Дата: 14.02.11 13:28
Оценка:
Здравствуйте, vdimas, Вы писали:

R3>>Да, я про это и говорю. Но нужен не только вывод типов у компилятора, но нужна и память программисту — он должен помнить, что возвращает Class1(): инициализированный класс, или какой-то результат функции.

V>А в чем принципиальная разница? Возвращается некое значение.

В случае с new мне достаточно в памяти держать только описание классов.
В случае без new — ещё и результаты выполнения функций.

Ну и ещё как-то так:
public class MyClass
{
  public MyClass() { }
}

public Main
{
  private object MyClass() { }
  private void DoWork()
  {
    object o = MyClass(); // ?
  }
}



V>Тут более полезно разделить вызов ф-ии и процедуры (для императивных языков), например как в VB, тогда читабельность не страдает.


Функции можно использовать также, как и процедуры (но не наоборот), т.е. процедуры — подмножество функций. Зачем их делить?
Вселенная бесконечна как вширь, так и вглубь.
Re[13]: Идеальный синтаксис (постановка задачи)
От: Undying Россия  
Дата: 15.02.11 04:33
Оценка:
Здравствуйте, DarkGray, Вы писали:

U>>В смысле? В шарпе нельзя написать DatabaseHlp.TableForImei() вместо DatabaseHlp.CreateTableForImei()?


DG>только и первое, и второе — пример ужасного кода


И что во втором варианте ужасного? Статических функций очень много, соответственно их в любом случае надо разбивать на группы. Чем способ разбиения на группы с помощью предиката в виде имени статического класса хуже любого другого?
Re[15]: Идеальный синтаксис (постановка задачи)
От: Undying Россия  
Дата: 15.02.11 04:34
Оценка:
Здравствуйте, DarkGray, Вы писали:

U>>Действие, которое функция выполняет.


DG>полный ответ, пожалуйста.

DG>вот есть произвольная функция — что именно должно быть отражено в названии функции.

Это и был полный ответ, т.к. этой формулировки вполне достаточно для придумывания названий функций в реальных задачах.
Re[10]: Идеальный синтаксис (постановка задачи)
От: vdimas Россия  
Дата: 15.02.11 08:43
Оценка:
Здравствуйте, Real 3L0, Вы писали:

R3>Функции можно использовать также, как и процедуры (но не наоборот), т.е. процедуры — подмножество функций. Зачем их делить?


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

Насчет "так же использовать" — это и есть популярная детская ошибка с игнорированием кодов возвратов, например.
Re[3]: Идеальный синтаксис (постановка задачи)
От: vdimas Россия  
Дата: 15.02.11 08:53
Оценка:
Здравствуйте, night beast, Вы писали:

V>>Вот, правильную тему поднял. Я пытался как-то "на бумаге" рарабатывать ЯП, который был мне удобен. Брал некие популярные задачи. Под одни из них синтаксис заточишь — в других местах сценариях неудобно. А вводить в синтаксис case или first-letter conventions, как в Хаскеле или Фортран — как-то несовременно.


NB>и к чему в итоге пришел?


Что "по шустряку" последовательный синтаксис разработать не выйдет.

Реально, раз в несколько лет я к этой теме возвращаюсь, ибо написать компилятор не проблема (даже с учетом трудозатрат на отладку его грамматики), проблема — построить непротиворечивые спецификации Языка.

Мне понравилась работа Воронкова Василия именно тем, что он попытался разработать стройный синтаксис. Особенно в первых версиях. Потом у него понесся перекос в сторону Хаскеля, угу, я бы оставил на ключевых словах, типа function, для соблюдения духа синтаксиса. Справедливости ради, у него всё-равно очень неплохо вышло. И хотя в наличии лишь интерпретатор, под этот язык может быть построен типобезопасный компиллер, бо присутствует предварительное объявление переменных (там пара моментов всего нужна для доработки, не суть). Да и наличие своей VM говорит о заточке под компиляцию. В остальном, черпать вдохновение в JavaScript было абсолютно правильно, ибо много интересных идей, просящихся в компиллируемую реализацию.
Re[16]: Идеальный синтаксис (постановка задачи)
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 15.02.11 11:12
Оценка:
U>Это и был полный ответ, т.к. этой формулировки вполне достаточно для придумывания названий функций в реальных задачах.

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

зы
один из критериев хорошего названия — не тащить в названия "физику".
на языке обычно описывает модель определенного мира, но слова new, create, get, set — это слова языка, а не слова выстраиваемой модели — поэтому они лишние.

например, во фразе:
table().paint-to(color('green'))

слово create лишнее, т.к. на самом деле никакой новый стол не создается, и новый цвет тем более(они уже все созданы реальным миром)
createTable().paint-to(createColor('green'))
Re[17]: Идеальный синтаксис (постановка задачи)
От: Undying Россия  
Дата: 15.02.11 12:10
Оценка:
Здравствуйте, DarkGray, Вы писали:

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

DG>а в данной теме ты решаешь именно эту задачу

В каком это месте формулировки:

Название функции должно включать в себя действие, которое функция выполняет.


недостаточно для определения хорошее это название или плохое? Я что-то не улавливаю твоей логики.

DG>зы

DG>один из критериев хорошего названия — не тащить в названия "физику".
DG>на языке обычно описывает модель определенного мира, но слова new, create, get, set — это слова языка, а не слова выстраиваемой модели — поэтому они лишние.

Слова create (и new как синоним/аналог create) это именно слова выстраиваемой модели, а вовсе не языка. И соответственно если их опускать, то вместо описания модели какая-то фигня получается.

DG>например, во фразе:

DG>
DG>table().paint-to(color('green'))
DG>

DG>слово create лишнее, т.к. на самом деле никакой новый стол не создается, и новый цвет тем более(они уже все созданы реальным миром)
DG>
DG>createTable().paint-to(createColor('green'))
DG>


CreateTable создает стол в модели мира, до вызова этого метода никакого стола в рамках модели нет. Соответственно для нас важно видеть, что после этого вызова в модели появился новый объект, поэтому слово Create необходимо, т.к. резко упрощает чтение кода.

С цветом пример вообще не в тему. Цвет стола это либо свойство, либо вообще readonly поле, в каком месте цвет является действием и соответственно зачем ты пытаешься его задать функцией не понятно.
Re[18]: Идеальный синтаксис (постановка задачи)
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 15.02.11 13:09
Оценка:
U>недостаточно для определения хорошее это название или плохое? Я что-то не улавливаю твоей логики.

недостаточное, конечно.

U>CreateTable создает стол в модели мира, до вызова этого метода никакого стола в рамках модели нет. Соответственно для нас важно видеть, что после этого вызова в модели появился новый объект, поэтому слово Create необходимо, т.к. резко упрощает чтение кода.


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

U> С цветом пример вообще не в тему. Цвет стола это либо свойство, либо вообще readonly поле, в каком месте цвет является действием и соответственно зачем ты пытаешься его задать функцией не понятно.


так значит ты еще не чувствуешь — когда что-то делается действием? а когда свойством?
действие можно заменять на свойство — только если не важны нюансы процесса изменения.
банальный пример машина и ее движение.
если в нашей модели не важно — как машина едет, то достаточно будет свойства координаты машины и их изменение.
если же важно, например, как именно машина едет, как у нее там мотор фурчит и бензин тратится, то придется вводить метод move(go/drive/ride и т.д.)

то же самое и со столом, раз введен метод paint-to значит важны нюансы перекраски — может это длительная по времени операция, может там его сначала надо зашкурить, покрыть грунтовкой и только потом красить, и т.д. — и всё это важно.

но речь-то шла не об этом, а о том, насколько уместно говорить о создании цвета, или о создании точки, или о создании человека

U> Соответственно для нас важно видеть, что после этого вызова в модели появился новый объект


почему это важно? критерий. что произойдет страшного — если мы забудет о том, что вот данная функция создает объект?
приучайся свои интуитивные ощущения — логически обосновывать, т.к. интуация во многих ситуациях выдает ответ нечетко и легко ошибится в его трактовке.
Re[19]: Идеальный синтаксис (постановка задачи)
От: Undying Россия  
Дата: 16.02.11 15:43
Оценка:
Здравствуйте, DarkGray, Вы писали:

U>>недостаточно для определения хорошее это название или плохое? Я что-то не улавливаю твоей логики.


DG>недостаточное, конечно.


Так когда будет пример, который покажет, что этой формулировки недостаточно?

А также когда будет объяснено откуда следует, что отсутствие действия означает получение объекта, а не что-то другое и почему это должно быть очевидным для всех программистов?

DG>вызов конструктора — это именно создание объекта в языке — причем в данном конкретном экземпляре программы, а не в модели.

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

И что это меняет? Если Create относится к объекту модели, то вызов означает появление в модели новой сущности. Если Create относится к обертке над объектом модели, то вызов означает, что программа стала работать с большей частью модели. И первое, и второе очень важная информация для понимания кода.

DG>приучайся свои интуитивные ощущения — логически обосновывать, т.к. интуация во многих ситуациях выдает ответ нечетко и легко ошибится в его трактовке.


Я уже не первый пост с нетерпением жду, когда ты логически обоснуешь, почему отсутствие действия означает создание объекта, а не что-то другое.
Re[19]: Идеальный синтаксис (постановка задачи)
От: Silver_S Ниоткуда  
Дата: 16.02.11 15:47
Оценка:
Здравствуйте, DarkGray, Вы писали:

U>> Соответственно для нас важно видеть, что после этого вызова в модели появился новый объект

DG>почему это важно? критерий. что произойдет страшного — если мы забудет о том, что вот данная функция создает объект?

Суть в том, что одними философствованиями и игрой слов в отрыве от конкретного языка(синтаксиса) невозможно выбрать один из двух вариантов — использовать new или нет . Одного ответа на все случаи нет.
Во-первых не две градации — нужен,не нужен. А хотя бы тысячу — до какой степени нужен.
А во-вторых это зависит от тысячи мелочей. Разработка синтаксиса это огромная сеть причинно-следственных связей. Один элемент изменишь и в других местах что-то изменится.
Даже наличие Garbage Collector, немного меняет суть "new".

Есть ведь еще конструкции, в некоторых языках:
var v = new Class{Fld=1};
var v = new Class(){Fld=1};
var v = new Class[1000];
var v = new Class[]{1,2};
Даже если бы неоднозначности другим способом устранили, все-равно костыль new тут только ускоряет чтение.
А в некоторых языках в паттерн матчинге конструкторы используются.На полезность new это тоже влияет.

И даже от текста программы зависит. Когда дерево собирается вручную (типа XML), может new мешает.
Когда быстрый вычислительный алгоритм, с вызовом кучи функций, тогда хорошо что new выделяется от обычных функций.
Когда сложный сценарий создания и сам объект сложный(что даже конструктор без параметров закрытый) тогда тоже может быть с new лучше.

Не ответишь о полезности new, в отрыве от тысячи других фич конкретного языка. И даже надо учитывать программы, которые на языке предполагается писать (наиболее типичные сценарии использования).
Re[10]: Идеальный синтаксис (постановка задачи)
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 16.02.11 19:33
Оценка:
U>Если тебе не понятно, что названия tr и td сами по себе не несут никакой смысловой нагрузки и соответственно не могут быть поняты без предварительного обучения, то показывать тебе что либо бесполезно, т.к. у тебя проблемы со здравым смыслом и элементарной логикой.

понимание слово create вшито в днк российского ребенка?
Re[11]: Идеальный синтаксис (постановка задачи)
От: Undying Россия  
Дата: 17.02.11 05:03
Оценка:
Здравствуйте, DarkGray, Вы писали:

U>>Если тебе не понятно, что названия tr и td сами по себе не несут никакой смысловой нагрузки и соответственно не могут быть поняты без предварительного обучения, то показывать тебе что либо бесполезно, т.к. у тебя проблемы со здравым смыслом и элементарной логикой.


DG>понимание слово create вшито в днк российского ребенка?


Понимание термина 'создать' вшито в любого носителя естественного языка. Равно как терминов ячейка и колонка.
Re[17]: Идеальный синтаксис (постановка задачи)
От: Undying Россия  
Дата: 17.02.11 05:48
Оценка:
Здравствуйте, DarkGray, Вы писали:

DG>и новый цвет тем более(они уже все созданы реальным миром)


Кстати, понял чем мне не понравился пример с цветом. Цвет это не объект, а readonly структура, т.е. сущность, которую бессмысленно сравнивать по ссылке, ее можно сравнивать только по значению. Для таких сущностей действительно не важен способ получения, т.к. не важно получаем ли мы один и тот же экземпляр или разные экземпляры, важно лишь его значение.
Re[8]: Идеальный синтаксис (постановка задачи)
От: Ziaw Россия  
Дата: 17.02.11 06:19
Оценка:
Здравствуйте, Undying, Вы писали:

Z>>Точно так же можно принять соглашение, что функция с именем Xxx() создает объект типа Xxx. Никаких препятствий для этого нет.


U>Только такое соглашение будет противоречить естественным языкам и здравому смыслу, соответственно увеличив порог вхождения и усложнив понимание.


Ты переоцениваешь интуитивность синтаксиса в языках программирования. Как заметили выше, создание объекта на стеке в С++ выглядит именно так и я не видел плача по поводу противоречий здравому смыслу.

Z>>Более того, конструкторы должны вести ровно так же, как любые другие функции языка, оператор new этому мешает.


U>Вот, например, в C# можно написать _.Tuple(key, value), но надо писать new Tuple<TKey, TValue>(key, value). Но мешает записать new Tuple(key, value) вовсе не оператор new, а косность создателей C#. Сам по себе new ничему помешать не может.


Ничего не понял, когда конструктор это функция такой проблемы вообще нет. Ее и вызывали бы как Tuple(key, value) и можно было бы использовать как любой другой делегат. Представь эту ситуацию и поймешь, что оператор new тут совершенно лишний.

Я кстати не очень понимаю, почему в C# сделали так как сделали, Хейлсберг в делфи использовал как конструкторы обычные статик методы.
Re[9]: Идеальный синтаксис (постановка задачи)
От: Undying Россия  
Дата: 17.02.11 07:12
Оценка:
Здравствуйте, Ziaw, Вы писали:

Z>Ты переоцениваешь интуитивность синтаксиса в языках программирования. Как заметили выше, создание объекта на стеке в С++ выглядит именно так и я не видел плача по поводу противоречий здравому смыслу.


C++ целиком является противоречием здравому смыслу, по этому половина программеров сразу же перебежала с него на C# 1.0, который с точки зрения языковых возможностей был полным убожеством, но зато здравому смыслу не противоречил.

Z>Ничего не понял, когда конструктор это функция такой проблемы вообще нет. Ее и вызывали бы как Tuple(key, value) и можно было бы использовать как любой другой делегат. Представь эту ситуацию и поймешь, что оператор new тут совершенно лишний.


В C# есть проблема, что для конструктора вывод типов запрещен, а для функций разрешен, но причина этой проблемы вовсе не в операторе new, а в косности создателей C#.
Re[18]: Идеальный синтаксис (постановка задачи)
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 17.02.11 09:44
Оценка:
U>Кстати, понял чем мне не понравился пример с цветом. Цвет это не объект, а readonly структура, т.е. сущность, которую бессмысленно сравнивать по ссылке, ее можно сравнивать только по значению. Для таких сущностей действительно не важен способ получения, т.к. не важно получаем ли мы один и тот же экземпляр или разные экземпляры, важно лишь его значение.

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

user('undying') и еще раз user('undying') — это одна и таже сущность.
Re[12]: Идеальный синтаксис (постановка задачи)
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 17.02.11 09:59
Оценка:
U>Понимание термина 'создать' вшито в любого носителя естественного языка. Равно как терминов ячейка и колонка.

в том-то и дело что не вшито, а получено в процессе обучения.

и хорошесть синтаксиса в первую очередь определяется какое минимальное кол-во знай необходимо помнить, чтобы восстановить свое умение читать тот или иной синтаксис, а не сколько необходимо выучить.
конструкция table() — хорошая, потому что даже если забыть что это значит, то это знание быстро восстанавливается из контекста.
т.к. другой трактовки, кроме как создания объекта — она не подразумевает.

или другими словами: необходимо минимизировать объем знаний, которые необходим для понимания ЕЯ + синтаксис ЯП.
а задача: минимировать объем знаний, который необходимо доп. выучить для понимания (синтаксис ЯП), зная (ЕЯ) — ложная.
Re[19]: Идеальный синтаксис (постановка задачи)
От: Undying Россия  
Дата: 17.02.11 10:14
Оценка:
Здравствуйте, DarkGray, Вы писали:


U>>Кстати, понял чем мне не понравился пример с цветом. Цвет это не объект, а readonly структура, т.е. сущность, которую бессмысленно сравнивать по ссылке, ее можно сравнивать только по значению. Для таких сущностей действительно не важен способ получения, т.к. не важно получаем ли мы один и тот же экземпляр или разные экземпляры, важно лишь его значение.


DG>в большинстве моделей и остальные сущности тоже сраниваются по идентификатору, а не по экземплярам.

DG>user('undying') и еще раз user('undying') — это одна и таже сущность.

Выделенное важно. User не readonly сущность, поэтому к ней эти рассуждения не применимы.
Re[20]: Идеальный синтаксис (постановка задачи)
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 18.02.11 11:17
Оценка:
U>>>недостаточно для определения хорошее это название или плохое? Я что-то не улавливаю твоей логики.

DG>>недостаточное, конечно.


U>Так когда будет пример, который покажет, что этой формулировки недостаточно?



следующий метод
List<Item> F(int count)
{
  var list = new List<Item>()
  for (int i = 0; i < count; ++i)
    list.Add(new Item(i));
  return list;
}

можно назвать MakeListOfTypeItem
или
FillItemListFromCountOfItems
или
GetItems

все эти названия под твое определение подходят, какое из них выбрать?
Re[21]: Идеальный синтаксис (постановка задачи)
От: Undying Россия  
Дата: 19.02.11 17:54
Оценка:
Здравствуйте, DarkGray, Вы писали:

DG>следующий метод

DG>
DG>List<Item> F(int count)
DG>{
DG>  var list = new List<Item>()
DG>  for (int i = 0; i < count; ++i)
DG>    list.Add(new Item(i));
DG>  return list;
DG>}
DG>

DG>можно назвать MakeListOfTypeItem
DG>или
DG>FillItemListFromCountOfItems
DG>или
DG>GetItems

DG>все эти названия под твое определение подходят, какое из них выбрать?


1 название более-менее, 2 плохое, т.к. список не только заполняется, но и создается, 3 вообще не в тему. Хорошее название здесь подобрать сложно, т.к. непонятно для решения каких задач такой универсальный метод имеет смысл.
Re[22]: Идеальный синтаксис (постановка задачи)
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 19.02.11 18:10
Оценка:
DG>>все эти названия под твое определение подходят, какое из них выбрать?

U>1 название более-менее, 2 плохое, т.к. список не только заполняется, но и создается, 3 вообще не в тему. Хорошее название здесь подобрать сложно, т.к. непонятно для решения каких задач такой универсальный метод имеет смысл.


и где определение, как необходимо называть методы, на основе которого ты сделал эти выводы?
Re[10]: Идеальный синтаксис (постановка задачи)
От: Ziaw Россия  
Дата: 19.02.11 18:36
Оценка:
Здравствуйте, Jack128, Вы писали:

Z>>Я кстати не очень понимаю, почему в C# сделали так как сделали, Хейлсберг в делфи использовал как конструкторы обычные статик методы.


J>Это не так, в дельфи конструкторы — это тоже отдельные сущности, и не везде, где можно юзать статические методы, можно юзать конструкторы.


Возможно. Но их вызов выглядел один в один как вызов статик метода.
Re[20]: Идеальный синтаксис (постановка задачи)
От: Ziaw Россия  
Дата: 20.02.11 13:17
Оценка:
Здравствуйте, Silver_S, Вы писали:

S_S> Суть в том, что одними философствованиями и игрой слов в отрыве от конкретного языка(синтаксиса) невозможно выбрать один из двух вариантов — использовать new или нет . Одного ответа на все случаи нет.

S_S>Во-первых не две градации — нужен,не нужен. А хотя бы тысячу — до какой степени нужен.
S_S>А во-вторых это зависит от тысячи мелочей. Разработка синтаксиса это огромная сеть причинно-следственных связей. Один элемент изменишь и в других местах что-то изменится.

В философии оно конечно так, но на практике в языках ужасающее количество решений не продумываются толком, а берутся из других языков практически без изменений.

S_S>Даже наличие Garbage Collector, немного меняет суть "new".


GC это не мелочь и меняет он суть отнюдь не немного.

S_S>Есть ведь еще конструкции, в некоторых языках:

S_S>var v = new Class{Fld=1};
S_S>var v = new Class(){Fld=1};

Первые два примера с конструктором связанны чисто условно, взгляни на with
Автор: catbert
Дата: 13.12.10
, ему конструктор не нужен.

S_S>var v = new Class[1000];

S_S>var v = new Class[]{1,2};
S_S>Даже если бы неоднозначности другим способом устранили, все-равно костыль new тут только ускоряет чтение.

Вторые к конструктору типа никакого отношения не имеют, это конструктор массива. Особый подход к массиву на уровне языка в современных языках считаю неоправданным (особенно когда кроме особого синтаксиса конструктора ничего в язык не вводится).

S_S>А в некоторых языках в паттерн матчинге конструкторы используются.На полезность new это тоже влияет.


Nemerle прекрасно использует конструкторы в PM без new. Уж в PM new совсем не нужен, он там больше сбивает с толку.

S_S>Когда быстрый вычислительный алгоритм, с вызовом кучи функций, тогда хорошо что new выделяется от обычных функций.

S_S> Когда сложный сценарий создания и сам объект сложный(что даже конструктор без параметров закрытый) тогда тоже может быть с new лучше.

Чем лучше?

S_S>Не ответишь о полезности new, в отрыве от тысячи других фич конкретного языка. И даже надо учитывать программы, которые на языке предполагается писать (наиболее типичные сценарии использования).


new полезен там, где для каждого его вызова требуется аналогичный delete.
Re[23]: Идеальный синтаксис (постановка задачи)
От: Undying Россия  
Дата: 20.02.11 18:51
Оценка:
Здравствуйте, DarkGray, Вы писали:

DG>и где определение, как необходимо называть методы, на основе которого ты сделал эти выводы?


Я тебе его уже дважды приводил:

Название функции должно включать в себя действие, которое функция выполняет.


Что делает приведенная тобой функция? Создает ряд натуральных чисел. Соответственно хорошее название должно звучать именно так. Из твоих вариантов более-менее был первый, т.к. был неполным, но по крайней мере не ложным, второй и третий вариант были очень плохими, т.к. вместо информации содержали дезинформацию.
Re[23]: Идеальный синтаксис (постановка задачи)
От: Undying Россия  
Дата: 20.02.11 19:02
Оценка:
Здравствуйте, DarkGray, Вы писали:

DG>стандартный пример, берем список одинаковых элементов

DG>т.к. мир иммутабельный, то нет разницы между двумя следующими записями

Вот есть у нас мутабельная сущность item с изменяемым x. Если мы создаем этот item один раз, а дальше передаем его по ссылке, то изменив x в одном месте, я имею полную уверенность, что x измениться во всех 124 местах, в которых этот item используется. Если же мы используем мегаконцепцию эмуляция мутабельных сущностей на иммутабельных объектах и создали item 124 раза, то когда нам наконец-то захотелось x изменить, то нам надо все 124 места вспомнить, а за тем в каждом месте item заменить. А в остальном да никакой разницы, подумаешь в одном случае надо изменить код только в одном месте, а в другом — в 124 местах, разве это разница?

DG>этот пример показывает, что если мир иммутабельный, то даже несмотря на операции изменяющие мир — нам не важно, создавались ли отдельные экземпляры или не создавались


Кошмар. И этот человек раньше умел делать мир проще...
Re[24]: Идеальный синтаксис (постановка задачи)
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 20.02.11 20:45
Оценка:
U>Если мы создаем этот item один раз, а дальше передаем его по ссылке, то изменив x в одном месте, я имею полную уверенность, что x измениться во всех 124 местах, в которых этот item используется.

если это происходит в неявном виде — это чревато.
а если говорить про явный вид, то значит есть явная операция конструирования "мира" на основе item.
и соответственно при изменении item — операция конструирования "мира" еще раз вызовется, и построит мир с измененным item
Re[20]: Идеальный синтаксис (постановка задачи)
От: VladD2 Российская Империя www.nemerle.org
Дата: 21.02.11 01:32
Оценка:
Здравствуйте, Silver_S, Вы писали:

S_S>И даже от текста программы зависит. Когда дерево собирается вручную (типа XML), может new мешает.

S_S>Когда быстрый вычислительный алгоритм, с вызовом кучи функций, тогда хорошо что new выделяется от обычных функций.
S_S> Когда сложный сценарий создания и сам объект сложный(что даже конструктор без параметров закрытый) тогда тоже может быть с new лучше.

Выходит, что язык тут не причем, а дело в контексте использования?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[21]: Идеальный синтаксис (постановка задачи)
От: VladD2 Российская Империя www.nemerle.org
Дата: 21.02.11 01:40
Оценка:
Здравствуйте, Ziaw, Вы писали:

Z>GC это не мелочь и меняет он суть отнюдь не немного.

Z>...
Z>Первые два примера с конструктором связанны чисто условно, взгляни на with
Автор: catbert
Дата: 13.12.10
, ему конструктор не нужен.

Z>...
Z>Вторые к конструктору типа никакого отношения не имеют, это конструктор массива. Особый подход к массиву на уровне языка в современных языках считаю неоправданным (особенно когда кроме особого синтаксиса конструктора ничего в язык не вводится).

+1

S_S>>А в некоторых языках в паттерн матчинге конструкторы используются.На полезность new это тоже влияет.

Z>Nemerle прекрасно использует конструкторы в PM без new. Уж в PM new совсем не нужен, он там больше сбивает с толку.

Думаю он это и имел в виду. Что мол в языке с ПМ new совсем лишний.

S_S>>Когда быстрый вычислительный алгоритм, с вызовом кучи функций, тогда хорошо что new выделяется от обычных функций.

S_S>> Когда сложный сценарий создания и сам объект сложный(что даже конструктор без параметров закрытый) тогда тоже может быть с new лучше.

Z>Чем лучше?


Наверно тем, что видно динамическое выделение памяти, значит тормоза. Но тогда надо убрать new для создания структур. Они ведь не в куче создаются. Т.е. это видимо референс в сторону С++.

S_S>>Не ответишь о полезности new, в отрыве от тысячи других фич конкретного языка. И даже надо учитывать программы, которые на языке предполагается писать (наиболее типичные сценарии использования).


Z>new полезен там, где для каждого его вызова требуется аналогичный delete.


Откровенно говоря наличие new и delete на мой взгляд — это ошибка дизайна. В С++ все (толковые программисты) только и занимаются тем, что скрывают использование delete. Вот и надо было эту практику сразу спрятать под покровы абстракции.

Скажем запретить явно использование new с delete и заставить программистов создавать для таких классов некие обертки. Если для этого предусмотреть спец.синтаксис, то можно получиться весьма не плохо, и управление памятью в С++ не стало бы "искусством".
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[19]: Идеальный синтаксис (постановка задачи)
От: VladD2 Российская Империя www.nemerle.org
Дата: 21.02.11 01:42
Оценка:
Здравствуйте, DarkGray, Вы писали:

U>>Кстати, понял чем мне не понравился пример с цветом. Цвет это не объект, а readonly структура, т.е. сущность, которую бессмысленно сравнивать по ссылке, ее можно сравнивать только по значению. Для таких сущностей действительно не важен способ получения, т.к. не важно получаем ли мы один и тот же экземпляр или разные экземпляры, важно лишь его значение.


DG>в большинстве моделей и остальные сущности тоже сраниваются по идентификатору, а не по экземплярам.

DG>user('undying') и еще раз user('undying') — это одна и таже сущность.

Это называется структурная эквивалентность. В линейке С такой фичи не поддерживалось.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[20]: Идеальный синтаксис (постановка задачи)
От: VladD2 Российская Империя www.nemerle.org
Дата: 21.02.11 01:42
Оценка:
Здравствуйте, Undying, Вы писали:

U>Выделенное важно. User не readonly сущность, поэтому к ней эти рассуждения не применимы.


Это почему? Как сделаешь, так и будет. Сделать юзера неизменяемым очень даже не плохая идея.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[25]: Идеальный синтаксис (постановка задачи)
От: Undying Россия  
Дата: 21.02.11 15:50
Оценка:
Здравствуйте, DarkGray, Вы писали:

U>>Если мы создаем этот item один раз, а дальше передаем его по ссылке, то изменив x в одном месте, я имею полную уверенность, что x измениться во всех 124 местах, в которых этот item используется.


DG>если это происходит в неявном виде — это чревато.


Чем? Автоматический кэш, что делает? Заменяет явные модификации на неявные. И какой код проще с автоматическими кэшами или явными модификациями?

DG>а если говорить про явный вид, то значит есть явная операция конструирования "мира" на основе item.


Бедный мир, который должен уметь конструироваться на основе каждой песчинки.

DG>и соответственно при изменении item — операция конструирования "мира" еще раз вызовется, и построит мир с измененным item


Пример можно? Только не уровня отдельного экземпляра/коллекции, а чего-то мало-мальски сложного и реального. Например, есть иерархия world -> carList -> car -> sensorList -> sensor. Как будет выглядеть замена конкретного AnalogSensor на DiscreteSensor?
Re[26]: Идеальный синтаксис (постановка задачи)
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 21.02.11 20:15
Оценка:
U>Чем? Автоматический кэш, что делает? Заменяет явные модификации на неявные. И какой код проще с автоматическими кэшами или явными модификациями?

ручное управление кэшами — это такой же анахронизм, как ручное управление памятью

DG>>а если говорить про явный вид, то значит есть явная операция конструирования "мира" на основе item.


U>Бедный мир, который должен уметь конструироваться на основе каждой песчинки.


система автоматических кэшей — это и есть конструирование мира из песчинки, записанное на коленке.

DG>>и соответственно при изменении item — операция конструирования "мира" еще раз вызовется, и построит мир с измененным item


U>Пример можно? Только не уровня отдельного экземпляра/коллекции, а чего-то мало-мальски сложного и реального. Например, есть иерархия world -> carList -> car -> sensorList -> sensor. Как будет выглядеть замена конкретного AnalogSensor на DiscreteSensor?


как будет записываться? или как будет исполняться?
Re[27]: Идеальный синтаксис (постановка задачи)
От: Undying Россия  
Дата: 22.02.11 05:45
Оценка:
Здравствуйте, DarkGray, Вы писали:

U>>Чем? Автоматический кэш, что делает? Заменяет явные модификации на неявные. И какой код проще с автоматическими кэшами или явными модификациями?

DG>ручное управление кэшами — это такой же анахронизм, как ручное управление памятью

И что можно автоматизировать в кэше? Он вроде и так полностью декларативный, от чего ты собрался автоматически избавиться? От вычисления значения или от указания источников?

U>>Пример можно? Только не уровня отдельного экземпляра/коллекции, а чего-то мало-мальски сложного и реального. Например, есть иерархия world -> carList -> car -> sensorList -> sensor. Как будет выглядеть замена конкретного AnalogSensor на DiscreteSensor?


DG>как будет записываться? или как будет исполняться?


Для начала, как будет записываться.
Re[24]: Идеальный синтаксис (постановка задачи)
От: VoidEx  
Дата: 22.02.11 09:29
Оценка:
Здравствуйте, Undying, Вы писали:

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


DG>>и где определение, как необходимо называть методы, на основе которого ты сделал эти выводы?


U>Я тебе его уже дважды приводил:


U>

U>Название функции должно включать в себя действие, которое функция выполняет.


U>Что делает приведенная тобой функция? Создает ряд натуральных чисел. Соответственно хорошее название должно звучать именно так. Из твоих вариантов более-менее был первый, т.к. был неполным, но по крайней мере не ложным, второй и третий вариант были очень плохими, т.к. вместо информации содержали дезинформацию.


Не создаёт, а возвращает. Может, у неё таблица заранее созданных списков есть? Какую именно часть действия надо заключать в название? А если описание функции подразумевает возврат списка от 0 до N без раскрытия деталей, откуда именно она его берёт? Что тогда писать? ReturnListFrom0ToN?
Re[25]: Идеальный синтаксис (постановка задачи)
От: Undying Россия  
Дата: 22.02.11 09:38
Оценка:
Здравствуйте, VoidEx, Вы писали:

VE>Не создаёт, а возвращает. Может, у неё таблица заранее созданных списков есть? Какую именно часть действия надо заключать в название? А если описание функции подразумевает возврат списка от 0 до N без раскрытия деталей, откуда именно она его берёт? Что тогда писать? ReturnListFrom0ToN?


В общем случае это будет FindOrCreate. Если создание не обладает побочными эффектами (т.е. создании при получении любым способом гарантируется), тогда Get.
Re[28]: Идеальный синтаксис (постановка задачи)
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 22.02.11 10:36
Оценка:
U>И что можно автоматизировать в кэше? Он вроде и так полностью декларативный, от чего ты собрался автоматически избавиться? От вычисления значения или от указания источников?

избавиться от указания самих кэшей.
вот данного кода достаточно, чтобы все кэши были расставлены автоматически при изменении любого объекта: list1, list2 и т.д.
var list1 = list(1, 2, 4);
var list2 = GetList2();
var list = list1 + list2;
textBox.Text = list.Length.ToString();

причем здесь может быть расставлен даже инкрементальный кэш, когда при добавлении элемента в list1, textBox.Text автоматически щелкает на единичку, без перевычисления всего.


U>>>Пример можно? Только не уровня отдельного экземпляра/коллекции, а чего-то мало-мальски сложного и реального. Например, есть иерархия world -> carList -> car -> sensorList -> sensor. Как будет выглядеть замена конкретного AnalogSensor на DiscreteSensor?


DG>>как будет записываться? или как будет исполняться?


U>Для начала, как будет записываться.


раз это конкретный sensor, то значит известен его идентификатор
world.car.sensor[id:37] = DiscreteSensor(bla-bla);

если известен не только id сенсора, но и машины,то
world.car[id:'o513хх77'].sensor[id:37] = DiscreteSensor(bla-bla);
Re[26]: Идеальный синтаксис (постановка задачи)
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 22.02.11 10:45
Оценка:
U>В общем случае это будет FindOrCreate. Если создание не обладает побочными эффектами (т.е. создании при получении любым способом гарантируется), тогда Get.

в данном примере, хорошим названием будет GenerateItems или GenerateNItems
слово Generate указывает на то, что из меньшего кол-ва информации генерится бОльшее кол-во информации.
указания List/Array и т.д. — нафиг не нужны, и фактически это продолжение венгерской нотации из C.
для указания, что Item-ов возвращается много достаточно суффикса -s
N-указывает на то, что генерация идет по кол-ву, а не другим способом.

т.е. в хорошем названии указывается, как трансформируется информация, а не что происходит в данном конкретном языке в данной конкретной реализации.
Re[27]: Идеальный синтаксис (постановка задачи)
От: Undying Россия  
Дата: 22.02.11 11:15
Оценка:
Здравствуйте, DarkGray, Вы писали:

DG>в данном примере, хорошим названием будет GenerateItems или GenerateNItems


Ничего против Generate не имею, это аналог Create, возможно в данном контексте более точный. Соответственно наилучшим названием будет GenerateNaturalNumbers.
Re[29]: Идеальный синтаксис (постановка задачи)
От: Undying Россия  
Дата: 22.02.11 11:26
Оценка:
Здравствуйте, DarkGray, Вы писали:

DG>избавиться от указания самих кэшей.

DG>вот данного кода достаточно, чтобы все кэши были расставлены автоматически при изменении любого объекта: list1, list2 и т.д.
DG>
DG>var list1 = list(1, 2, 4);
DG>var list2 = GetList2();
DG>var list = list1 + list2;
DG>textBox.Text = list.Length.ToString();
DG>


А если не надо, чтобы list изменялся при изменении list1 и list2?

DG>причем здесь может быть расставлен даже инкрементальный кэш, когда при добавлении элемента в list1, textBox.Text автоматически щелкает на единичку, без перевычисления всего.


Это шаманство, при котором шаг влево-шаг вправо расстрел. Т.е. гибкость снижается на порядок, в лаконичности выигрываем копейки, ну и нафиг такое счастье?

U>>Для начала, как будет записываться.

DG>раз это конкретный sensor, то значит известен его идентификатор

А если нет идентификаторов?

DG>
DG>world.car.sensor[id:37] = DiscreteSensor(bla-bla);
DG>

DG>если известен не только id сенсора, но и машины,то
DG>
DG>world.car[id:'o513хх77'].sensor[id:37] = DiscreteSensor(bla-bla);
DG>


Тогда, значит, меня интересовало как это будет исполняться.
Re[30]: Идеальный синтаксис (постановка задачи)
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 22.02.11 12:24
Оценка:
U>А если не надо, чтобы list изменялся при изменении list1 и list2?

т.е. хочется чтобы при первом исполнении list построился на основе list1 и list2, а при последующих list был самостоятельным хранилищем?
так и записать в явном виде:
var list1 = list(1, 2, 4);
var list2 = GetList2();
var list = list(initial:list1 + list2);
textBox.Text = list.Length.ToString();



DG>>причем здесь может быть расставлен даже инкрементальный кэш, когда при добавлении элемента в list1, textBox.Text автоматически щелкает на единичку, без перевычисления всего.


U>Это шаманство, при котором шаг влево-шаг вправо расстрел. Т.е. гибкость снижается на порядок, в лаконичности выигрываем копейки, ну и нафиг такое счастье?


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

U> Т.е. гибкость снижается на порядок, в лаконичности выигрываем копейки, ну и нафиг такое счастье?


в лаконичности как раз выигрывается 99% кода
вот попробуй записать на шарпе — ту же самую задачу, чтобы при изменении list1 и list2 менялся автоматически textBox
причем операции Add/Remove/Set над листом лишь меняли значение textBox на нужное число, а не требовали полной склейки списков.
а также дальше попробуй всё это дело "пошевелить" — повносить небольшие изменения функциональности

соответственно стоит понимать, что это лишь фрагмент реального кода, реальный код будет намного больше, например, вывод объединенного списка через виртуальный грид выглядит так
var list1 = list(1, 2, 4);
var list2 = GetList2();
var list = list1 + list2;
grid.RowCount = list.Length;
grid.ViewRows = list[.index >= grid.FirstViewRow && .index < grid.LastViewRow];

при этом GetList2 — это получение элементов из базы, а самих элементов может быть и десятки тысяч
сам код исполняется на сервере, а grid — это часть html-страницы в браузере

а для этого кода выпиши все кэши, в том числе на уровне браузера, сервера и базы?

у меня создается впечатление, что ты лишь думаешь о небольшом мирке конкретного экземпляра программы.
но текущие реалии требуют умение записывать задачи, которые решаются поверх хотя бы трехзвенки (база+сервер+браузер), и конкретный экземпляр программы никого не интересует.

U>>>Для начала, как будет записываться.

DG>>раз это конкретный sensor, то значит известен его идентификатор

U>А если нет идентификаторов?


ты же как-то знаешь какой именно сенсор хочешь заменить, значит какая-то идентифицирующая информация есть: порядкой номер, размер, цвет и т.д.

U>Тогда, значит, меня интересовало как это будет исполняться.


если не нужна старая копия, то будет замена по месту:
var sensors = world.cars.FindObject('o513хх77').sensors;
sensors.Remove(37);
sensors.Add(new DiscreteSensor(bla-bla));


если кому-то требуется старая копия в неизменном виде, то создатся новая копия мира
world = new World(world, sensor=>(sensor.id == 37) ? new DiscreteSensor(bla-bla): sensor);


возможны еще более сложные сценарии — ленивые, когда реального пересоздания мира не происходит, а лишь запоминается, что над миром было сделано такое-то изменение
Re[31]: Идеальный синтаксис (постановка задачи)
От: Undying Россия  
Дата: 22.02.11 16:06
Оценка:
Здравствуйте, DarkGray, Вы писали:

DG>т.е. хочется чтобы при первом исполнении list построился на основе list1 и list2, а при последующих list был самостоятельным хранилищем?

DG>так и записать в явном виде:
DG>
DG>var list1 = list(1, 2, 4);
DG>var list2 = GetList2();
DG>var list = list(initial:list1 + list2);
DG>textBox.Text = list.Length.ToString();
DG>


Проблема в том, что большая часть кода это код внутри функций, а для локальных переменных кэши не нужны, т.к. там, как правило, задача обратная — нужно зафиксировать состояние на начало работы функции и затем его обработать. Зачем нужен синтаксис, который утяжеляет запись более часто встречающейся задачи?

DG>ретрограды, использующие C, тоже самое говорят про автоматическое управление памятью

DG>вот только реальных сценариев, когда действительно необходимо ручное управление памятью или ручное управление кэшами очень мало.

Способов определения того, что объект изменился может быть очень много. Также иногда бывает, что нужны действия над старым значением кэша. Как автоматика будет решать такие задачи?

DG>в лаконичности как раз выигрывается 99% кода

DG>вот попробуй записать на шарпе — ту же самую задачу, чтобы при изменении list1 и list2 менялся автоматически textBox

Cache<List> listCache = new Cache(delegate(List list2) { return list(1, 2, 4) + list2; },
  delegate { return GetList2(); });
textBox.Source = delegate { return list.Length.ToString(); };


Что-то не вижу особого выигрыша в лаконичности, а ведь можно (хоть и бессмысленно) еще и на лямбды переписать. При этом в реальной задаче кода бизнес логики будет на порядок больше, чем кода декларации кэша, соответственно и вовсе экономия на спичках получится.

DG>причем операции Add/Remove/Set над листом лишь меняли значение textBox на нужное число, а не требовали полной склейки списков.


Это вроде элементарно, если операция + создает не обычную коллекцию, а обертку над коллекцией коллекций.

DG>а также дальше попробуй всё это дело "пошевелить" — повносить небольшие изменения функциональности


Проблема в чем?

DG>соответственно стоит понимать, что это лишь фрагмент реального кода, реальный код будет намного больше, например, вывод объединенного списка через виртуальный грид выглядит так

DG>
DG>var list1 = list(1, 2, 4);
DG>var list2 = GetList2();
DG>var list = list1 + list2;
DG>grid.RowCount = list.Length;
DG>grid.ViewRows = list[.index >= grid.FirstViewRow && .index < grid.LastViewRow];
DG>

DG>при этом GetList2 — это получение элементов из базы, а самих элементов может быть и десятки тысяч
DG>сам код исполняется на сервере, а grid — это часть html-страницы в браузере

Делаем list ленивой оберткой, с остальным виртуальный грид разберется сам.

DG>а для этого кода выпиши все кэши, в том числе на уровне браузера, сервера и базы?


Браузер не знаю что такое, не работал с web'ом. А на обычном клиенте тут можно вообще без кэшей, ежели list по marshalByRef выставить. Соответственно вижу тут один кэш на сервере и все работает.

DG>у меня создается впечатление, что ты лишь думаешь о небольшом мирке конкретного экземпляра программы.

DG>но текущие реалии требуют умение записывать задачи, которые решаются поверх хотя бы трехзвенки (база+сервер+браузер), и конкретный экземпляр программы никого не интересует.

На основе кэшей трехзвенка (база + сервер + клиент) строится без проблем. Как раз на днях за пять копеек перевел на модель сервер-клиент локальное приложение, при разработке которого о будущей централизации никто не думал.

DG>ты же как-то знаешь какой именно сенсор хочешь заменить, значит какая-то идентифицирующая информация есть: порядкой номер, размер, цвет и т.д.


В общем случае для решения данной задачи мне достаточно ссылки на SensorList и порядкового номера датчика.

DG>если не нужна старая копия, то будет замена по месту:

DG>
DG>var sensors = world.cars.FindObject('o513хх77').sensors;
DG>sensors.Remove(37);
DG>sensors.Add(new DiscreteSensor(bla-bla));
DG>


Не понял в чем ноу-хау. Вроде обычное мутабельное хранилище данных.

DG>если кому-то требуется старая копия в неизменном виде, то создатся новая копия мира

DG>
DG>world = new World(world, sensor=>(sensor.id == 37) ? new DiscreteSensor(bla-bla): sensor);
DG>


И где этот код заменяет датчик у конкретной машины? Т.е. как выглядит изменение узла дерева, если мы знаем путь до него в дереве?

В целом идея более-менее понятна. Пересоздание мира выглядит как вызов функции с миллионом опциональных параметров — результатом развертывания дерева объектов в плоский список. Не понятно только как с этим можно работать в мало-мальски сложном случае.
Re[32]: Поправка
От: Undying Россия  
Дата: 22.02.11 16:18
Оценка:
Тут, конечно, должно быть выделенное:

U>
U>Cache<List> listCache = new Cache(delegate(List list2) { return list(1, 2, 4) + list2; },
U>  delegate { return GetList2(); });
U>textBox.Source = delegate { return listCache.Result.Length.ToString(); };
U>
Re[32]: Идеальный синтаксис (постановка задачи)
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 22.02.11 22:59
Оценка:
DG>>причем операции Add/Remove/Set над листом лишь меняли значение textBox на нужное число, а не требовали полной склейки списков.

U>Это вроде элементарно, если операция + создает не обычную коллекцию, а обертку над коллекцией коллекций.


ты весь код напиши, ты обещал что его будет немного — значит еще строки 4-8

U>Делаем list ленивой оберткой, с остальным виртуальный грид разберется сам.


и как это поможет ловить изменения данных в базе?
если ты собираешься на клиенте постоянно опрашивать list, то кто при этом будет платить за бешеный трафик между клиентом и сервером?

U> Делаем list ленивой оберткой, с остальным виртуальный грид разберется сам.


во сколько строк кода встанет создание такой обертки?
или ты их забыл посчитать, когда говорил что кода будет не больше?


DG>>а для этого кода выпиши все кэши, в том числе на уровне браузера, сервера и базы?


U>Браузер не знаю что такое, не работал с web'ом. А на обычном клиенте тут можно вообще без кэшей, ежели list по marshalByRef выставить. Соответственно вижу тут один кэш на сервере и все работает.


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

DG>>у меня создается впечатление, что ты лишь думаешь о небольшом мирке конкретного экземпляра программы.

DG>>но текущие реалии требуют умение записывать задачи, которые решаются поверх хотя бы трехзвенки (база+сервер+браузер), и конкретный экземпляр программы никого не интересует.

U>На основе кэшей трехзвенка (база + сервер + клиент) строится без проблем. Как раз на днях за пять копеек перевел на модель сервер-клиент локальное приложение, при разработке которого о будущей централизации никто не думал.


то, что перевод осуществился — не означает автоматически при этом, что решение хорошее по трафику, времени реакции и т.д.

DG>>ты же как-то знаешь какой именно сенсор хочешь заменить, значит какая-то идентифицирующая информация есть: порядкой номер, размер, цвет и т.д.


U>В общем случае для решения данной задачи мне достаточно ссылки на SensorList и порядкового номера датчика.


ссылка на SensorList — это есть фактически идентификатор машины, порядковый номер датчика — это есть идентификатор(временный) датчика

U>Не понял в чем ноу-хау. Вроде обычное мутабельное хранилище данных.


ну, да. так же как внутри gc обычные new/delete
ноухау в том, что этот код не надо писать разработчику — он выполняется сам под капотом.

DG>>если кому-то требуется старая копия в неизменном виде, то создатся новая копия мира

DG>>
DG>>world = new World(world, sensor=>(sensor.id == 37) ? new DiscreteSensor(bla-bla): sensor);
DG>>


U>И где этот код заменяет датчик у конкретной машины? Т.е. как выглядит изменение узла дерева, если мы знаем путь до него в дереве?


если мы создаем копию, то не надо изменять узел — необходимо лишь при копировании создать нужный узел вместо исходного

U>В целом идея более-менее понятна. Пересоздание мира выглядит как вызов функции с миллионом опциональных параметров — результатом развертывания дерева объектов в плоский список. Не понятно только как с этим можно работать в мало-мальски сложном случае.


в первом приближении, можно так считать.
Re[32]: Идеальный синтаксис (постановка задачи)
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 22.02.11 23:05
Оценка:
U>Способов определения того, что объект изменился может быть очень много.

способов определения изменений немного:
первое деление: прямой опрос/события,
второе деление: по непосредственному значению/по признаку-индикатору
итого: 4 способа
Re[33]: Идеальный синтаксис (постановка задачи)
От: Undying Россия  
Дата: 23.02.11 05:07
Оценка:
Здравствуйте, DarkGray, Вы писали:

DG>способов определения изменений немного:

DG>первое деление: прямой опрос/события,
DG>второе деление: по непосредственному значению/по признаку-индикатору
DG>итого: 4 способа

При этом способов получения признака-индикатора может быть бесконечное множество. И чем тут может помочь автоматика не понятно.
Re[34]: Идеальный синтаксис (постановка задачи)
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 23.02.11 10:05
Оценка:
U>При этом способов получения признака-индикатора может быть бесконечное множество.

одним способом в виде простого выбирающего выражения
Re[6]: Идеальный синтаксис (постановка задачи)
От: vdimas Россия  
Дата: 23.02.11 11:17
Оценка:
Здравствуйте, FR, Вы писали:

FR>Хорошая кстати книга, но тяжелая, математики многовато, буду летом читать


А уточни плиз. Тоже интересно стало.
Re[11]: Идеальный синтаксис (постановка задачи)
От: VladD2 Российская Империя www.nemerle.org
Дата: 23.02.11 11:41
Оценка:
Здравствуйте, Ziaw, Вы писали:

Z>Возможно. Но их вызов выглядел один в один как вызов статик метода.


На самом деле в Дельфи вшит паттерн "фабричный метод". Но это не важно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Идеальный синтаксис (постановка задачи)
От: VladD2 Российская Империя www.nemerle.org
Дата: 23.02.11 11:45
Оценка:
Здравствуйте, DarkGray, Вы писали:

DG>но теоретического предела все равно же и близко не удалось достичь.


Теоретический предел — это сфероконь вакуумный. Я предпочитаю оперировать понятием достаточной производительности. Все что больше чем достаточно — это хорошо. Все что меньше — неприемлемо.

DG>значит где-то еще есть неоптимальности в реализации


Это меня не колышет.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Идеальный синтаксис (постановка задачи)
От: night beast СССР  
Дата: 24.02.11 06:00
Оценка:
Здравствуйте, VladD2, Вы писали:

V>>>Вот, правильную тему поднял. Я пытался как-то "на бумаге" рарабатывать ЯП, который был мне удобен. Брал некие популярные задачи. Под одни из них синтаксис заточишь — в других местах сценариях неудобно. А вводить в синтаксис case или first-letter conventions, как в Хаскеле или Фортран — как-то несовременно.


NB>>и к чему в итоге пришел?


VD>Сам не догадываешься? Пачка макулатуры .


ну почему сразу макулатуры. может что-то интересное вышло.

PS: ты там письмо мое получил с мануалом то tex?
Re[28]: Идеальный синтаксис (постановка задачи)
От: VoidEx  
Дата: 24.02.11 07:58
Оценка:
Здравствуйте, Undying, Вы писали:

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


Они и не видимы. Как определить, создался иммутабельный объект или вернулся?
И почему тогда тем же способом не определить ленивое создание.
Re[5]: Идеальный синтаксис (постановка задачи)
От: VladD2 Российская Империя www.nemerle.org
Дата: 24.02.11 09:12
Оценка:
Здравствуйте, night beast, Вы писали:

VD>>Сам не догадываешься? Пачка макулатуры .


NB>ну почему сразу макулатуры. может что-то интересное вышло.


Это была шутка в которой есть доля шутки.

NB>PS: ты там письмо мое получил с мануалом то tex?


Да. Но пока что руки до него не дошли.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Идеальный синтаксис (постановка задачи)
От: FR  
Дата: 24.02.11 15:46
Оценка:
Здравствуйте, vdimas, Вы писали:

FR>>Хорошая кстати книга, но тяжелая, математики многовато, буду летом читать


V>А уточни плиз. Тоже интересно стало.


Влад выше уже дал ссылку http://www.rsdn.ru/res/book/prog/FoundationsForPL.xml
Автор(ы):
Дж. Митчелл


Если Вы хотите написать или уже пишете свой язык программирования №1 в мире, то стоит заботать данную книгу. Книга большая, очень много математики, читается тяжело,
но создание языка программирования №1 — требует жертв. Книга представляет собой теоретическое введение в лямбда-исчисление (основу современных языков программирования).
Материал книги использовался при проведении 3-х семестровых курсов в Стэнфорде. Изучение книги позволяет при создании своего языка встать "на плечи гигантов" и переиспользовать опыт по выделению базовых абстракций из которых строятся языки программирования.

Ну и согласен с ним, что нужно при чтении большую скидку на академичность делать.
Но не согласен что бестолковая, пока листал много интересного обнаружил.
Re[35]: Идеальный синтаксис (постановка задачи)
От: Undying Россия  
Дата: 25.02.11 10:26
Оценка:
Здравствуйте, DarkGray, Вы писали:

U>>При этом способов получения признака-индикатора может быть бесконечное множество.

DG>одним способом в виде простого выбирающего выражения

Не вижу в предлагаемом тобой синтаксисе "простого выбирающего выражения".
Re[11]: Идеальный синтаксис (постановка задачи)
От: Undying Россия  
Дата: 25.02.11 10:35
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>А без предварительного обучения вообще ничего понять нельзя.


Хороший язык отличается тем, что в нем нужно выучить мало, чтобы понимать много. В плохом языке все наоборот. Наименования вроде tr и td это второй случай, т.е. плохой язык. Замени их на row и cell и дополнительного обучения/знакомства с html не потребуется.

VD>Мне казалось, что смешно озвучивать такие банальные вещи, как — "Для того чтобы прочесть текст сначала нужно выучить алфавит". Все что нужно знать для восприятия примера — это то, что tr и td — это типы, и то что создание объекта не требует указания new.


А то что tr и td это строчка и ячейка знать для восприятия примера не нужно?

VD>Приведенный пример (с tr и td) — это классический дсл основанный на реинтерпретации базового синтаксиса. Я не знаю кому он может быть не понятен. Разве что ли тем кто не знаком с HTML-ем.


Т.е. для того, что прочитать этот код нужно быть знакомым с html, при том, что задача никакого отношения к html'у может не иметь. Это такой прекрасный способ снизить порог вхождения и упростить чтение кода?
Re[12]: Идеальный синтаксис (постановка задачи)
От: VladD2 Российская Империя www.nemerle.org
Дата: 25.02.11 11:06
Оценка:
Здравствуйте, Undying, Вы писали:

U>Хороший язык отличается тем, что в нем нужно выучить мало, чтобы понимать много. В плохом языке все наоборот.


По твоей логике C# очень плохой язык, так как там нужно слишком много учить Вот тот же оператор new, например.

U>Наименования вроде tr и td это второй случай, т.е. плохой язык. Замени их на row и cell и дополнительного обучения/знакомства с html не потребуется.


Дык человек явно как раз html и пытался изобразить. Зачем ему вводить какие-то более общие понятия? К тому же это уже проблемы прикладного программиста как называть прикладные сущности. Захотел назвал row и cell, а захотел tr и td. Язык на котором он пишет от этого них хуже, ни лучше не становится.

Тезис твой о количестве концепций языка в общем-то верен. Но верен он не вот так вот в лоб, а опосредованно. Лучше тот язык чьи концепции стройнее и регулярнее.

Пример с оператором new как раз демонстрирует случай внесения лишних сущностей. В языке уже есть понятие функции. Конструктор может рассматриваться как функция. Но в язык вводится еще одна, специализированная сущность new которая делает невозможным рассмотрение конструктора как функции.

С точки зрения синтаксиса урон не большой. Ты вот даже преимущество в этом усмотрел. Но с точки зрения стройности всего языка — это серьезное упущение. Прикладной программист вынужден терпеть неудобства от того, что правила применимые для методов не применимы для конструкторов. Это и странный запрет на вывод типов конструторов, и невозможность использовать конструктор как ссылку на функцию.

VD>>Мне казалось, что смешно озвучивать такие банальные вещи, как — "Для того чтобы прочесть текст сначала нужно выучить алфавит". Все что нужно знать для восприятия примера — это то, что tr и td — это типы, и то что создание объекта не требует указания new.


U>А то что tr и td это строчка и ячейка знать для восприятия примера не нужно?


Нужно конечно. Только скажи честно ты с первого раза не догадался о том что "это строчка и ячейка"?
А раз догадался, то какие еще вопросы?

В данном случае мы имеем дело с простеньким ДСЛ-ем. Его ключевые слов не более чем выбор автора. Хочешь, назови их по другому, чтобы тебе было более понятно. Это детали которые к делу не относятся.

Давай лучше подумаем, как код мог бы выглядеть, если бы он был написан в привычной многим императивной манере? Мы получили бы что-то вроде:
var table = new Table();

var style = new Style();

style.Class = "main"

table.Styles.Add(style);

var tr = new TableRow();

tr.Add(new TableColumn() { Name = "A" });
tr.Add(new TableColumn() { Name = "B" });


var tr2 = new TableRow();

tr2.Add(new TableColumn() { Name = "1" });
tr2.Add(new TableColumn() { Name = "2" });

var tr3 = new TableRow();

tr3.Add(new TableColumn() { Name = "3" });
tr3.Add(new TableColumn() { Name = "4" });

и все это вместо:
var table = table
(
  style:{class:'main'},
  tr(td('A'), td('B')),
  tr(td('1'), td('2')),
  tr(td('3'), td('4')),
);

Последняя запись это всего лишь логичное развитие ряда упрощений.

А ведь большая часть программистов долбят код вроде первого варианта и прикрываются при этом твоими аргументами.

VD>>Приведенный пример (с tr и td) — это классический дсл основанный на реинтерпретации базового синтаксиса. Я не знаю кому он может быть не понятен. Разве что ли тем кто не знаком с HTML-ем.


U>Т.е. для того, что прочитать этот код нужно быть знакомым с html,


Конечно.

U>при том, что задача никакого отношения к html'у может не иметь.


С какого это переполоху? Как я понял задача как раз таки была в том чтобы описать HTML-ную табличку.

U>Это такой прекрасный способ снизить порог вхождения и упростить чтение кода?


У тебя какой-то пунктик на этом пороге. Ты что не понял написанного? А раз понял, то о чем речь то?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[29]: Идеальный синтаксис (постановка задачи)
От: Undying Россия  
Дата: 25.02.11 11:25
Оценка:
Здравствуйте, VoidEx, Вы писали:

VE>Они и не видимы. Как определить, создался иммутабельный объект или вернулся?

VE>И почему тогда тем же способом не определить ленивое создание.

Если мы весь мир делаем иммутабельным, то возникает другая проблема. Мир штука тяжелая и его пересоздание далеко не бесплатно, соответственно если иммутабельный объект тяжел, то создался он или вернулся становится очень даже заметно с точки зрения производительности.
Re[30]: Идеальный синтаксис (постановка задачи)
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 25.02.11 14:04
Оценка:
U> Мир штука тяжелая и его пересоздание далеко не бесплатно, соответственно если иммутабельный объект тяжел, то создался он или вернулся становится очень даже заметно с точки зрения производительности.

если не писать извратный код, то никакого пересоздания мира и не будет, а будет изменение по месту (такое же как и в мутабельном мире).

зы
твои замечания мне напоминают ретроградские высказывания 90-х, что мол если писать код
int x = 3;
int z = x + 5;

вместо
mov ax, 3
add ax, 5

то компилятор под каждую переменную выделит ячейку памяти, и все будет тормозить и жрать много памяти.
вот только компилятор под это генерит код
mov ax, 8


зы
и мне кажется, что ты не понимаешь простую вещь: что иммутабельный код пишется как иммутабельный, но исполняется как мутабельный
Re[31]: Идеальный синтаксис (постановка задачи)
От: Undying Россия  
Дата: 27.02.11 13:48
Оценка:
Здравствуйте, DarkGray, Вы писали:

U>> Мир штука тяжелая и его пересоздание далеко не бесплатно, соответственно если иммутабельный объект тяжел, то создался он или вернулся становится очень даже заметно с точки зрения производительности.


DG>если не писать извратный код, то никакого пересоздания мира и не будет, а будет изменение по месту (такое же как и в мутабельном мире).


И как это будет выглядеть? Вот мы получали типа иммутабельный объект некой сущности, далее эта сущность изменилась. Иммутабельный объект при этом изменится? Если да, то в каком месте он иммутабельный? Если нет, то откуда возьмется объект с новым состоянием?

И вообще ты как-то на конкретные вопросы не отвечаешь.

Как все таки будет выглядеть синтаксис зависимости одних объектов от других, если он основывается на "простом выбирающем выражении"? В изначальном предлагаемом x = a + b, никаких выбирающих выражений не видно.

И по этому поводу:

U>И где этот код заменяет датчик у конкретной машины? Т.е. как выглядит изменение узла дерева, если мы знаем путь до него в дереве?

DG>если мы создаем копию, то не надо изменять узел — необходимо лишь при копировании создать нужный узел вместо исходного

Я спрашивал что надо будет написать вместо new World(world, sensor=>(sensor.id == 37) ? new DiscreteSensor(bla-bla): sensor), если вместо числового идентификатора мы будем знать положение заменяемого сенсора в дереве?

И еще интересно, как выглядит функция new World внутри?
Re[33]: Идеальный синтаксис (постановка задачи)
От: Undying Россия  
Дата: 27.02.11 14:04
Оценка:
Здравствуйте, DarkGray, Вы писали:

U>>Делаем list ленивой оберткой, с остальным виртуальный грид разберется сам.


DG>и как это поможет ловить изменения данных в базе?

DG>если ты собираешься на клиенте постоянно опрашивать list, то кто при этом будет платить за бешеный трафик между клиентом и сервером?

Что-то я тут затупил, кэша достаточно одного, но естественно кэш должен быть на клиенте, а не на сервере. А в интерфейсе сервера должны быть методы GetListPart и GetChangeTick

DG>во сколько строк кода встанет создание такой обертки?

DG>или ты их забыл посчитать, когда говорил что кода будет не больше?

В общем случае тип для результата кэша все равно нужно описывать, т.к. обычно он имеет весьма отдаленное отношение к источникам. В конкретно случае с гридом, опять же обертка получается специализированная, т.к. должна вычитывать данные порциями и как-то их кэшировать, чем тут поможет твое a+b? Так на чем ты собрался экономить?

DG>ты код напиши, ты опять же обещал что его будет немного.

DG>пока я не вижу полного решения, которое автоматом обновляет грид при изменении данных в базе

В чем проблема-то? Делаем триггер изменяющий changeTick, changeTick выставляем в интерфейсе сервера, на клиенте используем обертку, кэширующую строки, если строки нет в кэше, то запрашиваем с сервера ее и сколько-то последующих, если changeTick изменился, то кэш сбрасываем.
Re[34]: Идеальный синтаксис (постановка задачи)
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 27.02.11 15:22
Оценка:
U>Что-то я тут затупил, кэша достаточно одного, но естественно кэш должен быть на клиенте, а не на сервере. А в интерфейсе сервера должны быть методы GetListPart и GetChangeTick

код где?

DG>>во сколько строк кода встанет создание такой обертки?

DG>>или ты их забыл посчитать, когда говорил что кода будет не больше?

U>В общем случае тип для результата кэша все равно нужно описывать, т.к. обычно он имеет весьма отдаленное отношение к источникам. В конкретно случае с гридом, опять же обертка получается специализированная, т.к. должна вычитывать данные порциями и как-то их кэшировать, чем тут поможет твое a+b? Так на чем ты собрался экономить?


вот это всё и экономится, потому что автоматически выводится языком, и писать всё это не надо. в том числе и обертку для грида

DG>>ты код напиши, ты опять же обещал что его будет немного.

DG>>пока я не вижу полного решения, которое автоматом обновляет грид при изменении данных в базе

U>В чем проблема-то? Делаем триггер изменяющий changeTick, changeTick выставляем в интерфейсе сервера, на клиенте используем обертку, кэширующую строки, если строки нет в кэше, то запрашиваем с сервера ее и сколько-то последующих, если changeTick изменился, то кэш сбрасываем.


1. где код?
2. везде упущено, как именно информация об изменении попадает из базы в сервер, а из сервера в клиент
Re[32]: Идеальный синтаксис (постановка задачи)
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 27.02.11 15:23
Оценка:
U>И как это будет выглядеть? Вот мы получали типа иммутабельный объект некой сущности, далее эта сущность изменилась. Иммутабельный объект при этом изменится? Если да, то в каком месте он иммутабельный? Если нет, то откуда возьмется объект с новым состоянием?

ты, вообще, что такое двойственность понимаешь?
и, например, понимаешь что в следующем коде с точки зрения языка: x и y — это разная память, но с точки зрения исполнения это будет одна и та же память.
int x = a * 5 + 7;
float y = x / 4;
Console.WriteLine(y);


то же самое и с иммутабельностью.

U>Вот мы получали типа иммутабельный объект некой сущности, далее эта сущность изменилась. Иммутабельный объект при этом изменится? Если да, то в каком месте он иммутабельный? Если нет, то откуда возьмется объект с новым состоянием?


с точки зрения языка ответы: нет, не изменится, язык создаст новый экземпляр
с точки зрения исполнения: да, объект изменится по месту

U>И вообще ты как-то на конкретные вопросы не отвечаешь.


U>Как все таки будет выглядеть синтаксис зависимости одних объектов от других, если он основывается на "простом выбирающем выражении"? В изначальном предлагаемом x = a + b, никаких выбирающих выражений не видно.


a и b — это и есть частные случаи выбирающих выражений

а чем тебе не нравится синтаксис x = a + b? x есть зависимая переменная от a и b.

или чем тебе этот код не понравился?
var list1 = list(1, 2, 4);
var list2 = db.peoples.(cars.count);
var list = list1 + list2;
grid.RowCount = list.Length;
grid.ViewRows = list[.index >= grid.FirstViewRow && .index < grid.LastViewRow];


все зависимости в коде уже прописаны


U>И по этому поводу:


U>>И где этот код заменяет датчик у конкретной машины? Т.е. как выглядит изменение узла дерева, если мы знаем путь до него в дереве?

DG>>если мы создаем копию, то не надо изменять узел — необходимо лишь при копировании создать нужный узел вместо исходного

U>Я спрашивал что надо будет написать вместо new World(world, sensor=>(sensor.id == 37) ? new DiscreteSensor(bla-bla): sensor), если вместо числового идентификатора мы будем знать положение заменяемого сенсора в дереве?


что такое положение в дереве? позиция в коллекции?
тогда так
world.car[7].sensor[37] = DiscreteSensor(bla-bla);

есть именованный путь? тогда так
world.autopark.director.driver.car.engine.fuel-sensor = DiscreteSensor(bla-bla);


U>написать вместо new World(world, sensor=>(sensor.id == 37) ? new DiscreteSensor(bla-bla): sensor),


этот код не надо писать, этот код исполняется("генерится") языком

U>И еще интересно, как выглядит функция new World внутри?


как-то так, и ее опять же писать самостоятельно не надо
World World(World world, Getter<Sensor, Sensor> sensorReplacer)
{
  var cars = new List<Car>();
  foreach (var car in cars)
  {
    var sensors = new List<Sensor>();
    foreach (var sensor in car.Sensors)
      sensors.Add(sensorReplacer(sensor));
    cars.Add(new Car(sensors));
  }
  return new World(cars);
}
Re[33]: Идеальный синтаксис (постановка задачи)
От: Undying Россия  
Дата: 27.02.11 16:17
Оценка:
Здравствуйте, DarkGray, Вы писали:

DG>ты, вообще, что такое двойственность понимаешь?

DG>и, например, понимаешь что в следующем коде с точки зрения языка: x и y — это разная память, но с точки зрения исполнения это будет одна и та же память.

И что произойдет, если после изменения сущности, я захочу обратиться к устаревшему объекту сущности?

DG>а чем тебе не нравится синтаксис x = a + b? x есть зависимая переменная от a и b.


DG>или чем тебе этот код не понравился?

DG>
DG>var list1 = list(1, 2, 4);
DG>var list2 = db.peoples.(cars.count);
DG>var list = list1 + list2;
DG>grid.RowCount = list.Length;
DG>grid.ViewRows = list[.index >= grid.FirstViewRow && .index < grid.LastViewRow];
DG>


Где здесь признаки-индикаторы, а не сами объекты? (cars.count) что ли?

DG>все зависимости в коде уже прописаны


В интерфейсе сервера есть получение коллекции и получение changeTick, на клиенте при изменении changeTick нужно пересчитать значение переменной на основе коллекции. Как будет выглядеть код?

U>>И еще интересно, как выглядит функция new World внутри?

DG>как-то так, и ее опять же писать самостоятельно не надо

А кто будет писать этот код? Как этот кто-то поймет какой метод создания (конструктор) нужно вызвать для создания объекта? Сейчас в общем случае даже человек, имея старый мир, не может определить как его пересоздать, как это сможет делать автоматика?

DG>
DG>World World(World world, Getter<Sensor, Sensor> sensorReplacer)
DG>{
DG>  var cars = new List<Car>();
DG>  foreach (var car in cars)
DG>  {
DG>    var sensors = new List<Sensor>();
DG>    foreach (var sensor in car.Sensors)
DG>      sensors.Add(sensorReplacer(sensor));
DG>    cars.Add(new Car(sensors));
DG>  }
DG>  return new World(cars);
DG>}
DG>


Допустим, машины у нас бывают двух типов: легковая и грузовая. Как изменится этот код?
Re[35]: Идеальный синтаксис (постановка задачи)
От: Undying Россия  
Дата: 27.02.11 16:30
Оценка:
Здравствуйте, DarkGray, Вы писали:

U>>Что-то я тут затупил, кэша достаточно одного, но естественно кэш должен быть на клиенте, а не на сервере. А в интерфейсе сервера должны быть методы GetListPart и GetChangeTick


DG>код где?


Ты без кода не можешь себе представить как выглядит выставление GetListPart и GetChangeTick в интерфейсе сервера?

U>>В общем случае тип для результата кэша все равно нужно описывать, т.к. обычно он имеет весьма отдаленное отношение к источникам. В конкретно случае с гридом, опять же обертка получается специализированная, т.к. должна вычитывать данные порциями и как-то их кэшировать, чем тут поможет твое a+b? Так на чем ты собрался экономить?


DG>вот это всё и экономится, потому что автоматически выводится языком, и писать всё это не надо. в том числе и обертку для грида


Каким таким волшебным образом? Ты уже ИИ разработал? Откуда язык узнает, что тут вообще нужна какая обертка? Что обертка должна кэшировать данные? Что вычитывать данные нужно не по одной записи, а сразу порциями определенной величины?

DG>>>ты код напиши, ты опять же обещал что его будет немного.

DG>>>пока я не вижу полного решения, которое автоматом обновляет грид при изменении данных в базе

U>>В чем проблема-то? Делаем триггер изменяющий changeTick, changeTick выставляем в интерфейсе сервера, на клиенте используем обертку, кэширующую строки, если строки нет в кэше, то запрашиваем с сервера ее и сколько-то последующих, если changeTick изменился, то кэш сбрасываем.


DG>1. где код?


Что ты из перечисленного не понял? Что ты хочешь в коде увидеть?

DG>2. везде упущено, как именно информация об изменении попадает из базы в сервер, а из сервера в клиент


Самый простой вариант тупо при каждой сработке синхронайзера грида запрашивать changeTick с сервера, который будет его получать запросом из базы. Учитывая, что на экране обычно штучное количество гридов особых затрат траффика не будет (полезной информации там будет по 8 байт в секунду на грид, накладных расходов на протокол правда значительно больше). Если оптимизировать, то можно в дополнение к changeTick сделать события о изменении.
Re[34]: Идеальный синтаксис (постановка задачи)
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 27.02.11 17:21
Оценка:
U>И что произойдет, если после изменения сущности, я захочу обратиться к устаревшему объекту сущности?

каким это образом? через какую переменную? ты где-то объявил переменную, которая жестко ссылается на старый мир?
если есть такая переменная, которая хочет ссылаться на старую копию, тогда значит изменения по месту не будет, а будет копирование мира.

DG>>а чем тебе не нравится синтаксис x = a + b? x есть зависимая переменная от a и b.


DG>>или чем тебе этот код не понравился?

DG>>
DG>>var list1 = list(1, 2, 4);
DG>>var list2 = db.peoples.(cars.count);
DG>>var list = list1 + list2;
DG>>grid.RowCount = list.Length;
DG>>grid.ViewRows = list[.index >= grid.FirstViewRow && .index < grid.LastViewRow];
DG>>


U>Где здесь признаки-индикаторы, а не сами объекты? (cars.count) что ли?


зачем они нужны? признаки-индикаторы — это конечная оптимизация, когда вместо честного сравнения делается нечестное, по индикатору.
и такую оптимизацию должен делать язык, а не программист.

DG>>все зависимости в коде уже прописаны


U>В интерфейсе сервера есть получение коллекции и получение changeTick, на клиенте при изменении changeTick нужно пересчитать значение переменной на основе коллекции. Как будет выглядеть код?


нет такой реальной задачи. так же как нет задачи — в ячейку памяти номер $1581 записать число 3.
есть задача — значение переменной должна всегда быть равно данному выражению от коллекции.

такую оптимизацию, если необходимо, может сделать язык — и сравнение делать по changeTick-у, а не по элементное.

U>>>И еще интересно, как выглядит функция new World внутри?

DG>>как-то так, и ее опять же писать самостоятельно не надо

U>А кто будет писать этот код? Как этот кто-то поймет какой метод создания (конструктор) нужно вызвать для создания объекта? Сейчас в общем случае даже человек, имея старый мир, не может определить как его пересоздать, как это сможет делать автоматика?


но старый мир как-то в коде же создавался, или он был дан инопланетянами свыше?

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


U>Допустим, машины у нас бывают двух типов: легковая и грузовая. Как изменится этот код?


будет
    car.Type.Create(sensors);
Re[36]: Идеальный синтаксис (постановка задачи)
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 27.02.11 17:43
Оценка:
DG>>код где?

U>Ты без кода не можешь себе представить как выглядит выставление GetListPart и GetChangeTick в интерфейсе сервера?


я сомневаюсь в твоих словах, что кода писать надо мало, поэтому я хочу увидеть код — который наглядно показывает, что кода действительно мало.

DG>>вот это всё и экономится, потому что автоматически выводится языком, и писать всё это не надо. в том числе и обертку для грида


U>Каким таким волшебным образом? Ты уже ИИ разработал? Откуда язык узнает, что тут вообще нужна какая обертка? Что обертка должна кэшировать данные? Что вычитывать данные нужно не по одной записи, а сразу порциями определенной величины?


все ответы уже написаны в коде.

> Откуда язык узнает, что тут вообще нужна какая обертка?


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

> Что обертка должна кэшировать данные?


используемые данные всегда кэшируются

> Что вычитывать данные нужно не по одной записи, а сразу порциями определенной величины?


это в коде написано
grid.ViewRows = list[.index >= grid.FirstViewRow && .index < grid.LastViewRow]

DG>>1. где код?


U>Что ты из перечисленного не понял? Что ты хочешь в коде увидеть?


я хочу увидеть код, который демонстрирует, что его действительно необходимо мало писать.

DG>>2. везде упущено, как именно информация об изменении попадает из базы в сервер, а из сервера в клиент


U>Самый простой вариант тупо при каждой сработке синхронайзера грида запрашивать changeTick с сервера, который будет его получать запросом из базы. Учитывая, что на экране обычно штучное количество гридов особых затрат траффика не будет (полезной информации там будет по 8 байт в секунду на грид, накладных расходов на протокол правда значительно больше). Если оптимизировать, то можно в дополнение к changeTick сделать события о изменении.


т.е. данные будут меняться не чаще одного раза в секунду?
при этом кол-во запросов на сервер в секунду будет кол-во открытых окон у всех клиентов?
соответственно при тысяче клиентов на ответ на запрос необходимо тратить ресурсов 1мс, трафик на сервере — 8мбит/c (при условии что минимальный пакет — 1кбайт)
при миллионе клиентов на ответ на запрос необходимо тратить ресурсов 1мкс, трафик на сервере — 8гбит/с
а такие серверы бывают?
Re[35]: Идеальный синтаксис (постановка задачи)
От: Undying Россия  
Дата: 27.02.11 18:18
Оценка:
Здравствуйте, DarkGray, Вы писали:

DG>каким это образом? через какую переменную? ты где-то объявил переменную, которая жестко ссылается на старый мир?

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

Большинство локальных функций объявляет такие переменные. Соответственно часто даже у самой функции модифицирующей мир есть ссылка на его старое состояние:

foreach (Sensor sensor in world.Car.Sensors)
sensor.Kind = "";


В итоге получается, если у нас многопоточное высоконагруженное приложение, то локальные функции в нем выполняются постоянно, а, значит, каждая модификация мира будет приводить к его пересозданию. В малонагруженном тоже все плохо, т.к. время модификации получается недетерминированным. Записал модификацию в цикле аккуратно все работает нормально, неосторожно зафиксировал старое состояние мира перед циклом и получил тормоза по полной. Как с этим работать-то?

DG>зачем они нужны? признаки-индикаторы — это конечная оптимизация, когда вместо честного сравнения делается нечестное, по индикатору.

DG>и такую оптимизацию должен делать язык, а не программист.

Так как язык догадается, что для объектов зафисящих от GetListPart нужно использовать GetChangeTick?

DG>такую оптимизацию, если необходимо, может сделать язык — и сравнение делать по changeTick-у, а не по элементное.


Как язык понимает что здесь нужно использовать changeTick и какой именно changeTick?

U>>А кто будет писать этот код? Как этот кто-то поймет какой метод создания (конструктор) нужно вызвать для создания объекта? Сейчас в общем случае даже человек, имея старый мир, не может определить как его пересоздать, как это сможет делать автоматика?


DG>но старый мир как-то в коде же создавался, или он был дан инопланетянами свыше?


Переменная принимаемая в конструкторе может быть а) временной (т.е. на ее основе создается другой объект и уже он хранится в классе), б) приватной.

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

U>>Допустим, машины у нас бывают двух типов: легковая и грузовая. Как изменится этот код?


DG>будет

DG>
DG>    car.Type.Create(sensors);
DG>


А ежели у легковой машины одни параметры, а у грузовой другие?
Re[37]: Идеальный синтаксис (постановка задачи)
От: Undying Россия  
Дата: 27.02.11 18:49
Оценка:
Здравствуйте, DarkGray, Вы писали:

DG>я сомневаюсь в твоих словах, что кода писать надо мало, поэтому я хочу увидеть код — который наглядно показывает, что кода действительно мало.


Где я говорил, что кода будет мало? Код будет простым, т.е. будет легко понимаемым, не будет содержать подводных камней и будет легко модифицироваться. Лаконичность решения я вообще не считаю мало-мальски важной характеристикой, т.к. время записи решения обычно много меньше обдумывания решения, а с простотой лаконичность не коррелирует.

DG>обертка не нужна.

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

Ты бы в начале хотя бы механизм решения простых задач показал, а потом уже такими определениями бросался. А то магия сплошная.

>> Что обертка должна кэшировать данные?

DG>используемые данные всегда кэшируются

>> Что вычитывать данные нужно не по одной записи, а сразу порциями определенной величины?


DG>это в коде написано

DG>grid.ViewRows = list[.index >= grid.FirstViewRow && .index < grid.LastViewRow]

Как у нас выглядит метод GetList2 и каким образом он на основе этой строчки научился брать из базы данные по частям?

DG>т.е. данные будут меняться не чаще одного раза в секунду?

DG>при этом кол-во запросов на сервер в секунду будет кол-во открытых окон у всех клиентов?
DG>соответственно при тысяче клиентов на ответ на запрос необходимо тратить ресурсов 1мс, трафик на сервере — 8мбит/c (при условии что минимальный пакет — 1кбайт)
DG>при миллионе клиентов на ответ на запрос необходимо тратить ресурсов 1мкс, трафик на сервере — 8гбит/с
DG>а такие серверы бывают?

Получай changeTick'и не напрямую, а через события (обратную связь). Проблема-то в чем?
Re[36]: Идеальный синтаксис (постановка задачи)
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 27.02.11 19:17
Оценка:
U>Большинство локальных функций объявляет такие переменные. Соответственно часто даже у самой функции модифицирующей мир есть ссылка на его старое состояние:

и кого интересуют локальные переменные? если их время жизни — время работы функции.

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


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

DG>>зачем они нужны? признаки-индикаторы — это конечная оптимизация, когда вместо честного сравнения делается нечестное, по индикатору.

DG>>и такую оптимизацию должен делать язык, а не программист.

U>Так как язык догадается, что для объектов зафисящих от GetListPart нужно использовать GetChangeTick?


это звучит, как фраза вида: как gc догадается, что переменная x лежит в ячейке 5?
и ответ одинаковый — раз язык сам сгенерил эти функции(сам разместил переменную x в ячейку 5), то он уж как-нибудь догадается, что именно их надо вызывать

DG>>такую оптимизацию, если необходимо, может сделать язык — и сравнение делать по changeTick-у, а не по элементное.


U>Как язык понимает что здесь нужно использовать changeTick и какой именно changeTick?


на основе правил оптимизации, в частности:
как только появляется отношение много ко много (множество результатов зависит от коллекции), то изменение стоит вычислять через сhangetick, а не напрямую.

DG>>но старый мир как-то в коде же создавался, или он был дан инопланетянами свыше?


U>Переменная принимаемая в конструкторе может быть а) временной (т.е. на ее основе создается другой объект и уже он хранится в классе), б) приватной.


это какие-то частности, которые не отменяют того факта, что всегда есть полный конструктор экземпляра

U>Да, кстати, я так и не увидел как выглядит метод пересоздания мира, если нужно заменить датчик у конкретной машины.


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

U>>>Допустим, машины у нас бывают двух типов: легковая и грузовая. Как изменится этот код?


DG>>будет

DG>>
DG>>    car.Type.Create(sensors);
DG>>


U>А ежели у легковой машины одни параметры, а у грузовой другие?


значит if добавится, либо виртуальный вызов
Re[38]: Идеальный синтаксис (постановка задачи)
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 27.02.11 19:40
Оценка:
U>Где я говорил, что кода будет мало? Код будет простым, т.е. будет легко понимаемым, не будет содержать подводных камней и будет легко модифицироваться. Лаконичность решения я вообще не считаю мало-мальски важной характеристикой, т.к. время записи решения обычно много меньше обдумывания решения, а с простотой лаконичность не коррелирует.

т.е. ты уже понял, что ты был не прав когда говорил
U> Т.е. гибкость снижается на порядок, в лаконичности выигрываем копейки, ну и нафиг такое счастье?
и начинаешь юлить?

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


DG>>обертка не нужна.

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

U>Ты бы в начале хотя бы механизм решения простых задач показал, а потом уже такими определениями бросался. А то магия сплошная.


давай примеры простых задач


>>> Что обертка должна кэшировать данные?

DG>>используемые данные всегда кэшируются

>>> Что вычитывать данные нужно не по одной записи, а сразу порциями определенной величины?


DG>>это в коде написано

DG>>grid.ViewRows = list[.index >= grid.FirstViewRow && .index < grid.LastViewRow]

U>Как у нас выглядит метод GetList2 и каким образом он на основе этой строчки научился брать из базы данные по частям?


GetList2 допустим выглядит как
int-s GetList2()
{
return db.peoples.(cars.count);
}

тогда запрос list[.index >= grid.FirstViewRow && .index < grid.LastViewRow] трансформируется последовательно:
//a. 
(list1+list2)[.index >= grid.FirstViewRow && .index < grid.LastViewRow]
//b.
 list2[.index >= grid.FirstViewRow - list1.Count && .index < grid.LastViewRow - list1.Count]
//c.
 db.peoples[.index >= grid.FirstViewRow - list1.Count && .index < grid.LastViewRow - list1.Count].(cars.count)
//d. 
select * from(
  select (select count(*) from cars where cars.peopleid=peoples.id) from peoples
)
between grid.FirstViewRow - list1.Count and grid.LastViewRow - list1.Count



U>Получай changeTick'и не напрямую, а через события (обратную связь). Проблема-то в чем?


дублирование кода
Re[30]: Идеальный синтаксис (постановка задачи)
От: VoidEx  
Дата: 01.03.11 11:06
Оценка:
Здравствуйте, Undying, Вы писали:

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


VE>>Они и не видимы. Как определить, создался иммутабельный объект или вернулся?

VE>>И почему тогда тем же способом не определить ленивое создание.

U>Если мы весь мир делаем иммутабельным, то возникает другая проблема. Мир штука тяжелая и его пересоздание далеко не бесплатно, соответственно если иммутабельный объект тяжел, то создался он или вернулся становится очень даже заметно с точки зрения производительности.


Пересоздание != создание на основе старого.

Список (1 : tail (listOf1000000000000000000Elements)) создается за константное время.
В любом случае, таким же образом и ленивое создание становится очень даже заметным по тому, в какой именно момент, соответственно это никакое не исключение и должно быть отображено в названии по твоей логике.
Re[39]: Идеальный синтаксис (постановка задачи)
От: Undying Россия  
Дата: 05.03.11 12:17
Оценка:
Здравствуйте, DarkGray, Вы писали:

DG>т.е. ты уже понял, что ты был не прав когда говорил

U>> Т.е. гибкость снижается на порядок, в лаконичности выигрываем копейки, ну и нафиг такое счастье?
DG>и начинаешь юлить?

А, ты про это. Выигрыш в лаконичности записи автоматического кэша встроенного в язык составляет копейки по сравнению с записью автоматического кэша реализованного библиотекой. То же самое и с кэшированием строк для грида, лаконичность решения встроенного в язык не шибко выше лаконичности решения реализованного в виде библиотеки.

U>>Как у нас выглядит метод GetList2 и каким образом он на основе этой строчки научился брать из базы данные по частям?


DG>GetList2 допустим выглядит как

DG>int-s GetList2()
DG>{
DG> return db.peoples.(cars.count);
DG>}

А если завтра задача изменится и группировку нужно будет делать не по номеру строк, а допустим по филиалам предприятия, то что мы делать будем? Ждать, когда в язык встроят поддержку филиалов предприятия?

U>>Получай changeTick'и не напрямую, а через события (обратную связь). Проблема-то в чем?

DG>дублирование кода

В чем заключается дублирование кода и почему его не будет если решение встроить в язык, а не реализовать библиотекой?
Re[31]: Идеальный синтаксис (постановка задачи)
От: Undying Россия  
Дата: 05.03.11 12:25
Оценка:
Здравствуйте, VoidEx, Вы писали:

VE>Список (1 : tail (listOf1000000000000000000Elements)) создается за константное время.

VE>В любом случае, таким же образом и ленивое создание становится очень даже заметным по тому, в какой именно момент, соответственно это никакое не исключение и должно быть отображено в названии по твоей логике.

Действительно, даже когда автоматическими кэшами описывается далеко не весь мир и пересчитывание значений кэша по возможности делается легким, такие проблемы возникают. И эти проблемы серьезно затрудняют понимание, а, значит, и качество кода. Если же пересчитывать весь мир, то такие проблемы из редко встречающихся станут массовыми. Соответственно, добавление префикса к проблемным вызовам будет хоть и костыльным, но полезным решением.
Re[37]: Идеальный синтаксис (постановка задачи)
От: Undying Россия  
Дата: 05.03.11 12:31
Оценка:
Здравствуйте, DarkGray, Вы писали:

DG>неправильная предпосылка ведет к неправильным выводам.

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

В какой момент будет производиться клонирование куска старого мира?

U>>Да, кстати, я так и не увидел как выглядит метод пересоздания мира, если нужно заменить датчик у конкретной машины.

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

Ты вместо ответа фигню какую-то написал, вида:

world.autopark.director.driver.car.engine.fuel-sensor = DiscreteSensor(bla-bla);


Вопрос же был как это будет выглядеть внутри функции RecreateWorld.
Re[40]: Идеальный синтаксис (постановка задачи)
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 05.03.11 15:12
Оценка:
DG>>GetList2 допустим выглядит как
DG>>int-s GetList2()
DG>>{
DG>> return db.peoples.(cars.count);
DG>>}

U>А если завтра задача изменится и группировку нужно будет делать не по номеру строк, а допустим по филиалам предприятия, то что мы делать будем? Ждать, когда в язык встроят поддержку филиалов предприятия?


а где ты тут увидел, что здесь что-то встроено в язык? а не реализовано как мета-библиотека?


U>>>Получай changeTick'и не напрямую, а через события (обратную связь). Проблема-то в чем?

DG>>дублирование кода

U>В чем заключается дублирование кода и почему его не будет если решение встроить в язык, а не реализовать библиотекой?


есть такое наблюдение, что для того, чтобы решить проблемы внутри системы необходимо выйти в надсистему.
а библиотека — это вообще подсистема.

и соответственно, кэширование удобнее реализовать через надсистему (берется код, и по нему автоматически расставляются кэши), а не через подсистему (есть библиотека, реализующая кэш, которая как-то в ряде мест присобачивается к программе)
Re: Идеальный синтаксис (постановка задачи)
От: Voblin Россия http://maslyaew.narod.ru/
Дата: 05.03.11 16:12
Оценка:
Здравствуйте, DarkGray, Вы писали:

DG>примечание: синтаксис трактуется в узком смысле, как способ записи информации в виде текста (последовательности символов)


DG>Что такое информация?

На этот вопрос может быть два ответа.
Ответ первый: Каждый из нас знает, что такое информация. То, что никто не может выразить это знание словами, не впадая в тавтологии и сомнительные аллегории — не такая уж и большая проблема.
Ответ второй: ... второй ответ тоже есть. Но его пока никто не сформулировал. Просто не смог. Потому что для этого нужен совсем чудовищный выверт ума. Как словами описать, что такое информация, если сами используемые слова — они уже сами по себе информация?

А можно пойти от обратного — найти то, что не является информацией. Ну да, есть такая штука. "Вещь-в-себе" называется. Она же — "вещь-сама-по-себе". Впрочем, это уже совсем хардкорная философия. Не уверен, что стоит её здесь разводить.

DG>начнем с простого: структуры и атомы.

DG>структура — это вид отношений(связей) между атомами.
Тускловато получается. Не исключено, что каждый атом так или иначе оказывает влияние на каждый другой атом...
Или имеются в виду атомарные факты?

DG>выделяют (по мере усложнения) следующие структуры: один элемент, множество(список), дерево, граф.

Дерево — крайне противоестественная структура. Единственное, что в ней естественного — это то, что она естественна для нашего мышления, которое легко справляется с базовыми "деревянными" операциями — обобщением (от "листочков" к Пэренту) и декомпозицией.
А в реальности деревьев почти совсем не бывает. Даже то дерево, которое растение, при внимательном рассмотрении оказывается... скопищем жилочек, слепленных в нечто древовидное чисто для того, чтобы ветром не гнуло. Даже родителей у каждого из нас — не один, а два.

Если бы мы умели мыслить только иерархиями, проблемы того, что в реальности деревья — большая редкость, не было бы вообще. Весь наш мир состоял бы из иерархий, и никаких альтернатив мы бы просто не знали. Поэтому учиться мыслить не иерархически — это не только возможно, но и очень полезно.

Метод отучения от "деревянного мышления" прост и незатейлив. Нужно каждый раз, когда, казалось бы, всё разложилось по полочкам "уровней", "подчинения", "вхождения" и т.п., нужно подумать следующую мысль: "А на самом деле всё намного сложнее и интереснее".

Так что не нравится мне синтаксис, который впихивает всё-всё-всё в одни сплошные деревья. Как-то это ущербненько. Извините.
Re[41]: Идеальный синтаксис (постановка задачи)
От: Undying Россия  
Дата: 09.03.11 06:43
Оценка:
Здравствуйте, DarkGray, Вы писали:

U>>А если завтра задача изменится и группировку нужно будет делать не по номеру строк, а допустим по филиалам предприятия, то что мы делать будем? Ждать, когда в язык встроят поддержку филиалов предприятия?


DG>а где ты тут увидел, что здесь что-то встроено в язык? а не реализовано как мета-библиотека?


А если завтра задача изменится и группировку нужно будет делать не по номеру строк, а допустим по филиалам предприятия, то что мы делать будем? Ждать когда в мета-библиотеку встроят поддержку филиалов предприятия?
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.