Ребят, вопрос такой возник: очень нравится мне идеология Смоллтока (не предмет спора, будем считать это субъективным мнением). Но вот его синтаксис... Я думал, после Перла мне уже ничего не страшно — ан нет, я ошибся. Какой-то он мне кажется жуууткий и нечитабельный. Конечно, привыкнуть можно даже к Лиспу, но мне бы хотелось не коверкать сознание, а просто сесть и работать.
Так вот сам вопрос: есть ли язык по идеологии совпадающий со Смоллтоком, но с более человеческим синтаксисом?
Для примера (что я считаю "человеческим") могу привести C# (да и вообще любой Си-подобный язык) — на мой взгляд это достаточно краткий и выразительный синтаксис, вполне пригодный для массового программинга.
Здравствуйте, quadrochups, Вы писали:
Q>pavel, а какая САМАЯ УДАЧНАЯ реализация Смоллтока существует?
На мой взгляд это Dolphin, вот почему:
— недорогая лицензия (примерно 500$);
— приятный внешний вид (в традиционном стиле windows);
— неплохой интелисенс. Т.к. код часто пишется в workspace-е "по ходу", то переменные уже как правило содержат объекты, а это значит что вся инфа об нем (список методов для интелисенса в частности) доступна;
— достаточно приличное быстродействие. для большинства задач более чем достаточно.
— активное доброжелательное комюнити.
Еще есть VisualWorks, про неге скажу следующее:
— невнятная лицензионная политика, а точнее просто дорого, и а это на фоне MS VS2005 — это на мой взгляд самый существенный недостаток, фактически ставящий крест на коммерческом использовании .
— самый быстрый, настоящий динамический JIT компилятор, уделывающий C++ на вызовах виртуальных методов (специально сам проверял — все правда!).
— реально многоплатформенный.
— мне не понравилось создание GUI, контролы выглядят как не родные.
— очень много хорошей доки.
— очень много наворочено вокруг продукта полезных библиотек и тулов (ORM-ы, профайлеры и т.п.).
Вообще мне в Смолтоке нравиться следующее:
— простой синтаксис. Это дает ОЧЕНЬ низкий порог входимости. Не повериш, но мне реально для того чтобы практически полностью освоить язык (синтаксис) и научиться читать его понадобилось около 2-3 часов (застваил себя напрячся и не жалею). На мой взгляд ST — просто идеальный язык для непрограммеров, а для бизнес-аналитиков, технологов-бизнес процессов, настройщиков информационных систем на предприятии (сам занимаюсь примерно и в этой сфере).
— динамическая типизация, да-да! она самая . не будем разводить флеймы, но я бы для определенных проектов СОЗНАТЕЛЬНО предпочел бы ее, прекрасно понимая все достоинства / недостатки.
за счет нее в частности более высокый уровень абстракции и соответсвенно возможность создания DSL.
— блоки кода (BlockClosures), это просто мега-круто и мега-удобно пользоваться.
— инкрементальный принцип разработки. т.е. программа создается маленьким кусочками, опробывал идею в workspace-е, из этого кусочка кода сделал метод, потом следующий и так шаг за шагом, пробуеш идею, проверяеш, save метод, подрефакторили, сохранили, юнит тестик под это дело. при этом у тебя есть живое состояние программы. Например, делаеш сложную учетную операцию, при каком-то стечении данных вылез ексепшн, в отладчике можно подлезть в любое место посмотреть любую переменную (в том числе приватные члены классов у любых живых объектов), раскопал суть проблемы тут же в отладчике и поправил и не теряя состояния пошел дальше. очень удобно.
— высокая динамичность среды. т.е. в работающем приложении можно без проблем добавлять/удалять методы в классы, менять сигнатуру класса, добавлять удалять классы и при этом программу не надо перезапускать и не теряется текущее состояние живых объектов. причем все это можно делать программно. в разумных пределах конечно.
По поводу твоего исходного вопроса — к сожалению ничего подобного с синтаксисом приближенным к "настоящим" языкам нету увы, жаль. Но по собственным ощущениям привыкнуть можно и не сильно болезненно, хотя до сих пор не нравиться как приходиться записывать сложные логические выражения — получается куча скобок, но 1-2 пишутся и выглядят нормально.
Здравствуйте, quadrochups, Вы писали:
Q>Ребят, вопрос такой возник: очень нравится мне идеология Смоллтока (не предмет спора, будем считать это субъективным мнением). Но вот его синтаксис... Я думал, после Перла мне уже ничего не страшно — ан нет, я ошибся. Какой-то он мне кажется жуууткий и нечитабельный.
Если неприятие возникает только от синтаксиса, то это нормально. Со временем проходит, причем быстро. На самом деле он весьма приятен именно отсутствием многих лишних синтаксических конструкций, ненужных благодаря поддержке структуризации кода в самой IDE.
Насчет читабельности... вот, например, из народного творчества. Примерчик программы на языке КороткийБазар (проверено на VisualWorks Smalltalk)
Здравствуйте, eao197, Вы писали:
Q>>Так вот сам вопрос: есть ли язык по идеологии совпадающий со Смоллтоком, но с более человеческим синтаксисом?
E>Ruby
Есть распространенное мнение, что таки да, Руби.
Впрочем, есть одна как минимум "фича" смолтолка, которой у Руби нет и не будет никогда (это не хорошо и не плохо, но на способ мышления на этом языке сильно влияет): Ruby хранит исходники в традиционной форме текстовых файлов, а Smalltalk — в image.
"Благодаря" этому, например, Smalltalk — это язык, имеющий лучшие в мире IDE (потому что он by design устроен так, что дихотомии design-time/run-time не существует, и в момент написания кода о нем есть вся та информация, что и в момент выполнения). Поэтому действительно полнофункциональный браузеры кода и refactory-браузеры для Ruby создать почти невозможно (т.к. любой класс и любой объект может измениться в рантайме, и простым парсингом исходников это очень тяжело определить и корректно обработать).
AFAIK, Smalltalk чуть ли не единственный язык-среда программирования, который подходит к исходникам не как к "простому тексту, который мы сейчас распрасим-скомпилируем-выполним".
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>Есть распространенное мнение, что таки да, Руби.
А вот я, например, до сих пор не уверен -- то ли Ruby -- это испорченный Perl-ом Smalltalk, то ли это улучшенный Smalltalk-ом Perl. Последний вариант весьма вероятен
ЗХ>Впрочем, есть одна как минимум "фича" смолтолка, которой у Руби нет и не будет никогда (это не хорошо и не плохо, но на способ мышления на этом языке сильно влияет): ЗХ>Ruby хранит исходники в традиционной форме текстовых файлов, а Smalltalk — в image.
А ведь это же поддчеркивается и по данной мной ссылке:
Ruby Sparkles
Take a true object-oriented language, such as Smalltalk. Drop the unfamiliar syntax and move to more conventional, file-based source code. Now add in a good measure of the flexibility and convenience of languages such as Python and Perl.
You end up with Ruby.
ЗХ>"Благодаря" этому, например, Smalltalk — это язык, имеющий лучшие в мире IDE (потому что он by design устроен так, что дихотомии design-time/run-time не существует, и в момент написания кода о нем есть вся та информация, что и в момент выполнения). Поэтому действительно полнофункциональный браузеры кода и refactory-браузеры для Ruby создать почти невозможно (т.к. любой класс и любой объект может измениться в рантайме, и простым парсингом исходников это очень тяжело определить и корректно обработать).
Интересно в irb работать (если она скомпилирована с поддержкой автодополнения): набираешь несколько первых букв и жмешь Tab -- имя расширяется в зависимости от контекста (будь то имя класса или имя метода). Как в Smalltalk-е, только результат ввода нельзя в файл сохранить. Хотя и там не всегда есть помощь от irb, например, в случае:
irb(main):001:0> def func(x)
irb(main):002:1> x.what # <= Что хотел сказать автор?
А вот так понимает:
irb(main):001:0> class My
irb(main):002:1> def what_i_want; bla_bla_bla; end
irb(main):003:1> def what_you_want; bla_bla_bla; end
irb(main):004:1> end
=> nil
irb(main):005:0> x = My.new
=> #<My:0x2c15014>
irb(main):006:0> x.what_
x.what_i_want x.what_you_want # <= Это подсказка от irb.
irb(main):006:0> x.what_
ЗХ>AFAIK, Smalltalk чуть ли не единственный язык-среда программирования, который подходит к исходникам не как к "простому тексту, который мы сейчас распрасим-скомпилируем-выполним".
+1
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Q>Какие-то восклицательные знаки, палочки, крышечки... ужыз.
Q>Понятно, что привыкнуть и к такому можно, но нафик столько мучений?
К любому синтаксису, как оказалось, легко привыкнуть (кроме, возможно J ). Просто после определенного момента перестаешь восприинимать синтаксис отдельно от языка, и язык хорошо так и спокойно ложится на синтаксис. А если синтаксис еще и логичный... Тогда вообще щастя И тогда то, что другим кажется мешаниной, тебе кажется очень понятным.
Кстати, если сделать над собой усилие и взглянуть на привычный C/Java/PHP не взглядом программиста, то становится понятно, насколько и там мешанина (из jakarta, Java):
ЗХ>>IDE IDEю — рознь. Очень стоит потрогать нормальное смолтолковское средство разработки (в котором само средство разработки можно модифицировать так же легко, как и прикладной код), чтобы почувствовать разницу
S>Я "трогал" только Smalltalk MT. Не впечатлило
Я извиняюсь за оффтопик, цитату с башорга вспомнил:
-Я не могу зайти на ваш сайт!
-Потрите все куки и попробуйте перезайти.
-Потёр. Приятно!
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Из-за невероятной тяжести первый реф.броузер был сделан именно в ST.
Броузер — это детский лепет. Он действительно делается без проблем. А вот комплит-ворд, навигация по коду, подсказки для методов и их параметров. А это все для полноценной работы нужндается в статической информации о типах.
А то что что-то где-то было впервые сделано ничего не значит. Это просто говорит, о том, что те кто делал Смолток по натуре исследователи.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>>Из-за невероятной тяжести первый реф.броузер был сделан именно в ST.
VD>Броузер — это детский лепет.
Не путаем рефакторинг браузер с класс браузером. Класс браузер был в Smalltalk изначально — это неотъемлимая часть среды разработки, которая, в свою очередь, неотъемлимая часть языка.
VD>Он действительно делается без проблем. А вот комплит-ворд, навигация по коду, подсказки для методов и их параметров.
Да уж, по сравнению со всем этим (и в сумме и по отдельности) автоматизированный рефакторинг — так, мелочь, не стоящая упоминания.
VD>А это все для полноценной работы нужндается в статической информации о типах.
А мужики-то и не знают... Придётся срочно это всё запрещать и вырезать. Тяжёлая работа, но что поделать — VladD2 так сказал.
S>Я "трогал" только Smalltalk MT. Не впечатлило
Не самая удачная реализация, хотя и есть свои плюсы.
Если будет время и возможность "потрогайте" Dolphin Smalltalk, масса новых интересных (положительных) впечатлений гарантирована!
Здравствуйте, quadrochups, Вы писали:
Q>Какие-то восклицательные знаки, палочки, крышечки... ужыз.
То, что с восклицательными знаками это формат предназначенный для переноса между образами. Человек такого не видит. Только в GNU ST используется такой формат для ввода человеком. Но что ты с гнутого возьмёш
Так что остаётся только:
new
| r |
r := super new.
r init.
^r
"Палочки" это к переменным.
Q>Понятно, что привыкнуть и к такому можно, но нафик столько мучений?
Здравствуйте, quadrochups, Вы писали:
ЗХ>>Поэтому действительно полнофункциональный браузеры кода и refactory-браузеры для Ruby создать почти невозможно
Q>Не совсем понимаю почему... Вон, даже у Си есть браузер кода В чём проблема?
Потому что в любом месте кода может быть написано что-нибудь такое:
#...работаем с каким-нибудь там obj....if blah-blah #какое-то чудовищно сложное условие
obj.define_method(:my_cool_method) do ... end
end
И, соответственно, всякие типичные задачи "весь список методов объекта", "переименовать метод", "разделить метод на несколько" и т.п. — они не то чтобы идут лесом, но очень сильно усложняются.
Не говоря уж об упомянутом method_missing
obj.my_cool_method #ага, здесь можно сделать вывод, что у obj есть my_cool_method!
#а фиг там. у obj просто определен какой-нибудь такой method_missing:def method_missing(meth,*arg)
if meth =~ /.../ #проверили имя метода каким-нибудь чудовищным регекспом, и решили, как на него ответитьif arg.size == ... #проверили кол-во аргументов и решили, отвечать ли на такой методelse
super#таки он нам не понравился, вызвали изначальный method_missingend
end
Чтобы браузить и рефакторить такие вещи, их нужно ээээ... исполнять в design-time, если понятно, о чем я. Smalltalk это делает; Ruby — нет.
Здравствуйте, Eugene Beschastnov, Вы писали:
VD>>А это все для полноценной работы нужндается в статической информации о типах. EB>А мужики-то и не знают... Придётся срочно это всё запрещать и вырезать. Тяжёлая работа, но что поделать — VladD2 так сказал.
Вырезать конечно не надо, но вот подтянуться по качеству рефакторинга и того же комлпит-ворда к лучшим средам для статически типизированных языков было бы не полохо. А то вот я гляжу, Дольфин уже заполучил комплит-ворд в очень ограниченном виде. И это в 7-ой то версии. А в SQL Windows и VB он был еще в середине 90-ых. Как-то все это не вяжется с пиаром супер навороченности сред Смолтока.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, quadrochups, Вы писали:
Q>>Так вот сам вопрос: есть ли язык по идеологии совпадающий со Смоллтоком, но с более человеческим синтаксисом?
E>Ruby
Питон тоже, но у него конечно синтаксис не совсем сишный
Здравствуйте, quadrochups, Вы писали:
Q>Ребят, вопрос такой возник: очень нравится мне идеология Смоллтока (не предмет спора, будем считать это субъективным мнением). Но вот его синтаксис... Я думал, после Перла мне уже ничего не страшно — ан нет, я ошибся. Какой-то он мне кажется жуууткий и нечитабельный. Конечно, привыкнуть можно даже к Лиспу, но мне бы хотелось не коверкать сознание, а просто сесть и работать. Q>Так вот сам вопрос: есть ли язык по идеологии совпадающий со Смоллтоком, но с более человеческим синтаксисом?
Q>Для примера (что я считаю "человеческим") могу привести C# (да и вообще любой Си-подобный язык) — на мой взгляд это достаточно краткий и выразительный синтаксис, вполне пригодный для массового программинга.
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>Есть распространенное мнение, что таки да, Руби.
Руби — отличный язык. Хотя есть и концептуальные отличия между ним и Smalltalk.
Так в Руби конструкции типа if, for, while, [] реализованы на уровне синтаксиса, а в Smalltalk — с помощью методов.
С одной стороны это позволяет лечге перейти к Руби от Java/C# и пр., с другой стороны в Smalltalk соблюдается концепция ООП.
Хотя отступление от ООП и имеет определенные минусы, ИМХО, это не мешает создавать хорошие (а заодно и красивые) программы на Руби.
ЗХ>Впрочем, есть одна как минимум "фича" смолтолка, которой у Руби нет и не будет никогда (это не хорошо и не плохо, но на способ мышления на этом языке сильно влияет): ЗХ>Ruby хранит исходники в традиционной форме текстовых файлов, а Smalltalk — в image.
В Smalltalk исходный текст можно тоже хранить в текстовых файлах. Так, при необходимости можно загружать код в image и, наоборот, выгрузить его оттуда в текстовый файл. Т.е. нужные библиотеки/классы лежат в image, а не нужные "на полочке" (на диске).
ЗХ>"Благодаря" этому, например, Smalltalk — это язык, имеющий лучшие в мире IDE (потому что он by design устроен так, что дихотомии design-time/run-time не существует, и в момент написания кода о нем есть вся та информация, что и в момент выполнения). Поэтому действительно полнофункциональный браузеры кода и refactory-браузеры для Ruby создать почти невозможно
Если для Руби реализовать IDE, работающую по принципу Smalltalk, т.е. формировать image, в котором будут файлы Руби, то ничего невозможного в этом нет. Вон та же IDEA подключает к проекту стороннюю библиотеку, и "интегрирует" ее в проект. Если код этих библиотек доступен неуж-то трудно реализовать "полнофункциональный браузер код и refactory-браузер"?
Правда следует учесть, что в IDE smalltalk хранится не только код, но и созданные объекты на текущий момент! То есть создайте любой объект в Workspace, поработайте с ним. Закройте и снова откройте image. И, вперед, продолжайте работать с тем же объектом. Это реализовать труднее, но, в принципе, также возможно и в Руби.
ЗХ>(т.к. любой класс и любой объект может измениться в рантайме, и простым парсингом исходников это очень тяжело определить и корректно обработать).
Не совсем понятно, что имелось ввиду.
Здравствуйте, Beam, Вы писали:
ЗХ>>(т.к. любой класс и любой объект может измениться в рантайме, и простым парсингом исходников это очень тяжело определить и корректно обработать). B>Не совсем понятно, что имелось ввиду.
вот это:
B>Правда следует учесть, что в IDE smalltalk хранится не только код, но и созданные объекты на текущий момент! То есть создайте любой объект в Workspace, поработайте с ним. Закройте и снова откройте image. И, вперед, продолжайте работать с тем же объектом. Это реализовать труднее, но, в принципе, также возможно и в Руби.
Реализовать это возможно, но тяжело, долго, и коммьюнити не слишком стремится этим заниматься. Причины этому недавно в ruby-talk обсуждались (там раз в месяц поднимается тема вроде "Why not to have Smalltalk-like IDE for Ruby?")
IDE IDEю — рознь. Очень стоит потрогать нормальное смолтолковское средство разработки (в котором само средство разработки можно модифицировать так же легко, как и прикладной код), чтобы почувствовать разницу
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>IDE IDEю — рознь. Очень стоит потрогать нормальное смолтолковское средство разработки (в котором само средство разработки можно модифицировать так же легко, как и прикладной код), чтобы почувствовать разницу
1. В Smalltalk нету МЕТОДОВ, там есть сообщения. Если программа приняла неизвестное сообщение, его можно вежливо обработать. Руби же сразу начинает ругацца — метод должен быть определён заранее. Я правильно уловил?
2. Не совсем понятна (притянутая из Перла) фича в виде префиксов переменных. В Перле — понятно, это позволяло обходиться без описаний и шикарно манипулировать разнородными сущностями. В Руби сделали $ и @ — довольно глупый выверт.
3. Аналогично, перенесённые из Перл "псевдопеременные" вида $_, $/, etc — для Перла (изначально как обработчика текста) это было простительно, но для нового, ОО языка я считаю это мусором в языке.
4. Аксессоры — тоже какая-то мешанина: есть синтаксис с get_/set_ (с какой радости? может это мои методы!), есть его запись через "=", а есть его сокращение через attr_* — вам не кажется, что эта чехарда несколько несерьёзна?
Я не хочу хаять Руби в целом — он может быть вполне достойной заменой. Но вот как альтернатива СМОЛЛ-току — смотрится слишком дилетантски.
Q>>Для примера (что я считаю "человеческим") могу привести C# (да и вообще любой Си-подобный язык) — на мой взгляд это достаточно краткий и выразительный синтаксис, вполне пригодный для массового программинга.
В>Это?
О, нет!!! Только не этот ужыз! Он хоть и "си-шный", но мешанина полнейшая.
Здравствуйте, quadrochups, Вы писали:
E>>Ruby
Q>Смотрел. Нашёл пару моментов, которые смущают:
Q>1. В Smalltalk нету МЕТОДОВ, там есть сообщения. Если программа приняла неизвестное сообщение, его можно вежливо обработать. Руби же сразу начинает ругацца — метод должен быть определён заранее. Я правильно уловил?
Нет. В Ruby каждый вызов метода -- это отсылка сообщения. Если сообщение (метод) для объекта не определен, то у объекта вызывается метод method_missing, в котором можно это дело вежливо обработать.
Q>2. Не совсем понятна (притянутая из Перла) фича в виде префиксов переменных. В Перле — понятно, это позволяло обходиться без описаний и шикарно манипулировать разнородными сущностями. В Руби сделали $ и @ — довольно глупый выверт.
Еще @@ забыли.
$ практически не используется, кроме как для обращения к системным переменным типа $!, $: и пр.
А вот @ и @@ удобны.
Q>3. Аналогично, перенесённые из Перл "псевдопеременные" вида $_, $/, etc — для Перла (изначально как обработчика текста) это было простительно, но для нового, ОО языка я считаю это мусором в языке.
Он не новый, а 1994 года выпуска. И ноги у него растут из Perl-а.
Для $_ и $/ есть пакет English
Q>4. Аксессоры — тоже какая-то мешанина: есть синтаксис с get_/set_ (с какой радости? может это мои методы!), есть его запись через "=", а есть его сокращение через attr_* — вам не кажется, что эта чехарда несколько несерьёзна?
Нет. Я вообще не понял, про какие get_/set_ идет речь.
Q>Я не хочу хаять Руби в целом — он может быть вполне достойной заменой. Но вот как альтернатива СМОЛЛ-току — смотрится слишком дилетантски.
Да ради бога. Проходя проходи.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
ЗХ>Впрочем, есть одна как минимум "фича" смолтолка, которой у Руби нет и не будет никогда (это не хорошо и не плохо, но на способ мышления на этом языке сильно влияет): ЗХ>Ruby хранит исходники в традиционной форме текстовых файлов, а Smalltalk — в image.
Я так понимаю, и в Смоллтоке работа происходит с текстом, но при этом программа ещё и выполняется. Так?
ЗХ>Поэтому действительно полнофункциональный браузеры кода и refactory-браузеры для Ruby создать почти невозможно
Не совсем понимаю почему... Вон, даже у Си есть браузер кода В чём проблема?
ЗХ>AFAIK, Smalltalk чуть ли не единственный язык-среда программирования, который подходит к исходникам не как к "простому тексту, который мы сейчас распрасим-скомпилируем-выполним".
Мне тогда не совсем понятен стиль работы программиста — он же должен иметь исходники, отладчик, и т.п. Вы не могли бы кратко описать, как смоллтокист создаёт программу?
Q>>1. В Smalltalk нету МЕТОДОВ, там есть сообщения. Если программа приняла неизвестное сообщение, его можно вежливо обработать. Руби же сразу начинает ругацца — метод должен быть определён заранее. Я правильно уловил?
E>Нет. В Ruby каждый вызов метода -- это отсылка сообщения. Если сообщение (метод) для объекта не определен, то у объекта вызывается метод method_missing, в котором можно это дело вежливо обработать.
Q>>2. Не совсем понятна (притянутая из Перла) фича в виде префиксов переменных. В Перле — понятно, это позволяло обходиться без описаний и шикарно манипулировать разнородными сущностями. В Руби сделали $ и @ — довольно глупый выверт.
E>Еще @@ забыли. E>$ практически не используется, кроме как для обращения к системным переменным типа $!, $: и пр. E>А вот @ и @@ удобны.
Хм... как сказать. Реализация методов класса — это и есть алгоритмы над членами класса. Какой смысл выделять их "плюшками"? А как же прозрачность кода?
Q>>3. Аналогично, перенесённые из Перл "псевдопеременные" вида $_, $/, etc — для Перла (изначально как обработчика текста) это было простительно, но для нового, ОО языка я считаю это мусором в языке.
E>Для $_ и $/ есть пакет English
Дело не в том как называть — здесь вопрос концепции. Если ВСЁ в Руби — объекты, зачем же тогда делать разные псевдосущности? (глобальные переменные, спец-переменные) Я ж потому и говорю про Смоллток, что он является "чистым" и целостным ООЯ. Т.е. достаточно иметь в голове небольшой набор правил, а сами программы пишутся, как говорится, не приходя в сознание.
Q>>4. Аксессоры — тоже какая-то мешанина: есть синтаксис с get_/set_ (с какой радости? может это мои методы!), есть его запись через "=", а есть его сокращение через attr_* — вам не кажется, что эта чехарда несколько несерьёзна?
E>Нет. Я вообще не понял, про какие get_/set_ идет речь.
Q>>Я не хочу хаять Руби в целом — он может быть вполне достойной заменой. Но вот как альтернатива СМОЛЛ-току — смотрится слишком дилетантски.
E>Да ради бога. Проходя проходи.
Вы не поняли моего вопроса... Я прошу показать, есть ли вразумительная замена Смоллтока, а не то, хороший Руби или плохой. И потом, см. замечание про "сорсы" и "image".
eao197, а я по-вашему откуда? Только это же список — он ни о чём не говорит. Например, описания "Близко к стандарту Smalltalk-80." — и что? А может есть Смоллток-3000, который гораздо круче! Или вот библиотеки — у всех они самодельные, т.е. уже мой код под другую систему не перенести. Значит надо выбирать ту, которая больше всех распространена. Ну и вообще, субъективные впечатления нужны — что удобнее, быстрее и т.п.
Я дал вам ссылку на один из лучших источников информации по Ruby, первое издание Programming Ruby (лучше, имхо, только второе издание). В котором все очень понятно, последовательно и доступно излагается. Так что лучше искать проблемы в собственных источниках, а не в языке программирования.
E>>Еще @@ забыли. E>>$ практически не используется, кроме как для обращения к системным переменным типа $!, $: и пр. E>>А вот @ и @@ удобны.
Q>Хм... как сказать. Реализация методов класса — это и есть алгоритмы над членами класса. Какой смысл выделять их "плюшками"? А как же прозрачность кода?
Потому что в реализациях алгоритмов используются и параметры, и локальные переменные. Чтобы в них не путаться в других языка программирования используют соглашения об именовании. Например, префиксы m_ (m_start_time) или суффиксы _ (start_time_), или запись через this (this->start_time в C++ или this.start_time в Java). В Ruby эту проблему решили на уровне синтаксиса языка (@start_time и никаких гвоздей).
Q>Дело не в том как называть — здесь вопрос концепции. Если ВСЁ в Руби — объекты, зачем же тогда делать разные псевдосущности? (глобальные переменные, спец-переменные) Я ж потому и говорю про Смоллток, что он является "чистым" и целостным ООЯ. Т.е. достаточно иметь в голове небольшой набор правил, а сами программы пишутся, как говорится, не приходя в сознание.
Теперь докажите, что, например $: или $! не является объектом. Объект самый настоящий, $ просто указывает область его видимости.
Q>>>4. Аксессоры — тоже какая-то мешанина: есть синтаксис с get_/set_ (с какой радости? может это мои методы!), есть его запись через "=", а есть его сокращение через attr_* — вам не кажется, что эта чехарда несколько несерьёзна?
E>>Нет. Я вообще не понял, про какие get_/set_ идет речь.
Q>Это отседа: http://www.msiu.ru/~roganova/Ing_Spring_2003-2004/AboutRuby/www.sophtanet.com.html (глава "Аксессоры")
Тогда вы еще и свой источник не правильно прочитали. В Ruby можно определять методы get_/set_, если это кому-то нравится. Но не принято, вместо этого используются имена name и name=. Но, поскольку в большинстве случаев их реализация тривиальна, то для упрощения их создания добавлены метаметоды attr, attr_reader и пр.
Q>>>Я не хочу хаять Руби в целом — он может быть вполне достойной заменой. Но вот как альтернатива СМОЛЛ-току — смотрится слишком дилетантски.
E>>Да ради бога. Проходя проходи.
Q>Вы не поняли моего вопроса... Я прошу показать, есть ли вразумительная замена Смоллтока, а не то, хороший Руби или плохой. И потом, см. замечание про "сорсы" и "image".
Вы бы определились, что вам нужно. Smalltalk, но с другим синтаксисом? Или другой язык, близкий по духу Smalltalk?
Имхо, лучше Smalltalk-а только Smalltalk, поэтому принимайте его таким какой он есть. Все остальные языки будут со своей философией и могут только напоминать что-то.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
E>Так что лучше искать проблемы в собственных источниках, а не в языке программирования.
eao, согласись, глупость сморозил? Как я, ничего не зная о Руби, могу "искать проблемы"? Есть гугля, вот им и пользуюсь. А главное — почему претензия ко мне, а не источнику? Походу, обсуждение (С ТВОЕЙ СТОРОНЫ) скатывается в подростковое кидание понтов. Во взрослом мире это называется "хамство". Пора подрасти?
Q>>Хм... как сказать. Реализация методов класса — это и есть алгоритмы над членами класса. Какой смысл выделять их "плюшками"? А как же прозрачность кода?
E>Потому что в реализациях алгоритмов используются и параметры, и локальные переменные. Чтобы в них не путаться...
А зачем в них путаться? Их использовать надо! Будет конфликт имён — транслятор предупредит, а так — не вижу смысла их разделять.
Q>>Дело не в том как называть — здесь вопрос концепции. Если ВСЁ в Руби — объекты, зачем же тогда делать разные псевдосущности? (глобальные переменные, спец-переменные) Я ж потому и говорю про Смоллток, что он является "чистым" и целостным ООЯ. Т.е. достаточно иметь в голове небольшой набор правил, а сами программы пишутся, как говорится, не приходя в сознание.
E>Теперь докажите, что, например $: или $! не является объектом. Объект самый настоящий, $ просто указывает область его видимости.
А зачем мне область видимости? (не говоря о достаточно "странных" именах) Есть объект, есть сообщение. А так вместо однородной кучи переменных я должен думать — спросить проперть у класса или взять глобальную переменную. Зачем меня напрягать? (см. выделенное)
Как написано, так и прочёл. Меня не волнует, принято там или нет. Я указал на ТРИ варианта синтаксиса описания аксессоров. Что фактически показывает бестолковое проектирование языка.
Q>>Вы не поняли моего вопроса... Я прошу показать, есть ли вразумительная замена Смоллтока, а не то, хороший Руби или плохой. И потом, см. замечание про "сорсы" и "image".
E>Вы бы определились, что вам нужно. Smalltalk, но с другим синтаксисом? Или другой язык, близкий по духу Smalltalk?
Вы бы сначала поняли вопрос, а потом на него отвечали. Нужны ОБА: и "человеческий" синтаксис, и концептуальная идея. Изучать всякие Питоны/Руби/Джамбы-юмбы можно до бесконечности, все они недалеко друг от дружки ушли. Интересовал именно Смоллток. И вы правильно поняли суть, говоря далее:
E>Имхо, лучше Smalltalk-а только Smalltalk, поэтому принимайте его таким какой он есть.
Вот. Просто в силу того, что я не вращаюсь в Смоллток кругах, я мог пропустить появление какого-то нового, человеческого диалекта, потому и спросил.
В любом случае, спасибо за уделённое внимание.
Здравствуйте, quadrochups, Вы писали:
Q>Ребят, вопрос такой возник: очень нравится мне идеология Смоллтока (не предмет спора, будем считать это субъективным мнением). Но вот его синтаксис... Я думал, после Перла мне уже ничего не страшно — ан нет, я ошибся. Какой-то он мне кажется жуууткий и нечитабельный. Конечно, привыкнуть можно даже к Лиспу, но мне бы хотелось не коверкать сознание, а просто сесть и работать. Q>Так вот сам вопрос: есть ли язык по идеологии совпадающий со Смоллтоком, но с более человеческим синтаксисом?
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, quadrochups, Вы писали:
Q>>pavel, а какая САМАЯ УДАЧНАЯ реализация Смоллтока существует?
E>Может вам проще в гости на smalltalk.ru сходить? E>В частности, посмотреть на описания существующих реализаций.
Здравствуйте, quadrochups, Вы писали:
Q>Ребят, вопрос такой возник: очень нравится мне идеология Смоллтока (не предмет спора, будем считать это субъективным мнением). Но вот его синтаксис... Я думал, после Перла мне уже ничего не страшно — ан нет, я ошибся. Какой-то он мне кажется жуууткий и нечитабельный.
А что именно не нравится в синтаксисе? Мне он как раз очень нравится — именованные параметры у методов, практически полное отсутствие синтаксического мусора (только то, что необходимо и практически ничего лишнего) и пр.
Здравствуйте, quadrochups, Вы писали:
Q>eao, согласись, глупость сморозил? Как я, ничего не зная о Руби, могу "искать проблемы"?
Вот так:
1. В Smalltalk нету МЕТОДОВ, там есть сообщения. Если программа приняла неизвестное сообщение, его можно вежливо обработать. Руби же сразу начинает ругацца — метод должен быть определён заранее.
это говорит об элементарном незнании матчасти. И гуглить ничего не нужно, поскольку я дал ссылку на книгу, в которой эти моменты описываются:
The answer has to do with the way Ruby determines which method should be called when you send a message to an object. When Ruby compiles the method invocation aSong.to_s, it doesn't actually know where to find the method to_s. Instead, it defers the decision until the program is run. At that time, it looks at the class of aSong. If that class implements a method with the same name as the message, that method is run. Otherwise, Ruby looks for a method in the parent class, and then in the grandparent, and so on up the ancestor chain. If it runs out of ancestors without finding the appropriate method, it takes a special action that normally results in an error being raised.[In fact, you can intercept this error, which allows you to fake out methods at runtime. This is described under Object#method_missing on page 355.]
Q>>>Хм... как сказать. Реализация методов класса — это и есть алгоритмы над членами класса. Какой смысл выделять их "плюшками"? А как же прозрачность кода?
E>>Потому что в реализациях алгоритмов используются и параметры, и локальные переменные. Чтобы в них не путаться...
Q>А зачем в них путаться? Их использовать надо! Будет конфликт имён — транслятор предупредит, а так — не вижу смысла их разделять.
Транслятор не предупредит, Ruby динамически типизированный язык, в нем переменные даже заранее декларировать не нужно.
E>>Теперь докажите, что, например $: или $! не является объектом. Объект самый настоящий, $ просто указывает область его видимости.
Q>А зачем мне область видимости? (не говоря о достаточно "странных" именах) Есть объект, есть сообщение. А так вместо однородной кучи переменных я должен думать — спросить проперть у класса или взять глобальную переменную. Зачем меня напрягать? (см. выделенное)
$: -- это объект, вы можете послать ему сообщение. Все в Ruby объект. Даже класс, который вы декларируете -- он тоже является объектом, даже в непосредственно в момент декларации.
Так что заметно, что из-за слабого знания матчасти вы еще не усвоили тот небольшой набор базовых концепций, который есть в Ruby.
А писать программы, не приходя в сознание, это сильно.
E>>Тогда вы еще и свой источник не правильно прочитали.
Q>Как написано, так и прочёл. Меня не волнует, принято там или нет. Я указал на ТРИ варианта синтаксиса описания аксессоров. Что фактически показывает бестолковое проектирование языка.
Ну по поводу проектирования можно говорить все что захочется.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Имхо, лучше Smalltalk-а только Smalltalk, поэтому принимайте его таким какой он есть. Все остальные языки будут со своей философией и могут только напоминать что-то.
Лучше Smalltalk должен быть Smalltalk без классов (на основе прототипов)
P.S. Кстати, кто-нибудь пробовал язык Self? Каково оно?
Здравствуйте, quadrochups, Вы писали:
ЗХ>>AFAIK, Smalltalk чуть ли не единственный язык-среда программирования, который подходит к исходникам не как к "простому тексту, который мы сейчас распрасим-скомпилируем-выполним".
Q>Мне тогда не совсем понятен стиль работы программиста — он же должен иметь исходники, отладчик, и т.п. Вы не могли бы кратко описать, как смоллтокист создаёт программу?
Может, проще самому попробовать?
Тем не меннее.. Исходников в привычном представлении как таковых нет. Весь код хранится в двух видах — тексты методов и байт-код. Причет и то, и другое хранится в специальных файлах, куда простым редактором лазать не рекомендуется.
Вся работа осуществляется через IDE. Опуская детали — программист видит список всех классов и список методов выбранного класса. Отредактировав выбранный метод (создав новый), программист жмет кнопку Accept, и ,опа, — метод сразу же компилируется.
Отладчик и прочие полезные тулзы (в частности, инспектор объектов) разумеется есть. Более того, в отладчике довольно удобно писать код, что особенно полезно при применении TDD — написал тест, вызывающий метод myMethod (еще несуществующий), запустил тест — вывалился отладчик с сообщением "message 'myMethod' not understood". Прямо в отладчике создал метод, написал в нем чего-нибудь, и продолжил выполнение. Если написал чего-нибудь хорошее, то и тест пройдет.
Здравствуйте, pavel74, Вы писали:
P>Еще есть VisualWorks, про неге скажу следующее: P>- невнятная лицензионная политика, а точнее просто дорого, и а это на фоне MS VS2005 — это на мой взгляд самый существенный недостаток, фактически ставящий крест на коммерческом использовании . http://www.progz.ru/forum/index.php?showtopic=15226
Если вкратце — для некоммерческих разработок (да и, по сути, для мелких коммерческих или внутренних) — бесплатно (при полном сохранении функционала).
Кроме этого существуют две лицензии, VAR и Server:
* VAR — Вы платите базовые $500 за каждого разработчика в год, и 6% от прибыли полученной от продаж за продукт (минус те $500*dev*year, что уже заплатили). При этом учитывается только вклад самого VW в продукт, например: VW — 60%, Oracle9 — 40%.
* Server — Вы платите $6000 в год за *серверную установку* продукта вне зависимости от количества разработчиков и прибыли.
Как легко видно, для мелких и средних фирм выгоднее лицензия VAR, для крупных — Server.
P>- мне не понравилось создание GUI, контролы выглядят как не родные.
Вкус и цвет — повод для драки . По мне, так вполне нормально выглядят. Кстати, насколько я знаю, прикручивание родных виджетов — это достаточно приоритетный проект у Cincom.
Здравствуйте, pavel74, Вы писали:
P>Еще есть VisualWorks, про неге скажу следующее: P>- невнятная лицензионная политика, а точнее просто дорого, и а это на фоне MS VS2005 — это на мой взгляд самый существенный недостаток, фактически ставящий крест на коммерческом использовании . P>- самый быстрый, настоящий динамический JIT компилятор, уделывающий C++ на вызовах виртуальных методов (специально сам проверял — все правда!). P>- реально многоплатформенный. P>- мне не понравилось создание GUI, контролы выглядят как не родные.
Ну, то что они выглядят как не родные, еще не страшно. Но вот расширяемость некоторых контролов, а особенно DataSet'a, удручает. Хотя, казалось бы, все написано на том же ST, бери и правь/добавляй.
С другой стороны, грядет Pollock (доолго уже грядет..), там, возможно, ситуация будет получше. Ну и native-контролы обещают поддержать.
P>- очень много хорошей доки. P>- очень много наворочено вокруг продукта полезных библиотек и тулов (ORM-ы, профайлеры и т.п.).
А кроме того, для VW есть Store — достаточно удобная VCS. Я не в курсе, как с этим дела у Dolphin'a?
Здравствуйте, Poisson, Вы писали:
P>Тем не меннее.. Исходников в привычном представлении как таковых нет. Весь код хранится в двух видах — тексты методов и байт-код. Причет и то, и другое хранится в специальных файлах, куда простым редактором лазать не рекомендуется.
Мнэээ......
А что же тогда является единицей source control'а?
С уважением, Евгений
JetBrains, Inc. "Develop with pleasure!"
Здравствуйте, xvost, Вы писали:
X>Здравствуйте, Poisson, Вы писали:
P>>Тем не меннее.. Исходников в привычном представлении как таковых нет. Весь код хранится в двух видах — тексты методов и байт-код. Причет и то, и другое хранится в специальных файлах, куда простым редактором лазать не рекомендуется.
X>Мнэээ...... X>А что же тогда является единицей source control'а?
Source Control (в диалекте VisualWorks, про прочие не скажу) свой, спецфицский и очень удобный. Работает с пакетами, классами, методами и так далее. Т.е. я могу для любого класса/метода посмотреть его историю изменений (прямо из IDE, одним кнопкой)
Здравствуйте, Poisson, Вы писали:
X>>А что же тогда является единицей source control'а? P>Source Control (в диалекте VisualWorks, про прочие не скажу) свой, спецфицский и очень удобный. Работает с пакетами, классами, методами и так далее. Т.е. я могу для любого класса/метода посмотреть его историю изменений (прямо из IDE, одним кнопкой)
А как совместная работа над проектом идет? Может какую-нибудь ссылочку на эту тему подкините?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, quadrochups, Вы писали:
Q>pavel, а какая САМАЯ УДАЧНАЯ реализация Смоллтока существует?
Из доступных бесплатно наверно Дольфин. Правда там половина на C++ написано (вопреки рекламным лозунгам). Да и откровенно говоря лично у меня Дольфин вызвал весма печальные ощущения гда два назад. Но вроде как последня версия вроде как даже комплит-ворд стала поддерживать. Просто прорыв для "самых лучших сред разработки".
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, quadrochups, Вы писали:
Q>Не совсем понимаю почему... Вон, даже у Си есть браузер кода В чём проблема?
С строготипизированный язык. Для него как раз любой рефакторинг и навигация делается с пол пинка.
Как раз для Смолтока это сделать тяжелее. А для Руби еще тяжелее. Хотя список классов можно сделть без проблем для обоих.
ЗХ>>AFAIK, Smalltalk чуть ли не единственный язык-среда программирования, который подходит к исходникам не как к "простому тексту, который мы сейчас распрасим-скомпилируем-выполним".
Q>Мне тогда не совсем понятен стиль работы программиста — он же должен иметь исходники, отладчик, и т.п. Вы не могли бы кратко описать, как смоллтокист создаёт программу?
Все очень просто. Ты не можешь править программу без специальной IDE. Программа "живет" в этой IDE. IDE знает многое о программе. В Руби же программу запускает интерпретатор не связанный с IDE. Фактически нет никаких проблем совместить IDE и интерпретатор, но это никто не сделал.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, pavel74, Вы писали:
P>>- блоки кода (BlockClosures), это просто мега-круто и мега-удобно пользоваться.
Д>Выглядит очень похоже на лямбду. Или есть какие-то отличия, которые я не заметил?
По сути она и есть, возможно есть какие-то различия в тонкостях. Самый простой пример использования блока кода:
|b| "объявили локальные переменные"
b:=[:i | i>10 ]. "создал блок кода, это в итоге объект и понимает сообщение value: "
какаятоКоллекция select: b .
" что значит - выбрать все элементы удовлетворяющие условию проверяемым блоком кода (в данном случае i>10 )
внутри коллекции работает свой алгоритм ее обхода и для каждого элмента запускает блок кода,
передавая ему в качестве параметра текущий элемент, т.е. можно не парится как именно правильно ее обходить.
Если блок кода вернул true - значит элемент нам подходит выбираем его в результат.
Да кстати класс коллекции может быть любым - интервал с верхней и нижней границей: ( 1 to: 100 )
просто массив, словарь на основе дерева или хэш таблицы или еще какой, за это заморочится сама коллекция.
"
или тоже самое токо одной строкой
какаятоКоллекция select: [:i| i>10].
Вообщем часто бывает в методе надо реализовать какой-то универсальный алгоритм, в котором в каком-либо месте код будет зависеть от конкретного контекста использования этого метода. При помощи блоков кода такие вещи решаются легко и красиво, передал в конкретном месте вызова этого метода ему блок кода и внутри реализации метода переданный блок кода и будет работать. В итоге гораздо проще писать обобщенные алгоритмы и повторно их использовать.
В Linq наконец-то такая возможность и появилась, не прошло и 20 лет с момента выхода первого ST в свет .
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Здравствуйте, VladD2, Вы писали:
VD>>Из доступных бесплатно наверно Дольфин. Правда там половина на C++ написано (вопреки рекламным лозунгам).
ANS>Это в .Net половина на С++ (точнее обёртки к нэтиву, но это один фиг). И ниче — все довольны.
А кто-то где-то говорил, что в дотнете все на нем? Вот про Смолток я это слушу постоянно. Ну, а открытое вранье я не люблю.
Первое что я услышал о Дольфине, что у него среда написана на Солтоке. Первы же взгляд на эту среду Spy++-ом показал, что это не правда.
Что до С++ в дотнете... Скачай Моно погляди сколько там на чем написано. Так же интересно поглядеть на IDEA и #Devolop.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>>>Правда там половина на C++ написано (вопреки рекламным лозунгам).
Сама виртуальная машина конечно, а как же иначе то. Что это за лозунги?
VD>А кто-то где-то говорил, что в дотнете все на нем? Вот про Смолток я это слушу постоянно. Ну, а открытое вранье я не люблю.
Возможно ты имел ввиду Сквик (или как там он правильно пишется), там вроде как говорят да, хотя может и не вся, да в принципе то какая разница. все сделать на смолтоке не самоцель, саму виртуальную машину крайне разумно и на цпп.
VD>Первое что я услышал о Дольфине, что у него среда написана на Солтоке. Первы же взгляд на эту среду Spy++-ом показал, что это не правда.
Ну зачем же крайности, почти вся логика среды на Smalltalk-е, но также для эффективности используются и нативные виндовые контролы (что на мой взгляд крайне разумно), в Dolphin 5 был RichEdit, в последнем Scintila. Наверняка просто разработчики решили не делать очередной велосипед (читай использовать сэкономленное время для других задач), а использовать готовые компоненты.
VD>А кто-то где-то говорил, что в дотнете все на нем? Вот про Смолток я это слушу постоянно. Ну, а открытое вранье я не люблю. VD>Первое что я услышал о Дольфине, что у него среда написана на Солтоке. Первы же взгляд на эту среду Spy++-ом показал, что это не правда.
Dolphin — Win-only диалект — использует родные виндовые виджеты.
В Squeak (который чистый интерпритатор) по соображением скорости есть т.н. плагины, которые пишутся на С. Там, например, обработка звука.
В VisualWorks (который развитие оригинального ST-80 из Ксерокса) всё на ST. Включая механизм исключений.
VD>Что до С++ в дотнете... Скачай Моно погляди сколько там на чем написано. Так же интересно поглядеть на IDEA и #Devolop.
Зачем такие напряги? Моно кучу лет до ума довести не могут. Из-за сильной связи с нэтивом.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Dolphin — Win-only диалект — использует родные виндовые виджеты. ANS>В Squeak (который чистый интерпритатор) по соображением скорости есть т.н. плагины, которые пишутся на С. Там, например, обработка звука. ANS>В VisualWorks (который развитие оригинального ST-80 из Ксерокса) всё на ST. Включая механизм исключений.
Ну, а что же ты всем предлагашь смотреть Dolphin постоянно рассказывая про среду на Смолтоке?
Что касается VisualWorks... Его где-то можно взять поглядеть? (бесплатно конечно)
VD>>Что до С++ в дотнете... Скачай Моно погляди сколько там на чем написано. Так же интересно поглядеть на IDEA и #Devolop.
ANS>Зачем такие напряги? Моно кучу лет до ума довести не могут. Из-за сильной связи с нэтивом.
Извени, но это чушь.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.