о языках программирования
Dec. 21st, 2004 04:22 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
avva«Смолток просто-напросто непрактичен» — пишет ![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif)
dz, наряду с другой ерундой, в своём сравнении Джавы и Смоллтока. Видно, что он просто не очень хорошо понимает, какая это качественная разница — действительное динамическое ООП — если думает, что «есть reflection API, который все ПРАКТИЧЕСКИЕ задачи - решает». Конечно, все практические задачи, которые могут возникнуть в системе, спроецированной статически, он решает, а другие задачи человеку, не понимающему Смоллток и динамическое ООП, и в голову не придут.
Мне это, впрочем, напомнило тему «супер-языков», о которой приходилось иногда размышлять. Под этим я понимаю вот что: иногда бывает так, что поклонники какого-то языка программирования утверждают, что использование их языка позволяет повысить эффективность написания тех или иных сложных программ в несколько раз (а то и больше). Вообще-то подобные утверждения то и дело высказывают поклонники чуть ли не любого языка программирования, но обычно их не стоит воспринимать всерьёз. Но это не значит, что такое в принципе невозможно, с другой стороны.
Как-то это сумбурно звучит, поэтому попробую зайти с другой стороны. Ясно, что есть области применения, в которых некоторые языки подходят куда лучше других. Ясно, что программисты разнятся по своим способностям, качеству и скорости работы, эффективности результата, и прямое сравнение тут невозможно. Если мы учтём все эти «ясно» и попытаемся всё же вынести из за скобки, останется ли внутри что-то объективное, зависящее от языка? И если останется, насколько оно влиятельно?
Во мне, когда я думаю об этом, борются два противоположных хода мысли. С одной стороны, мне хочется сказать, что язык и его особенности часто переоценивают. В конечном итоге всё решает сложность поставленной задачи, переходящая в сложность работы программиста, решающего эту задачу. Язык программирования как бы стоит посредине этого перехода, «амортизируя» часть сложности задачи и принимая её на себя; но использование разных языков хоть и меняет качество этой амортизации, но не слишком значительно, не во много раз. Использование очень разных языков программирования, основанных на разных подходах, может давать преимущество в тех или иных удобных для решения этими подходами задачах; но в случае, если таких удобств или специальных требований нет, их эффективность примерно одинакова, есть только иллюзия особенной эффективности того или иного языка, появляющаяся у программиста, который очень хорошо его знает, привык, притёрся к нему, и действительно для него лично он быстрее и эффективнее всего остального.
С другой стороны, мне хочется сказать, что всё наоборот. Метафора амортизации несостоятельна, т.к. не отражает тот факт, что, глядя на одну и ту же задачу с точки зрения очень разных языков и подходов к программированию, мы видим совершенно разные вещи, и исходная сложность поставленной задачи не является чем-то неизменным, она навязана нам тем взглядом, к которому мы привыкли; при смене языка/взгляда/подхода может оказаться, что всё стало во много раз легче, и это не какой-то особенный случай, вызванный специальными обстоятельствами исходной задачи, а самое обыденное дело. И может оказаться, что какие-то языки с этой точки зрения особенно эффективны, т.е. очень хорошо знающий такой язык программист сможет в среднем работать значительно эффективнее, чем очень хорошо знающий другой язык программист тех же способностей, при работе над той же не-специальной задачей общего направления (естественно, такая точка зрения должна опираться на предположение о возможности определить «задачу общего направления» и «примерно тех же способностей» так, чтобы не впасть в замкнутый круг, и, действительно, неочевидно, что можно это сделать).
В общем, я лично сохраняю скептицизм по этому поводу, и первая из вышеописанных точек зрения в целом побеждает во мне вторую. Ко второй, тем не менее (и вообще к теме разных подходов к программированию, и тому, насколько такие подходы влияют на результаты и эффективность работы программиста) сохраняется живой интерес. Так вот, наиболее убедительные и подтверждённые фактами претензии на особую эффективность любимого языка, которые мне приходилось встречать, проистекали из среды поклонников двух языков: Смоллток и Форт. Не знаю, почему именно эти два, возможно, это больше случайность моего личного знакомства с языками, программистами, и различными сетевыми обсуждениями этой темы, чем какая-то объективная реальность; и, как я написал выше, я вовсе не уверен в том, что такие претензии основаны на чём-то реальном. Но любопытно отметить, что общего в этих двух языках (вообще-то очень разных): именно концептуальная чистота языка («всё — объект» или «всё — макро») и ещё я бы отметил интеграцию языка внутри интерактивной системы, полностью написанной на этом же языке, что-то вроде мини-ОС для языка.
dz, наряду с другой ерундой, в своём сравнении Джавы и Смоллтока. Видно, что он просто не очень хорошо понимает, какая это качественная разница — действительное динамическое ООП — если думает, что «есть reflection API, который все ПРАКТИЧЕСКИЕ задачи - решает». Конечно, все практические задачи, которые могут возникнуть в системе, спроецированной статически, он решает, а другие задачи человеку, не понимающему Смоллток и динамическое ООП, и в голову не придут.Мне это, впрочем, напомнило тему «супер-языков», о которой приходилось иногда размышлять. Под этим я понимаю вот что: иногда бывает так, что поклонники какого-то языка программирования утверждают, что использование их языка позволяет повысить эффективность написания тех или иных сложных программ в несколько раз (а то и больше). Вообще-то подобные утверждения то и дело высказывают поклонники чуть ли не любого языка программирования, но обычно их не стоит воспринимать всерьёз. Но это не значит, что такое в принципе невозможно, с другой стороны.
Как-то это сумбурно звучит, поэтому попробую зайти с другой стороны. Ясно, что есть области применения, в которых некоторые языки подходят куда лучше других. Ясно, что программисты разнятся по своим способностям, качеству и скорости работы, эффективности результата, и прямое сравнение тут невозможно. Если мы учтём все эти «ясно» и попытаемся всё же вынести из за скобки, останется ли внутри что-то объективное, зависящее от языка? И если останется, насколько оно влиятельно?
Во мне, когда я думаю об этом, борются два противоположных хода мысли. С одной стороны, мне хочется сказать, что язык и его особенности часто переоценивают. В конечном итоге всё решает сложность поставленной задачи, переходящая в сложность работы программиста, решающего эту задачу. Язык программирования как бы стоит посредине этого перехода, «амортизируя» часть сложности задачи и принимая её на себя; но использование разных языков хоть и меняет качество этой амортизации, но не слишком значительно, не во много раз. Использование очень разных языков программирования, основанных на разных подходах, может давать преимущество в тех или иных удобных для решения этими подходами задачах; но в случае, если таких удобств или специальных требований нет, их эффективность примерно одинакова, есть только иллюзия особенной эффективности того или иного языка, появляющаяся у программиста, который очень хорошо его знает, привык, притёрся к нему, и действительно для него лично он быстрее и эффективнее всего остального.
С другой стороны, мне хочется сказать, что всё наоборот. Метафора амортизации несостоятельна, т.к. не отражает тот факт, что, глядя на одну и ту же задачу с точки зрения очень разных языков и подходов к программированию, мы видим совершенно разные вещи, и исходная сложность поставленной задачи не является чем-то неизменным, она навязана нам тем взглядом, к которому мы привыкли; при смене языка/взгляда/подхода может оказаться, что всё стало во много раз легче, и это не какой-то особенный случай, вызванный специальными обстоятельствами исходной задачи, а самое обыденное дело. И может оказаться, что какие-то языки с этой точки зрения особенно эффективны, т.е. очень хорошо знающий такой язык программист сможет в среднем работать значительно эффективнее, чем очень хорошо знающий другой язык программист тех же способностей, при работе над той же не-специальной задачей общего направления (естественно, такая точка зрения должна опираться на предположение о возможности определить «задачу общего направления» и «примерно тех же способностей» так, чтобы не впасть в замкнутый круг, и, действительно, неочевидно, что можно это сделать).
В общем, я лично сохраняю скептицизм по этому поводу, и первая из вышеописанных точек зрения в целом побеждает во мне вторую. Ко второй, тем не менее (и вообще к теме разных подходов к программированию, и тому, насколько такие подходы влияют на результаты и эффективность работы программиста) сохраняется живой интерес. Так вот, наиболее убедительные и подтверждённые фактами претензии на особую эффективность любимого языка, которые мне приходилось встречать, проистекали из среды поклонников двух языков: Смоллток и Форт. Не знаю, почему именно эти два, возможно, это больше случайность моего личного знакомства с языками, программистами, и различными сетевыми обсуждениями этой темы, чем какая-то объективная реальность; и, как я написал выше, я вовсе не уверен в том, что такие претензии основаны на чём-то реальном. Но любопытно отметить, что общего в этих двух языках (вообще-то очень разных): именно концептуальная чистота языка («всё — объект» или «всё — макро») и ещё я бы отметил интеграцию языка внутри интерактивной системы, полностью написанной на этом же языке, что-то вроде мини-ОС для языка.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2004-12-21 06:10 pm (UTC)Я не буду искать case study с сравнением килострок (да и пользы от них)? Объяснять, почему (ну, к примеру) edit-n-continue в Смоллток увеличивает удобство работы - тоже не выйдет, потому что не имеющие такого механизма и не нуждаются в нем. И не знают о нем.
Пойдем иначе и возьмем статистику. Утверждение "Смоллток ощутимо эффективнее для программиста" поддерживают:
1) Программисты, писавшие на C++/Java, и ушедшие на Смоллток
2) Программисты на Смоллток, волей судеб и начальства вынужденные сейчас писать на Java/C++
Вместе с тем, с этим утверждением обычно спорят все, Смоллтоком серьезно не занимавшиеся (знакомство на уровне основ языка не считаем. В любом случае, Смоллток - это в первую очередь культура программирования).
Вместе с тем, мы наблюдаем огромное количество споров Java vs C++, Java vs C# и т.д. - причем обе спорящие стороны, как правило, разбираются и в том, и другом. Т.е. в целом наблюдается забавная картина: если взять умного и хорошего программиста что на С++, что на Java (я специально беру "близкие" по применению ОО-языки, играющие в одной нише), и обучить его Смоллтоку, то он в 95% становится его апологетом. Подобные цифры вряд ли можно увидеть в случае перехода на Java/С++. И это не Форт, который еще может "понравится/не понравится". И не LISP. Это слишком иные миры - Смоллток же побеждает в своей нише.
Эффективность Смоллтока почему-то лучше всего ощущается пост-фактум, "заранее" в ней убедить сложно; возможно, моя недостаточная некомпетентность и недостаток опыта тому виной, но похожие споры я вижу уже столько раз..
--
Почему никто не использует Смоллток? Потому что о нем не знают. Почему не знают? Маркетинг хреновый. Ему не повезло - как не повезло OS/2 и Бетамакс. Тут нет никаких вопросов. Лучшие побеждают далеко не всегда.
Мой-то problem в другом: хорошим хочется делиться, поэтому мне приятно заронить в кого-нибудь (не в тебя, это уже не выйдет :) сомнения в том, что Java и C++ - единственные приемлимые решения для разработки (в общем случае).
Так что, если кратко, Смоллток - это красота и эффективность разработчика (а уж последнее разбивается на кучу "случаев" и "подслучаев")
--
А что ты ждал? Я скажу, что на Смоллтоке лучше всего писать.. ээ.. текстовые редакторы? Или военные симуляции? Это был бы удар по языку - он претендует на бОльшее - и при этом играет на том же поле, что и С++/C#/Java.
no subject
Date: 2004-12-21 07:21 pm (UTC)Нет, блин, я офигеваю.
МУЖЧИНА. Это у вас ДЕТСКИЙ МАКСИМАЛИЗМ. От него надо избавляться.
Смоллток у меня стоял на машине ещё когда она была IBM PC AT с двумя мегабайтами.
Некоторые вещи, которые ты вчера узнал и которые кажутся тебе откровением и которыми хочется поделиться - тривиально другими людьми пройдены. Просто пройдены и всё. Я тоже бегал от него по потолку, да. Ну я уже отбегался.
Это неправда, что ему просто не повезло. То есть - да, могло больше повезти, могло. Но говорить "в сане сидят идиоты, вложили бы они свои бабки в Смолток - было бы круто" - это чистое детство в жопе. Если бы у тебя были таке деньги, ты бы знал, почему их надо вложить в яву, а не в смолток.
Коротко - потому что с Явой есть хоть какой-то шанс вернуть инвестиции, а со Смолтоком - почти никакого. Да, маркетинг - это сильный механизм, но (Я ЭТО ГОВОРИЛ, ТЫ ПРОСТО НЕ ХОЧЕШЬ СЛЫШАТЬ) - Микрософт вложил в маркетинг Бейсика вряд ли меньше денег, чем Сан в маркетинг Явы. И - однако - ява выплыла, а бейсик - нет.
Это язык красивый, но непрактичный. Я эту примитивную фазу сказал уже раз сто. Им можно поделиться, некоторое количество людей в мире с него пропрётся - а большинство на это способных уже и пропёрлись. И - ВСЁ.
Да - наверняка где-то он вполне применим практически. Просто не везде.
Да - у IBM есть для него инструментарий. Но ты же никогда не согласишься с мыслью, что они сделали его по ошибке и теперь просто волокут свой крест. :) Я этого не утверждаю, но и так бывает.
Я совсем забыл про статическую типизацию - нельзя без неё жить на практике, НЕЛЬЗЯ. Кстати, я ровно в данный момент рздумываю, как на VM Smalltalk-стиля аккуратрно на уровне компайлера привинтить статик тайпчек. Есть идеи? Чтоб и динамику не убить, и вообще.
no subject
Date: 2004-12-21 07:31 pm (UTC)Я ни разу не сказал, что там сидят идиоты. Более того, я, вероятно, тоже вложился бы Java из чисто коммерческих соображений. Потому что Смоллток проиграл не тогда, когда появилась Ява. К этому времени мы уже имели industry standard в виде C/C++. Проиграл он чуть раньше, боюсь.
"Коротко - потому что с Явой есть хоть какой-то шанс вернуть инвестиции, а со Смолтоком - почти никакого. Да, маркетинг - это сильный механизм, но (Я ЭТО ГОВОРИЛ, ТЫ ПРОСТО НЕ ХОЧЕШЬ СЛЫШАТЬ) - Микрософт вложил в маркетинг Бейсика вряд ли меньше денег, чем Сан в маркетинг Явы. И - однако - ява выплыла, а бейсик - нет"
Это VisualBasic-то не выплыл?
"Я совсем забыл про статическую типизацию - нельзя без неё жить на практике, НЕЛЬЗЯ"
(*заинтересовано*) почему? нет, правда?
P.S. я понимаю, что это может выглядеть как максимализм в моем случае, но почему (а я писал об этом) на Смоллтоке пишут С НУЛЯ (т.е. это не legacy) свои системы крупные компании вроде Боинга, JPМорган'a и AMD?
no subject
Date: 2004-12-21 08:20 pm (UTC)вы несёте херню.
извините, конечно.
no subject
не Вы, а
no subject
Date: 2004-12-22 06:23 am (UTC)no subject
Date: 2004-12-21 08:47 pm (UTC)Про статическую типизацию:
Отлов ошибок на этапе компиляции важен для коммерческого софта. Чтобы поймать ошибку нужно сообщить компайлеру избыточную информацию. Тогда он сможет сопоставить и указать на нестыковки. Типы - достаточно удобная для этого сущность. Она - да! - избыточна, но интуитивно понятна и (обычно) проста.
no subject
Date: 2004-12-22 01:01 am (UTC)Такое вроде бы появляется в PHP5: опциональный контроль типов, но там о "статическом" сложно говорить :)
no subject
Date: 2004-12-22 08:03 am (UTC)no subject
Date: 2004-12-22 11:03 am (UTC)Почему бы не сделать анализ в первую очередь статическим, до (и помимо) всякого исполнения? Наложим на некоторые места графа программы ограничения, пройдёмся по возможным путям выполнения (всё равно проходим, чтобы обнаружить dead code, etc) и посмотрим, нет ли где нарушения, т. е. противоречивых ограничений. При желании выдадим warning-и, если где-то вдруг ограничение ослабляется, а потом опять ужесточается (мол, не дырка ли?). Это позволит типизировать *некоторые* пути передачи данных, статически доказать, что в указанных местах у нас будут указанные типы.
А в рантайме этого проверять не будем. Т. е. при желании можно эти ограничения превратить в assert-ы, но зачем, если мы до исполнения *доказали*, что типы будут всегда какие надо?
Аналогия: generics в Java 1.5. В runtime ничего не проверяется (и из RTTI про прототипы ничего не узнать), но при компиляции конкретизирующие типы проверены, и можно не сомневаться (в пределах доверия к компилятору), что ошибки приведения типов не будет.
Только в случае конкретно питона это потребует сильного расширения транслятора, который будет вынужден сначала проходить по всем модулям (импортируемым так и этак) и сверять ограничения типов и сами типы (которые там зело гибки). В случае smalltalk-а всё будет ещё хуже, вероятно, поскольку там компиляция вообще слабо отделена от исполнения (можно всё править на лету) -- интересно, как эта проблема решена в strongtalk-е (вчера впервые о нём услышал).
В общем, штука в том, что статическая типизация предполагает законеченность кода на момент проверки и создание "snapshot"-а, о котором точно известно, что статические проверки пройдены. А динамическая природа скриптовых языков с этим трудно совместима.
no subject
Date: 2004-12-23 11:25 am (UTC)Пример с type elimination неплох, только от этой аналогии до сколько-нибудь работающего решения - пропасть. Видимо поэтому никто еще и не пересек ;-)
no subject
Date: 2004-12-22 11:56 pm (UTC)no subject
Date: 2004-12-23 09:35 am (UTC)Про PHP5 потому, что там *опциональный* контроль типов, хоть и не статический.
no subject
Date: 2004-12-22 06:23 am (UTC)Для низкоуровневых языков это критично, да. Что бы в однобайтовый char не положить четырехбайтовый long. А для достаточно высокоуровневых этой проблемы не существует.
Более того, все типизированные языки подсознательно пытаются от этой типизации смыться. И рождаются либо монстры типа шаблонов, либо "значительное" ослабление типизации через неявную конвертацию типов и void *.
no subject
Date: 2004-12-22 07:48 am (UTC)Все остальные операции предполагают знание типа. Никакой метод, кроме вещей типа stack.push не принимает объекты любого типа. По определению.
no subject
Date: 2004-12-22 02:36 pm (UTC)Во многих случаях очень приятно формально (автоматическим анализом кода) подтвердить тот факт, что на всех возможных путях исполнения программы некоторые объекты гарантированно ответят на некоторые сообщения (в отличие от кидания DoNotUnderstand). Напарываться портм на такое в runtime и искать источник -- очень неприятное занятие.
no subject
Date: 2004-12-22 04:21 pm (UTC)Но проблема решается, на мой взгляд, не типизацией, а юнит-тестами (в т.ч. и функциональными).
(если серьезно)
Date: 2004-12-21 07:37 pm (UTC)Но народ собрал кучу голосов, написали петицию, и спустя несколько лет боданий Сан все-таки выложил это для free download.
Там, кстати, из интересных идей еще и mixin's - как вариант реализации множественного наследования.
Довольно интересная штука.
no subject
Date: 2004-12-22 06:20 am (UTC)Ты говоришь, что это красивый, но академический и непрактичный язык.
Я говорю, что это не только красивый, но и весьма практичный язык, который МОЖНО и НУЖНО применять на практике - как минимум потому, что это может дать преимущество перед коллективами, работающими на C++/Java. Язык современный, полноценный, с развитыми средствами разработки и библиотеками.
no subject
Date: 2004-12-23 11:17 am (UTC)Ух! Ваши слова да Богу в уши. Сан когда-то обещал выслушать все советы по модификации и языка и машины. Но то ли советов не было, то ли они были слишком радикальными (типа, отказаться от стековой машины - она очень неудобна для JIT), но они ее трогать боятся. У вас ситуация проще - нет паблик релиза, нет проблем такого масштаба.
По делу: вам придется возиться с полиморфными системами типов. Это очень неприятно, поскольку система должна быть с одной стороны разрешимой (то есть, тайпчекер не зациклился), с другой - достаточно гибкой. Такие системы есть - примеры: Хаскель, МЛ, система темплейтов в Си++. Но чтобы их адекватно реализовывать, надо теорию рассекать хорошо, а мне, например, это всегда было делать лень. Есть и неразрешимые системы - не гарантировано, что тайпчекер не зациклится, но показано, что люди не настолько извращены, чтобы смочь такие конструкции писать ;-) Пример - Cayenne.
Проблема номер 2: чтобы совсем не разрушить динамичность, придется реализовывать эффективный динамический диспатч. Это тоже сделано с помощью position in-line cache (PIC) в языке Self. Не везде применимо, правда. Особенно на процессорах с большим кешем и длинным пайплайном.
Статик тайпчек нужен в основном для эффективности (чтобы коды статического качества генерить), не для надежности. Брюс Экель, написавший Thinking in C++ и Thinking in Java а теперь полный Питоновский конверт (в смысле, уверовал человек) про это где-то написал. Если интересует, и есть время читать статьи, я ссылку найду.
Опять же, если есть время и желание, могу найти ссылку на Обероновские разработки по гибким и надежным системам JIT.
А вообще - успехов. Найдете как с практической стороны все это реализовать, поделИтесь методикой.
no subject
Date: 2004-12-23 12:21 pm (UTC)