Re[13]: Ой, чо с D деется-то!?
От: Vermicious Knid  
Дата: 17.11.06 14:28
Оценка: 30 (1)
Здравствуйте, ie, Вы писали:

E>>Да ладно сравнивать императивное решение с функциональным:

ie>Точно-точно!
ie>
ie>makeDist _ 0 = []
ie>makeDist n m = let r = round (fromIntegral n / m) in r : makeDist (n-r) (m-1)
ie>

Ну и Nemerle можно таким образом ужать:
def makeDist(n, m)
    if (n == 0) [] else
        def r = (n / m:>double).Round():>int; r :: makeDist(n-r, m-1)

Главная причина, по которой Nemerle трудно соревноваться в краткости со многими другими языками, это на самом деле .NET BCL и стандартная библиотека Nemerle, которая написана в стиле .NET BCL. Они вообще не способствуют написанию краткого кода. Но есть в принципе способы, которые позволяют это частично исправить. Например в примере выше используется такой вот маленький helper:
module RoundExt
    public Round(this num : double, mode : MidpointRounding = MidpointRounding.AwayFromZero) : double
        System.Math.Round(num, mode)
Re[14]: Ой, чо с D деется-то!?
От: ie Россия http://ziez.blogspot.com/
Дата: 17.11.06 14:34
Оценка: :)))
Здравствуйте, Vermicious Knid, Вы писали:

E>>>Да ладно сравнивать императивное решение с функциональным:

ie>>Точно-точно!
VK>Ну и Nemerle можно таким образом ужать:

Да я собсно и не спорю, ужать действительно что угодно можно, это так шутка юмора была
А кстати! J, дайте J!!
... << RSDN@Home 1.2.0 alpha rev. 0>>
Превратим окружающую нас среду в воскресенье.
Re[14]: Ой, чо с D деется-то!?
От: Vermicious Knid  
Дата: 17.11.06 14:40
Оценка: :)
Здравствуйте, Vermicious Knid, Вы писали:

VK>
VK>def makeDist(n, m)
VK>    if (m == 0) [] else
VK>        def r = (n / m:>double).Round():>int; r :: makeDist(n-r, m-1)
VK>

В примере была ошибка. Вот поэтому лучше ничего так не ужимать.
Re[12]: Ой, чо с D деется-то!?
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 17.11.06 15:06
Оценка:
Здравствуйте, WolfHound, Вы писали:

E>>Нет, не про это. Посмотри, скажем на исходный пример с CurryAll.

WH>Прости не вижу я там вывода типов кроме самого примитива аля auto.

Ну и ладно.

E>>Да уж, виртуальная машина, чтобы биты выжимать. Круто.

WH>Зря смеешся. Если в ВМ сделать поддержку работы с битами то это будет даже проще чем на С/С++ и с очень высокой вероятностью эффективней.

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

E>>Ты вот сейчас на C++ для Linux и AIX (если я ничего не перепутал) пишешь. В связи с этим два вопроса:

WH>Без AIX
E>>1) помешало бы тебе,
WH>Мне оно ни разу бы не помогло.

Ok. Вопрос закрыт.

E>>2) почему же ты не используешь Nemerle? Он что, биты хуже выжимает?

WH>

либо совершенно иная нежели CLR и JavaVM виртуальная машина.

WH>Ты вобще читаешь что я пишу?

Читаю, только есть в природе такая ВМ?
А вот Nemerle есть. Но ты его не используешь. Почему?


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[3]: Ой, чо с D деется-то!?
От: Андрей Хропов Россия  
Дата: 17.11.06 15:17
Оценка:
Здравствуйте, FR, Вы писали:

FR>Здравствуйте, Андрей Хропов, Вы писали:


АХ>>Для того чтобы почувствовать разницу вот тот же самый код на Nemerle


FR>А почему именно на Nеmerle?

Потому что эти языки (D и Nemerle) как мне кажется как раз могут рассматриваться в качестве конкурентов
(ну по крайней мере мне так кажется), поскольку оба статически типизированы, в них есть вывод типов (хотя у Немерле он и значительно мощнее), обладают средствами метапрограммирования
и активно развиваются.
Судя хотя бы вот по этой таблице
Автор: VladD2
Дата: 18.05.06
(хотя там не все верно, см. комментарии) у них много общих фич.

FR>Почему не на Наскеле или даже Питоне?

Питон — это динамика. Так что немного из другой оперы.
Хаскель не знаю

FR>Тоже будет такой же краткий код.

Да вот не такой же краткий (это еще к тому же только 2.5 который недавно вышел):

import functools.partial

def plus(x, y, z):
    return x + y + z

def minus(x, y, z):
    return x - y - z

plus_two = partial(plus,2);
print plus_two(6, 8)

plus_three = partial(plus_two,3);
print plus_three(7)

plus_all = partial(partial(partial(plus,3),4),5); # видимо только так?
print plus_all()

minus_all = partial(partial(partial(minus,7),8),9);
print minus_all()
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[3]: D и замыкания.
От: Андрей Хропов Россия  
Дата: 17.11.06 15:17
Оценка:
Здравствуйте, FR, Вы писали:

FR>Не это не то просто function считается статическим и соответствено не может ссылатся на локальные переменные, delegate же может. Но для delegate там ниже написано что нельзя ссылатся на локальные переменные из вложенной функции, так как при выходе получим мусор указывающий на стек, я попробовал на простых примерах все почему-то работает, вот и гадаю теперь UB или не UB Ладно надо будет примерчик посложнее проверить.


UB. попробуй
import std.stdio;

void main()
{
  int delegate(int) test(int x)
  {
    return (int y) {return x + y;};    
  }
  
  writefln(test(1)(2));
}


Кое-что писал по этому поводу здесь.
Вальтер ответил что посмотрим ближе к 2.0. Но в свете последних фич может и раньше увидим.
Ведь по сути вот эти функции Curry делают те же замыкания руками.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[13]: Ой, чо с D деется-то!?
От: WolfHound  
Дата: 17.11.06 15:26
Оценка:
Здравствуйте, eao197, Вы писали:

WH>>Зря смеешся. Если в ВМ сделать поддержку работы с битами то это будет даже проще чем на С/С++ и с очень высокой вероятностью эффективней.

E>Никогда не поверю, что соптимизированный под конкретное железо нативный код будет проигрывать ВМ.
Это можно достичь только на асме и только очень долго вылизывая код. А порвать С/С++ имея качественную модель ВМ не сложно.

E>А вот Nemerle есть. Но ты его не используешь. Почему?

По тому что корпоративный стандарт это С++. Плюс у моно все тотже консервативный ГЦ... Может они из жабы потырят нормальный...
В любом случае в CLR весьма хреново с обработкой битовых последовательностей.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[5]: Ой, чо с D деется-то!?
От: Андрей Хропов Россия  
Дата: 17.11.06 16:21
Оценка:
Здравствуйте, FR, Вы писали:

FR>>Да вроде в функционалном стиле код проще получается, например на питоне:


FR>Кстати на D тоже:


Более функциональный стиль это:
import std.math;
import std.stdio;

int[] makeDistrib2(int trxCount, int quantums,  int[] result = [])
{
  return (quantums == 0) ?
      result
    : { auto next = cast(int)round(cast(float)trxCount / quantums);
        return makeDistrib2(trxCount - next, quantums - 1, result ~ [next]); }() ;
}

void main()
{
  writefln(makeDistrib2( 2, 6 ));
}
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[4]: Ой, чо с D деется-то!?
От: Андрей Хропов Россия  
Дата: 17.11.06 16:21
Оценка: +2
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Андрей Хропов, Вы писали:


АХ>>Знаешь, с одной стороны да (этот синтаксис Tuples просто жесть по сравнение с Nemerle), с другой стороны в низкоуровневом языке задача которого заменить C/C++ это неплохо.

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

WH>Все что нужно это value-типы, поддержка двоичных данных на уровне виртуальной машины и оптимизатор который умеет делать region-inference. Еще нужно иметь несколько различных алгоритмов сборщика мусора в том числе подсчет ссылок и вобще отсутствие сборщика мусора (работает только region-inference).


Не согласен.
Помимо этого должна быть возможность вообще не пользоваться сборщиком мусора,
не должно быть обязательной зависимости от большого рантайма (для встроенных систем и вообще где мало памяти), должен быть встроенный ассемблер (желательно с легко настраиваемым под конкретную архитектуру набором инструкций) и указатели (можно (и даже неплохо) их конечно поместить в отдельный unsafe-загон, как в C#, но они должны быть, хотя бы для того чтобы реализовывать сборщики мусора).
Также должны быть средства жесткого задания бинарного представления в структурах (в D есть шаги в этом направлении).

WH>Короче см singularity там почти оно только CLR на роль виртуальной машины для ОС не очень подходит.

На языке для системного программирования должно быть можно написать ядро ОС.
Ядро в Singularity написано на assembler + C++ + С# (safe и unsafe).
Хотя неверифицируемая часть состоит всего из 5% кода.

Что ж, ждем-с этого счастья.

АХ>> Мне кажется основная проблема D сейчас — довольно медленный GC (ну и библиотек немного, но это уже скорее про инфраструктуру, а не сам язык):

WH>А для D не возможен быстрый GC. Ибо быстрый == точный, а не консервативный как в D.
Как в текущей реализации D.
Да, вот и надо приделать к D точный копирующий GC.

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

Почему? Надо только разобраться с вопросом можно ли (и как) работать с указателями на GC объекты.
Дизайн D вообще говоря меняется.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[14]: Ой, чо с D деется-то!?
От: Андрей Хропов Россия  
Дата: 17.11.06 16:37
Оценка:
Здравствуйте, WolfHound, Вы писали:

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

WH>Это можно достичь только на асме и только очень долго вылизывая код. А порвать С/С++ имея качественную модель ВМ не сложно.
Зависит от задач.
Для тех где много мелких хаотично связанных объектов создается — да, GC рулит.
Для задач где много вычислений (+ грамотно написанных) — вряд ли. Хоть Java с HotSpotом и приближается, но
1) Оверхед по памяти велик, а значит меньше размер задач которые вообще влезают в пямять + менее эффективно используется кэш
2) Сам HotSpot отъедает ресурсы.

WH>Плюс у моно все тотже консервативный ГЦ...

Уже нет (читаем Mono 1.2 release notes):

Garbage Collector: We now use Boehm GC [b]in precise mode
as opposed to fully conservative mode. We also use it with a precise set of GC roots which greatly improved Garbage Collection performance.
[/b]

Хотя на тесте shootout.binarytrees, который как раз неплохо показывает скорость работы GC оно все равно ~ 3 раза медленнее (писал здесь)
:

C# on .NET 2.0 : 1.902 sec
DMD 0.173 — malloc(original version) : 5.189 sec
C# on Mono 1.1.18 : 6.630 sec
DMD 0.173 — full GC : 19.720 sec

(1.1.18 работает приблизительно так же как 1.2)

На linux (Mandriva 2007) кстати Mono чуть быстрее: 5.920 sec
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[15]: Ой, чо с D деется-то!?
От: Cyberax Марс  
Дата: 17.11.06 16:49
Оценка:
Андрей Хропов wrote:
> WH>Плюс у моно все тотже консервативный ГЦ...
> Уже нет (читаем Mono 1.2 release notes
> <http://www.go-mono.com/archive/1.2/&gt;):
> *
> Garbage Collector: We now use Boehm GC in precise mode* as opposed to
> fully conservative mode. We also use it with a precise set of GC roots
> which greatly improved Garbage Collection performance.
>

Это не полностью точный режим работы — там стек до сих пор консервативный.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[10]: Ой, чо с D деется-то!?
От: Андрей Хропов Россия  
Дата: 17.11.06 17:12
Оценка: +1 -1
Здравствуйте, WolfHound, Вы писали:

E>>Вывод типов есть и в D, вообще-то говоря.

WH>Надеюсь ты не про это
WH>
WH>auto test = new Testing(1, 2, 3);
WH>

WH>
WH>Так вот по сравнению с неммерле это вобще ерунда.
Зато самое нужное.
Еще бы в D добавили вывод типов для аргументов лямбд, тогда было бы все нормально вообще.

E>>А то, что D такой долгострой, так это вообще лично мне не понятно. Видимо, Брайт считает, что спешить особо не нужно. D нацелен на нишу C++, вытеснить оттуда C++ полностью вообще не получится, а вот отвоевать свое место вполне возможно.

WH>На кой черт этот мутант там вобще нужен?
WH>Если нужно выжимать биты из быйтов то нужен либо обыкновенный С/С++
А зачем C/C++ если есть лучше их — D?

WH> либо совершенно иная нежели CLR и JavaVM виртуальная машина.

Какая?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[15]: Ой, чо с D деется-то!?
От: WolfHound  
Дата: 17.11.06 17:36
Оценка:
Здравствуйте, Андрей Хропов, Вы писали:

WH>>Это можно достичь только на асме и только очень долго вылизывая код. А порвать С/С++ имея качественную модель ВМ не сложно.

АХ>Зависит от задач.
Нет. Не зависит.
АХ>Для тех где много мелких хаотично связанных объектов создается — да, GC рулит.
АХ>Для задач где много вычислений (+ грамотно написанных) — вряд ли.
У нас есть два ЯВУ.
Первый переводится в промежуточное представление где все строго определено.
Второй переводится в представление в котором куча скользких мест.
Какой ЯВУ оптимизировать легче?
АХ>Хоть Java с HotSpotом и приближается, но
А причем тут жаба? Я же оже говорил что ее ВМ плохо подходит для системных вещей. Ее вобще проектировали не для тяжелых вычислений, а для интерпритации мелких управляющих программок.
АХ>1) Оверхед по памяти велик, а значит меньше размер задач которые вообще влезают в пямять + менее эффективно используется кэш
Для жабы да. Для .НЕТ это уже не совсем верно. А если проектировать систему в расчете на вычисления то там все совсем по другому можно переиграть.
АХ>2) Сам HotSpot отъедает ресурсы.
По мне так это вобще тупиковая идея.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[5]: Ой, чо с D деется-то!?
От: WolfHound  
Дата: 17.11.06 17:36
Оценка: +2
Здравствуйте, Андрей Хропов, Вы писали:

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

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

WH>>Все что нужно это value-типы, поддержка двоичных данных на уровне виртуальной машины и оптимизатор который умеет делать region-inference. Еще нужно иметь несколько различных алгоритмов сборщика мусора в том числе подсчет ссылок и вобще отсутствие сборщика мусора (работает только region-inference).

АХ>Не согласен.
АХ>Помимо этого должна быть возможность вообще не пользоваться сборщиком мусора,
Перечитай еще раз что я сказал.
АХ>не должно быть обязательной зависимости от большого рантайма (для встроенных систем и вообще где мало памяти),
Это совсем не проблема.
АХ>должен быть встроенный ассемблер (желательно с легко настраиваемым под конкретную архитектуру набором инструкций)
Только для загрузчика. А для этого проще внешний язычек прикрутить.
АХ>и указатели (можно (и даже неплохо) их конечно поместить в отдельный unsafe-загон, как в C#, но они должны быть, хотя бы для того чтобы реализовывать сборщики мусора).
У меня есть некоторые мысли на эту тему но я их сейчас думаю. Кгда додумаю напишу.
АХ>Также должны быть средства жесткого задания бинарного представления в структурах (в D есть шаги в этом направлении).
Я про это и говорил когда говорил про работу с битами на уровне ВМ.

АХ>На языке для системного программирования должно быть можно написать ядро ОС.

Есть только один язык на котором можно полностью написать ядро ОС. Это асм...
Если же С/С++ возводим в ранг системнах то и C# (и оберон) попадает тудаже...
АХ>Ядро в Singularity написано на assembler + C++ + С# (safe и unsafe).
АХ>Хотя неверифицируемая часть состоит всего из 5% кода.
5% это много. Должно быть много меньше.

АХ>Как в текущей реализации D.

АХ>Да, вот и надо приделать к D точный копирующий GC.
hint: union

АХ>Почему? Надо только разобраться с вопросом можно ли (и как) работать с указателями на GC объекты.

С указателями на ГЦ объект работать нельзя никак.
Иначе ни какого точного ГЦ не будет ни когда.

АХ>Дизайн D вообще говоря меняется.

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

С языками программирования как и интерфейсами объектов. Есть толстые и есть тонкие.
Толстые с виду проще но если нужно сделать что-то чего не предусмотрено то все... тушите свет...
Вот D это толстый язык, а немерле тонкий.
Вот попробуй к D прикрутить late.
Что не можешь? Нужно уговаривать автора?
А к немерле его прикрутил человек не имеющий к самому компилятору никакого отношения.
Таким образом ребята сейчас фиксят баги в ядре, а фенечки наворачивают совершенно посторонние люди.
Причем если к D прикрутить что-то типа late то он появится у всех. Даже у тех кому он не нужен. В случае с немерле все это прекрасно рулится при помощи подключения библиотек с расширениями и using.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[9]: Ой, чо с D деется-то!?
От: Андрей Хропов Россия  
Дата: 17.11.06 17:40
Оценка: +1
Здравствуйте, eao197, Вы писали:

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

WH>>Ибо интерпритатор.
WH>>А для горячей замены не нужна ни интерпритация ни динамическая типизация. Это ортогональные понятия.

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


Ну для гибридных сред с JIT компиляцией — легко.

E>Зато они стали высказываться, что нынешняя реализация рантайма Ruby не так плоха, как про нее принято говорить. Сделать лучше не так уж и просто.


Вон для того же Pythonа Psyco есть, PyPy делают. Не вижу принципиальных проблем создать аналог для Руби.
А RubyCLR как — быстр?

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

Просто он один работает над компилятором (причем он еще и занимается другими своими проектами!), который написан в основном на низкоуровневом C, причем он работает еще и без IDE.

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

E>К тому же за прошедшее время D стал, как минимум, достаточно известным

Ну это на самом деле надувательство и результат некоторого SEO КМК. Более реально о популярности языков можно судить по числу вакансий (Статистика востребованности знания языков
Автор: Андрей Хропов
Дата: 08.11.06
).
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[11]: Ой, чо с D деется-то!?
От: WolfHound  
Дата: 17.11.06 17:41
Оценка:
Здравствуйте, Андрей Хропов, Вы писали:

АХ>Зато самое нужное.

АХ>Еще бы в D добавили вывод типов для аргументов лямбд, тогда было бы все нормально вообще.
А лично мне очень понраилось писать 170 без единого уточнения типа. Так что...

WH>>Если нужно выжимать биты из быйтов то нужен либо обыкновенный С/С++

АХ>А зачем C/C++ если есть лучше их — D?
Я тут
Автор: WolfHound
Дата: 17.11.06
уже писал что будет с D на моих задачах.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[6]: Ой, чо с D деется-то!?
От: Андрей Хропов Россия  
Дата: 17.11.06 18:06
Оценка:
Здравствуйте, WolfHound, Вы писали:

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

WH>Ну загрузчик по любому нужно писать на асме. Тут даже С не подходит.
C + inline asm

WH>А вот то что пишут на С уже можно писать на чемто болие высокоуровневом.

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

WH>>>Все что нужно это value-типы, поддержка двоичных данных на уровне виртуальной машины и оптимизатор который умеет делать region-inference. Еще нужно иметь несколько различных алгоритмов сборщика мусора в том числе подсчет ссылок и вобще отсутствие сборщика мусора (работает только region-inference).

АХ>>Не согласен.
АХ>>Помимо этого должна быть возможность вообще не пользоваться сборщиком мусора,
WH>Перечитай еще раз что я сказал.
region inference говоришь. И где-нибудь он реализован? Как это на практике работает?
Он все равно кажется не слишком предсказуемым. Это вроде статического GC как мне кажется или то что иногда называют memory pools.

АХ>>должен быть встроенный ассемблер (желательно с легко настраиваемым под конкретную архитектуру набором инструкций)

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

АХ>>Также должны быть средства жесткого задания бинарного представления в структурах (в D есть шаги в этом направлении).

WH>Я про это и говорил когда говорил про работу с битами на уровне ВМ.
понял

АХ>>Ядро в Singularity написано на assembler + C++ + С# (safe и unsafe).

АХ>>Хотя неверифицируемая часть состоит всего из 5% кода.
WH>5% это много. Должно быть много меньше.
Откуда такие выводы?

АХ>>Как в текущей реализации D.

АХ>>Да, вот и надо приделать к D точный копирующий GC.
WH>hint: union
Да выкинуть их давно надо. Я ими никогда не пользовался.
Хороший оптимизатор все равно в случае чего (если это безопасно) может соптимизировать распределение памяти.

АХ>>Почему? Надо только разобраться с вопросом можно ли (и как) работать с указателями на GC объекты.

WH>С указателями на ГЦ объект работать нельзя никак.
WH>Иначе ни какого точного ГЦ не будет ни когда.
Можно, только осторожно (например, специально помечая). Проще конечно запретить.

АХ>>Дизайн D вообще говоря меняется.

WH>Дык. Надо же с самого начала все продумывать, собирать информацию о других языках... проанализировать к чему приведет то или иное решение.
WH>А автор D этого не сделал... вот теперь и мучается...
WH>С языками программирования как и интерфейсами объектов. Есть толстые и есть тонкие.
WH>Толстые с виду проще но если нужно сделать что-то чего не предусмотрено то все... тушите свет...
WH>Вот D это толстый язык, а немерле тонкий.
WH>Вот попробуй к D прикрутить late.
WH>Что не можешь? Нужно уговаривать автора?
WH>А к немерле его прикрутил человек не имеющий к самому компилятору никакого отношения.
WH>Таким образом ребята сейчас фиксят баги в ядре, а фенечки наворачивают совершенно посторонние люди.
WH>Причем если к D прикрутить что-то типа late то он появится у всех. Даже у тех кому он не нужен. В случае с немерле все это прекрасно рулится при помощи подключения библиотек с расширениями и using.

Согласен. Вальтер на мой взгляд не слишком хороший разработчик языков. Хотя хороший разработчик быстрых компиляторов.

Если бы я сам выбирал на чем разрабатывать, я бы выбрал Nemerle основным языком и С++ или D для критических по скорости и затратам памяти частей.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[7]: Ой, чо с D деется-то!?
От: Cyberax Марс  
Дата: 17.11.06 18:28
Оценка:
Андрей Хропов wrote:
> WH>Перечитай еще раз что я сказал.
> region inference говоришь. И где-нибудь он реализован? Как это на
> практике работает?
> Он все равно кажется не слишком предсказуемым. Это вроде статического GC
> как мне кажется или то что иногда называют memory pools.
Ага, RI — это автоматический вывод memory pool'ов. Сам по себе в чистом
виде — бесполезен, так как часто вызывает огромный overhead.

Есть в Cyclone — там для юзабельности добавлены refcounted-пулы (и
возможность ручной аннотации пулов для указателей).
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[10]: Ой, чо с D деется-то!?
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 17.11.06 18:34
Оценка: +1 -2 :))
Здравствуйте, Андрей Хропов, Вы писали:

АХ>А RubyCLR как — быстр?


.NET лежит вне сферы моих интересов.

АХ>Просто он один работает над компилятором (причем он еще и занимается другими своими проектами!), который написан в основном на низкоуровневом C, причем он работает еще и без IDE.


Да, IDE -- это наше все. Как же без этого, просто за компьютером без IDE сидеть невозможно. Ну никак.
Брам Мооленар делает VIM на C без IDE. Замечательный результат получается. Наверное, он делает что-то не так.
А вот Брайт каждые две недели новый релиз выпускает, с новыми фичами и багфиксами. Видимо он так же что-то не так делает. Ламер, должно быть. Не то что мы, завсегдатаи Философии Программирования.

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


Как-то пример Perl, Python и Ruby показывает, что это не страшно.

E>>К тому же за прошедшее время D стал, как минимум, достаточно известным

АХ>Ну это на самом деле надувательство и результат некоторого SEO КМК. Более реально о популярности языков можно судить по числу вакансий (Статистика востребованности знания языков
Автор: Андрей Хропов
Дата: 08.11.06
).


Не нужно путать известность (что и меряет TIOBE) и восстребованность (что показывает список вакансий).
Тем более, что восстребованность определяет популярность на данный момент. Если по ней судить, то не только D, но и хваленый Nemerle находится в полной ж... И вообще бы дальше COBOL-а и Fortran-а программирование не ушло.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[12]: Ой, чо с D деется-то!?
От: Андрей Хропов Россия  
Дата: 17.11.06 18:35
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Андрей Хропов, Вы писали:


АХ>>Зато самое нужное.

АХ>>Еще бы в D добавили вывод типов для аргументов лямбд, тогда было бы все нормально вообще.
WH>А лично мне очень понраилось писать 170 без единого уточнения типа. Так что...
Что такое 170?

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

WH>>>Если нужно выжимать биты из быйтов то нужен либо обыкновенный С/С++

АХ>>А зачем C/C++ если есть лучше их — D?
WH>Я тут
Автор: WolfHound
Дата: 17.11.06
уже писал что будет с D на моих задачах.

1) Не надо GC — не используй. new/malloc с тобой.
2) Возможно появится D с точным GC (ну или почти точным, но не сильно медленнее). Я у них там в форуме за это буду агитировать .
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.