В Java все находится в форме класса.
Если вы хотите использовать любой объект, тогда у вас есть две фазы:
Пример:
Object a;
a=new Object();
То же самое для концепции массива
Item i[]=new Item[5];
i[0]=new Item();
Если вы не дают секцию инициализации, тогда возникает NullpointerException
.
Я - больше Pythonista, чем пользователь Ruby, однако то же самое содержит для Ruby по почти таким же причинам.
архитектура Smalltalk является несколько замкнутой, тогда как Python и Ruby были созданы с нуля для упрощения интеграции. Smalltalk никогда действительно получил тело поддержки гибридного приложения в способе, которым имеют Python и Ruby, таким образом, понятие 'smalltalk как встроенный язык сценариев' никогда не завоевывало популярность.
Как в стороне, Java не был самой легкой вещью взаимодействовать через интерфейс с другими кодовыми базами (JNI довольно неуклюж), но это не мешало ему получить долю завоеванного внимания. IMO взаимодействующий через интерфейс аргумент является значительным - простота встраивания, не повредил Python - но этот аргумент только содержит умеренный вес как не, все приложения требуют этой возможности. Кроме того, более поздние версии Smalltalk действительно существенно обращались к изолированности.
библиотека классов большинства основных smalltalk реализаций (VisualWorks, VisualAge и т.д.) была большой и имела репутацию довольно крутой кривой обучения. Большая часть ключевой функциональности в Smalltalk скрыта где-нибудь в библиотеке классов, даже основном материале как потоки и наборы. Парадигма языка является также чем-то вроде культурного шока для кого-то не знакомого с ним, и постепенное представление программы, представленной браузером, очень отличается к тому, к чему привыкло большинство людей.
полный эффект состоит в том, что Smalltalk стал (несколько заслуженным) репутация быть трудным учиться; требуется довольно мало времени и усилия стать действительно опытным программистом Smalltalk. Ruby и Python намного легче изучить и принести новым программистам до скорости с.
Исторически, основные реализации Smalltalk были довольно дорогими и нуждались в экзотических аппаратных средствах для выполнения, как видно эта сеть lang.st80, отправляющая с 1983 . Windows 3.1, NT и '95 и ОС/2 были первыми операционными системами массового рынка на основных аппаратных средствах, способных к поддержке реализации Smalltalk с достойной собственной системной интеграцией. Ранее, Mac или аппаратные средства рабочей станции были самыми дешевыми платформами, способными к выполнению Smalltalk эффективно. Некоторые реализации (особенно Digitalk) поддерживали операционные системы ПК вполне хорошо и действительно преуспевали в том, чтобы нарастить некоторые обороты.
Однако ОС/2 никогда не была, что успешный и Windows не достигал основного принятия до середины 1990-х. К сожалению, это совпало с повышением сети как платформа и большое маркетинговое нажатие позади Java. Java захватил большую часть доли завоеванного внимания в последней части 1990-х, представив Smalltalk немного вечный неудачник.
Ruby и Python работают в более стандартном наборе инструментальных средств и не сильно связываются к определенной среде разработки. В то время как IDE Smalltalk, которые я использовал, достаточно хороши, я использую PythonWin для разработки Python в основном, потому что это имеет хорошего редактора с подсветкой синтаксиса и не добирается ногами.
Однако Smalltalk, был разработан, чтобы использоваться с IDE (на самом деле, Smalltalk был исходный графический IDE), и все еще имеет некоторые хорошие функции, не копируемые другими системами. Тестирование кода с выделением и 'Шоу, это' является все еще очень хорошая функция, которую я никогда не видел в IDE Python, хотя я не могу говорить за Ruby.
Smalltalk несколько поздно приезжал к стороне веб-приложения. Ранние усилия, такие как VisualWave никогда не были ужасно успешны и только когда Побережье вышло, достойная веб-платформа получила принятие в кругах Smalltalk. Тем временем Java EE имел полный приемный жизненный цикл, запускающийся с бредящих фанатов, продвигающих его и наконец скучающих и добирающихся переходящий на Ruby;-}
Как ни странно, Побережье начинает получать немного доли завоеванного внимания среди знатока, таким образом, мы можем найти что поездки Smalltalk что цикл назад в популярность.
Однако Smalltalk является очень хорошей системой, после того как Вы разработали, как управлять им.
Я думаю, что САМОЕ БОЛЬШОЕ различие - то, что Ruby намного более подобен жемчугу с точки зрения USEAGE. Smalltalk никогда не получал точку опоры на языки "сценариев".
VM действительно прохладен, и я надеюсь, что рубин будет иметь что-то подобным ему так, мы можем рассматривать все на нашей ОС, которая записана в рубине как объект в пространстве памяти, однако до тех пор я просто наслаждаюсь кратким, коротким синтаксисом Ruby, способность просто записать крошечный сценарий и снова использовать его позже. Ruby получил все преимущества жемчуга, и ООП намного более подобно smalltalk, чем взлом ООП perl.
Я думаю, что часть проблемы является development-environment-is-the-runtime. Это дает много питания, но оно также представляет большую кривую обучения.
Здесь привет мировое учебное руководство.
Это очень отличается от других языков, где я просто должен знать, как открыть текстовый редактор и копию и текст вставки, совершите нападки, сохраняют и запускают компилятор. Я должен знать, как использовать среду. То учебное руководство даже не показывает мне, как создать основную программу (который вероятен больше отказ того учебного руководства), что я могу работать.
существует определенно более высокая стоимость просто получения вещей, идущих, чем большинство других языков.
Большинство языков имеет некоторый хороший привлекательный код, который они могут представить. Я не видел это с Smalltalk. Я также думаю, что существует некоторое клеймо к Smalltalk, потому что это было вокруг такого длинного, и это все еще относительно неясно.
Используйте Ruby, потому что он имеет, мог бы иметь бизнес-участки, Smalltalk не делает.
я могу сказать Вам от личного опыта. Все еще с помощью Smalltalk, любите его, и использовали пару разновидностей. Хотя Smalltalk является большим языком и является всем, что Вы упомянули, Вы, привычка, вероятно, убеждает среднего директора по информационным технологиям/технического директора использовать Smalltalk на новом проекте. Конечно, Вам могло бы даже быть нелегко убеждать консервативного директора по информационным технологиям/технического директора использовать Ruby. В конце необходимо быть очень осторожными, если Вы хотите поддержанную долгосрочную коммерческую поддержку и способность найти не уличных сотрудников, которые могут поддерживать Ваши системы в будущем. Как пример, Smalltalk был действительно большой вещью в начале 90-х и IBM, которую инвестируют в большой степени в него в конце 90-х. Поскольку IBM Smalltalk была следующим языком для всех бизнес-приложений. IBM поместила Smalltalk на все включая их мейнфреймовые системы. Java стал популярным, принял рынок, и Smalltalk стал нишевым плеером. Более чем год назад IBM вывела язык (их термин является закатом). Кроме того, смотрите на Историю. ParkPlace и Digitalk, где первые главные коммерческие плееры на арене Smalltalk, они объединились и затем обанкротились.
Поскольку дистрибутивы Smalltalk были оценены в кратных числах $1 000, тогда как Ruby свободен.
Ruby к Smalltalk, как Арабские цифры к Римским цифрам. Та же математика, более легкий синтаксис.
Я сделал немного Smalltalk - IDE является одной вещью, которую я помню - Ruby имеет хорошую поддержку IDE?
Для меня не так случай того, что Ruby имеет, но что не имеет Ruby. И вещью, которую это не имеет, является потребность в VM и полной среде.
Smalltalk является большим - где я изучил понятия OO, но для простоты использования я иду для Ruby. Я могу написать код Ruby в своем любимом редакторе и выполнить его, формируют командную строку.
Так, для меня, это - то, что я выбираю Ruby over Smalltalk.
Угадайте, кто сказал это? (кавычка близка, возможно, не точна): "Я всегда думал, что Smalltalk победит Java. Я просто не знал, будет ли назван 'Ruby', когда он сделал так".
Барабан....
...
Ответ... Kent Beck
Я думаю все, кто работал с Ruby, некоторое время распознает его глубокий долг Smalltalk. Как один из этих людей, что мне нравится приблизительно Ruby по Smalltalk? Я думаю от строго перспектива языка, это - сахар. Ruby является сознательно очень сладким синтаксисом языком, тогда как Smalltalk является очень минимальным синтаксисом языком. Ruby является по существу объектной моделью Smalltalk с сахаром синтаксиса Perlish. Я, оказывается, люблю сахар и нахожу, что он делает программирование большего количества забавы.
Вы ответили на вопрос в своей первой строке: "Ruby становится популярным"
я сказал бы, превосходит ли один язык, другой не важен.. Как пример, PHP не может быть "лучшим" языком никогда, но я все еще рассмотрел бы использование его по Ruby on Rails ("лучший" инструмент для создания веб-сайтов), потому что это настолько широко распространено.
В основном, определенные за и против языка намного менее важны, чем все окружающее его - а именно, сообщество.
Сообщество! Ruby и особенно направляющие имеют такое великое сообщество. При бездельничании с smalltalk казалось, что не было, поскольку много экранов бросают, статьи, сообщения в блоге, и т.д. записанные о Smalltalk.
Ruby является текущим языком шума. Легче продать программное обеспечение, созданное с ним прямо сейчас, чем язык, разработанный в 70-х.
Smalltalk: люди вперед ifTrue: [думайте] ifFalse: [не думая]
Ruby: люди думают вперед, если взгляды назад
1) подобный RPN поток управления Smalltalk сообщениями не похож на Lisp - это - постоянные и спокойные, но weirds люди.
2) Ruby позволяет людям написать код с помощью идиоматического способа, которым люди говорят - действительно болтают если существует причина не к.
обновление переписало образец Smalltalk, чтобы на самом деле быть большим количеством свода законов..
Stephane Ducasse имеет некоторые замечательные книги Smalltalk в наличии здесь:
http://stephane.ducasse.free.fr/FreeBooks.html
поэтому, хотя сообщество Smalltalk столь же не плодотворно работает как Ruby и сообщества направляющих, там существует все еще некоторая большая справка.
то, что Ruby имеет тем Smalltalk, не делает?
я думаю, Ваша точка хорошо взята. Как друг однажды выразился, Ruby мог бы быть "старым вином в новой бутылке" в отношении Smalltalk. Но иногда новые вопросы бутылки. Вино должно быть в правильном месте в нужное время.
Это верно, что языки очень подобны. Мелкий способ интерпретировать, который должен назвать Ruby кавер-группой Smalltalk. Более разумная интерпретация - то, что закрытая система Smalltalk изолировала его, в то время как участие Ruby в экологии Unix и привычке к адаптации функций с каждого языка под солнцем дает ему бесконечно более нежную кривую принятия и легкую интеграцию с kickass инструментами как Мерзавец.
Я сказал бы противоположное: синтаксис Smalltalk является одним из самых простых и мощных синтаксисов языка программирования.
Я думаю, что Ваш вопрос несколько упускает суть. Вы не должны выбирать, Вы должны учиться их обоих!
, Если Вы действительно в состоянии, что можно выбрать следующую платформу (vm, инфраструктура) затем, Вам нужно к решительному, что использовать и можете задать конкретный вопрос с за и против с точки зрения того, что Ваше приложение является inteded, чтобы сделать.
я использовал smalltalk (любите его), и рубин (любят его).
Дома или для проекта с открытым исходным кодом я могу использовать каждый язык, который я люблю, но при выполнении работы я должен принять.
я начал использовать рубин (на работе), потому что нам был нужен некоторый язык сценариев, который вел себя более или менее одинаково под solaris, Linux и окнами (98,2000, xp). Ruby был в то время неизвестен среднестатистическому американцу и там не существовал никакие направляющие. Но было легко продать всем вовлеченным.
(Почему не Python? истина? Я однажды провожу неделю, ища для ошибки, которая произошла, когда терминал преобразовал мое пространство во вкладку, и предположение было испорчено).
, Таким образом, люди начали кодировать все больше в рубине, потому что он так ослаблялся, обладая и не облако на небе.
, Это верно, конечно, что большинство людей не выбирает языки программирования просто на основе их достоинств. Большинству программистов говорят что язык использовать кем-то еще.
и
, Чтобы быть привлекательным для хакеров, язык должен быть хорош для записи видов программ, которые они хотят записать. И это означает, возможно, удивительно, что должно быть хорошо для записи одноразовых программ.
И когда были в земле Lisp, пытаются заменить LISP библиотеками smalltalk
Ruby’s, сообществом, и импульс хорош
Поэтому, если LISP еще более мощен, чем Ruby, почему бы не использовать LISP? Типичные возражения на программирование в LISP:
- Там aren’t достаточно библиотек.
- Мы can’t нанимают программистов LISP.
- LISP никуда не пошел за прошлые 20 лет.
Эти aren’t подавляющие возражения, но they’re, конечно, достойный рассмотрения.
и
Теперь, учитывая выбор между мощным языком и популярным языком, может иметь превосходный смысл выбирать мощное. Но если различия в питании незначительны, быть популярным имеет все виды хороших преимуществ. В 2005 I’d хорошо подумали перед выбором LISP over Ruby. I’d, вероятно, только делают это, если мне был нужен оптимизированный код или макросы, которые действовали как законченные компиляторы.
Когда я покидаю свой дом утром для движения в работу, я часто борюсь с решением сделать левый или правый поворот из моего диска путем (я живу посреди улицы). Так или иначе получит меня моему месту назначения. Один путь приводит меня к магистрали, которая, в зависимости от трафика, вероятно, получит меня в офис самое быстрое. Я добираюсь для управления очень быстро, по крайней мере, для части пути, и у меня есть хороший шанс наблюдения симпатичной девочки или два на их способе работать :-)
, другой путь позволяет мне путешествовать вниз очень очаровательная, ветреная проселочная дорога с полным лесным покровом. Тот путь довольно приятен, и двух подходов определенно более забавное, хотя это означает, что я доберусь до офиса позже, чем у меня был бы я взятый магистраль. Каждый путь имеет свои достоинства. В дни, что я спешу, я буду обычно брать магистраль, хотя я могу столкнуться с трафиком, и я также увеличиваю свои возможности того, чтобы попасть в аварию (если я не осторожен в своей поспешности). Другие дни я могу выбрать древесный путь и ехать, наслаждаясь пейзажем и понять, что работаю поздно. Я могу попытаться убыстриться, повысив мои возможности получения билета или порождения несчастного случая сам.
Никакой путь не лучше, чем другой. Каждый из них обладает их преимуществами и рисками, и каждый получит меня к моей цели.
Я бы пошел дальше ответа Йонке и сказал, что сейчас существует большое количество языков, которые имеют очень сильное сообщество, почти на любой вкус, и некоторые из них получили широкое признание. (т.е. ваш менеджер позволит вам использовать их и на работе).
Выучить основы языка легко, но для того, чтобы использовать его эффективно, вам нужно потратить достаточно времени на изучение платформы и инструментов, а также как синтаксис и идиомы. IIRC, МакКоннелл утверждает, что требуется около трех лет, чтобы стать по-настоящему профессиональным.
Учитывая эти вещи, трудно оправдать тратить много времени на такие языки, как LISP и Smalltalk, хотя они интересны и, возможно, образовательны. 11958]
Интересная точка зрения Роберта Мартина (из RailsConf 2009): «То, что убило Smalltalk, могло убить и Руби»
I love both Smalltalk and Ruby - but have found that Ruby is more applicable to what I do daily, and is closer to my heart (practically speaking). What does Ruby offer that Smalltalk doesn't?
Some have mentioned gst (GNU Smalltalk); the problems still hold.
Бьет меня. Я потратил год на изучение Ruby и выполнение нескольких небольших проектов, чтобы увидеть, насколько он мне понравился. Думаю, я фанат Smalltalk, потому что каждый раз, когда я садился работать с Руби, я вздыхал и думал: «Я бы предпочел делать это на Smalltalk». В конце концов я сдался и вернулся к Smalltalk. Теперь я счастливее. Чем счастливее, тем лучше.
Что, конечно, вызывает вопрос: «Почему?». В произвольном порядке:
С другой стороны, это может быть просто бред человека, который программировал с тех времен, когда мэйнфреймы правили землей, нам приходилось идти пять миль, чтобы работать сквозь ослепляющие снежные бури, подниматься в обе стороны и компьютеры использовали пончики на память. Я ничего не имею против Ruby / Java / C / C ++ /, все они полезны в контексте, но дайте мне Smalltalk или дайте мне ... ну, может мне стоит выучить Lisp или Scheme или ...: -)
С другой стороны, это может быть просто бред человека, который программировал с тех времен, когда мэйнфреймы правили землей, нам приходилось идти пять миль, чтобы работать сквозь ослепляющие снежные бури, подниматься в обе стороны и компьютеры использовал пончики на память. Я ничего не имею против Ruby / Java / C / C ++ /, все они полезны в контексте, но дайте мне Smalltalk или дайте мне ... ну, может, мне стоит изучить Lisp или Scheme или ...: -)
С другой стороны, это может быть просто бред человека, который программировал с тех времен, когда мэйнфреймы правили землей, нам приходилось идти пять миль, чтобы работать сквозь ослепляющие снежные бури, подниматься в обе стороны и компьютеры использовал пончики на память. Я ничего не имею против Ruby / Java / C / C ++ /, все они полезны в контексте, но дайте мне Smalltalk или дайте мне ... ну, может мне стоит выучить Lisp или Scheme или ...: -)
и т. д.) больше не существует, поэтому вам нужно узнать что-то новое. У всего вышеперечисленного (и не только) есть эквиваленты, но вам придется научиться думать по-другому. Другое - хорошо.С другой стороны, это может быть просто бред человека, который программировал с тех времен, когда мэйнфреймы правили землей, нам приходилось идти пять миль, чтобы работать сквозь ослепляющие снежные бури, подниматься в обе стороны и компьютеры использовали пончики на память. Я ничего не имею против Ruby / Java / C / C ++ /, все они полезны в контексте, но дайте мне Smalltalk или дайте мне ... ну, может мне стоит выучить Lisp или Scheme или ...: -)
и т. д.) больше не существует, поэтому вам нужно узнать что-то новое. У всего вышеперечисленного (и не только) есть эквиваленты, но вам придется научиться думать по-другому. По-другому - хорошо.С другой стороны, это может быть просто бред человека, который программировал с тех времен, когда мэйнфреймы правили землей, нам приходилось идти пять миль, чтобы работать сквозь ослепляющие снежные бури, подниматься в обе стороны и компьютеры использовали пончики на память. Я ничего не имею против Ruby / Java / C / C ++ /, все они полезны в контексте, но дайте мне Smalltalk или дайте мне ... ну, может, мне стоит изучить Lisp или Scheme или ...: -)
С другой стороны, это может быть просто бред человека, который программировал с тех времен, когда мэйнфреймы правили землей, нам приходилось проходить пять миль, чтобы работать через ослепляющие снежные бури, подниматься в обе стороны, а компьютеры использовали пончики для памяти . Я ничего не имею против Ruby / Java / C / C ++ /, все они полезны в контексте, но дайте мне Smalltalk или дайте мне ... ну, может, мне стоит изучить Lisp или Scheme или ...: -)
С другой стороны, это может быть просто бред человека, который программировал с тех времен, когда мэйнфреймы правили землей, нам приходилось идти пять миль, чтобы работать через ослепляющие снежные бури, подниматься в обе стороны, а компьютеры использовали пончики для памяти . Я ничего не имею против Ruby / Java / C / C ++ /, все они полезны в контексте, но дайте мне Smalltalk или дайте мне ... ну, может, мне стоит изучить Lisp или Scheme или ...: -)
Вы можете довольно легко найти работу, используя Ruby. Хотя я очень люблю Smalltalk, попасть в нишу Smalltalk практически невозможно. Здесь есть обходной путь, но если вы не попали в него, когда он был популярен, сейчас это практически невозможно.
Все остальные причины блекнут на второй план, потому что вам нужно потратить много времени, сосредоточившись на реальной работе, чтобы выучить язык правильно. Если вы сами не богаты, лучший способ сделать это - познакомиться с этим на работе.
Как опоздавший к обсуждению, основная проблема Smalltalk и Lisp заключается в том, что вы не можете запускать их с CGI или FastCGI на общем хостинге.
Немытые массы никогда не воспользуются ими, если для их использования им понадобятся VPS или выделенные серверы. IMHO Seaside превосходит все остальные, но будет ли он работать на Dreamhost или Webfaction?