Разработчики из Google начали делать Noop — новый язык для JVM. Часть компилятора написана на Scala.

Noop says Yes to

* Dependency injection in the language
* Testability — a seam between every pair of classes
* Immutability
* Readable code is more important than any syntax feature
* Executable documentation that's never out-of-date
* Properties, strong typing, and sensible modern stdlib

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

N>Разработчики из Google начали делать Noop — новый язык для JVM. Часть компилятора написана на Scala.

N>

N>Noop says Yes to
N>* Dependency injection in the language

Тут я сломался.

http://code.google.com/p/noop/wiki/ProposalForNewableVsInjectable

Это ж ужас!

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

N>Разработчики из Google начали делать Noop — новый язык для JVM. Часть компилятора написана на Scala.

Пока нет документа с описанием языка — сложно что-то сказать.

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

N>>Разработчики из Google начали делать Noop — новый язык для JVM. Часть компилятора написана на Scala.

LVV>Пока нет документа с описанием языка — сложно что-то сказать.

Зато на многое можно повлиять.

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

N>Noop

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

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

N>Разработчики из Google начали делать Noop — новый язык для JVM. Часть компилятора написана на Scala.

Гораздо интереснее то, чему Noop говорит "нет":

Any statics whatsoever

Implementation inheritance (subclassing)

Primitives

Unnecessary boilerplate

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

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

N>>Разработчики из Google начали делать Noop — новый язык для JVM. Часть компилятора написана на Scala.

J>Гораздо интереснее то, чему Noop говорит "нет":
J>

J>

Implementation inheritance (subclassing)

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

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

N>Разработчики из Google начали делать Noop — новый язык для JVM. Часть компилятора написана на Scala.

N>[q]
N>Noop says Yes to

N>* Dependency injection in the language
N>* Testability — a seam between every pair of classes
N>* Immutability

Боюсь, получится еще один хаскель. Тотальная иммутабельность до добра не доводит.

По-моему, Scala — самый разумный на сегодняшний день выбор. Она поддерживает ФП в той же степени, что и Хаскель, при этом оставляя место и другим парадигмам. По-большому счету, для большинства задач и явы хватало, скала — просто более хорошая, новая ява, а больше ничего и не нужно.

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

LP>По-моему, Scala — самый разумный на сегодняшний день выбор. Она поддерживает ФП в той же степени, что и Хаскель, при этом оставляя место и другим парадигмам. По-большому счету, для большинства задач и явы хватало, скала — просто более хорошая, новая ява, а больше ничего и не нужно.

В общем-то я согласен. После того как усилиями Adriaan Moors в Scala были добавлены higher-kinded types, в ней стало возможно эмулировать почти все возможности стандартных Haskell type classes. Не хватает только возможности условной реализации классов (например, список является Ordered, если элементы являются Ordered).

Ну и еще не хватает поддержки rank-N polymorphism на уровне языка (хотя его можно эмулировать).

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

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

LP>>По-моему, Scala — самый разумный на сегодняшний день выбор. Она поддерживает ФП в той же степени, что и Хаскель, при этом оставляя место и другим парадигмам. По-большому счету, для большинства задач и явы хватало, скала — просто более хорошая, новая ява, а больше ничего и не нужно.

N>Не хватает только возможности условной реализации классов (например, список является Ordered, если элементы являются Ordered).

Не можешь объяснить, как такое возможно? Поддерживает ли данный элемент интерфейс Ordered или нет — это же информация времени выполенения. Наверное, это какой-то навороченный instanceof с диспетчеризацией внутри класса?

N>Ну и еще не хватает поддержки rank-N polymorphism на уровне языка (хотя его можно эмулировать).

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

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

N>>Не хватает только возможности условной реализации классов (например, список является Ordered, если элементы являются Ordered).

LP>Не можешь объяснить, как такое возможно? Поддерживает ли данный элемент интерфейс Ordered или нет — это же информация времени выполенения. Наверное, это какой-то навороченный instanceof с диспетчеризацией внутри класса?

Ну как в хаскеле:

instance  (Ord a) => Ord (Tree a)  where
    (Leaf _)     <= (Branch _)      =  True
    (Leaf x)     <= (Leaf y)        =  x <= y
    (Branch _)   <= (Leaf _)        =  False
    (Branch l r) <= (Branch l' r')  =  l == l' && r <= r' || l <= l'

Можно создавать Tree, для элементов которых не определен инстанс класса Ord, тогда и для деревьев он не будет определен. А если создадим Tree, элементы которого поддерживают Ord, то сразу получаем возможность упорядочивать и сами деревья. ИМХО, в Scala такое не возможно.

N>>Ну и еще не хватает поддержки rank-N polymorphism на уровне языка (хотя его можно эмулировать).
LP>Боюсь справшивать что это такое, ну да ладно, вроде жили без него, проживем и далее

Ну, проще говоря, это возможность передать куда-то функциональное значение, представляющее generic метод, и уже там, куда мы его передали, вызвать этот метод с разными типами-аргументами. Сейчас в Scala для этого нужно создавать специальный класс-обертку для такого функционального значения (здесь). А существующие расширения хаскеля поддерживают это на уровне языка.

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

N>

N>Noop says Yes to

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

Мое мнение — бредовая затея. Цели мутные. Полное ощущение, что люди живут в мире Явы и поняли что в ней что-то в ней не так, но что так и не поняли, так что пытаются прилепить к ней разные "нужные" вещи вроде ослиного хвоста и ластов.

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

N>В общем-то я согласен. После того как усилиями Adriaan Moors в Scala были добавлены higher-kinded types, в ней стало возможно эмулировать почти все возможности стандартных Haskell type classes.

А можно на пальцах объяснить — что это такое и с чем едят?

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

N>>В общем-то я согласен. После того как усилиями Adriaan Moors в Scala были добавлены higher-kinded types, в ней стало возможно эмулировать почти все возможности стандартных Haskell type classes.

VD>А можно на пальцах объяснить — что это такое и с чем едят?

Представь, что у тебя есть такая задача:

Есть много generic коллекций: List, LinkedList, Tree и т.д.
У всех этих коллекций есть generic метод Map[S], принимающий функцию, применяющий ее ко всем элементам коллекции и возвращающий коллекцию, имеющую тот же тип контейнера, но другой тип элементов.
Например, у типа List[T] этот метод будет иметь сигнатуру (T -> S) -> List[S], у LinkedList — сигнатуру (T -> S) -> LinkedList[S] и т.д. (пишу на псевдо-коде).

Теперь, тебе надо написать функцию Map0, которая будет абстрагироваться от конкретного типа коллекции, и вызывать у нее метод Map, передав ей функцию (_ -> 0), которая устанавливает все элементы коллекции в 0. Для этого все коллекции должны реализовывать общий интерфейс с методом Map. Но вот беда: в рамках обычных дженериков C#, Nemerle или Java такого не сделать — у методов Map совершенно разные сигнатуры. Здесь-то как раз и нужны higher-kinded types, то есть дженерики, у которых типы-параметры могут в свою очередь свои типы параметры. Тогда сигнатура метода Map будет такая (опять псевдо-код):

interface IMapableCollection[TCollection[_], T]
{
   Map[S] : (T -> S) -> TCollection[S];
}

class List[T] : IMapableCollection[List, T]
{
   Map[S] : (T -> S) -> List[S] { /* ... */ }
}

class LinkedList[T] : IMapableCollection[LinkedList, T]
{
   Map[S] : (T -> S) -> LinkedList[S] { /* ... */ }
}

def Map0[TCollection[_], T](coll : TCollection[T]) : TCollection[int] { coll.Map[int](_ -> 0); }

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

Более подробно читать диссертацию Adriaan Moors, его статьи, или Scala Language Specification.

В Haskell аналогичная задача решается классом типов Functor с функцией fmap.

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

N>Здесь-то как раз и нужны higher-kinded types, то есть дженерики, у которых типы-параметры могут в свою очередь свои типы параметры.
Здесь-то как раз и нужны higher-kinded types, то есть дженерики, у которых типы-параметры могут в свою очередь иметь свои типы параметры.

Надо добавить, что в Scala, кроме того, что обычные типы параметры могуть иметь upper и lower констрейнты (последние нужны в некоторых сценариях с контравариантностью), типы-параметры высших порядков тоже могут иметь констрейнты, и их собственные типы-параметры (которые, кстати, тоже могут быть высшего порядка!) тоже могут иметь констрейнты. Причем любой из этих типов параметров может быть как инвариантным, так и ко- или контравариантным, причем не только в трейтах(интерфейсах), но и в конкретных классах, а типы-параметры у типов-параметров высшего порядка — даже в методах.

Констрейнты в Scala называются bounds.

Пусть меня поправят специалисты, если я не прав, но по-моему, в Haskell нет никаких аналогов для подобных констрейнтов.

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

N>Тип-параметр TCollection — высшего порядка, потому что он декларирует наличие у него собственных типов-параметров (их имена обычно не важны, поэтому пишется _). При инстанциации типа IMapableCollection вместо TCollection должен быть передан generic тип, имеющий один обычный тип-праметр, без типа-аргумента.

Три вопроса:
1. Нельзя ли выразить этот тип верхнего уровня через ограничение (констрэйн)?
2. Насколько это нужно на практике? Не является ли это наукой ради науки?
3. Как эта штука уживается с наличием типов-значений?

N>Более подробно читать диссертацию Adriaan Moors, его статьи, или Scala Language Specification.
N>В Haskell аналогичная задача решается классом типов Functor с функцией fmap.

Аналог fmap можно получить средствами метапрограммирования.

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

N>...так и ко- или контравариантным, причем не только в трейтах(интерфейсах), но и в конкретных классах, а типы-параметры у типов-параметров высшего порядка — даже в методах.

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

N>Констрейнты в Scala называются bounds.

N>Пусть меня поправят специалисты, если я не прав, но по-моему, в Haskell нет никаких аналогов для подобных констрейнтов.

Остается вопрос — зачем оно все нужно?
Хаскель мне не нравится в первую очередь своей перенавороченностью. Даже простые вещи в нем имеют ужасающее описание.

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

J>

Any statics whatsoever

Что под статиками они понимают? Статические поля?

J>

Implementation inheritance (subclassing)

Давно пора приговорить.

J>

Primitives

?

J>

Unnecessary boilerplate

Слова ни о чем.

... << RSDN@Home 1.2.0 alpha 4 rev. 1237 on Windows 7 6.1.7100.0>>

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

J>>

Any statics whatsoever

AVK>Что под статиками они понимают? Статические поля?

Я думаю, и поля и методы. Наверное, будут делать, как в Scala — встроенные в язык singleton objects.

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

N>Я думаю, и поля и методы.

Ну поля — понятно, хотя уж больно фееричная перестраховка, а методы то чем помешали?

N> Наверное, будут делать, как в Scala — встроенные в язык singleton objects.

Не вникал подробно, но sigleton objects от проблем статических полей не избавляют
А вообще, как то по детски там у них все, имхо — ковыряются с мелочами, а на серьезные проблемы ответов не видно. Так языки лет 15-20 назад проектировали.

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

AVK>А вообще, как то по детски там у них все, имхо — ковыряются с мелочами, а на серьезные проблемы ответов не видно.

А вот интересно, на что ты обратил бы внимание, если бы сейчас проектировал высокоуровневый язык общего назначения.

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

VD>Три вопроса:
VD>1. Нельзя ли выразить этот тип верхнего уровня через ограничение (констрэйн)?
Не совсем понял вопрос, но скажу, что более простыми средствами эта проблема не решается, если мы хотим иметь безопасность типов во время компиляции (то есть отсутствие явных приведений типа).

VD>2. Насколько это нужно на практике? Не является ли это наукой ради науки?
Конечно, нужно. Сейчас вся стандартная библиотека коллекций в Scala переделана, чтобы использовать эту возможность. В общем-то, это очень естественная вещь: мы можем абстрагироваться от типа элементов коллекции, и можем абстрагироваться от типа контейнера. Можно привести кучу примеров, где это нужно. Например, мы уже имеем методы Map и Filter, и хотим написать MapFilter[S] : (T -> Option[S]) -> List[S], который бы применял данную функцию ко всем элементам, и те элементы, для которых она возвращает None, выбрасывал, а те, для которых возвращается Some(obj) — извлекал оттуда obj и помещал его в результирующую коллекцию. В Scala мы можем написать этот код один раз и он будет работать для любых коллекций, причем возвращать не базовый тип наподобие IEnumerable[S], а ту коллекцию, которую нужно.

VD>3. Как эта штука уживается с наличием типов-значений?
Нормально. В Scalа примитивные типы являются типами-значениями, и в отличие от Java, их можно использовать как типы-аргументы.

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

N>А вот интересно, на что ты обратил бы внимание, если бы сейчас проектировал высокоуровневый язык общего назначения.

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

Вот как выглядит настоящая Scala, а не псевдо-код:

trait Collection[TContainer[_], T] {
    def Convert[S](f : T => S) : TContainer[S]
    def Filter(p : T => Boolean) : TContainer[T]
}

class List[T] extends Collection[List, T] {
    def Convert[S](f : T => S) : List[S] = { /* ... */ }
    def Filter(p : T => Boolean) : List[T] = { /* ... */ }
}

class LinkedList[T] extends Collection[LinkedList, T] {
    def Convert[S](f : T => S) : LinkedList[S] = { /* ... */ }
    def Filter(p : T => Boolean) : LinkedList[T] = { /* ... */ }
}

object Program {
    def ConvertAndFilter[TContainer[X] <: Collection[TContainer, X], T](coll : TContainer[T], f : T => Int) : TContainer[Int] = { 
        coll.Convert(f).Filter(_ > 0) 
    }
    
    def Foo() : List[Int] = {
       val list = new List[String]
       ConvertAndFilter[List,String](list, _ => 2) // здесь почему-то не выводятся типы-аргументы
    }
}

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

VD>>3. Как эта штука уживается с наличием типов-значений?
N>Нормально. В Scalа примитивные типы являются типами-значениями, и в отличие от Java, их можно использовать как типы-аргументы.

Насколько я знаю это не так. Вэлью-типы тупо оборачиваются (боксятся).

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

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

N>>А вот интересно, на что ты обратил бы внимание, если бы сейчас проектировал высокоуровневый язык общего назначения.

AVK>Это очень сложный вопрос. Во-первых требований очень много, во-вторых у каждого свои задачи, и свои приоритеты. Но если говорить о том, о чем здесь мало спорят — наверное обратил бы внимание на технологичность процесса разработки на этом языке.
Тут одного языка мало — нужно разрабатывать сразу среду с языком.
Оригинальный подход к среде с языком сделали Виртовские ученики — разработка BlackBox очень не стандартна.

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

LVV>Тут одного языка мало — нужно разрабатывать сразу среду с языком.

Разумеется. К счастью, сейчас очень часто технологии разрабатываются с оглядкой на дизайн-тайм.

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

LVV>Оригинальный подход к среде с языком сделали Виртовские ученики — разработка BlackBox очень не стандартна.
Интересно, чего в ней вообще есть нестандартного?

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

LVV>Тут одного языка мало — нужно разрабатывать сразу среду с языком.
LVV>Оригинальный подход к среде с языком сделали Виртовские ученики — разработка BlackBox очень не стандартна.

Это что же там нового появилось?

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

AVK>наверное обратил бы внимание на технологичность процесса разработки на этом языке.

Это очень расплывчато.

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

VD>Это очень расплывчато.

Для раскрытия нужна масса времени.

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

N>Пусть меня поправят специалисты, если я не прав, но по-моему, в Haskell нет никаких аналогов для подобных констрейнтов.

Потому что в Haskell нет наследования?

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

N>>Пусть меня поправят специалисты, если я не прав, но по-моему, в Haskell нет никаких аналогов для подобных констрейнтов.

L>Потому что в Haskell нет наследования?

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

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

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

N>>Разработчики из Google начали делать Noop — новый язык для JVM. Часть компилятора написана на Scala.

N>>[q]
N>>Noop says Yes to

N>>* Dependency injection in the language
N>>* Testability — a seam between every pair of classes
N>>* Immutability

LP>Боюсь, получится еще один хаскель. Тотальная иммутабельность до добра не доводит.

У полумер это получается чаще.

LP>По-моему, Scala — самый разумный на сегодняшний день выбор. Она поддерживает ФП в той же степени, что и Хаскель

Три раза "ХА!".

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

Явы не хватает ни для какой задачи, вообще. Если, конечно, имеешь представление о тех же ОКамле с Хаскелем.

Я тут имею возможность сравнивать производительность одного и того же программиста на хорошо ему знакомой Яве и на малознакомом Хаскеле.

Сравнение явно не в пользу Явы.

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

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

LP>>По-моему, Scala — самый разумный на сегодняшний день выбор. Она поддерживает ФП в той же степени, что и Хаскель, при этом оставляя место и другим парадигмам. По-большому счету, для большинства задач и явы хватало, скала — просто более хорошая, новая ява, а больше ничего и не нужно.

N>В общем-то я согласен. После того как усилиями Adriaan Moors в Scala были добавлены higher-kinded types, в ней стало возможно эмулировать почти все возможности стандартных Haskell type classes. Не хватает только возможности условной реализации классов (например, список является Ordered, если элементы являются Ordered).

Иными словами, higher-kinded types не позволяют эмулировать даже базовые возможности классов типов Хаскеля.

Тем временем Хаскель ушёл ещё дальше.

N>Ну и еще не хватает поддержки rank-N polymorphism на уровне языка (хотя его можно эмулировать).

И GADT.

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

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

N>>Здесь-то как раз и нужны higher-kinded types, то есть дженерики, у которых типы-параметры могут в свою очередь свои типы параметры.
N>Здесь-то как раз и нужны higher-kinded types, то есть дженерики, у которых типы-параметры могут в свою очередь иметь свои типы параметры.

N>Надо добавить, что в Scala, кроме того, что обычные типы параметры могуть иметь upper и lower констрейнты (последние нужны в некоторых сценариях с контравариантностью), типы-параметры высших порядков тоже могут иметь констрейнты, и их собственные типы-параметры (которые, кстати, тоже могут быть высшего порядка!) тоже могут иметь констрейнты. Причем любой из этих типов параметров может быть как инвариантным, так и ко- или контравариантным, причем не только в трейтах(интерфейсах), но и в конкретных классах, а типы-параметры у типов-параметров высшего порядка — даже в методах.

N>Констрейнты в Scala называются bounds.

N>Пусть меня поправят специалисты, если я не прав, но по-моему, в Haskell нет никаких аналогов для подобных констрейнтов.

Классы типов.

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

Эти границы нужны при наличии наследования (отношения < (вложенность, или подстановочность, или как там оно называется) между типами). Если наследования типов нет, то и границы не нужны.

Хотя, с другой стороны, мы можем обеспечить работу в пересечении ограничений, (Lower a, Upper a) => ...

В общем и целом, система типов Хаскеля Тьюринг-полна и там можно выразить всё, что угодно.

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

L>>Потому что в Haskell нет наследования?
N>Ну, определенная форма наследования — для классов типов, всё таки есть.

Я так понял, что речь шла о наследовании типов всё же.

Ладно, тогда другой вопрос — чего ты хочешь добиться в рамках Хаскельных типов? Т.е. что будут означать констрейнты?
Пример из scala

trait Function1[-T1, +R]

Что будет означать в рамках Хаскеля, где нет наследования типов, эти — и +?

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

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

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

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

LVV>>Оригинальный подход к среде с языком сделали Виртовские ученики — разработка BlackBox очень не стандартна.
C>Интересно, чего в ней вообще есть нестандартного?
Среда — замкнутая. Для инженеров, вынужденных программировать, самое оно.
Любой модуль созданный в рамках среды, включается в среду. Вплоть до возможности прописывания данного модуля в меню. Таким образом, можно полностью сделать среду под свои задачи — на том же языке, на котором сами задачи пишутся.
Например, мне нужно специализированный редактор сделать, я реализую отдельный модуль, и он у меня лежит в системе и работает, когда я его вызываю. Модуль играет роль и компонента и DLL одновременно.
Окно с текстом — это не элементарный текст программы как в Блокноте.
Мне, например, очень импонирует, что я в одном и том же окне пишу текст лекции и тут же в этом же тексте пишу программу, которую могу оттранслировать и тут же запустить. Исходные данные для этой проги я могу тут же в этом же окне прописать — и прога их возьмет как входной файл (или как параметры командной строки — в данном случае неважно).

И кроме всего прочего, у меня, естественно, имеется возможность выйти из среды в том смысле, что либо подключить стороннюю DLL, либо создать свою собственную DLL для работы без среды в Windows. Можно и exe-модуль создать и работать независимо от среды.
В общем, мне как преподу она очень импонирует.

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

LVV>>>Оригинальный подход к среде с языком сделали Виртовские ученики — разработка BlackBox очень не стандартна.
C>>Интересно, чего в ней вообще есть нестандартного?
LVV>Среда — замкнутая. Для инженеров, вынужденных программировать, самое оно.
Не ново. См.: "Smalltalk", "Lisp" (в Симболиксах, к примеру).

LVV>Любой модуль созданный в рамках среды, включается в среду. Вплоть до возможности прописывания данного модуля в меню. Таким образом, можно полностью сделать среду под свои задачи — на том же языке, на котором сами задачи пишутся.
См.: "Smalltalk".

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

Эти подходы были известны задооооооооолго до Оберона. В частности, есть до сих пор удобные обучающие среды типа Squeak с теми же принципами.

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

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

LVV>>Тут одного языка мало — нужно разрабатывать сразу среду с языком.
LVV>>Оригинальный подход к среде с языком сделали Виртовские ученики — разработка BlackBox очень не стандартна.

VD>Это что же там нового появилось?
Насчет нового не знаю, я только в этом годе стал пользовать 1.5. Но народ ваяет 1.6 и переносит ее под Linux.

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

C>Эти подходы были известны задооооооооолго до Оберона. В частности, есть до сих пор удобные обучающие среды типа Squeak с теми же принципами.
Ага! Во-первых, спасибо за наводки.
Задолго это за сколько? ББ сваяли в 94-м. Это реальная система, на которой программирует куча народа.
А во-вторых, как-то для народа паскалеподобный язык поближе будет, чем SmallTalk. Прикинь, физику надо чет свое писать. Что он выберет: Паскаль или SmallTalk? ИМХО, ответ очевиден.
Видимо, потому в России предпочли ББ, а не SmallTalk в некоторых кругах.

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

C>>Эти подходы были известны задооооооооолго до Оберона. В частности, есть до сих пор удобные обучающие среды типа Squeak с теми же принципами.
LVV>Ага! Во-первых, спасибо за наводки.
LVV>Задолго это за сколько? ББ сваяли в 94-м. Это реальная система, на которой программирует куча народа.
Где-то в конце 70-х.

LVV>А во-вторых, как-то для народа паскалеподобный язык поближе будет, чем SmallTalk. Прикинь, физику надо чет свое писать. Что он выберет: Паскаль или SmallTalk? ИМХО, ответ очевиден.
SmallTalk, если его мозг не убит Паскалем.

LVV>Видимо, потому в России предпочли ББ, а не SmallTalk в некоторых кругах.
Ну да, так как мозги преподавателей убиты Паскалем.

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

T>Я тут имею возможность сравнивать производительность одного и того же программиста на хорошо ему знакомой Яве и на малознакомом Хаскеле.

T>Сравнение явно не в пользу Явы.
Расскажи поподробнее. Интересно.

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

LVV>>А во-вторых, как-то для народа паскалеподобный язык поближе будет, чем SmallTalk. Прикинь, физику надо чет свое писать. Что он выберет: Паскаль или SmallTalk? ИМХО, ответ очевиден.
C>SmallTalk, если его мозг не убит Паскалем.

Я думаю, что физик выберет Matlab. Во всяком случае в нашем универе движение идёт в его сторону.

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

LVV>>Задолго это за сколько? ББ сваяли в 94-м. Это реальная система, на которой программирует куча народа.
C>Где-то в конце 70-х.
F? ну да. АланКей жеж...
LVV>>А во-вторых, как-то для народа паскалеподобный язык поближе будет, чем SmallTalk. Прикинь, физику надо чет свое писать. Что он выберет: Паскаль или SmallTalk? ИМХО, ответ очевиден.
C>SmallTalk, если его мозг не убит Паскалем.
LVV>>Видимо, потому в России предпочли ББ, а не SmallTalk в некоторых кругах.
C>Ну да, так как мозги преподавателей убиты Паскалем.
Ну, с таким же успехом можно рекомендовать и Lisp.
Когда-то Дейкстра так же говорил о мозгах, "убитых" Фортраном и Бейсиком.
Я так вижу, что по популярности ББ примерно такое положение относительно С/С++ и клонов занимает, как SmallTalk относительно самого ББ.

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

LVV>Видимо, потому в России предпочли ББ, а не SmallTalk в некоторых кругах.

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

Что до Паскаля в вузах, то я только недавно беседовал с теми кто недавно со студенческой скамьи. Они в один голос выли о том, что преподы отстали на пол века и пичкают их доситорической фигней вроде Паскаля.
Я у них спросил — "а ФП вам преподают". Ответ был "Лисп давали, но только в рамках общего ознакомления с синтаксисом".

В общем, не обижайся но это ваше направление на развитие оберонов и паскалей — это шаг назад и торможение прогресса в нашей области.

Как не прискорбно но Smalltolk 80 был в сто раз современнее сегодняшнего Паскаля/Оберона. Я уже не говорю о старичке Лиспе и современных языках: Scala, Haskell, Nemerle. В них действительно есть чему поучиться. И от их знания будет реальная польза на практике. А от того что у преподавателя в текстовом редакторе кнопочки есть никому ни тепло, ни холодно.

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

LVV>>>Видимо, потому в России предпочли ББ, а не SmallTalk в некоторых кругах.
C>>Ну да, так как мозги преподавателей убиты Паскалем.
LVV>Ну, с таким же успехом можно рекомендовать и Lisp.

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

LVV>Когда-то Дейкстра так же говорил о мозгах, "убитых" Фортраном и Бейсиком.

Ну, дык это тоже самое. Да и языки на сегодня почти клонами выглядят.

LVV>Я так вижу, что по популярности ББ примерно такое положение относительно С/С++ и клонов занимает, как SmallTalk относительно самого ББ.

Откуда такая информация? Я об использовании ББ вашего, только от вас (перподавателей) и слышу.

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

LVV>>>Тут одного языка мало — нужно разрабатывать сразу среду с языком.
LVV>>>Оригинальный подход к среде с языком сделали Виртовские ученики — разработка BlackBox очень не стандартна.

VD>>Это что же там нового появилось?
LVV>Насчет нового не знаю, я только в этом годе стал пользовать 1.5. Но народ ваяет 1.6 и переносит ее под Linux.

А тогда что понимать под "очень не стандартна"? И зачем она такая нестандартность нужна, если она ничего нового не дает?

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

LVV>>Видимо, потому в России предпочли ББ, а не SmallTalk в некоторых кругах.
VD>Этот вывод из каких соображений сделан?
VD>Ну, где сейчас в России Паскаль распространен?
Да я на Оберонском форуме пообщался. Там народ разнообразный. Из Москвы, Орла, Новосибирска, Вологды.
Народ вполне так себе пишет на ББ. А наши спутники — на виртовских Модулах летают.
VD>Что до Паскаля в вузах, то я только недавно беседовал с теми кто недавно со студенческой скамьи. Они в один голос выли о том, что преподы отстали на пол века и пичкают их доситорической фигней вроде Паскаля.
VD>Я у них спросил — "а ФП вам преподают". Ответ был "Лисп давали, но только в рамках общего ознакомления с синтаксисом".
Это ты не с теми студентами разговаривал. Поговори с нашими. Вот из блога моего аспиранта, который сейчас нашим же и преподает:

В новом учебном году я веду три “классических” своих дисциплины (.NET программирование, Технологии программирования, Анализ комбинаторных алгоритмов) и одну новую магистерскую “Платформенно-независимые технологии разработки”. Вот, что от них нужно ожидать в плане новшеств.
Анализ комбинаторных алгоритмов.

У меня новый ассистент – Михаил Эрман (это тоже наш выпускник) и я этому рад. Давно хотел с ним поработать и мечта сбылась. Собственно предмет самый классический из всех потому как пойдет уже 7 сезон как я его преподаю. Соответственно настала пора что-то менять.

1. Примеры на лекциях будут приводится на Python 3.1 (алгоритмы) и С++(для описания структур данных). Цель такого необычного в нашем вузе для второго курса лингвистического набора в том, чтобы привлечь внимание к Python и избежать тупого переписывания ряда алгоритмов со слайдов лекции.
2. Количество лабораторных работ расширенно до 10. В комплект вошли лабораторные по вычислительной геометрии и поиску подстрок. Из 10 лабораторных 2 контрольные – т.е. выполняются непосредственно в течении 1 пары. Отставшие сдают это в том же режиме, реализуя другой вариант задания.
3. Предполагается внедрение системы автоматической проверки правильности лабораторных работ. Давно зревшая идея сейчас подкреплена заработавшей час назад очень сырой, но уже системой iLabs Nippel. Возможно также чуть позже будет внедрена проверка решений задач на плагиат.

.NET программирование

Предмет молодой (2ой год), большой и поэтому в этом году читается совершенно по другой схеме. На этой дисциплине у меня тоже появился ассистент – Яна Седова(тоже наша выпускница). И я опять таки очень доволен.

1. В пределах курса изучается 3 языка C# (углубленный), IronPython и F#. Скорее всего во втором семестре будет произведен переход на Visual Studio 2010.
2. Рассматриваются все основные технологии доступа к данным
3. Рассматривается технология WCF
4. Рассматривается программирования для Smart Device (смартфоны и КПК)
5. Лабораторные будут в общей массе сделаны в виде многошаговых заданий. Как на курсах Microsoft. Количество лабораторных приблизительно равно количеству занятий. Все лабораторные предполагаются к выполнению непосредственно в классе.
6. Всячески приветствуется участие в ImagineCup

Технологии программирования
Пока подержу паузу, поскольку предмет будет преподаваться во втором семестре. Тем не менее, буду рад дельным мыслям и предложениям по-этой дисциплине и по всем остальным в комментариях к посту. Не стесняйтесь.

Платформенно-независимые технологии разработки
Годовая магистерская дисциплина. В настоящий момент еще пишу рабочую программу. Однако кратко – дисциплина дает технологический обзор платформ .NET, Java, а также технологий на Python и Ruby.

Буду завершаться, а то уже много букв и поздно. Я жду ваших комментариев и призываю занимать активную жизненную позицию.

Так что скажи всем — пусть идут учиться к нам, а не в Московские и Питерские вузы.
VD>В общем, не обижайся но это ваше направление на развитие оберонов и паскалей — это шаг назад и торможение прогресса в нашей области.
Не согласен. У Оберонов есть свои недостатки. Но направление — правильное. Минимлистское в области традиционной модульно-процедурно--ООП-ориентированной парадигмы. И с повышенной надежностью. Недаром же наши спутники на этом летают.
VD>Как не прискорбно но Smalltolk 80 был в сто раз современнее сегодняшнего Паскаля/Оберона. Я уже не говорю о старичке Лиспе и современных языках: Scala, Haskell, Nemerle. В них действительно есть чему поучиться. И от их знания будет реальная польза на практике. А от того что у преподавателя в текстовом редакторе кнопочки есть никому ни тепло, ни холодно.
Языки интересные. Не спорю, очень полезные для развития мозгов. Как ортогональное направление в программировании. Твою статью о Немерле я распечатал, буду изучать.
Не, дело не в кнопочках. Я долго изучал всякие среды-языки, на чем бы написать обучающую среду для начинающих программеров. И ББ мне наиболее подходит. Там уже практически все есть Пиши модуль и достраивай среду.

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

LVV>Да я на Оберонском форуме пообщался. Там народ разнообразный. Из Москвы, Орла, Новосибирска, Вологды.
LVV>Народ вполне так себе пишет на ББ. А наши спутники — на виртовских Модулах летают.

А я на немерловом форуме пообщался. И народ тоже таки себе пишет на Немерле. Делаем вывод, что вся Россия пишет на Немерле?

LVV>Это ты не с теми студентами разговаривал.

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

LVV>Поговори с нашими. Вот из блога моего аспиранта, который сейчас нашим же и преподает:...
Что же? Не плохо. Только это аспирант. Он как раз из тех кто жалуется. Те с кем я беседовал были тоже аспирантами (некоторые из них).
А что же мы слышим от тебя?

LVV>Так что скажи всем — пусть идут учиться к нам, а не в Московские и Питерские вузы.



VD>>В общем, не обижайся но это ваше направление на развитие оберонов и паскалей — это шаг назад и торможение прогресса в нашей области.
LVV>Не согласен. У Оберонов есть свои недостатки. Но направление — правильное. Минимлистское в области традиционной модульно-процедурно--ООП-ориентированной парадигмы. И с повышенной надежностью. Недаром же наши спутники на этом летают.

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

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

А что до парадигм, то сейчас уже стало отчетливо видно, что современному программисту кроме процедурного и ОО- программирования нужно еще изучать функциональное программирование. И где оно в этом вашем ББ?

VD>>Как не прискорбно но Smalltolk 80 был в сто раз современнее сегодняшнего Паскаля/Оберона. Я уже не говорю о старичке Лиспе и современных языках: Scala, Haskell, Nemerle. В них действительно есть чему поучиться. И от их знания будет реальная польза на практике. А от того что у преподавателя в текстовом редакторе кнопочки есть никому ни тепло, ни холодно.
LVV>Языки интересные. Не спорю, очень полезные для развития мозгов. Как ортогональное направление в программировании.

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

LVV>Твою статью о Немерле я распечатал, буду изучать.

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

LVV>Не, дело не в кнопочках. Я долго изучал всякие среды-языки, на чем бы написать обучающую среду для начинающих программеров. И ББ мне наиболее подходит. Там уже практически все есть Пиши модуль и достраивай среду.

Там нет функционального программирования и нет метапрограммирования. А без этого не и не будет современного программиста.

Собственно ББ как этап — это наверно не плохо. Но я так и не услышал от тебя, что кроме него будет еще Хаскель, Лисп, ОКамл, Скала или скажем Немерле, т.е. языки поддерживающие ФП и МП.

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

LVV>>Народ вполне так себе пишет на ББ. А наши спутники — на виртовских Модулах летают.
VD>А я на немерловом форуме пообщался. И народ тоже таки себе пишет на Немерле. Делаем вывод, что вся Россия пишет на Немерле?
Да, согласен. Похожу еще и по Смолтоковским.
LVV>>Поговори с нашими. Вот из блога моего аспиранта, который сейчас нашим же и преподает:...
VD>Что же? Не плохо. Только это аспирант. Он как раз из тех кто жалуется. Те с кем я беседовал были тоже аспирантами (некоторые из них).
Да он-то как раз не жалуется. Кагда он заканчивал в 2003 году, мы как раз Дотнет 2003 в классы поставили. Так что наша кафедра всегда нос по ветру держала. Естественно, невозможно бежать впереди Микрософта, поэтому Додиез он уже осваивал сам в нашем же отделе АСУ.
VD>А что же мы слышим от тебя?
А от меня вы слышите, что я ищу систему, в которой с наименьшими затратами смогу написать обучающую систему по программированию. И пока ББ мне наиболее подходит. Но это не значит, что я собираюсь ставить двойки за незнание ББ и Оберона. Хотя некоторые вещи мне там очень нравятся. А некоторые — не очень. Как, собственно, в любом языке.
VD>Скажу только, что ваш этот оберонопаскаль — это даже не сегодняшний день. Это день вчерашний.
VD>Что до минимализма, то оберонам до лиспа никогда не добраться. Что может быть минимальнее двух скобок и идентификатора?
Ну, сэтим не поспоришь. Но и лисп уступает в минимализме Forth'у. Но парадигма программирования у них другая. А в традиционной парадигме, к которой ПРИВЫКЛИ прикладные программеры, Оберон минимален.
VD>А что до парадигм, то сейчас уже стало отчетливо видно, что современному программисту кроме процедурного и ОО- программирования нужно еще изучать функциональное программирование. И где оно в этом вашем ББ?
Да, с этим я согласен. ФП сейчас рулит. Потому и включили Фадиез в изучение. А я подумаю — и в обучающей среде таки и состряпаю...
VD>>>Как не прискорбно но Smalltolk 80 был в сто раз современнее сегодняшнего Паскаля/Оберона.
Да ИМХО он просто свое время опередил.
LVV>>Твою статью о Немерле я распечатал, буду изучать.
VD>Кстати, очень интересно было бы послушать мнение. Еще лучше было бы если ты попробовал подсунуть это дело молодым орлам. Интересно насколько они смогут понят написанное. А то тут большей частью обитают те кто и так все знает.
Дам обязательно! Пообсуждаем тут.
VD>Там нет функционального программирования и нет метапрограммирования. А без этого не и не будет современного программиста.
На оберон-форуме неоднократно возникали темы об отсутствии в Обероне шаблонов. Дык Легалов на SoftCraft предложил вполне себе Оберон с шаблонами.
VD>Собственно ББ как этап — это наверно не плохо. Но я так и не услышал от тебя, что кроме него будет еще Хаскель, Лисп, ОКамл, Скала или скажем Немерле, т.е. языки поддерживающие ФП и МП.
Хаскел, наверно, да. Скала — тоже, наверное, да.
Кстати, народ, который в ББ с 92 года сидит (прикинь, 15 лет уже!) очень ставит в заслугу стабильность среды. Говорят, задолбали Микрософты со своими нововведениями: не успеешь нормально освоить одну технологию — они предлагают следующую, еще более обширную, универсальную и более сложную. И считают такое положение дел только способом выкачивать из народа бабки. И я тут склонен скорее согласиться, чем нет.
Ибо модуль в ББ+КП — он как был модулем, так и остался. И является одновременно и компонентом в смысле COM, и библиотекой в смысле DLL. И все в рамках одной среды и одного языка. Нет необходимости изучать кучу технологий и потом как-то их стыковать. ИМХО ББ играет роль индивидуальной операционной системы. Как-то так. Стабильной, надежной. Работает быстро. И позволяет выйти во внешний мир, то есть создать ПО, например, под Windows, работающее без ББю Что еще прикладнику надо?

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

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

T>>Я тут имею возможность сравнивать производительность одного и того же программиста на хорошо ему знакомой Яве и на малознакомом Хаскеле.

T>>Сравнение явно не в пользу Явы.
EC>Расскажи поподробнее. Интересно.

Товарищ делал на Хаскеле описание процессорных ядер, из которых потом создавался код интерпретаторов.

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

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

Далее ему надо было сделать оптимизацию схемы. Он выбрал Яву, поскольку был выбор. Так мы полторы недели только обсуждали структуры данных.

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

LVV>Ну, сэтим не поспоришь. Но и лисп уступает в минимализме Forth'у. Но парадигма программирования у них другая. А в традиционной парадигме, к которой ПРИВЫКЛИ прикладные программеры, Оберон минимален.

Лисп поддерживает почти все существующие парадигмы (за исключением логического программирования). И по минимализму он вряд ли уступет даже форту.

LVV>Да, с этим я согласен. ФП сейчас рулит. Потому и включили Фадиез в изучение. А я подумаю — и в обучающей среде таки и состряпаю...

Вопрос в том на каком уровне все будет преподноситься. Те ребята с которыми я разговаривал как раз жаловались на поверхность обучения. Преподавать ФП и на C# 3.0 можно. Важно уделить этому достаточно времени и чтобы учителя сами понимали предмет.

VD>>Там нет функционального программирования и нет метапрограммирования. А без этого не и не будет современного программиста.
LVV>На оберон-форуме неоднократно возникали темы об отсутствии в Обероне шаблонов. Дык Легалов на SoftCraft предложил вполне себе Оберон с шаблонами.

Шаблоны к ФП не имеют никакого отношения. К тому же шаблоны в том виде в каком они есть в С++, например, противоречат КООП. Так что Оберону нужны скорее дженерики.

VD>>Собственно ББ как этап — это наверно не плохо. Но я так и не услышал от тебя, что кроме него будет еще Хаскель, Лисп, ОКамл, Скала или скажем Немерле, т.е. языки поддерживающие ФП и МП.
LVV>Хаскел, наверно, да. Скала — тоже, наверное, да.

Хм. F# — это ОКамл . Остаются два самых мощных языка — Лисп и Немерле — так как только они полноценно поддерживают метапрограммирование (МП). Что же их то по боку? На мой взгляд как раз будущее за МП. Так что если вы его не включите в программу (хоть в каком-то виде), то ваши выпускники к моменту выпуска все равно будут вынуждены догонять.

LVV>Кстати, народ, который в ББ с 92 года сидит (прикинь, 15 лет уже!) очень ставит в заслугу стабильность среды. Говорят, задолбали Микрософты со своими нововведениями: не успеешь нормально освоить одну технологию — они предлагают следующую, еще более обширную, универсальную и более сложную. И считают такое положение дел только способом выкачивать из народа бабки. И я тут склонен скорее согласиться, чем нет.

А реальные программисты ругают МС за то что они осторожничают и за то, что делают ошибки связанные с отсутвием в прошлом научного видения развтия языков и платформы.
Так что ваш народ просто стареет. За 15 лет не так уж много нового выпустил тот самый Майрософт.

LVV>Ибо модуль в ББ+КП — он как был модулем, так и остался.

Ага. Лиспу 50 лет и он по прежнему Лисп.

LVV>И является одновременно и компонентом в смысле COM, и библиотекой в смысле DLL. И все в рамках одной среды и одного языка.

Это так для любого КООЯ.

LVV>Нет необходимости изучать кучу технологий и потом как-то их стыковать.

Изучать нужно не меньше чем везде. А вот на практике Оберон точно никто применять не будет.
Учить же меньше нужно только потому, что Оберон застрял в прошлом веке, а программистское сообщество движется вперед.

LVV> ИМХО ББ играет роль индивидуальной операционной системы. Как-то так. Стабильной, надежной. Работает быстро. И позволяет выйти во внешний мир, то есть создать ПО, например, под Windows, работающее без ББю Что еще прикладнику надо?

Ему нужно все остальное. А вот эта местячковая среда ему как раз не нужна. Да и нет в ней ничего замечательного. Все это уже было в том же Смолтоке, но практика показала, что для людей это все не актуально.

Если же брать именно студентов, то им нужно совместить две вещи:
1. Быть как можно ближе к жизни.
2. Изучить как можно больше теории в области компьюетных наук.

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

Если брать именно работающих программистов, то им нужно:
1. Распространенность, т.е. нужно иметь возможность найти работу на некотором языке.
2. Удобство. Тут как раз поддержка все парадигм и т.п.
3. Наличие современных средств разработки: IDE c рефакторингом, подсвткой, навигацией и т.п. Средства проектирования. Средства контроля версий...

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

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

LVV>Не согласен. У Оберонов есть свои недостатки. Но направление — правильное. Минимлистское в области традиционной модульно-процедурно--ООП-ориентированной парадигмы. И с повышенной надежностью. Недаром же наши спутники на этом летают.
Пожалуйста сравни надежность обероновских программ с надежностью программ вот на этом языке
http://www.impredicative.com/ur/
И демки обязательно посмотри.
http://www.impredicative.com/ur/demo/

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

VD>Если же брать именно студентов, то им нужно совместить две вещи:
VD>1. Быть как можно ближе к жизни.
VD>2. Изучить как можно больше теории в области компьюетных наук.

VD>И тут Оберон совсем никуда не годится.

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

на мой взгляд, в обучении нужно разделить две части — изучение концепций и практические вещи. концепции давать на простых, концептуальных языках. если мы хотим изучить ФП — взять ml (а ещё1 лучше — язык из тьюринговской лекции Бэкуса). компонентное программирование — оберон. ооп — яву. и т.д.

и вот поняв каждую из этих концепций саму по себе, дальше уже можно давать ему коктейль Молотова типа современного .net. так чтобы для него это уже выглядело не как большой чёрный ящик с жутко запутанным содержимым внутри, а прсто набор таких-то и таких-то концепций, соединённых вместе. и на следующий большой чих со стороны грандов, типа появления того же f#, он мог спокойно реагировать — "а, решили скрестить ооп с фп? ну, ничего нового в этом мире"

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

LVV>>Не согласен. У Оберонов есть свои недостатки. Но направление — правильное. Минимлистское в области традиционной модульно-процедурно--ООП-ориентированной парадигмы. И с повышенной надежностью. Недаром же наши спутники на этом летают.
WH>Пожалуйста сравни надежность обероновских программ с надежностью программ вот на этом языке
WH>http://www.impredicative.com/ur/

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

Но, да. На его фоне Оберон — это дырявое корыто с ограниченной функциональностью. Только на его фоне и Хаскель с Немерлом курят во многих случаях.

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

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

VD>Ну, это не совсем честно. Все же Ur новорожденный. Это полнейший хайтек на сегодня.
Просто обероновцы постоянно говорят что оберон супернадежен. Вот я им и показал что они застряли мягко говоря в каменном веке.

VD>К тому же он специализирован (заточен только на веб).
Основа языка там вполне универсальна. Но реализация действительно заточено под веб. Хотя ее можно перезаточить и под другие задачи.

VD>Но, да. На его фоне Оберон — это дырявое корыто с ограниченной функциональностью. Только на его фоне и Хаскель с Немерлом курят во многих случаях.
Ну так чего мелочиться то?

VD>Проблема в том, что пока что он нигде не используется и совершенно не имеет инфраструктуры. Посему совершенно не ясно, что будет если применить его на практике.
Ну если прямо в таком виде в котором он есть то для простеньких сайтов пойдет.
Но если допилить при помощи человека который хорошо понимает проблемы серверов то получиться убийца ваще всего.
Я в принципе могу. Но мне это не особо интересно. Хотя если найдется тот кто заплатит я могу подумать.

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

T>Иными словами, higher-kinded types не позволяют эмулировать даже базовые возможности классов типов Хаскеля.
T>Тем временем Хаскель ушёл ещё дальше.

Adriaan утверждает, что в Scala тоже можно сделать вещи, невыразимые в Haskell:

Your example does not type check because it imposes a bound on the higher-order type parameter of the Monad's type constructor that is stricter than what was originally declared. Our paper on type constructor polymorphism explains how to do this is Scala. By the way, this is impossible in Haskell. You'd need something like abstraction over type class contexts.

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

LVV>Кстати, народ, который в ББ с 92 года сидит (прикинь, 15 лет уже!) очень ставит в заслугу стабильность среды. Говорят, задолбали Микрософты со своими нововведениями: не успеешь нормально освоить одну технологию — они предлагают следующую, еще более обширную, универсальную и более сложную.

Это очень хорошо характеризует этот народ. И с таким народом нам не по пути.

Здравствуйте, LaptevVV, Вы писали:
LVV>Да, согласен. Похожу еще и по Смолтоковским.
Пусть сначала на Обероне родят GemStone.

VD>>>>Как не прискорбно но Smalltolk 80 был в сто раз современнее сегодняшнего Паскаля/Оберона.
LVV>Да ИМХО он просто свое время опередил.
Если бы не зверские цены в своё время на лицензии, то сейчас никаких паскалей бы вообще никто не знал.

Здравствуйте, LaptevVV, Вы писали:
LVV>Кстати, народ, который в ББ с 92 года сидит (прикинь, 15 лет уже!) очень ставит в заслугу стабильность среды.
Читать ли это как "Последние 15 лет ББ существенно не менялся"?

Здравствуйте, LaptevVV, Вы писали:
LVV>Мне, например, очень импонирует, что я в одном и том же окне пишу текст лекции и тут же в этом же тексте пишу программу, которую могу оттранслировать и тут же запустить.
Кстати, а ты не интересовался literate programming? Ибо как только я столкнулся с желанием оформить программу со сравнительно большим объемом поясняющего текста (по сути близко по духу к некоторым лекциям) — как-то literate programming на горизонте всплыл. Не знаю, близко я этого дела не касался, но идея вроде хороша.

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

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

LVV>>Не согласен. У Оберонов есть свои недостатки. Но направление — правильное. Минимлистское в области традиционной модульно-процедурно--ООП-ориентированной парадигмы. И с повышенной надежностью. Недаром же наши спутники на этом летают.
WH>Пожалуйста сравни надежность обероновских программ с надежностью программ вот на этом языке
WH>http://www.impredicative.com/ur/
WH>И демки обязательно посмотри.
WH>http://www.impredicative.com/ur/demo/
Thank you, БОЛЬШОЕ СПАСИБО, КАТТА РАХМАТ!!!!!!
Обязательно посмотрю — руководство я уже скатал.
Только пока не найду, когда он разработан был.
Но название, конечно, классное!

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

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

LVV>>Кстати, народ, который в ББ с 92 года сидит (прикинь, 15 лет уже!) очень ставит в заслугу стабильность среды. Говорят, задолбали Микрософты со своими нововведениями: не успеешь нормально освоить одну технологию — они предлагают следующую, еще более обширную, универсальную и более сложную.
AVK>Это очень хорошо характеризует этот народ. И с таким народом нам не по пути.
Знаешь, а меня тоже достает смена версий. Особенно в Офисе. Тут я абсолдютно согласен с народом — Микрософт просто выкачивает бабло из пользователей.
В программировании тоже не все гладко. С появлением Дотнета это как-то не так остро. А вот COM-технология — это тихий ужас! А когда народ корячился и перескакивал с технологии на технологию — оберонцы с 92 года сидели в компонентном программировании и горя не знали. И переучиваться не пришлось. Все стабильно и работает.
И кстати, иногда новая технология выглядит чисто шашечками. Как и новый язык.
Это примерно так же, как автомобильные компании изощряются: и вот это еще можно, и вот это и то, и вот это. А мне это нифига не нужно, мне ЕХАТЬ надо. А я вынужден за эти нововведения ПЛАЬТИТЬ!

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

S>Здравствуйте, LaptevVV, Вы писали:
LVV>>Да, согласен. Похожу еще и по Смолтоковским.
S>Пусть сначала на Обероне родят GemStone.

VD>>>>>Как не прискорбно но Smalltolk 80 был в сто раз современнее сегодняшнего Паскаля/Оберона.
LVV>>Да ИМХО он просто свое время опередил.
S>Если бы не зверские цены в своё время на лицензии, то сейчас никаких паскалей бы вообще никто не знал.
То же самое можно сказать про С?
Это две равнозначные ветки появились одновременно.

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

MC>Здравствуйте, LaptevVV, Вы писали:
LVV>>Кстати, народ, который в ББ с 92 года сидит (прикинь, 15 лет уже!) очень ставит в заслугу стабильность среды.
MC>Читать ли это как "Последние 15 лет ББ существенно не менялся"?
Я не знаю — у Ткачева надо спросить. Это тот, который про обучение программированию доклад сделал (я его тут постил).

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

S>>Если бы не зверские цены в своё время на лицензии, то сейчас никаких паскалей бы вообще никто не знал.
LVV>То же самое можно сказать про С?
Вряд ли. С появился лет на 15 раньше smalltalk, и до сих пор занимает совершенно другую нишу, чем Оберон, джава, дотнет, или лисп. Другого типизированного ассемблера, в общем-то, нет.
LVV>Это две равнозначные ветки появились одновременно.
Ветки чего? По-моему, кто-то очень сильно путает много чего много с чем другим.

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

MC>Здравствуйте, LaptevVV, Вы писали:
LVV>>Мне, например, очень импонирует, что я в одном и том же окне пишу текст лекции и тут же в этом же тексте пишу программу, которую могу оттранслировать и тут же запустить.
MC>Кстати, а ты не интересовался literate programming? Ибо как только я столкнулся с желанием оформить программу со сравнительно большим объемом поясняющего текста (по сути близко по духу к некоторым лекциям) — как-то literate programming на горизонте всплыл. Не знаю, близко я этого дела не касался, но идея вроде хороша.
Я тоже близко не касался, но на сайты ходил. Еще раз посмотрю.
Но еще раз хочется кое-что высказать.
Я с С++ знаком с 91 года — когда вышла первая книжка Страуструпа. В 92 я уже программировал на С++ в среде Борланд 2.0. И с тех пор практически вся моя деятельность была с С++ связана. Я очень давно веду у нас в универе курс по ООП. На С++, естественно! Стал писать книжки для студентов по своей дисциплине: сборник и учебное пособие — изданы в издательстве Питер. Постоянно хожу по сети и интересуюсь новинками, чтобы студентам рассказывать.
Меня нельзя назвать зеленым новичком, которому шашечки очень интересны. Хотя и я в молодости этим болел.
Но последнее время — уже года три-четыре — меня не покидает чувство, что как-то уж очень сложно все. Особенно при применении помимо языка еще и разных дополнительных технологий. И хотелось для новичков обучающую среду сваять — просто мне надоело отвечать из года в год на одни и те же вопросы. Я стал смотреть и другие языки и среды: PERL, Ruby, Haskell. Понятно, что все посмотреть невозможно. Но вот нарвался на ББ.
И мне это — понравилось. Сочетание среды и языка.
Вот сейчас, например, я немного ковыряюсь в DieHard (это сборник тестов для датчиков случайных чисел Марсальи). Есть две версии — на С и на Фортране. Я перевожу на Компонентный паскаль в ББ.
Там нужно сгенерировать большой файл случайных чисел — порядка миллиона. И потом этот файл подавать на вход тестировщика.
Нефиг делать — и на С, и на Фортране. Но я поставил себя на место НЕПРОГРАММИСТА-инженера, которому нужно оттестировать свой датчик. И ощутил, что в ББ это как-то удобнее. Я не вылезу из среды. Мой датчик сгенерирует миллион чисел в хранилище (есть такое в ББ) или даже просто в другой документ ББ (просто в новом окне выведетя миллион чисел). И я опять же, не выходя из ББ это хранилище (или документ) — скормлю тестировщику.
Да, вы, конечно скажете, что все это легко сделать и в той среде, и в этой и т.д.
Мне тоже легко — я умею пользоваться дотнетом.
А кто не умеет? Или возможности нет — контора не покупает дотнет?
Скажете — можно на Яве, она свободна, да еще с Эклипсом. Но сравнив Яву и ББ с КП я ОДНОЗНАЧНО выбираю КП из-за объема изучения. Язык — МАЛЕНЬКИЙ, и синтаксис его знакомый (практически все инженеры когда-то изучали паскаль). Среда — МАЛЕНЬКАЯ и РАСШИРЯЕМАЯ. Причем, для расширения нет необходимости изучать еще один язык.
Помотрев, имеет ли среда связи с внешним миром (можно ли с помощью нее создавать независимые приложения, и можно ли подключать DLL из виндовс), работает ли с БД, умеет ли окошки стряпать и позволяет ли простую графику, я окончательно утвердился в мысли, что это ДЛЯ МЕНЯ — самое то.
Естественно, мне не все нравится в Компонентном паскале. И на мой взгляд, кое-чего не хватает.
Но главное свое назначение — мне преподавать надо — она покрывает с лихвой.
В общем, это достаточно сознательный выбор, а не следование рекламе (рекламы-то как раз и нет вообще!)

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

S>>>Если бы не зверские цены в своё время на лицензии, то сейчас никаких паскалей бы вообще никто не знал.
LVV>>То же самое можно сказать про С?
S>Вряд ли. С появился лет на 15 раньше smalltalk, и до сих пор занимает совершенно другую нишу, чем Оберон, джава, дотнет, или лисп. Другого типизированного ассемблера, в общем-то, нет.
Ну, про нишу понятно.
LVV>>Это две равнозначные ветки появились одновременно.
S>Ветки чего? По-моему, кто-то очень сильно путает много чего много с чем другим.
Две синтаксические ветки в процедурных языках: синтаксис С и синтаксис алгола-паскаля.

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

VD>>>>>Как не прискорбно но Smalltolk 80 был в сто раз современнее сегодняшнего Паскаля/Оберона.
LVV>>Да ИМХО он просто свое время опередил.
S>Если бы не зверские цены в своё время на лицензии, то сейчас никаких паскалей бы вообще никто не знал.
Надо сказать, что кроме лицензий у Smalltalk'а были тогда и другие проблемы (как и у Лиспа, кстати). Но это не отменяет тот факт, что Smalltalk 80 и сейчас лучше текущего Оберона.

Здравствуйте, LaptevVV, Вы писали:
S>>Ветки чего? По-моему, кто-то очень сильно путает много чего много с чем другим.
LVV>Две синтаксические ветки в процедурных языках: синтаксис С и синтаксис алгола-паскаля.
Синтаксис вообще ни при чём. Посмотрите на смолток. Мы говорим о семантике.

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

S>Здравствуйте, LaptevVV, Вы писали:
S>>>Ветки чего? По-моему, кто-то очень сильно путает много чего много с чем другим.
LVV>>Две синтаксические ветки в процедурных языках: синтаксис С и синтаксис алгола-паскаля.
S>Синтаксис вообще ни при чём. Посмотрите на смолток. Мы говорим о семантике.
Да, семантика у паскаля и С, появившихся практически одновременно, была "одной крови".
Но если говорить о семантике ООП, то ООП появилось еще раньше — в Симула-67, откуда ее и содрал Страуструп.
В Смоллтоке ООП была доведено до абсолюта: все — объекты.

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

VD>Но, да. На его фоне Оберон — это дырявое корыто с ограниченной функциональностью. Только на его фоне и Хаскель с Немерлом курят во многих случаях.

А что в нем такого уникального?

Здравствуйте, LaptevVV, Вы писали:
LVV>Да, семантика у паскаля и С, появившихся практически одновременно, была "одной крови".
LVV>Но если говорить о семантике ООП, то ООП появилось еще раньше — в Симула-67, откуда ее и содрал Страуструп.
LVV>В Смоллтоке ООП была доведено до абсолюта: все — объекты.
Я в курсе. Речь о том, что старшая речь, помимо "абсолютного ООП", содержала ещё много чего того, чего в обероне и поныне нет.
В частности, там были реализованы замыкания (через которые, собственно, и работает GemStone), а также хотспоттинг (без которого системы с выраженной компонентностью сливают убогим плюсам по производительности).

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

S>Здравствуйте, LaptevVV, Вы писали:
LVV>>Да, семантика у паскаля и С, появившихся практически одновременно, была "одной крови".
LVV>>Но если говорить о семантике ООП, то ООП появилось еще раньше — в Симула-67, откуда ее и содрал Страуструп.
LVV>>В Смоллтоке ООП была доведено до абсолюта: все — объекты.
S>Я в курсе. Речь о том, что старшая речь, помимо "абсолютного ООП", содержала ещё много чего того, чего в обероне и поныне нет.
S>В частности, там были реализованы замыкания (через которые, собственно, и работает GemStone), а также хотспоттинг (без которого системы с выраженной компонентностью сливают убогим плюсам по производительности).
Лан, спасибо за наводки. Пообщаюсь с народом на Оберонах.

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

VD>>Но, да. На его фоне Оберон — это дырявое корыто с ограниченной функциональностью. Только на его фоне и Хаскель с Немерлом курят во многих случаях.

AF>А что в нем такого уникального?

В двух словах, полный статический контроль приложения на стадии компиляции. Гарантия, что скомпилированное приложение не имеет уязвимостей и большей части ошибок. И все это запаковано в весьма простой (по крайней мере, на первый взгляд) вид языка сов строенной поддержкой XML и SQL.

Из уникального там только зависимые типы — эдакое модное направление в компьютерной науке.
Из фишек:
1. Специально разработанная система типов позволяющая осуществлять метапрограммирование на базе специально заточенной под это системы типов.
2. Классы типов как в хаскеле. Они привносят в язык весьма гибкий статический полиморфизм (нечто вроде перегрузки на стероидах или статических интерфейсов).

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

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

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

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

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

WH>>http://www.impredicative.com/ur/

LVV>Только пока не найду, когда он разработан был.

Вчера. Точнее завтра.
В общем, это пока что экспериментальный проект. По нему даже нормальной статьи нет. Только публикации к дисеру.

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

VD>>>>>>Как не прискорбно но Smalltolk 80 был в сто раз современнее сегодняшнего Паскаля/Оберона.
LVV>>>Да ИМХО он просто свое время опередил.
S>>Если бы не зверские цены в своё время на лицензии, то сейчас никаких паскалей бы вообще никто не знал.
LVV>То же самое можно сказать про С?
LVV>Это две равнозначные ветки появились одновременно.

Уверен, что Sinclair говорил про Smalltolk. На него правда цены были ужасные.
Но, я уверен, что дело не в этом. Или не только в этом. В конце девяностых Smalltolk продвигался IBM-ом. Но так и не продвинулся. Тогда на Smalltolk были очень либеральные цены. Толку — 0.
Просто народ не принял этот язык. От части из-за не высокой производительности. От части из-за оторванности от традиций. Отчасти по глупости.

Оберон же не принимают весьма осознанно.

В прочем, если бы его трактовали как ты — как высокоуровенвый ассемблер, эдакую замену С/С++, то может у него и был бы шанс. Но к такому ассемблеру нужно ручное управление пмятью и наличие более высокоуровенвых языков поверх его рантайма. Ведь Обером фактически — это виртуальная машина (как дотнет и ява). А писать все на ассемблере (пусть и высокоуровенвом) согласны не все.

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

VD>>>>>>Как не прискорбно но Smalltolk 80 был в сто раз современнее сегодняшнего Паскаля/Оберона.
LVV>>>Да ИМХО он просто свое время опередил.
S>>Если бы не зверские цены в своё время на лицензии, то сейчас никаких паскалей бы вообще никто не знал.
C>Надо сказать, что кроме лицензий у Smalltalk'а были тогда и другие проблемы (как и у Лиспа, кстати). Но это не отменяет тот факт, что Smalltalk 80 и сейчас лучше текущего Оберона.

Смотря в чем. Как системный язык Smalltolk 80 использовать нельзя, а Оберон можно.

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

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

Ну, справедливости ради надо заметить, что Smalltolk сливает плюсам по любому, а как раз Оберон выглядит весьма на уровне (с учетом, что оптимизирующих компилятор и ЖЦ ему писали преподы и студенты).

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

S>>В частности, там были реализованы замыкания (через которые, собственно, и работает GemStone), а также хотспоттинг (без которого системы с выраженной компонентностью сливают убогим плюсам по производительности).
LVV>Лан, спасибо за наводки. Пообщаюсь с народом на Оберонах.

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

Лучше изучи эти самые замыкания и функции высшего порядка (можно, например, на C# 3.0). Тогда ты и сам все поймешь.

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

VD>Уверен, что Sinclair говорил про Smalltolk. На него правда цены были ужасные.
VD>Но, я уверен, что дело не в этом. Или не только в этом. В конце девяностых Smalltolk продвигался IBM-ом. Но так и не продвинулся. Тогда на Smalltolk были очень либеральные цены. Толку — 0.
VD>Просто народ не принял этот язык. От части из-за не высокой производительности. От части из-за оторванности от традиций. Отчасти по глупости.
Так и хочется сказать: Неисповедимы пути господни!
VD>Оберон же не принимают весьма осознанно.

VD>В прочем, если бы его трактовали как ты — как высокоуровенвый ассемблер, эдакую замену С/С++, то может у него и был бы шанс. Но к такому ассемблеру нужно ручное управление пмятью и наличие более высокоуровенвых языков поверх его рантайма. Ведь Обером фактически — это виртуальная машина (как дотнет и ява). А писать все на ассемблере (пусть и высокоуровенвом) согласны не все.
Вот с этим я согласен. На оберонском форуме часто возникают споры по поводу примитивизма языка. И того нет, и этого нет. И ответ оберонцев всегда один и тот же: если нужно — напиши. Понятно, что не все хотят писать велосипеды. Мне тоже это не нравится. Тут только один способ есть: садится и написывать свою специфическую для своих задач библиотеку (что все оберонцы и делают). После пары лет будешь иметь заточенный под свои задачи нормальный инструментарий.

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

LVV>Знаешь, а меня тоже достает смена версий.

А меня нет.

LVV> Особенно в Офисе.

При чем тут офис?

LVV>И кстати, иногда новая технология выглядит чисто шашечками. Как и новый язык.

А иногда — нет.

LVV>Это примерно так же, как автомобильные компании изощряются: и вот это еще можно, и вот это и то, и вот это. А мне это нифига не нужно, мне ЕХАТЬ надо. А я вынужден за эти нововведения ПЛАЬТИТЬ!

Опять аналогии.

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

LVV>>Лан, спасибо за наводки. Пообщаюсь с народом на Оберонах.
VD>Это примерно тоже самое, что общаться с пятилетним ребенком на тему термодинамики.
VD>Они тупо не знают о чем идет речь.
Не, почему. Некоторые вполне вменяемые. И вполне знающие.
VD>Лучше изучи эти самые замыкания и функции высшего порядка (можно, например, на C# 3.0). Тогда ты и сам все поймешь.
Ну, теоретически-то я знаком. Но практики нет, поэтому сложно.

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

VD>Оберон же не принимают весьма осознанно.
Кстати, вот дополнение к моим постам: мнение одного из оберонцев.

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

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

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

LVV>На оберонском форуме часто возникают споры по поводу примитивизма языка. И того нет, и этого нет. И ответ оберонцев всегда один и тот же: если нужно — напиши.

Глупый ответ. Не достойный людей из науки. Да даже инженера не достойный.
Нельзя "написать" скажем замыкания. Для этого может и средств метапрограммирования не хватить. А в Обероне нет и их. Так что точно нельзя написать.

LVV> Понятно, что не все хотят писать велосипеды. Мне тоже это не нравится. Тут только один способ есть: садится и написывать свою специфическую для своих задач библиотеку (что все оберонцы и делают). После пары лет будешь иметь заточенный под свои задачи нормальный инструментарий.

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

Есть куча вещей которые невозможно заложить в библиотеку.
Решением проблемы могла бы быть мощьная система метапрограммирования (МП). Но она должна быть действительно мощна. С ее помощь должно быть можно серьезно переписывать код. Скажем для введения в язык замыканий система МП должна:
1. Позволять выявлять в коде лябды (специальные синтаксические конструкции описывающие анонимные функции)
2. Переписывать локальный код так чтобы он использовал не локальные переменные, а специально введенные локальные объекты.
3. Позволять программно объявлять новые типы реализующие замыкания.
4. Позволять переписывать код тел функций/методов.

Тоже самое нужно для поддержки сопоставления с образцом и многих других конструкций.

Для реализации скажем алгебраических типов нужно еще уметь менять синтаксис на уровне верхнеуровеных конструкций языка.

На сегодня это не умеет делать толком ни один язык. Ближе всего к идеалу стоят Nemerle и Lisp.
А Оберон — это просто островок для тех кто сошел на обочину индустрии. Люди его развивающие похоже просто не способны понять и принять новые концепции. А без этого язык обречен.

Здравствуйте, VladD2, Вы писали:
VD>Ну, справедливости ради надо заметить, что Smalltolk сливает плюсам по любому,
Ага-ага. Помнится, где-то бегал бенчмарк по виртуальным вызовам. Там оказывалось, что плюсы никак не могут заинлайнить вызов из-за виртуальности; а смолток ухитрялся это сделать.
В итоге call per second у старшей речи был не то, чтобы ниже, а скорее выше, чем у плюсов.
Ну, правда, я не уверен насчёт последнести версии компилятора плюсов, с которым это проверялось. Интел вон спекулятивный инлайнинг нынче умеет делать, если ему PGO-информацию скормить.
VD>а как раз Оберон выглядит весьма на уровне (с учетом, что оптимизирующих компилятор и ЖЦ ему писали преподы и студенты).
Ой, что-то я сомневаюсь, что в обероне сделали хотя бы PGO. А без неё или хотспоттинга порвать статическую линковку крайне трудно. Поэтому ожидаем массовых abstraction penalty для "сильно компонентных" систем. Понятно, что реализовать более-менее приемлемую оптимизацию на уровне одной единицы компиляции в принципе можно.

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

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

LVV>>На оберонском форуме часто возникают споры по поводу примитивизма языка. И того нет, и этого нет. И ответ оберонцев всегда один и тот же: если нужно — напиши.
VD>Глупый ответ. Не достойный людей из науки. Да даже инженера не достойный.
VD>Нельзя "написать" скажем замыкания. Для этого может и средств метапрограммирования не хватить. А в Обероне нет и их. Так что точно нельзя написать.
Здесь обычно ответ такой: не требуется для работы.
LVV>> Понятно, что не все хотят писать велосипеды. Мне тоже это не нравится. Тут только один способ есть: садится и написывать свою специфическую для своих задач библиотеку (что все оберонцы и делают). После пары лет будешь иметь заточенный под свои задачи нормальный инструментарий.
VD>Извини, то ты говоришь полнейшую ересь. Разберись в вопросе и тогда сам поймешь насколько ошибочно твое мнение.
Не, ты не понял. Я не о замыканиях, а вообще о подходе в ББ. Для С++ — писание своей библиотеки это, естественно, нонсенс, ибо есть стандартная. А для ББ — норма, ибо есть только среда и стандарта нет.
VD>Есть куча вещей которые невозможно заложить в библиотеку.
VD>Решением проблемы могла бы быть мощная система метапрограммирования (МП). Но она должна быть действительно мощна. С ее помощь должно быть можно серьезно переписывать код. Скажем для введения в язык замыканий система МП должна:
VD>1. Позволять выявлять в коде лямбды (специальные синтаксические конструкции описывающие анонимные функции)
VD>2. Переписывать локальный код так чтобы он использовал не локальные переменные, а специально введенные локальные объекты.
VD>3. Позволять программно объявлять новые типы реализующие замыкания.
VD>4. Позволять переписывать код тел функций/методов.
VD>Тоже самое нужно для поддержки сопоставления с образцом и многих других конструкций.
VD>Для реализации скажем алгебраических типов нужно еще уметь менять синтаксис на уровне верхнеуровеных конструкций языка.
Да с этим я согласен.
VD>На сегодня это не умеет делать толком ни один язык. Ближе всего к идеалу стоят Nemerle и Lisp.
VD>А Оберон — это просто островок для тех кто сошел на обочину индустрии. Люди его развивающие похоже просто не способны понять и принять новые концепции. А без этого язык обречен.
Может быть. Но для моих локальных проблем ББ подходит как нельзя лучше.
Попробую прототипы ваять. А если пойдет — то попробую перенести в Дотнет.

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

LVV>>>Лан, спасибо за наводки. Пообщаюсь с народом на Оберонах.
VD>>Это примерно тоже самое, что общаться с пятилетним ребенком на тему термодинамики.
VD>>Они тупо не знают о чем идет речь.
LVV>Не, почему. Некоторые вполне вменяемые. И вполне знающие.

ОК. Вот ты лично четко понимаешь что такое, зачем нужны и как реализовать:
1. Функциональный тип.
2. Замыкание.
3. Алгебраические типы данных.
4. Сопоставление с образцом.
?

VD>>Лучше изучи эти самые замыкания и функции высшего порядка (можно, например, на C# 3.0). Тогда ты и сам все поймешь.
LVV>Ну, теоретически-то я знаком. Но практики нет, поэтому сложно.

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

Предлагаю познакомиться с этим концепциями основательно и на практике. Тогда вопрос о реализации этих вещей в виде библиотеки оберона отпадет сам собой.

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

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

LVV>Кстати, вот дополнение к моим постам: мнение одного из оберонцев.
LVV>

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

Ну, что я могу сказать? Ошибочное и приземленное мышление.
Про парадокс Блаба

Автор(ы): Чистяков Влад (VladD2)
Дата: 03.03.2007
Язык программирования Nemerle заинтересовал многих в первую очередь своей мощнейшей подсистемой мак-росов. Однако и без них Nemerle предоставляет ряд су-щественных улучшений по сравнению с традиционными, императивными языками программирования (такими как Java, C# и C++).
Nemerle, кроме традиционного императивного програм-мирования, поддерживает функциональное программи-рование. Это выражается в наличии конструкций, упро-щающих манипуляцию функциями, построение и анализ сложных структур данных и т.п.
К сожалению, если вы не использовали возможности, присущие функциональным языкам ранее, то вам будет трудно оценить, насколько Nemerle может оказаться вам полезным в реальной повседневной работе. Данная статья призвана в неформальной форме продемонс-трировать это.

слыхал?
Вот — это отличный его пример.

LVV>И я с этим согласен.

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

LVV>Фичи должны быть оправданы. Например, усложнением решаемых задач.

Дык они и оправданы. А то что эти оберонисты не понимают этого — проблема именно оберонистов, а не фич или индустрии.

Структурное программирование, ООП и КООП — это замечательно! Но современный вуз обязан давать так же ФП и МП! Обязан!!!
А на Обероне вы точно этому не научите.

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

VD>>Ну, справедливости ради надо заметить, что Smalltolk сливает плюсам по любому,
S>Ага-ага. Помнится, где-то бегал бенчмарк

Бэнчмарков много бегает. Толку с них — 0.
Меж тем язык с дизайном Smalltolk принципиально не может опережать низкоуровневые языки в задачах требующих оптимизации по производительности. Я даже разговаривать на эту тему не хочу. Это такая же ересь как рассуждения о точности предсказаний астрологов.

S>по виртуальным вызовам.

Ага. Никому не нужный, ни чего не говорящий бэнчмарк. Короче, полное очковтирательство.

VD>>а как раз Оберон выглядит весьма на уровне (с учетом, что оптимизирующих компилятор и ЖЦ ему писали преподы и студенты).
S>Ой, что-то я сомневаюсь, что в обероне сделали хотя бы PGO. А без неё или хотспоттинга порвать статическую линковку крайне трудно. Поэтому ожидаем массовых abstraction penalty для "сильно компонентных" систем. Понятно, что реализовать более-менее приемлемую оптимизацию на уровне одной единицы компиляции в принципе можно.

А для тестов тупые алгоритмы того же ЖЦ — идеальное решение. Они тупо не чистят память, не имеют райт-барьера, поколений, и в итоге, выигрывают у более сложных собратьев.

Если же говорить серьезно, то дизайн Оберона отлично подходит для оптимизаций. Это практически типобезопасный С++ без шаблонов. Писать на нем долго и нудно, но написать быстрый софт можно.

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

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

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

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

VD>Меж тем язык с дизайном Smalltolk принципиально не может опережать низкоуровневые языки в задачах требующих оптимизации по производительности. Я даже разговаривать на эту тему не хочу. Это такая же ересь как рассуждения о точности предсказаний астрологов.
Stongtalk таки был быстрым, как и многочисленные типизированные расширения ST.

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

LVV>Здесь обычно ответ такой: не требуется для работы.

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

VD>>Извини, то ты говоришь полнейшую ересь. Разберись в вопросе и тогда сам поймешь насколько ошибочно твое мнение.
LVV>Не, ты не понял. Я не о замыканиях, а вообще о подходе в ББ. Для С++ — писание своей библиотеки это, естественно, нонсенс, ибо есть стандартная. А для ББ — норма, ибо есть только среда и стандарта нет.

Нет. Я как раз понял. Ты жывешь концепциями С++ и Оберона. Потому и не можешь понять мои слова. А они в общем-то очень просты. То о чем я говорю ВООБЩЕ НЕВОЗМОЖНО РЕАЛИЗОВАТЬ в рамках С++ и Оберона.

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

LVV>Может быть. Но для моих локальных проблем ББ подходит как нельзя лучше.
LVV>Попробую прототипы ваять. А если пойдет — то попробую перенести в Дотнет.

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

Оберон пригоден для освоения структурного программирования и для "механического" перехода от них к ООП.
Но это все на что он способен. Никакому инженеру или тем более полноценному программисту это устаревшее чудо и даром не нужно. Так что ваша задача включить в процесс обучения другие языки, на базе которых вы сможете продемонстрировать людям концепции ФП и МП. Ну, а для этого вам самим нужно все это освоить. Так что не зарывайся в это Оберон.

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

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

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

В то же время автор этого Ur-а вроде бы приводит какие-то гарантии завершаемости компиляции.

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

C>Stongtalk таки был быстрым, как и многочисленные типизированные расширения ST.

Stongtalk не Smalltolk. Да и все равно до С ему никогда не добраться.
Ну, а на сегодня и Smalltolk уже выглядит хорошо только на фоне Оберона.

Я же просто заметил, что Оберон весьма производительное решение на форе Smalltolk. И сделал это исключительно из справедливости. Ведь в обучении производительность вообще не нужна.

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

C>>Stongtalk таки был быстрым, как и многочисленные типизированные расширения ST.
VD>Stongtalk не Smalltolk. Да и все равно до С ему никогда не добраться.
VD>Ну, а на сегодня и Smalltolk уже выглядит хорошо только на фоне Оберона.
ST можно рассматривать как красивый минималистичный язык, построенный на идеологии ООП.

VD>Я же просто заметил, что Оберон весьма производительное решение на форе Smalltolk. И сделал это исключительно из справедливости. Ведь в обучении производительность вообще не нужна.
Ну да, согласен.

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

VD>Уверен, что Sinclair говорил про Smalltolk. На него правда цены были ужасные.
Sinclair и остальные говорят о Smalltalk... Или это тоже не важно, но прикольно?

Ну тогда держи: Nemerlo

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

VD>>Уверен, что Sinclair говорил про Smalltolk. На него правда цены были ужасные.
S>Sinclair и остальные говорят о Smalltalk... Или это тоже не важно, но прикольно?
Не трожь нашего VladD2! Без его очепяток он не был бы VladD2!

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

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

VD>>Уверен, что Sinclair говорил про Smalltolk. На него правда цены были ужасные.
S>Sinclair и остальные говорят о Smalltalk... Или это тоже не важно, но прикольно?

S>Ну тогда держи: Nemerlo

А шо? Мне нравится!

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

S>>Ну тогда держи: Nemerlo

VD>А шо? Мне нравится!

Угу у меня тоже сразу в голове украинский гимн зазвучал

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

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

S>>Ну тогда держи: Nemerlo

VD>А шо? Мне нравится!

Дарю

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

VD>А шо? Мне нравится! :))

Например, в сочетании «это ваше Немерлó» :) Или: «закрой Немерлó!» :)

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

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

T>>Иными словами, higher-kinded types не позволяют эмулировать даже базовые возможности классов типов Хаскеля.
T>>Тем временем Хаскель ушёл ещё дальше.

N>Adriaan утверждает, что в Scala тоже можно сделать вещи, невыразимые в Haskell:

N>

N>Your example does not type check because it imposes a bound on the higher-order type parameter of the Monad's type constructor that is stricter than what was originally declared. Our paper on type constructor polymorphism explains how to do this is Scala. By the way, this is impossible in Haskell. You'd need something like abstraction over type class contexts.

Семейства типов эту задачу не решат?

class AMonadContext context a where
    aMonadContext :: Monad m => a -> context (m a) -- a witness of existence.

class AMonad m where
    type Context m
    return :: AMonadContext (Context m) a => a -> m a
    (>>=) :: (AMonadContext (Context m) a,
              AMonadContext (Context m) b) => ...

instance AMonad Set where
    type Context Set = ReqOrder
    ...

instance Ord a => AMonadContext ReqOrder a where
    aMonadContext a = ReqOrder (return a)

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

Общая схема такова: мы создаём класс с параметром-конструктором типов, в котором каждому параметру требуем ассоциировать другой тип, конкретно, проекцию Context. Из проекции Context мы формируем ограничение на хранимый в конструкторе типов аргумент.

Итак, подходит ли это в качестве решения?

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

VD>Ну, что я могу сказать? Ошибочное и приземленное мышление.
VD>Про парадокс Блаба

Автор(ы): Чистяков Влад (VladD2)
Дата: 03.03.2007
Язык программирования Nemerle заинтересовал многих в первую очередь своей мощнейшей подсистемой мак-росов. Однако и без них Nemerle предоставляет ряд су-щественных улучшений по сравнению с традиционными, императивными языками программирования (такими как Java, C# и C++).
Nemerle, кроме традиционного императивного програм-мирования, поддерживает функциональное программи-рование. Это выражается в наличии конструкций, упро-щающих манипуляцию функциями, построение и анализ сложных структур данных и т.п.
К сожалению, если вы не использовали возможности, присущие функциональным языкам ранее, то вам будет трудно оценить, насколько Nemerle может оказаться вам полезным в реальной повседневной работе. Данная статья призвана в неформальной форме продемонс-трировать это.

слыхал?
VD>Вот — это отличный его пример.
Читал, конечно.
LVV>>И я с этим согласен.
VD>Прискорбно. Значит ваш вуз будет плодить тех самых блабов. И совершенно все равно какие языки или платформы вы будете преподавать. Ведь если преподаватель не знаком с концепциями которые предоставляют все эти лиспы, хаскели и т.п., то научить вы людей сможете только оберону, так как любое обучение не выйдет за рамки структурного программирования, ООП и КООП. В прочем, многие вузы и дальше структурного программирования не идут.
Тут как всегда наблюдаем соотношение изменчивость vs стабильность. В промышленности лучше иметь стабильность — на некоторый период времени. Так оно и есть. Потом наступает время изменчивости. Но скачком! Новая технология создает ступеньку. Вот вчера только затопили последний аналоговый Прогресс. А в ИТ изменчивость — это непрерывный процесс. И это не есть хорошо для производства программ.
LVV>>Фичи должны быть оправданы. Например, усложнением решаемых задач.
VD>Дык они и оправданы. А то что эти оберонисты не понимают этого — проблема именно оберонистов, а не фич или индустрии.
Ну, скорее всего, зависит от задач.
VD>Структурное программирование, ООП и КООП — это замечательно! Но современный вуз обязан давать так же ФП и МП! Обязан!!!
VD>А на Обероне вы точно этому не научите.
А мы на Обероне и не учим. А чему учим — ты ж читал мою цитату из блога. И Фадиез там есть.

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

VD>1. Специально разработанная система типов позволяющая осуществлять метапрограммирование на базе специально заточенной под это системы типов.

Звучит, гм, довольно тавтологично

VD>Причем программы в конечном счете транслируются в эффективный (по словам автора) С-код который компилируется с помощью GCC. При этом устраняется большая часть оверхэда вызванного использованием высокоуровенвых абстракций (в плоть до избавления программы от необходимости использовать сборку мусора).

Мощная заявка. А как оно это делает? Особенно интересно про сборку мусора.

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

Где можно почитать в доступной форме, что это такое и как работает?

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

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

Отнимая фичу — надо дать механизм ее реализации — такова суть языка scheme.

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

AF>Где можно почитать в доступной форме, что это такое и как работает?

Ссылки были выше. На сайте есть ряд работ. Основная их проблема — излишняя заформализованность.

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

VD>Основная их проблема — излишняя заформализованность.

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

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

N>Теперь, тебе надо написать функцию Map0, которая будет абстрагироваться от конкретного типа коллекции, и вызывать у нее метод Map, передав ей функцию (_ -> 0), которая устанавливает все элементы коллекции в 0. Для этого все коллекции должны реализовывать общий интерфейс с методом Map. Но вот беда: в рамках обычных дженериков C#, Nemerle или Java такого не сделать — у методов Map совершенно разные сигнатуры.

Разве результат выполнения Map (при вызове на коллекции интерфейсов) не придется все равно приводить к базовому классу?

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

AF>Вот-вот. В этих мануалах черт ногу сломит. Но мне была интересна сама концепция, что это за хитрая система типов. Она же вроде бы не уникальная для этого языка?

Насколько я понял, там поддерживается kind polymorphism, что довольно уникально.

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

AF>Разве результат выполнения Map (при вызове на коллекции интерфейсов) не придется все равно приводить к базовому классу?

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

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

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

T>>Иными словами, higher-kinded types не позволяют эмулировать даже базовые возможности классов типов Хаскеля.
T>>Тем временем Хаскель ушёл ещё дальше.

N>Adriaan утверждает, что в Scala тоже можно сделать вещи, невыразимые в Haskell:

N>

N>Your example does not type check because it imposes a bound on the higher-order type parameter of the Monad's type constructor that is stricter than what was originally declared. Our paper on type constructor polymorphism explains how to do this is Scala. By the way, this is impossible in Haskell. You'd need something like abstraction over type class contexts.

{-# LANGUAGE TypeFamilies, MultiParamTypeClasses, FlexibleContexts, FlexibleInstances, UndecidableInstances, RankNTypes #-}

import Data.Set hiding (map)

class Monad' m where
    return' :: a -> m a
    bind' :: m a -> (a -> m b) -> m b

class Monad''Req rq a where
    requirement :: rq a    -- a witness
    requirement = undefined


class (Monad''Req (ValueReq m) a, Monad''Req (ValueReq m) b) => Monad'' m a b where
    type ValueReq m :: * -> *
    return'' :: a -> m a
    bind'' :: m a -> (a -> m b) -> m b

data Ord a => RequireOrd a = RequireOrd a

instance Ord a => Monad''Req RequireOrd a

bindSet :: (Ord a, Ord b) => Set a -> (a -> Set b) -> Set b
bindSet g q = unions (map q (toList g))

instance (Ord a, Ord b) => Monad'' Set a b where
    type ValueReq Set = RequireOrd
    return'' a = singleton a
    bind'' g q = bindSet g q

checkZero :: Int -> Set Int
checkZero 0 = empty
checkZero n = singleton n

decrement :: Int -> Set Int
decrement n = singleton (n-1)

decCheck :: Set Int -> Set Int
decCheck set = (set `bind''` decrement) `bind''` checkZero

test = decCheck $ fromList [0,1,2,3]

См. также: http://hackage.haskell.org/package/rmonad

A library for restricted monads based on associated datatypes. This allows datatypes such as Set to be made into monads.

Сие позволяет мне заявить, что товарищи из Scala слегка поотстали от жизни в Хаскеле.

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

VD>В общем, то я пока что не могу высказать своего предпочтения, хотя пока что мне кажется использование более мощьной системы типов менее предпочтительным нежели использование хорошей макро-системы (именно в следствии большей прозрачности процесса).
А мне подход с системой типов нравится гораздо больше.
1)Мы в очень широком смысле не можем написать метафункцию не правильно.
2)Метафункция не может порождать не правильный код. Те все ошибки увидит разработчик матафункции, а не пользователь метафункции.
3)Если пользователь метафункции попытается не правильно ее использовать ему об этом расскажет компилятор.
4)Благодоря строгому отделению мух от котлет мы упрощаем сам компилятор.
В том же компиляторе немерла в алгоритме вывода типов есть куча приседаний вокруг макросов. Что явно не идет на пользу и так очень не простому алгоритму вывода типов.
В случае с навороченной системой типов система разваливается на несколько весьма изолированных слоев:
1)Парсер.
Если делать парсер на основе PEG то мы практически бесплатно получаем расширяемый во все стороны парсер.
На этой стадии мы сообщаем программисту об ошибках разбора текста.
Также мы производим переписывание из красивых синтаксических конструкций в вызовы метафункций.
2)Вывод типов. Разрешение перегрузки и тп.
Так как для вывода типов разницы между функцией и метафункцией нет мы получаем серьезное упрощение самой сложной части фронтенда.
Данная стадия основной источник ошибок времени компиляции.
В случае если ошибок компиляции не обнаружено на выходе этой стадии мы получаем дерево которое можно сразу скормить бекенду.
Однако так как по всей видимости для навороченных систем типов построить полный и не противоречивый вывод типов невозможно мы будем вынужденны использовать эвристики.
Как следствие эта стадия может дать неправильное дерево.

Следующие 2 стадии общие для всех фронтендов.
3)Верификатор.
Ага. Так как предыдущая стадия может молча выдать пургу мы проверяем дерево.
Благо верификакор можно создать без всяких эвристик.
Кстати для него тоже нет разницы между кодом и метакодом.
Ошибки на этой стадии трактуются исключительно как ICE.
4)Сериализация дерева в файл.
На этом работа фронтенда заканчивается.
Заметь фронтенд занимается только синтаксическим уровнем метакода (если он вообще есть). На этой стадии метакод не порождают никакого кода.

Теперь бекенд:
5)Десериализация дерева из файла.
6)Верификатор.
Ага. Тот самый что был в пункте 3.
В этот раз мы защищаемся от ошибок при сериализации/десериализации и от намеренных или нет искажений файла.
7)Частичное выполнение.
Именно на этой стадии происходит раскрутка метакода.
Причем все работает по очень простым правилам.
8)Оптимизация.
9)Генерация нативного кода.

Если нам не нужно сохранять модуль на диск стадии 4, 5 и 6 могут быть пропущены.

Также у меня есть подозрение что верификатор полностью или около того можно заменить системой типов. Что было бы гораздо предпочтительнее. И кода нужно будет меньше и количество ICE уменьшится.

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

N>Насколько я понял, там поддерживается kind polymorphism, что довольно уникально.

А можно объяснить идею вкратце?

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

WH>А мне подход с системой типов нравится гораздо больше.
WH>1)Мы в очень широком смысле не можем написать метафункцию не правильно.

Опыт исползования МП в С++ убеждает меня в обратном.
К тому же ошибки бывают разные. Формально правильная функция может генерировать логически неверный код. И как его тогда отлаживать?

WH>2)Метафункция не может порождать не правильный код. Те все ошибки увидит разработчик матафункции, а не пользователь метафункции.

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

WH>3)Если пользователь метафункции попытается не правильно ее использовать ему об этом расскажет компилятор.

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

WH>4)Благодоря строгому отделению мух от котлет мы упрощаем сам компилятор.

А вот на счет строгости вообще большие сомнения. Как раз макра отдаляет все очень хоршо. Макры понятны и очевидны. Есть входные куски кода, есть какие-то еще источники входной информации, есть алгоритм преобразования и есть выходной кода. Все довольно легко отлаживается.

Что будет в случае навороченной системы типов?

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

Можно ли будет порождать из метакода (основанного на вычислениях типов) порождать специализированные сообщения об ошибках?

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

WH>В том же компиляторе немерла в алгоритме вывода типов есть куча приседаний вокруг макросов.

Да, ну? Приведи, плиз, хотя бы один пример.

WH>Что явно не идет на пользу и так очень не простому алгоритму вывода типов.

Исходная посылка не верна. Так что все выводы идут в топку.
А вот то, что система типов у этого чуда будет гораздо навороченнее (при том, что количество поддерживаемых типов и их возможности даже по проще) — это точно.

WH>В случае с навороченной системой типов система разваливается на несколько весьма изолированных слоев:
WH>1)Парсер.
WH>Если делать парсер на основе PEG то мы практически бесплатно получаем расширяемый во все стороны парсер.
WH>На этой стадии мы сообщаем программисту об ошибках разбора текста.
WH>Также мы производим переписывание из красивых синтаксических конструкций в вызовы метафункций.
WH>2)Вывод типов. Разрешение перегрузки и тп.

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

WH>Так как для вывода типов разницы между функцией и метафункцией нет мы получаем серьезное упрощение самой сложной части фронтенда.

Упрощения я не вижу. Усложнение вижу.

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

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

И это тоже. В общем, тут только практика может показать. Есть некоторые "за" и некоторые "против".

WH>Кстати для него тоже нет разницы между кодом и метакодом.
WH>Ошибки на этой стадии трактуются исключительно как ICE.

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

WH>4)Сериализация дерева в файл.
WH>На этом работа фронтенда заканчивается.
WH>Заметь фронтенд занимается только синтаксическим уровнем метакода (если он вообще есть). На этой стадии метакод не порождают никакого кода.

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

Кроме того важно еще как схема компиляции будет уживаться с такими вещами как IDE. Макры уже тяжел подружить с IDE, а метакод на основе типов высшего порядка может вообще быть не совместим с IDE. А может наоборот. Тут без исследований не обойтись. На это уйдут годы.

WH>Теперь бекенд:
WH>5)Десериализация дерева из файла.
WH>6)Верификатор.
WH>Ага. Тот самый что был в пункте 3.
WH>В этот раз мы защищаемся от ошибок при сериализации/десериализации и от намеренных или нет искажений файла.
WH>7)Частичное выполнение.
WH>Именно на этой стадии происходит раскрутка метакода.

Метакод в бэкэнде? А как ты все это отлаживать то будешь?


WH>Также у меня есть подозрение что верификатор полностью или около того можно заменить системой типов. Что было бы гораздо предпочтительнее. И кода нужно будет меньше и количество ICE уменьшится.

Опять же на все подозрения придется убить еще несколько лет (или десятков).

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

Меж тем акры уже изучены и с ними все понятно. Естественно, что склоняешься к тем решениям которые более изучены.
Собственно я не спорю. Я могу быть не прав и все опасения могут быть напрасными. Но времени на их проверки у меня нет.

Приведу один пример.
Ты мне очень красиво расписал как хорош PEG и Packrat. Как и в данном случае сразу (без тестирования или анализа) заявил, что это офигительно и проблем там нет. Пообещал написать построитель парсеров (там типа работы было не много) который выдавал бы офигительно быстрые парсеры. Я уже тогда заметил, что все может быть не так гладко. Ну, и что в итоге? Я изучил теоретическую базу и оказалось, что на практике чистый Packrat имеет никуда не годную производительность. Объем словаря мемоизации становится очень большим и весь пар уходит в возню с ним. Обещанный оптимизированный вариант тобой так и не был написан. Вместо этого ты увлекся еще одной идеей которая сулит еще более крутые бенефиты. Понятно куда я веду?

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

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

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

VD>>Основная их проблема — излишняя заформализованность.

AF>Вот-вот. В этих мануалах черт ногу сломит. Но мне была интересна сама концепция, что это за хитрая система типов. Она же вроде бы не уникальная для этого языка?

http://rsdn.ru/forum/decl/3546753.1.aspx

Автор: palm mute
Дата: 24.09.09

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

LVV>И я с этим согласен.

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

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

VD>Опыт исползования МП в С++ убеждает меня в обратном.
Опыт использования С++ убеждает меня что функции высшего порядка фигня! Посмотри на stl.
Мысль понятна?
В любом случае все последующие апелляции к С++ будут игнорироваться. Ибо язык сильно не той системы.

VD>К тому же ошибки бывают разные. Формально правильная функция может генерировать логически неверный код. И как его тогда отлаживать?
Отладчиком разумеется.
С отладкой тут как раз все будет очень просто.
Так как код не отличим от метакода мы можем отлаживать метакод тем же отладчиком. Для удобства в отладчике будет флажок заглядывать в метакод или не надо.

VD>Где преимущества, так и ограничения. Камил в своей работе посвященной макрам как раз писал о том, что он выбрал работу с нетипизированным АСТ именно потому, что типизированные макры слишком сковывают свободу и в итоге порождают намного более сложные решения при весьма посредственных возможностях.
В данном случае работа идет не с AST.
Тут используется другой метод мета-программирования.

VD>А вот на счет строгости вообще большие сомнения. Как раз макра отдаляет все очень хоршо. Макры понятны и очевидны.
Тебе.
А лично меня очень сильно напрягают совершенно не формализованные потроха компилятора.

VD>Есть входные куски кода, есть какие-то еще источники входной информации, есть алгоритм преобразования и есть выходной кода. Все довольно легко отлаживается.
VD>Что будет в случае навороченной системы типов?
Метакод и код вообще говоря не различимы.
На входе данные и на выходе данные.
Типы и их структура это тоже данные.
Таким образом метафункция это просто код который что-то считает.
Но благодаря частичному выполнению весь оверхед связанный с обсчетом констант вообще и типов в частности исчезает.
Те фактически раскруткой метакода у нас занимается оптимизатор.

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

WH>>В том же компиляторе немерла в алгоритме вывода типов есть куча приседаний вокруг макросов.
VD>Да, ну? Приведи, плиз, хотя бы один пример.
DelayMacro и вся байда которая с этим связана.
Да и на тот же foreach посмотри... сколько там присаданий.

VD>А вот то, что система типов у этого чуда будет гораздо навороченнее (при том, что количество поддерживаемых типов и их возможности даже по проще) — это точно.
Система то будет навороченее но выделенное далеко не факт.

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

WH>>Так как для вывода типов разницы между функцией и метафункцией нет мы получаем серьезное упрощение самой сложной части фронтенда.
VD>Упрощения я не вижу. Усложнение вижу.
Простите но единообразная работа с кодом и метакодом это как ни крути упрощение.

VD>Вот что действительно может быть полезно, так это то что макрам не придется думать о самом выводе типов, что для немерле иногда очень актуально. Но это тоже только предположения.
Совершенно не придется.

VD>И это тоже. В общем, тут только практика может показать. Есть некоторые "за" и некоторые "против".
Так и немерле то и дело попадается на генерации невалидного кода.
Так что это нужно всем компиляторам...

VD>ICE — это ошибка в компиляторе. Неверно предположение программиста писавшего часть кода компилятора, или изменения в другой части компилятора повлиявшее на ту часть в которой возникло ICE. Так что ICE может быть в любом компиляторе (и есть в любом).
Ну да.
Только если верификатор поймал ошибку в сгенерированном компилятором коде то это самое натуральное ICE. Ибо компилятор не должен генерировать неправильный код.
Считай это встроенным в компилятор PEVerify

VD>Кроме того важно еще как схема компиляции будет уживаться с такими вещами как IDE. Макры уже тяжел подружить с IDE, а метакод на основе типов высшего порядка может вообще быть не совместим с IDE. А может наоборот. Тут без исследований не обойтись. На это уйдут годы.
Я думаю что наоборот.

VD>Метакод в бэкэнде? А как ты все это отлаживать то будешь?
См выше.

WH>>Также у меня есть подозрение что верификатор полностью или около того можно заменить системой типов. Что было бы гораздо предпочтительнее. И кода нужно будет меньше и количество ICE уменьшится.
VD>Опять же на все подозрения придется убить еще несколько лет (или десятков).
Не уйдут.
Я даже где то видел статью в которой зависимыми типами проверяли дерево в интерпретаторе.
Тут ровно тоже самое.
Так что это даже не подозрение, а почти 100% уверенность.

VD>Меж тем акры уже изучены и с ними все понятно. Естественно, что склоняешься к тем решениям которые более изучены.
Угу. На foreach посмотри.

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

VD>Приведу один пример.
VD>Ты мне очень красиво расписал как хорош PEG и Packrat.
Я только про PEG писал. С Packrat все было ясно с самого начала.

VD>Как и в данном случае сразу (без тестирования или анализа) заявил, что это офигительно и проблем там нет. Пообещал написать построитель парсеров (там типа работы было не много) который выдавал бы офигительно быстрые парсеры.
Строки давно он матчит. И матчит быстро.
Осталось сделать построение дерева и поддержку левой рекурсии.

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

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

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

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

VD>>Опыт исползования МП в С++ убеждает меня в обратном.
WH>Опыт использования С++ убеждает меня что функции высшего порядка фигня! Посмотри на stl.
WH>Мысль понятна?



WH>В любом случае все последующие апелляции к С++ будут игнорироваться. Ибо язык сильно не той системы.

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

VD>>К тому же ошибки бывают разные. Формально правильная функция может генерировать логически неверный код. И как его тогда отлаживать?
WH>Отладчиком разумеется.

Не...а. Отладчики пока что не умеют отлаживать вычисления в типах. Более того оные проходят в недрах компилятора и выделенной фазы не имеют.

WH>С отладкой тут как раз все будет очень просто.

Не убедил.

WH>Так как код не отличим от метакода мы можем отлаживать метакод тем же отладчиком. Для удобства в отладчике будет флажок заглядывать в метакод или не надо.

А с чего бы это код не отличим от метакода? Ты не забыл, что это не Немерле. В Ur предлагается писать метакод на базе типов высшего порядка. Как я понимаю — это совершенно другой язык нежели прикладной.

VD>>Где преимущества, так и ограничения. Камил в своей работе посвященной макрам как раз писал о том, что он выбрал работу с нетипизированным АСТ именно потому, что типизированные макры слишком сковывают свободу и в итоге порождают намного более сложные решения при весьма посредственных возможностях.
WH>В данном случае работа идет не с AST.

Возможно ты прав. А возможно нет. Без экспериментов и научной базы это не установить.

WH>Тут используется другой метод мета-программирования.

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

VD>>А вот на счет строгости вообще большие сомнения. Как раз макра отдаляет все очень хоршо. Макры понятны и очевидны.
WH>Тебе.
WH>А лично меня очень сильно напрягают совершенно не формализованные потроха компилятора.

Причем тут форматирование?

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

VD>>Есть входные куски кода, есть какие-то еще источники входной информации, есть алгоритм преобразования и есть выходной кода. Все довольно легко отлаживается.
VD>>Что будет в случае навороченной системы типов?
WH>Метакод и код вообще говоря не различимы.

А это хорошо? Да и откуда это следует? Я вот с легкостью понимал, что происходит в примерах этого Ur-а, но когда дошел до метакода, то тихо поплыл и запутался. А я (межуд прочем) в потрахах компилятора таки разобрался (ну, типа не совсем ванька дурак).

WH>На входе данные и на выходе данные.

Это пустые слова. Они и для макросов справедливы. Вопрос только в типе этих данных.

WH>Типы и их структура это тоже данные.
WH>Таким образом метафункция это просто код который что-то считает.

Ну, и макры — это тоже код который что-то считает.

WH>Но благодаря частичному выполнению весь оверхед связанный с обсчетом констант вообще и типов в частности исчезает.
WH>Те фактически раскруткой метакода у нас занимается оптимизатор.

Мне кажется от слов нужно перейти к примерам.

VD>>Можно ли будет заставить систему типов обращаться ко внешним источникам данных?
WH>Нельзя. Но если очень хочется то можно.

Так можно или нельзя? Потому как если нельзя, то в топку.

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

Мне хотелось бы иметь возможность и к БД обратиться из метакода, и таймеру, и к чему я захочу.

WH>В языках с неизменяемыми типами данных в ресурсах можно хранить не только и не столько блобы, а любые неизменяемые структуры данных.

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

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

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

WH>После чего любая функция в том числе метафункция сможет обратиться к этим данным.

Напоминает анекдот когда мужик предложил классный способ бороться с самолетами противника. Когда они подлетают к границе, то переворачиваются и падают. На вопрос как это реализовать он ответил "- Ну, вы же учерые! — Вы идумйте!".

WH>>>В том же компиляторе немерла в алгоритме вывода типов есть куча приседаний вокруг макросов.
VD>>Да, ну? Приведи, плиз, хотя бы один пример.
WH>DelayMacro и вся байда которая с этим связана.

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

WH>Да и на тот же foreach посмотри... сколько там присаданий.

Там кроме того самого DelayMacro никаких приседаний нет. Просто код foreach генерирует специализированный код под разные случаи жизни. Сделано это чтобы удовлетворять спецификацию шарпа в которую заложили много эвристик.
В прочем, ОК. Продемонстрируй как такой макрос будет выглядеть на типах высших порядков и сравним.

VD>>А вот то, что система типов у этого чуда будет гораздо навороченнее (при том, что количество поддерживаемых типов и их возможности даже по проще) — это точно.
WH>Система то будет навороченее но выделенное далеко не факт.

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

VD>>В приведенной ситеме типов перегрузки (не считая классов типов) и сабтайпинг не поддерживается.
WH>Ну так они и в ML не поддерживаются. Но это не мешает немерлу их поддерживать.

А про складывание/перемножение сложности ты слыхал?
Ты почитай с чего начинает автор. Он там в первых строках начинает разговор о невозможности гарантировать окончания компиляции в общем случае и о введении ограничений чтобы это обойти, говорит. Прикрути его изыски к системе типов дотнета и может статься, что этого монстра уже никто никогда не сможет понять или реализовать.

WH>>>Так как для вывода типов разницы между функцией и метафункцией нет мы получаем серьезное упрощение самой сложной части фронтенда.
VD>>Упрощения я не вижу. Усложнение вижу.
WH>Простите но единообразная работа с кодом и метакодом это как ни крути упрощение.

Где там единообразие? Ты даже к ресурсам обратиться не можешь.

VD>>И это тоже. В общем, тут только практика может показать. Есть некоторые "за" и некоторые "против".
WH>Так и немерле то и дело попадается на генерации невалидного кода.

В нем этот код можно материализовать (сгенерировать текст) и посмотреть. А что будем делать с сообщениями об ошибках при обработке "35-го" порядка?

WH>Так что это нужно всем компиляторам...

Ты пробовал ставить и использовать этот самый Ur?

VD>>ICE — это ошибка в компиляторе. Неверно предположение программиста писавшего часть кода компилятора, или изменения в другой части компилятора повлиявшее на ту часть в которой возникло ICE. Так что ICE может быть в любом компиляторе (и есть в любом).
WH>Ну да.
WH>Только если верификатор поймал ошибку в сгенерированном компилятором коде то это самое натуральное ICE. Ибо компилятор не должен генерировать неправильный код.

С макрами все просто. Как бы они не изгалялись в итоге они должны породить нетипизированное АСТ которое уже будет подвергаться типизации. Так что при качественном компиляторе ICE не должно быть. Только жизнь есть жизнь. Ошибки в компиляторе случаются. Плюс, конечно, неограниченная мощь макросов может тупо все сломать ни смотря ни на что.
Но неограниченная немощь тоже плохо. Так что если метакод будет ограничен — это будет очень плохо.
Как я уже говорил, метакод обязан иметь возможность обращаться к внешним ресурсам (пусть и только на чтение), и обязан иметь возможность выдавать сообщения об ошибках.

WH>Считай это встроенным в компилятор PEVerify

Звучит хорошо... в теории.

VD>>Кроме того важно еще как схема компиляции будет уживаться с такими вещами как IDE. Макры уже тяжел подружить с IDE, а метакод на основе типов высшего порядка может вообще быть не совместим с IDE. А может наоборот. Тут без исследований не обойтись. На это уйдут годы.
WH>Я думаю что наоборот.

Что наоборот? Тебе ничего не придется делать и все чудесным образом интегрируется в IDE?

VD>>Опять же на все подозрения придется убить еще несколько лет (или десятков).
WH>Не уйдут.

Где гарантии?

WH>Я даже где то видел статью в которой зависимыми типами проверяли дерево в интерпретаторе.
WH>Тут ровно тоже самое.
WH>Так что это даже не подозрение, а почти 100% уверенность.

"почти 100% уверенность" — это надо запомнить!

VD>>Меж тем акры уже изучены и с ними все понятно. Естественно, что склоняешься к тем решениям которые более изучены.
WH>Угу. На foreach посмотри.

Смотрел. Он есть и работает в 10 раз лучше встроенного в шарп. А где посмотреть на аналог на ЗТ?

VD>>Собственно я не спорю. Я могу быть не прав и все опасения могут быть напрасными. Но времени на их проверки у меня нет.
WH>А я тебе и не предлагаю. Я просто изложил свои соображения на этот счет.

Ну, а что толку с соображений? Ты что-то конкретное предлагаешь?

Пойми, я не спорю, что в этом что-то есть. Но так же я жопой чую, что в это есть куча проблем, а "правильное решение" (с) где-то по середине. Я так же как ты "почти 100% уверен", что без связи с внешним миром МП — это вещь в себе которая никому не нужна.

VD>>Приведу один пример.
VD>>Ты мне очень красиво расписал как хорош PEG и Packrat.
WH>Я только про PEG писал. С Packrat все было ясно с самого начала.

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

VD>>Как и в данном случае сразу (без тестирования или анализа) заявил, что это офигительно и проблем там нет. Пообещал написать построитель парсеров (там типа работы было не много) который выдавал бы офигительно быстрые парсеры.
WH>Строки давно он матчит. И матчит быстро.

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

WH>Осталось сделать построение дерева и поддержку левой рекурсии.

Я пережил бы даже без левой рекурсии. Но мне нужно испытать это дело на реальной грамматике и реальном процессоре.

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

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

Знаешь сколько красивых идей я выбросил (за свою жизнь) только потому, что на практике в них оказалось очень много нюансов? R#-помнишь? И это только верхушка айсберга. Алгоритмов было намного больше.

WH>В любом случае я изначально не считал немерле приделом своих мечтаний. Вернее он и близко там не стоял. Просто под .НЕТ ничего лучше нет.

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

Те же ЗТД — это интересная идея. Весьма перспективная. Но законченной концепции и тем более решения на них нет и не будет ближайшие 5 лет.

Лично мне не нужен язык тольтко потому, что в нем реализованы некие ЗТД. Мне нужен язык решающий мои проблемы как программиста. Если ЗТД помогут мне в этом — замечательно. Если нет, ну и хрен бы с ними. В любом случае они должны решать те проблемы которые нужно решать мне, а не я должен подстраиваться под их ограничения. В общем, дизайн не должен вестись от возможностей. Он должен вестись от потребностей.

VD>>Так вот генерировать красивые идеи читая чужие дисеры — это конечно интересно, но довольно бесполезно.
WH>Меня очень давно не устраивают современные языки. По этому я читаю диссеры и генерирую идеи.

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

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

Так можно всю жизнь прождать.

WH>А пока этого нет я буду читать диссиры, генерировать идеи и скармливать эти идеи общественности. Пусть проверяет.

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

Вот простой вопрос. Если у нас есть макросы, то мы можем оформлять их синтаксис с использованием EBNF (как мы это обсуждали). При этом сложность распознавания синтаксиса перекладывается на механизмы автоматического построения парсеров (встроенного в язык). А как быть с метасистемой построенной на базе ЗТД?