Здравствуйте, 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.
Здравствуйте, мыщъх, Вы писали:
>> нет, пусть машина думает за меня и ловит все случаи присвоения чего-то иного, она быстрая. М>не вопрос. в динамических языках при желании программиста в момент присвоения переменной вызывается определенная программистов функция. и эта функция может обрабатывать ситуацию по тому или иному сценарию. а в языках со статической типизаций звиздец полный. особенно в си, у которого функцию можно объявить как int foo(), а реализовать как float foo(). и у вызывающего кода нет никакой возможности определить тип, а контролировать валидность декларации очень затруднительно, особенно если это функция из динамической библиотеки.
Может не стоит приводить в пример язык со статической, но слабой типизацией?
Здравствуйте, Tilir, Вы писали:
T>Речь идёт о том что программирование это инженерная дисциплина в которой нельзя что-то получить чем-то не заплатив.
T>Получаете скорость разработки -- платите объёмом кода,
Чего?
T>получаете высокоуровневые примтивы -- платите быстродействием и так далее.
Ой, не факт.
Если мы имеем дело с ДСЛ, то мы получаем примитивы предельно высокого уровня для данной задачи.
При этом за счет предметно ориентированных оптимизаций и предметно ориентированной кодогенерации мы получаем такое быстродействие, что руками гоняться вспотеешь.
Это я тебе говорю как человек, который по уши в ДСЛях.
T>Без вариантов.
Это по тому, что ты только языки общего назначения рассматриваешь.
А они все неадекватны. Просто по тому, что они общего назначения.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, мыщъх, Вы писали:
К>Может не стоит приводить в пример язык со статической, но слабой типизацией?
хорошо, давайте возьмем другой язык. и 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.
24.12.11 10:03, netch80 написав(ла): > Здравствуйте, Tilir, Вы писали: > T>Речь об этом, а не о C и не о его сравнении с Лиспом пусть они оба будут здоровы. Чтож всех так на холивор тянет > А кто первый начал-то? Если бы Вы просто разрекламировали книгу, то вопроса бы не было. Но Вы начали с бессмысленного наезда на другие языки вообще и особенно на LISP, и породили замечательный holy war. Теперь разбирайте последствия.
Хм. Я-то это прочитал как не «начал», а «закончил». Как призыв не вести холивары о том, какой язык лучше. А для этого нужно понимать, что у каждого языка есть слабые стороны. И в разных контекстах те или иные сильные и слабые стороны важнее.
Здравствуйте, мыщъх, Вы писали:
N>> Ну не скажи. Если я вот хочу, чтобы в данной переменной было только целое число и ничего иного, это от нищеты хардвера? М>а что вам мешает? берем жабу скрипт. в нем какая типизация? уж точно не статическая. между тем, создать... эээ.... "переменную" (в вашей терминологии) в которой могло бы быть только целое число проще простого. при вызове "foo = 3.3" вызвается опеределенная нами функция, которая смотрит на число, видит, что оно не целое и обрабатывает ситуацию по тому или иному сценарию.
Значит, проверка на этапе выполнения. Которая или сказывается уже на пользователях, или требует функционального теста с эмуляцией выполнения целевого кода, и этот тест с эмуляцией надо писать, на что затраты больше (потому что надо ещё грамотно написать тест и проверить его), чем в случае, если бы детект некорректного присвоения был сделан на компиляции. Крис, Вы тупо баяните. И я баяню общеизвестными доводами в ответ. Это тут обсуждалось уже столько раз, что уже начинает тошнить от повторения. Опознание проблемы на компиляции (если описание типа не требует существенных затрат времени) всегда значительно дешевле, чем при выполнении, даже в тестировании, и это просто смешно уже повторять.
М>кстати, по поводу целых. извините, но тут вы сильно неправы. целое не есть тип. типы есть числа, индексы, указатели... целое как тип именно от бедности (хардверной). в чем кайф от разнесения целых и вещественных по разным типам?
Кайф в том, что мы гарантируем определённые свойства присвоенного значения и избавляемся от проблем, которые могли бы быть в случае какого-то другого значения. Целое — это не панацея, но базовый кирпич. В конкретном случае это может быть просто целое (если облом уточнять), целое из интервала от 0 до 999, целое из интервала от -45 до +55, целое из набора -38 и 97 (и никаких других) и так далее. Наконец, целое — это предельно простое и понятное минимально образованному системному программисту отображение используемого железом набора битовых значений. Да, можно согласиться, что всё это от бедности, но в пределах этой бедности интерпретировать значения слов, например, как float — заведомо менее удобно людям, чем как int. А если требовать от значений соответствия типу, у которого установлено множество и/или интервал значений, получится просто и внятно.
M> тем более, что вещественные включают в себя целые? типы пряшут от машинных, а не математических понятий именно в силу проблем эффективности хардверной реализации. в идеале, язык должен предоставлять: натуральные, рациональные, вещественные...
И почему в этом ряду пропущено целое, если Вы уж взялись перечислять математические типы? Там оно имеет колоссальное значение, важный этап между натуральными и рациональными, база для теории чисел, и так далее.
М>кстати, в си очень интересно определен тип индекс. который размер. то есть он индекс, но он размер. вот так. впрочем, это никого не парит, ибо им большинство все равно не пользуются, а потом переносят программу с 32 бит на 64 с матами. всякий раз когда вижу int вместо индекса -- меня реально коробит.
Тут вопрос не в размерности индекса как таковой, а в неявных конверсиях с потенциальной потерей значения. Потому в более современных языках это стараются ограничить. Вообще, такие неявные конверсии, или молчаливое целочисленное переполнение — адская проблема Си, и то, что нельзя сделать хотя бы что-то вроде шарпового checked(a+b), ужасно. А книга и автор треда считают, видимо, эту проблему несущественной? (В соответствующей главе только банальный трёп про неявные конверсии с расширением.)
>> нет, пусть машина думает за меня и ловит все случаи присвоения чего-то иного, она быстрая. М>не вопрос. в динамических языках при желании программиста в момент присвоения переменной вызывается определенная программистов функция. и эта функция может обрабатывать ситуацию по тому или иному сценарию. а в языках со статической типизаций звиздец полный. особенно в си, у которого функцию можно объявить как int foo(), а реализовать как float foo(). и у вызывающего кода нет никакой возможности определить тип, а контролировать валидность декларации очень затруднительно, особенно если это функция из динамической библиотеки.
Опять странное говорите. Библиотеке должен соответствовать хедер. Если его нет, то вообще компилировать нельзя. Если он есть, но не той версии, это должен контролировать пакетизатор. А что, если для того же имени в библиотеке изменится состав аргументов (что на практике значительно чаще, чем смена типа результата)?
М>динамические библиотеки в языках со статической типизацией выглядят чужаками.
В таком случае начните с того, что и динамическая память там якобы чужак — как же, могут неожиданно сделать free() на используемую область. В чём разница?
Здравствуйте, Tilir, Вы писали:
T>Здравствуйте, __lambda__, Вы писали:
В серьёзной разработке, два языка на проект -- перебор, три -- безумие. Хотя бы потому, что найти команду из десяти человек, знающих один и тот же язык (особенно если это язык C) -- легко. А вот найти, знающих три...
Утверждение крайне спорное.
У нас в виндах в последнее время три это фактически необходимый минимум, например: С++, C#, SQL. Уже три. Это если поддержиывать только одну базу данных, а не три в разных билдах, что встречается достаточно часто (сегментация рынка чтоб ее)
Это если не считать недоязыки типа HTML, XML, XSLT, которые уже везде.
Если пойти дальше, выясняется, что у серьезных проектов есть еще инсталляторы: WIX или nsis (свой язык).
И им нужно как-то собираться в один клик: а это либо shell, либо Scons (python) либо cmake — свой язык с блекджеком и, ну вы поняли.
Можно также вспомнить, что в некоторых местах до сих пор бывавает assembler, сам видел. Достаточно посмотреть внутрь cryptopp, например. Или если что-то где-то хукнуть надо.
Здравствуйте, мыщъх, Вы писали:
М>Здравствуйте, 0x7be, Вы писали:
0>>Здравствуйте, мыщъх, Вы писали:
М>>>статическая типизация она не от большого ума, а от нищеты хардвера. 0>>Можешь развить эту свою мысль? М>а ее надо развивать?
Надо. Персонально для 0x7be.
Может быть ты не знаешь, но 0x7be — молодой и талантливый парень.
Но молодой (массы вещей не знает) но талантливый (очень быстро учится).
Это он написал статью про предел высокоуровневости языка.
Так что уж удели время.
Здравствуйте, boot, Вы писали:
B>Здравствуйте, batu, Вы писали:
B>>С количеством слов не согласен. Теоретически все можно обозначить знаками.. Но разбираться в этой мешанине знаков будет совсем не просто. Это типа каста посвященных организуется. И потеряется вторая роль языка-общение. Важнее минимизация количества правил языка и базовых понятий. А уже сколько можно из этих правил определить понятий (они же слова) вопрос сорок пятый. Кстати, если не ограничивать длину слова, то вообще континуум получается. Частенько встречаю что количество фраз языка счетно. Это не правильно.
B>Вот это похоже на плодотворные рассуждения, а от философии, как говорит статистика, проку никакого. Чтобы что-то с чем-то сравнить, нужно сперва измерить и представить числом, и сравнивать числа напрямую связанные с измеряемым, а не число ботинок в аналогии
Видно что у вас с философией не очень. Измерить можно только счетное число. В этом и есть великая загадка диагонали квадрата. Ее невозможно представить числом.
Здравствуйте, мыщъх, Вы писали:
М>Здравствуйте, D. Mon, Вы писали:
DM>>Да чего тут спорить. Си — молодой и динамично развивающийся язык, он появился намного позже лиспа и учел опыт предшественников, исправил их ошибки. Исчезли эти тормозные и жрущие память списки и сборка мусора. Благодаря новым достижениям компиляторостроения появился синтаксис, статическая типизация. Это большие шаги вперед!
М>статическая типизация она не от большого ума, а от нищеты хардвера.
статическая типизация нужна для верификации кода на стадии компиляции.
Здравствуйте, __lambda__, Вы писали:
___>Кстати, справедливости ради, компиляторы Common Lisp'а генерят очень эффективный нативный код.
Скажем так. Иногда генерируют код сравнимый с эффективным. И почему речь о SBCL идет во множественном числе?
Реально код хорош только для Лиспов. Для любого плохенького С-компилятора такой код назову хреновым. Но главная проблема в том, что в Лиспе хватает проектных решений которые в принципе не позволяют получать высокопроизводительный код. Да начин писать на Лиспе в целях получения быстрого кода, и код будет даже хуже чем на С.
___>Да, но Си завоевал не весь мир, а мир системного низкоуровневого программирования.
Это сейчас так. А в 80-ых, например, он был полным мэйнстиром.
___>Это же не весь мир?
Я просто боялся, что меня обзовут Капитаном Очевидностью, если я буду к своим словам добавлять описание в стиле "обобщение" или "аллегория". Но, похоже, все же, надо.
На фоне популярности Лиспа и Висик супер-популярным языком покажется.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, netch80, Вы писали:
N>"Упрямый лисповед" будет спорить о другом — о том, какая доля задач реально требует гонки за "максимально эффективным кодом" в ущерб другим качествам, как та же возможность метапрограммирования. Слишком многие путают эти две цели.
Дык те кто используют С по делу, как раз и используют его для низкоуровневый задач (часто называемые системными).
Из высказывания автора книги, к сожалению не ясно что конкретно имелось в виду. Но возможно, что автор имел в виду, что лиспофил как раз демонстрировал языковые навороты в то время как задачей является работа с железом и памятью. В таком контексте навороты в области ФП и МП предлагаются как средство для улучшения написания драйверов устройств, то это действительно похоже на аллегорию с ботинком.
В прочем, возможно авто просто не шарит в Лиспе и от того гонит. Это кому как угодно. Один фиг из его слов никаких выводов сделать невозможно.
VD>>Если же взять метапрограммирование или поддержку ФП, то у С не будет шансов.
VD>>Критериев ведь масса. Скажем простота изучения средним человеком. Тут у лиспа тоже нет шансов. Именно по тому С завоевал мир, а Лисп остался уделом гиков.
N>Простота обучения тут ни при чём (она, BTW, для Лиспа выше, если сравнивать изучение с нуля, не обладая никакими знаниями по программированию).
Ваще не понял сказанного.
N>LISP "остался уделом гиков" потому, что его задачи дальше от тех целей, которые нужны "среднему человеку" из мира мелкой писюшатины.
Звучит не убедительно.
N>Поколение, которое выросло на том, что для любой задачи нужно знать свойства местной аппаратуры, дёргать за вызовы MS-DOS и BIOS (а то и напрямую к железу), не только требует для этого языки, в которых это возможно предельно естественным образом (как C или писюковые диалекты Паскаля),
Времена прерывания давно прошли, но ничего не изменилось.
N>но и создаёт поле искажения реальности, самой плотностью использования процедурных средств навязывая представление, что есть только они.
С этим можно согласиться. Только все равно это не объясняет непопулярности лиспа. Дело не только в это.
В те времена были ведь не только С, С++ и Обжет Дельфи с Турбо Борландом. Были еще ХБэйс, Клипер, Кларион и т.п., т.е. языки для бизнес-задач. Там то Лисп мог стрельнуть. Но вот и там он оказался неудел.
N>Новых генераторов этого поля искажения нет уже лет 10, и поэтому мы наблюдаем рост использования ФЯ — люди наконец-то начали замечать, что факторы, которые стимулируют использовать C, уже для них неактуальны.
Ну, назвать это ростом можно только с долей иронии. Скорее можно говорить о проникновении ФП в императивные мэйнстрим-языки. Но оно тоже очень вялое. Более того есть реальное и серьезное сопротивление. Но речь не об этом.
Речь о Лиспе. И о том почему он слил такому неразвитому С.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, 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
Здравствуйте, 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.
Здравствуйте, __lambda__, Вы писали:
VD>>Скажем так. Иногда генерируют код сравнимый с эффективным. И почему речь о SBCL идет во множественном числе?
___>Потому что, есть не только SBCL, а еще есть Clozure CL, Lispworks, Allegro CL, ...
Вот только когда речь заходит о скорости генерируемого кода, то почему-то все в SBCL тычут.
Почему?
VD>>На фоне популярности Лиспа и Висик супер-популярным языком покажется.
___>Вообще, оценивать на базе популярности, сомнительно. Сам же ведь говорил поначалу очень умно и трезво. Мол, нужна функция оценки. А тут мы скатились к банальной популярности. Ну тогда уж PHP венец творения человечества! А лучший певец это Филипп Киркоров.
А не надо фразы из контекста выдерать. Тогда все будет ОК.
Изначально я говорил "если сравнивать по критерию...". Про популярность заикнулся не я. Но это тоже вполне себе критерий по которому можно сравнить. Вопрос только в том, что это даст.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, мыщъх, Вы писали:
T>>Компилятор может быть маленьким не означает что он будет маленьким. М>"может быть маленьким" -- очень сомнительное достоинство языка, если таких компиляторов нет.
Здравствуйте, DarkGray, Вы писали:
B>>В этом и есть великая загадка диагонали квадрата. Ее невозможно представить числом.
DG>представить нельзя, но можно измерить с заданной точностью в виде двух граней
Я думаю разницу вы понимаете.
