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

ANS>>Я думал о рефлексии. Тогда всё действительно сводится к тому, что не хватает relation, как первоклассной сущности.
S>relation как первоклассная сущность в SQL есть. Нет функций как первоклассной сущности.

Не совсем понял. Ты пишешь, что так нельзя:

Вот чего нельзя сделать в SQL:

public IQueryable<T> SearchPerson<T>(IQueryable<T> source, string searchText) 
  where T: IPerson
{
   from p in source 
     where p.FirstName.Contains(searchText) || p.LastName.Contains(searchText)
...

Т.е. `source` как параметр передать нельзя. И тут же ты говоришь, что relation это первоклассная сущность. Какой тогда критерий первоклассности чего-либо, если не (не)возможность передать это нечто аргументом в функцию?

S>Подзапросы не спасут вас от монолитности запроса — это всего лишь те же шесть страниц, записанные в другом порядке.
Пожалуй, это проблемы хост-языка, а не самого SQL. В Java это решаемо. А если нерешаемо в T-SQL, то это проблемы именно T-SQL.

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

S>Ну, а язык для компиляторов не обязан позволять написать фильтр. Или, по крайней мере, написать его удобно (понятно, что любой тьюринг-полный язык сразу даст написать и фильтр, и компилятор с DSL).

Самое смешное, что как раз язык для написания компиляторов и не должен быть Тьюринг-полным. Для него это крайне нежелательное свойство. Смотрите на Coq (и на CompCert за примером применения).

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

WH>>1)В институте плохому учат. У них там все действительно сложнее, чем надо получается.
WH>>2)Сложность рукопашного кода всё равно больше. Чем сложность компилятора.
T>Не нужно передергивать.
В каком месте?

T>"Сложность рукопашного кода всё равно больше" — для каких задач ?
Для всех чей домен не является подмножеством используемого языка.
Те для чуть менее чем всех.

T>Всегда ли нужно писать полноценное решение ?
А какое еще?

T>На примере CSV-парсера. В разных проектах, в которые пришлось сунуть нос, видел уже наверное под сотню парсеров, от простых вроде string.split до всяких регулярных выражений и тд. Работают все по разному, с разной степенью надежности, производительности и тд.
CSV? string.split'ом? Оригинально.

T>1 Покажи на примере этой простой задачи преимущества DSL.
Так это зависит от того что ты делаешь.
Скажи, зачем ты парсишь CSV?

T>2 Всегда ли нужно писать полноценный парсер вроде CSV ?
А как иначе? Если нам нужно разобрать CSV то нам нужно писать его парсер.

T>3 Объясни, кем заменить тех, кто не в состоянии написать чтото большее string.split ?
Этих по-хорошему нужно гнать из профессии.
Но если приспичило можно их посадить писать код на ДСЛ, который не дает делать плохие вещи.

T>DSL, хочешь ты или нет, это очень сложная тема.
Только для тех, кто ничего кроме книги дракона не видел.

T>Очевиднл, рукапашный код будет еще сложнее, но сложности задачи это не отменяет. Если люди способны работать на продакшн и могут писать вроде string.split, то нужно предложить хорошую замену задирая планку требований до небес.
Ничего не понял.

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

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

PSV>>Создаётся чистый HTML (пусть верстальщиком, дизайнером), без шаблонов, без CSS-элементов, без никакого кода, где есть некоторые правила, например, условные имена для div. Программист в коде читает этот файл, он трансформируется в структуры и пр. этого языка, дальше манипулируй с документом как хочешь в рамках программного кода.
WH>Я бы не сказал что это хороший подход.
WH>ИМХО тут слишком много не нужной работы.
Ну, главное, чтобы работа была, а когда надо, уменьшить её сможем .

Я тут посмотрел то, что, скорее всего, ты имел в виду. Здесь, кажись Влад, давал ссылку на пример из knockoutjs, приведу код оттуда.
Это View:

<h2>Planets</h2>
<p>
    <label>
        <input type='checkbox' data-bind='checked: displayAdvancedOptions' />
        Display advanced options
    </label>
</p>
 
<p data-bind='fadeVisible: displayAdvancedOptions'>
    Show:
    <label><input type='radio' name="type" value='all' data-bind='checked: typeToShow' />All</label>
    <label><input type='radio' name="type" value='rock' data-bind='checked: typeToShow' />Rocky planets</label>
    <label><input type='radio' name="type" value='gasgiant' data-bind='checked: typeToShow' />Gas giants</label>
</p>
 
<div data-bind='template: { foreach: planetsToShow,
                            beforeRemove: hidePlanetElement,
                            afterAdd: showPlanetElement }'>
    <div data-bind='attr: { "class": "planet " + type }, text: name'> </div>
</div>
 
<p data-bind='fadeVisible: displayAdvancedOptions'>
    <button data-bind='click: addPlanet.bind($data, "rock")'>Add rocky planet</button>
    <button data-bind='click: addPlanet.bind($data, "gasgiant")'>Add gas giant</button>
</p>

И код для View model:

var PlanetsModel = function() {
    this.planets = ko.observableArray([
        { name: "Mercury", type: "rock"},
        { name: "Venus", type: "rock"},
        { name: "Earth", type: "rock"},
        { name: "Mars", type: "rock"},
        { name: "Jupiter", type: "gasgiant"},
        { name: "Saturn", type: "gasgiant"},
        { name: "Uranus", type: "gasgiant"},
        { name: "Neptune", type: "gasgiant"},
        { name: "Pluto", type: "rock"}
    ]);
 
    this.typeToShow = ko.observable("all");
    this.displayAdvancedOptions = ko.observable(false);
 
    this.addPlanet = function(type) {
        this.planets.push({
            name: "New planet",
            type: type
        });
    };
 
    this.planetsToShow = ko.computed(function() {
        // Represents a filtered list of planets
        // i.e., only those matching the "typeToShow" condition
        var desiredType = this.typeToShow();
        if (desiredType == "all") return this.planets();
        return ko.utils.arrayFilter(this.planets(), function(planet) {
            return planet.type == desiredType;
        });
    }, this);
 
    // Animation callbacks for the planets list
    this.showPlanetElement = function(elem) { if (elem.nodeType === 1) $(elem).hide().slideDown() }
    this.hidePlanetElement = function(elem) { if (elem.nodeType === 1) $(elem).slideUp(function() { $(elem).remove(); }) }
};
 
// Here's a custom Knockout binding that makes elements shown/hidden via jQuery's fadeIn()/fadeOut() methods
// Could be stored in a separate utility library
ko.bindingHandlers.fadeVisible = {
    init: function(element, valueAccessor) {
        // Initially set the element to be instantly visible/hidden depending on the value
        var value = valueAccessor();
        $(element).toggle(ko.utils.unwrapObservable(value)); // Use "unwrapObservable" so we can handle values that may or may not be observable
    },
    update: function(element, valueAccessor) {
        // Whenever the value subsequently changes, slowly fade the element in or out
        var value = valueAccessor();
        ko.utils.unwrapObservable(value) ? $(element).fadeIn() : $(element).fadeOut();
    }
};
 
ko.applyBindings(new PlanetsModel());

И здесь ты давал ссылки на прототип DSL для Немерля, как я понимаю, по мотивам этого knockoutjs (здесь

Автор: WolfHound
Дата: 15.02.11

и здесь

Автор: WolfHound
Дата: 14.02.11

).
Да, конечно, DSL неплох, сразу позволяет в HTML декларативно задать много чего, с меньшей возней и реально с меньшей работой. Но этот DSL хорош именно для программистов. Я понимаю, что в реальной жизни, имхо, больше случаев, когда программист сам себе дизайнер. В предыдущем своём посту я больше акцентировал внимание на тот случай, когда в проект притаскиваются специалисты по юзабилити. Какому-то верстальщику, или дизайнеру (на всякий случай, чтобы здесь никого не обидеть, назвав стилиста парикмахером), имхо, уже непросто будет набрать подобный View. Во-первых, дизайнерам нужно разобраться с новым языком, пусть и несложным, похожим на HTML, но со своими нюансами. Во-вторых, им нужно или изучить новый инструментарий для этого языка, если имеется, или адаптировать свои годами подточенные IDE/редакторы для вёрстки HTML. Имхо, это всё несложно решаемо. Главная беда в том, что дизайнерам, имхо, обычно пофиг, как устроена программа и как она будет создавать документы. Им не только в лом набирать всякий биндинг, но и опасно это делать: программисты долго будут материться от того, что эти спецы набиндили.

Вот примерно то, о чём я говорил в рамках всяких фреймворках для Кложуры:

<html>
<head>
  <title></title>
  <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>

<body>
<div>
  <div id="msg1">Old value: <span id="old" /></div>
  <div id="msg2" />
  <form method="post" action="/some_action" >
    <input type="text" name="value" ></input><input type="submit" name="ok" ></input>
  </form>
</div>

Это заготовка для HTML, чистая разметка без ничего лишнего. Вот по таким мотивам можно обрабатывать HTML:

(html/deftemplate page-index "web_clojure_demo/index.html" [ctxt]
  [:title] (html/content "Awesome application")
  [:#old] (html/content (:old ctxt))
  [:#msg2] (html/set-attr "style" "display: none"))

(html/deftemplate page-summary "web_clojure_demo/index.html" [ctxt]
  [:title] (html/content "Awesome application")
  [:#old] (html/content (:old ctxt))
  [:#msg2] (html/content (str "Summary is " (:sum ctxt))))

Здесь создаются две функции, которые принимают параметр ctxt, загружают html-шаблон и модифицируют содержимое, изменяют стили.
Вот так эти функции можно применять:

(defn parse-input [a]
  (Integer/parseInt a))

(defn index []
  (let [old (redis/get db "value")]
    (page-index {:old old})))

(defn summary [value]
  (let [old (redis/get db "value")]
    (redis/set db "value" value)
    (page-summary { :sum (+ (parse-input value) (parse-input old))
                    :old old})))

HTML, CSS можно лепить с нуля в таком стиле:

(defpartial todo-item [{:keys [id title due]}]
    [:li {:id id} ;; maps define HTML attributes
        [:h3 title]
        [:span.due due]]) ;; add a class

(defpartial todos-list [items]
    [:ul#todoItems ;; set the id attribute
        (map todo-item items)])

(todos-list [{:id "todo1"
              :title "Get Milk"
              :due "today"}])
;; =>
;; <ul id="todoItems">
;; <li id="todo1">
;; <h3>Get Milk</h3>
;; <span class="due">today</span>
;; </li>
;; </ul>

Короче говоря, в самом лиспе можно вертеть/крутить HTML и CSS как угодно.

Но это не главное, что хотел сказать. Вот вырезка из ссылки по поводу прототипа DSL для Немерля:

view HelloView(model : HelloModel)
{
    <p>First name: <input value <-> model.firstName; /></p>
    <p>Last name: <input value <-> model.lastName; /></p>
    <h2>Hello, <span text <- model.fullName; />!</h2>
}

model HelloModel
{
    firstName : string = "Planet";
    lastName : string = "Earth";
    fullName : string <- $"$firstName $lastName";
}

Здесь, как простой пример, понятен даже дизайнеру, в принципе, ему можно объяснить декларации для отношений.

А здесь:

view BetterListView(model : BetterListModel)
{
    <def itemToAdd = ""; />
    <form submit -> model.addItem(itemToAdd); >
            Add item: <input type = text; value <-> itemToAdd; valueUpdate = afterkeydown; />
            <button type = submit; enable <- !itemToAdd.IsEmpty; >Add</button>
    </form>
     
    <p>Your values:</p>
    <select multiple = multiple; height = 5; options <- model.items;  selectedOptions <-> selectedItems; />
     
    <div>
        <def selectedItems = []; />
        <button click -> model.removeItems(selectedItems); enable <- !selectedItems.IsEmpty; >Remove</button>
        <button click -> model.items.sort(); enable <- items.Length > 1; >Sort</button>
    </div>
}

model BetterListModel
{
    items : list[string] = ["Fries", "Eggs Benedict", "Ham", "Cheese"];
    addItem(item : stirng) : void
    {
        items.Add(item);
    }
    remodeItems(itemsToRemove : list[ListItem[stirng]]) : void
    {
        items.RemoveAll(itemsToRemove);
    }
}

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

А здесь:

view TemplatingView(model : PeopleModel)
{
    <div content <- PeopleView(model); />
    <label><input type = checkbox; checked <-> showRenderTimes; /> Show render times</label>
}

view PeopleView(model : PeopleModel)
{
    <h2>People</h2>
    <ul>
        <li foreach (person in model.people)>
            <div>
                $(person.name) has <span text <- $"$(children().length)">&nbsp;</span> children:
                <a click -> person.addChild(); >Add child</a>
                <span class = "renderTime"; visible <- model.showRenderTimes; >
                    (person rendered at <span text = $"$(Date().getSeconds())"; />)
                </span>
            </div>
            <div content <- ChildrenView(mode, person.children); />
        </li>
    </ul>
}

view ChildrenView(model : PeopleModel, children : list[string])
{
    <ul>
        <li foreach (name in children)>
            $name
            <span class = "renderTime"; visible <- model.showRenderTimes; >
                (child rendered at <span text = $"$(Date().getSeconds())"; />)
            </span>
        </li>
    </ul>
}


model PersonModel
{
    name : string;
    children : list[string];
    addChild() : void
    {
        children.Add("New child");
    }
}

model PeopleModel
{
    people : list[PersonModel] = [
        PersonModel("Annabelle", ["Arnie", "Anders", "Apple"]),
        PersonModel("Bertie", ["Boutros-Boutros", "Brianna", "Barbie", "Bee-bop"]),
        PersonModel("Charles", ["Cayenne", "Cleopatra"])
    ];
    showRenderTimes : bool = false;
}

уже и программистам тяжко. Сам по себе HTML крайне тяжёл для работы с ним вручную, а когда он разбавляется ещё алгоритмическим кодом или кодо-подобными тэгами, становится ещё грустнее.

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

// оформим шаблон так для примера, теоретически он может быть во внешнем HTML-файле и как-то получен оттуда: 

template HelloTempl
{
<html>
<body>
    <p>First name: <input value type="text" name="firstName" /></p>
    <p>Last name: <input value type="text" name="lastName" /></p>
    <h2>Hello, <span id="fullName" />!</h2>
}

view HelloView(template: HelloTempl, model: HelloModel)
{
    template.firstName <-> model.firstName;
    template.lastName <-> model.lastName;
    template.fullName <- model.fullName;
    
    //могут быть и другие настройки:
    template.anyElement.style = display: none;
}

model HelloModel
{
    firstName : string = "Planet";
    lastName : string = "Earth";
    fullName : string <- $"$firstName $lastName";
}

Короче говоря, когда всё разделено, обычно, как-то проще жить, более гибче. Здесь HTML будет иметь натуральный вид, или можно использовать любой DSL для HTML (типа HAML), чтобы упростить, как минимум, теперь уже необходимость в явном указании атрибутов вида type="..." name="..." id = "..." и т.д. Кому-то проще набирать через Zen Coding и т.д. При этом, я думаю, что можно сохранить основные задуманные фишки: вычисления во время компиляции, какие нужно, контроль типов, ну и реактивность.

Иными словами, если бы я занимался соответствующим проектом, то задумался бы, стоит ли делать только такие шаблоны по мотивам knockoutjs, во всяком случае, только ими ограничиться. Это сугубо моё личное имхо.

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

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

VE>>А как бы стоило сделать на твой взгляд?
WH>Никак. Языки общего назначения не имеют смысла.
WH>Чем больше изучаю, тем сильнее утверждаюсь в этом мнении.

WH>Вот буквально только что презенташка попалась.
WH>http://suif.stanford.edu/~jwhaley/PLDITutorial.ppt
WH>http://bddbddb.sourceforge.net/index.html
WH>56 страниц сильно оптимизированного кода на жабе (год разработки) против 17 строк на ДСЛ (год разработки компилятора).
WH>ДСЛ работал в 2 раза быстрее. Плюс на этом ДСЛ еще кучу кода, потом понаписали. Как следствие сэкономили десятилетия работы.
WH>Про то, что код на ДСЛ проще понять, поддерживать, развивать и там намного меньше багов я думаю можно даже не заикаться.

WH>А для распространённых задач ДСЛи уже будут написаны.

Ну и что?
Практическая ценность с этого какая? Честно говоря было бы уместней не подобные сравнения, в этот самый "ДСЛ" с перечнем его преимуществ как платформу для разработки и документацией. Если все действительно так радужно — то будет как C, C++ & co. Найдет свое место, а пока это нишевый продукт. Что как бы намекает, на общее назначение и смысл)) (во избежание споров — это шутка, а не противопоставление)

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

V>>Давно уже. Мощность некоторого языка — это мощность мн-ва допустимых цепочек.

G>Это мощность парсера. А еще семантика этих цепочек есть.

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

Тебя же не смущает, что лексер вообще по регулярной грамматике бегает? Это только часть разбора.


V>>Отсебятина из-за непонимания. кол-во писанины зависит исключительно от соотношения встроенных в язык/библиотеки ср-в и потребностей в них для конкретной задачи. В DSL это соотношение гораздо лучше для конкретного класса задач.
G>Так это и есть та мощность языка, которую имеет смысл тут рассматривать.

Это выразительность.

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

WH>>В том, что бизнес задачами занимаются люди, которые дальше языков общего назначения ничего не видят.
T>Других просто нет.
Есть. И остальных переучивать надо.

T>Враньё. Курс вроде компиляторов есть почти во всех серьехзных ИТ-вузах. Из своих наблюдений
Там такой курс, что лучше бы его не было.
Ибо все, что люди из него выносят это то, что компиляторы это что-то сложное.
При этом реальных навыков создания компиляторов они не получают. По тому и говорю, что не учат.

T>1. большинство программистов плохо знает математику
И что?

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

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

S>А, ну так состав операций никак не изменился.
Да я бы не сказал.

S>Вообще, все нужные операции уже давно описаны Коддом.
S>Проблема SQL — только в том, что в нём нет понятия "функция" в широком смысле. И тем более нет понятия "функция высшего порядка".
На самом деле все гораздо хуже.

A relation is a data structure which consists of a heading and an unordered set of tuples which share the same type.

Те отношение не имеет порядка.
В отношении не может быть дублей.
На практике нам нужно нарушать оба условия.
Таким образом, язык работы с БД не может быть построен на отношениях.
Что на практике и происходит. Например, order by или top для отношений просто не имеют смысла.

По всей видимости, наиболее адекватной моделью будут списки кортежей с именованными полями.
Ибо они с одной стороны поддерживают нужные на практике фичи. И с другой стороны для них можно один в один определить аналоги реляционных операций.
Также с ними будут работать все наработки в области реляционных БД просто по тому, что по факту они и работают со списками кортежей, а не с отношениями.

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

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Т.е. `source` как параметр передать нельзя. И тут же ты говоришь, что relation это первоклассная сущность. Какой тогда критерий первоклассности чего-либо, если не (не)возможность передать это нечто аргументом в функцию?
Наличие встроенной поддержки в языке. Критерий передаваемости чего-либо в функцию бессмысленен в отсутствие функций, вы не находите?
Вот у нас есть relation. Вот у нас есть правила композиции relation, из которых получаются другие relation. Первоклассность этой сущности — в том, что мы внутри запроса можем в любом месте, где нужен relation, подставить любой (подходящий) relation.
Вы называете это "подзапросами".

S>>Подзапросы не спасут вас от монолитности запроса — это всего лишь те же шесть страниц, записанные в другом порядке.
ANS> Пожалуй, это проблемы хост-языка, а не самого SQL.
Пожалуй, вы не понимаете, что такое язык. То, о чём я говорю — это проблемы именно SQL. SQL не предусматривает никакого "хост-языка", а способ, которым вы предлагате "решать это в Java" — ужасен. Ровно потому, что Java отвратительно приспособлена для работы с реляционными данными. Там есть функции, зато нет реляций как первоклассных сущностей. Примеры, которые я вам привел на linq, в Java будут выглядеть отвратительно.
Ровно потому, что linq — это SQL с функциями. У него свои (достаточно унылые) ограничения, но в целом он гораздо ближе подошёл к решению реляционного вопроса, чем любая связка из GPPL и SQL.

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

V>>Тебя же не смущает, что в аббревиатуре UML последняя буква означает Language?

_>Хгм, тут речь шла именно о формате данных, в котором редактор сохраняет данные на диск. Т.е. то что сам редактор является своеобразным графическим DSL я с самого начала не сомневался (хотя слово language тут конечно несколько сомнительно, но это мелочи).

Чего сомнительного? ИМХО, это программистская привычка. Изначальный смысл слова "язык" — это вообще медиа. Ну, звук то бишь.
До сих пор вроде есть языки, не имеющие текстового представления.


_>Весь вопрос был в том, задаётся ли этот самый язык неким эфемерным способом через набор контролов, которыми манипулируют.

У графических языков и спецификации графические.


_>Или же мы можем просто формально считать обычным текстовым dsl'ом тот самый формат, в котором нарисованный интерфейс сохраняется на диск?

У всяких CAD-ов обычно много поддерживаемых форматов для файла импорта/экспорта, но семантика графических элементов — постоянна. По крайней мере в рамках одного графического стандарта, если мы о схеме принципиальной, например, т.к. есть традиционо стандарты соц-лагеря, есть европейские и есть американские.


_>Вот тут у меня и Sinclair мнения и разошлись. Но я не думаю что эту мелочь имеет смысл особо долго обсуждать — это скорее просто вопрос терминологии, что считать dsl, а что нет.

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

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

WH>На практике нам нужно нарушать оба условия.
WH>Таким образом, язык работы с БД не может быть построен на отношениях.
WH>Что на практике и происходит. Например, order by или top для отношений просто не имеют смысла.
А, это-то фигня. Это тривиальное расширение понятия relation, и я про него в курсе. Просто в рамках этого топика не хотел переусложнять на ровном месте.

WH>По всей видимости, наиболее адекватной моделью будут списки кортежей с именованными полями.
Не, не списки. Список задаёт ad-hoc порядок, а нам интересен ключ упорядочивания и ещё кое-какие метаданные.

WH>Ибо они с одной стороны поддерживают нужные на практике фичи. И с другой стороны для них можно один в один определить аналоги реляционных операций.
WH>Также с ними будут работать все наработки в области реляционных БД просто по тому, что по факту они и работают со списками кортежей, а не с отношениями.
Совершенно верно.

WH>А раз у нас все на списках то можно использовать все наработки функциональных языков.
WH>Также можно использовать Liquid Types для того чтобы задавать спискам дополнительные ограничения. Например, что список содержит только уникальные элементы. Причем можно указать какие поля дают уникальность. Тогда при проекции, которая включает все эти поля, мы не потеряем информацию о том, что элементы в списке уникальны.
И при отборе тоже не потеряем, т.к. подсписок уникального списка — уникальный список.

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

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

_>Не знал что Дельфи такая модная в этом смысле. ) Мы то её никогда не использовали по своми причинам и видимо никогда не будем. Но возможно что часть идей оттуда хорошо бы стащить. )))
Естественно, ведь её популярность не на пустом месте была (кроме политических причин: распространённость Паскаля в учебных заведениях и развитость пиратства). И сейчас её уже столько лет все хоронят и хоронят, а она всё живёт себе и живёт (хотя, далеко не все хоронят).

PSV>>Здесь рядом в своём сообщении WolfHound говорит о реактивном программировании на основе model-view. Вполне здравая идея, проверенная у нас. Удобно, когда подправил скрипт и сразу видишь результат неотходя от кассы, часто не нужны отладчики или debug-сообщения.

_>Интересно, есть ли рабочий пример такого подхода? В смысле не какая-то конкретная реализация типа вашей, а как универсальный фреймворк.
Ну, не знаю, чтобы прям универсальный, всех удовлетворил, да чтобы и под С++ (как я понимаю, он прежде всего интересен). Можно в Qt глянуть, что там в последних версиях наворотили с их фактически JavaScript-програмлянием и CSS, может там есть какая-то реактивность, я не в курсе. А так, если кругом оглянуться, то можно найти немало всякой реактивности. Те же action-ы в Delphi, у них есть свойства Caption, Hint, ShortCut и пр., когда их изменяешь, то связанные элементы тоже себя обновляют. При этом одну и ту же action можно привязать нескольким элементам, например, пункту меню и кнопке на тулбаре, все себя сами корректируют. Также, например, action можно привязать к набору данных и указать, чтобы она следила за его состоянием, и когда, скажем, он пустой, то нужно себя запрещать, т.е. установить Enabled = false. В результате, например, если на экране пустая таблица, то кнопка "удалить" автоматом не работает (становится запрещенной). Всё настраивается в дизайнере или программируется.

Или вот попался пример на WPF (я в нём не разбираюсь). Здесь TextBox будет виден только тогда, когда включён CheckBox (насколько приятно в таком XML ковыряться, я не в курсе, лично мне не очень):

<Window x:Class="ParaPlan.Windows.Window1"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    Title="Window1" Height="300" Width="300"
    xmlns:converters="clr-namespace:ParaPlan.Converters">
    <StackPanel Orientation="Vertical">
        <StackPanel.Resources>
            <converters:BooleanToHiddenVisibility x:Key="boolToVis"/>
        </StackPanel.Resources>
        <CheckBox Content="Check to show text box below me" Name="checkViewTextBox"/>
        <TextBox Text="only seen when above checkbox is checked"
                 Visibility="{Binding Path=IsChecked, ElementName=checkViewTextBox, Converter={StaticResource boolToVis}}"/>
    </StackPanel>
</Window>

Вот примерчик на JavaFX, когда он ещё скриптом был (вроде и сейчас есть, но сторонним проектом):

package com.dieajax.sample.TrafficLight;
 
import javafx.scene.Scene;
import javafx.scene.text.Text;
import javafx.stage.Stage;
import javafx.scene.shape.Circle;
import javafx.scene.paint.Color;
import javafx.ext.swing.SwingComboBox;
import javafx.ext.swing.SwingComboBoxItem;
import javafx.scene.layout.VBox;
 
def trafficColors : Color[] = [Color.RED, Color.YELLOW, Color.GREEN];
def trafficColorNames : String[] = ["Red", "Yellow", "Green"];
def trafficColorActions : String[] = ["Stop", "Slow", "Go"];
 
class Model {
    var action: String;
    var selectedColorIndex: Integer on replace oldValue {
        action = trafficColorActions[selectedColorIndex];
    }
}
 
var trafficLightComboBox = SwingComboBox {
    translateX: 113
    width: 75
    selectedIndex: 2
    items: for (colorName in trafficColorNames)
        SwingComboBoxItem {
            text: colorName
        }        
    }
 
var model = Model {
    selectedColorIndex: bind trafficLightComboBox.selectedIndex;
};
 
var trafficLight = Circle {
            centerX: 150
            centerY: 20
            radius: 20
            fill: bind trafficColors[model.selectedColorIndex]
        }
 
var trafficLightText = Text {
                x: 135
                y: 10
                content: bind model.action
            }
 
Stage {
    title: "Die, Ajax! - Traffic Light Sample"
    width: 300
    height: 250
    scene: Scene {
        content: [
                VBox {
                    spacing: 20
                    content: [trafficLight, trafficLightText, trafficLightComboBox]
                }
        ]
    }
}

Здесь и модель можно увидеть, и биндинг (искать слово bind) и триггер на изменение переменной (выражение "on replace" — это лямбда, где доступно старое значение переменной).

А я также под реактивной разработкой подразумеваю и реальную скорострельность в создании чего-то. Та же упомянутая Кложура позволяет, благодаря языку и платформе, реализовать некое динамическое приложение. Лисперы часто предпочитают эмакс, который для лисп-кода даёт больше удобств, чем любая IDE для С++-кода. Открыл буфер в эмаксе со скриптом из проекта, реализовал новую функцию, рядом в соседнем буфере набросал тестик, тут же его выполнил, проверил функцию, всё ОК, дал команду и где-то рядом запущенный процесс приложения тут же подхватил твои изменения и ты сразу видишь результат. Всё нормально, возвращается в эмакс в буфер с программой и начинаешь ваять следующую функцию. Можешь без тестирования и т.п. сразу любоваться своим творением. Всякий REPL тут же тебе в помощь и т.д.

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

_>Ну вообще то например древние rc файлы тоже действовали по такому принципу. Т.е. там были только id, к которым потом обращался код. Правда не было разделения на структуру (html) и стили (css), но это уже мелочи. И я бы не сказал что из этого вышел очень удачный инструмент. Хотя для своего времени...

Я в соседнем сообщении

Автор: PSV100
Дата: 12.04.12

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

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

WH>>>1)В институте плохому учат. У них там все действительно сложнее, чем надо получается.
WH>>>2)Сложность рукопашного кода всё равно больше. Чем сложность компилятора.
T>>Не нужно передергивать.
WH>В каком месте?

В процитированом.

T>>"Сложность рукопашного кода всё равно больше" — для каких задач ?
WH>Для всех чей домен не является подмножеством используемого языка.
WH>Те для чуть менее чем всех.

Ну тогда навскидку"
Как быть с теми, чей домен не сильно определен ?
Как быть с теми, которые плохо формализованы ?
Как быть с теми которые затрагивают сразу несколько доменов ?

T>>Всегда ли нужно писать полноценное решение ?
WH>А какое еще?

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

T>>На примере CSV-парсера. В разных проектах, в которые пришлось сунуть нос, видел уже наверное под сотню парсеров, от простых вроде string.split до всяких регулярных выражений и тд. Работают все по разному, с разной степенью надежности, производительности и тд.
WH>CSV? string.split'ом? Оригинально.

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

T>>1 Покажи на примере этой простой задачи преимущества DSL.
WH>Так это зависит от того что ты делаешь.
WH>Скажи, зачем ты парсишь CSV?

Импортирую данные которые кастомеры по отрасли хранят в CSV.

T>>2 Всегда ли нужно писать полноценный парсер вроде CSV ?
WH>А как иначе? Если нам нужно разобрать CSV то нам нужно писать его парсер.

Я видел проекты где решения вроде string.split работали десятками лет. Для чего там полноценный парсер ? Я вот не смог объяснить, потому там и по сей день string.split.

T>>3 Объясни, кем заменить тех, кто не в состоянии написать чтото большее string.split ?
WH>Этих по-хорошему нужно гнать из профессии.

Ни один бизнес не пойдет на такое решение.

WH>Но если приспичило можно их посадить писать код на ДСЛ, который не дает делать плохие вещи.

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

T>>DSL, хочешь ты или нет, это очень сложная тема.
WH>Только для тех, кто ничего кроме книги дракона не видел.

А большинство про неё даже не знают.

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

WH>>>В том, что бизнес задачами занимаются люди, которые дальше языков общего назначения ничего не видят.
T>>Других просто нет.
WH>Есть. И остальных переучивать надо.

Я боюсь что это утопия.

T>>Враньё. Курс вроде компиляторов есть почти во всех серьехзных ИТ-вузах. Из своих наблюдений
WH>Там такой курс, что лучше бы его не было.
WH>Ибо все, что люди из него выносят это то, что компиляторы это что-то сложное.
WH>При этом реальных навыков создания компиляторов они не получают. По тому и говорю, что не учат.

Это и показывает, что материал сложный. Когда материал простой, все студенты его на раз умеют.

T>>2. компиляторы хорошо идут только у тех кто хорошо знает математику
WH>Для того чтобы писать компиляторы матан знать не нужно. Вернее хватит весьма поверхностных знаний.

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

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

T>>Это передергивание. Пока ты дошел до этого, ты сотни раз писал вские парсеры, грамматики и тд и тд и тд. То есть, ты уже написал под сотню другую вариантов и твой коротенький код есть результат всех этих попыток.

O> Достаточно один раз написать, чтобы понять. Не велика проблема. Это как "hello, world".

Я чет сомневаюсь что ты в любой задаче сможешь выдать качественное решение для общего случая решив её только единожды
Пример — почему ты не предложил html+css примерно 40 лет назад ?

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

VE>>А как бы стоило сделать на твой взгляд?
WH>Никак. Языки общего назначения не имеют смысла.
WH>Чем больше изучаю, тем сильнее утверждаюсь в этом мнении.



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

В кратце, люди создают инструментарий для себя
1 орудийный == синтаксис
2 понятийный == семантика

Людие которые в разумные сроки могут п.2 + п.1 настолько мало, что их можно пересчитать по пальцам.

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

S>А, это-то фигня. Это тривиальное расширение понятия relation, и я про него в курсе. Просто в рамках этого топика не хотел переусложнять на ровном месте.
Тривиальность это вопрос десятый.
Но нужно про это помнить.

S>Не, не списки. Список задаёт ad-hoc порядок, а нам интересен ключ упорядочивания и ещё кое-какие метаданные.
Одно другому не мешает.
А ключ сортировки можно на это навесить при помощи тех же жидких типов.

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

S>Осталось приделать к этому приемлемый синтаксис, и золотой ключик у нас в кармане.
Не только еще и нормальную систему типов было бы неплохо прикрутить.
Как минимум хочется алгебраических типов и вместо null использовать Option.

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

T>Это и показывает, что материал сложный. Когда материал простой, все студенты его на раз умеют.
Нет. Это показывает, что студентов учат не правильному материалу.

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

WH>>Для всех чей домен не является подмножеством используемого языка.
WH>>Те для чуть менее чем всех.
T>Как быть с теми, чей домен не сильно определен ?
Определить. Твой КО.

T>Как быть с теми, которые плохо формализованы ?
Формализовать. Можно итерациями. Это работает не хуже чем с библиотеками.

T>Как быть с теми которые затрагивают сразу несколько доменов ?
Чего? У задачи один домен.
Большие задачи всегда можно разбить на маленькие, для которых легко определить домен.

T>Импортирую данные которые кастомеры по отрасли хранят в CSV.
Ничего не сказал.
Куда ты их ипортируешь?
Зачем ты их импортируешь?
Не проще ли сказать базе данных, чтобы она их сама импортировала? Они умеют.

T>Я видел проекты где решения вроде string.split работали десятками лет. Для чего там полноценный парсер ? Я вот не смог объяснить, потому там и по сей день string.split.
То что ошибка не проявлялась или ее проявления не были замечены не значит что ошибки не было.
И сам такой баг нашол. Код с ошибкой отрабатывал десятки миллионов раз в день в течение нескольких лет.
Но ошибка не проявлялась.
Когда я засунул туда немного не обычные данные, но полностью корректные данные все упало.

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

T>Не совсем ясно, как быть с приложением, где встретится сразу пачка разных областей. Где набрать дсл на все случаи жизни ?
Написать. Это просто.

T>А большинство про неё даже не знают.
Нужно учиться. Или ты думаешь, куда ты попал?
Программист это инженер, а не дворник. Он просто обязан быть хорошо подготовлен.

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

O>> Достаточно один раз написать, чтобы понять. Не велика проблема. Это как "hello, world".

T>Я чет сомневаюсь что ты в любой задаче сможешь выдать качественное решение для общего случая решив её только единожды

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

T>Пример — почему ты не предложил html+css примерно 40 лет назад ?

40 лет назад от этого html-а никакой пользы не было бы, а css отображать было не на чем.

А вот когда html таки появился, я сразу говорил что это чушь, и что все делают заведомо неправильно. Недоумевал, почему вылезло это SGML-отродье и почему забыли про DPS и другие умные технологии. Да что там — latex тот же уже на всю катушку был популярен (и Тим Барнс-Ли его прекрасно знал, как и про DPS). Но все равно родилась фигня, а до хотя бы отдаленно приличного состояния вся эта шелуха не дошла и по сей день.