О выразительности Smtalltak

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

О выразительности Smtalltak

sdfgh153
Идея с новой веткой действительно хороша, а то мне стыдно даже.
Продолжаем разговор!
 
Похоже, мы говорим о разных вещах. Что имелось ввиду под "выразительностью" я понял. Меня больше интересует выразительность в смысле "удобства выражать свои мысли". 
И здесь хорошо бы сравнить на основе "процедуры" принятия решений при программировании на том или ином языке. Когда очень давно (лет 10 назад, наверное) пробегала такая статейка по поводу C++ vs. Smalltalk.

Давайте тогда ещё больше локализуем вопрос процедуры. Входит ли сюда время на создание новой сущности (класса, метода)? Или только процесс выражения мыслей?
В первом случае у St действительно есть небольшой перевес за счет шикарнейшей "IDE" (специально в кавычках, чтобы исключить буквожорство :)
Код в Smtalltalk писать действительно удобно. Но к языку это особого отношения не имеет. Что касается обычной работы по реализации своих идей, я бы поспорил даже на уровне руби.
Что нужно сделать в St чтобы добавить локальную переменную? Вернуться в начало метода и добавить её в блок локальных переменных.
В руби ее можно просто начать использовать. Да, я знаю, что большинство смолтоков сами предложать определить переменную, но всё же.

В остальном, я повторюсь: я не вижу принципиальной разницы между St и Ruby, примеры кода я писал уже.

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

Не очень понимаю, что заставляет вас так думать, разверните мысль, пожалуйста? Продолжения испокон веку входят именно в язык.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу Russian Smalltalk User Group.
 
Чтобы отказаться от подписки на эту группу и перестать получать из нее сообщения, отправьте электронное письмо на адрес [hidden email].
Настройки подписки и доставки писем: https://groups.google.com/groups/opt_out.
Reply | Threaded
Open this post in threaded view
|

Re: О выразительности Smtalltak

Dennis Schetinin
До этого момента я не понимал, что речь именно и только о языке.

Относительно Smalltalk-а я не могу заставить и не хочу себя разделять язык и среду (не какую-то конкретную, а в ее потенциале). Язык — это способ выразить мысли. При кодировании сам по себе текст играет мало значения — важно сколько усилий мне приходится тратить на изложение своих мыслей. И среда вполне может компенсировать недостатки языка. Представленный пример это очень хорошо иллюстрирует. Конечно, Smalltalk до сих пор даже близко не подошел к реализации всего заложенного потенциала (а потенциал среды во многом определяется именно языком, кстати), но что могло бы быть (и не так уж сложно воплотить, кстати) — легко себе представить.

Как язык Smalltalk очень интересен (прежде всего своей гуманистичностью), но, конечно, не лишен недостатков. Причем, весьма существенных. Хотя подозреваю, что в вопросе о недостатках я несколько… оригинален что ли… В общем, как показывают предыдущие попытки обсудить их, тут я в меньшинстве. В общем, меня смущает, что синтаксис языка не минималистичен и нарушает некоторые базовые принципы (не всегда объектен). Но Ruby, насколько я знаю, в этом отношении еще хуже, причем значительно. 

По второму вопросу… Он мне не до конца ясен. Мне кажется почти очевидной мысль, что качество языка (а оно, пожалуй, определяется его выразительная мощью, к слову) есть отношение возможностей к сложности языка. Чем больше возможностей, тем лучше — это, наверное, обсуждать нет смысла. Чем проще, тем лучше — некоторые с этим будут спорить, но наверное не мы :)  Так что, "тупое" наращивание возможностей за счет введения новых ключевых слов и синтаксических конструкций (как это делается до сих пор в большинстве языков) не только не усиливает их выразительную мощь, а скорее уменьшает (впрочем, все субъективно, ибо точные числовые оценки зависят от выбранных метрик, разумеется).

Идея, что язык надо стараться сохранять неизменяемым, а все нужные фишки лучше реализовывать в библиотеке, нашла свое воплощение (как минимум — возможно и раньше) в Simula-67. До этого те же авторы сделали Simula (потом ее стали обозначать как Simula-I), который был надмножеством Alogol-а, который дополнили средствами описания имитационных моделей дискретных систем. А вот Simula-67 уже был сделан иначе: там Algol тоже пришлось расширять, но уже не конкретными фишками, а более общими механизмами, которые позволили реализовать те же средства моделирования уже не в языке, а в библиотеке.

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

Разумеется, все это — просто общие слова, если они не поддерживаются практикой. Но думаю авторы той же Simula руководствовались именно практическими аспектами: подозреваю, что Simula было сложно поддерживать, были сложности с обучением, популяризацией. В конечном итоге, "выстрелил" именно Simula-67. Думаю, не с проста — именно за счет своей на порядок большей выразительной мощи. Так что, наверное, это все-таки не просто общие рассуждения — за ними стоит практический смысл.

Та же история с континуациями наглядно это демонстрирует — с практической точки зрения, но чуть в другом аспекте (и, возможно, даже более важном): не было на тот момент континуаций в Ruby, и сообщество не могло себе позволить реализовать их — это потребовало бы (и, как я понимаю, потребовало) расширения языка — введения новой синтаксической конструкции. А в Smalltalk-е не понадобилось что-либо делать с языком, достаточно оказалось написать класс. Поэтому Seaside родился именно в Smalltalk-е, хотя его автор был Ruby-стом.

Отсутствие управляющих конструкций в Smalltalk-е — из той же оперы. Возможно, практические преимущества этого не очевидны, но красиво же! Да и есть они, наверняка, если подумать… :)



--

Best regards,


Dennis Schetinin



24 октября 2013 г., 10:02 пользователь Semyon Novikov <[hidden email]> написал:
Идея с новой веткой действительно хороша, а то мне стыдно даже.
Продолжаем разговор!
 
Похоже, мы говорим о разных вещах. Что имелось ввиду под "выразительностью" я понял. Меня больше интересует выразительность в смысле "удобства выражать свои мысли". 
И здесь хорошо бы сравнить на основе "процедуры" принятия решений при программировании на том или ином языке. Когда очень давно (лет 10 назад, наверное) пробегала такая статейка по поводу C++ vs. Smalltalk.

Давайте тогда ещё больше локализуем вопрос процедуры. Входит ли сюда время на создание новой сущности (класса, метода)? Или только процесс выражения мыслей?
В первом случае у St действительно есть небольшой перевес за счет шикарнейшей "IDE" (специально в кавычках, чтобы исключить буквожорство :)
Код в Smtalltalk писать действительно удобно. Но к языку это особого отношения не имеет. Что касается обычной работы по реализации своих идей, я бы поспорил даже на уровне руби.
Что нужно сделать в St чтобы добавить локальную переменную? Вернуться в начало метода и добавить её в блок локальных переменных.
В руби ее можно просто начать использовать. Да, я знаю, что большинство смолтоков сами предложать определить переменную, но всё же.

В остальном, я повторюсь: я не вижу принципиальной разницы между St и Ruby, примеры кода я писал уже.

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

Не очень понимаю, что заставляет вас так думать, разверните мысль, пожалуйста? Продолжения испокон веку входят именно в язык.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу Russian Smalltalk User Group.
 
Чтобы отказаться от подписки на эту группу и перестать получать из нее сообщения, отправьте электронное письмо на адрес [hidden email].
Настройки подписки и доставки писем: https://groups.google.com/groups/opt_out.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу Russian Smalltalk User Group.
 
Чтобы отказаться от подписки на эту группу и перестать получать из нее сообщения, отправьте электронное письмо на адрес [hidden email].
Настройки подписки и доставки писем: https://groups.google.com/groups/opt_out.
Reply | Threaded
Open this post in threaded view
|

Re: О выразительности Smtalltak

vmusulainen-2
In reply to this post by sdfgh153
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|

Re: О выразительности Smtalltak

Dennis Schetinin
In reply to this post by sdfgh153
Мелочь, конечно, но все-таки.

24 октября 2013 г., 10:02 пользователь Semyon Novikov <[hidden email]> написал:
В руби ее можно просто начать использовать. Да, я знаю, что большинство смолтоков сами предложать определить переменную, но всё же.


Буквально сегодня наткнулся на человека, который жаловался на то, что в Питоне (в отличие от Smalltalk-а) не надо объявлять переменные, и он постоянно "огребает" из-за того, что ошибаясь в написании переменной (fooo вместо foo), он "огребает" ненужные проблемы. По идее, среда должна такие вещи отслеживать, конечно.


--

Best regards,


Dennis Schetinin

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу Russian Smalltalk User Group.
 
Чтобы отказаться от подписки на эту группу и перестать получать из нее сообщения, отправьте электронное письмо на адрес [hidden email].
Настройки подписки и доставки писем: https://groups.google.com/groups/opt_out.
Reply | Threaded
Open this post in threaded view
|

Re: О выразительности Smtalltak

sdfgh153
In reply to this post by Dennis Schetinin
Привет,
Я долго сочинял ответ. На самом-то деле, по-существу, мне и возразить почти нечего.

Разве что возражу насчёт сред. Это для Smalltalk исторически сложилась ситуация, когда язык и среду можно разделить только насочиняв какой-нибудь GNU Smalltalk. Это большое, жирное исключение из правил. Так что все фишки IDE Smalltalk по-хорошему являются фишками языка, потому что иначе никак.

Я не хочу сказать, что это однозначно плохо, но мне больше нравится не зависеть от среды. Когда я пишу на Haskell, например, моя среда выглядит как Vim и консоль той операционной системы, где я нахожусь. И большего мне просто не надо, все те вещи, которые "по идее должна учитывать среда" учитывает язык.

Напомню ссылку на прекрасную статью: http://www.recursivity.com/blog/2012/10/28/ides-are-a-language-smell/

Да, язык должен быть простым в основе. Библиотеки, либо расширения должны строится из того же материала, из которого и сам язык. В этом смысле я абсолютно согласен, что тот же C# – сложный язык. Сложный именно потому, что в него напихано "фич", многие из которых выглядят будто примотаны изолентой. Такая сложность вредит.

Но есть сложность другого рода, которая не всегда однозначно вредна. Тот же хаскель — сложный язык, просто потому что там с пятой страницы учебника начинается лютый матан и теория категорий. Хотя на самом-то деле хаскель настолько же прост "в ядре" как и St, он даже проще для понимания, потому что он изначально математически верен. Но ядро языка очень простое: система типов Хиндли-Милнера + редукция лямбда-термов + ленивые вычисления. Всё, больше там нет ничего. Но там есть синтаксический сахар, много сахара. Он появляется там поверх абстракций, которые можно соорудить и без него. Его цель — не запутать, а упростить жизнь.

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

Вообще говоря, любой тьюринг-полный язык даёт возможность реализовать на себе что угодно, не только продолжения. А Руби, слава Богу, Тьюринг-полный :)

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

Хаскель практически их не содержит тоже, все вещи, которые не вписываются или сильно расширяют базу языка выносятся в Language Extensions, например шаблоны или "Kind polymorphism".

Кстати у Ruby есть реализация, которая может вас заинтересовать: http://en.wikipedia.org/wiki/Rubinius

Rubinius follows in the Lisp and Smalltalk traditions, by natively implementing as much of Ruby as possible in Ruby code.
It also has a goal of being thread-safe in order to be able to embed more than one interpreter in a single application.

Дальше, если говорить о синтаксисе Smalltalk, то он, безусловно прекрасен. Но не надо думать, будто нигде больше ничего такого нет :)
Во-первых Objective-C, во-вторых уж где-где, а в питоне точно есть Keyword Arguments (http://docs.python.org/release/1.5.1p1/tut/keywordArgs.html).

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


2013/10/24 Dennis Schetinin <[hidden email]>
До этого момента я не понимал, что речь именно и только о языке.

Относительно Smalltalk-а я не могу заставить и не хочу себя разделять язык и среду (не какую-то конкретную, а в ее потенциале). Язык — это способ выразить мысли. При кодировании сам по себе текст играет мало значения — важно сколько усилий мне приходится тратить на изложение своих мыслей. И среда вполне может компенсировать недостатки языка. Представленный пример это очень хорошо иллюстрирует. Конечно, Smalltalk до сих пор даже близко не подошел к реализации всего заложенного потенциала (а потенциал среды во многом определяется именно языком, кстати), но что могло бы быть (и не так уж сложно воплотить, кстати) — легко себе представить.

Как язык Smalltalk очень интересен (прежде всего своей гуманистичностью), но, конечно, не лишен недостатков. Причем, весьма существенных. Хотя подозреваю, что в вопросе о недостатках я несколько… оригинален что ли… В общем, как показывают предыдущие попытки обсудить их, тут я в меньшинстве. В общем, меня смущает, что синтаксис языка не минималистичен и нарушает некоторые базовые принципы (не всегда объектен). Но Ruby, насколько я знаю, в этом отношении еще хуже, причем значительно. 

По второму вопросу… Он мне не до конца ясен. Мне кажется почти очевидной мысль, что качество языка (а оно, пожалуй, определяется его выразительная мощью, к слову) есть отношение возможностей к сложности языка. Чем больше возможностей, тем лучше — это, наверное, обсуждать нет смысла. Чем проще, тем лучше — некоторые с этим будут спорить, но наверное не мы :)  Так что, "тупое" наращивание возможностей за счет введения новых ключевых слов и синтаксических конструкций (как это делается до сих пор в большинстве языков) не только не усиливает их выразительную мощь, а скорее уменьшает (впрочем, все субъективно, ибо точные числовые оценки зависят от выбранных метрик, разумеется).

Идея, что язык надо стараться сохранять неизменяемым, а все нужные фишки лучше реализовывать в библиотеке, нашла свое воплощение (как минимум — возможно и раньше) в Simula-67. До этого те же авторы сделали Simula (потом ее стали обозначать как Simula-I), который был надмножеством Alogol-а, который дополнили средствами описания имитационных моделей дискретных систем. А вот Simula-67 уже был сделан иначе: там Algol тоже пришлось расширять, но уже не конкретными фишками, а более общими механизмами, которые позволили реализовать те же средства моделирования уже не в языке, а в библиотеке.

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

Разумеется, все это — просто общие слова, если они не поддерживаются практикой. Но думаю авторы той же Simula руководствовались именно практическими аспектами: подозреваю, что Simula было сложно поддерживать, были сложности с обучением, популяризацией. В конечном итоге, "выстрелил" именно Simula-67. Думаю, не с проста — именно за счет своей на порядок большей выразительной мощи. Так что, наверное, это все-таки не просто общие рассуждения — за ними стоит практический смысл.

Та же история с континуациями наглядно это демонстрирует — с практической точки зрения, но чуть в другом аспекте (и, возможно, даже более важном): не было на тот момент континуаций в Ruby, и сообщество не могло себе позволить реализовать их — это потребовало бы (и, как я понимаю, потребовало) расширения языка — введения новой синтаксической конструкции. А в Smalltalk-е не понадобилось что-либо делать с языком, достаточно оказалось написать класс. Поэтому Seaside родился именно в Smalltalk-е, хотя его автор был Ruby-стом.

Отсутствие управляющих конструкций в Smalltalk-е — из той же оперы. Возможно, практические преимущества этого не очевидны, но красиво же! Да и есть они, наверняка, если подумать… :)



--

Best regards,


Dennis Schetinin



24 октября 2013 г., 10:02 пользователь Semyon Novikov <[hidden email]> написал:
Идея с новой веткой действительно хороша, а то мне стыдно даже.
Продолжаем разговор!
 
Похоже, мы говорим о разных вещах. Что имелось ввиду под "выразительностью" я понял. Меня больше интересует выразительность в смысле "удобства выражать свои мысли". 
И здесь хорошо бы сравнить на основе "процедуры" принятия решений при программировании на том или ином языке. Когда очень давно (лет 10 назад, наверное) пробегала такая статейка по поводу C++ vs. Smalltalk.

Давайте тогда ещё больше локализуем вопрос процедуры. Входит ли сюда время на создание новой сущности (класса, метода)? Или только процесс выражения мыслей?
В первом случае у St действительно есть небольшой перевес за счет шикарнейшей "IDE" (специально в кавычках, чтобы исключить буквожорство :)
Код в Smtalltalk писать действительно удобно. Но к языку это особого отношения не имеет. Что касается обычной работы по реализации своих идей, я бы поспорил даже на уровне руби.
Что нужно сделать в St чтобы добавить локальную переменную? Вернуться в начало метода и добавить её в блок локальных переменных.
В руби ее можно просто начать использовать. Да, я знаю, что большинство смолтоков сами предложать определить переменную, но всё же.

В остальном, я повторюсь: я не вижу принципиальной разницы между St и Ruby, примеры кода я писал уже.

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

Не очень понимаю, что заставляет вас так думать, разверните мысль, пожалуйста? Продолжения испокон веку входят именно в язык.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу Russian Smalltalk User Group.
 
Чтобы отказаться от подписки на эту группу и перестать получать из нее сообщения, отправьте электронное письмо на адрес [hidden email].
Настройки подписки и доставки писем: https://groups.google.com/groups/opt_out.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу Russian Smalltalk User Group.
 
Чтобы отказаться от подписки на эту группу и перестать получать из нее сообщения, отправьте электронное письмо на адрес [hidden email].
Настройки подписки и доставки писем: https://groups.google.com/groups/opt_out.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу Russian Smalltalk User Group.
 
Чтобы отказаться от подписки на эту группу и перестать получать из нее сообщения, отправьте электронное письмо на адрес [hidden email].
Настройки подписки и доставки писем: https://groups.google.com/groups/opt_out.