LINUX.ORG.RU

Rust 1.6

 ,


2

3

Команда разработчиков Rust рада представить первый в этом году релиз Rust — 1.6. Rust — это системный язык программирования, при разработке которого внимание сосредоточено на безопасности, скорости и параллелизме. Как обычно, вы можете установить Rust 1.6 с соответствующей страницы на официальном сайте, а также посмотреть примечания к выпуску на GitHub. Выпуск включает в себя около 1100 патчей и содержит ряд небольших улучшений, одно важное изменение, а также изменение на Crates.io.

Стабилизация libcore

Самым большим нововведением в 1.6 является стабилизация libcore. Стандартная библиотека Rust состоит из двух уровней: небольшая базовая библиотека libcore и полная стандартная библиотека libstd, которая построена на основе libcore. libcore является полностью платформонезависимой, и требует только горстку внешних функций. libstd строится на основе libcore, добавляя поддержку выделения памяти, операций ввода-вывода и параллелизма. При использовании Rust во встраиваемых средах и при написании операционных систем, разработчики часто избегают libstd, используя только libcore.

Стабилизация libcore являтся важным шагом к возможности писать самое низкоуровневое ПО, используя стабильный Rust. Это позволит развиваться экосистеме библиотек вокруг libcore, но приложения пока полностью не поддерживаются. Ожидайте изменения в этой области в будущих релизах.

Стабилизации библиотеки

Около 30 библиотечных функций и методов теперь являются стабильными в 1.6. Заметные улучшения включают в себя:

  • Семейство функций drain() для коллекций. Эти методы позволяют перемещать элементы из коллекций, сохраняя память, в которой они размещены, тем самым снижая выделение памяти в некоторых ситуациях.
  • Ряд реализаций типажа From для конвертирования между типами стандартной библиотеки, в основном между целочисленными типами и числами с плавающей точкой.
  • Наконец, Vec::extend_from_slice(), ранее известный как push_all(). Этот метод существенно быстрее, чем более общий метод extend().

Crates.io запрещает использование масок в версиях зависимостей

Если вы являетесь мейнтейнером контейнера на Crates.io, возможно вы видели следующее предупреждение:

новые контейнеры более не могут использовать маски при описании зависимостей.

Другими словами, это запрещено:

[dependencies]
regex = "*"

Вместо этого вы должны указать конкретную версию или диапазон версий, используя одну из опций: ^, ~, или =.

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

>>> Официальный анонс

★★★★★

Проверено: Klymedy ()
Последнее исправление: Klymedy (всего исправлений: 6)

Ответ на: комментарий от anonymous

как Firefox

Дайте знать, когда напишите на plain C браузер, настолько же стабильный, как Firefox. После этого можно будет вернуться к разговору.

eao197 ★★★★★
()
Ответ на: комментарий от eao197

После этого можно будет вернуться к разговору.

Речь не о том, можно ли написать на С Firefox или нет. А в том, какие требования к надежности такого ПО. Если у всех в мире упадет FF на просмотре последних новостей, никто от этого особо не расстроится. А вот если у хостера вдруг посыпится кластерная FS по всему датацентру, над которой тысячи виртуалок, то кого-то могут и убить в итоге. В С++ сейчас бардак, управление которым таки нетривиально.

anonymous
()
Ответ на: комментарий от anonymous

Речь не о том, можно ли написать на С Firefox или нет.

Вопрос «можно или нет» как раз во многом и упирается в

А в том, какие требования к надежности такого ПО.

Т.к. на задачах свыше какого-то порога сложности разработка на низкоуровневых языках, вроде C, обходится слишком уж дорого. В том числе и в плане обеспечения надежности. Т.к. на низкоуровневом языке мест для совершения ошибок гораздо больше. Больше же требуется и сил для их обнаружения, выявления и предотвращения в будущем.

В OpenSource, на который здесь принято подрочить, объем ресурсов бывает такой, что на это можно наплевать. Но как только ресурсы становятся проблемой, то от использования C стараются уйти, если это возможно. Поэтому, скажем, clang/llvm, Chromium, Couchbase, RethinkDB и т.д. используют C++, а не C.

В С++ сейчас бардак, управление которым таки нетривиально.

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

eao197 ★★★★★
()
Последнее исправление: eao197 (всего исправлений: 1)
Ответ на: комментарий от eao197

Я С не защищаю. Тут, наверное, недопонимание вышло. Тот анонимус, который не верит в большие проекты на С++, говорил, что Постгрес будет сложно написать на С++, потому что сам С++ сейчас лихорадит неподетски. С++03 устарел, а С++14 еще никто пользоваться толком не умеет.

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

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

anonymous
()
Ответ на: комментарий от eao197

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

Так говоришь, будто С++ высокоуровневый и в нем сил не требуется. А чем реально C++98, на котором почти весь софт написан, отличается от C в этом плане? Все те же грабли плюс пара новых абстракций, добавляющих россыпь новых граблей. Очень способствует продуктивности, ага.

anonymous
()
Ответ на: комментарий от anonymous

Тот анонимус, который не верит в большие проекты на С++, говорил, что Постгрес будет сложно написать на С++,

Имхо, там были разные анонимы :)

потому что сам С++ сейчас лихорадит неподетски.

Как раз сейчас у C++ все намного лучше, чем 10 лет назад, когда у многих вообще не было уверенности в том, что C++0x когда-нибудь появится, да и сам язык выживет.

С++03 устарел, а С++14 еще никто пользоваться толком не умеет.

С C++14 несколько другая проблема: пока далеко не все имеют возможность перейти на C++11 полностью, не говоря уже про C++14. Мне, например, до сих пор приходится на VC++12.0 и GCC 4.9 оглядываться, а ведь у многих ситуация еще хуже.

Кроме того, перейдя на C++11/14 старый код, написанный под C++98/03, в большинстве своем продолжит работать и кардинально его переписывать не нужно.

А вот Постгрес вряд ли на C++ когда-нибудь перейдет, т.к. такое переписывание — это слишком дорогое и длительное мероприятие.

Ну, конкретно, я думаю, имелось в виду то, что в С++ нет пока еще модулей и пакетного мендежера a-la Maven.

Этого в ближайшее время и не предвидится.

В результате слишком трудоемко котроллировать используемые сторонние библиотеки.

Это не такая большая проблема. Гораздо серьезнее две другие:

- когда отдельные программисты не хотят выходить за рамки «C with Classes». При этом кивая, например, на Google C++ Codestyle или на еще более жесткие, вроде JSF C++ Coding Standard или MISRA-C++, не отдавая себе отчет в специфике и причинах появления таких стандартов. В итоге пишут код, в котором от C++ только некоторые ключевые слова;

- когда отдельные программисты пишут весь код в стиле шаблонной магии, считая, что если их код проще, чем реализация Boost.Spirit, Boost.Phonix и Boost.Hana, то он ничего не стоит.

Вот это да, это проблемы. А зависимости можно и вручную поддерживать.

eao197 ★★★★★
()
Ответ на: комментарий от anonymous

Все те же грабли плюс пара новых абстракций, добавляющих россыпь новых граблей.

Это ты про шаблоны и деструкторы? Да, граблей добавилось, но и многие вещи всё же сильно упростились. Вспомним не к ночи gtk+ с его ручным ref/unref. Но появились страшные буквы UB, которыми впору пугать детей. И да, неопределенное поведение контроллировать очень трудно. Раз-два и сегфолт на ровном месте.

anonymous
()
Ответ на: комментарий от anonymous

Так говоришь, будто С++ высокоуровневый и в нем сил не требуется.

По сравнению с plain C — высокоуровневый. А C++11/14 так очень высокоуровневый.

А чем реально C++98, на котором почти весь софт написан, отличается от C в этом плане?

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

Очень немало.

Все те же грабли плюс пара новых абстракций, добавляющих россыпь новых граблей.

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

Очень способствует продуктивности, ага.

Способствует. Голову только включать нужно, ага.

eao197 ★★★★★
()
Ответ на: комментарий от eao197

Имхо, там были разные анонимы :)

Да, буду подписываться. А то начинает казаться, что это анонимные голоса в голове разговаривают. Наверное, именно поэтому анонимов на ЛОРе держат? :)

//Психиатр

anonymous
()
Ответ на: комментарий от Oxdeadbeef

А генерации строчки текста в компайл-тайме так и нет, лол.

Я надеюсь, что ты-то понимаешь, что аргумент так себе?

DarkEld3r ★★★★★
()
Ответ на: комментарий от eao197

Список статически-типизированных языков, в которых это возможно, предоставите?

D, Nemerle, Rust. Думаю, что в скале тоже можно.

Другое дело, что я бы не стал считать это критическим недостатком.

DarkEld3r ★★★★★
()
Ответ на: комментарий от eao197

Вот это да, это проблемы.

Вот, сам знаешь же всё. А теперь прикинь, кто выработает гайдлайн и насует его всему стаду котов в опен-сорц проекте? Это должен быть какой-то господь-бог как минимум.

anonymous
()
Ответ на: комментарий от eao197

Если вы не смогли научиться с помощью C++ обходить грабли C

Ух ты, в треде мистер крутые яйца, никогда не допускающий сегфолтов. Может научишь кедоделов программы писать, а?

anonymous
()
Ответ на: комментарий от eao197

Да, я тот аноним, что вещал здесь за Boost Hana, метапрограммирование и структуры данных с базами.

А вот Постгрес вряд ли на C++ когда-нибудь перейдет, т.к. такое переписывание — это слишком дорогое и длительное мероприятие.

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

Это не такая большая проблема. Гораздо серьезнее две другие:

Есть такое дело да. Нащупать золотую середину не просто.

//Психиатр

anonymous
()
Ответ на: комментарий от DarkEld3r

D, Nemerle, Rust.

Nemerle сдох толком и не родившись (впрочем, туда ему и дорога).

Rust пока слишком новый язык, чтобы можно было делать какие-то выводы.

А вот D очень хороший пример. Стабильный релиз D 1.000 случился в январе 2007-го года. Т.е. 9 лет назад, когда C++ медленно, но уверенно скатывался в жопу из-за долгостроя под названием C++0x, успехов Java и активным развитием .NET-а Microsoft-ом.

Ну и какие мегапродукты появились на D за прошедшие годы? Почему мегавозможность по генерации текстовых строк в компайл-тайм не позволила D хоть сколько-нибудь заметно потеснить C++ или какой-то другой из старых языком?

Может на практике в 99% случаев это самое метапрограммирование с целью сформировать строку в компайл-там вообще никому не вперлось?

eao197 ★★★★★
()
Ответ на: комментарий от anonymous

никогда не допускающий сегфолтов

анекдот-про-сибирских-лесорубов-и-японскую-пилу.txt

tailgunner ★★★★★
()
Ответ на: комментарий от anonymous

Может научишь кедоделов программы писать, а?

Я еще никогда не видел программы на C или C++, в которых не было бы сегфолтов. Рано или поздно что-нибудь, где-нибудь да вылезет.

Только вот на C++ воспрепятствовать этому в разы проще, чем на C.

Надеюсь, что в Rust-е это делается еще проще. Но, боюсь, там будет своя цена, в других местах.

eao197 ★★★★★
()
Ответ на: комментарий от eao197

Ну и какие мегапродукты появились на D за прошедшие годы?
Почему мегавозможность по генерации текстовых строк в компайл-тайм не позволила D хоть сколько-нибудь заметно потеснить C++ или какой-то другой из старых языком?
Может на практике в 99% случаев это самое метапрограммирование с целью сформировать строку в компайл-там вообще никому не вперлось?

Подожди, подожди. С кем ты споришь? Где я утверждал, что это отсутствие этой возможности - главная (или вообще сколь-нибудь заметная) проблема С++? Tоже считаю, что вопят про отсутствие «генерации строки на этапе компиляции» из-за отсутствия аргументов.

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

Кстати, про скалу интересно. Она ведь более-менее живая, намного живее того же D. И какие-то макросы имеются. К сожалению, языка не знаю, так что точно сказать не могу есть ли там эта возможность.

(впрочем, туда ему и дорога).

Почему?

Nemerle сдох толком и не родившись

Как знать - их ведь джетбрейнс подобрали и они пилят очередную вундервафлю (Nitra) - может из этого что-нибудь и получится. Впрочем, на данный момент, перспективы и правда сомнительные.

DarkEld3r ★★★★★
()
Ответ на: комментарий от eao197

Может ты ещё и кедофан?

Нет.

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

anonymous
()
Ответ на: комментарий от DarkEld3r

С кем ты споришь?

В данном случае не с вами персонально. Скорее ваш список языков дал возможность показать всем C++хейтерам с аргументом про «строку в компайл-тайме» наглядный пример.

Кстати, про скалу интересно.

Про скалу мне было интересно где-то в 2006-2007-ом, когда я искал вменяемую альтернативу C++. Но показалось, что Scala — это эдакий C++, но для JVM. Т.е. какой-нибудь мегамозг, которому забыли поставить ограничения, может наколбасить такой запутанный код, что никто в команде не разберется.

Ну и, кроме того, Scala — это JVM и сборка мусора, что очень далеко от ниши, в которой должны жить C, C++ и Rust. Так что не интересно вдвойне :)

Почему?

Скажем так, наблюдал как главные пиарщики засрали один из немногих адекватных профильных ресурсов в Рунете — RSDN.

eao197 ★★★★★
()
Ответ на: комментарий от anonymous

Забыл, что ты вендузятнег,

Это исторически сложилось. В свое время забабахался настраивать Linux-ы на ноутбуках. Оказалось, что спокойно можно жить под оффтопиком со свежими драйверами, а для онтопика и других Unix-ов писать под виртуалкой.

презирающий опенсорс.

Это более чем неправда, т.к. как раз занимаюсь оперсорсом.

Неясно только, зачем ты тут трешься.

Да у вас разрешения, видимо, забыл спросить.

eao197 ★★★★★
()
Ответ на: комментарий от eao197

А вот Постгрес вряд ли на C++ когда-нибудь перейдет, т.к. такое переписывание — это слишком дорогое и длительное мероприятие

C++ тем и хорош, что резкое переписывание необязательно, см. gcc.

anonymous
()
Ответ на: комментарий от anonymous

C++ тем и хорош, что резкое переписывание необязательно, см. gcc.

Это да. Но у PostgreSQL вроде как и подвижек никаких не наблюдается. Тогда как MS свой MSSQL в итоге на C++ перевела.

eao197 ★★★★★
()
Ответ на: комментарий от eao197

Ну и, кроме того, Scala — это JVM и сборка мусора, что очень далеко от ниши, в которой должны жить C, C++ и Rust. Так что не интересно вдвойне :)

Scala и C++ — это сейчас совсем разные вселенные. Scala может использоваться либо как язык ФП, и тогда он интересен хаскеллерам, которые бы хотели найти работу, либо как Java c сокращенным синтаксисом.

Система типов Scala тоже полна по Тьюрингу и в ней тоже можено делать что-то типа шаблонной магии. Но генерики в ней полиморфные, и этим всё сказано. Вся эта магия существует только на уровне вывода и контроля типов. Что, в прочем, уже не мало. В сочетании с макросами дает возможность организовать «типобезопасную» работу с динамически-типизированными данными, что очень любят в биг-дате, где Scala сейчас и окопалась. Для Java-программиста хотя бы умение читать Scala-код — это must have skill.

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

//Психиатр

anonymous
()
Ответ на: комментарий от eao197

показать всем C++хейтерам с аргументом

Хейтерам пофиг на (такие) аргументы. Они увидят, что это возможно, а остальное их не интересует. Даже если бы возможность была только в динамически-типизированных языках - их бы и это не остановило.

Scala — это эдакий C++, но для JVM. Т.е. какой-нибудь мегамозг, которому забыли поставить ограничения, может наколбасить такой запутанный код, что никто в команде не разберется.

Это точно аргумент за С++?..

Опять же, вопрос ограничений - он непростой. К расту много претензий, в том числе, потому что они многое стараются зарегулировать и продвигать «правильный вариант». Да, ограничения можно обойти и, в основном, они даже полезны, но это воспринимается как «выкручивание рук» и недостаточная гибкость. Угодить всем невозможно.

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

Скажем так, наблюдал как главные пиарщики засрали один из немногих адекватных профильных ресурсов в Рунете — RSDN.

Их можно понять - искренне болеют за своё детище. Да и в целом людям свойственно закрывать глаза на «мелкие недостатки», если они видят «заметные преимущества». Да и язык у них был неплохой, другое дело, что продвигать его нормально у них не получалось.

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

DarkEld3r ★★★★★
()
Ответ на: комментарий от eao197

Тогда как MS свой MSSQL в итоге на C++ перевела.

Ресурсы несравнимы. Ну и традиционные БД очень инертны и консервативны в плане всяких архитектурных решений.

//Психиатр

anonymous
()
Ответ на: комментарий от DarkEld3r

Хейтерам пофиг

Надеюсь, не пофиг сторонним читателям.

Это точно аргумент за С++?

Это не аргумент за C++. Это пояснение, почему мне лично Scala не понравился в итоге. Точнее, это одна из причин, почему не понравился.

Относительно сборки мусора согласен, но это не делает язык плохим (для своей ниши).

Дык я и не говорил, что он плох. Хотя где-то он, скорее всего, будет таким же плохим выбором, как и C++.

Изначально ведь речь шла просто про типизацию.

Имхо, сравнивать нужно инструменты, попадающие в одинаковую нишу. Вот берем нишу C++: это требовательный к ресурсам софт, который, как правило, работает повыше голого железа. И в котором использование сборщика мусора либо нежелательно, либо проблематично.

После чего смотрим, что еще есть в этой нише и что может помочь нам решать похожие задачи. Написать ядро новой СУБД, например.

Как по мне, так не очень логично сравнивать здесь возможности Scala с возможностями C++.

eao197 ★★★★★
()
Ответ на: комментарий от eao197

Это пояснение, почему мне лично Scala не понравился в итоге. Точнее, это одна из причин, почему не понравился.

Но С++, который имеет такие же «проблемы», ведь нравится? Или это просто за неимением лучшего?

Имхо, сравнивать нужно инструменты, попадающие в одинаковую нишу.

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

DarkEld3r ★★★★★
()
Ответ на: комментарий от anonymous

Ресурсы несравнимы.

Да тут еще как посмотреть. Количество народу, которое участвует в каком-нибудь раскрученном OpenSource-проекте, может превышать количество штатных программистов, занимающихся каким-то закрытым продуктом.

Не буду утверждать, что это так для противопоставления PostgreSQL и MSSQL. Но в каком-нибудь мелком проекте масштаба, скажем, gSOAP, в OpenSource контрибьюторов может оказаться сильно больше, чем в закрытом аналоге, который какая-нибудь конторка будет развивать для себя.

eao197 ★★★★★
()
Ответ на: комментарий от DarkEld3r

Вот там в шапке новости написано, что к релизу 1.6 они только core стабилизировали. Значит, еще много чего наломают.

//Психиатр

anonymous
()
Ответ на: комментарий от DarkEld3r

Но С++, который имеет такие же «проблемы», ведь нравится? Или это просто за неимением лучшего?

За неименеем лучшего. Лет восемь назад C++ конкретно достал так, что всерьез искал замену, даже с учетом необходимости плавного перевода старой кодовой базы на новую технологию.

Но ничего подходящего не нашлось.

Впрочем, лучше стал понимать, почему C++ вот такой, почему его нечем заменять, и что вообще с этим делать.

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

Тогда сравнивать придётся два с половиной языка - тоже не очень интересно.

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

eao197 ★★★★★
()
Ответ на: комментарий от eao197

который какая-нибудь конторка будет развивать для себя

Тут да, сильно побольше. Но в плане базы данных, MS может свой MSSQL выкинуть (забыть) и переписать всё заново. За 10 лет. С PostgreSQL такого не получится. Он у них единственный проект.

//Психиатр

anonymous
()
Ответ на: комментарий от anonymous

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

Вот наглядный пример: http://is.gd/tc2ck7

quantum-troll ★★★★★
()
Последнее исправление: quantum-troll (всего исправлений: 1)
Ответ на: комментарий от anonymous

Вот там в шапке новости написано, что к релизу 1.6 они только core стабилизировали. Значит, еще много чего наломают.

Это разные вещи. «Нестабильные» штуки в расте - это примерно как пользоваться «экспериментальными» фичами того же Clang. Вот как они сами пишут:

Note that support for these features may change or be removed without notice, as the draft C++1z standard evolves.

То есть на свой страх и риск. Точно так же и в расте: нестабильные вещи - это или деталь реализации или АПИ ещё не устоялся и идут эксперименты. Лучше не использовать, если хочется стабильности.

DarkEld3r ★★★★★
()
Ответ на: комментарий от DarkEld3r

Это разные вещи. «Нестабильные» штуки в расте - это примерно как пользоваться «экспериментальными» фичами того же Clang

Ну, понимаешь, у нас пол-языка в нестабильных штуках, а пользоваться-то надо. Так и в Скале, всё самое интересное по нескольку лет отмечено как нестабильное.

//Психиатр

anonymous
()
Ответ на: комментарий от anonymous

Так и в Скале, всё самое интересное по нескольку лет отмечено как нестабильное.

Ну если в скале так же, то значит у них неплохо со стабильностью, как по мне.

DarkEld3r ★★★★★
()
Ответ на: комментарий от eao197

Это более чем неправда, т.к. как раз занимаюсь оперсорсом.

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

anonymous
()
Ответ на: комментарий от DarkEld3r

Ну если в скале так же, то значит у них неплохо со стабильностью, как по мне.

В каком-то смысле - да. Год жить можно, до следующего релиза :)

anonymous
()
Ответ на: комментарий от anonymous

Система типов С++ полна по Тьюрингу, поэтому в её рамках можно реализовать аппроксимированный поиск лучшей реализации из множества, удовлетворяющей заданным критериям. Это и есть декларативное программирование.

Декларитивное программирование выглядит так: «эй, СУБД, создай оптимальный индекс для таблицы img. Имей в виду, что в столбце data в ней будут картинки jpeg размером X*Y*Z, где Z - глубина цвета» :-) Всякие полнота по Тюрингу и апкроксимации тут для понтов перед теми, кто не в теме :-)

anonymous
()
Ответ на: комментарий от anonymous

И что, такого же эффекта нельзя добиться в С++ от компилятора? Чтобы он создал, например, пространственный индекс с заданными свойствами из шаблонных компонентов.

//Психиатр

anonymous
()
Ответ на: комментарий от anonymous

И то, раньше они завязнут в клубке метапрограмм и зафейлятся.

Чем «умнее» язык, тем сложнее его использование в команде :-) Лисп - крайне «умён», от этого его «горе от ума» :-) Этот язык хорошо подходит для отдельных одиночек-вольнодумцев, что противоречит самой концепции «команды» :-) Т.е. чем богаче язык, чем больше возможностей, чем больше парадигм, тем сложнее организовать командную разработку :-) От того все эти «стандарты», нормативы, паттерны, совещания, конференции, семинары, вебинары - это всё приёмы организации :-) Слишком «умный» Common Lisp, слишком сложный Си++ невольно заставляют задумываться, что при текущем уровне скилла, на сегодняшнем оборудовании, C и Java - самые адекватные языки программирования для решения практических задач *командами* - простые и эффективные :-) Не надо задвигать про деструкторы и шаблоны :-) Не надо анафорических макросов :-) Всё это имеет место быть, всё это имеет применение :-) Просто на секунду, на минуту, на ночь остановитесь и подумайте :-) Не надо фанатеть, надо просто думать :-)

anonymous
()
Ответ на: комментарий от anonymous

И что, такого же эффекта нельзя добиться в С++ от компилятора? Чтобы он создал, например, пространственный индекс с заданными свойствами из шаблонных компонентов.

Реальное метапрограммирование - это создание микрокомпилятора :-) На языке шаблонов C++ ты такой компилятор с твоим скиллом не создашь - пупок у тебя развяжется :-)

anonymous
()
Ответ на: комментарий от anonymous

это создание микрокомпилятора

Этим микрокомпилятором как раз компилятор С++ и является. Метапрограмме остается только перебрать известные ей стратегии специализации и выбрать оптимальную. Сильный ИИ на таком движке, конечно, не создать, но специализировать сложный шаблон вполне можно. И пупок не развяжется.

//Психиатр

anonymous
()
Ответ на: комментарий от anonymous

Этим микрокомпилятором как раз компилятор С++ и является.

C++ не понимает «создай мне индекс для таблицы table ...» :-) Обучить ты его этому не сможешь по одной банальной причине - у тебя, у простого цепепе-кодера нет доступа к компилятору цепепе посредством языка шаблонов :-) Ты этого не понял ещё? :-) Бросай фанатеть, включай мозг :-)

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

Это задача компилятора цепепе, к которому ты, как сказано выше, доступа не имеешь :-)

anonymous
()
Ответ на: комментарий от anonymous

C++ не понимает «создай мне индекс для таблицы table ...» :-) Обучить ты его этому не сможешь по одной банальной причине - у тебя, у простого цепепе-кодера нет доступа к компилятору цепепе посредством языка шаблонов

Мы об одном и том же говорим? Я говорю о том, что я могу попросить компилятор создать класс MyCoolSpatialIndex<List, Of, Target, Properties>. Что он вполне может сделать из готовых компонентов и метапрограмм, склеивающих эти компоненты. А ты о чем говоришь?

//Психиатр

anonymous
()
Ответ на: комментарий от anonymous

создать класс MyCoolSpatialIndex<List, Of, Target, Properties>

При инстанцировании этого класса компилятор не имеет возможности обратиться к СУБД чтобы выяснить детали о том, как именно создать твой CoolSpatialIndex оптимально :-) (Про генерацию строчки в компайл-тайме я вообще промолчу - не сможет компилятор сгенерировать «CREATE INDEX idx ON table ....».) :-) Ты вынужден указывать детали врукопашную, при банальном изменении структуры таблицы, нужно опять менять List, Of, Target, Properties в строгом соответствии со сделанными изменениями в СУБД :-) Твой компилятор не сможет сказать тебе: «дорогой, ты мне говоришь создать хреновый индекс, т.к. в таблице в СУБД у тебя данные, которые плохо соответствуют List Of Target Properties» :-)

anonymous
()
Ответ на: комментарий от anonymous

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

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

//Психиатр

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.