Решение проблемы двух ботинок
От: Tilir Россия http://tilir.livejournal.com
Дата: 23.12.11 09:16
Оценка: 149 (15) +5 -3 :))) :))
Hi,

Перечитываю сейчас прекрасный, прекрасный построчный комментарий к стандарту языка C ("The New C Standard -- An Economical and Cultural Commentary" by Derek M. Jones, свежую версию всегда можно выкачать бесплатно здесь).

Совершенно гениальная фраза из введения:

"Proposals to use other languages sometimes have more obvious flaws in their arguments. An analysis of why Lisp should be used [398] is based on how that language overcomes some of the C-inherent problems, while overlooking its own more substantial weaknesses (rather like proposing that people hop on one leg as a solution to wearing out two shoes by walking on two)"

Близкий к тексту перевод (в квадратных скобках -- мои комментарии):

"Предложения использовать иные [кроме C] языки часто имеет существенные изъяны в своей аргументации. Как пример -- анализ преимуществ языка Lisp приведённый в [ссылка на статью какого-то лисповеда из Беркли] основан на том как средcтва этого языка позволяют преодолевать проблемы, присущие C, но при этом опускаются его [языка Lisp] гораздо более существенные недостатки (примерно как если бы кто-то предлагал людям прыгать на одной ноге как средство избежать необходимости носить два ботинка, когда ходишь на двух)"

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

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

---
With best regards, Konstantin
Re: Решение проблемы двух ботинок
От: D. Mon Великобритания http://thedeemon.livejournal.com
Дата: 24.12.11 07:27
Оценка: 41 (3) :))) :))) :)))
Да чего тут спорить. Си — молодой и динамично развивающийся язык, он появился намного позже лиспа и учел опыт предшественников, исправил их ошибки. Исчезли эти тормозные и жрущие память списки и сборка мусора. Благодаря новым достижениям компиляторостроения появился синтаксис, статическая типизация. Это большие шаги вперед!
Re[3]: Аллегория совершенно дурацкая
От: Qbit86 Кипр
Дата: 23.12.11 18:07
Оценка: 93 (1) :))) :))) :)))
Здравствуйте, Ведмедь, Вы писали:

В>И аллегория совершщенно дурацкая — В этом смысле можно сказать, что С в случае с одним ботинком предлагает выкинуть все ботинки и скакать без ботинок.


Неудачная метафора подобна лягушке с форточкой.
Глаза у меня добрые, но рубашка — смирительная!
Re[2]: Решение проблемы двух ботинок
От: мыщъх США http://nezumi-lab.org
Дата: 24.12.11 08:29
Оценка: -7 :)))
Здравствуйте, D. Mon, Вы писали:

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


статическая типизация она не от большого ума, а от нищеты хардвера.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Re[2]: Решение проблемы двух ботинок
От: Tilir Россия http://tilir.livejournal.com
Дата: 24.12.11 02:09
Оценка: +4 :))
Здравствуйте, __lambda__, Вы писали:

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


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

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

P.S. Цитата ваша -- из той же серии -- саблю в зубы и поскакали с присвистом. Ну где вы возьмёте такую архитектуру, чтобы на неё не лёг язык C и чтобы таких компов в мире было больше десятка? А если не возьмёте -- то и зачем вам оно?
Re[5]: Решение проблемы двух ботинок
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 24.12.11 09:54
Оценка: +6
Здравствуйте, мыщъх, Вы писали:

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

М>а что вам мешает? берем жабу скрипт. в нем какая типизация? уж точно не статическая. между тем, создать... эээ.... "переменную" (в вашей терминологии) в которой могло бы быть только целое число проще простого. при вызове "foo = 3.3" вызвается опеределенная нами функция, которая смотрит на число, видит, что оно не целое и обрабатывает ситуацию по тому или иному сценарию.

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

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


Кайф в том, что мы гарантируем определённые свойства присвоенного значения и избавляемся от проблем, которые могли бы быть в случае какого-то другого значения. Целое — это не панацея, но базовый кирпич. В конкретном случае это может быть просто целое (если облом уточнять), целое из интервала от 0 до 999, целое из интервала от -45 до +55, целое из набора -38 и 97 (и никаких других) и так далее. Наконец, целое — это предельно простое и понятное минимально образованному системному программисту отображение используемого железом набора битовых значений. Да, можно согласиться, что всё это от бедности, но в пределах этой бедности интерпретировать значения слов, например, как float — заведомо менее удобно людям, чем как int. А если требовать от значений соответствия типу, у которого установлено множество и/или интервал значений, получится просто и внятно.

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


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

М>кстати, в си очень интересно определен тип индекс. который размер. то есть он индекс, но он размер. вот так. впрочем, это никого не парит, ибо им большинство все равно не пользуются, а потом переносят программу с 32 бит на 64 с матами. всякий раз когда вижу int вместо индекса -- меня реально коробит.


Тут вопрос не в размерности индекса как таковой, а в неявных конверсиях с потенциальной потерей значения. Потому в более современных языках это стараются ограничить. Вообще, такие неявные конверсии, или молчаливое целочисленное переполнение — адская проблема Си, и то, что нельзя сделать хотя бы что-то вроде шарпового checked(a+b), ужасно. А книга и автор треда считают, видимо, эту проблему несущественной? (В соответствующей главе только банальный трёп про неявные конверсии с расширением.)

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

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

Опять странное говорите. Библиотеке должен соответствовать хедер. Если его нет, то вообще компилировать нельзя. Если он есть, но не той версии, это должен контролировать пакетизатор. А что, если для того же имени в библиотеке изменится состав аргументов (что на практике значительно чаще, чем смена типа результата)?

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


В таком случае начните с того, что и динамическая память там якобы чужак — как же, могут неожиданно сделать free() на используемую область. В чём разница?
The God is real, unless declared integer.
Re[5]: Решение проблемы двух ботинок
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 24.12.11 07:32
Оценка: 10 (3) +2
Здравствуйте, VladD2, Вы писали:

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


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


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


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

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


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


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

Вообще эти два языка можно нормально рассматривать только в качестве двух слоёв одного бутерброда, а если спорить, то о том, на какой миллиметр-два сдвинуть границу между их применениями в конкретном случае.
The God is real, unless declared integer.
Re[6]: Решение проблемы двух ботинок
От: мыщъх США http://nezumi-lab.org
Дата: 23.12.11 20:27
Оценка: 6 (3) +1 :)
Здравствуйте, Tilir, Вы писали:

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


М>>при всей моей любви к си я не могу удержаться от вопросов:

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

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

T>эту нишу занимал basic. Тоже можно было писать с первых минут и была сразу куча сахара.
хотите сказать, что выучить фортран было сильно сложнее чем си? покажите мне монументальный faq по фортрану где на 100 страницах обсуждается, что внутренее представлене нулевого указателя никого не парит, и что *0 это никакой не нуль и на некоторых экзотических платформах программа может сломаться если функции передать 0, а не *0. а может и не сломаться, если компилятор поймет, что 0 это указатель.

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

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

#include <stdio.h>
int main() {
  int x[5];
  printf("%p\n", x);
  printf("%p\n", x+1);
  printf("%p\n", &x);
  printf("%p\n", &x+1);
  return 0;
}


так что про простоту си не надо. чтобы писать промышленную программу на фортране большого опыта не надо, чего не скажешь о си.


T>Компилятор может быть маленьким не означает что он будет маленьким.

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

T>Вы лучше удивитесь как сквозь все эти годы была пронесена изящная

T>рациональная простота и адекватность языка C. Я считаю это просто чудом.
кто же с этим спорит? си до сих пор мой основной язык. и мои коллеги тоже пишут на си (без плюсов). как раз по поводу плюсов у нашего тима однозначное мнение -- на фига нам это морская свинка, которая и не свинка, и не морская.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Re: Решение проблемы двух ботинок
От: HrorH  
Дата: 23.12.11 11:16
Оценка: +1 :))) :)
Здравствуйте, Tilir, Вы писали:

T>"Предложения использовать иные [кроме C] языки часто имеет существенные изъяны в своей аргументации. Как пример -- анализ преимуществ языка Lisp приведённый в [ссылка на статью какого-то лисповеда из Беркли] основан на том как средcтва этого языка позволяют преодолевать проблемы, присущие C, но при этом опускаются его [языка Lisp] гораздо более существенные недостатки (примерно как если бы кто-то предлагал людям прыгать на одной ноге как средство избежать необходимости носить два ботинка, когда ходишь на двух)"


Ничем не доказанное утверждение.
Язык Lisp и его более современные диалекты намного мощнее C/C++, просто сравнивать смешно.
Язык C имеет свою отдельную низкоуровневую нишу.
Допустим книга замечательная, никто не спорит, но зачем же говорить о том, что язык C венец творения, когда это, мягко говоря, не так.
Re: Решение проблемы двух ботинок
От: __lambda__ Россия http://zen-hacker.blogspot.com/
Дата: 23.12.11 22:45
Оценка: +5
Здравствуйте, 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.

Computer science is no more about computers than astronomy is about telescopes (c) Edsger Dijkstra
Re[4]: Решение проблемы двух ботинок
От: мыщъх США http://nezumi-lab.org
Дата: 24.12.11 09:12
Оценка: -3 :))
Здравствуйте, netch80, Вы писали:

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


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


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

а что вам мешает? берем жабу скрипт. в нем какая типизация? уж точно не статическая. между тем, создать... эээ.... "переменную" (в вашей терминологии) в которой могло бы быть только целое число проще простого. при вызове "foo = 3.3" вызвается опеределенная нами функция, которая смотрит на число, видит, что оно не целое и обрабатывает ситуацию по тому или иному сценарию.

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

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

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

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

динамические библиотеки в языках со статической типизацией выглядят чужаками.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Re: Решение проблемы двух ботинок
От: IT Россия linq2db.com
Дата: 24.12.11 06:08
Оценка: -2 :))
Здравствуйте, Tilir, Вы писали:

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


C must die.

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


C++ тоже.

C# sucks.

Nemerle rocks!
Если нам не помогут, то мы тоже никого не пощадим.
Re[4]: Решение проблемы двух ботинок
От: batu Украина  
Дата: 24.12.11 14:32
Оценка: +1 -2 :)
Здравствуйте, boot, Вы писали:

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


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


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

Видно что у вас с философией не очень. Измерить можно только счетное число. В этом и есть великая загадка диагонали квадрата. Ее невозможно представить числом.
Re[5]: Решение проблемы двух ботинок
От: HrorH  
Дата: 23.12.11 12:04
Оценка: +1 -2
Здравствуйте, alpha21264, Вы писали:

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


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


A>>>В процитированном тексте вроде не называют С++ венцом творения.

A>>>И вообще, учись читать.

HH>>С этого места поподробнее.


A>Если человек не умеет читать, то "поподробнее" бесполезно — он все равно не прочтет.

A>В статье ничего не говорится про С++ как венец творения. Ты это как-то вычитал и обвинил автора.
A>Что тебе подробнее? Куда подробнее? Что тут дробить? Это ОДИН БИТ ИНФОРМАЦИИ!!! Он не дробится.

Автор топика цитирует высказывание о том, что часто сравнения языка C с другими языками не состоятельны. И приводит в качестве примера Lisp.
Из этого можно сделать вывод, что он считает C мощнее Lisp-a.
Да, он не говорит, что C венец творения, но с такой аргументацией, которую он использует, это можно сказать о любом языке. Ведь аргументация нулевая.
Также я не цитировал его фразу как то, что C++ венец творения. Это Вы уже неправильно цитируете меня.
То есть если я и не умею читать, то Вы тоже.
Далее Вы пишите:
И вообще, учись читать.
К чему относится это "и вообще", если, как Вы говорите, там один бит информации?
Как видите, я по крайней мере иногда пытаюсь читать внимательно.
И последнее. Холиварить дело хорошее, но надо держать себя в руках.
Re[2]: Решение проблемы двух ботинок
От: Tilir Россия http://tilir.livejournal.com
Дата: 23.12.11 20:00
Оценка: +3
Здравствуйте, мыщъх, Вы писали:

М>извините, но эта фраза вообще ни о чем. о какой проблеме ботинок идет речь?


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

Речь об этом, а не о C и не о его сравнении с Лиспом пусть они оба будут здоровы. Чтож всех так на холивор тянет
Re[4]: Решение проблемы двух ботинок
От: Tilir Россия http://tilir.livejournal.com
Дата: 24.12.11 01:34
Оценка: :)))
Здравствуйте, мыщъх, Вы писали:

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


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


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


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

Короче самое место туплу -- в C++, где обкатываются и отрабатываются все спорные идеи (туда же ссылки, шаблоны и т.п.). Ну собственно его туда и добавили, люди работают
Re[8]: Решение проблемы двух ботинок
От: batu Украина  
Дата: 25.12.11 17:30
Оценка: -1 :))
Здравствуйте, DarkGray, Вы писали:


DG>>>представить нельзя, но можно измерить с заданной точностью в виде двух граней

B>>Я думаю разницу вы понимаете.

DG>в реальных задачах такой измеримости хватает

А я и не спорю. В реальной жизни вообще бесконечность ни к чему. Но любопытно. Ведь любое что-то состоит из чего-то.. Ну, атомов, допустим. Их можно посчитать по сторонам квадрата. Разрезаем квадрат по диагонали и там же должно быть целое число этих что назвали атомами.. А оно отнюдь! Разве не любопытно?
Re[4]: Решение проблемы двух ботинок
От: Tilir Россия http://tilir.livejournal.com
Дата: 23.12.11 12:53
Оценка: 62 (1) +1
Здравствуйте, HrorH, Вы писали:

HH>Т.е Вы правда считаете, что C это венец творения?

HH>Я не собираюсь доказывать, что Lisp или Haskell лучше чем C.
HH>Если Вы в этом сомневаетесь, то значит просто не знаете эти языки.
HH>Если нужна информация по Haskell, могу дать ссылки.
HH>Что касается промышленного применения, то "более массовое" никогда не означало "лучшее".

Вы будете удивлены но я не просто знаю Haskell, я часто его использую. Там где он мне нужен, разумеется. Мало того -- у меня даже есть статья по Haskell в журнале RSDN, загляните в профиль. Внимательно перечитайте исходное сообщение -- там ничего не возносится и ничего не принижается. Постарайтесь вникнуть и понять о чём идёт речь. В индустрии есть объективные проблемы -- скажем работа с памятью это всегда проблема, а делать это хоть сколько-нибудь кроссплатформенно это уже ПРОБЛЕМА. Но эти проблемы сравнимы с проблемами подбора верной обуви, чтобы не ходить босым и не ранить ноги. Можно рассмотреть их серьёзно и конструктивно (см. "Memory as a Programming Concept in C and C++" by Frantisek Franek, Cambridge University Press, 2004) а можно сказать "не надо управлять памятью вообще, на нашей новой платформе вы сможете ходить не касаясь земли а значит и обувь вам будет не нужна" (то что ходить можно будет только по этой платформе а платформа -- два на полтора метра -- в обзоре упускается). И т.п.
Re[3]: Решение проблемы двух ботинок
От: Tilir Россия http://tilir.livejournal.com
Дата: 23.12.11 19:02
Оценка: 53 (2)
Здравствуйте, Ведмедь, Вы писали:

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


Как точный ответ на ваш вопрос я процитирую вступление к фундаментальному труду "Программирование на языке C" Кернигана и Ричи. Читайте:

...
В языке "C" отсутствуют операции, имеющие дело непосредственно с составными объектами, такими как строки символов, множества, списки или с массивами, рассматриваемыми как целое. Здесь, например, нет никакого аналога операциям PL/1, оперирующим с целыми массивами и строками. Язык не предоставляет никаких других возможностей распределения памяти, кроме статического определения и механизма стеков, обеспечиваемого локальными переменных функций; здесь нет ни "куч"(HEAP), ни "сборки мусора", как это предусматривается в АЛГОЛЕ-68. Наконец, сам по себе "C" не обеспечивает никаких возможностей ввода-вывода: здесь нет операторов READ или WRITE и никаких встроенных методов доступа к файлам. Все эти механизмы высокого уровня должны обеспечиваться явно вызываемыми функциями.
Аналогично, язык "C" предлагает только простые, последовательные конструкции потоков управления: проверки, циклы, группирование и подпрограммы, но не мультипрограммирование, параллельные операции, синхронизацию или сопрограммы.
Хотя отсутствие некоторых из этих средств может выглядеть как удручающая неполноценность ("выходит, что я должен обращаться к функции, чтобы сравнить две строки символов ?!"), но удержание языка в скромных размерах дает реальные преимущества. Так как "C" относительно мал, он не требует много места для своего описания и может быть быстро выучен. Компилятор с "C" может быть простым и компактным
...


Знаете в каком году это писалось?
Re[2]: Почти оффтоп
От: Klapaucius  
Дата: 10.01.12 09:08
Оценка: 18 (1) +1
Здравствуйте, Mamut, Вы писали:

M>Ведь если посмотреть почти на все холивары типа X vs. Y, где X и Y — два произвольно взятых языка, то они все моментально скатываются в: X — лучше, потому что в Y фича A сделана плохо, а в X фича А сделана хорошо. При этом таки да, недостатки языка X старательно замалчиваются или считаются несущественными.


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

M>Смешно, что даже автор, который эту фразу нашел, и представил ее к нам сам скатился в точно такой же спор в C vs. Fortran и т.п.


Ну так эта фраза ему понравилась в той форме, что он нашел. И я сомневаюсь, что она понравилась ему, если бы она была такой:

Предложения использовать иные [кроме LISP] языки часто имеет существенные изъяны в своей аргументации. Как пример -- анализ преимуществ языка C приведённый в [ссылка на статью какого-то сиведа из Беркли] основан на том как средcтва этого языка позволяют преодолевать проблемы, присущие LISP, но при этом опускаются его [языка C] гораздо более существенные недостатки (примерно как если бы кто-то предлагал людям прыгать на одной ноге как средство избежать необходимости носить два ботинка, когда ходишь на двух)

В этом проблема такой фразы. Вот кто-то сказал "я прав, а ты ошибаешься" — и ему очень фраза понравилась. И тут ему отвечает кто-то другой: "я прав, а ты ошибаешься" — и та же самая фраза уже не кажется первому такой хорошей.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[2]: Решение проблемы двух ботинок
От: Ведмедь Россия  
Дата: 23.12.11 14:32
Оценка: 3 (1) +1
Здравствуйте, DarkGray, Вы писали:


T>>"Предложения использовать иные [кроме C] языки часто имеет существенные изъяны в своей аргументации. Как пример -- анализ преимуществ языка Lisp приведённый в [ссылка на статью какого-то лисповеда из Беркли] основан на том как средcтва этого языка позволяют преодолевать проблемы, присущие C, но при этом опускаются его [языка Lisp] гораздо более существенные недостатки (примерно как если бы кто-то предлагал людям прыгать на одной ноге как средство избежать необходимости носить два ботинка, когда ходишь на двух)"


DG>так автор сам-то говорит, чем язык C хуже Лисп?

DG>или он других упрекает за то, что когда они говорят о своем языке, то хвалят только свой язык; а при этом сам же говоря о своем языке, хвалит только свой язык?

В общем тоже читаю и не понимаю в чем смысл топика? В том что когда хвалят лисп, то умалчивают его недостатки? А что авторы, пишушие положительные статьи по С выставляют напоказ его недостатки? И аллегория совершщенно дурацкая — В этом смысле можно сказать, что С в случае с одним ботинком предлагает выкинуть все ботинки и скакать без ботинок.
Да пребудет с тобой Великий Джа
Re[2]: Решение проблемы двух ботинок
От: alpha21264 СССР  
Дата: 23.12.11 11:32
Оценка: :))
Здравствуйте, HrorH, Вы писали:

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


T>>"Предложения использовать иные [кроме C] языки часто имеет существенные изъяны в своей аргументации. Как пример -- анализ преимуществ языка Lisp приведённый в [ссылка на статью какого-то лисповеда из Беркли] основан на том как средcтва этого языка позволяют преодолевать проблемы, присущие C, но при этом опускаются его [языка Lisp] гораздо более существенные недостатки (примерно как если бы кто-то предлагал людям прыгать на одной ноге как средство избежать необходимости носить два ботинка, когда ходишь на двух)"


HH>Ничем не доказанное утверждение.

HH>Язык Lisp и его более современные диалекты намного мощнее C/C++, просто сравнивать смешно.
HH>Язык C имеет свою отдельную низкоуровневую нишу.
HH>Допустим книга замечательная, никто не спорит, но зачем же говорить о том, что язык C венец творения, когда это, мягко говоря, не так.

В процитированном тексте вроде не называют С++ венцом творения.
И вообще, учись читать.

PS. Как бы мне на Лиспе что-нибудь написать. Если знаешь, кинь ссылку.

Течёт вода Кубань-реки куда велят большевики.
Re[4]: Решение проблемы двух ботинок
От: alpha21264 СССР  
Дата: 23.12.11 11:51
Оценка: :))
Здравствуйте, HrorH, Вы писали:

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


A>>В процитированном тексте вроде не называют С++ венцом творения.

A>>И вообще, учись читать.

HH>С этого места поподробнее.


Если человек не умеет читать, то "поподробнее" бесполезно — он все равно не прочтет.
В статье ничего не говорится про С++ как венец творения. Ты это как-то вычитал и обвинил автора.
Что тебе подробнее? Куда подробнее? Что тут дробить? Это ОДИН БИТ ИНФОРМАЦИИ!!! Он не дробится.

Течёт вода Кубань-реки куда велят большевики.
Re[3]: Решение проблемы двух ботинок
От: мыщъх США http://nezumi-lab.org
Дата: 23.12.11 21:31
Оценка: +2
Здравствуйте, Tilir, Вы писали:

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


М>>извините, но эта фраза вообще ни о чем. о какой проблеме ботинок идет речь?

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

> Получаете скорость разработки -- платите объёмом кода, получаете высокоуровневые примтивы

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

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

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

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


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

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

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

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

"объективно" сравнивать достоинства и недостаки языков нельзя. например, и для самолетов, и для автомобилей категория "аэродинамика" очень важна. для грузовиков она уже сомнительна, а к тракторам и комбайнам -- не применима в принципе. и у трактора с автомобилем настолько мало общего, что их сравнивать вообще неуместно. так почему же мы сравниваем си с лиспом, но не сравниваем танк с крейсером?
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Re[2]: Решение проблемы двух ботинок
От: batu Украина  
Дата: 23.12.11 21:53
Оценка: +1 :)
Здравствуйте, boot, Вы писали:

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


T>>...


B>Добавлю только, что совершенный язык, это тот, в котором меньше слов, а сказать можно больше. Наличие 2-х пунктов сравнения, значительно затрудняет задачу поиска совершенного языка. То ли найти клопа на веревке для белья, а то ли на всем полу...

С количеством слов не согласен. Теоретически все можно обозначить знаками.. Но разиьаться в этой мешанине знаков будет совсем не просто. Это типа каста организуется. Важнее минимизация правил языка и базовых понятий. А уже из сколько понятий (они же слова) можно из них определить вопрос сорок пятый. Кстати, если не ограничивать длину слова, то вообще континуум получается. Частенько встречаю что количество фраз языка счетно. Это не правильно.
Re[6]: Решение проблемы двух ботинок
От: мыщъх США http://nezumi-lab.org
Дата: 24.12.11 09:42
Оценка: -1 :)
Здравствуйте, Курилка, Вы писали:

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


К>Может не стоит приводить в пример язык со статической, но слабой типизацией?

хорошо, давайте возьмем другой язык. и api операционной системы. в какой операционной системе типы явно закодированы в библиотеках? язык может требовать принудительной декларации и си++ ее действительно требует. вот только функции mydll!foo() плевать как ее задекларировали. она вернет то, что захочет.

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

в динамических средах (коими являются современные оси) статика выглядит пережитком старины.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Re[5]: Решение проблемы двух ботинок
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 25.12.11 08:43
Оценка: +2
Здравствуйте, batu, Вы писали:

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

B>Видно что у вас с философией не очень.

А у Вас — полный швах с математикой.

B> Измерить можно только счетное число. В этом и есть великая загадка диагонали квадрата.


А также посконная и кондовая. (c)
Понятия "счётное число" не существует. Не знаю, откуда Вы его выкопали и что имели в виду. Рациональное? С точки зрения математики, квадратный корень из 2 — настолько же полноправное число, как и просто 2, и число Пи, и мнимая единица; и невозможность представить конечным количеством цифр или в виде дроби не мешает этому.

B> Ее невозможно представить числом.


В каком там классе учат иррациональные числа? 8, 9? В общем, рекомендую повторить изучение алгебры и геометрии за эти классы.
The God is real, unless declared integer.
Re[3]: Решение проблемы двух ботинок
От: FragMent  
Дата: 23.12.11 12:14
Оценка: 8 (1)
Здравствуйте, Tilir, Вы писали:

T>Покажите мне хоть один (опубликованный в реферабельном журнале) позитивный обзор языка Lisp (CLOS, Haskell, Miranda, Nemerle) в сравнении с C, где его (Lisp и т.д.) объективные недостатки (а любой из них объективно настолько менее распространён в промышленном программировании, чем C, что как вы выразились "даже сравнивать смешно" -- это же не случайно) были бы... хм... ну хоть упомянуты что ли?


Не совсем подходит под критерии, но вот статья от уважаемого человека
http://www.softcraft.ru/paradigm/fp/whynotfp.shtml
Re[7]: Решение проблемы двух ботинок
От: FR  
Дата: 25.12.11 06:51
Оценка: 1 (1)
Здравствуйте, мыщъх, Вы писали:

T>>Компилятор может быть маленьким не означает что он будет маленьким.

М>"может быть маленьким" -- очень сомнительное достоинство языка, если таких компиляторов нет.

http://bellard.org/tcc/
Re[8]: Решение проблемы двух ботинок
От: Undying Россия  
Дата: 14.01.12 13:38
Оценка: 1 (1)
Здравствуйте, DarkGray, Вы писали:

DG>1. Должны ли сущности записи совпадать с сущностями логики решения?


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

DG>2. Должны ли сущности исполнения совпадать с сущностями логики решения?


Нужно для удобства отладки.

DG>3. Что такое вес логической сущности? И как его можно измерить или вычислить?


Если подумать, то вовсе не факт, что вес имеет смысл учитывать. Т.к. если смотреть в корень проблемы, то возможно важны как раз штуки, а не веса. Например, почему очень дороги сеттеры? Потому что при традиционном методе программирования информация в программе дублируется множество раз. Возьмем самый примитивный пример. Есть бизнес-объект, его нужно показать пользователю. Мы берем переменную этого объекта и копируем ее, к примеру, в textBox. Т.е. на ровном месте получаем дублирование информации. Соответственно дальше изменение состояние бизнес-объекта (сеттер) должно порождать множество изменений (сеттеров) объектов от него зависящих. А т.к. отслеживание зависимостей это не тривиальная задача, то сложность программы растет лавинообразно, и возникает впечатление, что ничего страшнее сеттеров нет. Хотя на самом деле корень проблемы не в сеттерах, а в дублировании состояния.

Если же мы с помощью автоматических кэшей и LazyMaker'ов (тот же автоматический кэш, но не пересчитывающий результат, а выполняющий определенное действие при изменении входов) от дублирования состояния избавляемся, то сеттеры становятся ничуть не дороже геттеров. Например, если в предыдущем примере, мы textBox опишем в виде LazyMaker'а зависящего от переменной бизнес-объекта и вызов этого LazyMaker'а поместим в onPaint формы, то после изменения состояния объекта нам будет достаточно принудительно перерисовать форму (или мир в общем случае), чтобы гарантировать корректное состояние. Соответственно изменение состояния становится тривиальной операцией, не вносящей дополнительной сложности.

DG>4. Можно ли выделить какие-то базовые сущности? Что это за сущности?


По привычке я считал, что главное зло это сеттеры и лишние слои абстракции. Но в свете предыдущего пункта сеттеры оказались реабилитированными, а истинным виновником проблемы оказалось дублирование состояния. По поводу лишних слоев абстракции надо подумать, возможно они тоже плохи не сами по себе, а из-за того что нарушают нечто более фундаментальное. Так вроде да, получается, что и лишние слои абстракций плохи тем, что на ровном создают лишнее состояние с неизбежным дублированием состояния логического. Т.е. похоже, что от принципа минимума состояния и нужно плясать.
Re[2]: Решение проблемы двух ботинок
От: Tilir Россия http://tilir.livejournal.com
Дата: 23.12.11 11:57
Оценка: :)
Здравствуйте, HrorH, Вы писали:

T>>"Предложения использовать иные [кроме C] языки часто имеет существенные изъяны в своей аргументации. Как пример -- анализ преимуществ языка Lisp приведённый в [ссылка на статью какого-то лисповеда из Беркли] основан на том как средcтва этого языка позволяют преодолевать проблемы, присущие C, но при этом опускаются его [языка Lisp] гораздо более существенные недостатки (примерно как если бы кто-то предлагал людям прыгать на одной ноге как средство избежать необходимости носить два ботинка, когда ходишь на двух)"


HH>Ничем не доказанное утверждение.


Утверждение о чём? Автор вообще очень аккуратно отозвался ровно об одной статье "[398] R. J. Fateman. Software fault prevention by language choice: Why C is not my favorite language. University of California at Berkeley, 1999" так что автора сложно упрекнуть anyway.

Но давайте для эксперимента обобщим это утверждение о недостатке объективности в аргументации с одного обзора на большинство.

Покажите мне хоть один (опубликованный в реферабельном журнале) позитивный обзор языка Lisp (CLOS, Haskell, Miranda, Nemerle) в сравнении с C, где его (Lisp и т.д.) объективные недостатки (а любой из них объективно настолько менее распространён в промышленном программировании, чем C, что как вы выразились "даже сравнивать смешно" -- это же не случайно) были бы... хм... ну хоть упомянуты что ли?
Re[3]: Решение проблемы двух ботинок
От: HrorH  
Дата: 23.12.11 12:39
Оценка: +1
Здравствуйте, Tilir, Вы писали:

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


T>>>"Предложения использовать иные [кроме C] языки часто имеет существенные изъяны в своей аргументации. Как пример -- анализ преимуществ языка Lisp приведённый в [ссылка на статью какого-то лисповеда из Беркли] основан на том как средcтва этого языка позволяют преодолевать проблемы, присущие C, но при этом опускаются его [языка Lisp] гораздо более существенные недостатки (примерно как если бы кто-то предлагал людям прыгать на одной ноге как средство избежать необходимости носить два ботинка, когда ходишь на двух)"


HH>>Ничем не доказанное утверждение.


T>Утверждение о чём?


Смотрите. Говорится о том, что в статье опускаются более существенные недостатки языка Lisp, чем те недостатки языка C, которые упоминаются в статье.
Здесь неявно утверждается, что такие недостатки в языке Lisp есть.
Но во-первых, не говорится, какие конкретно недостатки.
Во-вторых, это неявное утверждение не доказывается.
Re: Решение проблемы двух ботинок
От: boot  
Дата: 23.12.11 12:45
Оценка: -1
Здравствуйте, Tilir, Вы писали:

T>...


Добавлю только, что совершенный язык, это тот, в котором меньше слов, а сказать можно больше. Наличие 2-х пунктов сравнения, значительно затрудняет задачу поиска совершенного языка. То ли найти клопа на веревке для белья, а то ли на всем полу...
Жизнеспособность прямо пропорциональна простоте!
Re[5]: Решение проблемы двух ботинок
От: HrorH  
Дата: 23.12.11 13:03
Оценка: :)
Здравствуйте, Tilir, Вы писали:


T>Вы будете удивлены но я не просто знаю Haskell, я часто его использую. Там где он мне нужен, разумеется. Мало того -- у меня даже есть статья по Haskell в журнале RSDN, загляните в профиль. Внимательно перечитайте исходное сообщение -- там ничего не возносится и ничего не принижается. Постарайтесь вникнуть и понять о чём идёт речь. В индустрии есть объективные проблемы -- скажем работа с памятью это всегда проблема, а делать это хоть сколько-нибудь кроссплатформенно это уже ПРОБЛЕМА. Но эти проблемы сравнимы с проблемами подбора верной обуви, чтобы не ходить босым и не ранить ноги. Можно рассмотреть их серьёзно и конструктивно (см. "Memory as a Programming Concept in C and C++" by Frantisek Franek, Cambridge University Press, 2004) а можно сказать "не надо управлять памятью вообще, на нашей новой платформе вы сможете ходить не касаясь земли а значит и обувь вам будет не нужна" (то что ходить можно будет только по этой платформе а платформа -- два на полтора метра -- в обзоре упускается). И т.п.


Если Вы прочитаете мои ответы, то поймете, что я хоть и не сразу, но вроде вник в Ваше сообщение.
Теперь я предлагаю Вам вникнуть самому в мои ответы.
По поводу Haskell. Если Вы знаете его, не смейтесь, лучше помогите.
Не могли бы Вы объяснить, как использовать type class Traversable на каком-нибудь доступном примере?
Или Вы используете вместо него что-то другое?
Re[6]: Решение проблемы двух ботинок
От: Tilir Россия http://tilir.livejournal.com
Дата: 23.12.11 18:42
Оценка: +1
Здравствуйте, HrorH, Вы писали:

HH>По поводу Haskell. Если Вы знаете его, не смейтесь, лучше помогите.

HH>Не могли бы Вы объяснить, как использовать type class Traversable на каком-нибудь доступном примере?
HH>Или Вы используете вместо него что-то другое?

Если у вас есть конкретная проблема c Traversal, задайте вопрос в "Декларативном программировании", вам помогут. Если же хочется узнать "как чего вообще", то есть замечательная публикация Гиббонса с примерами и доступным объяснением.
Re[7]: Решение проблемы двух ботинок
От: Tilir Россия http://tilir.livejournal.com
Дата: 23.12.11 21:16
Оценка: :)
Здравствуйте, мыщъх, Вы писали:

М> хотите сказать, что выучить фортран было сильно сложнее чем си?

М>так что про простоту си не надо. чтобы писать промышленную программу на фортране большого опыта не надо, чего не скажешь о си.

Поэтому их все и пишут на фортране, наверное, да?

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

К тому же фортран не годился и не годится для системного и general-purpose программирования по понятным причинам, это числодробилка by design. Сейчас нишу фортрана занял Matlab, который уже совсем не конкурент, что и понятно -- scientific это очень специфичная область.

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


Хороший у вас тим
Re[8]: Решение проблемы двух ботинок
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 23.12.11 21:34
Оценка: +1
Здравствуйте, Tilir, Вы писали:

М>> хотите сказать, что выучить фортран было сильно сложнее чем си?

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

Видел.

T> Это как раз тот случай когда, как говорят, "простота хуже воровства". Ограничение программиста примитивными средствами -- это такое же зло как и запутывание его в дебрях возможностей.


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

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

T> Стоимость поддержки и в том и в другом случае растёт в разы.


Стоимость поддержки сишных тараканов вроде указателей — да, растёт в разы.

T>К тому же фортран не годился и не годится для системного и general-purpose программирования по понятным причинам, это числодробилка by design.


Для системного — согласен. Для общего — нет. Про числодробилку — повторяю: перестаньте думать о версиях 40-летней давности. Вообще потрясающе — про Си Вы знаете самое свежее, а чуть отойти в сторону от этого — начинаются дела давно минувших дней, времён очаковских и покоренья крыма.

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

T>Хороший у вас тим

Для их задач, видимо, совершенно адекватный.
The God is real, unless declared integer.
Re[9]: Решение проблемы двух ботинок
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 23.12.11 21:46
Оценка: :)
Здравствуйте, netch80, Вы писали:

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


T>>Скажите вы вообще в жизни ну хоть раз крупную программу на фортране -- видели?


Кстати, интересно получается: Вы утверждаете, что всего лишь рекламируете книгу, которая адекватно описывает язык Си, рассказывает исторические причины, etc. Но при этом почему-то мимоходом дважды наехали на другие языки — сначала на LISP, потом на Фортран — в очень характерной форме, которая у англоязычных братьев носит название FUD. Вот мне интересно, это намеренно или просто само собой получается?

А по поводу истории и обоснований языка — позвольте-ка задать пару встречных вопросов. Вот как Вы считаете (после чтения книги) — какой частью тела вообще думал тот, кто вводил функции типа strncat(), и тот, кто сохраняет их в современном стандарте даже без пометки "deprecated, don't use"?
The God is real, unless declared integer.
Re[10]: Решение проблемы двух ботинок
От: Tilir Россия http://tilir.livejournal.com
Дата: 23.12.11 23:16
Оценка: -1
Здравствуйте, netch80, Вы писали:

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


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

P.S. Я не наезжал на Фортран, я высказал своё личное мнение относительно причин его падения. Если вы считаете что это ещё не труп и относитесь к числу тех энтузиастов которые хотят снова поставить это на ноги -- ну что же, достойная уважения позиция. Не вижу причин устраивать на эту тему холивар. С моей точки зрения -- птичка сдохла. "Новый Фортран" -- это такой оксюморон, как упомянутая мыщхом свинка. И не новый и не Фортран.
Re[4]: Решение проблемы двух ботинок
От: VladD2 Российская Империя www.nemerle.org
Дата: 24.12.11 03:13
Оценка: +1
Здравствуйте, HrorH, Вы писали:

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


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

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

Критериев ведь масса. Скажем простота изучения средним человеком. Тут у лиспа тоже нет шансов. Именно по тому С завоевал мир, а Лисп остался уделом гиков.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Решение проблемы двух ботинок
От: __lambda__ Россия http://zen-hacker.blogspot.com/
Дата: 24.12.11 06:27
Оценка: +1
Здравствуйте, VladD2, Вы писали:

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


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

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


Да, но Си завоевал не весь мир, а мир системного низкоуровневого программирования. Это же не весь мир? То что, он занял эту нишу хорошо, плохо то, что топикстартер нашел в нем silver bullet. Да и связать простоту изучения с завоеванием мира сложно. Ведь C++ не прост, ни капельки и тоже можно сказать завоевал мир. Тут скорее другие факторы сыграли свою роль.
Computer science is no more about computers than astronomy is about telescopes (c) Edsger Dijkstra
Re[11]: Решение проблемы двух ботинок
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 24.12.11 07:57
Оценка: +1
Здравствуйте, 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> "Новый Фортран" -- это такой оксюморон, как упомянутая мыщхом свинка. И не новый и не Фортран.


Откройте глаза пошире и обернитесь вокруг себя. В мире значительно больше разного, чем кажется. И Фортран, и Лисп, и Эрланг, и много прочего.
The God is real, unless declared integer.
Re[5]: Решение проблемы двух ботинок
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 24.12.11 08:29
Оценка: +1
Здравствуйте, 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> а также усложняют компиляторы для простых архитектур.


Компиляторы сейчас и так сложные даже для простых архитектур. Но ничто не мешает в принципе сделать эту возможность пропускаемой, если не хватает ресурсов (ой сомневаюсь, Си сейчас совсем не тривиальный для компиляции, это вам не Паскаль).
The God is real, unless declared integer.
Re[3]: Решение проблемы двух ботинок
От: Ligen Украина http://zone-of-ambiguity.blogspot.com/
Дата: 24.12.11 10:14
Оценка: +1
Здравствуйте, Tilir, Вы писали:

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


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

Утверждение крайне спорное.
У нас в виндах в последнее время три это фактически необходимый минимум, например: С++, C#, SQL. Уже три. Это если поддержиывать только одну базу данных, а не три в разных билдах, что встречается достаточно часто (сегментация рынка чтоб ее)

Это если не считать недоязыки типа HTML, XML, XSLT, которые уже везде.
Если пойти дальше, выясняется, что у серьезных проектов есть еще инсталляторы: WIX или nsis (свой язык).
И им нужно как-то собираться в один клик: а это либо shell, либо Scons (python) либо cmake — свой язык с блекджеком и, ну вы поняли.
Можно также вспомнить, что в некоторых местах до сих пор бывавает assembler, сам видел. Достаточно посмотреть внутрь cryptopp, например. Или если что-то где-то хукнуть надо.

Вобщем — фигня, а не утверждение.
Viva el Junta Militar! Viva el Presidente!
Re[3]: Решение проблемы двух ботинок
От: Abyx Россия  
Дата: 24.12.11 16:02
Оценка: +1
Здравствуйте, мыщъх, Вы писали:

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


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


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


статическая типизация нужна для верификации кода на стадии компиляции.
In Zen We Trust
Re[6]: Решение проблемы двух ботинок
От: VladD2 Российская Империя www.nemerle.org
Дата: 24.12.11 18:13
Оценка: -1
Здравствуйте, __lambda__, Вы писали:

___>Кстати, справедливости ради, компиляторы Common Lisp'а генерят очень эффективный нативный код.


Скажем так. Иногда генерируют код сравнимый с эффективным. И почему речь о SBCL идет во множественном числе?

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

___>Да, но Си завоевал не весь мир, а мир системного низкоуровневого программирования.


Это сейчас так. А в 80-ых, например, он был полным мэйнстиром.

___>Это же не весь мир?


Я просто боялся, что меня обзовут Капитаном Очевидностью, если я буду к своим словам добавлять описание в стиле "обобщение" или "аллегория". Но, похоже, все же, надо.

На фоне популярности Лиспа и Висик супер-популярным языком покажется.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Решение проблемы двух ботинок
От: VladD2 Российская Империя www.nemerle.org
Дата: 24.12.11 18:32
Оценка: :)
Здравствуйте, netch80, Вы писали:

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


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

В прочем, возможно авто просто не шарит в Лиспе и от того гонит. Это кому как угодно. Один фиг из его слов никаких выводов сделать невозможно.

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


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


N>Простота обучения тут ни при чём (она, BTW, для Лиспа выше, если сравнивать изучение с нуля, не обладая никакими знаниями по программированию).


Ваще не понял сказанного.

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


Звучит не убедительно.

N>Поколение, которое выросло на том, что для любой задачи нужно знать свойства местной аппаратуры, дёргать за вызовы MS-DOS и BIOS (а то и напрямую к железу), не только требует для этого языки, в которых это возможно предельно естественным образом (как C или писюковые диалекты Паскаля),


Времена прерывания давно прошли, но ничего не изменилось.

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


С этим можно согласиться. Только все равно это не объясняет непопулярности лиспа. Дело не только в это.
В те времена были ведь не только С, С++ и Обжет Дельфи с Турбо Борландом. Были еще ХБэйс, Клипер, Кларион и т.п., т.е. языки для бизнес-задач. Там то Лисп мог стрельнуть. Но вот и там он оказался неудел.

N>Новых генераторов этого поля искажения нет уже лет 10, и поэтому мы наблюдаем рост использования ФЯ — люди наконец-то начали замечать, что факторы, которые стимулируют использовать C, уже для них неактуальны.


Ну, назвать это ростом можно только с долей иронии. Скорее можно говорить о проникновении ФП в императивные мэйнстрим-языки. Но оно тоже очень вялое. Более того есть реальное и серьезное сопротивление. Но речь не об этом.

Речь о Лиспе. И о том почему он слил такому неразвитому С.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Решение проблемы двух ботинок
От: FR  
Дата: 25.12.11 08:31
Оценка: +1
Здравствуйте, batu, Вы писали:

B>Видно что у вас с философией не очень. Измерить можно только счетное число. В этом и есть великая загадка диагонали квадрата. Ее невозможно представить числом.


Иррациональное число
Re[6]: Диагональ квадрата
От: Qbit86 Кипр
Дата: 25.12.11 08:53
Оценка: :)
Здравствуйте, netch80, Вы писали:

B>> Измерить можно только счетное число. В этом и есть великая загадка диагонали квадрата. Ее невозможно представить числом.

N>А у Вас — полный швах с математикой.

Очевидно, автор глубоко впечатлился статьёй про пифагорейцев в какой-нибудь детской математической энциклопедии. Звон-то слышал, но пересказать может только на уровне «великая загадка диагонали квадрата» и что-то невнятное про соизмеримость, счётность, etc.
Глаза у меня добрые, но рубашка — смирительная!
Re[2]: Почти оффтоп
От: Privalov  
Дата: 26.12.11 06:53
Оценка: +1
Здравствуйте, Mamut, Вы писали:

M>Смешно, что даже автор, который эту фразу нашел, и представил ее к нам сам скатился в точно такой же спор в C vs. Fortran и т.п.


Ты об этом
Автор: мыщъх
Дата: 24.12.11
?

Меня там смутило вот это заявление, imho, ничем не обоснованное.

чтобы писать промышленную программу на фортране большого опыта не надо, чего не скажешь о си.


Я тут же привел пример граблей, с которыми разработчик, не видевший Фортрана, самостоятельно с ходу не справится. Даже если будет хорошо знать указатели в С. И потом, не было никакого спора. Там уважаемый netch80 просто посмотрел, что происходит с примером, который я привел, не более того. У меня просто нет Фортрана, иначе я сам бы все сделал и ничего бы не стал спрашивать.

Лучшая, imho, работа по сравнению языков программирования — книга "Языки программирования Ада, Си, Паскаль. Сравнение и оценка/Под ред. А. Р. Фьюера, Н. Джехани". Точнее, первая статья в ней.
Re[2]: Почти оффтоп
От: HrorH  
Дата: 26.12.11 11:35
Оценка: +1
Здравствуйте, Mamut, Вы писали:


T>>Совершенно гениальная фраза из введения:


T>>"Proposals to use other languages sometimes have more obvious flaws in their arguments. An analysis of why Lisp should be used [398] is based on how that language overcomes some of the C-inherent problems, while overlooking its own more substantial weaknesses (rather like proposing that people hop on one leg as a solution to wearing out two shoes by walking on two)"


T>>Близкий к тексту перевод (в квадратных скобках -- мои комментарии):


T>>"Предложения использовать иные [кроме C] языки часто имеет существенные изъяны в своей аргументации. Как пример -- анализ преимуществ языка Lisp приведённый в [ссылка на статью какого-то лисповеда из Беркли] основан на том как средcтва этого языка позволяют преодолевать проблемы, присущие C, но при этом опускаются его [языка Lisp] гораздо более существенные недостатки (примерно как если бы кто-то предлагал людям прыгать на одной ноге как средство избежать необходимости носить два ботинка, когда ходишь на двух)"


M>Странно, что абсолюно верная фраза вызвала столько холивара


Холивар с самого начала был зря, каюсь.
Но меня удивляет другое. Почему никто не видит, что фраза эта с сюрпризом.
На первый взгляд кажется, что здесь говорится о том, что лисповед не упомянул в статье недостатки языка Лисп, и это было замечено автором книги. Все совершенно логично.
Но реально здесь сказано следующее: язык Lisp имеет более существенные недостатки, чем недостатки языка C, указанные в статье лисповеда.
Но сказано это неявно, это подрузамевается в самой констукции фразы. Это так называемая пресуппозиция.
Вообще фраза о том, что где-то чего-то нет, часто подрузамевает то, что это нечто там должно быть.
Я придрался именно к тому, что это неявное утверждение не доказывается, и даже не говорится, о каких недостатках идет речь.
Но у меня (уже позже) сложилось впечатление, что метафора так понравилась топикстартеру, что он сам не заметил тот неявный наезд, который позволил себе автор книги.
Re[6]: Решение проблемы двух ботинок
От: Mamut Швеция http://dmitriid.com
Дата: 27.12.11 18:44
Оценка: :)
M>>Для верификации очень маленького подмножества того, что код делает.

K>Зато это очень маленькое подмножество является очень благодатной почвой для ошибок.


Безусловно. Что интересно, правильно составленные тесты позволяют выловить не только этот, но и более широкий класс ошибок, одним махом.

Сразу говорю, что тесты не панацея, а то тут начнут мне пенять, чем ни попадя.

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

Пока что единственное но — нет автоматического перехода от упавшего теста к нашалившей строчке в IDE/Emacs'е и нет автоматического запуска тестов по мере написания кода. Но, думаю, это еще впереди


dmitriid.comGitHubLinkedIn
Re[3]: Решение проблемы двух ботинок
От: Klapaucius  
Дата: 10.01.12 11:49
Оценка: +1
Здравствуйте, Tilir, Вы писали:

T>Речь идёт о том что программирование это инженерная дисциплина в которой нельзя что-то получить чем-то не заплатив.


Это-то, конечно, верно. Зато вполне можно что-то заплатить и не получить за это ничего, ну или меньше, чем в принципе возможно. И не просто "можно". Из-за ранних этапов развития программирования как инженерной дисциплины такое происходит постоянно.

T>Получаете скорость разработки -- платите объёмом кода, получаете высокоуровневые примтивы -- платите быстродействием и так далее. Без вариантов. Решатель проблемы двух ботинок это человек который предлагает нечто новое и по его мнению лучшее (ага мы теперь не будем вынуждены носить два ботинка -- ну там не заботится о памяти, иметь функции как объекты первого класса, у нас будет паттерн матчинг и т.дю) -- при этом не осознавая настоящей инженерной цены этого решения (мелким шрифтом -- только прыгать придётся на одной ноге, треть времени программы у нас будет орудовать сборщик мусора, а для написания hello world -- вам придётся учить теорию категорий).


Если учесть общие темпы развития и консерватизм отрасли, сложно предположить, что такие персонажи — реальная проблема. Более реальная проблема — это персонажи, отвергающие нечто новое, по их мнению ненужное, при этом не осознавая настоящей инженерной цены этого решения.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[5]: Решение проблемы двух ботинок
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 12.01.12 11:18
Оценка: +1
DG>>как минимум очевидна чуть другая формулировка:
DG>>(при прочих равных) лучше тот язык, который позволяет записать решение меньшим кол-вом бит.

U>Лучше тот язык, который позволяет записать решение меньшим количеством сущностей. Биты здесь вообще не в тему.


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

ты сейчас о каком из них?
если минимизировать первое — то лучшим ЯП становится: машина тьюринга, там всего две сущности в алфавите: 0 и 1
если минимизировать второе — то лучшим ЯП становится: ЯП с бесконечным алфавитом, когда все программы записываются одним символом из этого алфавита.

обе крайности плохие: в первом случае, требуется неограниченное время на анализ конкретной программы, во втором случае — требуется неограниченное время на изучение алфавита.
Re[7]: Решение проблемы двух ботинок
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 13.01.12 20:09
Оценка: +1
U> Первичным является количество логических сущностей,

да, я в целом понимаю о чем ты, и я с этим согласен.

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

1. Должны ли сущности записи совпадать с сущностями логики решения?
2. Должны ли сущности исполнения совпадать с сущностями логики решения?
3. Что такое вес логической сущности? И как его можно измерить или вычислить?
4. Можно ли выделить какие-то базовые сущности? Что это за сущности?
Re[3]: Решение проблемы двух ботинок
От: HrorH  
Дата: 23.12.11 11:48
Оценка:
Здравствуйте, alpha21264, Вы писали:

A>В процитированном тексте вроде не называют С++ венцом творения.

A>И вообще, учись читать.

С этого места поподробнее.
Re[3]: Решение проблемы двух ботинок
От: HrorH  
Дата: 23.12.11 12:12
Оценка:
Здравствуйте, Tilir, Вы писали:

T>Но давайте для эксперимента обобщим это утверждение о недостатке объективности в аргументации с одного обзора на большинство.


T>Покажите мне хоть один (опубликованный в реферабельном журнале) позитивный обзор языка Lisp (CLOS, Haskell, Miranda, Nemerle) в сравнении с C, где его (Lisp и т.д.) объективные недостатки (а любой из них объективно настолько менее распространён в промышленном программировании, чем C, что как вы выразились "даже сравнивать смешно" -- это же не случайно) были бы... хм... ну хоть упомянуты что ли?


Т.е Вы правда считаете, что C это венец творения?
Я не собираюсь доказывать, что Lisp или Haskell лучше чем C.
Если Вы в этом сомневаетесь, то значит просто не знаете эти языки.
Если нужна информация по Haskell, могу дать ссылки.
Что касается промышленного применения, то "более массовое" никогда не означало "лучшее".
Re[3]: Решение проблемы двух ботинок
От: HrorH  
Дата: 23.12.11 12:23
Оценка:
Здравствуйте, Tilir, Вы писали:

T>Но давайте для эксперимента обобщим это утверждение о недостатке объективности в аргументации с одного обзора на большинство.


T>Покажите мне хоть один (опубликованный в реферабельном журнале) позитивный обзор языка Lisp (CLOS, Haskell, Miranda, Nemerle) в сравнении с C, где его (Lisp и т.д.) объективные недостатки (а любой из них объективно настолько менее распространён в промышленном программировании, чем C, что как вы выразились "даже сравнивать смешно" -- это же не случайно) были бы... хм... ну хоть упомянуты что ли?


Какие недостатки этих языков Вы видите?
Недостатки есть везде, и действительно не все любят о них говорить.
Но иногда недостатком кажется то, что непривычно и не знакомо.
Re[4]: Решение проблемы двух ботинок
От: Tilir Россия http://tilir.livejournal.com
Дата: 23.12.11 12:38
Оценка:
Здравствуйте, FragMent, Вы писали:

T>>Покажите мне хоть один (опубликованный в реферабельном журнале) позитивный обзор языка Lisp (CLOS, Haskell, Miranda, Nemerle) в сравнении с C


FM>Не совсем подходит под критерии, но вот статья от уважаемого человека

FM>http://www.softcraft.ru/paradigm/fp/whynotfp.shtml

Статья с названием "Why no one uses functional languages" это действительно нечто, что не подходит под слова "позитивный обзор"
Re: Решение проблемы двух ботинок
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 23.12.11 13:03
Оценка:
T>"Предложения использовать иные [кроме C] языки часто имеет существенные изъяны в своей аргументации. Как пример -- анализ преимуществ языка Lisp приведённый в [ссылка на статью какого-то лисповеда из Беркли] основан на том как средcтва этого языка позволяют преодолевать проблемы, присущие C, но при этом опускаются его [языка Lisp] гораздо более существенные недостатки (примерно как если бы кто-то предлагал людям прыгать на одной ноге как средство избежать необходимости носить два ботинка, когда ходишь на двух)"

так автор сам-то говорит, чем язык C хуже Лисп?
или он других упрекает за то, что когда они говорят о своем языке, то хвалят только свой язык; а при этом сам же говоря о своем языке, хвалит только свой язык?
Re[2]: Решение проблемы двух ботинок
От: Tilir Россия http://tilir.livejournal.com
Дата: 23.12.11 13:17
Оценка:
Здравствуйте, DarkGray, Вы писали:

DG>так автор сам-то говорит, чем язык C хуже Лисп?

DG>или он других упрекает за то, что когда они говорят о своем языке, то хвалят только свой язык; а при этом сам же говоря о своем языке, хвалит только свой язык?

Автор и не рвётся решать проблемы других языков. Никакого сравнения с его стороны, равно как и никаких утверждений что Lisp "лучше" или "хуже" чем C -- не происходит. И вы ошибаетесь -- автор не "хвалит язык C". Хвалить на 1600 страницах -- это уже что-то арабское. Автор рассматривает некоторые экономические и социально-культурные аспекты нового стандарта -- всего-то. И рассматривает их объективно, указывая места где были приняты компромиссные решения и причины этих компромиссов.
Re[2]: Решение проблемы двух ботинок
От: Tilir Россия http://tilir.livejournal.com
Дата: 23.12.11 13:18
Оценка:
Здравствуйте, boot, Вы писали:

B>Добавлю только, что совершенный язык, это тот, в котором меньше слов, а сказать можно больше.


Не очевидно.
Re[3]: Решение проблемы двух ботинок
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 23.12.11 14:06
Оценка:
T>Не очевидно.

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

но т.к. человек плохо воспринимает абракадабру вида 1%343%:?№!ФВs-Az, то это требование заменяется другим:
(при прочих равных) лучше тот язык, который позволяет записать решение меньшим кол-вом термов
Re[2]: Решение проблемы двух ботинок
От: Don Reba Канада https://stackoverflow.com/users/49329/don-reba
Дата: 23.12.11 14:17
Оценка:
Здравствуйте, boot, Вы писали:

B>Добавлю только, что совершенный язык, это тот, в котором меньше слов, а сказать можно больше. Наличие 2-х пунктов сравнения, значительно затрудняет задачу поиска совершенного языка. То ли найти клопа на веревке для белья, а то ли на всем полу...


Совершенный язык помогает решить задачу быстро, дёшево и качественно. Соответсвенно, он должен быть не только краток, но и широко распространён, прост в изучении, итд.
Ce n'est que pour vous dire ce que je vous dis.
Re[4]: Решение проблемы двух ботинок
От: boot  
Дата: 23.12.11 15:50
Оценка:
Здравствуйте, DarkGray, Вы писали:


T>>Не очевидно.


DG>как минимум очевидна чуть другая формулировка:

DG>(при прочих равных) лучше тот язык, который позволяет записать решение меньшим кол-вом бит.

DG>но т.к. человек плохо воспринимает абракадабру вида 1%343%:?№!ФВs-Az, то это требование заменяется другим:

DG>(при прочих равных) лучше тот язык, который позволяет записать решение меньшим кол-вом термов

Здесь Вы привязаны к конкретной задаче, тут и философствовать не о чем Так и рассуждают при выборе языка. А вот если говорить о совершенстве вообще... Нету его.
Жизнеспособность прямо пропорциональна простоте!
Re: Решение проблемы двух ботинок
От: gegMOPO4  
Дата: 23.12.11 17:03
Оценка:
Здравствуйте, Tilir, Вы писали:
T>Мне кажется, это прекрасно. Достаточно просто почитать немного этот форум и "решатели проблемы двух ботинок" обнаружатся в ассортименте. Мне кажется, эта фраза достойна быть мемом. Чтобы, когда видишь как люди изощряются на одной ноге прыгать, всё сразу было ЯСНО -- ага, вот ещё один дядя решает проблему двух ботинок.

Да, так и есть. Правда, дома удобнее ходить в тапочках, плавать в ластах, есть ботинки лыжные и коньковые. А некоторые люди вообще одноногие, им не нужен второй ботинок. Для каждого случая уместно своё (думаю, автор это понимает).

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


Спасибо, отложу, обязательно нужно будет посмотреть. Упс… она у меня давно отложена. Ну, тем более надо прочитать.

Правда, книга уже несколько устарела.
Re[4]: Решение проблемы двух ботинок
От: Tilir Россия http://tilir.livejournal.com
Дата: 23.12.11 18:49
Оценка:
Здравствуйте, DarkGray, Вы писали:

DG>как минимум очевидна чуть другая формулировка:

DG>(при прочих равных) лучше тот язык, который позволяет записать решение меньшим кол-вом бит.

Тоже неочевидно. По моим критериям, если у вас есть конкретная задача и программа для неё на нескольких языках, то с точки зрения операционной лучше тот язык для которого компилятор сгенерирует лучший (по важным для вас критериям -- скжаем быстродействию или потреблению памяти) код, а с точки зрения денотационной -- тот, программу на котором программисту равному вам по квалификации будет проще читать и поддерживать. Но и то и другое больше зависит не от языка а от культуры и инфраструктуры программирования и сильно плывёт от задачи к задаче.
Re: Решение проблемы двух ботинок
От: мыщъх США http://nezumi-lab.org
Дата: 23.12.11 19:17
Оценка:
Здравствуйте, Tilir, Вы писали:

T>Hi,


T> Мне кажется, это прекрасно. Достаточно просто почитать немного этот форум и "решатели проблемы двух ботинок" обнаружатся в ассортименте.

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

язык -- не религия. и в промышленном программировании редкий комплекс написан на одном языке. и во многих случаях альтернативы нет. а сравнивать си и лисп это, извините, как сравнивать болид с шагающим экскаватором. ну или самолет с поездом. например, из питера в москву можно как доехать, так и долететь, но из москвы в сидней поезда не ходят.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Re[4]: Решение проблемы двух ботинок
От: мыщъх США http://nezumi-lab.org
Дата: 23.12.11 19:24
Оценка:
Здравствуйте, Tilir, Вы писали:

T>Здравствуйте, Ведмедь, Вы писали:


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


> # но удержание языка в скромных размерах дает реальные преимущества. Так как "C" относительно мал,

> # он не требует много места для своего описания и может быть быстро выучен.
> # Компилятор с "C" может быть простым и компактным
T> Знаете в каком году это писалось?
при всей моей любви к си я не могу удержаться от вопросов:

1) почему питон и руби предоставляют кучу мощных языковых средств, а начать писать на них, можно буквально с первых минут?
2) почему компиляторы си и документация по языку разрослить до ужасно нескромных размеров?
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Re[5]: Решение проблемы двух ботинок
От: Tilir Россия http://tilir.livejournal.com
Дата: 23.12.11 19:53
Оценка:
Здравствуйте, мыщъх, Вы писали:

М>при всей моей любви к си я не могу удержаться от вопросов:

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

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

Компилятор может быть маленьким не означает что он будет маленьким. Современный оптимизирующий компилятор -- это как тяжёлый авианосец -- плод совместного инженерного труда сотен и тысяч людей. И большая часть -- под водой.

Вы лучше удивитесь как сквозь все эти годы была пронесена изящная рациональная простота и адекватность языка C. Я считаю это просто чудом.
Re: Решение проблемы двух ботинок
От: batu Украина  
Дата: 23.12.11 21:40
Оценка:
Здравствуйте, Tilir, Вы писали:

T>Совершенно гениальная фраза из введения:



T>"Предложения использовать иные [кроме C] языки часто имеет существенные изъяны в своей аргументации. Как пример -- анализ преимуществ языка Lisp приведённый в [ссылка на статью какого-то лисповеда из Беркли] основан на том как средcтва этого языка позволяют преодолевать проблемы, присущие C, но при этом опускаются его [языка Lisp] гораздо более существенные недостатки (примерно как если бы кто-то предлагал людям прыгать на одной ноге как средство избежать необходимости носить два ботинка, когда ходишь на двух)"

Неудачное сравнение Кроме декларативных языков (логических и функциональных) и императивных (которых тоже куча от ассемблеров и объектных до прототипных или жабы) существуют и экзотические. Но все они скорее хождение на руках или скачки на одной ноге.. До хождения на двух ногах мы еще не дошли.. Скорее спорим на какой ноге эффективней прыгать на левой или на правой.
Re[3]: Решение проблемы двух ботинок
От: batu Украина  
Дата: 23.12.11 21:56
Оценка:
Здравствуйте, Don Reba, Вы писали:

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


B>>Добавлю только, что совершенный язык, это тот, в котором меньше слов, а сказать можно больше. Наличие 2-х пунктов сравнения, значительно затрудняет задачу поиска совершенного языка. То ли найти клопа на веревке для белья, а то ли на всем полу...


DR>Совершенный язык помогает решить задачу быстро, дёшево и качественно. Соответсвенно, он должен быть не только краток, но и широко распространён, прост в изучении, итд.

Совершенно согласен. Очень много внимания уделяется именно эффективности языка, а ведь он выполняет еще задачу общения и документирования. Зашифровать кракозябрами можно все что угодно. Только потом еще один язык дешифратор понадобится
Re[4]: Решение проблемы двух ботинок
От: batu Украина  
Дата: 23.12.11 22:01
Оценка:
Здравствуйте, DarkGray, Вы писали:


T>>Не очевидно.


DG>как минимум очевидна чуть другая формулировка:

DG>(при прочих равных) лучше тот язык, который позволяет записать решение меньшим кол-вом бит.

DG>но т.к. человек плохо воспринимает абракадабру вида 1%343%:?№!ФВs-Az, то это требование заменяется другим:

DG>(при прочих равных) лучше тот язык, который позволяет записать решение меньшим кол-вом термов
Есть на эту тему очень удобный язык. Пронумеруем все задачи решаемые этим языком и программирование тогда будет заключаться в написании номера задачи.
Re[6]: Решение проблемы двух ботинок
От: __lambda__ Россия http://zen-hacker.blogspot.com/
Дата: 23.12.11 23:00
Оценка:
Здравствуйте, Tilir, Вы писали:

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


"Скриптовые поделки" Мы тут инженера собрались или кто?
Computer science is no more about computers than astronomy is about telescopes (c) Edsger Dijkstra
Re[3]: Решение проблемы двух ботинок
От: boot  
Дата: 24.12.11 03:42
Оценка:
Здравствуйте, batu, Вы писали:

B>>Добавлю только, что совершенный язык, это тот, в котором меньше слов, а сказать можно больше. Наличие 2-х пунктов сравнения, значительно затрудняет задачу поиска совершенного языка. То ли найти клопа на веревке для белья, а то ли на всем полу...

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

Вот это похоже на плодотворные рассуждения, а от философии, как говорит статистика, проку никакого. Чтобы что-то с чем-то сравнить, нужно сперва измерить и представить числом, и сравнивать числа напрямую связанные с измеряемым, а не число ботинок в аналогии
Жизнеспособность прямо пропорциональна простоте!
Re[3]: Решение проблемы двух ботинок
От: boot  
Дата: 24.12.11 03:53
Оценка:
Замечательно сказано, все, кроме намека на __lambda__. Зря мы переходим на личности, вместо поиска лучшего вокруг, начинается поиск худшего друг в друге.
Жизнеспособность прямо пропорциональна простоте!
Re[3]: Решение проблемы двух ботинок
От: __lambda__ Россия http://zen-hacker.blogspot.com/
Дата: 24.12.11 05:47
Оценка:
Здравствуйте, Tilir, Вы писали:

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


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

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


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

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


Не знают хотя бы три языка, берите их сразу себе
Computer science is no more about computers than astronomy is about telescopes (c) Edsger Dijkstra
Re[3]: Решение проблемы двух ботинок
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 24.12.11 08:03
Оценка:
Здравствуйте, Tilir, Вы писали:

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


А кто первый начал-то? Если бы Вы просто разрекламировали книгу, то вопроса бы не было. Но Вы начали с бессмысленного наезда на другие языки вообще и особенно на LISP, и породили замечательный holy war. Теперь разбирайте последствия.
The God is real, unless declared integer.
Re[3]: Решение проблемы двух ботинок
От: 0x7be СССР  
Дата: 24.12.11 08:30
Оценка:
Здравствуйте, мыщъх, Вы писали:

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

Можешь развить эту свою мысль?
Re[3]: Решение проблемы двух ботинок
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 24.12.11 08:31
Оценка:
Здравствуйте, мыщъх, Вы писали:

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


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


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


Ну не скажи. Если я вот хочу, чтобы в данной переменной было только целое число и ничего иного, это от нищеты хардвера? нет, пусть машина думает за меня и ловит все случаи присвоения чего-то иного, она быстрая.
The God is real, unless declared integer.
Re[4]: Решение проблемы двух ботинок
От: мыщъх США http://nezumi-lab.org
Дата: 24.12.11 08:45
Оценка:
Здравствуйте, 0x7be, Вы писали:

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


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

0>Можешь развить эту свою мысль?
а ее надо развивать?
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Re[5]: Решение проблемы двух ботинок
От: Курилка Россия http://kirya.narod.ru/
Дата: 24.12.11 09:17
Оценка:
Здравствуйте, мыщъх, Вы писали:

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

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

Может не стоит приводить в пример язык со статической, но слабой типизацией?
Re[3]: Решение проблемы двух ботинок
От: WolfHound  
Дата: 24.12.11 09:35
Оценка:
Здравствуйте, Tilir, Вы писали:

T>Речь идёт о том что программирование это инженерная дисциплина в которой нельзя что-то получить чем-то не заплатив.



T>Получаете скорость разработки -- платите объёмом кода,

Чего?

T>получаете высокоуровневые примтивы -- платите быстродействием и так далее.

Ой, не факт.
Если мы имеем дело с ДСЛ, то мы получаем примитивы предельно высокого уровня для данной задачи.
При этом за счет предметно ориентированных оптимизаций и предметно ориентированной кодогенерации мы получаем такое быстродействие, что руками гоняться вспотеешь.
Это я тебе говорю как человек, который по уши в ДСЛях.

T>Без вариантов.

Это по тому, что ты только языки общего назначения рассматриваешь.
А они все неадекватны. Просто по тому, что они общего назначения.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[4]: Решение проблемы двух ботинок
От: gegMOPO4  
Дата: 24.12.11 09:45
Оценка:
24.12.11 10:03, netch80 написав(ла):
> Здравствуйте, Tilir, Вы писали:
> T>Речь об этом, а не о C и не о его сравнении с Лиспом пусть они оба будут здоровы. Чтож всех так на холивор тянет
> А кто первый начал-то? Если бы Вы просто разрекламировали книгу, то вопроса бы не было. Но Вы начали с бессмысленного наезда на другие языки вообще и особенно на LISP, и породили замечательный holy war. Теперь разбирайте последствия.

Хм. Я-то это прочитал как не «начал», а «закончил». Как призыв не вести холивары о том, какой язык лучше. А для этого нужно понимать, что у каждого языка есть слабые стороны. И в разных контекстах те или иные сильные и слабые стороны важнее.
Posted via RSDN NNTP Server 2.1 beta
Re[5]: Решение проблемы двух ботинок
От: alpha21264 СССР  
Дата: 24.12.11 10:14
Оценка:
Здравствуйте, мыщъх, Вы писали:

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


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


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

0>>Можешь развить эту свою мысль?
М>а ее надо развивать?

Надо. Персонально для 0x7be.
Может быть ты не знаешь, но 0x7be — молодой и талантливый парень.
Но молодой (массы вещей не знает) но талантливый (очень быстро учится).
Это он написал статью про предел высокоуровневости языка.
Так что уж удели время.

Течёт вода Кубань-реки куда велят большевики.
Re[5]: Решение проблемы двух ботинок
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 24.12.11 14:48
Оценка:
B>В этом и есть великая загадка диагонали квадрата. Ее невозможно представить числом.

представить нельзя, но можно измерить с заданной точностью в виде двух граней
Re[5]: Решение проблемы двух ботинок
От: 0x7be СССР  
Дата: 24.12.11 15:52
Оценка:
Здравствуйте, мыщъх, Вы писали:

0>>Можешь развить эту свою мысль?

М>а ее надо развивать?
Мне — да
В смысле, что объясни подробнее, я то я не понял
Re[5]: Решение проблемы двух ботинок
От: VoidEx  
Дата: 24.12.11 18:30
Оценка:
Здравствуйте, мыщъх, Вы писали:

М>в идеале, язык должен предоставлять: натуральные, рациональные, вещественные...

целые...
Re[7]: Решение проблемы двух ботинок
От: __lambda__ Россия http://zen-hacker.blogspot.com/
Дата: 25.12.11 00:17
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Скажем так. Иногда генерируют код сравнимый с эффективным. И почему речь о SBCL идет во множественном числе?


Потому что, есть не только SBCL, а еще есть Clozure CL, Lispworks, Allegro CL, ...

VD>На фоне популярности Лиспа и Висик супер-популярным языком покажется.


Вообще, оценивать на базе популярности, сомнительно. Сам же ведь говорил поначалу очень умно и трезво. Мол, нужна функция оценки. А тут мы скатились к банальной популярности. Ну тогда уж PHP венец творения человечества! А лучший певец это Филипп Киркоров.
Computer science is no more about computers than astronomy is about telescopes (c) Edsger Dijkstra
Re[5]: Решение проблемы двух ботинок
От: мыщъх США http://nezumi-lab.org
Дата: 25.12.11 00:41
Оценка:
Здравствуйте, VladD2, Вы писали:

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


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


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


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

вот практический пример из жизни. мы пишем IPS. и все модули у нас делятся на два типа. online и off-line. онлайн подразумевает реал-тайм. если по производительности в реалтайм мы не вписываемся хотя бы на несколько процентов, то модуль уходит в off-line и с инженерной точки зрения все равно сколько он обрабатывает данные — 10 ms или 10 сек. все равно цикл оффлайна это десятки _минут_. то есть оптимизация офф-лайна никому не интересна, зато интересно кол-во фич, которые мы хотим реализовать. а кол-во фич напрямую зависит от скорости разработки. а в он-лайне очень мало, что можно сделать и потому набор фич там не меняется годами и скорость разработки не критична.

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

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

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

а давайте сравнивать ответку с плоскогубцами? критериев масса. напрмер, масса (т.е. вес). надежность (отсутствие в отвертке подвижных частей). травмоопасность...
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Re[8]: Решение проблемы двух ботинок
От: VladD2 Российская Империя www.nemerle.org
Дата: 25.12.11 04:56
Оценка:
Здравствуйте, __lambda__, Вы писали:

VD>>Скажем так. Иногда генерируют код сравнимый с эффективным. И почему речь о SBCL идет во множественном числе?


___>Потому что, есть не только SBCL, а еще есть Clozure CL, Lispworks, Allegro CL, ...


Вот только когда речь заходит о скорости генерируемого кода, то почему-то все в SBCL тычут.
Почему?

VD>>На фоне популярности Лиспа и Висик супер-популярным языком покажется.


___>Вообще, оценивать на базе популярности, сомнительно. Сам же ведь говорил поначалу очень умно и трезво. Мол, нужна функция оценки. А тут мы скатились к банальной популярности. Ну тогда уж PHP венец творения человечества! А лучший певец это Филипп Киркоров.


А не надо фразы из контекста выдерать. Тогда все будет ОК.

Изначально я говорил "если сравнивать по критерию...". Про популярность заикнулся не я. Но это тоже вполне себе критерий по которому можно сравнить. Вопрос только в том, что это даст.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Решение проблемы двух ботинок
От: batu Украина  
Дата: 25.12.11 08:26
Оценка:
Здравствуйте, DarkGray, Вы писали:

B>>В этом и есть великая загадка диагонали квадрата. Ее невозможно представить числом.


DG>представить нельзя, но можно измерить с заданной точностью в виде двух граней

Я думаю разницу вы понимаете.
Re[9]: Решение проблемы двух ботинок
От: FR  
Дата: 25.12.11 08:35
Оценка:
Здравствуйте, VladD2, Вы писали:


VD>Вот только когда речь заходит о скорости генерируемого кода, то почему-то все в SBCL тычут.

VD>Почему?

Потому же что и в интеловский компилятор C++.
Re[7]: Решение проблемы двух ботинок
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 25.12.11 09:18
Оценка:
DG>>представить нельзя, но можно измерить с заданной точностью в виде двух граней
B>Я думаю разницу вы понимаете.

в реальных задачах такой измеримости хватает
Re[7]: Решение проблемы двух ботинок
От: Privalov  
Дата: 25.12.11 13:14
Оценка:
Здравствуйте, мыщъх, Вы писали:

М>хотите сказать, что выучить фортран было сильно сложнее чем си?


Ты просто не сталкивался как следует с Фортраном.

М>покажите мне монументальный faq по фортрану где на 100 страницах обсуждается, что внутренее представлене нулевого указателя никого не парит, и что *0 это никакой не нуль и на некоторых экзотических платформах программа может сломаться если функции передать 0, а не *0. а может и не сломаться, если компилятор поймет, что 0 это указатель.


Я сейчас отстал от жизни, но когда я плотно работал на Фортране, там указателей не было. Думаю, FAQ по указателям не было именно по этой причине.

М>так же мне интересно сколько нужно затратить времени на изучение си, чтобы ответить, что напечатает вот такая прогрмма:


Всякие адреса.

А что напечатает такая программа на Фортране?

       CALL MSPEAK(2)
       K=2
       PRINT *, K
       END

       SUBROUTINE MSPEAK(I)
       INTEGER I
       I = I + 1
       RETURN
       END




М>так что про простоту си не надо. чтобы писать промышленную программу на фортране большого опыта не надо, чего не скажешь о си.


Ну-ну...
Re[8]: Решение проблемы двух ботинок
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 25.12.11 13:19
Оценка:
Здравствуйте, Privalov, Вы писали:

P>А что напечатает такая программа на Фортране?


Для современных версий такие хохмы, думаю, не сработают. Хотя надо читать стандарты.
The God is real, unless declared integer.
Re[9]: Решение проблемы двух ботинок
От: Privalov  
Дата: 25.12.11 13:28
Оценка:
Здравствуйте, netch80, Вы писали:

N>Для современных версий такие хохмы, думаю, не сработают. Хотя надо читать стандарты.


Возможно. Нет у меня современного Фортрана под рукой, чтобы проверить. Но у него была офигенная обратная совместимость в те времена, когда я на нем программировал. Но даже если такое не пройдет, то можно сделать не менее распространенное:

    DO 5 I = 1.10


Я знаю, что циклы DO/ENDDO существуют в Фортране уже много лет, но кода на старом добром Фортране IV еще довольно-таки до фига.
Re[10]: Решение проблемы двух ботинок
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 25.12.11 13:52
Оценка:
Здравствуйте, Privalov, Вы писали:

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


N>>Для современных версий такие хохмы, думаю, не сработают. Хотя надо читать стандарты.


P>Возможно. Нет у меня современного Фортрана под рукой, чтобы проверить.


У меня есть. На FreeBSD, Linux. Результаты такие:
* f2c выдал 2 (как и хотелось по-современному)
* gfortran от gcc 4.4 и 4.5 дали одинаковый результат — программа упала в корку в mspeak() (константы сидят в R/O странице, как и положено современному средству).

Все опции компиляции — по умолчанию.

P> Но у него была офигенная обратная совместимость в те времена, когда я на нем программировал. Но даже если такое не пройдет, то можно сделать не менее распространенное:


P>
P>    DO 5 I = 1.10
P>


Да, и f2c и gfortran делают присвоение (если по умолчанию). Но:
* задание -ffree-form (gfortran; f2c такого не умеет) привело к тому, что "Error: Syntax error in iterator". Это соответствует изменению парсера для freeform синтаксиса.
* опять-таки, implicit none не зря придумали; gfortran знает -fimplicit-none для задания умолчания, и с ним тривиально ловить такие хохмы...

P>Я знаю, что циклы DO/ENDDO существуют в Фортране уже много лет, но кода на старом добром Фортране IV еще довольно-таки до фига.


Согласен. И эффекты там бывают нетривиальные (я ещё люблю наблюдать комбинации несовместимых format и namelist, но это в общем случае непереносимо). Но сейчас большинство их можно достаточно легко вычистить.
The God is real, unless declared integer.
Re[11]: Решение проблемы двух ботинок
От: Privalov  
Дата: 25.12.11 14:27
Оценка:
Здравствуйте, netch80, Вы писали:

N>У меня есть. На FreeBSD, Linux. Результаты такие:

N>* f2c выдал 2 (как и хотелось по-современному)

Выходит, что f2c аргументы по значению передает?

N>* gfortran от gcc 4.4 и 4.5 дали одинаковый результат — программа упала в корку в mspeak() (константы сидят в R/O странице, как и положено современному средству).


Выглядит логичным, потому как порчу констант если и делали, то намеренно.

P>>
P>>    DO 5 I = 1.10
P>>


N>Да, и f2c и gfortran делают присвоение (если по умолчанию). Но:

N>* задание -ffree-form (gfortran; f2c такого не умеет) привело к тому, что "Error: Syntax error in iterator". Это соответствует изменению парсера для freeform синтаксиса.

Выглядит так, будто компилятор Фортрана служебные слова начал отличать от всего остального.
На самом деле free form был еще в MS Fortran 5.0. Но я так и не привык к нему. Коллеги постарше вообще не могли его читать.

N>* опять-таки, implicit none не зря придумали; gfortran знает -fimplicit-none для задания умолчания, и с ним тривиально ловить такие хохмы...


После того, как набор программ, которые я переносил с ЕС на PC, заработал, первое, что я сделал — вставил везде в исходники это самое implicit none. В двух-трех местах вылезло несколько таких штучек: prtl, prti и prt1, которые на самом деле должны были быть одной переменной. Пришлось чинить.

N>И эффекты там бывают нетривиальные (я ещё люблю наблюдать комбинации несовместимых format и namelist, но это в общем случае непереносимо). Но сейчас большинство их можно достаточно легко вычистить.


Угу. А еще нетривиальное использование EQUIVALENCE.
Re[12]: Решение проблемы двух ботинок
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 25.12.11 14:49
Оценка:
Здравствуйте, Privalov, Вы писали:

N>>У меня есть. На FreeBSD, Linux. Результаты такие:

N>>* f2c выдал 2 (как и хотелось по-современному)
P>Выходит, что f2c аргументы по значению передает?

Нет, там хитрее. В функцию он передал &c__2 по указателю (которая static, равна 2, и даже не const), а вот дальше делал не k = c__2, а k = 2.
То есть чуть более хитрый тест его бы даже легче заломал, чем gfortran, но вот проявлений в типичных случаях было бы меньше.

N>>Да, и f2c и gfortran делают присвоение (если по умолчанию). Но:

N>>* задание -ffree-form (gfortran; f2c такого не умеет) привело к тому, что "Error: Syntax error in iterator". Это соответствует изменению парсера для freeform синтаксиса.

P>Выглядит так, будто компилятор Фортрана служебные слова начал отличать от всего остального.


Ну да, приходим к более современному парсеру.

N>>* опять-таки, implicit none не зря придумали; gfortran знает -fimplicit-none для задания умолчания, и с ним тривиально ловить такие хохмы...


P>После того, как набор программ, которые я переносил с ЕС на PC, заработал, первое, что я сделал — вставил везде в исходники это самое implicit none. В двух-трех местах вылезло несколько таких штучек: prtl, prti и prt1, которые на самом деле должны были быть одной переменной. Пришлось чинить.


Небось первый набор шёл ещё девочками с бланков?

N>>И эффекты там бывают нетривиальные (я ещё люблю наблюдать комбинации несовместимых format и namelist, но это в общем случае непереносимо). Но сейчас большинство их можно достаточно легко вычистить.

P>Угу. А еще нетривиальное использование EQUIVALENCE.

Ну как сишный union мы его использовали направо и налево.
The God is real, unless declared integer.
Re[13]: Решение проблемы двух ботинок
От: Privalov  
Дата: 25.12.11 15:14
Оценка:
Здравствуйте, netch80, Вы писали:

P>>Выходит, что f2c аргументы по значению передает?


N>Нет, там хитрее. В функцию он передал &c__2 по указателю (которая static, равна 2, и даже не const), а вот дальше делал не k = c__2, а k = 2.

N>То есть чуть более хитрый тест его бы даже легче заломал, чем gfortran, но вот проявлений в типичных случаях было бы меньше.

Интересно, как это он так. Там же вся фишка в том, чтобы убить этот самый static. Впрочем, есло f2c — это транслатор с Фортрана на С, то от него мы много разной ерунды получали, в конце концов отказались от него.

P>>Выглядит так, будто компилятор Фортрана служебные слова начал отличать от всего остального.


N>Ну да, приходим к более современному парсеру.


Нормально, только для обратной совместимости надо бы предусмотреть опции или метакоманды.

N>Небось первый набор шёл ещё девочками с бланков?


Не знаю. Когда это начинало разрабатываться, я, наверно, еще в детсад не ходил еще. Но на PC откомпилировалось практически сразу. (MSF 5.0 в MS DOS).

P>>Угу. А еще нетривиальное использование EQUIVALENCE.


N>Ну как сишный union мы его использовали направо и налево.


Уже не помню деталей, там что-то, связанное с объявлением EXTERNAL было в EQUIVALENCE. Сам так не делал, поэтому, возможно, здесь гоню.
Re[6]: Решение проблемы двух ботинок
От: batu Украина  
Дата: 25.12.11 17:21
Оценка:
Здравствуйте, FR, Вы писали:

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


B>>Видно что у вас с философией не очень. Измерить можно только счетное число. В этом и есть великая загадка диагонали квадрата. Ее невозможно представить числом.


FR>Иррациональное число

А я об чем...
Re[6]: Решение проблемы двух ботинок
От: batu Украина  
Дата: 25.12.11 17:24
Оценка:
Здравствуйте, netch80, Вы писали:


B>> Измерить можно только счетное число. В этом и есть великая загадка диагонали квадрата.


N>А также посконная и кондовая. (c)

N>Понятия "счётное число" не существует. Не знаю, откуда Вы его выкопали и что имели в виду. Рациональное? С точки зрения математики, квадратный корень из 2 — настолько же полноправное число, как и просто 2, и число Пи, и мнимая единица; и невозможность представить конечным количеством цифр или в виде дроби не мешает этому.

Ну и я об этом.. Имелось в виду не только рациональные, а любые которых счетное число. Надо было написать счетное количество.. Ну, звыняете..
Re: Почти оффтоп
От: Mamut Швеция http://dmitriid.com
Дата: 25.12.11 22:01
Оценка:
T>Совершенно гениальная фраза из введения:

T>"Proposals to use other languages sometimes have more obvious flaws in their arguments. An analysis of why Lisp should be used [398] is based on how that language overcomes some of the C-inherent problems, while overlooking its own more substantial weaknesses (rather like proposing that people hop on one leg as a solution to wearing out two shoes by walking on two)"


T>Близкий к тексту перевод (в квадратных скобках -- мои комментарии):


T>"Предложения использовать иные [кроме C] языки часто имеет существенные изъяны в своей аргументации. Как пример -- анализ преимуществ языка Lisp приведённый в [ссылка на статью какого-то лисповеда из Беркли] основан на том как средcтва этого языка позволяют преодолевать проблемы, присущие C, но при этом опускаются его [языка Lisp] гораздо более существенные недостатки (примерно как если бы кто-то предлагал людям прыгать на одной ноге как средство избежать необходимости носить два ботинка, когда ходишь на двух)"


Странно, что абсолюно верная фраза вызвала столько холивара

Ведь если посмотреть почти на все холивары типа X vs. Y, где X и Y — два произвольно взятых языка, то они все моментально скатываются в: X — лучше, потому что в Y фича A сделана плохо, а в X фича А сделана хорошо. При этом таки да, недостатки языка X старательно замалчиваются или считаются несущественными.

Смешно, что даже автор, который эту фразу нашел, и представил ее к нам сам скатился в точно такой же спор в C vs. Fortran и т.п.


dmitriid.comGitHubLinkedIn
Re[9]: Решение проблемы двух ботинок
От: мыщъх США http://nezumi-lab.org
Дата: 25.12.11 22:11
Оценка:
Здравствуйте, batu, Вы писали:

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



DG>>>>представить нельзя, но можно измерить с заданной точностью в виде двух граней

B>>>Я думаю разницу вы понимаете.

DG>>в реальных задачах такой измеримости хватает

B>А я и не спорю. В реальной жизни вообще бесконечность ни к чему. Но любопытно. Ведь любое что-то состоит из чего-то.. Ну, атомов, допустим. Их можно посчитать по сторонам квадрата. Разрезаем квадрат по диагонали и там же должно быть целое число этих что назвали атомами.. А оно отнюдь! Разве не любопытно?

один из нас тормозит. возьмем кристаллическую решотку. типа вот такую:

+ + +
+ + +
+ + +

диагональ -- три атома. вопрос -- ну и что из этого следует?!

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

***
***
***

вам не кажется, что все равно иррациональное число получается? ну чисто геометрически.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Re[10]: Решение проблемы двух ботинок
От: batu Украина  
Дата: 26.12.11 07:05
Оценка:
Здравствуйте, мыщъх, Вы писали:

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


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



DG>>>>>представить нельзя, но можно измерить с заданной точностью в виде двух граней

B>>>>Я думаю разницу вы понимаете.

DG>>>в реальных задачах такой измеримости хватает

B>>А я и не спорю. В реальной жизни вообще бесконечность ни к чему. Но любопытно. Ведь любое что-то состоит из чего-то.. Ну, атомов, допустим. Их можно посчитать по сторонам квадрата. Разрезаем квадрат по диагонали и там же должно быть целое число этих что назвали атомами.. А оно отнюдь! Разве не любопытно?

М>один из нас тормозит. возьмем кристаллическую решотку. типа вот такую:


М>+ + +

М>+ + +
М>+ + +

М>диагональ -- три атома. вопрос -- ну и что из этого следует?!


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


М>***

М>***
М>***

М>вам не кажется, что все равно иррациональное число получается? ну чисто геометрически.

Ну, есть еще вариант диагональ равна стороне. Тоже 3 атома
Re[11]: Решение проблемы двух ботинок
От: мыщъх США http://nezumi-lab.org
Дата: 26.12.11 09:30
Оценка:
Здравствуйте, batu, Вы писали:

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


М>>вам не кажется, что все равно иррациональное число получается? ну чисто геометрически.

B>Ну, есть еще вариант диагональ равна стороне. Тоже 3 атома
зачем нам атомы, когда у нас есть пиксели? допустим, три пикселя каждая сторона и три пикселя диагональ. и чему будет равен угол? что-то мне подсказывает, что 90 градусов у нас никак не получается.

ничего мистического в диагоналях нет. допустим, квадрат 1 x 1. диагональ 2^1/2. если диагональ принять за единичный отрезок, то иррациональными становятся стороны.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Re[4]: Решение проблемы двух ботинок
От: Mamut Швеция http://dmitriid.com
Дата: 26.12.11 11:14
Оценка:
М>>Здравствуйте, D. Mon, Вы писали:

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


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


A>статическая типизация нужна для верификации кода на стадии компиляции.



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


dmitriid.comGitHubLinkedIn
Re[3]: Почти оффтоп
От: Mamut Швеция http://dmitriid.com
Дата: 26.12.11 11:42
Оценка:
T>>>Совершенно гениальная фраза из введения:

T>>>"Proposals to use other languages sometimes have more obvious flaws in their arguments. An analysis of why Lisp should be used [398] is based on how that language overcomes some of the C-inherent problems, while overlooking its own more substantial weaknesses (rather like proposing that people hop on one leg as a solution to wearing out two shoes by walking on two)"


T>>>Близкий к тексту перевод (в квадратных скобках -- мои комментарии):


T>>>"Предложения использовать иные [кроме C] языки часто имеет существенные изъяны в своей аргументации. Как пример -- анализ преимуществ языка Lisp приведённый в [ссылка на статью какого-то лисповеда из Беркли] основан на том как средcтва этого языка позволяют преодолевать проблемы, присущие C, но при этом опускаются его [языка Lisp] гораздо более существенные недостатки (примерно как если бы кто-то предлагал людям прыгать на одной ноге как средство избежать необходимости носить два ботинка, когда ходишь на двух)"


M>>Странно, что абсолюно верная фраза вызвала столько холивара


HH>Холивар с самого начала был зря, каюсь.

HH>Но меня удивляет другое. Почему никто не видит, что фраза эта с сюрпризом.
HH>На первый взгляд кажется, что здесь говорится о том, что лисповед не упомянул в статье недостатки языка Лисп, и это было замечено автором книги. Все совершенно логично.
HH>Но реально здесь сказано следующее: язык Lisp имеет более существенные недостатки, чем недостатки языка C, указанные в статье лисповеда.
HH>Но сказано это неявно, это подрузамевается в самой констукции фразы. Это так называемая пресуппозиция.

По-моему, это из разряда школьных «Пушкин использовал в третьей строке пятой строфы шестой главы слово X потому что он считал, что...»

HH>Вообще фраза о том, что где-то чего-то нет, часто подрузамевает то, что это нечто там должно быть.

HH>Я придрался именно к тому, что это неявное утверждение не доказывается, и даже не говорится, о каких недостатках идет речь.
HH>Но у меня (уже позже) сложилось впечатление, что метафора так понравилась топикстартеру, что он сам не заметил тот неявный наезд, который позволил себе автор книги.

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


dmitriid.comGitHubLinkedIn
Re[4]: Почти оффтоп
От: HrorH  
Дата: 26.12.11 11:50
Оценка:
Здравствуйте, Mamut, Вы писали:

HH>>Но реально здесь сказано следующее: язык Lisp имеет более существенные недостатки, чем недостатки языка C, указанные в статье лисповеда.

HH>>Но сказано это неявно, это подрузамевается в самой констукции фразы. Это так называемая пресуппозиция.

M>По-моему, это из разряда школьных «Пушкин использовал в третьей строке пятой строфы шестой главы слово X потому что он считал, что...»


Совершенно верно. Это не из техники, а из гуманитарных наук. Я встретил это в НЛП, т.е. психологии.
Дело в том, что когда речь идет об умении думать, то необходимо заметить, что думает именно человек, а науки, которые занимаются человеком называются гуманитарными.
Кстати языки высокого уровня тем и интересны, что более подходят для развития человеческого мышления.
Re[5]: Почти оффтоп
От: Mamut Швеция http://dmitriid.com
Дата: 26.12.11 15:48
Оценка:
HH>>>Но реально здесь сказано следующее: язык Lisp имеет более существенные недостатки, чем недостатки языка C, указанные в статье лисповеда.
HH>>>Но сказано это неявно, это подрузамевается в самой констукции фразы. Это так называемая пресуппозиция.

M>>По-моему, это из разряда школьных «Пушкин использовал в третьей строке пятой строфы шестой главы слово X потому что он считал, что...»


HH>Совершенно верно. Это не из техники, а из гуманитарных наук. Я встретил это в НЛП, т.е. психологии.

HH>Дело в том, что когда речь идет об умении думать, то необходимо заметить, что думает именно человек, а науки, которые занимаются человеком называются гуманитарными.

Что думает именно человек, неизвестно никому, потому что чужая душа потемки


dmitriid.comGitHubLinkedIn
Re[7]: Решение проблемы двух ботинок
От: A13x США  
Дата: 26.12.11 19:33
Оценка:
Здравствуйте, VladD2, Вы писали:

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


___>>Кстати, справедливости ради, компиляторы Common Lisp'а генерят очень эффективный нативный код.


VD>Скажем так. Иногда генерируют код сравнимый с эффективным. И почему речь о SBCL идет во множественном числе?


Вообще-то есть еще lispworks и allegro common lisp.
Re[5]: Решение проблемы двух ботинок
От: A13x США  
Дата: 26.12.11 19:40
Оценка:
Здравствуйте, мыщъх, Вы писали:

М>...

М>2) почему компиляторы си и документация по языку разрослить до ужасно нескромных размеров?

Тут уже приводили как пример — tcc, не оптимизирующий компилятор с сумасшедшей скоростью компиляции — порядка 40 Мб кода в секунду.
Re[4]: Решение проблемы двух ботинок
От: konsoletyper Россия https://github.com/konsoletyper
Дата: 27.12.11 06:18
Оценка:
Здравствуйте, Tilir, Вы писали:

T>

T>...
T> В языке "C" отсутствуют операции, имеющие дело непосредственно с составными объектами, такими как строки символов, множества, списки или с массивами, рассматриваемыми как целое. Здесь, например, нет никакого аналога операциям PL/1, оперирующим с целыми массивами и строками. Язык не предоставляет никаких других возможностей распределения памяти, кроме статического определения и механизма стеков, обеспечиваемого локальными переменных функций; здесь нет ни "куч"(HEAP), ни "сборки мусора", как это предусматривается в АЛГОЛЕ-68. Наконец, сам по себе "C" не обеспечивает никаких возможностей ввода-вывода: здесь нет операторов READ или WRITE и никаких встроенных методов доступа к файлам. Все эти механизмы высокого уровня должны обеспечиваться явно вызываемыми функциями.
T> Аналогично, язык "C" предлагает только простые, последовательные конструкции потоков управления: проверки, циклы, группирование и подпрограммы, но не мультипрограммирование, параллельные операции, синхронизацию или сопрограммы.
T> Хотя отсутствие некоторых из этих средств может выглядеть как удручающая неполноценность ("выходит, что я должен обращаться к функции, чтобы сравнить две строки символов ?!"), но удержание языка в скромных размерах дает реальные преимущества. Так как "C" относительно мал, он не требует много места для своего описания и может быть быстро выучен. Компилятор с "C" может быть простым и компактным
T>...


Так ведь говорится в контексте 70-х, когда каждая новая возможность вводилась с помощью нового языкового средства. K&R всего лишь указали, что возможности можно вводить с помощью библиотек, а язык прорабатывать в сторону увеличения мощности для написания этих библиотек. Сйчас это ясно кому угодно. Никто не пытается противопоставлять C некий язык блаб, потому что в блабе строки, списки и комплексные числа поддерживаются нативно. Вместо этого к C есть другие претензии. Ну как минимум — некто пишет фреймворк, где в числе прочего поддерживаются строки, списки и комплексные числа. Так почему функции для сравнения этих сущностей должны называться compare_strings, compare_lists, compare_complex_numbers, вместо того, чтобы всем дружно называться — compare?
Re[5]: Решение проблемы двух ботинок
От: konsoletyper Россия https://github.com/konsoletyper
Дата: 27.12.11 06:30
Оценка:
Здравствуйте, Mamut, Вы писали:

M>Для верификации очень маленького подмножества того, что код делает.


Зато это очень маленькое подмножество является очень благодатной почвой для ошибок.
Re[6]: Решение проблемы двух ботинок
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 27.12.11 06:50
Оценка:
Здравствуйте, konsoletyper, Вы писали:

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


M>>Для верификации очень маленького подмножества того, что код делает.


K>Зато это очень маленькое подмножество является очень благодатной почвой для ошибок.


Из чего это следует?
The God is real, unless declared integer.
Re[12]: Решение проблемы двух ботинок
От: batu Украина  
Дата: 27.12.11 09:44
Оценка:
Здравствуйте, мыщъх, Вы писали:

М>зачем нам атомы, когда у нас есть пиксели? допустим, три пикселя каждая сторона и три пикселя диагональ. и чему будет равен угол? что-то мне подсказывает, что 90 градусов у нас никак не получается.


М>ничего мистического в диагоналях нет. допустим, квадрат 1 x 1. диагональ 2^1/2. если диагональ принять за единичный отрезок, то иррациональными становятся стороны.

Я хотел сказать о философской проблеме рациональных чисел и ее связи с возможностью измерять. Идея заключается в возможности разделить нечто на целое количество равных (не важно сколь угодно малых) частей. Если это возможно, то возможно и измерить. Так вот появление иррациональных чисел и доказывает что не все можно измерять. В частности диагональ квадрата. Это странно. Хотя и не к такому привыкали
Re[7]: Решение проблемы двух ботинок
От: konsoletyper Россия https://github.com/konsoletyper
Дата: 27.12.11 11:01
Оценка:
Здравствуйте, netch80, Вы писали:

M>>>Для верификации очень маленького подмножества того, что код делает.


K>>Зато это очень маленькое подмножество является очень благодатной почвой для ошибок.


N>Из чего это следует?


Из опыта. Кстати, по поводу ошибок. Тут уместно говорить не столько об автоматическом отлове ошибок, сколько о том, как снизить вероятность их возникновения и приблизить время их обнаружения к месту, где они реально возникли. И тут уже вопрос не только о системе типов языка. Например, в том же C# есть нехорошая в этом смысле конструкция as, которую стараются избегать. Готов обсудить конкретные особенности конкретных языков, которые помогают или мешают легче обнаруживать ошибки.

Вот вам пожалуйста динамически типизированный язык javascript. В нём, если неправильно набрать имя переменной, получим значение undefined. Этот undefined может очень долго путешествовать по графу объектов, пока, например, кто-нибудь не попытается вызвать у него метод. В Ruby есть похожая штука, хорошо хоть в случае с локальными переменными это побороли.
Re: Решение проблемы двух ботинок
От: Klapaucius  
Дата: 10.01.12 09:08
Оценка:
Здравствуйте, Tilir, Вы писали:

T>Относительно каждой строчки стандарта C99 обсуждаются причины почему она должна быть именно такой и не иначе


А причины, почему она должна была быть не такой, а иной обсуждаются?
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[4]: Решение проблемы двух ботинок
От: Undying Россия  
Дата: 12.01.12 05:53
Оценка:
Здравствуйте, DarkGray, Вы писали:

DG>как минимум очевидна чуть другая формулировка:

DG>(при прочих равных) лучше тот язык, который позволяет записать решение меньшим кол-вом бит.

Лучше тот язык, который позволяет записать решение меньшим количеством сущностей. Биты здесь вообще не в тему.
Re[8]: Решение проблемы двух ботинок
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 12.01.12 07:04
Оценка:
Здравствуйте, konsoletyper, Вы писали:

M>>>>Для верификации очень маленького подмножества того, что код делает.

K>>>Зато это очень маленькое подмножество является очень благодатной почвой для ошибок.
N>>Из чего это следует?
K>Из опыта.

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

K> Кстати, по поводу ошибок. Тут уместно говорить не столько об автоматическом отлове ошибок, сколько о том, как снизить вероятность их возникновения и приблизить время их обнаружения к месту, где они реально возникли.


Спасибо, кэп (tm)

K> И тут уже вопрос не только о системе типов языка. Например, в том же C# есть нехорошая в этом смысле конструкция as, которую стараются избегать. Готов обсудить конкретные особенности конкретных языков, которые помогают или мешают легче обнаруживать ошибки.


А что в ней не так?

Я могу рассказать грабли только Python и Erlang. Ну ещё проругаться в общем на Perl. По отношению к остальным я не считаю себя вправе сейчас рассказывать что-то системное.

K>Вот вам пожалуйста динамически типизированный язык javascript. В нём, если неправильно набрать имя переменной, получим значение undefined.


Да, javascript — кошмарный ужас, причём не только из-за таких примеров. Тут в соседней ветке обсуждалось. Когда "5" + 3 == 53, но "5" — 3 == 2, авторов языка следует изгонять на Лабрадор. В нормальном языке неявные конверсии типов, такие, как между строкой и числом, должны быть запрещены.

Но не только с ним тут грабли. Я сейчас перечитываю "Рефакторинг" Фаулера. Там в начале есть пример ошибки в коде на Java, выловленной только тестом, от неявной конверсии double -> int.

K> Этот undefined может очень долго путешествовать по графу объектов, пока, например, кто-нибудь не попытается вызвать у него метод. В Ruby есть похожая штука, хорошо хоть в случае с локальными переменными это побороли.


Жуть.
The God is real, unless declared integer.
Re[9]: Решение проблемы двух ботинок
От: konsoletyper Россия https://github.com/konsoletyper
Дата: 12.01.12 11:35
Оценка:
Здравствуйте, netch80, Вы писали:

K>> И тут уже вопрос не только о системе типов языка. Например, в том же C# есть нехорошая в этом смысле конструкция as, которую стараются избегать. Готов обсудить конкретные особенности конкретных языков, которые помогают или мешают легче обнаруживать ошибки.


N>А что в ней не так?


В ней — это в конструкции as из C# или в чём-то другом. На всякий случай про C# (хотя это уже везде, где можно, обсуждали). При обычном касте (который синтаксически аналогичен оному из C) CLR кидает исключение, если объект не принадлежит к классу, что понятно описывает ошибку. Если же использовать as, то ошибка произойдёт только при попытке обратиться к null, который получится в результате. Это null может очень долго путешествовать по графу объектов, прежде чем у него решат чего-нибудь вызвать. Оно понятно, что для каждой конструкции есть своё применение, но вот процент случаев, когда благодаря as код становится короче, очень невелик. По крайней мере, он меньше процента вероятности получить ошибку по причине наличия as не по месту, потому я вообще не использую такие конструкции. И заставляю IDE на них громко материться.

K>>Вот вам пожалуйста динамически типизированный язык javascript. В нём, если неправильно набрать имя переменной, получим значение undefined.


N>Да, javascript — кошмарный ужас, причём не только из-за таких примеров. Тут в соседней ветке обсуждалось. Когда "5" + 3 == 53, но "5" — 3 == 2, авторов языка следует изгонять на Лабрадор. В нормальном языке неявные конверсии типов, такие, как между строкой и числом, должны быть запрещены.


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

По поводу конверсии. Конверсии число -> строка вполне допустимы. Ошибки, которые возникают из-за конверсии, вполне отлавливаются системой типов. Ну за исключением случаев, когда результат неявно приводится к вышестоящему типу (java.lang.Object, например). Ну а автоматическая конверсия строк во что угодно — действительно зло.

N>Но не только с ним тут грабли. Я сейчас перечитываю "Рефакторинг" Фаулера. Там в начале есть пример ошибки в коде на Java, выловленной только тестом, от неявной конверсии double -> int.


Наверное, из double в int. А можно пример?

K>> Этот undefined может очень долго путешествовать по графу объектов, пока, например, кто-нибудь не попытается вызвать у него метод. В Ruby есть похожая штука, хорошо хоть в случае с локальными переменными это побороли.


N>Жуть.


Да-да, это-то как раз и есть жуть, а не какая-нибудь штука вроде положительного и отрицательного нулей или проблем с бесконечностями и NaN.
Re[10]: Решение проблемы двух ботинок
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 12.01.12 18:06
Оценка:
Здравствуйте, konsoletyper, Вы писали:

K>>> И тут уже вопрос не только о системе типов языка. Например, в том же C# есть нехорошая в этом смысле конструкция as, которую стараются избегать. Готов обсудить конкретные особенности конкретных языков, которые помогают или мешают легче обнаруживать ошибки.

N>>А что в ней не так?
K>В ней — это в конструкции as из C# или в чём-то другом. На всякий случай про C# (хотя это уже везде, где можно, обсуждали).

Моё знание C# недалеко ушло от helloworld.

N>>Да, javascript — кошмарный ужас, причём не только из-за таких примеров. Тут в соседней ветке обсуждалось. Когда "5" + 3 == 53, но "5" — 3 == 2, авторов языка следует изгонять на Лабрадор. В нормальном языке неявные конверсии типов, такие, как между строкой и числом, должны быть запрещены.

K>А вот это как раз не страшно. Страшно не неочевидное поведение языка — можно просто избегать конструкций, которые потенциально приводят к подобным ужасам.

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

K> Страшно, когда есть фича, без которой нельзя обойтись (например, локальные переменные), и которая содержит в себе бомбу замедленного действия.


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

K>По поводу конверсии. Конверсии число -> строка вполне допустимы.


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

K> Ошибки, которые возникают из-за конверсии, вполне отлавливаются системой типов.


В Javascript? Прц.

N>>Но не только с ним тут грабли. Я сейчас перечитываю "Рефакторинг" Фаулера. Там в начале есть пример ошибки в коде на Java, выловленной только тестом, от неявной конверсии double -> int.

K>Наверное, из double в int. А можно пример?

Основные строки из примера в книге:

int thisAmount = 0;
...
thisAmount += (each_getDaysRented() — 2) * 1.5;

объявление thisAmount должно было быть double вместо int.
И даже warning'а не выдало, насколько я понял автора, хотя в нормальном языке вообще не должно было скомпилироваться, ибо преобразование из плавучего типа в целый должно быть только явным с указанием необходимого действия (round, trunc, floor или ceil, и тех round'ов может быть несколько).

K>>> Этот undefined может очень долго путешествовать по графу объектов, пока, например, кто-нибудь не попытается вызвать у него метод. В Ruby есть похожая штука, хорошо хоть в случае с локальными переменными это побороли.

N>>Жуть.
K>Да-да, это-то как раз и есть жуть, а не какая-нибудь штука вроде положительного и отрицательного нулей или проблем с бесконечностями и NaN.

А при чём тут они? Это специфика предметной области (плавучка сама по себе уже предметная область, хоть и промежуточная), а не тараканы языка.
The God is real, unless declared integer.
Re[11]: Решение проблемы двух ботинок
От: konsoletyper Россия https://github.com/konsoletyper
Дата: 12.01.12 18:50
Оценка:
Здравствуйте, netch80, Вы писали:

N>>>Да, javascript — кошмарный ужас, причём не только из-за таких примеров. Тут в соседней ветке обсуждалось. Когда "5" + 3 == 53, но "5" — 3 == 2, авторов языка следует изгонять на Лабрадор. В нормальном языке неявные конверсии типов, такие, как между строкой и числом, должны быть запрещены.

K>>А вот это как раз не страшно. Страшно не неочевидное поведение языка — можно просто избегать конструкций, которые потенциально приводят к подобным ужасам.

N>Их тут невозможно избежать. Достаточно получить в аргументах или в пришедшем с сети неожиданный тип данных, и проблема будет замаскирована.


Вот-вот. А в Java, например, если это какой-нибудь JAXB, то все "неожиданные типы данных" отловятся автоматом, без лишних проверок в коде (которые вручную можно и забыть проставить).

N>Опечатки в локальных переменных ловятся на одном первом проходе теста, неважно, ручного или

N>автоматизированного.

Кстати, а для динамически типизированных языков бывают code coverage tools? Или проверка того факта, что весь код покрыт тестами, есть только на честном слове?

K>>По поводу конверсии. Конверсии число -> строка вполне допустимы.


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


Ну так оно и ясно, что компилятор не телепат и заранее не знает, в каком формате выводить числа. А вот, например, для логгирования это очень удобно. И эффект очень даже предсказуемый: сложили число со строкой, получили строку, ибо неявное преобразование возможно только из числа в строку. Но это только в нормальных языках, где обратного неявного преобразования не существует. А в JavaScript, да, всё очень неожиданно.

K>> Ошибки, которые возникают из-за конверсии, вполне отлавливаются системой типов.


N>В Javascript? Прц.


Так я и высказался по поводу системы типов в контексте защиты статической типизации. В Javascript её нет, потому получаются вот такие вот внезапности. А была бы статическая типизация — проблем не было бы.

N>Основные строки из примера в книге:


N> int thisAmount = 0;

N> ...
N> thisAmount += (each_getDaysRented() — 2) * 1.5;

N>объявление thisAmount должно было быть double вместо int.

N>И даже warning'а не выдало, насколько я понял автора, хотя в нормальном языке вообще не должно было скомпилироваться, ибо преобразование из плавучего типа в целый должно быть только явным с указанием необходимого действия (round, trunc, floor или ceil, и тех round'ов может быть несколько).

Не верю!

K>>Да-да, это-то как раз и есть жуть, а не какая-нибудь штука вроде положительного и отрицательного нулей или проблем с бесконечностями и NaN.


N>А при чём тут они? Это специфика предметной области (плавучка сама по себе уже предметная область, хоть и промежуточная), а не тараканы языка.


А при том, что ругатели JavaScript часто ругают эти моменты, не обращая внимания на большую беду с локальными/глобальными переменными и undefined'ами.
Re[6]: Решение проблемы двух ботинок
От: Undying Россия  
Дата: 13.01.12 10:33
Оценка:
Здравствуйте, DarkGray, Вы писали:

U>>Лучше тот язык, который позволяет записать решение меньшим количеством сущностей. Биты здесь вообще не в тему.


DG>есть два количества сущностей:

DG>количество сущностей в алфавите (в наборе понимаемых сущностей),

Это не сущности, а количество синтаксических конструкций в языке. Речь не о них.

DG>количество символов(сущностей) в записи решения.


Это тоже не то.

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

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

DG>ты сейчас о каком из них?

DG>если минимизировать первое — то лучшим ЯП становится: машина тьюринга, там всего две сущности в алфавите: 0 и 1

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

DG>если минимизировать второе — то лучшим ЯП становится: ЯП с бесконечным алфавитом, когда все программы записываются одним символом из этого алфавита.


Здесь получается одна сущность, но с огромным весом, соответственно вместо упрощения получается усложнение.
Re[7]: Решение проблемы двух ботинок
От: Undying Россия  
Дата: 13.01.12 10:41
Оценка:
U>Естественно когда речь идет о минимуме количества сущностей, то не нужно понимать это как примитивное определение количества. Сущности разного рода могут иметь кардинально отличающийся вес, например, сеттер для объекта с большим временем жизни может быть много дороже десятка геттеров. Соответственно понятие количества включает в себя веса сущностей.

Т.е. количество сущностей измеряется не в штуках, а в неких единицах сложности. Аналогично тому как, к примеру, количество капитала измеряется не в штуках заводов, домов и тапочек, а в деньгах.
Re[12]: Решение проблемы двух ботинок
От: FR  
Дата: 14.01.12 11:27
Оценка:
Здравствуйте, konsoletyper, Вы писали:

K>Кстати, а для динамически типизированных языков бывают code coverage tools?


Конечно, например для питона http://nedbatchelder.com/code/coverage/

K>Или проверка того факта, что весь код покрыт тестами, есть только на честном слове?


Все вменяемые тестовые системы для того же питона позволяют запускать и проверку покрытия
параллельно с тестами. Тоже и IDE'шки http://pydev.org/manual_adv_coverage.html
Re[9]: Решение проблемы двух ботинок
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 15.01.12 19:52
Оценка:
DG>>1. Должны ли сущности записи совпадать с сущностями логики решения?

U>Разумеется. Иначе нам придется делать двойную работу. Вначале придумывать решение в голове, а затем неочевидным образом транслировать его в код.


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


DG>>2. Должны ли сущности исполнения совпадать с сущностями логики решения?


U>Нужно для удобства отладки.


а для эффективности исполнения?


DG>>3. Что такое вес логической сущности? И как его можно измерить или вычислить?


U> Потому что при традиционном методе программирования информация в программе дублируется множество раз. ... в дублировании состояния.


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

U>Если же мы с помощью автоматических кэшей и LazyMaker'ов ..

U> Соответственно изменение состояния становится тривиальной операцией, не вносящей дополнительной сложности.

при большом кол-ве "выходов"(text-box-ы, экраны, подписки других систем и т.д.) появляется задача отслеживания, какие выходы необходимо пересчитать на основе текущих изменений, и эта задачи не тривиальная


DG>>4. Можно ли выделить какие-то базовые сущности? Что это за сущности?


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


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

и при оперировании информацией абстракции часто решают задачи уменьшения кол-ва информации, которым приходится оперировать в ряде конкретных задач.
как это измерять?
Re[10]: Решение проблемы двух ботинок
От: Undying Россия  
Дата: 16.01.12 11:59
Оценка:
Здравствуйте, DarkGray, Вы писали:

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


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

DG>>>2. Должны ли сущности исполнения совпадать с сущностями логики решения?

U>>Нужно для удобства отладки.
DG>а для эффективности исполнения?

Аналогично первому пункту.

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


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

DG>при большом кол-ве "выходов"(text-box-ы, экраны, подписки других систем и т.д.) появляется задача отслеживания, какие выходы необходимо пересчитать на основе текущих изменений, и эта задачи не тривиальная


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

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


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

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

DG>как это измерять?

Первый вид сложности — это количество сущностей (как хранимых, так и разновидностей).
Второй вид сложности — это количество степеней свободы сущности. Например, readonly объект имеет меньше степеней свободы, чем модифицируемый объект, и соответственно проще.

В некоторых случаях снижение сложности второго рода приводит к увеличению сложности первого рода. Однозначного ответа когда это оправдано нет, надо рассматривать конкретные [группы] случаев.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.