Здравствуйте, FR, Вы писали:
FR>Я имел в виду что есть ли пример на си и аналогичный пример на nim чтобы посмотреть FR>отстает ли и покопать почему.
перевести 2 строчки на С конечно огромный труд
FR>А так он и сейчас примерно тоже самое и генерирует, но я не уверен что while будет FR>хуже for'а оптимизироваться.
Здравствуйте, alex_public, Вы писали:
_>Только вот оно будет всего лишь процентов на 10 быстрее, т.е. данная правка к нашей проблеме отношения не имеет.
не может быть — этот цикл в идеале должен прокручиваться за 4 такта cpu и ничего быстрее ты не получишь. ты размер картинки уменьшил?
Здравствуйте, FR, Вы писали:
FR>>>Unlambda же карринг в полный рост, EP>>Да, внутри реализаций комбинаторов, и что? FR>Ну если есть каринг
Это всего лишь унарная функция возвращающая другую такую же унарную функцию.
FR>и замыкания лямбда не больше чем сахар в общем-то.
Нет там замыканий, там вообще нет ни параметров, ни переменных в явном виде — нет free variables, замыкаться не на что.
Это комбинаторы в чистом виде — point free style.
Здравствуйте, Ikemefula, Вы писали:
I>Напомнишь, на каких языках написаны инструменты джетбрейнс ? Как то так выходит, мейнстримные программисты зарабатывают столько, что хватает даже на команду нитры, котлина и десяток таких же.
А теперь подумай: Если мейнстрим языки такие хорошие, почему JetBrains тратит деньги на котлин и нитру?
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
I>>Напомнишь, на каких языках написаны инструменты джетбрейнс ? Как то так выходит, мейнстримные программисты зарабатывают столько, что хватает даже на команду нитры, котлина и десяток таких же. WH>А теперь подумай:
Могу предположить:
WH>Если мейнстрим языки такие хорошие, почему JetBrains тратит деньги на котлин
Kotlin — попытка захватить кусочек языкового рынка? + синергия к другим проектам.
WH>и нитру?
Парсинг языков, восстановление после ошибок, и т.п. — им нужны так как продают разнообразные IDE, и по всей видимости сделают ещё не одну новую IDE
Здравствуйте, FR, Вы писали:
FR>Да компилируется в C, C++, JavaScript, притом итоговая скорость компиляции очень высокая, не уступает FR>по моему D'шной, так-как сгенерированный код весьма тупой и линейный. FR>В общем тебе сюда http://nim-lang.org/
Судя по всему компиляция в C++ там только для взаимодействия, основной же target это C. То есть готовые фичи C++ (которых нет в C) — они использовать не будут, и придётся реализовывать их заново, насколько хорошо — большой вопрос.
Но да, надо будет пристальней посмотреть на этот язык.
Здравствуйте, BulatZiganshin, Вы писали:
FR>>Я имел в виду что есть ли пример на си и аналогичный пример на nim чтобы посмотреть FR>>отстает ли и покопать почему.
BZ>перевести 2 строчки на С конечно огромный труд
Ну как бы нет, но начал проверять и часик пролетел незаметно
var sum: int64 = 0
for i in 1'i64..<1_000_000_000'i64:
if i mod 2 != 0: sum += i else: sum -= i
echo sum
#include <stdio.h>
#include <inttypes.h>
int main()
{
int64_t sum = 0LL;
int64_t i;
for(i = 0LL; i < 1000000000LL; ++i)
if(i % 2LL != 0) sum += i; else sum -=i;
printf("%"PRId64"\n", sum);
return 0;
}
результат запуска (флаги для компиляции си скопировал из нима):
>~/bin/nim-0.11.2/bin/nim c --forcebuild -d:release --opt:speed --verbosity:0 "sum_nim.nim"
>Exit code: 0
>time -p ./sum_nim
500000000
real 0.91
user 0.91
sys 0.00
>Exit code: 0
>gcc -w -O3 -fno-strict-aliasing sum_c.c -o sum_c
>Exit code: 0
>time -p ./sum_c
500000000
real 0.92
user 0.91
sys 0.00
>Exit code: 0
Как бы разницы совсем нет.
FR>>А так он и сейчас примерно тоже самое и генерирует, но я не уверен что while будет FR>>хуже for'а оптимизироваться.
BZ>так сгенери и посмотри
Здравствуйте, Evgeny.Panasyuk, Вы писали:
WH>>Если мейнстрим языки такие хорошие, почему JetBrains тратит деньги на котлин EP>Kotlin — попытка захватить кусочек языкового рынка? + синергия к другим проектам.
Его делают в первую очередь для того чтобы самим писать на нём всё то что пишут на яве.
EP>Парсинг языков, восстановление после ошибок, и т.п. — им нужны так как продают разнообразные IDE, и по всей видимости сделают ещё не одну новую IDE
Это одна из причин. Вторая смотри выше.
Тут очень много умных людей. И они понимают, что греют вселенную своим непроизводительным трудом. Из-за этого все эти проекты и появляются.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Судя по всему компиляция в C++ там только для взаимодействия, основной же target это C. То есть готовые фичи C++ (которых нет в C) — они использовать не будут, и придётся реализовывать их заново, насколько хорошо — большой вопрос.
Ну судя по форуму основной разработчик языка как раз работает сейчас над С++ target
Хотя согласен пока все это очень сыро, но по моему уже лучше чем у D c C++ из коробки.
Плюс такая штука как http://nim-lang.org/docs/nimc.html#additional-features-emit-pragma
позволяет многое упростить, хотя оно и близко к хаку.
EP>Но да, надо будет пристальней посмотреть на этот язык.
Да, но сразу предупреждаю мелких багов и багофич полно, скажем итераторы местами очень
дурные
Здравствуйте, WolfHound, Вы писали:
I>>Напомнишь, на каких языках написаны инструменты джетбрейнс ? Как то так выходит, мейнстримные программисты зарабатывают столько, что хватает даже на команду нитры, котлина и десяток таких же. WH>А теперь подумай: Если мейнстрим языки такие хорошие, почему JetBrains тратит деньги на котлин и нитру?
Хрен его знает. У конккурентов ничего такого нет и тем не менее доминирует на рынке никак не jetBrains
FR>>Ну как бы нет, но начал проверять и часик пролетел незаметно
BZ>поэтому я и не хочу этим заниматься, я этот час в прошлом году уже потратил, свои выводы сделал
Не думаю что за часик можно хоть какое-то представление о языке получить.
Минимум по моему это хотя бы тысяча-другая строк на этом языке написанных.
Не спорю что nim сырой и местами угловатый, но думаю все это для опытного
с++ программиста мелочи, все вполне в пределах нормы для c++
FR>> if i mod 2 != 0: sum += i else: sum -= i
BZ>у меня был другой пример. в отличие от твоего, его при грамотном разворачивании цикла можно ускорить, хотя я не помню делал ли это сишный компилятор:
BZ>a=a*42+p[0] BZ>a=a*42+p[1]
BZ>превращается в
BZ>a=a*42*42+p[0]*42+p[1]
Возможно, в оптимизации всякое случается, но не думаю что будет вообще заметно в
среднем.
Здравствуйте, BulatZiganshin, Вы писали:
_>>Только вот оно будет всего лишь процентов на 10 быстрее, т.е. данная правка к нашей проблеме отношения не имеет. BZ>не может быть — этот цикл в идеале должен прокручиваться за 4 такта cpu и ничего быстрее ты не получишь. ты размер картинки уменьшил?
Вот если уменьшить, то да, будем наблюдать полноценный эффект ускорения. Но зачем нам её уменьшать, когда примеры с гораздо большим объёмом данных (и другим алгоритмом) тоже демонстрируют полноценное ускорение?) Правильнее алгоритм доработать... Только вот тут без ассемблера уже проблематично.
Здравствуйте, alex_public, Вы писали:
_>Что касается метапрограммирования на платформах jvm и .net, то на мой взгляд это не имеет большого смысла из-за самой ориентации этих платформ.
Зачем тогда придуманы и широко используются T4? И что тогда народ трахается с реализацией разных INotifyPropertyChanged?
Как раз задач которые требуют кодогенерации море. Просто часть людей не доросла до их решения с помощью МП, а часть готова возиться с текстуальной кодогенерацией без удобств, лишь бы не пользоваться ничем "левым".
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Mazay, Вы писали:
M>Тестов нет на шутауте, зато я привёл тесты по ссылке ниже. Так что наезд в силе.
По этим тестам разницы нет. Да и код там не эквивалентен.
M>Ничего подобного. Алгоритм и его реализация на конкретном языке — это разные вещи, разный уровень абстракции.
Ты эту лапшу на уши вешай школьникам, а не мне. На D можно повторить весь С-ишный код в точности до инструкции влючая ручные вызовы maloc. Но в тестах используется хардкорная версия на С и С++, и высокоуровневая на D. Это или жульничество, или эти тесты нельзя использовать для сравнения компиляторов.
Если ты этого не понимаешь, то мне жаль тебя, а разговаривать с тобой не интересно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, alex_public, Вы писали:
_>>>http://sysdev.me/rust-1-0-doubts/ _>>>http://eax.me/cpp-will-never-die/ DE>>...
_>На самом деле даже не важно имеют их аргументы смысл или нет. Важнее другое. Тут мы имеем примеры двух однозначных представителей целевой аудитории Rust, причём явно следящих за ним всё последнее время. Однако после его релиза они говорят о том, что всё же не будут его применять на практике. Т.е. значит что почему-то не зацепил в достаточной степени...
Вы уверены, что эти два авторе не являются одним и тем же нашим kaa?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, DarkEld3r, Вы писали:
DE>Как по мне, то приятен он разве что на фоне обжектив-С.
Нормальный язык. Есть пара странностей, но она как раз из-за наследия Обжектив-С (например, отсутствие перегрузок).
DE>Ну и "история успеха" тут несколько специфическая. Обжектив-С был языком, по сути, одной платформы. Владелец платформы делает новый язык именно с целью заменить старый. Вкладывает деньги, пиарит и т.д. Результат закономерный и всё равно далеко не "моментальный".
Моментального успеха и не бывает. Но в том, что Свифт проскочит в мэйнстрим я уверен. Язык вполне привычный. Бабло на его развитие и раскрутку имеется. Брэнд за ним серьзеный. Психологических проблем не будет. Единственное что может его загубить — изменение политики в Эппл. Но вряд ли это произойдет.
DE>Интересно будет понаблюдать как долго будут начинаться новые проекты на обжектив-С. И будет ли эпл насильно пересаживать на новый язык.
В этом нет смысла. Им важно только лишь осложнить кросплатформную разработку. Конкуренция между своими языками их не волнует. От того, что все останутся на Обжектив-С им ни горяче, ни холодно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, alex_public, Вы писали:
_>Ты не согласен с самими цифрами или с их источником?
Цифры высосаны из пальца. Их обсуждать — себя не любить.
_>Скажем так, C++ вполне конкурентен и без МП (хотя лично мне он такой уже не подходит) хотя бы за своё быстродействие. А вот у Nemerle без МП нет киллер-фич в сравнение с C#.
Немерл без МП (если в нем будет все что сделано макросами, но встроено в язык) лучше шарпа раз в 10. МС эти фичи за 10 лет повторить не смог. И я об этом абзацем ниже написал.
VD>>Ну, какого хрена загонять язык общего назначения в нишу "использование МП"? Язык по всем критериям лучше C#. Если исключить тулинг, то трудно найти код который бы оказался бы кратче или красивее будучи написанным на Шарпе. VD>>Но, почему-то ниша Шарпа, по твоему, шире чем ниша Немерла.
_>Не совсем так. Речь идёт о той нише, где есть смысл в переходе с C# на Nemerle.
В переходе есть смысл в любой нише. Если убрать проблемы присущие "самопальной" реализации, то у Шарпа просто нет ни одного приемущества, а у Немерла их масса. Он просто очень серьезный суперсет шарпа.
_>А так то понятно, что теоретически любой C# код можно заменить на Nemerle, только вот непонятно зачем тратиться на такой переход, не получая никаких ощутимых бонусов.
Затем чтобы не трахаться на ровном месте и не тратить свое время зря.
VD>>И? МП на шаблонах еще более сложная и невнятная штука. Как это тебе мешает использовать Буст и другие библиотеки?
_>А у Nemerle есть свой аналог Boost'а? )
Все что есть в Буст у немерла или реализовано в виде макросов, или уже имеется в стандартной библиотеке дотнета. Она, к твоему сведению, раз в 100 больше буста.
_>>>В то время как платформы Java и .Net ориентированны в первую очередь на внутрикорпоративную разработку VD>>Плюс это не совсем так. На дотнете и яве пишут различнийший софт. Тот же ReSharper и IDEA тому отличный пример. Вы бы назвали эти задачи "системными".
_>Не стоит выдавать явные исключения за правило. )
Какие исключения? IDE на С++ — вот это исключение. И поверь мне на слов — сервисы IDE офигеть как требовательны к производительности.
_>Нуу если называть интроспекцию времени исполнения метапрограммированием, то конечно же... Представляю ступор этих товарищей, когда им предложат быстренько накидать свой DSL на макросах... )))
Дык, это ты праешься что-то там называть. А, по жизни люди и код генерируют через T4, и IL на лету создают с помощью SRE. Рефлексия тоже подходит для многих задач. Например, для визуализации ее хватает с лихвой. Но это не значит, что никто не использует компайлтаймные решения. Просто они более убогие чем то чего можно достичь в Немерле. И вот тут парадокс...
_>Главное не конкретные цифры, а тенденции. Не думаю, что в них я ошибся. )
Не. Тенденция не интересна, если прирост в год по чайной ложке. Реальное развите должно в какой-то момент переходит в экспоненциальное. Возможно я не прав в том, что жду этого слишком быстро. Но в принципе это должно происходить иначе все так и останется в режиме "для гиктов".
_>А если попробовать реализовать скажем фронтенд к gcc? )
Подключайся, реализуем. У нас на все сил не хватит. У нас получается офигительный генератор фронтэндов, но для каждого бэкэнда нужно приложить не мало усилий. И прикладывать их должны люди знающие эти бэкэнды, так как там очень важны детали.
Думаю, что где-то к сентябрю мы начнем работу на новой версии Немерла (или чего-то очень близкого к нему по духу) на базе Нитры. Нитра принципиально подразумевает поддержку нескольких бэкэндов. Присоединяйтесь и создадим вместе нативные бэкэнды. Я, правда, думал сделать бэкнд для LLVM, но можно и для GCC. Лично я и в том, и в другом примерно одинаково не разбираюсь .
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
_>>>>http://sysdev.me/rust-1-0-doubts/ _>>>>http://eax.me/cpp-will-never-die/ DE>>>...
_>>На самом деле даже не важно имеют их аргументы смысл или нет. Важнее другое. Тут мы имеем примеры двух однозначных представителей целевой аудитории Rust, причём явно следящих за ним всё последнее время. Однако после его релиза они говорят о том, что всё же не будут его применять на практике. Т.е. значит что почему-то не зацепил в достаточной степени...
VD>Вы уверены, что эти два авторе не являются одним и тем же нашим kaa?
Ну, первый очевидно он, а второй (eax.me) — просто какой-то осёл (судя по статье).
Представляю ступор этих товарищей, когда им предложат быстренько накидать свой DSL на макросах... )))
