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

T>Мне кажется, это прекрасно. Достаточно просто почитать немного этот форум и "решатели проблемы двух ботинок" обнаружатся в ассортименте. Мне кажется, эта фраза достойна быть мемом. Чтобы, когда видишь как люди изощряются на одной ноге прыгать, всё сразу было ЯСНО -- ага, вот ещё один дядя решает проблему двух ботинок.

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

Например, попробуйте, возьмите Си для разработки веб-приложений, конечно, можно. Это как можно дойти пешком из Сибири до Москвы. Но лучше я сяду на самолет и долечу за несколько часов. Возьму Java/.Net/Ruby/Python, да тот же Lisp и долечу с комфортом.

Вот на самом деле кого на этом форуме полно, так это тех, кто ищет один silver bullet. И обычно, правда под этот silver bullet язык Си, ну никак не подойдет, тут как раз Lisp или Nemerle под кандидаты больше подходят, потому как они умеют подстраиваться под задачу, довольно гибкие инструменты, за счет метапрограммирования.

T>Кстати вся книга совершенно удивительна. Относительно каждой строчки стандарта C99 обсуждаются причины почему она должна быть именно такой и не иначе, приводится много кода, сравнение с другими языками (в первую очередь C++), обсуждается куча интересных вопросов из экономики и социологии разработки ПО, приводятся результаты статистических исследований и т.п., очень рекомендую к прочтению всем, кто интересуется языком C. Правда объёмная -- чуть больше 1600 страниц в pdf.

Вот я тебе приведу цитату из не менее удивительной книги Paradigms of Artificial Intelligence Programmin (PAIP) by Peter Norvig:

There is a myth that Lisp (and Prolog) are "special-purpose" languages, while
languages like Pascal and C are "general purpose." Actually, just the reverse is
true. Pascal and C are special-purpose languages for manipulating the registers and
memory of a von Neumann-style computer. The majority of their syntax is devoted
to arithmetic and Boolean expressions, and while they provide some facilities for
forming data structures, they have poor mechanisms for procedural abstraction
or control abstraction. In addition, they are designed for the state-oriented style
of programming: computing a result by changing the value of variables through
assignment statements.
Lisp, on the other hand, has no special syntax for arithmetic. Addition and
multiplication are no more or less basic than list operations like appending, or string
operations like converting to upper case. But Lisp provides all you will need for
programming in general: defining data structures, functions, and the means for
combining them.

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

T>Скриптовых поделок было во все времена навалом и ещё будет навалом когда эти забудут. Во времена когда C только разрабатывался, эту нишу занимал basic. Тоже можно было писать с первых минут и была сразу куча сахара.

"Скриптовые поделки" Мы тут инженера собрались или кто?

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

N>А по поводу истории и обоснований языка — позвольте-ка задать пару встречных вопросов. Вот как Вы считаете (после чтения книги) — какой частью тела вообще думал тот, кто вводил функции типа strncat(), и тот, кто сохраняет их в современном стандарте даже без пометки "deprecated, don't use"?

В ней сделали restrict на параметры, начиная с C99, поскольку основные и неочевидные проблемы были в тех случаях когда параметры могли пересекаться.

P.S. Я не наезжал на Фортран, я высказал своё личное мнение относительно причин его падения. Если вы считаете что это ещё не труп и относитесь к числу тех энтузиастов которые хотят снова поставить это на ноги -- ну что же, достойная уважения позиция. Не вижу причин устраивать на эту тему холивар. С моей точки зрения -- птичка сдохла. "Новый Фортран" -- это такой оксюморон, как упомянутая мыщхом свинка. И не новый и не Фортран.

Здравствуйте, мыщъх, Вы писали:

М>гм. позвольте внести поправки и уточнения. например, в си нет возможности вернуть более одного аргумента из функции. и потому приходится либо возвращать структуру, что тормоза, либо возвращать значение по указателю, что снова тормоза. добавив туплы мы не только сделаем программу нагляднее, но и в большинстве случаев сможем обойтись одними регистрами. мы выиграли скорость, наглядность, сократили размер сгенерированного кода, потребности в памяти и даже упростили оптимизатор, т.к. теперь ему не нужно проводить глобальную оптимизацию, чтобы понимать, что foo(int *data_in, int *data_a_out, int *status) это три разных непересекающихся блока памяти.

М>а что мы при этом проиграли? тем более, что если си позволяет вернуть структуру (а он позволяет), то возвращение тупла даже не усложняет компилятор. можно ввести очень простое правило -- если это тупл из двух int'ов, то на x86 мы возвращаем первый в eax, второй в edx. в остальных случаях действуем так, как при возвращении структуры.

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

Перечитайте что вы написали. Вы же по сути сами и признали, что туплы не дают выгоды. С точки зрения ассемблера компилятору абсолютно пофиг раскладывать по регистрам структуру из двух интов или тупл из двух интов, что там что там два регистра. Кроме того туплы утяжеляют фронтенд и замедляют компиляцию. Ровно на разбор тупла. Кстати ещё и заставляют вводить перегруженные слова/символы в язык. И всё это -- напомню -- без очевидной выгоды. Кроме того туплы ухудшают читаемость программы. Вместо очевидного имени члена структуры обращение может вестись по индексу тупла или вообще идти итерирование по самому туплу. Итерирование кстати может быть и неявным -- там скажем по указателю на тупл. Или даже (представьте этот ужас) -- по смещённому указателю на член тупла. Кстати об итерировании. Оно не представляется естественным образом в ассемблере ни одной популярной архитектуры (почему у нас и нет итерирования по сишным структурам) поскольку в общем случае данные в тупле -- РАЗНОГО размера. Более того -- возникают аналогичные структурам вопросы с паддингом, c эквивалентностью по типам данных, с передачей через varargs и т.п. которые в стандарте и во всех ABI существующих архитектур придётся прописывать ещё раз -- только теперь для туплов. Ну и к тому же туплы повышают порог входа в язык и усложняют обучение, а также усложняют компиляторы для простых архитектур.

Короче самое место туплу -- в C++, где обкатываются и отрабатываются все спорные идеи (туда же ссылки, шаблоны и т.п.). Ну собственно его туда и добавили, люди работают

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

___>Мда, это не прекрасно, а печально. Печально, что автор ограничивает набор доступного ему инструментария только одним. А еще печально, что Вы нашли это таким гениальным и прекрасным. Пока Вы так и будете ходить на одних лишь двух ботинках, другие будут ездить на машине, летать на самолетах, ездить в поездах, там, где это уместно.

О да, я много видел таких летунов. И поездунов. Живут они обычно весело, но недолго. В критический момент в "самом лучшем фреймворке для самой быстрой разработки" оказывается одна такая маленькая мешающая особенность... разумеется это всегда и есть тот самый момент когда сроки на проект уже горят. И тот самый поезд на котором вы так быстро проехали десять километров, вам приходится ещё километр тащить на плечах в ту самую точку куда почему-то нет рельсов. Немногие дотаскивают.

Я обычно стараюсь в корпоративной среде держаться от летунов с горящими глазами подальше. Чтобы когда от очередного брызги разлетаются -- не задело. Выглядят они... противоречиво. Обычно то, что вы называете "ездой на поезде" мне представляется прыжками на месте на одной ноге с переворотом через голову. Хоп -- у меня тут будет паттерн "итератор" (прыжок) -- хоп но не реализовать же его как лоху, надо взять Traversal ведь монадные трансформеры это круто -- хоп (тройное сальто через голову с переворотом) и так далее. В джигитовке с "тысячей языков тысячей технологий" самой по себе нет ничего плохого, я и сам её люблю, мозги поразмять, когти поточить. Но стоит чётко понимать: джигитовка -- не разработка. В серьёзной разработке, два языка на проект -- перебор, три -- безумие. Хотя бы потому, что найти команду из десяти человек, знающих один и тот же язык (особенно если это язык C) -- легко. А вот найти, знающих три...

P.S. Цитата ваша -- из той же серии -- саблю в зубы и поскакали с присвистом. Ну где вы возьмёте такую архитектуру, чтобы на неё не лёг язык C и чтобы таких компов в мире было больше десятка? А если не возьмёте -- то и зачем вам оно?

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

HH>Я не собираюсь доказывать, что Lisp или Haskell лучше чем C.

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

Если же взять метапрограммирование или поддержку ФП, то у С не будет шансов.

Критериев ведь масса. Скажем простота изучения средним человеком. Тут у лиспа тоже нет шансов. Именно по тому С завоевал мир, а Лисп остался уделом гиков.

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

B>>Добавлю только, что совершенный язык, это тот, в котором меньше слов, а сказать можно больше. Наличие 2-х пунктов сравнения, значительно затрудняет задачу поиска совершенного языка. То ли найти клопа на веревке для белья, а то ли на всем полу...
B>С количеством слов не согласен. Теоретически все можно обозначить знаками.. Но разиьаться в этой мешанине знаков будет совсем не просто. Это типа каста организуется. Важнее минимизация правил языка и базовых понятий. А уже из сколько понятий (они же слова) можно из них определить вопрос сорок пятый. Кстати, если не ограничивать длину слова, то вообще континуум получается. Частенько встречаю что количество фраз языка счетно. Это не правильно.

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

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

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

T>О да, я много видел таких летунов. И поездунов. Живут они обычно весело, но недолго. В критический момент в "самом лучшем фреймворке для самой быстрой разработки" оказывается одна такая маленькая мешающая особенность... разумеется это всегда и есть тот самый момент когда сроки на проект уже горят. И тот самый поезд на котором вы так быстро проехали десять километров, вам приходится ещё километр тащить на плечах в ту самую точку куда почему-то нет рельсов. Немногие дотаскивают.

Может хватит уже с метафорами? Ты конкретно скажи, для веб-приложений среднего уровня возьмешь один лишь Си? Для взаимодействия с базами данных не будешь пользоваться SQL? Для описания веб-интерфейсов не будешь пользоваться HTML/CSS/JS?

T>Я обычно стараюсь в корпоративной среде держаться от летунов с горящими глазами подальше. Чтобы когда от очередного брызги разлетаются -- не задело. Выглядят они... противоречиво.

И слава богу! Держись от нас подальше, а то ведь брызги пока только от тебя.

T>Хотя бы потому, что найти команду из десяти человек, знающих один и тот же язык (особенно если это язык C) -- легко. А вот найти, знающих три...

Не знают хотя бы три языка, берите их сразу себе

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

T>Относительно каждой строчки стандарта C99

C must die.

T>сравнение с другими языками (в первую очередь C++)

C++ тоже.

C# sucks.

Nemerle rocks!

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

VD>Орлы! Для сравнения двух языков нужно определить функцию сравнения (по какому критерию сравнивать). Скажем если взять в качестве критерия возможности создания максимально эффективного кода, то Лисп окажется в пролете. И только упрямый лисповед будет об этом спорить.

Определять критерии сравнения это хорошо и правильно, это инженерный подход, а не та метафорическая лирика, что тут развели.
Кстати, справедливости ради, компиляторы Common Lisp'а генерят очень эффективный нативный код.

VD>Критериев ведь масса. Скажем простота изучения средним человеком. Тут у лиспа тоже нет шансов. Именно по тому С завоевал мир, а Лисп остался уделом гиков.

Да, но Си завоевал не весь мир, а мир системного низкоуровневого программирования. Это же не весь мир? То что, он занял эту нишу хорошо, плохо то, что топикстартер нашел в нем silver bullet. Да и связать простоту изучения с завоеванием мира сложно. Ведь C++ не прост, ни капельки и тоже можно сказать завоевал мир. Тут скорее другие факторы сыграли свою роль.

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

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

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

HH>>Я не собираюсь доказывать, что Lisp или Haskell лучше чем C.

VD>Орлы! Для сравнения двух языков нужно определить функцию сравнения (по какому критерию сравнивать). Скажем если взять в качестве критерия возможности создания максимально эффективного кода, то Лисп окажется в пролете. И только упрямый лисповед будет об этом спорить.

"Упрямый лисповед" будет спорить о другом — о том, какая доля задач реально требует гонки за "максимально эффективным кодом" в ущерб другим качествам, как та же возможность метапрограммирования. Слишком многие путают эти две цели.

VD>Если же взять метапрограммирование или поддержку ФП, то у С не будет шансов.

VD>Критериев ведь масса. Скажем простота изучения средним человеком. Тут у лиспа тоже нет шансов. Именно по тому С завоевал мир, а Лисп остался уделом гиков.

Простота обучения тут ни при чём (она, BTW, для Лиспа выше, если сравнивать изучение с нуля, не обладая никакими знаниями по программированию).
LISP "остался уделом гиков" потому, что его задачи дальше от тех целей, которые нужны "среднему человеку" из мира мелкой писюшатины. Поколение, которое выросло на том, что для любой задачи нужно знать свойства местной аппаратуры, дёргать за вызовы MS-DOS и BIOS (а то и напрямую к железу), не только требует для этого языки, в которых это возможно предельно естественным образом (как C или писюковые диалекты Паскаля), но и создаёт поле искажения реальности, самой плотностью использования процедурных средств навязывая представление, что есть только они.
Новых генераторов этого поля искажения нет уже лет 10, и поэтому мы наблюдаем рост использования ФЯ — люди наконец-то начали замечать, что факторы, которые стимулируют использовать C, уже для них неактуальны.

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

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

N>>А по поводу истории и обоснований языка — позвольте-ка задать пару встречных вопросов. Вот как Вы считаете (после чтения книги) — какой частью тела вообще думал тот, кто вводил функции типа strncat(), и тот, кто сохраняет их в современном стандарте даже без пометки "deprecated, don't use"?
T>В ней сделали restrict на параметры, начиная с C99, поскольку основные и неочевидные проблемы были в тех случаях когда параметры могли пересекаться.

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

T>P.S. Я не наезжал на Фортран, я высказал своё личное мнение относительно причин его падения. Если вы считаете что это ещё не труп и относитесь к числу тех энтузиастов которые хотят снова поставить это на ноги -- ну что же, достойная уважения позиция.

Не нужен тут никакой особый энтузиазм, у него в HPC достойная ниша и из которой его тяжело выбить современными средствами. По современным меркам, Фортран — это в первую очередь вычислительный DSL, а любой DSL хорош тем, что решения в его терминах, соответствующие задаче, лучше оптимизируются. Оптимизировать под вычислительные задачи (а особенно под параллельность) код, написанный на Си или аналоге, сложнее хотя бы из-за указателей, которые тут нафиг не сдались для задачи и только сбивают компилятор с толку. В результате мы имеем то, что там, где фортрановскому компилятору надо в лучшем случае дать подсказку, сишному приходится явно писать метод (например, через директивы OpenMP). Но за пределами собственно вычислений тоже есть что делать, и у современного Фортрана достаточно средств даже для представления задачи в парадигме ООП (используется в основном для связи с внешними средствами).

Но, с другой стороны, C — такой же DSL, только под другую задачу (переносимый ассемблер).

T> Не вижу причин устраивать на эту тему холивар. С моей точки зрения -- птичка сдохла.

То, что Вы не видите дальше своего носа (своих узких задач), не значит, что других задач нет и средств для них нет. Естественно, про C знает, по крайней мере в поколении, выросшем в 90-е годы, каждый, потому что тогда это было основное средство практически для всего. Но это проблема одного поколения.

T> "Новый Фортран" -- это такой оксюморон, как упомянутая мыщхом свинка. И не новый и не Фортран.

Откройте глаза пошире и обернитесь вокруг себя. В мире значительно больше разного, чем кажется. И Фортран, и Лисп, и Эрланг, и много прочего.

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

T>Речь об этом, а не о C и не о его сравнении с Лиспом пусть они оба будут здоровы. Чтож всех так на холивор тянет

А кто первый начал-то? Если бы Вы просто разрекламировали книгу, то вопроса бы не было. Но Вы начали с бессмысленного наезда на другие языки вообще и особенно на LISP, и породили замечательный holy war. Теперь разбирайте последствия.

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

DM>Да чего тут спорить. Си — молодой и динамично развивающийся язык, он появился намного позже лиспа и учел опыт предшественников, исправил их ошибки. Исчезли эти тормозные и жрущие память списки и сборка мусора. Благодаря новым достижениям компиляторостроения появился синтаксис, статическая типизация. Это большие шаги вперед!

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

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

T>Перечитайте что вы написали. Вы же по сути сами и признали, что туплы не дают выгоды. С точки зрения ассемблера компилятору абсолютно пофиг раскладывать по регистрам структуру из двух интов или тупл из двух интов, что там что там два регистра. Кроме того туплы утяжеляют фронтенд и замедляют компиляцию. Ровно на разбор тупла. Кстати ещё и заставляют вводить перегруженные слова/символы в язык. И всё это -- напомню -- без очевидной выгоды. Кроме того туплы ухудшают читаемость программы. Вместо очевидного имени члена структуры обращение может вестись по индексу тупла или вообще идти итерирование по самому туплу.

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

int doWork(int *res1, xxx *res2, yyy input1, zzz input2);
...
rc = doWork(&r1, &r2, fdhksj, rgdhdjk)

мы просто пишем

rc, r1, r2 = doWork(fdhksj, rgdhdjk)

Это опробовано на куче языков (например, Python, Erlang, а из компилируемых близких к C — в Go).
А про замедление компиляции вообще смешно говорить — минимальная оптимизация по нынешним временам съедает времени в разы больше, чем весь фронтэнд, по крайней мере для C. И для C++ затраты не столь велики, там в основном съедает шаблонизация.

На уровне ассемблера это, конечно, превратится в скрытые параметры, передаваемые по ссылке; см. тот же Go.

Что за "перегруженные слова/символы", я не понял. Прошу разъяснить.

T> Итерирование кстати может быть и неявным -- там скажем по указателю на тупл. Или даже (представьте этот ужас) -- по смещённому указателю на член тупла.

Итерирование не нужно. Кортеж — это не список. Странно, что знакомый с ФЯ человек их так легко путает.

T> Кстати об итерировании. Оно не представляется естественным образом в ассемблере ни одной популярной архитектуры (почему у нас и нет итерирования по сишным структурам) поскольку в общем случае данные в тупле -- РАЗНОГО размера.

Конечно. И накойхер (фамилиё такое) Вы вообще решили там чего-то итерировать?

T> Более того -- возникают аналогичные структурам вопросы с паддингом, c эквивалентностью по типам данных, с передачей через varargs и т.п. которые в стандарте и во всех ABI существующих архитектур придётся прописывать ещё раз -- только теперь для туплов.

Они всего лишь добавятся в начало списка аргументов.

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

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

T> а также усложняют компиляторы для простых архитектур.

Компиляторы сейчас и так сложные даже для простых архитектур. Но ничто не мешает в принципе сделать эту возможность пропускаемой, если не хватает ресурсов (ой сомневаюсь, Си сейчас совсем не тривиальный для компиляции, это вам не Паскаль).

Здравствуйте, мыщъх, Вы писали:

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

Здравствуйте, мыщъх, Вы писали:

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

DM>>Да чего тут спорить. Си — молодой и динамично развивающийся язык, он появился намного позже лиспа и учел опыт предшественников, исправил их ошибки. Исчезли эти тормозные и жрущие память списки и сборка мусора. Благодаря новым достижениям компиляторостроения появился синтаксис, статическая типизация. Это большие шаги вперед!

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

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

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

0>Здравствуйте, мыщъх, Вы писали:

М>>статическая типизация она не от большого ума, а от нищеты хардвера.
0>Можешь развить эту свою мысль?
а ее надо развивать?