Не понимаю восторгов по поводу canvas и игровых движков на «чистом HTML5».
Ребята повторяют только то, что было сделано давным-давно (подчеркну: не делают ничего нового), а результат жутко неэффективен в плане использования вычислительных ресурсов.
Извините, как-то однобоко. Вы рассмотрели грамматики и разбор, и совершенно упустили (а) проверку типов (какие синтаксические конструкции разрешены, а какие — нет), (б) семантику (описание выполнения). В настоящих языках программирования это гораздо важнее, причем именно с точки зрения их использования.
Сами разработчики считают, что OCaml им очень сильно помог в плане разработки, сопровождения, и найма толковых программистов: www.cl.cam.ac.uk/~avsm2/icfp2010-xen-draft.pdf
Очень, очень похоже на статью Дейкстры. Впрочем, вижу, что об этом Вы уже написали. :)
Даже если не программировать на Си++, и не заниматься 64-х битными программами, все равно программирование — это сложно, и дело тут и в людях, и в инструментах.
Мне кажется, что мы просто еще не доросли до серьезных вещей, а то, что есть сейчас, представляется этаким «каменным веком», иными словами, программированию до серьезной дисциплины еще пилить и пилить.
Какие-то проблемы реализации абстрактного синтаксиса на Си++. :)
Забавно, у меня диплом по этой теме (typeful abstract syntax, разбор, проверка типов, интерпретатор), но там, конечно, все по-другому, и на экспериментальном ЯП.
Ребят, я конечно все понимаю, опыт и так далее, однако есть одно «но».
Никто из тех, кто заявил, что статья «бред», не привёл ни одного аргумента в пользу своего весомого мнения. Да что там, никто даже и не прокомментировал пойнты из статьи.
Хватит устраивать детский сад на Хабре.
И по поводу статьи: с основными пойнтами согласен, однако (а) все это можно преодолеть (что и демонстрирует мильён GUI-фреймворков на Си++), (б) этот мильён фреймворков «достаточно хорош» для своих задач.
Если я все правильно понял, Вам нужно следующее: чтобы будильник мог выполнять различные действия, когда «будит»?
Тогда зачем это все нужно, если можно просто параметризовать абстрактный тип данных «будильник» функцией «будить»?
Будильник представим таким абстрактным типом данных (в ML-like записи):
mk_alarmclock: (wakeup: time -> unit) -> alclock
start: alclock -> unit
stop: alclock -> unit
Вот и все. Чтобы сконструировать будильник (alclock), нужно передать ему функцию wakeup, которая принимает «время» и возвращает unit. И еще доступны две функции, start и stop.
В Си++ Вы скорее всего захотите использовать функтор вместо функции, чтобы хранить все, что Вам нужно. К сожалению, я не полностью понял проблему, которую Вы пытаетесь решить.
> Я начал изучать вопрос ее происхождения и довольно быстро наткнулся на тот факт, что ее вообще никто не изобретал, а родилась и получила широкое распространение эта модель лишь благодаря серии досадных недоразумений.
Концентрация на нуждах пользователя это замечательно. :)
А как разрабатывается общая «архитектура» (структура) разрабатываемого приложения?
> Насчет коммуникации — в основном прямое общение, иногда доска с фламастерами. Не приветствуется удаленная работа без особых причин.
Угу, просто вот я замечаю, что довольно трудно передать понимание даже через прямое общение… (ибо бэкграунд у всех разный) Мы с напарником создаем математические модели, например (работает хорошо, обычно исключает многозначность трактовки).
(и все, теперь мы определили сигнатуру для функции create: три аргумента, строка, число и булева переменная, возвращает пользовательский «тип» account).
Да, пример именно с with_open_file немного отвлекает от темы (уж там замыкание можно и выделить на куче :) — хотя, может быть, в embedded или каких-то особых ситуациях такое делать не рекомендуется).
На самом деле, хотелось показать то, чего нет в D:
— возможность записывать сложные пред- и постусловия прямо в коде (и давать компилятору проверить их выполнение до запуска программы)
— возможность сочетать эффективность и безопасность (для сравнения, RAII — это безопасность и выразительность)
В D типы обычно не используются для улучшения безопасности (по-моему, там основной фокус в увеличении выразительности и абстрагирования от некоторых деталей, что тоже дает безопасность: например, можно сравнить ссылки и указатели). В ATS же можно указать некоторые аннотации для стандартных функций POSIX и облегчить их безопасное использование (если эти функции удовлетворяют тем предпосылкам, которые даны в их типе, то все будет хорошо).
> Делегат, как я понимаю — просто указатель на кусок кода, вроде указателя на функцию в Си (+ указатель на кусок памяти с переменными для closure), т.е. 2 числа, так что не сказал бы, что он несет какие-то особые накладные расходы.
Угу, замыкание это указатель на функцию + указатель на окружение (которое, по сути просто struct какой-то).
Выделение всего этого дела в куче — вот накладные расходы (хотя во многих случаях этим можно пренебречь).
Вот тут описано, как в ATS память под замыкание можно выделить на стеке вызывающей функции:
Правда, мне непонятно, зачем нужен трюк с fixIO: не могу найти вхождений [s] в [\s -> ...]. Что я не замечаю?
Ребята повторяют только то, что было сделано давным-давно (подчеркну: не делают ничего нового), а результат жутко неэффективен в плане использования вычислительных ресурсов.
Зачем это нужно с практической точки зрения?
pastebin.com/Zxew5kh4
(не на питоне, естественно). По ссылке — формально верифицированный факториал (три версии) на ATS, с небольшим объяснением, что и как.
Давайте что-нибудь более практичное рассмотрим?
Даже если не программировать на Си++, и не заниматься 64-х битными программами, все равно программирование — это сложно, и дело тут и в людях, и в инструментах.
Мне кажется, что мы просто еще не доросли до серьезных вещей, а то, что есть сейчас, представляется этаким «каменным веком», иными словами, программированию до серьезной дисциплины еще пилить и пилить.
Забавно, у меня диплом по этой теме (typeful abstract syntax, разбор, проверка типов, интерпретатор), но там, конечно, все по-другому, и на экспериментальном ЯП.
Никто из тех, кто заявил, что статья «бред», не привёл ни одного аргумента в пользу своего весомого мнения. Да что там, никто даже и не прокомментировал пойнты из статьи.
Хватит устраивать детский сад на Хабре.
И по поводу статьи: с основными пойнтами согласен, однако (а) все это можно преодолеть (что и демонстрирует мильён GUI-фреймворков на Си++), (б) этот мильён фреймворков «достаточно хорош» для своих задач.
Тогда зачем это все нужно, если можно просто параметризовать абстрактный тип данных «будильник» функцией «будить»?
Будильник представим таким абстрактным типом данных (в ML-like записи):
mk_alarmclock: (wakeup: time -> unit) -> alclock
start: alclock -> unit
stop: alclock -> unit
Вот и все. Чтобы сконструировать будильник (alclock), нужно передать ему функцию wakeup, которая принимает «время» и возвращает unit. И еще доступны две функции, start и stop.
В Си++ Вы скорее всего захотите использовать функтор вместо функции, чтобы хранить все, что Вам нужно. К сожалению, я не полностью понял проблему, которую Вы пытаетесь решить.
> Уалкера Ройса, Крэга Лармана,
А как по-английски? И еще, раз уж Вы в этом разбираетесь, может, посоветуете обзорную книгу по методологиям разработки?
А где же факты?
Концентрация на нуждах пользователя это замечательно. :)
А как разрабатывается общая «архитектура» (структура) разрабатываемого приложения?
> Насчет коммуникации — в основном прямое общение, иногда доска с фламастерами. Не приветствуется удаленная работа без особых причин.
Угу, просто вот я замечаю, что довольно трудно передать понимание даже через прямое общение… (ибо бэкграунд у всех разный) Мы с напарником создаем математические модели, например (работает хорошо, обычно исключает многозначность трактовки).
Как делаете Вы?
> Чрезвычайно полезный для реальной практики материал
> реальной практики
Это как? Нереальная практика тоже существует?
Например,
> (provide/contract
> [create (string? number? boolean?. ->. account?)])
(и все, теперь мы определили сигнатуру для функции create: три аргумента, строка, число и булева переменная, возвращает пользовательский «тип» account).
Еще тут: docs.plt-scheme.org/guide/contracts.html
Жаль, что в D весьма куцые возможности по проверке программ во время компиляции. :(
На самом деле, хотелось показать то, чего нет в D:
— возможность записывать сложные пред- и постусловия прямо в коде (и давать компилятору проверить их выполнение до запуска программы)
— возможность сочетать эффективность и безопасность (для сравнения, RAII — это безопасность и выразительность)
В D типы обычно не используются для улучшения безопасности (по-моему, там основной фокус в увеличении выразительности и абстрагирования от некоторых деталей, что тоже дает безопасность: например, можно сравнить ссылки и указатели). В ATS же можно указать некоторые аннотации для стандартных функций POSIX и облегчить их безопасное использование (если эти функции удовлетворяют тем предпосылкам, которые даны в их типе, то все будет хорошо).
Угу, замыкание это указатель на функцию + указатель на окружение (которое, по сути просто struct какой-то).
Выделение всего этого дела в куче — вот накладные расходы (хотя во многих случаях этим можно пренебречь).
Вот тут описано, как в ATS память под замыкание можно выделить на стеке вызывающей функции:
www.ats-lang.org/TUTORIAL/contents/stack-allocation.html