Здравствуйте, igna, Вы писали:
I>Здравствуйте, Disappear, Вы писали:
D>>Практика программирования уже успела многое сказать о пригодности интерфейса STL
I>Что именно? Что приходится думать больше чем собственно надо? Зато можно передавать заказчику исходный текст качественно написанной программы не опасаясь, что для сопровождения он наймет кого-нибудь подешевле. И вообще, круто и не для средних умов.
Здравствуйте, Kisloid, Вы писали:
K>Вообще то, он изначально разрабатывается под Mono (свободная реализация .net, есть и под Линукс, Винду, МакОС). Существует уже достаточно давно.
В Mono реализованы те же библиотеки классов, что и у MS? Интерфейс, сети и т.п.? Сорри за навязчивость, но сам я с .NET не работал.
Здравствуйте, ie, Вы писали:
N>>Для обработки изображений (чем я и занимаюсь) не так уж и много языков подходят. На чём мне ещё писать?
ie>Тот же D будет несомненным шагом вперед
Да? Я, вот, работаю и не ощущаю никаких неудобств, связанных с С++. Это, значит, плохо? Сложности возникают при разработке алгоритмов, а реализуется всё достаточно быстро и в срок.
Далее: тут приводится куча аргументов о скорой смерти С++ (а значит и D) в связи с развитием С#/Nemerle. Зачем же мне учить мертворожденный язык?
Здравствуйте, Disappear, Вы писали:
D>Не у всех ведь мозг превратился в кость. Человек разумный — способен разумно выбирать. Без фанатизма.
Не у всех конечно. Но я то говорил о закономерности. А она на лицо.
Ды ты вот на свои рассуждения погляди. Ты спрашиваеш у людей почему бы в место устаревшего 10 лет назад языка не использовать новый который чуть лучше чем предыдущий. Но даже не задумываешся над тем, что он так же морально устарел.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Cyberax, Вы писали:
C>Не совсем так — там просто никто особо и не заботился о точном GC. Сам C>язык, в общем и целом, позволяет использовать точный GC, но есть C>несколько вещей, которые его запрещают (типа объединений в стиле С).
Там таких мест достаточно.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Disappear, Вы писали:
D>Читал про nemerle немного. Выбивает интерес сразу то, что язык работает через .NET CLI (как и любую другую VM)
А у тебя задачи которые требуют нэйтив-код? Ты драйверы для Виндовс, что ли пишеш?
D>Субъективно конечно — но синтаксис мне не понравился, как-то скептически отношусь к добавлению функционала через всяческие синтаксические причуды (закорючки и пр.)
Вот видишь? А что же ты хочешь от других С++-программистов? Ты такой же блаб как и они. Ну, чуть-чуть более продвинутый. Но это ничего не меняет. Ты точно так же смотришь не более мощьный язык как на нечто странное с причудами. И у тебя точно так же не возникает желания сесть и разобраться что это за причуды и почему они были придуманы. А если бы напрягся, то глядишь Ди тебе уже и не показался бы каким-то там продвинутым.
D>Вы отчаянный Nemerle-ист!
Я не отчаянный и не Nemerle-ист.
Я вообще не -ист, и не -аст. Я просто не блалб который не может выйти за узкие рамки собственных привычкек и знаний.
D>А я C++ шник, все же.
Я 10 лет писал на С/С++. Так что кто из нас больше С++-ник еще можно поспорить.
D> Но нужно ведь постоянно что-то улучшать, адаптироваться и развиваться.
Зачем? С является вполне достаточным для написания любых программ. У него даже есть свои немалые приемущества. Он, например, отлично переносится на любую платформу.
С++ уже не изменялся с 98-го года (почти 10 лет). И все (почти все) им пользуются.
D> За 9 лет со времен принятия первого стандарта С++ многое изменилось, для IT индустрии такой срок — целая вечность.
Это твое воображение. На самом деле для людей которые что-то понимал в этой индустрии все изменилось еще 25 лет назад.
С++ в качестве прототипа имел язык окторый и сейчас во многом его привосходит — Simula. Этот язык в те времена имел средства рефлексии, вирутальные методы, GC и многое другое. Все это Страуступ принес в угоду производительности. Прошло 20 лет. GC и все остальное уже не вызвает существенных проблем с произодительностью, но никто этого не замечает. Ведь С++ откровенно проутюжил мозги массам и оболванил их до собсвтенного уровня. Целое поголение программистов смотрит на мир глазами С++.
D>Эх.. раз уж теперь эта ветка о философии.
Здесь эта ветка просто спешна. А вот в С++ она была грустна. Так как не может быть ничего грустнее чем борьба одной посредственности с другой.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, konsoletyper, Вы писали:
D>>Читал про nemerle немного.
K>Надо было не немного. Именно из-за немного срабатывает парадокс Блаба.
Это как раз самое прикольное. Ведь он тут уже разбился об стену непонимания со стороны своих коллекг С++-ников которые точно так же "немного почитали о Ди".
Но спроецировать на себя он это просто не в силах. Ведь то что он пока не постиг для него "что-то непонятное и закарючистое", а Ди понятен и логичен. Вот только чего при таком подходе ждать от других то? Для них Ди точно так же непонятен и закорючист.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Disappear, Вы писали:
D>Минусы VM: D>- Это всегда ряд ограничений при сближении с платформой. Все зависит от VM, но в хорошей VM этих ограничений должно быть больше. D>- Прерывания, порты ввода вывода, управление памятью и другая жизненная реальность — все это скрыто под занавесом виртуальной машины. D>- Код под виртуальной машиной всегда будет медленнее native кода. Это элементарные законы математики, тут ничего нельзя изменить. Никакие технологии, и отчаянные попытки маркетологов не убедят в обратном.
Это набор фибий. То что ты называешь "ряд ограничений" — это на самом деле назвается более высокий уровень абстракции.
Прирвывания и порты недоступны тебе так как сорверменная ОС не позоляют получить прямой доступ к ним. А через посредников ты можешь получить к ним доступ хоть из ЯваСкрип.
Скорость моего кода работающего на VM значительно выше чем кода большинства программистов гордящихся тем, что они пишут на С++. Ведь скорость исполнения не меняется (инструкции процессора то те же), а вот возможностей по алгоритмической отимизации у меня болше (потому что язык выше уровенм, и я заню по более).
D>Это только минусы, есть конечно ряд хороших плюсов. Но как не печально, все это не подходит для C++ программистов, которые привыкли "ощущать" работу программы.
Эти минусы ни что иное как фобии. Так что же ты хочешь когда сталкиваешся с такими же фобиями по отношению к Ди? Нормальный процесс.
K>>Какие именно закорючки не понравились? Чем вообще синтаксис плох?
D>Говорю же — субъективно. Как С++ программисту, нравится С/C++ синтаксис, а лучше — если он проще, как в D.
Ну, а какие тогда претензии к тем, для кого Ди закорчюки "чисто субъективно"?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Nuzhny, Вы писали:
N>И это простой и понятный пример? Множество скобок и др. символов лично для меня не вполне читабельны. Все программы на Немерле так выглядят?
Ну, давай сравним с оригиналом.
Возмем саму функцию (на D):
Могу переписать ее более "понятно" для тех кто привык только к С++:
Factorial(n : uint) : ulong
{
if (n == 0 || n == 1) 1
else n * Factorial(n - 1)
}
Она правда корректна по сравнению с оригиналом (где в случае n < 1 будет зацикливание), но все же.
Где здесь какие-то лишние скобочки или еще что-то?
Теперь думаем что мы получили и как можем использовать. А получили мы рекурсивый шаблон на D. Использовать этот шаблон мы может только во время компиляции. Вычисляться он будет в режиме интерпретации.
На Nemerle мы получили просто функцю. Мы можем вызвать ее в программе как любую другую. Теперь чтобы вычислить эту функцию во время компляции мы просто помещаем ее вызов в макрос:
в котором мы производим вычисление и помещаем результат вычисления код генерируемый макросом.
В обличии от D или C++ мы вольны произвести в макросе вычисления любой сложности. Так если у нас уже есть нужная функция которую нужно вычислить во время компиляции, то мы просто вызваем ее в макросе и получаем требуемый результатм.
То есть для нас нет разницы между кодом программы и метакодом. В D же и в С++ мы вынждены писать метакод на птичьех языках которые сильно отличаются от того языка что мы вынуждены применять в реальной программе.
Что тут непонятного? Возможно:
<[ $(res : ulong) ]>
да, это новое для D/C++-программиста. Но объяснить это не так то и сложно.
Это способ сгенерировать код. Подобных средств в D и С++ попросту нет. Потому и сравнивать тут нечего.
<[ ]> — это аналог строкового литерала в C++, но в отличии от С++ внутри этого литерала получается не страка, а выражение которое можно подставить в программу. Другими словами <[ ]> выделяет участки кода которые интерпретируются компилятором не как исполняемый код, а как заготовка для генерации кода.
$ — позвляет состалься в этой заготовке на переменные из внешнего кода. Так что мы, например, может написат так:
<[
if ($x)
SomeCall();
else
$x
]>
и значение "x" будет подставлено в те места где пы указали $x. Толко значнеие "x" будет интерпретироваться как участок кода. Так что если мы подставляем некий литерал, то нам нужно указать компилятору, что его нужно преобразовать в код. Так $(res : ulong) говорит, что значение из внешней (мета-) программы нужно преобрзовать в литерал (в компилируемой программе).
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Nuzhny, Вы писали:
N>Причём тут С++? Сами же привели несколько нормальных вариантов. Могу ещё школу вспомнить и Паскаль с Бейсиком — будет читабельно (не обязательно кратко).
Ну, вот и подумай насколько это глупый код!
Ты не сможешь его вызвать из программы. Он доступен только во время компиляции.
Я же свой код могу вызвать как во время компиляции, так и во время исполненения.
Это будет один и тот же код. Более того, он будет скомпилированным! И выполнится очень быстро.
Твой же код будет интерпретироваться компилятором. Конечно factorial-а это не проблема. Но мы же говорим не о нем?
Понимаеш ли, подход ди чуть лучше чем С++. В нем в отличии от С++ есть явные средства для вычислений времени компиляции. Но все равно подход D ущербен. Ведь в нем прикладной код нельзя испльзовать во время компиляции.
В Nemerle же ты имешь возможность написать просто код и использовать его где тебе надо.
То есть мета-язык и просто язык — это одно и тоже!
D>кроме-того оптимизатор, может в compile-time посчитать такие функции: D>int factorial(int n) D>{ D> if (n == 1) D> return 1; D> else D> return n * factorial(n — 1); D>}
D>static int x = factorial(5);
D>Факториал — это только простейший пример, зачем на основе него строить какие-то выводы.
В том-то все и дело. Факториал — это примитившена.
Тут (на этом форуме) как то народ попытася повторить прмитивнеший пример реализованный на Немерле — реалзовать автоматический генератор паттерна "Абстрактная фабрика". И что ты думашь? Ни на С++, ни на D этот пример полностью поторить так и не удалось! http://rsdn.ru/Forum/Message.aspx?mid=2311589&only=1
Что-то удавалось, но на 100% все равно не получилось. Фабрика была или статичная, или ограниченная.
И это в том время как у парня реализовавшего фабрику на макросах Немерле ушло на ее реализацию не более часа времени.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Дм.Григорьев, Вы писали:
ДГ>Блин, Немерле, Немерле... Хватит дразниться, в конце концов!!!
А кто дразнит то?
ДГ>1. Что слышно насчет реализаций под линукс, и/или свободных реализаций? Когда ожидать?
К сожалению никаких новостей... с тех пор как была выпущена первая версия Nemerle она отлично работает под Моно на любой платформе где Моно поддерживается (включая Линуксы, МакОС и т.п.). Так что никаких новостей.
ДГ>2. И во что дело упирается — в нормальную VM? Не верю. Что им мешает в натив компилять?
Видимо то, что нормальная VM несколько более продвинутое решение нежели примитивная компиляция в нэйтив. VM обеспечивает не толкьо компиляцию в нэйтив, но и качественный GC, рефлексию, динамическую компиляцию, защиту, переносимость, библиотеки и т.п. Реализовать подобное чудо в рамках открытого проекта очень не просто. Пока что это чудо удалось только в Моно и Яве. И то Ява это проект скорее пропроитарный.
ДГ>3. Поддержка со стороны IDE, кроме VS + твоей интеграции?
А зачем "кроме". В прочем думаю будет еще интеграция с МоноДвелоп-ом.
ДГ>4. Вообще, какова текущая ситуация? Что куда компилируется и где это 'куда' может работать? ДГ>Спасибо.
Ситуация такая. Исходники компилирются в сборки и работают под MS .Net Framework или Mono.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Дм.Григорьев, Вы писали:
ДГ>Еще вопрос: область применения, точнее наличие библиотек. В частности:
ДГ>- построение графических интерфейсов (и какова степень развитости этой либы)
MS Forms, #GTK, WPF. Развитие недостижимое для С++-библиотек.
ДГ>- коннекторы к SQL серверам
Любые доступные под Моно и дотентом. Фактически ко всем современным СУБД.
ДГ>- поддержка сетей (в частности, http(s)-клиента)
Все, в общем, и в частности.
ДГ>- возможности использования для серверной разработки
Полные, в общем, и в частности.
ДГ>- что ещё?
Черт его знает.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Курилка, Вы писали:
К>Насколько я понимаю, всё это определяется платформой на которой работает немерле — .Net, думаю что есть в нём, ты в курсе.
+ еще Моно.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Дм.Григорьев, Вы писали:
ДГ>Как-то не особо верится, что объектные либы от C# легко прикручиваются к немерле. Хочется услышать подтверждение от главного немерлиста.
Это не предмет веры. Никаких "объектных либ" в природе не существует.
Существуют сборки. Они одинаковы (бинарно) для Моно и дотнета. Сборка скомпилированная из C#-искходников без проблем используется из Nemerle и наоборот.
Все что нужно сделать — это добавить ссыку на сборку. Сделать это можно или в Студии с помощью соотвествующего диалога, или из командной строки. Например, чтобы подключить сборки WinForms (из .Net Framwork) написанную на C# к проекту на Немерле нужно вызвать компилятор следующим образом:
ncc.exe /r:System.Windows.Forms.dll test.n
Собственно проект Интеграции со Студие состоит из проектов на C# и Nemerle взаимодействующих между собой. Никаких проблем при этом не возникает.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Nuzhny, Вы писали:
ie>>Тот же D будет несомненным шагом вперед
N>Да? Я, вот, работаю и не ощущаю никаких неудобств, связанных с С++. Это, значит, плохо? Сложности возникают при разработке алгоритмов, а реализуется всё достаточно быстро и в срок.
Ну дык неудобства начинаются после того, когда есть что сравнивать. А если кроме C++ ничего не видеть, то и неудобствам возникнуть то неоткуда.
N>Далее: тут приводится куча аргументов о скорой смерти С++ (а значит и D) в связи с развитием С#/Nemerle. Зачем же мне учить мертворожденный язык?
Учи Nemerle, но учти(!) после его использования хотя бы в одном проекте возникает жуткая ломка при возвращении к прежним языкам
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Disappear, Вы писали:
D>>Не у всех ведь мозг превратился в кость. Человек разумный — способен разумно выбирать. Без фанатизма.
VD>Не у всех конечно. Но я то говорил о закономерности. А она на лицо.
VD>Ды ты вот на свои рассуждения погляди. Ты спрашиваеш у людей почему бы в место устаревшего 10 лет назад языка не использовать новый который чуть лучше чем предыдущий. Но даже не задумываешся над тем, что он так же морально устарел.
Я не считаю, что если язык является static typed и native compiled, то его можно считать морально устаревшим.
Есть разные идеологии, и разные подходы. Для разработки ПО мирового масштаба по прежнему используются native языки.
