Подтвердить что ты не робот

Что вас больше всего пугает в интегрированной среде разработки большинства современных Smalltalks?

Как я верхом на волне возрождения Smalltalk (особенно потому, что многие люди Ruby-on-Rails заново открывают Smalltalk и видят Seaside в качестве следующей обновленной веб-структуры), у меня возникают вопросы типа "да", но как использовать мой любимый редактор для редактирования кода Smalltalk? "или" Does Smalltalk все еще настаивает на том, чтобы жить в собственном мире?".

Теперь впервые испытав Smalltalk еще в 1981 году, я не очень хорошо понимаю эти вопросы. Кажется довольно естественным, что я хочу, чтобы редактор и отладчик были подкованны к моему текущему состоянию кода и интегрировались с системой управления изменениями, которая известна Smalltalk. Использование внешнего редактора или отладчика или менеджера управления изменениями будет казаться очень неудобным.

Итак, что вас больше всего пугает, когда вы не можете редактировать пятистрочные методы в Smalltalk с помощью своего любимого редактора или использовать свою любимую систему управления изменениями, отличную от Smalltalk?

4b9b3361

Ответ 1

Все по-другому. Хотите пойти в конец линии? Это не Ctrl-E. Хотите сложить несколько слов, словом? Это не Мета-F....

Текстовое редактирование - это фундаментальное программирование. Мессинг с этими входами возится с чем-то глубоко в моем сознании.

Изменить: здесь кто-то запрашивает привязки ключей emacs на comp.lang.smalltalk в 1987 году.

Ответ 2

Меня не пугает, в частности, но я нашел разработку API в VW немного сложной, даже когда я использовал другие мелкие вещи. Эффект браузеров заключается в том, что вы склонны видеть API немного за раз, и довольно часто это не сразу становится очевидным, когда вы должны искать определенную функциональность.

Smalltalk также немного страдает от сдвига парадигмы, чтобы понять, как это работает. Когда я занимался бакалавром в университете (через некоторое время после того, как я впервые встретился с Smalltalk), мне пришлось немного поработать над тем, чтобы наблюдать за всеми остальными в классе, преодолевая первоначальный горный парадигм, когда они изучили систему (Squeak) для первого время.

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

Кроме того (и, к сожалению), Java появилась в середине 1990-х годов и захватила весь ум. Крупные Smalltalks либо полностью умерли, либо были проданы ничьим игрокам. Это довольно иронично (в счастливой манере), что Руби служил для повторного пробуждения интереса к Smalltalk, но затяжное восприятие устаревания "сдержанный" не помогает.

См. Это мое сообщение для некоторого представления о достоинствах (как я их вижу) о том, что в этот день и возраст сильно вовлечен в Smalltalk.

Я был бы очень рад вернуться в Smalltalk, если бы возникла такая возможность.

Ответ 3

Единственный Smalltalk, с которым я проводил время, - Squeak, поэтому мои представления могут не применяться к другим средам Smalltalk.

Что касается меня в отношении подхода на основе изображений, так это то, что, хотя у вас есть замечательные вещи в среде Smalltalk, это огороженный сад, который затрудняет взаимодействие с чем-либо вне этой среды. Например, что, если я хочу использовать внешние инструменты, такие как Yacc и Lex? Что делать, если я хочу использовать некоторые программы C или Python для генерации кода Smalltalk? Что делать, если я хочу смешивать Smalltalk с кучей кода, написанного на других языках, редактируя код на всех этих языках в одном редакторе и сохраняя его в одном и том же дереве исходного кода?

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

Ответ 4

Один большой шоу-стоппер для меня - это тот код, который я пишу один Smalltalk VM, после всех этих лет несовместим с другими Smalltalk VM.

Я понимаю, почему это так: ядро ​​Smalltalk - чрезвычайно маленький набор аксиом и ключевых слов. Это означает, что после 30 минут обучения Smalltalk вы уже изучаете библиотеку API, а не язык. Мне нравится этот подход к языковому дизайну.

Все, что все сводится к тому, что в мире Smalltalk заключается в том, что, если не будет достигнуто консенсус между всеми поставщиками VM, чтобы иметь общую базовую стандартную API, мой код Smalltalk, написанный для одной виртуальной машины, почти наверняка не будет работать на других VM, когда я решил переключиться.

Это также имеет следствие обрезки части моего знания пространства при переключении виртуальных машин.

Заметьте, что я едва попробовал Smalltalk в своей жизни. Я далеко не специалист. Это понимание происходит от разговоров с Джеймсом Робертсоном около месяца назад.

Еще один момент, который я хотел бы сделать, - это то, что Seaside действительно работает на самых популярных виртуальных машинах Smalltalk. Интересно, сколько (что должно было быть) стандартного API, который им приходилось создавать для достижения этого успеха.

Со всем сказанным, у меня всегда есть ухо, чтобы больше узнать о состоянии Smalltalk. Я хочу попробовать Smalltalk очень мощную среду разработки (и другие ее достоинства).

Ответ 5

Я знаю это поздно, но самая большая досада для меня заключается в том, что на самом деле нет хорошего редактора ни в одном из мелких предметов. Это я не могу понять. Работа с текстом настолько существенна, что меньше "поддерживается"....

Это всегда так просто смотреть на один метод, а затем вам нужно найти какой-нибудь поисковик методов или другой браузер, чтобы проверить другой метод. Это то, что мне действительно не нравится....

Ответ 6

В то время как ограниченная среда Smalltalk делала такие вещи, как полагаясь на управляемую базой данных систему управления версиями, иногда, когда другие языки все еще боролись с наличием надлежащего редактора, она делает интеграцию очень тяжело в сегодняшние времена.

С такими инструментами, как Eclipse или Team Foundation Server, вы так привыкли к тому, что все инструменты интегрируются друг с другом. Например. если требование создано, оно автоматически связано с наборами изменений, которые программист выполняет для реализации этого требования. Это "разрыв границ" между ранее используемыми инструментами практически невозможно в мире Smalltalk, но с большими проектами, большими командами, более высоким уровнем абстракции и т.д. Вам нужны инструменты, которые являются более чем причудливым редактором и помогают вам в полной разработке программного обеспечения жизненный цикл.

Ответ 7

Нет никакой полезной поддержки для навигации с помощью клавиатуры или поддержки пользовательского интерфейса платформы.

В то время как это правда, вам действительно не нужен невероятный текстовый редактор (хорошо написанный) Smalltalk, способный перемещаться по окружающей среде, сохраняя при этом руки на клавиатуре, весьма полезен (и в моем случае необходим для сокращения RSI). Я просто пытался инспектировать VisualWorks, и клавиши со стрелками даже не работали правильно, чтобы перемещаться вверх и вниз по списку. Когда я попал в пробел, я получил прогулку. Вздох.

Ответ 8

В мире Windows нет ничего похожего на Dolphin Smalltalk. IDE фантастичен. Другой качественный продукт, если вы хотите попробовать, - это Visualworks, он работает хорошо, имеет очень быструю виртуальную машину, и документация очень хорошая.

Я использовал оба в прошлом, нечего бояться.