Цитата: Artemon от февраля 9, 2009, 13:17
"Некрасиво", "суржик", "мне не нравится", "уродский пиджин" - а С++ красиво смотрится? А звучит? Но функции свои при этом выполняет вполне.
Имхо, С++ - самый красивый язык программирования.
Цитата: GaLL от февраля 10, 2009, 11:37
Цитата: Artemon от февраля 9, 2009, 13:17
"Некрасиво", "суржик", "мне не нравится", "уродский пиджин" - а С++ красиво смотрится? А звучит? Но функции свои при этом выполняет вполне.
Имхо, С++ - самый красивый язык программирования.
А как же функциональные?
Цитата: Алексей Гринь от февраля 10, 2009, 12:40
А как же функциональные?
Функциональные ЯП? Не понимаю, чего в них хорошего.
Если не писали, не поймёте. Логика приложения пишется проще и быстрее в разы. Ясно, что с вводом/выводом не ахти, но не всю же жизнь формошлёпством заниматься.
Это я всё о семантике. А синтаксис! Синтаксис прекрасен.
Единственный язык программирования с синтаксисом , вызывающим у меня эстетические эмоции , это форт . А лисповский стиль выражений можно и в операторном языке применять .
А я и не про лисп, я скорее про Хаскель, ОКамл, Эрланг там.
Цитата: "Алексей Гринь" от
Если не писали, не поймёте. Логика приложения пишется проще и быстрее в разы.
Οὐ πιστεύω. Если бы разработка на них велась быстрее, то они, соотвественно, сейчас были бы куда популярнее, чем есть на самом деле. Ну а если касаться проблем, где нужны лишь вычисления, то тут на передний план часто выступает производительность, а с ней функциональные ЯП не дружат, по понятным причинам.
А вообще, я ошибся. По крайней мере одно преимущество у них есть: неизменяемость переменных (простите за ὀξύμωρον, тут, конечно, слово "переменная" не очень подходит) помогает избежать многих типичных багов.
ЦитироватьЕсли бы разработка на них велась быстрее, то они, соотвественно, сейчас были бы куда популярнее, чем есть на самом деле.
Не в этом дело. Большая часть программистов - быдло, и для них последовательные операции чисто житейского плана "взять денег в банкомате > пойти до магазина > купить молока" на несколько страниц понять легче, нежели описать μαθηματικὴν модель в две строчки.
ЦитироватьНу а если касаться проблем, где нужны лишь вычисления, то тут на передний план часто выступает производительность, а с ней функциональные ЯП не дружат, по понятным причинам.
По производительности уступают совсем чуть-чуть (не более 10%, в некоторых случаях может быть даже быстрее; είπω только за компилируемый Хаскель, про остальные не οῖδα). Поделки на императивных языках μάλιστα часто теряют производительность и падают из-за утечек памяти (дружно вспоминаем русские игры вроде как с κακῇ γραφικῇ, но с жуткими тормозами) и прочих издержек работы с памятью напрямую. Некоторые хорошие комплияторы способны делать такие оптимизации, которые ни один С++ компилятор сделать не сможет никогда (в силу архитектуры языка).
> Большая часть программистов - быдло, и для них последовательные операции чисто житейского плана "взять денег в банкомате > пойти до магазина > купить молока" на несколько страниц понять легче, нежели описать μαθηματικὴν модель в две строчки.
Ругань разочаровывает в собеседнике , но один вопрос всё-таки задам : как в принципе можно описать что-либо в 100 раз короче и с той же детализацией ?
Цитата: "Алексей Гринь" от
Некоторые хорошие комплияторы способны делать такие оптимизации, которые ни один С++ компилятор сделать не сможет никогда (в силу архитектуры языка).
О, а тут уже хотелось бы τὰ δείγματα (примеры), т. е. какой код и как оптимизируется. Σ++ обладает относительно большой близостью к распространенным машинным языкам, не понимаю, как функциональные ЯП могут его сделать. К тому же в них часто применяется рекурсия, а это не есть εὖ для любого проца.
Цитата: "okruzhor" от
Единственный язык программирования с синтаксисом , вызывающим у меня эстетические эмоции , это форт .
А мне S-выражения больше по душе.
Цитата: "GaLL" от
Σ++ обладает относительно большой близостью к распространенным машинным языкам
Несмотря на это и очень качественные трансляторы на нём умудряются создавать таких чудовищ, что диву даёшься. 7-я ветка Оперы прославилась падучестью на ровном месте. Мощь C++ во всей красе. :)
Кстати, в этом году грозятся родить новый стандарт С++. Давайте делать ставки, через сколько лет появится транслятор, полностью его поддерживающий. ;)
Цитироватьне понимаю, как функциональные ЯП могут его сделать
Уровень абстракции позволяет. Σ++ напрямую работает со всем, что можно, и ежели компилятор вмешается в его работу, то может всё загубить.
Я про Хаскель конкретных примеров сказать не могу, но вот как пример того, что более высокий уровень позволяет оптимизировать приложения: JIT-компилируемые языки, например, способны в райнтаме девиртуализировать виртуальные методы в обычные, и поиск метода по vtbl не будет оверхедом за ненадобностью (особенно в циклах). В С++ такого сделать нельзя. В Хаскелле подобного вида оптимизации по спискам, заменам рекурсий на итерации и всякой шляпе, не относящейся к этому форуму и этой теме никак.
ЦитироватьРугань разочаровывает в собеседнике , но один вопрос всё-таки задам : как в принципе можно описать что-либо в 100 раз короче и с той же детализацией ?
Классический пример по сортировке (алгоритмы ещё фигня, в функциональных языках типизация много высшего порядка, нежели в С++, и работать с нею одно удовольствие):
Цитата: C/C++void qsort(int a[], int lo, int hi) {
{
int h, l, p, t;
if (lo < hi) {
l = lo;
h = hi;
p = a[hi];
do {
while ((l < h) && (a[l] <= p))
l = l+1;
while ((h > l) && (a[h] >= p))
h = h-1;
if (l < h) {
t = a[l];
a[l] = a[h];
a[h] = t;
}
} while (l < h);
t = a[l];
a[l] = a[hi];
a[hi] = t;
qsort( a, lo, l-1 );
qsort( a, l+1, hi );
}
}
Цитата: Haskell
qsort [] = []
qsort (y:ys) = qsort (filter (< y) ys) ++ [y] ++ qsort (filter (>= y) ys)
А теперь вернёмся к обсуждению международного языка.
Цитата: Алексей Гринь от февраля 10, 2009, 16:26
Цитата: Haskell
qsort [] = []
qsort (y:ys) = qsort (filter (< y) ys) ++ [y] ++ qsort (filter (>= y) ys)
Справедливости ради сюда надо добавить определения «filter» и «++», а возможно и «<» с «>=».
А что значит Окружор, если не секрет?
Цитата: myst от февраля 10, 2009, 17:00
Цитата: Алексей Гринь от февраля 10, 2009, 16:26
Цитата: Haskell
qsort [] = []
qsort (y:ys) = qsort (filter (< y) ys) ++ [y] ++ qsort (filter (>= y) ys)
Справедливости ради сюда надо добавить определения «filter» и «++», а возможно и «<» с «>=».
Пожалуйста.
Цитата: filter
filter :: (a -> Bool) -> [a] -> [a]
filter _ [] = []
filter p (x:xs) | p x = x : filter p xs
| otherwise = filter p xs
Стандартная для любого ФП функция высшего порядка. Она стандартна и используется так же часто, как, скажем, цикл for в сиплюсе.
++ - стандартный оператор склейки нескольких списков в один. А вот реализация:
Цитировать(++) :: [a] -> [a] -> [a]
[] ++ ys = ys
(x:xs) ++ ys = x : (xs ++ ys)
То же самое. Стандартней не бывает.
Это всё т.н. функции высшего порядка, вокруг них строится бóльшая часть философии ФП.
< и
>= - аналог виртуальных функций (точнее, интерфейсов с одним методом, хз как это будет в унылой сиплюсовской терминологии), объект любого пользовательского типа, поддерживающего сравнения, способен быть аргументом этой функции.
Т.е. в данном примере они не значат ничего, у них нет реализации. Это лишь абстракция, обобщение.
+ в примере стек сиплюса загнётся на больших списках, а хаскелевский нет (скомпилируется в итерацию).
А теперь всё же вернёмся к обсуждению международного языка, ребята. Я просто хотел сказать, что С++ - игры детишек в песочек.
(голимый оффтоп набирал обороты) :(
Нормальный оффтоп чего вы? :-[
Труъ ойтишнеги пишут на Оссемблере. Остальное - рукоблудие :P
Цитата: "Алексей Гринь" от
Стандартная для любого ФП функция высшего порядка.
Вот здесь-то и засада. В STL уже есть сортировка и не одна. Часть функций сравнения в Хаскеле может быть вынесена в библиотеку. Я к тому, что для честного сравнения надо либо в обоих языках использовать стандартную библиотеку, либо в обоих не использовать. Хаскелл в любом случае должен выиграть, но не столь эффектно.
Цитата: "злой" от
Труъ ойтишнеги пишут на Оссемблере.
На каком оссемблере для какова працесара? :eat:
Ваще оссемблер не Ъ. Опкоды наше всё!
ЦитироватьВот здесь-то и засада. В STL уже есть сортировка и не одна. Часть функций сравнения в Хаскеле может быть вынесена в библиотеку. Я к тому, что для честного сравнения надо либо в обоих языках использовать стандартную библиотеку, либо в обоих не использовать. Хаскелл в любом случае должен выиграть, но не столь эффектно.
Поспорил бы, оффтопа не хочу.
ЦитироватьЧасть функций сравнения в Хаскеле может быть вынесена в библиотеку.
Вы не поняли. Функции > и <= никуда не выносятся. Вот пример на Си - готов к употреблению, но он работает только с целыми числами. Пример на Хаскелле тоже
готов к употреблению, но он принимает на вход любые сравниваемые объекты, не только целые. Это могут быть как float, так и списки, так и любые другие
пользовательские типы, у которых определены операторы > <=. Примеры абсолютно идентичны в плане работы и не требуют каких-либо сторонних либ.
ЦитироватьЯ к тому, что для честного сравнения надо либо в обоих языках использовать стандартную библиотеку, либо в обоих не использовать.
Без функций filter, map и т.д. ФЯ не может существовать. Рассматривайте это как аналог императивным for, while (которых в ФЯ нет) и т.д., с той лишь разницей, что for и while зашиты глубоко в недрах компилятора, а filter и map описаны на самом языке. Вас, видимо, это смутило.
for и while близки к природе. На ассемблере они реализуются элементарно. А как реализованы ваши перегруженные операторы?
Даешь холивар! Пхнглуи мглвнавх вхагнагл Хаскелль фхтагн!
Цитата: "Алексей Гринь" от
Без функций filter, map и т.д. ФЯ не может существовать. Рассматривайте это как аналог императивным for, while (которых в ФЯ нет) и т.д., с той лишь разницей, что for и while зашиты глубоко в недрах компилятора, а filter и map описаны на самом языке. Вас, видимо, это смутило.
Так любую библиотечную функцию можно трактовать. Поэтому я и говорю, надо сравнивать либо голые грамматики, либо спецификации целиком, которые обычно и стандартную библиотеку описывают. Я предпочитаю второе. Это и практичнее, и понятнее. А то вон у Форта не грамматика, а пшик. :)
ЦитироватьТак любую библиотечную функцию можно трактовать
Т.е. то, что в сишном примере используются операторы, которых нет в Хаскеле это ничего, да, а то что в Хаскелле заместо них используются функции, описанные стандартными средствами и являющиеся самим ядром ФЯ - это уже сразу фу, фу, несправедливо?
ЦитироватьПоэтому я и говорю, надо сравнивать либо голые грамматики
Этот пример можно переписать, используя внутреннию рекурсию, без фильтра. Только я сейчас не осилю.
Название у темы не слишком провокационное? С++ и красота — это чересчур цинично, нет?
Цитата: "Алексей Гринь" от
Этот пример можно переписать, используя внутреннию рекурсию, без фильтра. Только я сейчас не осилю.
Понятно, что можно. Просто он будет, не столь короткий.
Цитата: "Алексей Гринь" от
Т.е. то, что в сишном примере используются операторы, которых нет в Хаскеле это ничего, да, а то что в Хаскелле заместо них используются функции, описанные стандартными средствами и являющиеся самим ядром ФЯ - это уже сразу фу, фу, несправедливо?
Несправедливо не это, а то что в примере на C++ не используется STL. Либо, как я уже предлагал, не использовать стандартные библиотеки и оба велосипеда делать прямо из руды. :)
А вот уж если со стороны Хаскеля подключать либы, то это тем более заткнёт и С++, и СТЛ, и кривой костыль под названьем шаблоны :)
Это все мерянье пиписьками и дело вкуса. Объективные критерии таковы: ставится конкретная задача. Один программер пишет на одном языке, второй - на другом. Готовые программы сравнивают по размеру, безглючности и скорости работы. Остальное - демагогия.
Цитата: "Алексей Гринь" от
А вот уж если со стороны Хаскеля подключать либы, то это тем более заткнёт и С++, и СТЛ, и кривой костыль под названьем шаблоны
Если разрешить подключать любые библиотеки, то, боюсь, Хаскел не сможет тягаться с C++ по охвату задач.
На практике могут вылезать различные грабли, связанные не столько с самим языком, сколько с несовершенством инструментов. И они сильно обламывают.
:3tfu: Я сейчас вроде наконец нашёл себе инструмент для «зубочисток», чтобы не заморачиваться C и C++. Правда, это не Хаскелл.
Цитата: "злой" от
Готовые программы сравнивают по размеру, безглючности и скорости работы. Остальное - демагогия.
Как говаривал Линус: «Shut up and show your code!» :)
Цитата: myst от февраля 10, 2009, 19:51
Цитата: "злой" от
Готовые программы сравнивают по размеру, безглючности и скорости работы. Остальное - демагогия.
Как говаривал Линус: «Shut up and show your code!» :)
Вот-вот. Подход практика.
ЦитироватьЕсли разрешить подключать любые библиотеки, то, боюсь, Хаскел не сможет тягаться с C++ по охвату задач.
Вы уже успели изучить список либ Хаскеля? :)
ЦитироватьНа практике могут вылезать различные грабли, связанные не столько с самим языком, сколько с несовершенством инструментов. И они сильно обламывают.
"Несовершенство инструментов" это отсутствие красивой ИДЕшечке где можно так кнопочку КЛАЦ! на формочку прикрепить, а потом ещё радиобаттон так КЛАЦ! немного повыше? Мама, смотри, я программист! :D
Я же с самого начала говорил, ФЯ не предназначены для IO, но они идеально подходят для сложнейшей логики, под которую только хедеры на унылом сипэпэ писались бы месяцы.
Сложнейшая логика упрощается при помощи карт Карно до простейшей :P
ЦитироватьГотовые программы сравнивают по размеру, безглючности и скорости работы. Остальное - демагогия.
Посчёт размера - у Хаскель-программ, скомпиленных GHC, минимальный размер где-то ~400 кб, но это потому что внутри зашит сразу весь рантайм со всякими сборщиками мусора ит.д. Посчёт безглючности - проводились тесты, точных данных не помню, смысл был в том, что на одну ошибку/баг ФЯ приходятся десятки сипэпэшных. Посчёт скорости работы - в пределах 5-10% от сипэпэ, но тесты я смотрел давно, ситуация, возможно, уличшилась.
я не люблю С++, потому что в нем есть глобальные переменные, что нарушает логику ООП. мой любимый - C#
Цитата: "злой" от
Труъ ойтишнеги пишут на Оссемблере. Остальное - рукоблудие :P
:yes:
А красота, это вот:
-module(fact).
-export([fac/1]).
fac(0) -> 1;
fac(N) -> N * fac(N-1).
8-)
Цитата: "Алексей Гринь" от
Вы уже успели изучить список либ Хаскеля?
Вы в этом сомневаетесь? Тогда предлагаю, сделать так: Вы публикуете список библиотек для Хаскела, я — для C++. По рукам? ;)
Цитата: "Алексей Гринь" от
"Несовершенство инструментов" это отсутствие красивой ИДЕшечке где можно так кнопочку КЛАЦ! на формочку прикрепить, а потом ещё радиобаттон так КЛАЦ! немного повыше? Мама, смотри, я программист!
Нет, это когда, например, с поддержкой уникода ахтунг, со скоростью выполнения ахтунг в квадрате, с потреблением памяти ахтунг в кубе, плюс анальный доступ к системным функциям и с совместимостью различных реализаций ужоснах.
Цитата: "regn" от
мой любимый - C#
Что только не делают люди, лишь бы не пользоваться Java. ;)
Хаскелл стандартизирован? Как у его реализаций с поддержкой уникода? Какая функциональность включена в стандартную библиотеку? И наконец, какие он имеет преимущества перед CL? :smoke:
Хаскелл стандартизирован. Уникод есть. Функциональность перечислять всю? На haskell.org дуйте. CL - common lisp? да он же убог, незря Схему придумали.
Цитата: myst от февраля 10, 2009, 20:53
Цитата: "regn" от
мой любимый - C#
Что только не делают люди, лишь бы не пользоваться Java. ;)
C# давно обогнал яву. Благодаря нему закостенелая старопердунская политика самой Явы канула лету - конкуренция, как никак, появилась, и она оживилась, стала развиваться. Самый юмор в том, что ява с каждым новым релизом тупо копирует фишки у C# (яволюбы дженерики, вон, скопировали, но так убого реализовав, что мне стыдно). Я как-то портировал c C# на Java код своей либы для работы с irc, и только так понимаешь, насколько убог тот или иной язык. Для явовской версии пришлось ОЧЕНЬ много дописывать (подчёркиваю, дописывать, а не переписывать).
Цитата: "Алексей Гринь" от
CL - common lisp? да он же убог, незря Схему придумали.
Это несерьёзные лозунги. :no: Так какие у Хаскелла преимущества?
Цитата: "Алексей Гринь" от
Функциональность перечислять всю?
По категориям.
Цитата: "myst" от
На haskell.org дуйте.
У нас холивар, или прогулка с гидом по сайтам? :)
Цитата: "Алексей Гринь" от
C# давно обогнал яву. Благодаря нему закостенелая старопердунская политика самой Явы канула лету - конкуренция, как никак, появилась, и она оживилась, стала развиваться. Самый юмор в том, что ява с каждым новым релизом тупо копирует фишки у C# (яволюбы дженерики, вон, скопировали, но так убого реализовав, что мне стыдно). Я как-то портировал c C# на Java код своей либы для работы с irc, и только так понимаешь, насколько убог тот или иной язык. Для явовской версии пришлось ОЧЕНЬ много дописывать (подчёркиваю, дописывать, а не переписывать).
Неважно насколько убога Java, важно, что она есть практически везде. А .NET где? Windows и всё, если не считать вечно догоняющего Mono. Посему, в топку это поделие Нанософта.
Учитывая, что 95% мира пользует форточки, любовь отнекиваться от такой широкой аудитории больше походит на психическую болезнь (аутизм? :)).
Цитата: "Алексей Гринь" от
Учитывая, что 95% мира пользует форточки, любовь отнекиваться от такой широкой аудитории больше походит на психическую болезнь
А триллион всевозможных мобильных девайсов не в счёт, да? ;)
Ну да бог с ним, с дотнетом. В чём крутизна Хаскелла? У GHC есть режим выполнения без явной фазы компиляции?
То есть я могу написать скрипт типа
#!/bin/ghc
-- some Haskell code
и запускать его из shell'а, не заморачиваясь созданием бинарников?
Цитата: злой от февраля 10, 2009, 19:49
Это все мерянье пиписьками
Ну так в этом же весь смысл. (￣‿￣)y-～
ЦитироватьТо есть я могу написать скрипт типа
и запускать его из shell'а, не заморачиваясь созданием бинарников?
Есть.
Вообще, первоначально спор был не о Хаскеле конкретно, а о ФЯ вообще. Эрланг, например, весьма практичный язык. Или его ценность вы тоже будете ставить во сомнение?
ЦитироватьА триллион всевозможных мобильных девайсов не в счёт, да?
Ненависть.
Как вообще можно жить без лямбда-исчисления, каррирования, паттерн-матчинга, выведения типов, функций высшего порядка, рекурсий, корекурсий, генераторов, ленивых вычислений, алгебраических типов, замыканий? Ащще хз.
Цитата: Алексей Гринь от февраля 10, 2009, 22:52
Как вообще можно жить без лямбда-исчисления, каррирования, паттерн-матчинга, выведения типов, функций высшего порядка, рекурсий, корекурсий, генераторов, ленивых вычислений, алгебраических типов, замыканий? Ащще хз.
Это слишком сложно. Где вы найдёте людей, которые все это изучат и полюбят?
Ох. Ничуть не сложнее ковыряния в песочке.
10 PRINT "End of story"
20 GOTO 10
30 END
;D
Цитата: "Алексей Гринь" от
Вообще, первоначально спор был не о Хаскеле конкретно, а о ФЯ вообще. Эрланг, например, весьма практичный язык. Или его ценность вы тоже будете ставить во сомнение?
Я не ставлю под сомнение ценность, меня интересует практическая пригодность. Common Lisp для «зубочисток» — милое дело. А Хаскелл? Вы его в повседневной практике используете? Для чего? Красота описания алгоритма быстрой сортировки приносит только эстетическое удовольствие, к сожалению.
Если вы не знаете, что такое алгебраические типы данных, и в чём их преимущество, вы не поймёте преимуществ Хаскелля.
Цитата: "Алексей Гринь" от
Если вы не знаете, что такое алгебраические типы данных, и в чём их преимущество, вы не поймёте преимуществ Хаскелля.
Вы не на мой вопрос отвечаете. Я Вас спрашиваю, для решения каких задач лично Вы его используете?
AI.
Цитата: "Алексей Гринь" от
AI.
А поподробнее, с примерами кода, показывающими ништяки Хаскелла?
Большую
вам
дулю
- НАТЕ!
Цитата: "Алексей Гринь" от
Большую
вам
дулю
- НАТЕ!
Значит примеров кода нет. Так и запишем. Ну хоть одну из задач опишите, а то просто AI не слишком содержательно. :smoke:
Цитата: Алексей Гринь от февраля 11, 2009, 16:23
AI.
Наверно пишете умного бота для ведения бесед на лингвофоруме? :)
Цитата: "Чайник777" от
Наверно пишете умного бота для ведения бесед на лингвофоруме?
Было у меня такое подозрение, было. ;)
C++ — красивый?! Из всех С-подобных у него, по-моему, самый нелогичный синтаксис. Одно только сверхиспользование знаков < и > чего стóит! Возможности языка, безусловно, шире, чем у многих других. Но это ведет лишь к тому, что у программиста С++ есть больше вариантов сделать ошибку на ровном месте.
Цитата: "Python" от
C++ — красивый?!
Я говорил, название темы — провокация. ;)
Если бы я знал, что мое оффтоповое сообщение (вместе с последующим оффтопом) выделят в отдельную тему, то не стал бы его писать. Так что никакой провокации я не задумывал, просто антитезис высказыванию Артемону, и то невраждебный.
Если и выносить тему, то лучше в "Просто общение" и названием просто "C++". А то получился безапелляционный тезис, который я не выдвигал.
Апофеоз убожества как Си++, так и его парсеров, это обязательность вставки пробела при вложенных шаблонах, типа:
f = new List<List<>>();
нужно заменять на
f = new List<List<> >();
Видите ли, >> их кривой парсер воспринимает за совершенно другой токен. Таких кривостей на каждом шагу.
Да, это действительно неприятная особенность. Однако, Алексей Гринь, Вы напрасно приписываете ФПЯ высокое быстродействие, в этом отношении они сильно уступают языкам вроде С++. Возможно, ситуация изменится, когда будут получат распространение процессоры, работающие напрямую с байт-кодом.
Ну ничего, скоро выйдет новый стандарт с новыми сюрпризами. А сколько радости принесут его рализации... :smoke:
Цитата: "GaLL" от
Однако, Алексей Гринь, Вы напрасно приписываете ФПЯ высокое быстродействие, в этом отношении они сильно уступают языкам вроде С++. Возможно, ситуация изменится, когда будут получат распространение процессоры, работающие напрямую с байт-кодом.
Не уловил связь с байт-кодом, однако. :what:
GaLL, ФЯ уже давно умеют компилироваться в натив. С быстродействием, уступающим императивным на пару процентов, и то засчёт более тщательного слежения за безопасностью (в ФЯ, в принципе, просто нереально получить ошибку времени исполнения, типа там memory violation, null dereference, stack overflow etc., что в ответственных приложениях не приветствуется).
Я слышал, после сбоя в программе одного космич. аппарата, написанной то ли на С, то ли на С++, решено было в целях безопасности перейти на ФЯ. И вы должны понимать, какой сложности расчёты проводятся на подобного рода проектах ежесекундно.
Цитата: Алексей Гринь от февраля 13, 2009, 17:34
GaLL, ФЯ уже давно умеют компилироваться в натив. С быстродействием, уступающим императивным на пару процентов, и то засчёт более тщательного слежения за безопасностью (в ФЯ, в принципе, просто нереально получить ошибку времени исполнения, типа там memory violation, null dereference, stack overflow etc., что в ответственных приложениях не приветствуется)
Ну давайте сравним два компилятора: один - любого ФПЯ, другой, скажем, майкрософтовский или интеловский компилятор С++, написав какой-нибудь алгоритм.
Цитата: "Алексей Гринь" от
Я слышал, после сбоя в программе одного космич. аппарата, написанной то ли на С, то ли на С++, решено было в целях безопасности перейти на ФЯ. И вы должны понимать, какой сложности расчёты проводятся на подобного рода проектах ежесекундно.
Ой ли? Там разве не на Асме пишуть?
ЦитироватьНу давайте сравним два компилятора: один - любого ФПЯ, другой, скажем, майкрософтовский или интеловский компилятор С++.
Если любой ФПЯ, то сразу же - окамл-подобный F# под ДотНет, который 95% от скорости С++ :) Я с удовольствием подарю в никуда 5% ради надёжности и гарантированности верного исполнения программы.
Цитата: злой от февраля 13, 2009, 17:40
Цитата: "Алексей Гринь" от
Я слышал, после сбоя в программе одного космич. аппарата, написанной то ли на С, то ли на С++, решено было в целях безопасности перейти на ФЯ. И вы должны понимать, какой сложности расчёты проводятся на подобного рода проектах ежесекундно.
Ой ли? Там разве не на Асме пишуть?
Компиляторы plain С генерят лучший асм, нежели человеки вручную.
Цитата: Алексей Гринь от февраля 13, 2009, 17:42
Цитата: злой от февраля 13, 2009, 17:40
Цитата: "Алексей Гринь" от
Я слышал, после сбоя в программе одного космич. аппарата, написанной то ли на С, то ли на С++, решено было в целях безопасности перейти на ФЯ. И вы должны понимать, какой сложности расчёты проводятся на подобного рода проектах ежесекундно.
Ой ли? Там разве не на Асме пишуть?
Компиляторы plain С генерят лучший асм, нежели человеки вручную.
Та шо ви говоrите. И чем же он лучше?
Цитата: "Алексей Гринь" от
Я слышал, после сбоя в программе одного космич. аппарата, написанной то ли на С, то ли на С++, решено было в целях безопасности перейти на ФЯ. И вы должны понимать, какой сложности расчёты проводятся на подобного рода проектах ежесекундно.
Это уже не имеет отношения к быстродействию. Проблема малой разработанности средств защиты кода в С/C++ (типа контроля переполнения буфера и т. п.) действительно серьезна, эта и многие другие причины постепенно должны привести к его почти полному вытеснению другими ЯП.
Цитата: злой от февраля 13, 2009, 17:43
Цитата: Алексей Гринь от февраля 13, 2009, 17:42
Цитата: злой от февраля 13, 2009, 17:40
Цитата: "Алексей Гринь" от
Я слышал, после сбоя в программе одного космич. аппарата, написанной то ли на С, то ли на С++, решено было в целях безопасности перейти на ФЯ. И вы должны понимать, какой сложности расчёты проводятся на подобного рода проектах ежесекундно.
Ой ли? Там разве не на Асме пишуть?
Компиляторы plain С генерят лучший асм, нежели человеки вручную.
Та шо ви говоrите. И чем же он лучше?
Если проект - хелловорлд, то хуже, конечно же.
Цитата: Алексей Гринь от февраля 13, 2009, 17:41
ЦитироватьНу давайте сравним два компилятора: один - любого ФПЯ, другой, скажем, майкрософтовский или интеловский компилятор С++.
Если любой ФПЯ, то сразу же - окамл-подобный F# под ДотНет, который 95% от скорости С++ :) Я с удовольствием подарю в никуда 5% ради надёжности и гарантированности верного исполнения программы.
Какие 5 процентов, о чем Вы? ;D
Цитата: Алексей Гринь от февраля 13, 2009, 17:45
Цитата: злой от февраля 13, 2009, 17:43
Цитата: Алексей Гринь от февраля 13, 2009, 17:42
Цитата: злой от февраля 13, 2009, 17:40
Цитата: "Алексей Гринь" от
Я слышал, после сбоя в программе одного космич. аппарата, написанной то ли на С, то ли на С++, решено было в целях безопасности перейти на ФЯ. И вы должны понимать, какой сложности расчёты проводятся на подобного рода проектах ежесекундно.
Ой ли? Там разве не на Асме пишуть?
Компиляторы plain С генерят лучший асм, нежели человеки вручную.
Та шо ви говоrите. И чем же он лучше?
Если проект - хелловорлд, то хуже, конечно же.
У меня есть кое-какой опыт дизассемблирования (прошивок для спутниковых ресиверов). Там местами либо программист сухорукий, либо компилятор неэффективный, но код явно можно было сделать порациональнее. Асм рулит.
Цитата: myst от февраля 13, 2009, 17:31
Цитата: "GaLL" от
Однако, Алексей Гринь, Вы напрасно приписываете ФПЯ высокое быстродействие, в этом отношении они сильно уступают языкам вроде С++. Возможно, ситуация изменится, когда будут получат распространение процессоры, работающие напрямую с байт-кодом.
Не уловил связь с байт-кодом, однако. :what:
Байт-код теоретически может быть более-менее приближенным к ФПЯ, машинный же язык - вряд ли.
Цитата: GaLL от февраля 13, 2009, 17:47
Цитата: Алексей Гринь от февраля 13, 2009, 17:41
ЦитироватьНу давайте сравним два компилятора: один - любого ФПЯ, другой, скажем, майкрософтовский или интеловский компилятор С++.
Если любой ФПЯ, то сразу же - окамл-подобный F# под ДотНет, который 95% от скорости С++ :) Я с удовольствием подарю в никуда 5% ради надёжности и гарантированности верного исполнения программы.
Какие 5 процентов, о чем Вы? ;D
5 процентов, да. Вас это удивляет?
Цитата: GaLL от февраля 13, 2009, 17:50
Цитата: myst от февраля 13, 2009, 17:31
Цитата: "GaLL" от
Однако, Алексей Гринь, Вы напрасно приписываете ФПЯ высокое быстродействие, в этом отношении они сильно уступают языкам вроде С++. Возможно, ситуация изменится, когда будут получат распространение процессоры, работающие напрямую с байт-кодом.
Не уловил связь с байт-кодом, однако. :what:
Байт-код теоретически может быть более-менее приближенным к ФПЯ, машинный же язык - вряд ли.
И в чём же принципиальное отличие байткода от машинных кодов?
А теперь попробуйте перевести несколько предложений на этот язык и каково это будет звучать... ;D
Цитата: Алексей Гринь от февраля 13, 2009, 17:50
5 процентов, да. Вас это удивляет?
Меня это не удивляет, я знаю, что это - фантастика (если, конечно, мы говорим о неких "чистых" алгоритмах типа поиска нескольких подстрок в строке и т. п.).
Цитата: Алексей Гринь от февраля 13, 2009, 17:42
Компиляторы plain С генерят лучший асм, нежели человеки вручную.
Тут именно в автоматическом генерировании. Человек почти во всех случаях (кроме самых тривиальных) может придумать, как оптимизировать созданный компилятором код, но на это может уйти очень много времени.
Цитата: GaLL от февраля 13, 2009, 17:55
Цитата: Алексей Гринь от февраля 13, 2009, 17:42
Компиляторы plain С генерят лучший асм, нежели человеки вручную.
Тут именно в автоматическом генерировании. Человек почти во всех случаях (кроме самых тривиальных) может придумать, как оптимизировать созданный компилятором код, но на это может уйти очень много времени.
Написали на Си, компилятор откомпилировал, критические куски на Асме сделали?
Цитата: GaLL от февраля 13, 2009, 17:53
Цитата: Алексей Гринь от февраля 13, 2009, 17:50
5 процентов, да. Вас это удивляет?
Меня это не удивляет, я знаю, что это - фантастика (если, конечно, мы говорим о неких "чистых" алгоритмах типа поиска нескольких подстрок в строке и т. п.).
Если нравится жить мифами и предубеждениями, пожалуйста.
В си-языках мне не нравится чуствительность к регистру символов. Все таки, для реальных языков это непривычно
Цитата: злой от февраля 13, 2009, 17:57
Написали на Си, компилятор откомпилировал, критические куски на Асме сделали?
Да, например, так. В этом случае, как и если реализовывать проект целиком на ассемблере, явно потребуется значительно больше времени, чем если не касаться вопросов быстродействия.
Хм, если бы среди компьютеров провели опрос какой язык программирования им нравится, что бы они выбрали? :tss:
Цитата: jvarg от февраля 13, 2009, 17:59
В си-языках мне не нравится чуствительность к регистру символов. Все таки, для реальных языков это непривычно
рЕгИСТРонЕзавИСимОСТЬ ДЛя ЭмО...)))))))))))))))))))))))))
А вообще, дисциплинирует хорошо. Писать в разных частях программы имена переменных/классов в разных регистрах - это какая-то ущербность.
Цитата: Алексей Гринь от февраля 13, 2009, 17:57
Если нравится жить мифами и предубеждениями, пожалуйста.
Я предложил поставить эксперимент.
Цитата: GaLL от февраля 13, 2009, 18:06
Цитата: Алексей Гринь от февраля 13, 2009, 17:57
Если нравится жить мифами и предубеждениями, пожалуйста.
Я предложил поставить эксперимент.
Что будем сравнивать? На какой задаче?
Цитата: Невский чукчо от февраля 13, 2009, 18:02
Хм, если бы среди компьютеров провели опрос какой язык программирования им нравится, что бы они выбрали? :tss:
Ассемблер, конечно! :) На всех остальных языках процессорам приходится выполнять много лишнего. Вспоминается mov eax, eax из проги, написанной в Delphi.
Цитата: Алексей Гринь от февраля 13, 2009, 18:08
Что будем сравнивать? На какой задаче?
Вариантов очень много, не знаю, на чем остановиться.
Может, попробуем C# vs. C++? C# третьей версии наполовину функционален :) С собой сейчас только gcc и C#овский компилятор.
Цитата: Алексей Гринь от февраля 13, 2009, 18:12
Может, попробуем C# vs. C++? C# третьей версии наполовину функционален :) С собой сейчас только gcc и C#овский компилятор.
Тоже можно. Только С++ лучше будем тестить на компиляторе от Intel или Microsoft, они генерируют более быстродейственный код, нежели gcc/g++, по крайней мере те версии, с которыми я сталкивался.
Цитата: "злой" от
У меня есть кое-какой опыт дизассемблирования (прошивок для спутниковых ресиверов). Там местами либо программист сухорукий, либо компилятор неэффективный, но код явно можно было сделать порациональнее. Асм рулит.
Качество кода у разных компиляторов под разные процессоры разное. Если для IA-32 и компилятор от Intel, то я тягаться с ним не буду. А вот для Atmel'ов можно потягаться. :)
К тому же не надо забывать, что даже в пределах IA-32 оптимальный машинный код для разных моделей процессоров будет разным. Ассемблер теряет смысл. А если мы хотим перенести программу на другую процессорную архитектуру, то в случае ассемблера идём за мылом и верёвкой. :)
Цитата: "GaLL" от
Человек почти во всех случаях (кроме самых тривиальных) может придумать, как оптимизировать созданный компилятором код, но на это может уйти очень много времени.
На каком проценте задач это жизненно необходимо?
Какой получаемый профит? Что делать при апгрейде процессора, снова грызть этот кактус?
ЦитироватьТолько С++ лучше будем тестить на компиляторе от Intel или Microsoft
Не имею таких и не умею. Интел - согласен, Майкрософт - поспорил бы.
Цитата: myst от февраля 13, 2009, 18:24
Цитата: "GaLL" от
Человек почти во всех случаях (кроме самых тривиальных) может придумать, как оптимизировать созданный компилятором код, но на это может уйти очень много времени.
На каком проценте задач это жизненно необходимо?
Какой получаемый профит? Что делать при апгрейде процессора, снова грызть этот кактус?
Вы так говорите, как будто я за оптимизацию всего подряд. :) Вовсе нет, это, так сказать, маргинальня задача.
Цитата: Алексей Гринь от февраля 13, 2009, 18:25
ЦитироватьТолько С++ лучше будем тестить на компиляторе от Intel или Microsoft
Не имею таких и не умею. Интел - согласен, Майкрософт - поспорил бы.
В смысле - поспорил? :???
А какое умение Вы подразумеваете? Сам язык везде почти один и тот же. Наверно, речь идет о разнообразных опциях компиляции, но тут можно в порядке эксперимента проверить эффективность кода, сгенереированного с разными ключами.
Цитата: "GaLL" от
Вы так говорите, как будто я за оптимизацию всего подряд. Вовсе нет, это, так сказать, маргинальня задача.
В такой ситуации руками оптимизировать переписыванием на ассемблер тоже нет никакого смысла. В общем, асм — для встроенных систем, там он действительно Д'Артаньян. :)
Цитата: GaLL от февраля 13, 2009, 18:29
Цитата: Алексей Гринь от февраля 13, 2009, 18:25
ЦитироватьТолько С++ лучше будем тестить на компиляторе от Intel или Microsoft
Не имею таких и не умею. Интел - согласен, Майкрософт - поспорил бы.
В смысле - поспорил? :???
А какое умение Вы подразумеваете? Сам язык везде почти один и тот же. Наверно, речь идет о разнообразных опциях компиляции, но тут можно в порядке эксперимента проверить эффективность кода, сгенереированного с разными ключами.
Ну-ну, особенно микрософтский С++ такой же. Очень такой же. Да.
Господа, всё уже сделано до нас!
http://shootout.alioth.debian.org
Цитата: myst от февраля 13, 2009, 18:30
Цитата: "GaLL" от
Вы так говорите, как будто я за оптимизацию всего подряд. Вовсе нет, это, так сказать, маргинальня задача.
В такой ситуации руками оптимизировать переписыванием на ассемблер тоже нет никакого смысла. В общем, асм — для встроенных систем, там он действительно Д'Артаньян. :)
Так я о том же. "Магринальная задача", т. е. иногда возникает такая необходимость, в подавляющем же большинстве случает - совсем нет.
Цитата: myst от февраля 13, 2009, 18:33
Господа, всё уже сделано до нас!
http://shootout.alioth.debian.org
Я то же самое нагуглил, но мне везде The requested URL /u32q/gpp.php was not found on this server. пишут.
Цитата: Алексей Гринь от февраля 13, 2009, 18:33
Ну-ну, особенно микрософтский С++ такой же. Очень такой же. Да.
Если ограничиться тестированием компиляторов, то зачем весь этот Microsoft specific?
О, вдруг заработало.
Цитата: "GaLL" от
Так я о том же. "Магринальная задача", т. е. иногда возникает такая необходимость, в подавляющем же большинстве случает - совсем нет.
Я хотел сказать, что на персоналках и для «маргинальной задачи» тоже смысла нет. :)
Цитата: myst от февраля 13, 2009, 18:36
Цитата: "GaLL" от
Так я о том же. "Магринальная задача", т. е. иногда возникает такая необходимость, в подавляющем же большинстве случает - совсем нет.
Я хотел сказать, что на персоналках и для «маргинальной задачи» тоже смысла нет. :)
Нет, есть. Вспомните Doom II и Quake. Можно еще вспомнить разработку ОС и драйверов.
Цитата: "GaLL" от
Нет, есть. Вспомните Doom II и Quake.
В те времена смысл ещё сохранялся. А сейчас интеловцы такой зверинец развели, что чёрт ногу сломит. Количество специалистов, способных его приручить, боюсь, очень невелико. А ведь ещё есть AMD. Да и Cyrix восстал из ада. :)
Вы имеете в виду расширения архитектуры x86, начиная от MMX и пр.? Это не такая уж проблема, просто заниматься этим теперь нет особого смысла. И это одна из причин, почему время С++ с его упором на быстродействие уходит.
Цитата: "GaLL" от
Вы имеете в виду расширения архитектуры x86, начиная от MMX и пр.?
Я имею в виду, что внутренняя архитектура интеловских процессоров меняется от модели к модели. И машинный код, оптимальный для одной модели, уже не так оптимален для другой.
Цитата: "GaLL" от
Можно еще вспомнить разработку ОС и драйверов.
При разработке ОС (MenuetOS не в счёт :) ) обычно стремятся минимизировать необходимый ассемблерный код, и с драйверами та же история, насколько я знаю.
Цитата: myst от февраля 13, 2009, 19:03
Цитата: "GaLL" от
Вы имеете в виду расширения архитектуры x86, начиная от MMX и пр.?
Я имею в виду, что внутренняя архитектура интеловских процессоров меняется от модели к модели. И машинный код, оптимальный для одной модели, уже не так оптимален для другой.
Безусловно, но некоторые аспекты оптимизации все равно более-менее стабильны. Например, эффективно избавление от условных операторов (то бишь условных джампов), выравнивание адресов перехода, не говоря уже о простом выкидывании лишних инструкций или замене более простой вариант. Кроме того, есть такие грубые "хаки", как самомодифицирующийся код. ;)
ЦитироватьКроме того, есть такие грубые "хаки", как самомодифицирующийся код. ;)
Его дебуггить потом ...
Цитата: "GaLL" от
Кроме того, есть такие грубые "хаки", как самомодифицирующийся код.
Растопчем защиту памяти, друзья. ;)
Цитата: "GaLL" от
Например, эффективно избавление от условных операторов (то бишь условных джампов), выравнивание адресов перехода, не говоря уже о простом выкидывании лишних инструкций или замене более простой вариант.
На этом современные компиляторы фору человекам дадут, не говоря о скорости.
А ещё в С++ есть такая крутая вещь
#ifndef _ACTOR_HPP
#define _ACTOR_HPP
#endif /* _ACTOR_HPP */
Любой современный ЯП должен имет такую фичу, да! Ура!