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

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

MF>>что в нем хорошего, в нем даже return обязателен, хотя могли бы не делать обязательным.

_>А зачем делать необязательным?

для упрощения.

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

I>>В джаваскрипте метапрограммирование уже отменили ?

_>Ты про функцию eval что ли? ))) Это даже близко не оно...

Во первых, метапрограммирование в js доступно безо всякого eval и подобных техник.

Во вторых, возможности абсолютно одинаковые с теми, что ты показал

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

I>>Зато есть люди, которые неспособны писать код на динамическом языке.

DM>Разумеется. Все люди такие. Просто некоторые наивно думают, что они могут.

Очевидно "все" это ты и пару твоих знакомых

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

I>Очевидно "все" это ты и пару твоих знакомых

Очевидно, тебе незнакомо слово "все".

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

_>Да, очень похоже. Жаль нет времени сравнить самому удобство и производительность. Правда после привыкания к наличию мощного метапрограммирования, все языки без него кажутся уже не такими удобными... ))) А вообще ocaml мне когда-то весьма нравился.

Тык OCaml (с Camlp4) как раз и есть язык с весьма мощным метапрограммированием

FR>>F# — WebSharper

_>А вот здесь уже немного другое. Здесь уже классическая традиция MS видна: фреймворк всё за тебя делает, но при этом шаг влево или вправо — расстрел. ))) Лично я против подобной смеси клиентского/серверного кода. Ну и наконец производительность самого F# в сравнение C++/D/Ocaml... )))

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

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

MF>>что в нем хорошего, в нем даже return обязателен, хотя могли бы не делать обязательным.

_>А зачем делать необязательным?

Отмена обязательного return это следсвие возможности рассматривать любой блок кода как выражение.

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

C>>Такое тоже было, для Java в том числе. Есть даже для Питона (mako), с JIT'ом от PyPy будет сравнимо с D.
_>Хыхы, похоже ты совсем не в курсе что такое D. Его главный компилятор (dmd) заметно уступает только C++, но эффективнее Java. А JavaScript или вообще Python (даже с PyPy) ещё хуже Java.
Да в курсе я про D. Быстрее он только на детских benchmark'ах. Если нужно что-то серьёзное, с большим количеством памяти и не дай б-г многопоточностью — всё упс.

C>>JSP компилируется в Java, которая работает быстрее D. В частности, из-за нормального мусоросборщика, а не D-шного угрёбища.
_> Кстати, нормальный код на D может практические не использовать GC (переменные на стеке и т.п. в лучших традициях C++). В том же обсуждаемом фреймворке основные типы данных объявлены как struct, а не как class и соответственно при работе с ними GC обычно не затрагивается.
И что? В реальных программах данные не в стеке лежат. Добавляем сюда ещё отсутствие нормального межпоточного разделения данных и вообще всё уныло.

_>Я уже не говорю про эффективную работу с иммутабельными (а все строки из шаблонов как раз такими и являются) данными...
Нет там эффективной работы. Она есть только в Rust.

_>Эээ что? ) Вот допустим берём jsp. Тут часто используют TomCat. Так вот какова схема работы TomCat, какую нагрузку он способен выдерживать, есть ли автобалансировщик и т.п.?
Ну как обычно — рендериться страничка, отдаётся в буффер, Tomcat его пихает в сокет. Масштабируемость зависит от прикладного кода.

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

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

_>>Ну в общем да. Только с использованием высокопроизводительного статически типизированного компилируемого языка — это уже не такая обычная вещь. )))

FR>Для малопопулярных статически типизированных языков вполне обычная:

FR>OCaml — Ocsigen
FR>F# — WebSharper

Эээ, а си шарп — тоже малопопулярный???

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

A>Да найдутся — просто лень писать, будет многа букав. Позволю одно замечание: злоупотребление шорткатами это плохо. У меня сложилось впечатление, что это основная цель этого языка. K примеру, C++ не отбирает у меня контекст, он не говорит, мол вы итак понимаете контекст, поэтому он не нужен. Как раз нужен! Я не писатель, я читатель.

Не очень понимаю о чём речь. Лично я как раз максимально привычен к C++, но при этом на D коде (особенно шаблонном) реально отдыхаю и наслаждаюсь... )

A>Только одна иллюстрация
A>

template procedural(alias formula)

A>Это шаблон класса, структуры или функции? Я не должен видеть тело, чтобы это понять.

Эээм, если речь про шаблоны классов/структур/функций в значение C++, то они записываются в D совершенно по другому (вообще без специальных ключевых слов, просто появляется дополнительный набор параметров). А ключевым словом template в D обозначаются так называемые "параметризованные контексты" — вообще отдельная вещь, точного аналога которой в C++ нет.

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

MF>для упрощения.

Не вижу никакого упрощения. Если надо возвращать некое значение, то нам всё равно придётся записать его отдельно в конце. Так в чём тогда простота, в экономии лишнего слова? )

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

I>Во первых, метапрограммирование в js доступно безо всякого eval и подобных техник.
I>Во вторых, возможности абсолютно одинаковые с теми, что ты показал

Угу, в рантайме то вообще всё что угодно можно творить. Но я подобное не считаю нормальным метапрограммированием. Оно тормозное и непроверяемое (на стадии компиляции). Т.е. формально говоря это конечно же МП, но на практике лучше уж без него. )))

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

FR>Тык OCaml (с Camlp4) как раз и есть язык с весьма мощным метапрограммированием

Хы, ну с этой штукой OCaml и посильнее D становится, не говоря уже о плюсах. Но оно всегда казалось некой отдельной сущностью, а не частью языка. Т.е. вот в C++ и D шаблоны и макросы используются не только для каких-то "особенных" вещей (ну типа boost.spirit и т.п.), но и вообще повсеместно в рядовом простейшем коде для ускорения работы. А Camlp4 для таких дел кажется как-то не нормально подключать.

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

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

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

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

MF>>для упрощения.

_>Не вижу никакого упрощения. Если надо возвращать некое значение, то нам всё равно придётся записать его отдельно в конце. Так в чём тогда простота, в экономии лишнего слова? )

Да, в экономии отдельного слова.

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

XC>Отмена обязательного return это следсвие возможности рассматривать любой блок кода как выражение.

И? Какие преимущества имеем с этого? )

Кстати, в лямбда-функциях естественно можно и без return. Не пойму даже почему в плюсах так не сделали.

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

C>Да в курсе я про D. Быстрее он только на детских benchmark'ах. Если нужно что-то серьёзное, с большим количеством памяти и не дай б-г многопоточностью — всё упс.

Ждём пруфлинк тогда. )

C>И что? В реальных программах данные не в стеке лежат. Добавляем сюда ещё отсутствие нормального межпоточного разделения данных и вообще всё уныло.

Как раз с межпоточным там всё удобно. Причём есть несколько разных возможных уровней работы. Можно работать на самом низком уровне (мьютексы и т.п. как в том же C++), можно на более высоком уровне синхронизации (как в java и т.п.), а можно использовать готовую полноценную систему акторов (как в эрланге). Последнее мне нравится больше всего. И всё это поддерживается соответствующими моделями памяти.

Но что самое интересное, в контексте нашей текущей беседы (фреймворка vibe.d) это всё вообще не актуально, т.к. фреймворк базируется на классической асинхронной схеме со своими лёгкими потоками.

C>Нет там эффективной работы. Она есть только в Rust.

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

А что касается Rust'а... То он же ещё пока даже близко не является готовым языком программирования. Так, какие-то наброски пока. Ну и кстати из того, что уже есть, он выглядит скорее как замена языку C, а не C++.

C>Ну как обычно — рендериться страничка, отдаётся в буффер, Tomcat его пихает в сокет. Масштабируемость зависит от прикладного кода.

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

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

_>Угу, в рантайме то вообще всё что угодно можно творить. Но я подобное не считаю нормальным метапрограммированием.

Это именно нормальное метапрограммирование, при том, что есть все остальные виды.

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

Вообще то наоборот, оно лучше чем eval, и без него в современном JS вообще ничего не делается.

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

_>Угу, в рантайме то вообще всё что угодно можно творить. Но я подобное не считаю нормальным метапрограммированием. Оно тормозное и непроверяемое (на стадии компиляции). Т.е. формально говоря это конечно же МП, но на практике лучше уж без него. )))

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

var result = start().x().y().z();

Все функции в либе асинхронные, имеют два колбека — success, error, а вот код который я привел выглядит как обычный синхронный.
Джаваскрипт требует смешное количество кода, что бы убрать спагетти из колбеков. Попробуй для сравнения тоже самое в С++ или D.

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

Под контекстом я как раз понимаю то, что С++ явно называет и выделяет все конструкции, а D нет. Например в С++ шаблон это template<typename T>, в D это (Т). Для меня, незнаюшего контекста, было трудно понять, что такое (Т), потому что также записываются и вызов функции, и параметры функции. Естественно можно сказать, что проблема взята из ниоткуда, ибо если я знаю контекст, то она сразу же исчезает, но мне не нравится общая тенденция без какой-либо видимой причины использовать контекстно-зависимый синтаксис.

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

A>Под контекстом я как раз понимаю то, что С++ явно называет и выделяет все конструкции, а D нет. Например в С++ шаблон это template<typename T>, в D это (Т). Для меня, незнаюшего контекста, было трудно понять, что такое (Т), потому что также записываются и вызов функции, и параметры функции. Естественно можно сказать, что проблема взята из ниоткуда, ибо если я знаю контекст, то она сразу же исчезает, но мне не нравится общая тенденция без какой-либо видимой причины использовать контекстно-зависимый синтаксис.

С++ явно называет и выделяет все конструкции? По-моему, С++ один из самых зависимых от контекста языков (если не самый).
Например, что это?

  a(b);

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

A>Например в С++ шаблон это template<typename T>, в D это (Т). Для меня, незнаюшего контекста, было трудно понять, что такое (Т), потому что также записываются и вызов функции, и параметры функции.
Честно говоря, не понимаю где тут проблема. На Д ведь шаблоны обьявляются так:

void foo(T)(T x)

Как это можно с обьявлением простой функции спутать? Тут же два "списка параметров". То есть разница есть. Или речь про то, что подумает человек не знающий синтаксиса? Ну тогда он и в С++, в не меньшей степени, потеряется.