имелось ввиду «скорее проц, чем оперативка»

что до графики, на видео хватает вполне (ибо не fullhd же на нетбуке смотреть).

и вообще, мы сейчас про драйвера для линукса говорим?

RAM

Получается, техасовские DSP теперь в gcc и левые закрытые тулчейны больше не нужны?

Паскаль же

Ну наконец-то! Таки. Сделали. Это.

Не забудь упомянуть про то, что теперь стадии 2-3 собираются с g++ только и про улучшения в genautomata для не хэ86.

Паскаль же

Мне нравится Паскаль, но у него слабая инфраструктура, по сравнению с Си, и за ним уже нет никого сильного, как за Го. Т. е. будущего у него скорее всего нет, а у Го, возможно, есть.

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

Есть Ада, у которой сильная инфраструктура и за которой стоят серьезные люди :)

возможностей ФП

Поверьте лисперу, они не нужны.

Если ФП это про функциональное программирование - то не верю, нужно оно как и логическое - возникли они не вчера, а даже задолго до новомодных языков и проживут еще долго в отличии от модных ныне, и за функциональным и логическим программированием наше светлое будущее (я про программистов).

Сейчас скомпилировал под Gentoo gcc-4.7.0 через таким же образом подготовленный и собранный как и месяц назад ebuild для gcc-4.6.3. Ebuild-ы готовил сам (готовых просто не нашел) на основе пачтей для gcc-4.6.2 и нового pie 0.5.2 для 4.7.0. Остальные патчи взял от 4.6.2, но пришлось примерно 10 патчей поправить для 4.7.0 (для 4.6.3 не больше пяти правил).

Сейчас произвожу пробную сборку mc, imagemagick, inkscape.

Если все удачно, то затем сборка ядра 3.3.0 и затем уже попытка сборки glibc-2.15.

Если ФП это про функциональное программирование - то не верю, нужно оно как и логическое

Нет, концепции как ФП, так и ЛП, вне сомнения, очень важны и оказывают сильнейшее влияние на всю отрасль. Но насильное вклячивание «новомодных ФП-фич» в императивный процедурный язык обычно ни к чему хорошему не приводит.

Лично я не против фич ФП и ЛП в новомодных языках. Глядишь поклонники этих языков начнут чаще использовать ФП и ЛП в своей работе и учебе, а то и вовсе переключатся на правильные языки.

Все о чем писал ранее успешно пересобралось на gcc-4.7.0. Решил теперь собрать nginx-1.1.17. Не получилось - обломилось на boost-1.4.8. Итак, обновление споткнулось на boost. Не захотел он собираться на gcc-4.7.0. Сейчас разбираюсь, ищу информацию как обойти трабл:

«x86_64-pc-linux-gnu-g++» -ftemplate-depth-128 -march=amdfam10 -O2 -pipe -finline-functions -Wno-inline -w -pthread -fPIC -DBOOST_ALL_DYN_LINK=1 -DBOOST_ALL_NO_LIB=1 -DNDEBUG -I"." -c -o «bin.v2/libs/wave/build/gcc-4.7/gentoorelease/pch-off/threading-multi/cpplexer/re2clex/cpp_re.o» «libs/wave/src/cpplexer/re2clex/cpp_re.cpp»

...skipped <pbin.v2/libs/wave/build/gcc-4.7/gentoorelease/pch-off/threading-multi>libboost_wave-mt-1_48.so.1.48.0 for lack of <pbin.v2/libs/thread/build/gcc-4.7/gentoorelease/pch-off/threading-multi>libboost_thread-mt-1_48.so.1.48.0... ...skipped <pstage/lib>libboost_wave-mt-1_48.so.1.48.0 for lack of <pbin.v2/libs/wave/build/gcc-4.7/gentoorelease/pch-off/threading-multi>libboost_wave-mt-1_48.so.1.48.0... ...skipped <pstage/lib>libboost_wave-mt-1_48.so for lack of <pstage/lib>libboost_wave-mt-1_48.so.1.48.0... ...failed updating 9 targets... * ERROR: dev-libs/boost-1.48.0-r1 failed (compile phase): * Building of Boost libraries failed

nginx не собрался из-за passenger который уперся в boost.

boost успешно обновил до 1.49.0 (правкой штатного ebuild 1.48.0), но и после этого nginx+passenger не собираются.

Думаю все проблемы в несовместимости passenger с gcc-4.7.0 и boost. В поисках решения.

вовсе переключатся на правильные языки

Переключиться на «правильные» языки полностью нельзя в силу врожденной тормознутости большинства ФП-фич.

Этот патч примененный к файлу boost из passenger-a решил проблему сборки nginx-1.1.17 под gcc-4.7.0.

https://svn.boost.org/trac/boost/changeset/76133/trunk/boost/config/stdlib/li...

Теперь очередь за cuda-sdk.

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

CUDA SDK 4.1 ранее успешно собиравшийся на gcc-4.6.3 boost-1.48.0 glibc-2.15 на отрез отказывается собираться на gcc-4.7.0 boost-1.49.0 glibc-2.15 - готового решения пока не нашел, если кто уже собрал отпишитесь пожалуйста:

/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0/include/g++-v4/ext/atomicity.h(48): error: identifier «__atomic_fetch_add» is undefined

/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0/include/g++-v4/ext/atomicity.h(52): error: identifier «__atomic_fetch_add» is undefined

Других проблем после перехода на gcc-4.7.0 не выявлено.

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

это теория или уже проверено на опыте?

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

Так думает автор учебников по Haskell Душкин. Я тоже разделяю эту точку зрения. Деткам нужно давать ФП и ЛП, вместо того что не дает прорывных результатов, а дает только вяло текущее исправление трудно отлавливаемых багов и как результат - короткий (не более 3 лет) жизненный цикл изделий и как следствие не удовлетворенность результатами своего труда, который в основном идет на корзину, а не на пользу.

народ салют!

Почитав комменты, что-то не уловил. Нужен нам Gcc или уже можно переходить на Clang?

/* Рад, что вышла новая версия. Вскоре пойду тестить =) */

too fat

gcc нужен. переходить на clang тоже можно.

clang не навязывает GPL-лицензию, компилит быстро, но пока не все gcc-фишки умеет. плюс - информативные сообщения об ошибках, llvm и все его бонусы

gcc умеет все gcc-фишки (внезапно, да), чуть лучше оптимизирует код, умеет больше языков/платформ.

еще gcc внезапно ломает компилируемость различных пакетов при своих минорных апдейтах. по clang'у информации об этом у меня нет

http://forums.nvidia.com/index.php?showtopic=106592&st=0&p=590552&amp...

Проблема с CUDA SDK 2009 года наблюдается снова. Решение простое - добавить в cu файл (или еще лучше в один из заголовочных файлов #undef _GLIBCXX_ATOMIC_BUILTINS

и теперь примеры CUDA SDK 4.1 успешно собираются и на GCC 4.7.0

А если не секрет

То, каким именно компилятором компилят крупные конторы свои проекты? Интересны проекты под Linux конечно.

к крупным конторам отношения не имею)

скорее всего, 99% контор юзают gcc, ибо linux исторически спарен с GNU. но в последнее время появляются намеки на возможность перемен.

вот тут можно вычленить порядочно любопытного по теме: Debian: clang способен заменить gcc

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

поищите во всяких гитхабах и сорсфорджах по фильтру «язык:ассемблер», там вроде везде есть такая возможность

а еще можно помочь, выучив С, например, и присоединившись к какому-нибудь любому другому проекту :)

Лично я вижу место Go в серверной среде. Немалую роль тут играет заточенность его референсного компилятора на amd64. Сейчас у него еще слишком много детских проблем(многие из которых решаются разработчиками достаточно быстро).
Основные идеи мне очень близки (особенно реализация «многопоточности» и ipc между «потоками» сразу в языке). Писать на нем просто и главное нет этих новомодных заигрываний с ФП. Как я думаю - Go это, чем мог стать D.
Если интересно - можно почитать их рассылку https://groups.google.com/forum/?fromgroups#!forum/golang-nuts

Не понял чем Go лучше Си, Си++ или того же Паскаля. Чем Вам лично не угодило «новомодное» ФП (Haskell развивается не меньше времени, а главное быстрее чем Си++, и быстрее других впитывает в себя все полезное из новомодных возможностей императивного программирования но на декларативный манер)? По моему место Go конкурировать с Си++, и даже не с системным Си. И до возможностей предоставлящих ФП, обычным традиционным языкам, не дотянутся даже при наличии фич ФП в них.

Я тоже считаю, что Go сможет когда-нибудь конкурировать в нише, в которой сейчас C++ и иногда даже Java (серверный или системный софт).
Чем он лучше Си, С++:
- синтаксический сахар - самое главное - не нужно ставить точку с запятой после каждой строки, ИМХО это просто киллер фича, сколько было проблем с тем, что где-то забыл поставить эту точку с запятой и компиляция вываливалась в совершенно другом месте, определение типа при создании переменной без его явного указания(хотя можно и указывать), короче много мелких вещей на которые уходит время и повышается вероятность совершить ошибку, да и для новичков хорошо - не нужно забивать этим голову, о отсюда лаконичность самого кода;
- встроенная «многопоточность» с ipc - больше никаких pthreads, все что нужно сразу заложено в языке, сейчас это становится все более актуальным, т.к. почти все компьютеры имеют по несколько ядер;
- концепция интерфейсов - это не ООП и не шаблоны, а что-то среднее;
- работа с юникодом и юнокодовыми строками из коробки;

Обычно я представляю себе Go как некий симбиоз Си и Питона, из си мы имеем комплируемый код, а из питона - синтаксический сахар и простоту написания.

По поводу ФП - лично для мне его эталоном является Lisp, это что-то с невозможным синтаксисом (примерно как брейнфак). Как я думаю всем этим языкам место в учебных заведениях или может в каких-то задачах, где одна только математика.
Может быть я такой прожженный императивщик или пробитый ретроград, но мне лично тяжело читать вот такой код(взято отсюда http://ru.wikipedia.org/wiki/Haskell , хотя первый раз вижу код на Haskell):
primesST = 2 : 3 : sieve 0 5 9 (drop 2 primesST)
where
sieve k x q ps = let fs = take k (tail primesST) in
[n | n <- [x,x+2..q-2], all ((/=0).rem n) fs]
++ sieve (k+1) (q+2) (head ps^2) (tail ps)

а это выливается в трудности его дальнейшей поддержки.

Большинство ФП языков - интерпретируемые, а значит делать приложения, которые работают 24/7 на этом невыгодно (слишком много ресурсов будет нужно). Если уж так нужен интерпретируемый язык - то есть баш или на крайний случай питон.

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

хотя какие-то упоротые написали на haskell оконный менеджер

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

но мне лично тяжело читать вот такой код

когда я вообще не знал С, мне тоже было трудно читать код хелловорд.ц

в приведенном вами фрагменте нет ничего сложного, если его правильно отформатировать и знать синтаксис языка

Большинство ФП языков - интерпретируемые

может, и больше половины, но не существенно.

а вот среди популярных императивных/объектно-ориентированных языков: c/c++, java, python, ruby, php - какова доля компилируемых? из перечисленных только с/c++, поправьте, если что-то *популярное* пропустил

Все верно, но прогнозы относительно языков из числа Haskell, Рефал, Акторный Пролог - очень хорошие. Возможно именно они или их наследники приблизят момент появления умной машины и программы с элементами очень похожими на уже забытый ИИ. Haskell и Prolog используют (не предавая это широкой огласке) на промышленном уровне во всех областях. Многие задачи очень изящно решаются с помощью математически прозначного кода в десяки раз более короткого и в разы быстрее выполняющегося чем на Си++ (при условии что на Си++ задача реализуема достаточно оптимально). Haskell в основом используется в компиляторах. Пролог можно использовать как продвинутую замену невнятным языкам запросов, способным выдавать в качестве результата только колонки и строки, Пролог же может выдавать также и связанные тексты и позволяет делать заключения на основе хранящейся информации.

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

У ФП и ЛП языки идут в ногу с развитием теории и появлением потребности в новых возможностях у прикладников.

Чтобы узнать что написано на Haskell достаточно зайти на страничку проекта. Его к примеру с успехом применяют для веб-разработки (по типу Ruby On Rails), а также для утилизации возможностей многоядерных платформ (к примеру той же Cuda через ffi), а Акторный Пролог ориентирован на встроенное в него распараллеливание.

Нет Си конечно тоже нужен (на нем ядро Linux наиисано), и много интересных идей появилось и в Си++, и в Ruby, но всех эти идеи успешно поглощают языки ФП и даже прелагают более изящные и значительно более производительные решения (к примеру фирменная фича ROR - Haml, полная копия в Haskell - Hamlet, а тажке более продвинутое решение - blaze-html).

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

primesST = 2 : 3 : sieve 0 5 9 (drop 2 primesST) where sieve k x q ps = let fs = take k (tail primesST) in [n | n <- [x,x+2..q-2], all ((/=0).rem n) fs] ++ sieve (k+1) (q+2) (head ps^2) (tail ps)

Это всего лишь пример и даже не из реальной жизни, причем очень неудачный и с целью запугать непосвященных в основы ФП.

На Си и Си++ гораздо легче привести более запутанный а зачастую даже и абсудрный код (который потом выправляют и оптимизируют целую вечность) - для примера можно взять фрагмент из кода для какого нибудь драйвера или модуля.

Приводя этот код, я имел в виду, что далеко не всегда нужно использовать лямда-выражения, потому как они запутывают код. Может быть это выглядит красиво, когда одна строчка делает столько всего полезного, но когда вам через 4 года придется вернуться к этом коду, то понять его сразу будет тяжело, даже если его писали вы сами.
Можно почитать Эрика Реймонда, в его книге «Искусство программирования для UNIX» про это хорошо написано.

ФП требует математической подготовки, потому ФП неприменим для написания того, что сейчас принято называть коммерческим кодом. Но от отказа от ФП код не становится понятнее, скорее напротив. Тяжело читать любой императивный код, который сами не писали, а ФП более унифицированный, зная шаблонные алгоритмы и способы их реализации при ФП, труда в чтении кода не будет, тем более при наличии ключевых комментариев, хотя бы по одной строке комментария на 100 строчек кода. Также хотелось бы отметить что алгоритм на языке функционального прораммирования в среднем в десять раз короче кода на императивном языке. Конечно есть алгоритмы которые больше или меньше подходят для ФП и ЛП, но в последнее время были разработаны приемы, позволяющие облегчить реализацию и таких алгоритмов применяя только методы ФП и ЛП.