Re: Noop - новый язык для JVM
От: D. Mon Великобритания http://thedeemon.livejournal.com
Дата: 19.09.09 15:14
Оценка: :))) :))) :)
Здравствуйте, nikov, Вы писали:

N>Noop


Кажется, я догадываюсь в какую инструкцию процессора будут компилироваться программы на этом языке.
Re[12]: Noop - новый язык для JVM
От: Cyberax Марс  
Дата: 25.09.09 13:38
Оценка: 5 (2) +3 -1
Здравствуйте, LaptevVV, Вы писали:

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

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

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

SmallTalk, если его мозг не убит Паскалем.

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

Ну да, так как мозги преподавателей убиты Паскалем.
Sapienti sat!
Re[14]: Noop - новый язык для JVM
От: WolfHound  
Дата: 26.09.09 19:43
Оценка: 121 (5)
Здравствуйте, LaptevVV, Вы писали:

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

Пожалуйста сравни надежность обероновских программ с надежностью программ вот на этом языке
http://www.impredicative.com/ur/
И демки обязательно посмотри.
http://www.impredicative.com/ur/demo/
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[4]: Noop - новый язык для JVM
От: nikov США http://www.linkedin.com/in/nikov
Дата: 23.09.09 18:28
Оценка: 91 (5)
Здравствуйте, 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.
Re[21]: Немерло
От: Qbit86
Дата: 28.09.09 08:45
Оценка: 15 (1) :))) :)
Здравствуйте, VladD2, Вы писали:

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


Например, в сочетании «это ваше Немерлó» :) Или: «закрой Немерлó!» :)
Глаза у меня добрые, но рубашка — смирительная!
Re[10]: Noop - новый язык для JVM
От: Cyberax Марс  
Дата: 25.09.09 12:48
Оценка: +5
Здравствуйте, LaptevVV, Вы писали:

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

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

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

См.: "Smalltalk".

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

См.: "Smalltalk".

Эти подходы были известны задооооооооолго до Оберона. В частности, есть до сих пор удобные обучающие среды типа Squeak с теми же принципами.
Sapienti sat!
Re[11]: Noop - новый язык для JVM
От: LaptevVV Россия  
Дата: 25.09.09 13:05
Оценка: :)))
Здравствуйте, Cyberax, Вы писали:

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

Ага! Во-первых, спасибо за наводки.
Задолго это за сколько? ББ сваяли в 94-м. Это реальная система, на которой программирует куча народа.
А во-вторых, как-то для народа паскалеподобный язык поближе будет, чем SmallTalk. Прикинь, физику надо чет свое писать. Что он выберет: Паскаль или SmallTalk? ИМХО, ответ очевиден.
Видимо, потому в России предпочли ББ, а не SmallTalk в некоторых кругах.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[20]: Noop - новый язык для JVM
От: Cyberax Марс  
Дата: 28.09.09 08:34
Оценка: +2 :)
Здравствуйте, samius, Вы писали:

VD>>Уверен, что Sinclair говорил про Smalltolk. На него правда цены были ужасные.

S>Sinclair и остальные говорят о Smalltalk... Или это тоже не важно, но прикольно?
Не трожь нашего VladD2! Без его очепяток он не был бы VladD2!
Sapienti sat!
Re[5]: Noop - новый язык для JVM
От: thesz Россия http://thesz.livejournal.com
Дата: 28.09.09 15:37
Оценка: 22 (2)
Здравствуйте, 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 слегка поотстали от жизни в Хаскеле.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[4]: Noop - новый язык для JVM
От: thesz Россия http://thesz.livejournal.com
Дата: 26.09.09 08:43
Оценка: 3 (2)
Здравствуйте, EvilChild, Вы писали:

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


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


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

EC>Расскажи поподробнее. Интересно.

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

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

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

Далее ему надо было сделать оптимизацию схемы. Он выбрал Яву, поскольку был выбор. Так мы полторы недели только обсуждали структуры данных.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[6]: Noop - новый язык для JVM
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 25.09.09 08:07
Оценка: +1 :)
Здравствуйте, nikov, Вы писали:

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


Потому что в Haskell нет наследования?
Re[14]: Noop - новый язык для JVM
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.09.09 04:58
Оценка: +2
Здравствуйте, LaptevVV, Вы писали:

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

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

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

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


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

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


Откуда такая информация? Я об использовании ББ вашего, только от вас (перподавателей) и слышу.
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[20]: Noop - новый язык для JVM
От: VladD2 Российская Империя www.nemerle.org
Дата: 28.09.09 07:15
Оценка: +2
Здравствуйте, LaptevVV, Вы писали:

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


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

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


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

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

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

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

На сегодня это не умеет делать толком ни один язык. Ближе всего к идеалу стоят Nemerle и Lisp.
А Оберон — это просто островок для тех кто сошел на обочину индустрии. Люди его развивающие похоже просто не способны понять и принять новые концепции. А без этого язык обречен.
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[18]: Noop - новый язык для JVM
От: nikov США http://www.linkedin.com/in/nikov
Дата: 28.09.09 07:38
Оценка: +1 :)
Здравствуйте, VladD2, Вы писали:

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


Тьюринг-полные системы типов обладают тем недостатком, что компилятор вместо выдачи внятной диагностики при ошибке может просто зависнуть.
Re[19]: Noop - новый язык для JVM
От: samius Россия http://sams-tricks.blogspot.com
Дата: 28.09.09 08:31
Оценка: :))
Здравствуйте, VladD2, Вы писали:

VD>Уверен, что Sinclair говорил про Smalltolk. На него правда цены были ужасные.

Sinclair и остальные говорят о Smalltalk... Или это тоже не важно, но прикольно?

Ну тогда держи: Nemerlo
Re[20]: Noop - новый язык для JVM
От: VladD2 Российская Империя www.nemerle.org
Дата: 28.09.09 08:37
Оценка: :))
Здравствуйте, samius, Вы писали:

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


VD>>Уверен, что Sinclair говорил про Smalltolk. На него правда цены были ужасные.

S>Sinclair и остальные говорят о Smalltalk... Или это тоже не важно, но прикольно?

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


А шо? Мне нравится!
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Noop - новый язык для JVM
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 29.09.09 11:03
Оценка: 15 (1)
Здравствуйте, thesz, Вы писали:

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


Если ты выносишь параметр монады в параметры класса, то open functions не нужны, MPTC достаточно:

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

instance (Ord a, Ord b) => Monad Set a b where
    return a = singleton a
    g >>= q = bindSet g q


Это аналог того, что есть в статье

trait BoundedMonad[A <: Bound[A], M[X <: Bound[X]], Bound[X]]


И в статье тоже Set — экземпляр BoundedMonad.

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

Например, по своем решают эту проблему Class families. Правда, по моему это шило на мыло.

А так — сделать из Set монаду (но другую) можно, решения по выносу контекста есть — restricted datatypes, например.

Насчёт того, как авторы поотстали от Haskell — о restricted datatypes я знал, всё остальное — из ссылок в статье
Re[7]: Noop - новый язык для JVM
От: nikov США http://www.linkedin.com/in/nikov
Дата: 24.09.09 13:37
Оценка: 6 (1)
Вот как выглядит настоящая 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) // здесь почему-то не выводятся типы-аргументы
    }
}
Re[17]: Noop - новый язык для JVM
От: VladD2 Российская Империя www.nemerle.org
Дата: 28.09.09 06:38
Оценка: 6 (1)
Здравствуйте, Andrei F., Вы писали:

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


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


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

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

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

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

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

Короче говоря те кто занимается обероном скорее всего просто не поймут о каких материях тут идет речь. Они просто живут в другом мире. Мире железного века, когда ковать уже научились (освоили ООП и КООП), но про ракеты еще не слышали (ФП, МП, зависимые типы).
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Noop - новый язык для JVM
От: nikov США http://www.linkedin.com/in/nikov
Дата: 21.09.09 14:24
Оценка: 4 (1)
Здравствуйте, 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 для этого нужно создавать специальный класс-обертку для такого функционального значения (здесь). А существующие расширения хаскеля поддерживают это на уровне языка.
Re[6]: Noop - новый язык для JVM
От: nikov США http://www.linkedin.com/in/nikov
Дата: 28.09.09 14:10
Оценка: 4 (1)
Здравствуйте, Andrei F., Вы писали:

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


Не придется. Почитай эту статью, в ней несколько примеров, и хорошее объяснение, как это работает.
Re[21]: Noop - новый язык для JVM
От: VladD2 Российская Империя www.nemerle.org
Дата: 28.09.09 17:23
Оценка: 2 (1)
Здравствуйте, Andrei F., Вы писали:

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


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


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


http://rsdn.ru/forum/decl/3546753.1.aspx
Автор: palm mute
Дата: 24.09.09
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Noop - новый язык для JVM
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 23.09.09 20:47
Оценка: 1 (1)
Здравствуйте, nikov, Вы писали:

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


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

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


Не вникал подробно, но sigleton objects от проблем статических полей не избавляют
А вообще, как то по детски там у них все, имхо — ковыряются с мелочами, а на серьезные проблемы ответов не видно. Так языки лет 15-20 назад проектировали.
... << RSDN@Home 1.2.0 alpha 4 rev. 1237 on Windows 7 6.1.7100.0>>
AVK Blog
Re[8]: Noop - новый язык для JVM
От: Cyberax Марс  
Дата: 24.09.09 14:47
Оценка: 1 (1)
Здравствуйте, LaptevVV, Вы писали:

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

Интересно, чего в ней вообще есть нестандартного?
Sapienti sat!
Re[20]: Noop - новый язык для JVM
От: WolfHound  
Дата: 28.09.09 15:46
Оценка: 1 (1)
Здравствуйте, VladD2, Вы писали:

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

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

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

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

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

Также у меня есть подозрение что верификатор полностью или около того можно заменить системой типов. Что было бы гораздо предпочтительнее. И кода нужно будет меньше и количество ICE уменьшится.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[2]: Noop - новый язык для JVM
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 23.09.09 20:10
Оценка: +1
Здравствуйте, 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>>
  • AVK Blog
    Re[13]: Noop - новый язык для JVM
    От: Nuzhny Россия https://github.com/Nuzhny007
    Дата: 25.09.09 20:06
    Оценка: +1
    Здравствуйте, Cyberax, Вы писали:

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

    C>SmallTalk, если его мозг не убит Паскалем.

    Я думаю, что физик выберет Matlab. Во всяком случае в нашем универе движение идёт в его сторону.
    https://elibrary.ru/author_counter.aspx?id=875549
    Re[13]: Noop - новый язык для JVM
    От: LaptevVV Россия  
    Дата: 26.09.09 04:42
    Оценка: -1
    Здравствуйте, Cyberax, Вы писали:

    LVV>>Задолго это за сколько? ББ сваяли в 94-м. Это реальная система, на которой программирует куча народа.

    C>Где-то в конце 70-х.
    F? ну да. АланКей жеж...
    LVV>>А во-вторых, как-то для народа паскалеподобный язык поближе будет, чем SmallTalk. Прикинь, физику надо чет свое писать. Что он выберет: Паскаль или SmallTalk? ИМХО, ответ очевиден.
    C>SmallTalk, если его мозг не убит Паскалем.
    LVV>>Видимо, потому в России предпочли ББ, а не SmallTalk в некоторых кругах.
    C>Ну да, так как мозги преподавателей убиты Паскалем.
    Ну, с таким же успехом можно рекомендовать и Lisp.
    Когда-то Дейкстра так же говорил о мозгах, "убитых" Фортраном и Бейсиком.
    Я так вижу, что по популярности ББ примерно такое положение относительно С/С++ и клонов занимает, как SmallTalk относительно самого ББ.
    Хочешь быть счастливым — будь им!
    Без булдырабыз!!!
    Re[12]: Noop - новый язык для JVM
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 26.09.09 04:55
    Оценка: +1
    Здравствуйте, LaptevVV, Вы писали:

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


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

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

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

    Как не прискорбно но Smalltolk 80 был в сто раз современнее сегодняшнего Паскаля/Оберона. Я уже не говорю о старичке Лиспе и современных языках: Scala, Haskell, Nemerle. В них действительно есть чему поучиться. И от их знания будет реальная польза на практике. А от того что у преподавателя в текстовом редакторе кнопочки есть никому ни тепло, ни холодно.
    http://nemerle.org/Banners/?g=dark
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[16]: Noop - новый язык для JVM
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 26.09.09 12:36
    Оценка: +1
    Здравствуйте, 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 рефакторингом, подсвткой, навигацией и т.п. Средства проектирования. Средства контроля версий...

    Вот и выходит, что ББ не подходит ни для студентов, ни для взрослых программистов.
    Все это, естественно, только мое мнение.
    http://nemerle.org/Banners/?g=dark
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[17]: Noop - новый язык для JVM
    От: BulatZiganshin  
    Дата: 27.09.09 09:36
    Оценка: +1
    Здравствуйте, VladD2, Вы писали:

    VD>Если же брать именно студентов, то им нужно совместить две вещи:

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

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


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

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

    и вот поняв каждую из этих концепций саму по себе, дальше уже можно давать ему коктейль Молотова типа современного .net. так чтобы для него это уже выглядело не как большой чёрный ящик с жутко запутанным содержимым внутри, а прсто набор таких-то и таких-то концепций, соединённых вместе. и на следующий большой чих со стороны грандов, типа появления того же f#, он мог спокойно реагировать — "а, решили скрестить ооп с фп? ну, ничего нового в этом мире"
    Люди, я люблю вас! Будьте бдительны!!!
    Re[16]: Noop - новый язык для JVM
    От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
    Дата: 28.09.09 03:39
    Оценка: +1
    Здравствуйте, LaptevVV, Вы писали:
    LVV>Да, согласен. Похожу еще и по Смолтоковским.
    Пусть сначала на Обероне родят GemStone.

    VD>>>>Как не прискорбно но Smalltolk 80 был в сто раз современнее сегодняшнего Паскаля/Оберона.

    LVV>Да ИМХО он просто свое время опередил.
    Если бы не зверские цены в своё время на лицензии, то сейчас никаких паскалей бы вообще никто не знал.
    ... << RSDN@Home 1.2.0 alpha rev. 677>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    http://rsdn.org/File/5743/rsdnaddict.GIF
    Re[18]: Noop - новый язык для JVM
    От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
    Дата: 28.09.09 05:21
    Оценка: +1
    Здравствуйте, LaptevVV, Вы писали:

    S>>Если бы не зверские цены в своё время на лицензии, то сейчас никаких паскалей бы вообще никто не знал.

    LVV>То же самое можно сказать про С?
    Вряд ли. С появился лет на 15 раньше smalltalk, и до сих пор занимает совершенно другую нишу, чем Оберон, джава, дотнет, или лисп. Другого типизированного ассемблера, в общем-то, нет.
    LVV>Это две равнозначные ветки появились одновременно.
    Ветки чего? По-моему, кто-то очень сильно путает много чего много с чем другим.
    ... << RSDN@Home 1.2.0 alpha rev. 677>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    http://rsdn.org/File/5743/rsdnaddict.GIF
    Re[17]: Noop - новый язык для JVM
    От: Cyberax Марс  
    Дата: 28.09.09 05:51
    Оценка: +1
    Здравствуйте, Sinclair, Вы писали:

    VD>>>>>Как не прискорбно но Smalltolk 80 был в сто раз современнее сегодняшнего Паскаля/Оберона.

    LVV>>Да ИМХО он просто свое время опередил.
    S>Если бы не зверские цены в своё время на лицензии, то сейчас никаких паскалей бы вообще никто не знал.
    Надо сказать, что кроме лицензий у Smalltalk'а были тогда и другие проблемы (как и у Лиспа, кстати). Но это не отменяет тот факт, что Smalltalk 80 и сейчас лучше текущего Оберона.
    Sapienti sat!
    Re[26]: Noop - новый язык для JVM
    От: Cyberax Марс  
    Дата: 28.09.09 07:46
    Оценка: +1
    Здравствуйте, VladD2, Вы писали:

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

    Stongtalk таки был быстрым, как и многочисленные типизированные расширения ST.
    Sapienti sat!
    Re[28]: Noop - новый язык для JVM
    От: nikov США http://www.linkedin.com/in/nikov
    Дата: 29.09.09 14:31
    Оценка: :)
    L>Здравствуйте, nikov, Вы писали:

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


    L>При -Yrecursion ты должен явно задавать максимальную глубину рекурсии.


    L>А демонстрировать чего там

    L>
    L>type T = { def foo(bar: T) }
    L>

    L>

    Ну это не доказательство возможности представления любой рекурсивной функции.
    Ты попробуй написать программу, на которой type checker останавливается только в том случае, если существует четное число, большее 2, не представимое в виде суммы двух простых чисел.
    Re[30]: Noop - новый язык для JVM
    От: nikov США http://www.linkedin.com/in/nikov
    Дата: 29.09.09 15:23
    Оценка: :)
    Здравствуйте, lomeo, Вы писали:

    L>Я и не на типах то такое не напишу.


    Не верю.
    Noop - новый язык для JVM
    От: nikov США http://www.linkedin.com/in/nikov
    Дата: 17.09.09 17:27
    Оценка:
    Разработчики из 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

    Re: Noop - новый язык для JVM
    От: thesz Россия http://thesz.livejournal.com
    Дата: 18.09.09 11:50
    Оценка:
    Здравствуйте, 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

    Это ж ужас!
    Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
    Re: Noop - новый язык для JVM
    От: LaptevVV Россия  
    Дата: 18.09.09 11:58
    Оценка:
    Здравствуйте, nikov, Вы писали:

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


    Пока нет документа с описанием языка — сложно что-то сказать.
    Хочешь быть счастливым — будь им!
    Без булдырабыз!!!
    Re[2]: Noop - новый язык для JVM
    От: nikov США http://www.linkedin.com/in/nikov
    Дата: 18.09.09 13:11
    Оценка:
    Здравствуйте, LaptevVV, Вы писали:

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


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


    Зато на многое можно повлиять.
    Re: Noop - новый язык для JVM
    От: jenyavb  
    Дата: 20.09.09 12:22
    Оценка:
    Здравствуйте, nikov, Вы писали:

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


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

  • Any statics whatsoever
  • Implementation inheritance (subclassing)
  • Primitives
  • Unnecessary boilerplate

  • ... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>
    Re[2]: Noop - новый язык для JVM
    От: achmed Удмуртия https://www.linkedin.com/in/nail-achmedzhanov-9907188/
    Дата: 21.09.09 06:51
    Оценка:
    Здравствуйте, jenyavb, Вы писали:

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


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


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

    J>

    J>

  • Implementation inheritance (subclassing)


  • вместо наследования будет поддержка композиции (агрегации) ProposalForComposition
    с претензией на оригинальность
    Re: Noop - новый язык для JVM
    От: LaPerouse  
    Дата: 21.09.09 09:33
    Оценка:
    Здравствуйте, 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 — самый разумный на сегодняшний день выбор. Она поддерживает ФП в той же степени, что и Хаскель, при этом оставляя место и другим парадигмам. По-большому счету, для большинства задач и явы хватало, скала — просто более хорошая, новая ява, а больше ничего и не нужно.
    Социализм — это власть трудящихся и централизованная плановая экономика.
    Re[2]: Noop - новый язык для JVM
    От: nikov США http://www.linkedin.com/in/nikov
    Дата: 21.09.09 10:09
    Оценка:
    Здравствуйте, LaPerouse, Вы писали:

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


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

    Ну и еще не хватает поддержки rank-N polymorphism на уровне языка (хотя его можно эмулировать).
    Re[3]: Noop - новый язык для JVM
    От: LaPerouse  
    Дата: 21.09.09 13:32
    Оценка:
    Здравствуйте, nikov, Вы писали:

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


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


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


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

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


    Боюсь справшивать что это такое, ну да ладно, вроде жили без него, проживем и далее
    Социализм — это власть трудящихся и централизованная плановая экономика.
    Re: Noop - новый язык для JVM
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 22.09.09 21:09
    Оценка:
    Здравствуйте, nikov, Вы писали:

    N>

    N>Noop says Yes to


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

    Мое мнение — бредовая затея. Цели мутные. Полное ощущение, что люди живут в мире Явы и поняли что в ней что-то в ней не так, но что так и не поняли, так что пытаются прилепить к ней разные "нужные" вещи вроде ослиного хвоста и ластов.
    http://nemerle.org/Banners/?g=dark
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[3]: Noop - новый язык для JVM
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 22.09.09 21:12
    Оценка:
    Здравствуйте, nikov, Вы писали:

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


    А можно на пальцах объяснить — что это такое и с чем едят?
    http://nemerle.org/Banners/?g=dark
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[5]: Noop - новый язык для JVM
    От: nikov США http://www.linkedin.com/in/nikov
    Дата: 23.09.09 18:44
    Оценка:
    Здравствуйте, nikov, Вы писали:

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

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

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

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

    Пусть меня поправят специалисты, если я не прав, но по-моему, в Haskell нет никаких аналогов для подобных констрейнтов.
    Re[5]: Noop - новый язык для JVM
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 23.09.09 18:51
    Оценка:
    Здравствуйте, nikov, Вы писали:

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


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

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

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

    Аналог fmap можно получить средствами метапрограммирования.
    http://nemerle.org/Banners/?g=dark
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[6]: Noop - новый язык для JVM
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 23.09.09 18:54
    Оценка:
    Здравствуйте, nikov, Вы писали:

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


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

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


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


    Остается вопрос — зачем оно все нужно?
    Хаскель мне не нравится в первую очередь своей перенавороченностью. Даже простые вещи в нем имеют ужасающее описание.
    http://nemerle.org/Banners/?g=dark
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[3]: Noop - новый язык для JVM
    От: nikov США http://www.linkedin.com/in/nikov
    Дата: 23.09.09 20:42
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

    J>>
  • Any statics whatsoever

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


    Я думаю, и поля и методы. Наверное, будут делать, как в Scala — встроенные в язык singleton objects.
  • Re[5]: Noop - новый язык для JVM
    От: nikov США http://www.linkedin.com/in/nikov
    Дата: 23.09.09 22:32
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

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


    А вот интересно, на что ты обратил бы внимание, если бы сейчас проектировал высокоуровневый язык общего назначения.
    Re[6]: Noop - новый язык для JVM
    От: nikov США http://www.linkedin.com/in/nikov
    Дата: 23.09.09 22:48
    Оценка:
    Здравствуйте, 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, их можно использовать как типы-аргументы.
    Re[6]: Noop - новый язык для JVM
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 23.09.09 22:52
    Оценка:
    Здравствуйте, nikov, Вы писали:

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


    Это очень сложный вопрос. Во-первых требований очень много, во-вторых у каждого свои задачи, и свои приоритеты. Но если говорить о том, о чем здесь мало спорят — наверное обратил бы внимание на технологичность процесса разработки на этом языке.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1237 on Windows 7 6.1.7100.0>>
    AVK Blog
    Re[7]: Noop - новый язык для JVM
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 24.09.09 13:49
    Оценка:
    Здравствуйте, nikov, Вы писали:

    VD>>3. Как эта штука уживается с наличием типов-значений?

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

    Насколько я знаю это не так. Вэлью-типы тупо оборачиваются (боксятся).
    http://nemerle.org/Banners/?g=dark
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[7]: Noop - новый язык для JVM
    От: LaptevVV Россия  
    Дата: 24.09.09 13:56
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

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


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


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

    Тут одного языка мало — нужно разрабатывать сразу среду с языком.
    Оригинальный подход к среде с языком сделали Виртовские ученики — разработка BlackBox очень не стандартна.
    Хочешь быть счастливым — будь им!
    Без булдырабыз!!!
    Re[8]: Noop - новый язык для JVM
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 24.09.09 14:43
    Оценка:
    Здравствуйте, LaptevVV, Вы писали:

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


    Разумеется. К счастью, сейчас очень часто технологии разрабатываются с оглядкой на дизайн-тайм.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1237 on Windows 7 6.1.7100.0>>
    AVK Blog
    Re[8]: Noop - новый язык для JVM
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 24.09.09 14:53
    Оценка:
    Здравствуйте, LaptevVV, Вы писали:

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

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

    Это что же там нового появилось?
    http://nemerle.org/Banners/?g=dark
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[7]: Noop - новый язык для JVM
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 24.09.09 14:53
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

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


    Это очень расплывчато.
    http://nemerle.org/Banners/?g=dark
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[8]: Noop - новый язык для JVM
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 24.09.09 14:54
    Оценка:
    Здравствуйте, VladD2, Вы писали:

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


    Для раскрытия нужна масса времени.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1237 on Windows 7 6.1.7100.0>>
    AVK Blog
    Re[7]: Noop - новый язык для JVM
    От: nikov США http://www.linkedin.com/in/nikov
    Дата: 25.09.09 09:08
    Оценка:
    Здравствуйте, lomeo, Вы писали:

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


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


    Ну, определенная форма наследования — для классов типов, всё таки есть.
    Кроме того, некое подобие приведения к базовому типу предоставляют экзистенциальные типы (но это уже нестандартный Haskell).
    Re[2]: Noop - новый язык для JVM
    От: thesz Россия http://thesz.livejournal.com
    Дата: 25.09.09 10:02
    Оценка:
    Здравствуйте, 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>при этом оставляя место и другим парадигмам. По-большому счету, для большинства задач и явы хватало, скала — просто более хорошая, новая ява, а больше ничего и не нужно.


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

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

    Сравнение явно не в пользу Явы.
    Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
    Re[3]: Noop - новый язык для JVM
    От: thesz Россия http://thesz.livejournal.com
    Дата: 25.09.09 10:04
    Оценка:
    Здравствуйте, 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.
    Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
    Re[6]: Noop - новый язык для JVM
    От: thesz Россия http://thesz.livejournal.com
    Дата: 25.09.09 10:15
    Оценка:
    Здравствуйте, nikov, Вы писали:

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


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

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

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


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


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


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

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

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

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

    В общем и целом, система типов Хаскеля Тьюринг-полна и там можно выразить всё, что угодно.
    Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
    Re[8]: Noop - новый язык для JVM
    От: lomeo Россия http://lomeo.livejournal.com/
    Дата: 25.09.09 11:37
    Оценка:
    Здравствуйте, nikov, Вы писали:

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

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

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

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

    trait Function1[-T1, +R]

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

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


    Ну, эмулировать наследование мы, конечно, можем. Для этого даже необязательно использовать экзестенциальные типы.
    Re[9]: Noop - новый язык для JVM
    От: LaptevVV Россия  
    Дата: 25.09.09 12:42
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

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


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

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

    И кроме всего прочего, у меня, естественно, имеется возможность выйти из среды в том смысле, что либо подключить стороннюю DLL, либо создать свою собственную DLL для работы без среды в Windows. Можно и exe-модуль создать и работать независимо от среды.
    В общем, мне как преподу она очень импонирует.
    Хочешь быть счастливым — будь им!
    Без булдырабыз!!!
    Re[9]: Noop - новый язык для JVM
    От: LaptevVV Россия  
    Дата: 25.09.09 12:50
    Оценка:
    Здравствуйте, VladD2, Вы писали:

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


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

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

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

    Насчет нового не знаю, я только в этом годе стал пользовать 1.5. Но народ ваяет 1.6 и переносит ее под Linux.
    Хочешь быть счастливым — будь им!
    Без булдырабыз!!!
    Re[3]: Noop - новый язык для JVM
    От: EvilChild Ниоткуда  
    Дата: 25.09.09 18:18
    Оценка:
    Здравствуйте, thesz, Вы писали:

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


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

    Расскажи поподробнее. Интересно.
    now playing: Scsi-9 — Lady Delay
    Re[10]: Noop - новый язык для JVM
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 26.09.09 04:59
    Оценка:
    Здравствуйте, LaptevVV, Вы писали:

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

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

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

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

    А тогда что понимать под "очень не стандартна"? И зачем она такая нестандартность нужна, если она ничего нового не дает?
    http://nemerle.org/Banners/?g=dark
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[13]: Noop - новый язык для JVM
    От: LaptevVV Россия  
    Дата: 26.09.09 05:37
    Оценка:
    Здравствуйте, 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. В них действительно есть чему поучиться. И от их знания будет реальная польза на практике. А от того что у преподавателя в текстовом редакторе кнопочки есть никому ни тепло, ни холодно.
    Языки интересные. Не спорю, очень полезные для развития мозгов. Как ортогональное направление в программировании. Твою статью о Немерле я распечатал, буду изучать.
    Не, дело не в кнопочках. Я долго изучал всякие среды-языки, на чем бы написать обучающую среду для начинающих программеров. И ББ мне наиболее подходит. Там уже практически все есть Пиши модуль и достраивай среду.
    Хочешь быть счастливым — будь им!
    Без булдырабыз!!!
    Re[14]: Noop - новый язык для JVM
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 26.09.09 06:09
    Оценка:
    Здравствуйте, LaptevVV, Вы писали:

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

    LVV>Народ вполне так себе пишет на ББ. А наши спутники — на виртовских Модулах летают.

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

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


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

    LVV>Поговори с нашими. Вот из блога моего аспиранта, который сейчас нашим же и преподает:...

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

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




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

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

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

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

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

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

    LVV>Языки интересные. Не спорю, очень полезные для развития мозгов. Как ортогональное направление в программировании.

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

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


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

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


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

    Собственно ББ как этап — это наверно не плохо. Но я так и не услышал от тебя, что кроме него будет еще Хаскель, Лисп, ОКамл, Скала или скажем Немерле, т.е. языки поддерживающие ФП и МП.
    http://nemerle.org/Banners/?g=dark
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[15]: Noop - новый язык для JVM
    От: LaptevVV Россия  
    Дата: 26.09.09 08:14
    Оценка:
    Здравствуйте, 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, работающее без ББю Что еще прикладнику надо?
    Хочешь быть счастливым — будь им!
    Без булдырабыз!!!
    Re[15]: Noop - новый язык для JVM
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 27.09.09 14:57
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

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

    WH>Пожалуйста сравни надежность обероновских программ с надежностью программ вот на этом языке
    WH>http://www.impredicative.com/ur/

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

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

    Проблема в том, что пока что он нигде не используется и совершенно не имеет инфраструктуры. Посему совершенно не ясно, что будет если применить его на практике.
    http://nemerle.org/Banners/?g=dark
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    йт
    Re[16]: Noop - новый язык для JVM
    От: WolfHound  
    Дата: 27.09.09 16:30
    Оценка:
    Здравствуйте, VladD2, Вы писали:

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

    Просто обероновцы постоянно говорят что оберон супернадежен. Вот я им и показал что они застряли мягко говоря в каменном веке.

    VD>К тому же он специализирован (заточен только на веб).

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

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

    Ну так чего мелочиться то?

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

    Ну если прямо в таком виде в котором он есть то для простеньких сайтов пойдет.
    Но если допилить при помощи человека который хорошо понимает проблемы серверов то получиться убийца ваще всего.
    Я в принципе могу. Но мне это не особо интересно. Хотя если найдется тот кто заплатит я могу подумать.
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[4]: Noop - новый язык для JVM
    От: nikov США http://www.linkedin.com/in/nikov
    Дата: 27.09.09 17:21
    Оценка:
    Здравствуйте, 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.

    Re[16]: Noop - новый язык для JVM
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 27.09.09 21:10
    Оценка:
    Здравствуйте, LaptevVV, Вы писали:

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


    Это очень хорошо характеризует этот народ. И с таким народом нам не по пути.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1237 on Windows 7 6.1.7100.0>>
    AVK Blog
    Re[16]: Noop - новый язык для JVM
    От: Mr.Cat  
    Дата: 28.09.09 04:03
    Оценка:
    Здравствуйте, LaptevVV, Вы писали:
    LVV>Кстати, народ, который в ББ с 92 года сидит (прикинь, 15 лет уже!) очень ставит в заслугу стабильность среды.
    Читать ли это как "Последние 15 лет ББ существенно не менялся"?
    Re[10]: Noop - новый язык для JVM
    От: Mr.Cat  
    Дата: 28.09.09 04:12
    Оценка:
    Здравствуйте, LaptevVV, Вы писали:
    LVV>Мне, например, очень импонирует, что я в одном и том же окне пишу текст лекции и тут же в этом же тексте пишу программу, которую могу оттранслировать и тут же запустить.
    Кстати, а ты не интересовался literate programming? Ибо как только я столкнулся с желанием оформить программу со сравнительно большим объемом поясняющего текста (по сути близко по духу к некоторым лекциям) — как-то literate programming на горизонте всплыл. Не знаю, близко я этого дела не касался, но идея вроде хороша.
    Re[15]: Noop - новый язык для JVM
    От: LaptevVV Россия  
    Дата: 28.09.09 04:55
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

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


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

    WH>Пожалуйста сравни надежность обероновских программ с надежностью программ вот на этом языке
    WH>http://www.impredicative.com/ur/
    WH>И демки обязательно посмотри.
    WH>http://www.impredicative.com/ur/demo/
    Thank you, БОЛЬШОЕ СПАСИБО, КАТТА РАХМАТ!!!!!!
    Обязательно посмотрю — руководство я уже скатал.
    Только пока не найду, когда он разработан был.
    Но название, конечно, классное!
    Хочешь быть счастливым — будь им!
    Без булдырабыз!!!
    Re[17]: Noop - новый язык для JVM
    От: LaptevVV Россия  
    Дата: 28.09.09 05:01
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

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


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

    AVK>Это очень хорошо характеризует этот народ. И с таким народом нам не по пути.
    Знаешь, а меня тоже достает смена версий. Особенно в Офисе. Тут я абсолдютно согласен с народом — Микрософт просто выкачивает бабло из пользователей.
    В программировании тоже не все гладко. С появлением Дотнета это как-то не так остро. А вот COM-технология — это тихий ужас! А когда народ корячился и перескакивал с технологии на технологию — оберонцы с 92 года сидели в компонентном программировании и горя не знали. И переучиваться не пришлось. Все стабильно и работает.
    И кстати, иногда новая технология выглядит чисто шашечками. Как и новый язык.
    Это примерно так же, как автомобильные компании изощряются: и вот это еще можно, и вот это и то, и вот это. А мне это нифига не нужно, мне ЕХАТЬ надо. А я вынужден за эти нововведения ПЛАЬТИТЬ!
    Хочешь быть счастливым — будь им!
    Без булдырабыз!!!
    Re[17]: Noop - новый язык для JVM
    От: LaptevVV Россия  
    Дата: 28.09.09 05:03
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

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

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

    VD>>>>>Как не прискорбно но Smalltolk 80 был в сто раз современнее сегодняшнего Паскаля/Оберона.

    LVV>>Да ИМХО он просто свое время опередил.
    S>Если бы не зверские цены в своё время на лицензии, то сейчас никаких паскалей бы вообще никто не знал.
    То же самое можно сказать про С?
    Это две равнозначные ветки появились одновременно.
    Хочешь быть счастливым — будь им!
    Без булдырабыз!!!
    Re[17]: Noop - новый язык для JVM
    От: LaptevVV Россия  
    Дата: 28.09.09 05:04
    Оценка:
    Здравствуйте, Mr.Cat, Вы писали:

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

    LVV>>Кстати, народ, который в ББ с 92 года сидит (прикинь, 15 лет уже!) очень ставит в заслугу стабильность среды.
    MC>Читать ли это как "Последние 15 лет ББ существенно не менялся"?
    Я не знаю — у Ткачева надо спросить. Это тот, который про обучение программированию доклад сделал (я его тут постил).
    Хочешь быть счастливым — будь им!
    Без булдырабыз!!!
    Re[11]: Noop - новый язык для JVM
    От: LaptevVV Россия  
    Дата: 28.09.09 05:33
    Оценка:
    Здравствуйте, Mr.Cat, Вы писали:

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

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

    S>>>Если бы не зверские цены в своё время на лицензии, то сейчас никаких паскалей бы вообще никто не знал.

    LVV>>То же самое можно сказать про С?
    S>Вряд ли. С появился лет на 15 раньше smalltalk, и до сих пор занимает совершенно другую нишу, чем Оберон, джава, дотнет, или лисп. Другого типизированного ассемблера, в общем-то, нет.
    Ну, про нишу понятно.
    LVV>>Это две равнозначные ветки появились одновременно.
    S>Ветки чего? По-моему, кто-то очень сильно путает много чего много с чем другим.
    Две синтаксические ветки в процедурных языках: синтаксис С и синтаксис алгола-паскаля.
    Хочешь быть счастливым — будь им!
    Без булдырабыз!!!
    Re[20]: Noop - новый язык для JVM
    От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
    Дата: 28.09.09 05:55
    Оценка:
    Здравствуйте, LaptevVV, Вы писали:
    S>>Ветки чего? По-моему, кто-то очень сильно путает много чего много с чем другим.
    LVV>Две синтаксические ветки в процедурных языках: синтаксис С и синтаксис алгола-паскаля.
    Синтаксис вообще ни при чём. Посмотрите на смолток. Мы говорим о семантике.
    ... << RSDN@Home 1.2.0 alpha rev. 677>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    http://rsdn.org/File/5743/rsdnaddict.GIF
    Re[21]: Noop - новый язык для JVM
    От: LaptevVV Россия  
    Дата: 28.09.09 05:59
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

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

    S>>>Ветки чего? По-моему, кто-то очень сильно путает много чего много с чем другим.
    LVV>>Две синтаксические ветки в процедурных языках: синтаксис С и синтаксис алгола-паскаля.
    S>Синтаксис вообще ни при чём. Посмотрите на смолток. Мы говорим о семантике.
    Да, семантика у паскаля и С, появившихся практически одновременно, была "одной крови".
    Но если говорить о семантике ООП, то ООП появилось еще раньше — в Симула-67, откуда ее и содрал Страуструп.
    В Смоллтоке ООП была доведено до абсолюта: все — объекты.
    Хочешь быть счастливым — будь им!
    Без булдырабыз!!!
    Re[16]: Noop - новый язык для JVM
    От: Andrei F.  
    Дата: 28.09.09 06:23
    Оценка:
    Здравствуйте, VladD2, Вы писали:

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


    А что в нем такого уникального?
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
    Re[22]: Noop - новый язык для JVM
    От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
    Дата: 28.09.09 06:29
    Оценка:
    Здравствуйте, LaptevVV, Вы писали:
    LVV>Да, семантика у паскаля и С, появившихся практически одновременно, была "одной крови".
    LVV>Но если говорить о семантике ООП, то ООП появилось еще раньше — в Симула-67, откуда ее и содрал Страуструп.
    LVV>В Смоллтоке ООП была доведено до абсолюта: все — объекты.
    Я в курсе. Речь о том, что старшая речь, помимо "абсолютного ООП", содержала ещё много чего того, чего в обероне и поныне нет.
    В частности, там были реализованы замыкания (через которые, собственно, и работает GemStone), а также хотспоттинг (без которого системы с выраженной компонентностью сливают убогим плюсам по производительности).
    ... << RSDN@Home 1.2.0 alpha rev. 677>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    http://rsdn.org/File/5743/rsdnaddict.GIF
    Re[23]: Noop - новый язык для JVM
    От: LaptevVV Россия  
    Дата: 28.09.09 06:33
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

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

    LVV>>Да, семантика у паскаля и С, появившихся практически одновременно, была "одной крови".
    LVV>>Но если говорить о семантике ООП, то ООП появилось еще раньше — в Симула-67, откуда ее и содрал Страуструп.
    LVV>>В Смоллтоке ООП была доведено до абсолюта: все — объекты.
    S>Я в курсе. Речь о том, что старшая речь, помимо "абсолютного ООП", содержала ещё много чего того, чего в обероне и поныне нет.
    S>В частности, там были реализованы замыкания (через которые, собственно, и работает GemStone), а также хотспоттинг (без которого системы с выраженной компонентностью сливают убогим плюсам по производительности).
    Лан, спасибо за наводки. Пообщаюсь с народом на Оберонах.
    Хочешь быть счастливым — будь им!
    Без булдырабыз!!!
    Re[16]: Noop - новый язык для JVM
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 28.09.09 06:40
    Оценка:
    Здравствуйте, LaptevVV, Вы писали:

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


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


    Вчера. Точнее завтра.
    В общем, это пока что экспериментальный проект. По нему даже нормальной статьи нет. Только публикации к дисеру.
    http://nemerle.org/Banners/?g=dark
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[18]: Noop - новый язык для JVM
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 28.09.09 06:48
    Оценка:
    Здравствуйте, LaptevVV, Вы писали:

    VD>>>>>>Как не прискорбно но Smalltolk 80 был в сто раз современнее сегодняшнего Паскаля/Оберона.

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

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

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

    В прочем, если бы его трактовали как ты — как высокоуровенвый ассемблер, эдакую замену С/С++, то может у него и был бы шанс. Но к такому ассемблеру нужно ручное управление пмятью и наличие более высокоуровенвых языков поверх его рантайма. Ведь Обером фактически — это виртуальная машина (как дотнет и ява). А писать все на ассемблере (пусть и высокоуровенвом) согласны не все.
    http://nemerle.org/Banners/?g=dark
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[18]: Noop - новый язык для JVM
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 28.09.09 06:50
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

    VD>>>>>>Как не прискорбно но Smalltolk 80 был в сто раз современнее сегодняшнего Паскаля/Оберона.

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

    Смотря в чем. Как системный язык Smalltolk 80 использовать нельзя, а Оберон можно.
    http://nemerle.org/Banners/?g=dark
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[23]: Noop - новый язык для JVM
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 28.09.09 06:53
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

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


    Ну, справедливости ради надо заметить, что Smalltolk сливает плюсам по любому, а как раз Оберон выглядит весьма на уровне (с учетом, что оптимизирующих компилятор и ЖЦ ему писали преподы и студенты).
    http://nemerle.org/Banners/?g=dark
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[24]: Noop - новый язык для JVM
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 28.09.09 06:55
    Оценка:
    Здравствуйте, LaptevVV, Вы писали:

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

    LVV>Лан, спасибо за наводки. Пообщаюсь с народом на Оберонах.

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

    Лучше изучи эти самые замыкания и функции высшего порядка (можно, например, на C# 3.0). Тогда ты и сам все поймешь.
    http://nemerle.org/Banners/?g=dark
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[19]: Noop - новый язык для JVM
    От: LaptevVV Россия  
    Дата: 28.09.09 07:02
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    VD>Уверен, что Sinclair говорил про Smalltolk. На него правда цены были ужасные.

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

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

    Вот с этим я согласен. На оберонском форуме часто возникают споры по поводу примитивизма языка. И того нет, и этого нет. И ответ оберонцев всегда один и тот же: если нужно — напиши. Понятно, что не все хотят писать велосипеды. Мне тоже это не нравится. Тут только один способ есть: садится и написывать свою специфическую для своих задач библиотеку (что все оберонцы и делают). После пары лет будешь иметь заточенный под свои задачи нормальный инструментарий.
    Хочешь быть счастливым — будь им!
    Без булдырабыз!!!
    Re[18]: Noop - новый язык для JVM
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 28.09.09 07:03
    Оценка:
    Здравствуйте, LaptevVV, Вы писали:

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


    А меня нет.

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


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

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


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

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


    Опять аналогии.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1237 on Windows 7 6.1.7100.0>>
    AVK Blog
    Re[25]: Noop - новый язык для JVM
    От: LaptevVV Россия  
    Дата: 28.09.09 07:06
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    LVV>>Лан, спасибо за наводки. Пообщаюсь с народом на Оберонах.

    VD>Это примерно тоже самое, что общаться с пятилетним ребенком на тему термодинамики.
    VD>Они тупо не знают о чем идет речь.
    Не, почему. Некоторые вполне вменяемые. И вполне знающие.
    VD>Лучше изучи эти самые замыкания и функции высшего порядка (можно, например, на C# 3.0). Тогда ты и сам все поймешь.
    Ну, теоретически-то я знаком. Но практики нет, поэтому сложно.
    Хочешь быть счастливым — будь им!
    Без булдырабыз!!!
    Re[19]: Noop - новый язык для JVM
    От: LaptevVV Россия  
    Дата: 28.09.09 07:09
    Оценка:
    Здравствуйте, VladD2, Вы писали:

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

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

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

    И я с этим согласен. Фичи должны быть оправданы. Например, усложнением решаемых задач.
    Хочешь быть счастливым — будь им!
    Без булдырабыз!!!
    Re[24]: Noop - новый язык для JVM
    От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
    Дата: 28.09.09 07:20
    Оценка:
    Здравствуйте, VladD2, Вы писали:
    VD>Ну, справедливости ради надо заметить, что Smalltolk сливает плюсам по любому,
    Ага-ага. Помнится, где-то бегал бенчмарк по виртуальным вызовам. Там оказывалось, что плюсы никак не могут заинлайнить вызов из-за виртуальности; а смолток ухитрялся это сделать.
    В итоге call per second у старшей речи был не то, чтобы ниже, а скорее выше, чем у плюсов.
    Ну, правда, я не уверен насчёт последнести версии компилятора плюсов, с которым это проверялось. Интел вон спекулятивный инлайнинг нынче умеет делать, если ему PGO-информацию скормить.
    VD>а как раз Оберон выглядит весьма на уровне (с учетом, что оптимизирующих компилятор и ЖЦ ему писали преподы и студенты).
    Ой, что-то я сомневаюсь, что в обероне сделали хотя бы PGO. А без неё или хотспоттинга порвать статическую линковку крайне трудно. Поэтому ожидаем массовых abstraction penalty для "сильно компонентных" систем. Понятно, что реализовать более-менее приемлемую оптимизацию на уровне одной единицы компиляции в принципе можно.
    ... << RSDN@Home 1.2.0 alpha rev. 677>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    http://rsdn.org/File/5743/rsdnaddict.GIF
    Re[21]: Noop - новый язык для JVM
    От: LaptevVV Россия  
    Дата: 28.09.09 07:23
    Оценка:
    Здравствуйте, VladD2, Вы писали:

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


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

    VD>Глупый ответ. Не достойный людей из науки. Да даже инженера не достойный.
    VD>Нельзя "написать" скажем замыкания. Для этого может и средств метапрограммирования не хватить. А в Обероне нет и их. Так что точно нельзя написать.
    Здесь обычно ответ такой: не требуется для работы.
    LVV>> Понятно, что не все хотят писать велосипеды. Мне тоже это не нравится. Тут только один способ есть: садится и написывать свою специфическую для своих задач библиотеку (что все оберонцы и делают). После пары лет будешь иметь заточенный под свои задачи нормальный инструментарий.
    VD>Извини, то ты говоришь полнейшую ересь. Разберись в вопросе и тогда сам поймешь насколько ошибочно твое мнение.
    Не, ты не понял. Я не о замыканиях, а вообще о подходе в ББ. Для С++ — писание своей библиотеки это, естественно, нонсенс, ибо есть стандартная. А для ББ — норма, ибо есть только среда и стандарта нет.
    VD>Есть куча вещей которые невозможно заложить в библиотеку.
    VD>Решением проблемы могла бы быть мощная система метапрограммирования (МП). Но она должна быть действительно мощна. С ее помощь должно быть можно серьезно переписывать код. Скажем для введения в язык замыканий система МП должна:
    VD>1. Позволять выявлять в коде лямбды (специальные синтаксические конструкции описывающие анонимные функции)
    VD>2. Переписывать локальный код так чтобы он использовал не локальные переменные, а специально введенные локальные объекты.
    VD>3. Позволять программно объявлять новые типы реализующие замыкания.
    VD>4. Позволять переписывать код тел функций/методов.
    VD>Тоже самое нужно для поддержки сопоставления с образцом и многих других конструкций.
    VD>Для реализации скажем алгебраических типов нужно еще уметь менять синтаксис на уровне верхнеуровеных конструкций языка.
    Да с этим я согласен.
    VD>На сегодня это не умеет делать толком ни один язык. Ближе всего к идеалу стоят Nemerle и Lisp.
    VD>А Оберон — это просто островок для тех кто сошел на обочину индустрии. Люди его развивающие похоже просто не способны понять и принять новые концепции. А без этого язык обречен.
    Может быть. Но для моих локальных проблем ББ подходит как нельзя лучше.
    Попробую прототипы ваять. А если пойдет — то попробую перенести в Дотнет.
    Хочешь быть счастливым — будь им!
    Без булдырабыз!!!
    Re[26]: Noop - новый язык для JVM
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 28.09.09 07:25
    Оценка:
    Здравствуйте, LaptevVV, Вы писали:

    LVV>>>Лан, спасибо за наводки. Пообщаюсь с народом на Оберонах.

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

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

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

    LVV>Ну, теоретически-то я знаком. Но практики нет, поэтому сложно.

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

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

    Готов даже пожертвовать своим времени и помочь тебе в освоении этого дела на базе моего нынешнего фаворита — Немерле.
    Если есть широкий канал, то можно пообщаться через Skype.
    Думаю, что человеку знакомому с С++ пары недель хватит для освоения новых концепций.
    http://nemerle.org/Banners/?g=dark
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[20]: Noop - новый язык для JVM
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 28.09.09 07:32
    Оценка:
    Здравствуйте, LaptevVV, Вы писали:

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

    LVV>

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


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

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


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

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


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

    Структурное программирование, ООП и КООП — это замечательно! Но современный вуз обязан давать так же ФП и МП! Обязан!!!
    А на Обероне вы точно этому не научите.
    http://nemerle.org/Banners/?g=dark
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[25]: Noop - новый язык для JVM
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 28.09.09 07:37
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    VD>>Ну, справедливости ради надо заметить, что Smalltolk сливает плюсам по любому,

    S>Ага-ага. Помнится, где-то бегал бенчмарк

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

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


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

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

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

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

    Если же говорить серьезно, то дизайн Оберона отлично подходит для оптимизаций. Это практически типобезопасный С++ без шаблонов. Писать на нем долго и нудно, но написать быстрый софт можно.
    http://nemerle.org/Banners/?g=dark
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[22]: Noop - новый язык для JVM
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 28.09.09 07:48
    Оценка:
    Здравствуйте, LaptevVV, Вы писали:

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


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

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

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

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

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

    LVV>Может быть. Но для моих локальных проблем ББ подходит как нельзя лучше.

    LVV>Попробую прототипы ваять. А если пойдет — то попробую перенести в Дотнет.

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

    Оберон пригоден для освоения структурного программирования и для "механического" перехода от них к ООП.
    Но это все на что он способен. Никакому инженеру или тем более полноценному программисту это устаревшее чудо и даром не нужно. Так что ваша задача включить в процесс обучения другие языки, на базе которых вы сможете продемонстрировать людям концепции ФП и МП. Ну, а для этого вам самим нужно все это освоить. Так что не зарывайся в это Оберон.
    http://nemerle.org/Banners/?g=dark
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[19]: Noop - новый язык для JVM
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 28.09.09 07:51
    Оценка:
    Здравствуйте, nikov, Вы писали:

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


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

    В то же время автор этого Ur-а вроде бы приводит какие-то гарантии завершаемости компиляции.
    http://nemerle.org/Banners/?g=dark
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[27]: Noop - новый язык для JVM
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 28.09.09 07:53
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

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


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

    Я же просто заметил, что Оберон весьма производительное решение на форе Smalltolk. И сделал это исключительно из справедливости. Ведь в обучении производительность вообще не нужна.
    http://nemerle.org/Banners/?g=dark
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[28]: Noop - новый язык для JVM
    От: Cyberax Марс  
    Дата: 28.09.09 08:04
    Оценка:
    Здравствуйте, VladD2, Вы писали:

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

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

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

    Ну да, согласен.
    Sapienti sat!
    Re[21]: Noop - новый язык для JVM
    От: FR  
    Дата: 28.09.09 08:41
    Оценка:
    Здравствуйте, VladD2, Вы писали:

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


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


    Угу у меня тоже сразу в голове украинский гимн зазвучал
    Re[21]: Noop - новый язык для JVM
    От: samius Россия http://sams-tricks.blogspot.com
    Дата: 28.09.09 08:44
    Оценка:
    Здравствуйте, VladD2, Вы писали:

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


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


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


    Дарю
    Re[5]: Noop - новый язык для JVM
    От: thesz Россия http://thesz.livejournal.com
    Дата: 28.09.09 09:18
    Оценка:
    Здравствуйте, 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 мы формируем ограничение на хранимый в конструкторе типов аргумент.

    Итак, подходит ли это в качестве решения?
    Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
    Re[21]: Noop - новый язык для JVM
    От: LaptevVV Россия  
    Дата: 28.09.09 10:16
    Оценка:
    Здравствуйте, VladD2, Вы писали:

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

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

    VD>Вот — это отличный его пример.
    Читал, конечно.
    LVV>>И я с этим согласен.
    VD>Прискорбно. Значит ваш вуз будет плодить тех самых блабов. И совершенно все равно какие языки или платформы вы будете преподавать. Ведь если преподаватель не знаком с концепциями которые предоставляют все эти лиспы, хаскели и т.п., то научить вы людей сможете только оберону, так как любое обучение не выйдет за рамки структурного программирования, ООП и КООП. В прочем, многие вузы и дальше структурного программирования не идут.
    Тут как всегда наблюдаем соотношение изменчивость vs стабильность. В промышленности лучше иметь стабильность — на некоторый период времени. Так оно и есть. Потом наступает время изменчивости. Но скачком! Новая технология создает ступеньку. Вот вчера только затопили последний аналоговый Прогресс. А в ИТ изменчивость — это непрерывный процесс. И это не есть хорошо для производства программ.
    LVV>>Фичи должны быть оправданы. Например, усложнением решаемых задач.
    VD>Дык они и оправданы. А то что эти оберонисты не понимают этого — проблема именно оберонистов, а не фич или индустрии.
    Ну, скорее всего, зависит от задач.
    VD>Структурное программирование, ООП и КООП — это замечательно! Но современный вуз обязан давать так же ФП и МП! Обязан!!!
    VD>А на Обероне вы точно этому не научите.
    А мы на Обероне и не учим. А чему учим — ты ж читал мою цитату из блога. И Фадиез там есть.
    Хочешь быть счастливым — будь им!
    Без булдырабыз!!!
    Re[18]: Noop - новый язык для JVM
    От: Andrei F.  
    Дата: 28.09.09 11:26
    Оценка:
    Здравствуйте, VladD2, Вы писали:

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


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

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


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

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


    Где можно почитать в доступной форме, что это такое и как работает?
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
    Re[20]: Noop - новый язык для JVM
    От: Mr.Cat  
    Дата: 28.09.09 11:54
    Оценка:
    Здравствуйте, LaptevVV, Вы писали:
    LVV>

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

    Отнимая фичу — надо дать механизм ее реализации — такова суть языка scheme.
    Re[19]: Noop - новый язык для JVM
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 28.09.09 12:04
    Оценка:
    Здравствуйте, Andrei F., Вы писали:

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


    Ссылки были выше. На сайте есть ряд работ. Основная их проблема — излишняя заформализованность.
    http://nemerle.org/Banners/?g=dark
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[20]: Noop - новый язык для JVM
    От: Andrei F.  
    Дата: 28.09.09 12:40
    Оценка:
    Здравствуйте, VladD2, Вы писали:

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


    Вот-вот. В этих мануалах черт ногу сломит. Но мне была интересна сама концепция, что это за хитрая система типов. Она же вроде бы не уникальная для этого языка?
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
    Re[5]: Noop - новый язык для JVM
    От: Andrei F.  
    Дата: 28.09.09 14:01
    Оценка:
    Здравствуйте, nikov, Вы писали:

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


    Разве результат выполнения Map (при вызове на коллекции интерфейсов) не придется все равно приводить к базовому классу?
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
    Re[21]: Noop - новый язык для JVM
    От: nikov США http://www.linkedin.com/in/nikov
    Дата: 28.09.09 14:08
    Оценка:
    Здравствуйте, Andrei F., Вы писали:

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


    Насколько я понял, там поддерживается kind polymorphism, что довольно уникально.
    Re[22]: Noop - новый язык для JVM
    От: Andrei F.  
    Дата: 28.09.09 15:55
    Оценка:
    Здравствуйте, nikov, Вы писали:

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


    А можно объяснить идею вкратце?
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
    Re[21]: Noop - новый язык для JVM
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 28.09.09 17:04
    Оценка:
    Здравствуйте, 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 имеет никуда не годную производительность. Объем словаря мемоизации становится очень большим и весь пар уходит в возню с ним. Обещанный оптимизированный вариант тобой так и не был написан. Вместо этого ты увлекся еще одной идеей которая сулит еще более крутые бенефиты. Понятно куда я веду?

    Так вот генерировать красивые идеи читая чужие дисеры — это конечно интересно, но довольно бесполезно. А вот сделать что-то законченное и применимое на практике — это большой и неблагодарный труд. Но только сделав его можно получить продукт который действительно сможет поднять производительность программиста.
    http://nemerle.org/Banners/?g=dark
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[20]: Noop - новый язык для JVM
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 28.09.09 18:09
    Оценка:
    Здравствуйте, LaptevVV, Вы писали:

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


    А я — нет. Как тот самый производитель программ, смею тебя заверить — мы добавляем только те фичи, которые, как мы считаем, будут очень полезны большому количеству народу (и нам самим в том числе). И хотел бы я знать, как можно зарабатывать на фичах бесполезных.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1237 on Windows 7 6.1.7100.0>>
    AVK Blog
    Re[22]: Noop - новый язык для JVM
    От: WolfHound  
    Дата: 28.09.09 19:22
    Оценка:
    Здравствуйте, 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>Так вот генерировать красивые идеи читая чужие дисеры — это конечно интересно, но довольно бесполезно.

    Меня очень давно не устраивают современные языки. По этому я читаю диссеры и генерирую идеи.
    Начал я это делать еще до того как ты немерлом увлекся.
    А когда из диссеров и идей сложу мозаику в единую систему типов которая даст мне все что я хочу от языка программирования вот тогда я и начну действовать в этом направлении активно.
    А пока этого нет я буду читать диссиры, генерировать идеи и скармливать эти идеи общественности. Пусть проверяет.
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[23]: Noop - новый язык для JVM
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 28.09.09 20:22
    Оценка:
    Здравствуйте, 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 (как мы это обсуждали). При этом сложность распознавания синтаксиса перекладывается на механизмы автоматического построения парсеров (встроенного в язык). А как быть с метасистемой построенной на базе ЗТД?
    http://nemerle.org/Banners/?g=dark
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[24]: Noop - новый язык для JVM
    От: WolfHound  
    Дата: 28.09.09 22:46
    Оценка:
    Здравствуйте, VladD2, Вы писали:

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

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

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

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

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

    Там все метапрограммирование основано на хитром fold'е который умеет сворачивать типы.

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

    Я очень редко ошибаюсь на счет алгоритмов.

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

    А там нет преобразований AST как таковых.
    Там все основано на частичных вычислениях.
    Те мы просто пишем код в котором очень много вычислений происходит над константами времени компиляции(типы в частности).
    Далее все вычисления которые зависят исключительно от констант проводит компилятор.
    А благодаря тому что константы у нас попадаются весьма интересные, а именно типы и имена челенов типов то мы можем получать МП на всю катушку.

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

    WH>>Тебе.
    WH>>А лично меня очень сильно напрягают совершенно не формализованные потроха компилятора.
    VD>Причем тут форматирование?
    Где в моей цитате слово форматирование? Там есть немного похожее слово имеющее сильно другое значение.
    Пожалуйста читай более одного раза если тебе кажется что я написал что-то не то.

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

    Ну ты эта посмотри код на Ur/Web что-ли.
    Причем я думаю что если поработать над синтаксисом его можно сделать еще проще.

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

    Просто автор Ur'а как и большинство ученых страдает острой формой формализма.
    Я уверен что там все можно переделать гораздо более человечески.

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

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


    VD>Ну, структуры БД и время можно представить неизменяемой структурой данных.

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


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

    Это кстати далеко не всегда хорошо.

    VD>Получается макры таки имеют преимущества и если их не воспроизвести, то грош-цена такому метааппарату.

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

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

    А оно тянет за собой весьма не мало.
    В частности алгоритмы поиска решений подходящих под ограничения идут лесом почти со 100% вероятностью.
    А они тут ИМХО весьма кстати.

    VD>В прочем, ОК. Продемонстрируй как такой макрос будет выглядеть на типах высших порядков и сравним.

    Это будет очень не честное сравнение...
    А не честное по тому что все коллекции в таком языке будут реализовывать класс типов который умеет Fold или как минимум имеют метод Fold...
    //имя и тип
    syntax foreach : Expression
    //правило для PEG
    rule "foreach" "(" name : Identificator "in" collection : Expression ")" body : Expression
    //переписываем
    code
      <[ _ = ($collection).Fold({}, ($name, _) => _ = $body; {}; end )]>
    end
    //{} это кортеж из 0 элементов. Универсальная заглушка вместо void.

    Если же у нас тяжелый случай и ничего объединяющего нет то мы просто напишем набор перегруженных функций. И будет тоже самое.
    И работать будет быстро ибо бекенд у нас заточен на оптимизацию ФВП и не только.

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

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

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

    Вот чего я не стану делать точно так это брать за основу систему типов .НЕТа. Ибо оно то еще убожество.
    Все что нужно добавить в ту систему типов это сабклассинг для ООП и слово mutable для императивщены.
    Ни то ни другое на выводе типов практически не отразится.

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

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

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

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

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

    VD>Ты пробовал ставить и использовать этот самый Ur?
    Да при чем тут вообще ур?
    Я говорю про подобные системы в принципе.

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

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

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

    VD>Звучит хорошо... в теории.
    Если платформу бутстрапить то это будет практикой.

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

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

    WH>>Я даже где то видел статью в которой зависимыми типами проверяли дерево в интерпретаторе.

    WH>>Тут ровно тоже самое.
    WH>>Так что это даже не подозрение, а почти 100% уверенность.
    VD>"почти 100% уверенность" — это надо запомнить!
    И чего ты тут ехидничаешь?
    Даже если я не смогу на 100% проверить результирующий AST при помощи ЗТ все равно верификатор будет очень сильно проще чем делать его без ЗТ.

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

    Выше...

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

    А давай ты будешь читать то что я пишу. Ладно?

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

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

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

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

    VD>Да и бэкэнд компилятора тоже не игрушка. Писать его только для того, чтобы создать более удобный ЯП — это маразм.

    А тут просто выбора нет. Максимум что можно использовать это LLVM.

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

    А я знаю. Но это не мешает мне вести исследования в этом направлении.

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

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

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

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

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

    Я ничего не жду.
    Я просто не знаю в каком конкретно направлении копать.
    Немерле точно не то направление.
    Ибо мне система типов нужна более мощная и формальная чтобы можно было рассуждать о программе.
    Яркий пример IEnumeraor[T] реализующий IDisposable.
    Пока дело ограничивается одним foreach все хорошо. А если появляются ФВП у меня крышу сносит от попытки понять кто Dispose делать будет.

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

    Так я уже говорил.
    Просто на уровне синтаксиса тупо переписываем при помощи PEG'а и все. См про foearch.
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[24]: Noop - новый язык для JVM
    От: nikov США http://www.linkedin.com/in/nikov
    Дата: 29.09.09 07:05
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    VD>Не...а. Отладчики пока что не умеют отлаживать вычисления в типах.


    Кстати, Одерски планирует прикрутить к Scala отладчик типов. Пока ещё не совсем ясно, как это будет выглядеть.
    Re[22]: Noop - новый язык для JVM
    От: thesz Россия http://thesz.livejournal.com
    Дата: 29.09.09 08:40
    Оценка:
    Здравствуйте, VladD2, Вы писали:

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


    WH>>А мне подход с системой типов нравится гораздо больше.

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

    Посмотри на Agda2.
    Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
    Re[23]: Noop - новый язык для JVM
    От: nikov США http://www.linkedin.com/in/nikov
    Дата: 29.09.09 11:44
    Оценка:
    Здравствуйте, Andrei F., Вы писали:

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


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


    kind — это как бы тип типа. Он включает себя количество типов-параметров, принимаемых данным типом, их kinds, а в некоторых языках (например, Scala) — их вариантность и констрейнты.
    kind polymorphism — это возможность написать код, type variables в котором могут быть инстанциированы типами с различными kinds.
    Re[25]: Noop - новый язык для JVM
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 29.09.09 12:26
    Оценка:
    Здравствуйте, nikov, Вы писали:

    VD>>Не...а. Отладчики пока что не умеют отлаживать вычисления в типах.


    N>Кстати, Одерски планирует прикрутить к Scala отладчик типов. Пока ещё не совсем ясно, как это будет выглядеть.


    А что, их система типов полна по Тьюрингу?
    http://nemerle.org/Banners/?g=dark
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[26]: Noop - новый язык для JVM
    От: nikov США http://www.linkedin.com/in/nikov
    Дата: 29.09.09 13:20
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    VD>А что, их система типов полна по Тьюрингу?


    Насколько я знаю, система типов в стандартной Scala позволяет выразить примитивно-рекурсивные функции, а расширения языка (флаг компилятора -Yrecursion) — любые рекурсивные функции (соответственно, typechecker может зависать в этом режиме). Но я не берусь это продемострировать.
    Re[27]: Noop - новый язык для JVM
    От: lomeo Россия http://lomeo.livejournal.com/
    Дата: 29.09.09 13:48
    Оценка:
    Здравствуйте, nikov, Вы писали:

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


    При -Yrecursion ты должен явно задавать максимальную глубину рекурсии.

    А демонстрировать чего там

    type T = { def foo(bar: T) }

    Re[29]: Noop - новый язык для JVM
    От: nikov США http://www.linkedin.com/in/nikov
    Дата: 29.09.09 14:34
    Оценка:
    Здравствуйте, nikov, Вы писали:

    N>Ты попробуй написать программу, на которой type checker останавливается только в том случае, если существует четное число, большее 2, не представимое в виде суммы двух простых чисел.


    Кстати, интересно было бы посмотреть на это и на других языках (Haskell, C++).
    Re[29]: Noop - новый язык для JVM
    От: lomeo Россия http://lomeo.livejournal.com/
    Дата: 29.09.09 15:15
    Оценка:
    Здравствуйте, nikov, Вы писали:

    N>Ну это не доказательство возможности представления любой рекурсивной функции.


    Конечно, не доказательство, оно же не компилируется!

    N>Ты попробуй написать программу, на которой type checker останавливается только в том случае, если существует четное число, большее 2, не представимое в виде суммы двух простых чисел.


    Ой-ой-ой... Сейчас вечер. Я и не на типах то такое не напишу.

    На параллельный пост — на Haskell система типов является Тьюринг-полной. Достаточно включить UndecidableInstances.
    Re[22]: Немерло
    От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
    Дата: 30.09.09 07:21
    Оценка:
    Здравствуйте, Qbit86, Вы писали:
    Q>Например, в сочетании «это ваше Немерлo»  Или: «закрой Немерлo!»
    Всякому образованному человеку очевидно, что Немерло — это N'est Merlot, такое вино.
    ... << RSDN@Home 1.2.0 alpha rev. 677>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    http://rsdn.org/File/5743/rsdnaddict.GIF
    Re[6]: Noop - новый язык для JVM
    От: nikov США http://www.linkedin.com/in/nikov
    Дата: 06.10.09 04:54
    Оценка:
    Здравствуйте, thesz, Вы писали:

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

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

    Спасибо за наводку, сейчас разбираюсь с этим.
    Re[15]: Noop - новый язык для JVM
    От: vdimas Россия  
    Дата: 08.10.09 22:06
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    WH>Пожалуйста сравни надежность обероновских программ с надежностью программ вот на этом языке

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

    Хм... отвал башки. Настолько очевидная концепция, что как впечатление остается лишь вопрос: "почему этого не было еще лет 10 назад?"
     
    Подождите ...
    Wait...
    Пока на собственное сообщение не было ответов, его можно удалить.