Часто пишут о грядущей смерти C/С++ и о том что Java + .NET будущее программирования на долгие годы вперед.
Я считаю, что Java и .NET просто шаг вперед к языкам и платформам которые дадут возможности управления всеми доступными ресурсами сразу на разных уровнях. От регистров процессоров до бизнес логики. Язык будущего должен давать возможность определять классы и создавать их экземпляры так, что бы можно было определять уровни доступа к ресурсам на разных уровнях.
Например: class TRenderDevice: level {hardware}
{
.... //Тут функции с указателями, с кусками на асме и прочими произведениями суровых бородатых разработчиков
}
class TCreditCardsReader level {high_secure}
{
.... //Тут высокоуровневые конструкции, выполняемые в управляемом окружении, написанные Java/.NET гуру
}
Спор о management/unmanagement сегодня лишен практического смысла. Интересно будет решение которое даст эффективное слияние этих подходов.
А как вы видите развитие средств разработки программ?
Вопрос скорее из области прикладной науки, чем программирования. Как должна выглядеть сама модель построения конструкций такого языка?
Здравствуйте, TimurSPB, Вы писали:
TSP>Часто пишут о грядущей смерти C/С++ и о том что Java + .NET будущее программирования на долгие годы вперед. TSP>Я считаю, что Java и .NET просто шаг вперед к языкам и платформам которые дадут возможности управления всеми доступными ресурсами сразу на разных уровнях. От регистров процессоров до бизнес логики. Язык будущего должен давать возможность определять классы и создавать их экземпляры так, что бы можно было определять уровни доступа к ресурсам на разных уровнях.
TSP>Например: TSP>class TRenderDevice: TSP>level {hardware} TSP>{ TSP>.... //Тут функции с указателями, с кусками на асме и прочими произведениями суровых бородатых разработчиков TSP>}
TSP>class TCreditCardsReader TSP>level {high_secure} TSP>{ TSP>.... //Тут высокоуровневые конструкции, выполняемые в управляемом окружении, написанные Java/.NET гуру TSP>}
TSP>Спор о management/unmanagement сегодня лишен практического смысла. Интересно будет решение которое даст эффективное слияние этих подходов. TSP>А как вы видите развитие средств разработки программ? TSP>Вопрос скорее из области прикладной науки, чем программирования. Как должна выглядеть сама модель построения конструкций такого языка?
I think that The Language Of The Future (TLOTF) will Facilitate Workflow Integration for E-Business. It will, Basically, Grow an Exposure of Call To Action through all Phases of и тут я устал.
Если серьёзно, то иди читай про зависимые типы.
То, что ты выдал на поверхность, лишь показывает, что ни с чем ты толком не работал. Ни про железо не знаешь, ни про драйвера, ни про разработку от железа и вверх.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, TimurSPB, Вы писали:
TSP>А как вы видите развитие средств разработки программ?
От текста к визуальным образам с произвольным профилированием визуализации в зависимости от текущих задач. Но, правда, мощности даже современных компьютеров на это слегка не очень хватает. Визуализируй-ка мне boost в реалтайме... В процессе разработки.
В прочем, это породит новый язык. Текстовый. Для описания предпочтений.
TSP>Вопрос скорее из области прикладной науки, чем программирования. Как должна выглядеть сама модель построения конструкций такого языка?
Задача 0: наследование имеющегося ПО. До хрена процентов которого написана на C, C++, Shell language, Perl, Visual Basic, SQL. Пока что об эту задачу обламывают зубы все без исключения.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, TimurSPB, Вы писали:
TSP> возможности управления всеми доступными ресурсами сразу на разных уровнях. От регистров процессоров до бизнес логики.
Какую проблему/проблемы это решает?
TSP> Язык будущего должен давать возможность определять классы и создавать их экземпляры так, что бы можно было определять уровни доступа к ресурсам на разных уровнях.
Тот же вопрос.
TSP>Спор о management/unmanagement
managed/unmanaged
TSP> сегодня лишен практического смысла.
Почему?
TSP> Интересно будет решение которое даст эффективное слияние этих подходов.
Слияние в каком плане? Интеграция кусков кодя разных типов и сейчас возможна, чуть хуже в джаве, чуть лучше в дотнете.
TSP>А как вы видите развитие средств разработки программ?
Каких конкретно средств?
TSP> Как должна выглядеть сама модель построения конструкций такого языка?
Что такое "модель построения конструкций такого языка"?
... << RSDN@Home 1.2.0 alpha 4 rev. 1249 on Windows 7 6.1.7600.0>>
ГВ>Задача 0: наследование имеющегося ПО. До хрена процентов которого написана на C, C++, Shell language, Perl, Visual Basic, SQL. Пока что об эту задачу обламывают зубы все без исключения.
Вообще-то любопытный момент. В 1980 году я бы сказал то же самое про Фортран.
Мне лет десять назад понадобилась хорошая библиотека по теории вероятности. Искал долго, попадалось большое количество всякого и разного, все на Фортране. Наконец нашел на С, вполне приличная библиотека, как оказалось, в исходниках. Чтение этих исходников сразу показало , откуда уши растут — это был фортрановский код, переведенный на С почти 1:1, в том числе с GOTO. Впрочем, это и не скрывалось — в readme было сказано, что работа по переводу была выполнена по какому-то гранту.
Здравствуйте, TimurSPB, Вы писали:
TSP>Спор о management/unmanagement сегодня лишен практического смысла. Интересно будет решение которое даст эффективное слияние этих подходов. TSP>А как вы видите развитие средств разработки программ? TSP>Вопрос скорее из области прикладной науки, чем программирования. Как должна выглядеть сама модель построения конструкций такого языка?
Надоело проектировать снизу вверх. Сейчас, чтобы написать более-менее крупную программу, нужно писать тонны "мелкого" кода, сразу погружаться в реализацию кучи всевозможных деталей... Бывает, еще даже толком не представляешь, что именно должно получиться, а уже приходится писать код реализации
Я хочу язык, позволяющий проектировать сверху вниз. Т.е. я создаю какую-то конструкцию, называю ее "программа", затем детализирую ее — создаю подконструкции, например, "интерфейс", "бизнес-логика", затем детализирую их и т.д., и только через несколько уровней дохожу до классов и функций. По сути, это что-то вроде расширенных UML-конструкций, включенных в синтаксис языка. Чтобы эти высокоуровневые конструкции задавали какие-то ограничения на код (вроде в VS2010 сделали какую-то фичу, с помощью которой можно ограничивать связность разных частей программы... хочу нечто подобное, но на уровне языка и с бОльшим количеством возможностей)
На любом этапе разработки программа должна как минимум компилироваться с диагностикой ошибок уровня проектирования.
Средства разработки... хочу IDE, по функционалу превосходящее Visual Studio 2010, а по скорости работы — превосходящее Visual Studio 6.0.
Хочу, чтобы IDE были рассчитаны не только для написания нового кода, но и для исследования существующего. В среду разработки, да и в язык, должен быть встроен по сути "аутлайнер" с возможностью организовывать деревья, с навигацией по тегам и т.п. фичами. Чтобы можно было без проблем одному человеку разбираться в сверхбольших проектах, написаных множеством людей.
Здравствуйте, x-code, Вы писали:
XC>Надоело проектировать снизу вверх.
Проектируй сверху вниз.
XC> Сейчас, чтобы написать более-менее крупную программу, нужно писать тонны "мелкого" кода
От этого тебя никакой язык не спасет. Если мы, конечно, об универсальных языках.
XC>, сразу погружаться в реализацию кучи всевозможных деталей...
А сразу и не надо. Банальный ООП без всяких изысков спокойно это позволяет.
XC> Бывает, еще даже толком не представляешь, что именно должно получиться
Бывает.
XC>, а уже приходится писать код реализации
Совсем не обязательно.
XC>Я хочу язык, позволяющий проектировать сверху вниз.
Современные языки обычно это позволяют
XC> Т.е. я создаю какую-то конструкцию, называю ее "программа"
class Program {}
XC>, затем детализирую ее — создаю подконструкции, например, "интерфейс", "бизнес-логика"
class UI {}
class BizLogic {}
XC>, затем детализирую их и т.д.,
Ну да
XC> и только через несколько уровней дохожу до классов и функций.
А что изменится, если вместо ключевого слова class будет написано entity, а вместо метода слово operation?
XC> По сути, это что-то вроде расширенных UML-конструкций
UML тоже штука весьма низкоуровневая, несмотря на свои притензии.
XC> Чтобы эти высокоуровневые конструкции задавали какие-то ограничения на код (вроде в VS2010 сделали какую-то фичу, с помощью которой можно ограничивать связность разных частей программы... хочу нечто подобное, но на уровне языка и с бОльшим количеством возможностей)
Code contracts имеют весьма опосредованное отношение к проектированию. Это средство контроля корректности реализации. Пока у тебя нет того самого мелкого кода, контракты не нужны.
XC>На любом этапе разработки программа должна как минимум компилироваться с диагностикой ошибок уровня проектирования.
Что такое "ошибки уровня проектирования"? Пример можно?
XC>Средства разработки... хочу IDE, по функционалу превосходящее Visual Studio 2010, а по скорости работы — превосходящее Visual Studio 6.0.
Хочу быть здоровым и богатым
XC>Хочу, чтобы IDE были рассчитаны не только для написания нового кода, но и для исследования существующего.
Большинство современных больших IDE уже.
XC> В среду разработки, да и в язык, должен быть встроен по сути "аутлайнер" с возможностью организовывать деревья, с навигацией по тегам и т.п. фичами. Чтобы можно было без проблем одному человеку разбираться в сверхбольших проектах, написаных множеством людей.
Чорт в деталях, т.е. в том, что это за фичи. Да, для VS2010 кое что уже есть из твоего списка, многое умеет решарпер.
... << RSDN@Home 1.2.0 alpha 4 rev. 1249 on Windows 7 6.1.7600.0>>
Здравствуйте, x-code, Вы писали:
XC>Я хочу язык, позволяющий проектировать сверху вниз. Т.е. я создаю какую-то конструкцию, называю ее "программа", затем детализирую ее — создаю подконструкции, например, "интерфейс", "бизнес-логика", затем детализирую их и т.д., и только через несколько уровней дохожу до классов и функций.
http://fprog.ru/2009/issue1/dmitry-astapov-checkers/
XC>Средства разработки... хочу IDE, по функционалу превосходящее Visual Studio 2010, а по скорости работы — превосходящее Visual Studio 6.0. XC>Хочу, чтобы IDE были рассчитаны не только для написания нового кода, но и для исследования существующего. В среду разработки, да и в язык, должен быть встроен по сути "аутлайнер" с возможностью организовывать деревья, с навигацией по тегам и т.п. фичами. Чтобы можно было без проблем одному человеку разбираться в сверхбольших проектах, написаных множеством людей.
Среда разработки и язык — разные вещи.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
XC>> Чтобы эти высокоуровневые конструкции задавали какие-то ограничения на код (вроде в VS2010 сделали какую-то фичу, с помощью которой можно ограничивать связность разных частей программы... хочу нечто подобное, но на уровне языка и с бОльшим количеством возможностей)
AVK>Code contracts имеют весьма опосредованное отношение к проектированию. Это средство контроля корректности реализации. Пока у тебя нет того самого мелкого кода, контракты не нужны.
Не исключено, что x-code имеет ввиду MEF. Но это тоже далеко не панацея от всех бед
XC>> В среду разработки, да и в язык, должен быть встроен по сути "аутлайнер" с возможностью организовывать деревья, с навигацией по тегам и т.п. фичами. Чтобы можно было без проблем одному человеку разбираться в сверхбольших проектах, написаных множеством людей.
AVK>Чорт в деталях, т.е. в том, что это за фичи. Да, для VS2010 кое что уже есть из твоего списка, многое умеет решарпер.
Можно ещё на DSL посмотреть, недавнего Фаулера покурить. IntentSoft IP, JetBrains MPS, Oslo, M. Дело к тому идёт, просто пока ещё не научились это толково делать.
Здравствуйте, x-code, Вы писали:
XC>Я хочу язык, позволяющий проектировать сверху вниз.
См. язык Дракон на оберонском форуме http://forum.oberoncore.ru/index.php XC>Хочу, чтобы IDE были рассчитаны не только для написания нового кода, но и для исследования существующего. В среду разработки, да и в язык, должен быть встроен по сути "аутлайнер" с возможностью организовывать деревья, с навигацией по тегам и т.п. фичами. Чтобы можно было без проблем одному человеку разбираться в сверхбольших проектах, написаных множеством людей.
Среды такой пока нет. Ибо существующие промышленные ПРОФЕССИОНАЛЬНЫЕ среды заточены под текстовый редактор (от уж маразм, так маразм!). Когда будут заточны под семантические модели — тогда будет тебе счастье!
А то и сам попробуй написать...
Кстати, Дракон — это самое оно — семантические модели...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, TimurSPB, Вы писали:
TSP>Часто пишут о грядущей смерти C/С++ и о том что Java + .NET будущее программирования на долгие годы вперед. TSP>Я считаю, что Java и .NET просто шаг вперед к языкам и платформам которые дадут возможности управления всеми доступными ресурсами сразу на разных уровнях. От регистров процессоров до бизнес логики. Язык будущего должен давать возможность определять классы и создавать их экземпляры так, что бы можно было определять уровни доступа к ресурсам на разных уровнях.
TSP>Например: TSP>class TRenderDevice: TSP>level {hardware} TSP>{ TSP>.... //Тут функции с указателями, с кусками на асме и прочими произведениями суровых бородатых разработчиков TSP>}
TSP>class TCreditCardsReader TSP>level {high_secure} TSP>{ TSP>.... //Тут высокоуровневые конструкции, выполняемые в управляемом окружении, написанные Java/.NET гуру TSP>}
TSP>Спор о management/unmanagement сегодня лишен практического смысла. Интересно будет решение которое даст эффективное слияние этих подходов. TSP>А как вы видите развитие средств разработки программ? TSP>Вопрос скорее из области прикладной науки, чем программирования. Как должна выглядеть сама модель построения конструкций такого языка?
От регистров процессора до бизнес-логики? Это ещё пол дела. Желательно чтоб это было удобно.
Здравствуйте, x-code, Вы писали:
XC>Средства разработки... хочу IDE, по функционалу превосходящее Visual Studio 2010, а по скорости работы — превосходящее Visual Studio 6.0.
Эх... Чует мое сердце, что скорости работы Visual Studio 6.0 уже никогда не будет
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, x-code, Вы писали:
XC>>Средства разработки... хочу IDE, по функционалу превосходящее Visual Studio 2010, а по скорости работы — превосходящее Visual Studio 6.0.
PD>Эх... Чует мое сердце, что скорости работы Visual Studio 6.0 уже никогда не будет
Не... Блэк-бокс вполне себе шустро работает...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Надо сказать, что такой язык программирования, каким ему следовало бы быть, никогда не будет использоваться, даже если кто-нибудь сподобился бы его придумать. Естественные языки тоже несовершенны. Однако на эспиранто что-то нет желающих общаться. Люди привыкли мелочно ковыряться с КПД в 10% в своей песочнице. И их оттуда вытащить необычайно тяжело.
Здравствуйте, TimurSPB, Вы писали:
TSP>Как должна выглядеть сама модель построения конструкций такого языка?
В естественном языке десятки тысяч слов (не считая научных терминов). Но общаться на нём можно, имея словарный запас в несколько десятков слов. Язык программирования должен быть таким же. При этом он должен охватывать все области программирования, позволять описывать DSL'и (domain-specific language). Он должен быть отделён от каких-то обязательных библиотек. Также, он должен обеспечивать полный контроль над получаемым исполняемым кодом.
Здравствуйте, любой, Вы писали:
Л>В естественном языке десятки тысяч слов (не считая научных терминов). Но общаться на нём можно, имея словарный запас в несколько десятков слов. Язык программирования должен быть таким же.
Почему?
Здравствуйте, любой, Вы писали: Л>В естественном языке десятки тысяч слов (не считая научных терминов). Но общаться на нём можно, имея словарный запас в несколько десятков слов.
Словарь Вильяма Шекспира, по подсчету исследователей, составляет 12000 слов. Словарь негра из людоедского племени «Мумбо-Юмбо» составляет 300 слов. Эллочка Щукина легко и свободно обходилась тридцатью. Вот слова, фразы и междометия, придирчиво выбранные ею из всего великого, многословного и могучего русского языка:
1. Хамите.
2. Хо-хо! (Выражает, в зависимости от обстоятельств, иронию, удивление, восторг, ненависть, радость, презрение и удовлетворенность.)
3. Знаменито.
4. Мрачный. (По отношению ко всему. Например: «мрачный Петя пришел», «мрачная погода», «мрачный случай», «мрачный кот» и т. д.)
5. Мрак.
6. Жуть. (Жуткий. Например, при встрече с доброй знакомой: «жуткая встреча»).
7. Парниша. (По отношению ко всем знакомым мужчинам, независимо от возраста и общественного положения).
8. Не учите меня жить.
9. Как ребёнка. («Я его бью, как ребенка» — при игре в карты. «Я его срезала, как ребенка» — как видно, в разговоре с ответственным съемщиком).
10. Кр-р-расота!
11. Толстый и красивый. (Употребляется как характеристика неодушевленных и одушевленных предметов).
12. Поедем на извозчике. (Говорится мужу).
13. Поедем на таксо. (Знакомым мужского пола).
14. У вас вся спина белая (шутка).
15. Подумаешь!
16. Уля. (Ласкательное окончание имен. Например: Мишуля, Зинуля).
17. Ого! (Ирония, удивление, восторг, ненависть, радость, презрение и удовлетворенность).
Оставшиеся в крайне незначительном количестве слова служили передаточным звеном между Эллочкой и приказчиками универсальных магазинов.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, x-code, Вы писали:
XC>>Средства разработки... хочу IDE, по функционалу превосходящее Visual Studio 2010, а по скорости работы — превосходящее Visual Studio 6.0.
PD>Эх... Чует мое сердце, что скорости работы Visual Studio 6.0 уже никогда не будет
Смотри следующую версию Notepad. И по функциональности не сильно уступает.
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, VoidEx, Вы писали:
Л>>В естественном языке десятки тысяч слов (не считая научных терминов). Но общаться на нём можно, имея словарный запас в несколько десятков слов. Язык программирования должен быть таким же. VE>Почему?
Язык — это единое культурное пространство, в котором люди с разным уровнем подкованности способны понимать друг друга, не затрагивая какие-то глубокие проблемы. Кроме того, наиболее употребительные вещи должны излагаться в более краткой форме. Чтоб тратить меньше времени на чтение и набор.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Мне лет десять назад понадобилась хорошая библиотека по теории вероятности. Искал долго, попадалось большое количество всякого и разного, все на Фортране. Наконец нашел на С, вполне приличная библиотека, как оказалось, в исходниках. Чтение этих исходников сразу показало , откуда уши растут — это был фортрановский код, переведенный на С почти 1:1, в том числе с GOTO. Впрочем, это и не скрывалось — в readme было сказано, что работа по переводу была выполнена по какому-то гранту.
А напрямую фортрановские библиотеки нельзя было использовать? ЕМНИП, это несложно. Правда, загвоздка была: Borland C++ с MS Fortran в среде MS DOS не состыковывался, кроме простейших случаев.
Здравствуйте, TimurSPB, Вы писали:
TSP>Часто пишут о грядущей смерти C/С++ и о том что Java + .NET будущее программирования на долгие годы вперед. TSP>Я считаю, что Java и .NET просто шаг вперед к языкам и платформам которые дадут возможности управления всеми доступными ресурсами сразу на разных уровнях. От регистров процессоров до бизнес логики. Язык будущего должен давать возможность определять классы и создавать их экземпляры так, что бы можно было определять уровни доступа к ресурсам на разных уровнях.
В будущем будут писать программы сразу на смеси языков. Скажем, C/C++ для мест, узких в плане производительности или требующих интимных отношений с операционной системой, на Ерланге, Окамле или Хаскелле в "умных" местах, на Питоне в "гибких", на Яве в местах, требующих интеграции с legacy, на дотнете там, где код пишут 1000 индусов. Однополярный мир закончился
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>От текста к визуальным образам с произвольным профилированием визуализации в зависимости от текущих задач. Но, правда, мощности даже современных компьютеров на это слегка не очень хватает. Визуализируй-ка мне boost в реалтайме... В процессе разработки.
Вся эволюция культуры заключается как раз в движении от визуальных образов к тексту (не только в программировании). Думаете, тенденция к распаду нашей цивилизации таки победит?
ГВ>Задача 0: наследование имеющегося ПО. До хрена процентов которого написана на C, C++, Shell language, Perl, Visual Basic, SQL. Пока что об эту задачу обламывают зубы все без исключения.
Тут уже наметился общепринятый подход: оставляем legacy как есть, и делаем к нему интерфейс из нового кода. Новый код может быть написан на совершенно другом языке, и даже жить в другой коробке с другой операционной системой.
Здравствуйте, TimurSPB, Вы писали:
TSP>А как вы видите развитие средств разработки программ?
Как избавление 99% программистов от мыслей о низкоуровневой работе.
Не нужно быть гением-провидцем, чтобы понять, что все развитие компьютеров идет в сторону улучшения асбрагирования от железа. Вот очевидные этапы развития:
1. 40-ые года прошлого века — программирование на уровне переключения проводочков и перепаивания ламп.
2. 50-ые — программирование на уровне машинных инструкций.
3. 60-ые — переход к ассемблерам.
4. 60-70-ые — переход к "языкам высокого уровня" аля Алгол и Фртран (в последствие С, Паскаль).
5. 70-ые — переход к ООП и ФП.
6. 90-ые переход к типобезопасным и управляемым языкам. Переход к компонентным технологиям.
7. (будущее) Очевидно развитие будет идти в ту же сторону. Будет повышаться уровень языков, мощность библиотек. В программировании будет все больше цениться декларативность (причем достигаемая не обязательно с помощью ФП, а любая). Языки начнут предоставлять возможности верификации программ.
Тоже самое на уровне ОС:
1. ОС нет как класс.
2. ОС без защиты памяти и вообще почти без ничего. Есть только базовые сервисы.
3. ОС предоставляют основные сервисы. Программам не надо общаться с железом напрямую.
4. ОС с защитой памяти процессов, сменные драйверы.
5. (будущее) Управляемые и верефицируемые ОС.
Конечно исследования и пробные работы были и раньше. И, вообще, все года довольно услонвые, но общая тенденция именно такова.
Так что требовать от языков каких-то переходов на более низкий уровень — это просто смешно. В том же C# на сегодня есть конструкция unsafe. Вот только на практике ее используют крайне редко. Большей части для интеграции со "старым миром".
Самое смешное, что с точки зрения оптимизации скорости выполнения ПО высокоуровенвость и декларативность кода — это благо, а не недостаток. Пока что оптимизация находится на очень низком уровне и преимущество это скорее гипотетическое. Но со временем оно обязательно перейдет в практическую плоскость. И тогда вороченье битами станет таким же моветоном как сегодня программирование на ассемблере.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Эх... Чует мое сердце, что скорости работы Visual Studio 6.0 уже никогда не будет
У меня она тормозила безбожно, потому как компьютер был слабенький, а писал я на С++ с использованием Томато (как его там?).
А 2008-ая студия у меня сейчас запускается весьма шустро. Я ее запускаю очень часто, так как отлаживаю интеграцию для нее же. Компьютер конечно другой. 4-х ядерный и намного более быстрый. Но и возможности стали намного большими. Да и языки сильно мощнее.
Конечно VS 2010 по началу будет казаться дико медленной. Но со временем железо догонит и перегонит. Так что и она окажется вполне шустрой. Ну, а возможности в очередной раз расширятся.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Pzz, Вы писали:
ГВ>>От текста к визуальным образам [...] Pzz>Вся эволюция культуры заключается как раз в движении от визуальных образов к тексту (не только в программировании). Думаете, тенденция к распаду нашей цивилизации таки победит?
Вот знаешь, о том же задумался. Может, идея визуализации и не совсем правильная.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, LaptevVV, Вы писали:
PD>>Эх... Чует мое сердце, что скорости работы Visual Studio 6.0 уже никогда не будет LVV>Не... Блэк-бокс вполне себе шустро работает...
Мне кажется, что его среда даже VS 6 по функциональности уступает.
Там хоть комплит есть?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
T>Если серьёзно, то иди читай про зависимые типы.
Интересно, языки, поддерживающие зависимые типы, заставляют ли программиста описывать типы максимально точно? А то ведь можно например описать бОльшую область возращаемого значения функции, чем её реальная область значения. И какой тогда от них смысл будет, если программистам будет влом их писать.
А если функция короткая (простая), программист вообще будет считать излишним описывать. и тд.
Возможно ли в языках, поддерживающих ЗТ, подставлять уже описанную функцию (например из библиотеки) в преобразование типа? То есть программирование частично сведется к преобразованию типов.
Здравствуйте, Aleх, Вы писали:
A>Здравствуйте, thesz, Вы писали:
T>>Если серьёзно, то иди читай про зависимые типы. A>Интересно, языки, поддерживающие зависимые типы, заставляют ли программиста описывать типы максимально точно? А то ведь можно например описать бОльшую область возращаемого значения функции, чем её реальная область значения. И какой тогда от них смысл будет, если программистам будет влом их писать.
В декларативном программировании это всё расписали. Там есть ветка про зависимые типы.
A>А если функция короткая (простая), программист вообще будет считать излишним описывать. и тд.
Нет.
Функция две строки и строка типа.
Обычно — функция пять-семь строк и тип в одну строку.
Здравствуйте, LaptevVV, Вы писали:
LVV>Среды такой пока нет. Ибо существующие промышленные ПРОФЕССИОНАЛЬНЫЕ среды заточены под текстовый редактор (от уж маразм, так маразм!). Когда будут заточны под семантические модели — тогда будет тебе счастье!
Маразм — это рассматривать визуальную модель через замочную скважину, коей является любой даже 30" монитор. Для работы со средненькой моделью нужен монитор размером со стену. Вот тогда может быть и будет счастье.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, thesz, Вы писали:
T>Здравствуйте, Aleх, Вы писали:
A>>Здравствуйте, thesz, Вы писали:
T>>>Если серьёзно, то иди читай про зависимые типы. A>>Интересно, языки, поддерживающие зависимые типы, заставляют ли программиста описывать типы максимально точно? А то ведь можно например описать бОльшую область возращаемого значения функции, чем её реальная область значения. И какой тогда от них смысл будет, если программистам будет влом их писать.
T>В декларативном программировании это всё расписали. Там есть ветка про зависимые типы.
A>>А если функция короткая (простая), программист вообще будет считать излишним описывать. и тд.
T>Нет.
T>Функция две строки и строка типа.
T>Обычно — функция пять-семь строк и тип в одну строку.
T>http://www.cs.swan.ac.uk/~csetzer/lectures/intertheo/07/interactiveTheoremProvingForAgdaUsers.html T>http://www.cs.chalmers.se/~peterd/papers/DependentTypesAtWork.pdf
A>>Возможно ли в языках, поддерживающих ЗТ, подставлять уже описанную функцию (например из библиотеки) в преобразование типа? То есть программирование частично сведется к преобразованию типов.
T>Что такое "подставлять функцию из библиотеки в преобразование типа"?
Это значит, пусть описана функция (например сортировка) описан тип аргумента(просто список) и тип результата (отсортированный список). Программист пишет преобразование типа (список => отсортированный список), и вместо преобразования компилятор подставляет функцию.
А ещё лучше так. В библиотеке описаны множество функций, работающих с одинаковыми парами тип аргумента и тип возвращаемого значения (например сортировки, но разные алгоритмы, имеющие разные характеристики, например вычислительную сложность), и компилятор на месте преобразования типа подставляет наиболее оптимальную с точки зрения производительности функцию в зависимости от того, от некоторых характеристик данных, например их размера (длины в случае списка).
Было бы вообще замечательно, если бы компилятор мог генерировать некоторые классы функций. Разумеется задача не разрешима в общем виде, но всё же в некоторых простых случаях было бы удобно, и я полагаю это возможно реализовать.
Так вот, что нибудь похожее где нибудь реализовано, или ЗТ позволяют только верифицировать код?
Здравствуйте, Pzz, Вы писали:
Pzz>Вся эволюция культуры заключается как раз в движении от визуальных образов к тексту (не только в программировании). Думаете, тенденция к распаду нашей цивилизации таки победит?
Вся _предшествующая_ эволюция культуры. Это диалектическая спираль: от визуальных образов к тексту и далее снова к визуальным образам. Не думаешь же ты, что текст и есть квинт-эссенция культуры?
А про визуализацию boost: auto_ptr — черненький параллелепипед, share_ptr — красненький.
Здравствуйте, любой, Вы писали:
Л>Здравствуйте, VoidEx, Вы писали:
Л>>>В естественном языке десятки тысяч слов (не считая научных терминов). Но общаться на нём можно, имея словарный запас в несколько десятков слов. Язык программирования должен быть таким же. VE>>Почему?
Л>Язык — это единое культурное пространство, в котором люди с разным уровнем подкованности способны понимать друг друга, не затрагивая какие-то глубокие проблемы.
Неправда. Пока не было обильного обмена информацией, люди в разных городах могли друг друга не понимать. Боюсь, что даже сейчас люди из разных поколений будут понимать друг друга крайне смутно.
Вот математика — это единое культурное пространство, правда, там нужно иметь достаточно высокий уровень подкованности.
Здравствуйте, Aleх, Вы писали:
A>>>Возможно ли в языках, поддерживающих ЗТ, подставлять уже описанную функцию (например из библиотеки) в преобразование типа? То есть программирование частично сведется к преобразованию типов.
T>>Что такое "подставлять функцию из библиотеки в преобразование типа"? A>Это значит, пусть описана функция (например сортировка) описан тип аргумента(просто список) и тип результата (отсортированный список). Программист пишет преобразование типа (список => отсортированный список), и вместо преобразования компилятор подставляет функцию.
Уже есть.
A>А ещё лучше так. В библиотеке описаны множество функций, работающих с одинаковыми парами тип аргумента и тип возвращаемого значения (например сортировки, но разные алгоритмы, имеющие разные характеристики, например вычислительную сложность), и компилятор на месте преобразования типа подставляет наиболее оптимальную с точки зрения производительности функцию в зависимости от того, от некоторых характеристик данных, например их размера (длины в случае списка).
Задайте требуемую сложность в типе — а [yrl=http://okmij.org/ftp/Haskell/number-parameterized-types.html]это уже возможно[/url], — получите требуемую функцию по выбору сложности.
A>Было бы вообще замечательно, если бы компилятор мог генерировать некоторые классы функций. Разумеется задача не разрешима в общем виде, но всё же в некоторых простых случаях было бы удобно, и я полагаю это возможно реализовать.
Значит, надо реализовать, если возможно.
A>Так вот, что нибудь похожее где нибудь реализовано, или ЗТ позволяют только верифицировать код?
Скрестите вон те две ссылки, что выше, и будет вам счастие.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, Геннадий Васильев, Вы писали:
Pzz>>Вся эволюция культуры заключается как раз в движении от визуальных образов к тексту (не только в программировании). Думаете, тенденция к распаду нашей цивилизации таки победит?
ГВ>Вот знаешь, о том же задумался. Может, идея визуализации и не совсем правильная.
Она, по-моему, сродни комиксам. С одной стороны, сложную вещь так не скажешь, т.е. уровень падает. С другой, комиксы проще для восприятия, чем текст, т.е. культура становится более массовой.
Здравствуйте, Vi2, Вы писали:
Pzz>>Вся эволюция культуры заключается как раз в движении от визуальных образов к тексту (не только в программировании). Думаете, тенденция к распаду нашей цивилизации таки победит?
Vi2>Вся _предшествующая_ эволюция культуры. Это диалектическая спираль: от визуальных образов к тексту и далее снова к визуальным образам.
Ну в принципе да, время от времени цивилизация приходит в состояние упадка. Старые достижения забываются, мир завоёвывают варвары. Потом проходит сколько-то веков, и цивилизация возрождается. Не исключено, что сейчас мы наблюдаем именно процесс упадка. Надеюсь не дожить до его завершения
Vi2>Не думаешь же ты, что текст и есть квинт-эссенция культуры?
VE>Вот математика — это единое культурное пространство, правда, там нужно иметь достаточно высокий уровень подкованности.
Чёрта с два. Одну и ту же сложную задачу обычно можно решить совершенно разными способами. Применяя разные подходы. В зависимости от того, к какой научной школе ты ближе.
Простой пример: если ты знаешь, что такое вариация функционала, ты можешь решить определённую задачу немного проще, чем просто с применением в лоб дифференциального исчисления. Но это не обязательно значит, что ты её не решишь без применения вариаций.
(Сравните: http://www.cneat.ru/lex3.html
и http://www.ispa-soft.ru/statxi/statxq2.htm)
То же касается и операционного исчисления.
Уверен, что есть ещё много областей математики, знание которых в принципе является не точным признаком квалифицированности, а только отношением к определённому разделу математики.
Pzz>В будущем будут писать программы сразу на смеси языков. Скажем, C/C++ для мест, узких в плане производительности или требующих интимных отношений с операционной системой, на Ерланге, Окамле или Хаскелле в "умных" местах, на Питоне в "гибких", на Яве в местах, требующих интеграции с legacy, на дотнете там, где код пишут 1000 индусов. Однополярный мир закончился
Врядли. Из соображений безопасности выгоднее обособить такой функционал в отдельные модули, за интеграцией/доступом к которым следить по отдельности.
Здравствуйте, thesz, Вы писали:
T>Здравствуйте, Aleх, Вы писали:
A>>>>Возможно ли в языках, поддерживающих ЗТ, подставлять уже описанную функцию (например из библиотеки) в преобразование типа? То есть программирование частично сведется к преобразованию типов.
T>>>Что такое "подставлять функцию из библиотеки в преобразование типа"? A>>Это значит, пусть описана функция (например сортировка) описан тип аргумента(просто список) и тип результата (отсортированный список). Программист пишет преобразование типа (список => отсортированный список), и вместо преобразования компилятор подставляет функцию.
T>http://lambda-the-ultimate.org/node/1178
T>Уже есть.
Вижу генерацию функции по описанию типа.
Но где там зависимые типы?
A>>А ещё лучше так. В библиотеке описаны множество функций, работающих с одинаковыми парами тип аргумента и тип возвращаемого значения (например сортировки, но разные алгоритмы, имеющие разные характеристики, например вычислительную сложность), и компилятор на месте преобразования типа подставляет наиболее оптимальную с точки зрения производительности функцию в зависимости от того, от некоторых характеристик данных, например их размера (длины в случае списка).
T>Задайте требуемую сложность в типе — а [yrl=http://okmij.org/ftp/Haskell/number-parameterized-types.html]это уже возможно[/url], — получите требуемую функцию по выбору сложности.
Ну а по второй ссылке, где там вообще генерация функций? Например в этом документе http://okmij.org/ftp/papers/number-parameterized-types.pdf в основном про типы, параметризуемые различными числами. Скопируйте цитату, где это написано "Задайте требуемую сложность в типе — ... получите требуемую функцию по выбору сложности"
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Каким он будет — в основном будет определяться тем, какими будут задачи, и какие новые явления в миое ИТ нас ожидают. А это непредсказуемо.
Что там не предсказуемого то? Ближайшая задача — освоение кучи ядер. У меня на компьютере их уже 4. На горизонте 6 и 8. Лет через 5 будет, скорее всего 16. Писать параллельный код на С++ или Яве с использованием мьютексов и нетерлоков — это маразм. Так что ежу понятно, что в ближайшие время силы пойдут на решение этой проблемы. Ну, и вопрос повышения уровня абстракции никто не снимал с повестки дня.
Всем кто молится на указатели и битовые операции счастливо оставаться в прошлом веке.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Как-то негоже давать ссылки не на конкретные темы, а просто на чужие форумы. Вместо полезной ссылки получается бесплатная реклама. Точнее с учетом поставленных тебе оценок — антиреклама.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, LaptevVV, Вы писали:
LVV>>См. язык Дракон на оберонском форуме LVV>>http://forum.oberoncore.ru/index.php
VD>Как-то негоже давать ссылки не на конкретные темы, а просто на чужие форумы. Вместо полезной ссылки получается бесплатная реклама. Точнее с учетом поставленных тебе оценок — антиреклама.
Там прям конкретный форум: Визуальный язык Дракон
Как у нас на РСДН, например, С++.
А туда заходишь, и начинаешь обсуждать. Там первой темой висит краткое описание и чего надо прочитать, если хочешь подробно.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, VladD2, Вы писали:
PD>>>Эх... Чует мое сердце, что скорости работы Visual Studio 6.0 уже никогда не будет LVV>>Не... Блэк-бокс вполне себе шустро работает...
VD>Мне кажется, что его среда даже VS 6 по функциональности уступает. VD>Там хоть комплит есть?
Посмотрел... Там не то что комплита. Там даже подсветки синтаксиса нет. Какой смысл сравнивать это Вордпэд с IDE?
То что гиперлинки в текст можно вставить и картинки никак не помогает писать код.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, LaptevVV, Вы писали:
LVV>Там прям конкретный форум: Визуальный язык Дракон
А кому нужен этот конкретный форум? Дай ссылку на конкретное описание. Это будет интересно.
К тому же ты дал ссылку даже не на конкретный форум, а просто в никуда.
LVV>Как у нас на РСДН, например, С++.
Ну, и нормально будет дать человеку не знающему С++ ссылку на rsdn.ru?
LVV>А туда заходишь, и начинаешь обсуждать. Там первой темой висит краткое описание и чего надо прочитать, если хочешь подробно.
Открою тебе секрет. Здесь вряд ли кому-то захочется обсуждать драконы. По карйней мере до тех пор пока не будет внятного объяснения, что это такое и что это дает.
В общем, разумно было бы вместо ссылки на черт знает какой сайт дать ссылку на страницу в Википедии или на этом сайте которая описывала бы этот язык.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Aleх, Вы писали:
A>Здравствуйте, thesz, Вы писали:
T>>Здравствуйте, Aleх, Вы писали:
A>>>>>Возможно ли в языках, поддерживающих ЗТ, подставлять уже описанную функцию (например из библиотеки) в преобразование типа? То есть программирование частично сведется к преобразованию типов.
T>>>>Что такое "подставлять функцию из библиотеки в преобразование типа"? A>>>Это значит, пусть описана функция (например сортировка) описан тип аргумента(просто список) и тип результата (отсортированный список). Программист пишет преобразование типа (список => отсортированный список), и вместо преобразования компилятор подставляет функцию.
T>>http://lambda-the-ultimate.org/node/1178 T>>Уже есть. A>Вижу генерацию функции по описанию типа. A>Но где там зависимые типы?
Есть такая штука, называется лямбда-куб. Типы Хаскеля и ML только одна точка на этом кубе ("типы зависят от типов"), и входят в качестве подвселенной во вселенную зависимых типов.
A>>>А ещё лучше так. В библиотеке описаны множество функций, работающих с одинаковыми парами тип аргумента и тип возвращаемого значения (например сортировки, но разные алгоритмы, имеющие разные характеристики, например вычислительную сложность), и компилятор на месте преобразования типа подставляет наиболее оптимальную с точки зрения производительности функцию в зависимости от того, от некоторых характеристик данных, например их размера (длины в случае списка).
T>>Задайте требуемую сложность в типе — а [yrl=http://okmij.org/ftp/Haskell/number-parameterized-types.html]это уже возможно[/url], — получите требуемую функцию по выбору сложности.
A>Ну а по второй ссылке, где там вообще генерация функций? Например в этом документе http://okmij.org/ftp/papers/number-parameterized-types.pdf в основном про типы, параметризуемые различными числами. Скопируйте цитату, где это написано "Задайте требуемую сложность в типе — ... получите требуемую функцию по выбору сложности"
Для этого надо скомбинировать подход с подходом выше. Сложность можно задавать, она входит в тип функции, функции по типу мы собирать умеем.
Поскольку вы уверены в том, что это осуществимо, вам и карты в руки.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, Vi2, Вы писали:
Vi2>Вся _предшествующая_ эволюция культуры. Это диалектическая спираль: от визуальных образов к тексту и далее снова к визуальным образам. Не думаешь же ты, что текст и есть квинт-эссенция культуры?
Vi2>А про визуализацию boost: auto_ptr — черненький параллелепипед, share_ptr — красненький.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>>От текста к визуальным образам с произвольным профилированием визуализации в зависимости от текущих задач. Но, правда, мощности даже современных компьютеров на это слегка не очень хватает. Визуализируй-ка мне boost в реалтайме... В процессе разработки.
Pzz>Вся эволюция культуры заключается как раз в движении от визуальных образов к тексту (не только в программировании). Думаете, тенденция к распаду нашей цивилизации таки победит?
Ты упустил:
а) Чертежи
б) Электрические схемы
в) Графики и функции
TimurSPB пишет:
> Часто пишут о грядущей смерти C/С++ и о том что Java + .NET будущее > программирования на долгие годы вперед.
С никуда не денется. В смысле, не умрёт. Ясное дело, что его будут
использовать меньше, но будут. Операционки на чём ещё писать ?
> Я считаю, что Java и .NET просто шаг вперед к языкам и платформам > которые дадут возможности управления всеми доступными ресурсами сразу на > разных уровнях.
Я так не считаю. Java я вообще не люблю и, я бы сказал, это -- шаг
назад, во всех отношениях. Да и по идеологии своей Java --язык,
который создавался в период объектно-ориентированной эйфории,
однобокий, убогий ОО- язык.
.Net (С#) тут уже намного лучше -- он создавался позже,
и развивается лучше (на сколько я знаю, я могу быть не прав),
и в более правильном направлении.
А вот о языках, которые "дадут возможности управления всеми
доступными ресурсами сразу на разных уровнях" -- таких
языков в принципе быть не должно. Лучше иметь 10 разных
хороших языков каждый для своей цели, чем 1 универсальный
для всего-всего-всего.
> должен давать возможность определять классы и создавать их экземпляры > так, что бы можно было определять уровни доступа к ресурсам на разных > уровнях.
Есть мнение, что ОО-программированием мир не ограничивается.
А в связи с развитием многозадачных платформ в первую очередь должны
"играть" чисто функциональные языки.
Здравствуйте, alpha21264, Вы писали:
Pzz>>Вся эволюция культуры заключается как раз в движении от визуальных образов к тексту (не только в программировании). Думаете, тенденция к распаду нашей цивилизации таки победит?
A>Ты упустил: A>а) Чертежи
Collada?
A>б) Электрические схемы
Которые всё чаще описываются на VHDL и VHDL-AMS.
A>в) Графики и функции
Это да. Тут деваться некуда. Так и использование у них чисто иллюстративное, а не для разработки.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
dmz>>В эрланге битовый паттерн-матчинг. А в Си нету даже двоичных литералов. Это к вопросу о.
VD>Ага. Это к вопросу о том, что всегда найдется кто-то кому тема не интересна, но очень хочется подокапываться к словам и поболоболить без темы.
Ну почему, интересна. Все мы понемногу, с разных сторон занимаемся языком будущего. Просто приводить битовые операции как некую антитезу прогрессу неправильно --- в старых, унылых языках даже и битовых операций толком нет.
Здравствуйте, dmz, Вы писали:
dmz>Ну почему, интересна. Все мы понемногу, с разных сторон занимаемся языком будущего. Просто приводить битовые операции как некую антитезу прогрессу неправильно --- в старых, унылых языках даже и битовых операций толком нет.
Просто одни читают суть, а другие буквы.
Про указатели тоже можно много умного сказать. Вспомнить, что они есть в безопасном виде в Обероне и в не безопасном в Шарпе. Вот только это и есть разговор не по сути.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, alpha21264, Вы писали:
Pzz>>Вся эволюция культуры заключается как раз в движении от визуальных образов к тексту (не только в программировании). Думаете, тенденция к распаду нашей цивилизации таки победит?
A>Ты упустил: A>а) Чертежи A>б) Электрические схемы A>в) Графики и функции
Электрические схемы особо хороший пример: по мере усложнения они постепенно вытесняются текстом на verilog'е
Здравствуйте, VladD2, Вы писали:
VD>В общем, разумно было бы вместо ссылки на черт знает какой сайт дать ссылку на страницу в Википедии или на этом сайте которая описывала бы этот язык.
Хорошо. Вот самая конкретная ссылка http://forum.oberoncore.ru/viewtopic.php?f=62&t=1276
Там даже об использовании вариантов Дракона при программировании Бурана (того самого).
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, alpha21264, Вы писали:
Pzz>>>Вся эволюция культуры заключается как раз в движении от визуальных образов к тексту (не только в программировании). Думаете, тенденция к распаду нашей цивилизации таки победит?
A>>Ты упустил: A>>а) Чертежи A>>б) Электрические схемы A>>в) Графики и функции
Pzz>Электрические схемы особо хороший пример: по мере усложнения они постепенно вытесняются текстом на verilog'е
Понимаешь... verilog не является человеко-читаемым.
Если ты хочешь сам понять (а не компьютеру скормить) то информацию надо представить наглядно.
То есть видимо глазами.
По-этому, пишем мы на языке (текст), а получаем ГУИ (картинку).
И даже текст — это структура. С заголовочками, отступами, выделением цветом и т.д.
Напомнить чем Ворд отличается от текстового редактора?
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, LaptevVV, Вы писали:
LVV>>Среды такой пока нет. Ибо существующие промышленные ПРОФЕССИОНАЛЬНЫЕ среды заточены под текстовый редактор (от уж маразм, так маразм!). Когда будут заточны под семантические модели — тогда будет тебе счастье!
IT>Маразм — это рассматривать визуальную модель через замочную скважину, коей является любой даже 30" монитор. Для работы со средненькой моделью нужен монитор размером со стену. Вот тогда может быть и будет счастье.
В советских НИИ нечто подобное делали. Общая схема какой-нибудь фиговины — распечатка во всю стену.
Правда, если таких фиговин было две, то стены не хватало
Здравствуйте, любой, Вы писали:
Л>В естественном языке десятки тысяч слов (не считая научных терминов). Но общаться на нём можно, имея словарный запас в несколько десятков слов. Язык программирования должен быть таким же. При этом он должен охватывать все области программирования, позволять описывать DSL'и (domain-specific language). Он должен быть отделён от каких-то обязательных библиотек. Также, он должен обеспечивать полный контроль над получаемым исполняемым кодом.
Дык это, С/С++ знаешь?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
ЕМНИП, это несложно. Правда, загвоздка была: Borland C++ с MS Fortran в среде MS DOS не состыковывался, кроме простейших случаев.
Если нам не помогут, то мы тоже никого не пощадим.
Например в этом документе http://okmij.org/ftp/papers/number-parameterized-types.pdf в основном про типы, параметризуемые различными числами. Скопируйте цитату, где это написано "Задайте требуемую сложность в типе — ... получите требуемую функцию по выбору сложности"
