Здравствуйте, Курилка, Вы писали:
C>>Не поднимали. Emacs лучше Borland C++, но уже хуже MSVS версии так седьмой. К>Чтот у меня не сходится: вроде речь про середину 90-х, а седьмая студия — это уже .Net (ещё без цифры) и 2002-й год. Кто-то что-то тут не то К>Да даже 6.0 ито лишь в середине 98-го появилась.
Да, это я говорю уже про конец 90-х.
К>А с емаксом, подозреваю, что вопросы были в том, насколько он был под винду юзабелен в то время (сам не в курсе).
Вполне юзабелен был.
Здравствуйте, dr.Chaos, Вы писали:
DC>Здравствуйте, maxkar, Вы писали:
DC>Ну, во-первых, спасибо за содержательный ответ .
M>>А можно ваше определение рефакторинга? Это то, что "делается перед внесением фичи, чтобы облегчить этот процесс"?. Просто если использовать, например, определение из wiki (которое более широкое, чем ваше), у меня получается, что как раз таки большая часть рефакторингов делается не перед внесением фичи а во время или сразу после внесения фичи, после изменения кода. Я в дальнейшем буду использовать термин "рефакторинг" для обозначения "изменения программы без изменения ее фунциональности (или внешнего поведения) с целью улучшения ее качества" (вольный перевод wiki). Если вас не устраивает — готов использовать другое название, только предложите Именно для того определения, которое я привел. Потому что такая активность существует и хочется как-то ее называть.
DC>Время когда и для чего рефакторинг совершается никак не влияет на его определение. Я думаю на вопрос руководителю: "Я хочу здесь переделать, часы дашь?", будет вполне разумный вопрос: "А зачем тебе потребовалась переделка?" Т.е. упрощение кода служит довольно прагматичным целям, а вовсе не эстетическим чувствам программиста.
С прагматичными целями согласен. Одна из моих целей — сэкономить время при последующем чтении. Чтобы код читался "линейно", без остановок, возвратов назад и т.п. Желательно — на "повышенной скорости, по-диагонали". Это в целом даже более актуально, чем подготовка всего кода к дальнейшему изменению. Потому, что чтобы сделать изменение, сначала нужно найти то место, в котором это изменение должно быть. При практически нулевых затратах на улучшение сейчас это может принести ощутимую выгоду в дальнейшем. Серьезные (и длительные) преобразования, действительно, делаются по согласованию с менеджерами, в том числе с учетом возможных путей дальнейшей эволюции, вероятности внесения багов, сложности поддержки и т.п. Но не пойду же я к менеджеру с вопросом "а вот у меня здесь сложная формула, я хочу из нее выделить подвыражение и назвать его. Можно я потрачу на это 1,5-3 секунды?".
Как уже писал, читаемость — достаточно субъективный вопрос. Но пока что мой опыт показывает, что те рефакторинги, которые я применяю, полезны не только мне. Из опыта. Я провожу ревью кода других разработчиков. После прохождения "первой ступени" (правильное использование библиотек, нормальный дизайн, проверка граничных случаев там, где надо и т.п.) я начинаю обращать внимание на читаемость (до прохождения того этапа занматься читаемостью особого смысла не вижу). По стилю кода и читаемость замечания даются даже на в "рекомендательной" форме ("лучше делать так потому, что") а в форме альтернативы ("я бы сделал так то, потому что мне кажется, что.../мне удобнее..."). Получалось так, что те программисты тоже в дальнейшем начинали использовать указанный стиль (и по ревью заметно, и в беседе сами говорили, что так действительно удобнее). Ну и еще видел программистов, которые сразу же в том стиле пишут (и формулируют "критерии" точно так же, как и я).
Вопрос про определение был задан не с целью придраться и т.п. Мне просто стало интересно, мы расходимся в определениях или вы просто не используете ряд практик, которые использую я (эти практики и описал далее).
M>>1. "Extract variable"... M>>2. "Introduce constant"... M>>3. "Extract method"... M>>4. "Rename something"...
DC>Ээээ.... И это все возможности что предоставляет IDE?
Нет. Совсем далеко не все. Это "рефакторинги, которые часто используются при написании (сразу после написания) кода".
1. Здесь не приведены "quick fix", которые используются при написании кода (в eclipse они не попали в рефакторинги). Применяются, опять же, с целью улучшения читаемости. Это "invert if/conditional", "replace if with conditional", "change method signature" (вызов метода с отличающейся сигнатурой, позволяет добавить параметр/параметры прямо из точки вызова), "create method" (не уверен, что именно так называется. Заводит несуществующий метод по его вызову в коде). Последнее хочется отметить особо — оно и "extract method" у меня являются единственными источниками private-методов. Ну т.е. private ... ... (...) я пишу только в vim и т.п. В IDE же либо сначала пишется вызов, либо метод образуется из уже существующего кода. Исключений не помню (хотя, возможно, и были).
2. Здесь не приведены рефакторинги, которые используются "перед" написанием кода (т.е. подготовка к исправлениям/внесению функциональности).
3. Здесь нет рефакторингов, которые "не используются". Мною, естественно. Возможно, кто-то другой использует те рефакторинги.
4. Не приведены рефакторинги, которые используются при написании кода, но редко. Вообще не помню, что из этой категории бывает. Хотя, например, "change method signature", наверное. "Move methods up/down" с некоторой натяжкой тоже.
5. Не приведены возможности анализа. Это деревья вызовов, поиски вхождений (не текста, а именно поля/функции). Outline. Переходы к реализации из кода, переходы к родительским определениям из кода. Открытие ресурса или класса по имени (не нужно ходить по файловой системе). Документация в outline (как документация к текущему вызову так и набираемый javadoc). Документация при code completion (ага, очень удобно смотреть, как обрабатываются граничные условия не ходя далеко). Отметки "на полях" для проблем, специальных комментариев (TODO и т.п., настраиваются), элемента под курсором (поля/метода).
За исключением п. 3 всеми этими возможностями я пользуюсь. Вероятно, есть еще какая-то часть, которую я забыл, и есть части, которыми я не пользуюсь (ну например, отладчиком пользуюсь очень редко).
DC>Т.е. ты хочешь сказать что эти 4 приёма являются полным и непротиворечивым базисом для совершения любого рефакторинга?
Да ни в коем случае. Это "контрпример" к утверждению "рефакторинги выполняются пред правкой бага/внесением изменения". Не более того. А вдруг у вас все то же используется, но только называете вы его по-другому? Да, и заодно это был "контрпример" к утверждению "IDE являются костылями к недостаточной выразительности языка программирования" (не ваше утверждение, но пример и на него отвечает).
M>>Немного напишу про упомянутцй "expand selection", который используется для 1-го и 3-го рефакторингов. Это расширение существующего выделения на логические блоки кода, уже содержащего выделение. Возможный пример для ocaml'а: исходная конструкция let a = if b > 0 then c + d else let e = c-d in e * e, исходное выделение — первая e в выражении e * e. Выделения при очередных расширениях:
M>>Ну и напоследок про «перераспределить обязанности между классами и один из них, возможно, выкинь». В таком виде рефакторинга нет. Он будет выполняться с помощью нескольких более простых. А вот в каких терминах мы будем работать при этих мелких рефакторингах — это большой вопрос. Можно таскать "куски текста" (понимая под этим перемещение метода, например). Только вот при этом нужно контролировать, что все зависимости утянуты и т.п. Возможно, метод менять (если часть методов осталось в одном классе, а часть уехала). А можно сказать, что "вот этот метод должен уехать в тот класс". При этом IDE может проверить зависимости (например, скажет, что ссылки остались на приватный метод и видимость ему нужно поменять), сама поменяет все ссылки на функции в исходном коде. При перемещении метода вверх в иерархии классов можно одним кликом сказать "добавить зависимости", проверить их и продолжить операцию. Ну да, наверное, все равно какие-то мелочи придется сделать "в тексте руками". Но если не все плохо, это будет малая часть. А большая часть будет в реорганизации структуры, фрагментов программы.
DC>Т.е., в итоге, ты предлагаешь писать код так чтоб в IDE было удобно выделять этот код, а IDE было удобно с ним работать?
Нет. Я предлагаю писать код так, чтобы его было удобно читать (работать с кодом) и он при этом выполнял поставленные задачи. IDE в этом помогает. О сложностях IDE при разборе кода я совершенно не забочусь, она как-нибудь справится. Все перечисленные ранее (и в прошлый раз, и сейчас) возможности не требуют от меня каких-либо специальных действий для их работы (специального оформления, специальной разметки и т.п.). А все потому, что IDE тоже работает не с текстом, а со структурой программы, так же, как и я.
DC>Когда ты говоришь что IDE тебе даёт "высокоуровневые операции для манипуляции над программой" ты не прав, все высокоуровневые манипуляции над программой тебе даёт твой мозг, а IDE тебе облегчает только маленькую часть из них, и самое плохое что набор операций маленький и нерасширяемый, т.е. ты, в итоге, начинаешь думать над переделкой дизайна в терминах того что предоставляет IDE. А если ты забиваешь на эти рамки, то получается что у тебя просто набор манипуляций над текстом программы, а в этом плане vim даст 100 очков форы.
Ну так мне это и нужно! Пускай операции мне дает мозг. Но ведь IDE понимает меня именно в моих терминах! Она понимает команду "перемести метод туда". Ей не надо это разжевывать в качестве последовательности низкоуровныевых команды (выдели, перемести, добавь иморт туда). Да, многого она не понимает, но базовые частые команды она значет хорошо. У меня есть уровни "библиотека или программа"/"пакет"/"класс"/"поле или метод"/"алогоритм реализации метода"/"текст, которым записан алгоритм". И я общаюсь с IDE на том уровне, на котором хочу (да, приходиться работать на разных уровнях). Чистые "текстовые преобразования" я при необходимости тоже делаю. Обычно в vim'е . Помню, как в нем последовательностью замен по регулярным выражениям из одного куска кода делал другой. Можно было бы и в IDE это сделать, но vim'овский сиснтаксис выражений я помню, а IDE-шный еще читать нужно было (оно там есть, все то же я мог бы сделать сразу из eclipse).
И не даст vim 100 очков форы как только дело коснется операций над "логическими единицами программы". Банальный пример. Пусть у нас есть семейство каких-либо форматов, которые мы разбираем. Есть format1.Parser.parse(...), format2.Parser.parse(...), ..., format15.Parser.parse(...). Все функции parse — статические. Где-то в коде могли использоваться через Parser.parse (с импортами), где-то — через статические импорты. В одном коде могли использоваться несколько парсеров. И вот мы решили переименовать format8.Parser.parse() в format8.Parser.parseOldFormat(...) и завести format8.Parser.parseNewFormat(...) (Ну, с целью улучшения читаемости). Как это "безболезненно" сделать в vim'е? Ну так, чтобы переименовалось ровно то, что нужно? Напомню, есть статические импорты и разные обращения (а еще где-то тоже может определяться свой метод parse, который скрывает импортированный статически метод). Ну да, данный пример немного надуман. Но в реальных проектах подобная ситуация вполне возможна — всякие filter/find(condition)/adapt и прочие утилитарные методы, которые плодятся по "похожим сервисам". А в IDE вся операция переименования — безболезненная и достаточно безопасная (баги в переименовывалке я не встречал). Причем если будет место для потенциальных конфликтов в результате переименования (изменится семантика "текста"), IDE меня предупредит, покажет список всех изменений (preview) и заставит его подтвердить.
С "нерасширяемым" набором тоже не соглашусь. В текстовом редакторе он тоже "ограниченный". Ну ладно, notepad рассматривать не будем (там эта проблема совсем не лечится). В vim'е можно написать скрипт, забиндить клавиши, это уже "расширение" IDE. Ну так подобным способом можно и eclipse расширять. Вот недавно обнаружил в eclipse функцию "create refactoring script", которая по проведенным ранее рефакторингом может какой-то скрипт делать. Подробнее не изучал, не за чем было. Но это все мелочи. При желании можно написать плагин (ага, на java, на которой я и так пишу) и там реализовать все те "высокоуровневые" операции, которые мне нужны. И что замечательно — при реализации плагина я получу все бонусы от работы с "высокоуровневой" моделью кода, мне не придется вручную разбирать, кто же откуда импортирован и вообще как парсится кусок текста (на случай экзотических записей и т.п.). Вот, например, модель java, с которой я могу работать при написании плагина (рефакторинги и т.п.). При желании я могу работать и с текстом, не используя эту модель (используя модель текстового редактора).
В общем, высокоуровневость при возможности перейти на нижний уровень — это совсем даже не плохо. Да, ее можно использовать для решения не тех задач, для которых она предназначена. Но не использовать ее только по этой причине — неправильно. А иначе придется отказаться почти от всего и писать на ассемблере. А что? OСaml, например, не дает мне сделать то, что дает делать низкоуровневый C (segfault, например). Ну так давайте от caml'а откажемся. А потом и от C откажемся, так как в нем нет, например, команд mmx. А в assembler'е — есть! Так что для каждой задачи — свой инструмент.
P.S. Написал, и понял, что пример с переименованием метода parse в vim'е можно сделать "достаточно безопасно". Потому что существует интеграция eclipse в vim (наоборот тоже существует, но не интересна). Т.е. vim выступает в качестве front-end'а к запущенному в качестве back-end'а eclipse. И есть у меня подозрения, что переименование в данном случае прошло бы относительно безболезненно. Но вот только в этом случае мы бы получили уже не текстовый редактор, а "полноценную" IDE.
Здравствуйте, metaprogrammer, Вы писали:
M>>> IDE были не нужны, и вдруг разом стали нужны, так что ли? C>>Не совсем. До где-то середины 90-х сложные IDE были невозможны на x86 технически. Но даже простые IDE типа Turbo Pascal'а/Borland C++ уже в ту пору рулили.
M> Да ну, какие это на фиг IDE? Редактор с запускалкой компилятора и хелпа и подсветкой ошибок. Ничего из того, о чём тут говорит Влад, там и близко не было. Никакого автоматизированного рефакторинга, никакого автокомплита и прочих сомнительных прелестей.
Надо сравнивать с тогдашними реалиями. Тогда даже объединение всех средств работы с проектом в одном продукте уже было новшеством. Тогда люди в основном работали из консоли. В лучшем случае это был Нортон.
C>>Они просто подняли производительность труда и снизили планку входа.
M> А всякие там emacs на пару с sed и awk на ещё большие высоты поднимали производительность труда. И что?
Тогда у людей еще емаксов не было. Емакс вышел из стен МИТ-а где-то в 80-ых. ГНУтый емакс — это 1984. К тому же это штуковина на любителя.
VD>>>> То что тогда казалось подвигом, сейчас обычное дело. M>>> Примерчик можно? C>>Отладка кода в режиме ядра, к примеру. Сейчас я спокойно это делаю символьным отладчиком из IDE.
M> Это частности.
Это реалии жизни. Код тогда было писать сложнее. Задачи были примитивнее. Теперь код казалось бы писать проще, но сложность задач выросла многократно компенсировавав упрощение жизни.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Надо сравнивать с тогдашними реалиями. Тогда даже объединение всех средств работы с проектом в одном продукте уже было новшеством. Тогда люди в основном работали из консоли. В лучшем случае это был Нортон.
Даже если у человека на было денег на workstation, это скорее был бы Brief или KEDIT.
Но в то время уже давно (с середины 70-x) были, лисп-машины с настоящими IDE — на них, например, разрабатывали Smalltalk (Xerox Dorado и Dolphin). Using KEE (Knowledge Engineering Environment) on a Symbolics Lisp Machine(Еще ссылки тут).
VD>Тогда у людей еще емаксов не было. Емакс вышел из стен МИТ-а где-то в 80-ых. ГНУтый емакс — это 1984. К тому же это штуковина на любителя.
Нортон коммандера тем более еще не было — первая версия вышла в 86-ом)
Весь UNIX был написан в редакторе ed- это не было большой проблемой так как вместо мониторов были телетайпы
Из ed'а вышли sam(~80 год) and vi(76 год). Пользуясь sam, например, Страуструп написал С++. Торвальдс до сих пор пишет в MicroEMACS(85 год). Разумеется все они пользовались grep sed и awk.
Здравствуйте, VladD2, Вы писали:
C>>>Не совсем. До где-то середины 90-х сложные IDE были невозможны на x86 технически. Но даже простые IDE типа Turbo Pascal'а/Borland C++ уже в ту пору рулили.
M>> Да ну, какие это на фиг IDE? Редактор с запускалкой компилятора и хелпа и подсветкой ошибок. Ничего из того, о чём тут говорит Влад, там и близко не было. Никакого автоматизированного рефакторинга, никакого автокомплита и прочих сомнительных прелестей.
VD>Надо сравнивать с тогдашними реалиями. Тогда даже объединение всех средств работы с проектом в одном продукте уже было новшеством. Тогда люди в основном работали из консоли. В лучшем случае это был Нортон.
в середине 90-х? и медведи заглядывали в окна, как же без этого
простые ide (turbo pascal) появились в начале 80-х, года с 87-го в них стали появляться отладчики. в конце 80-х были turbo pascal, rurbo c++, quick msc, ms power bench, так что обычные программисты (те что сейчас пользуются msvs) были уже об-ide-чены. рефакторингов/автокомплитов действительно до середины 90-х я не видел
Здравствуйте, z00n, Вы писали:
Z>Но в то время уже давно (с середины 70-x) были, лисп-машины с настоящими IDE — на них, например, разрабатывали Smalltalk (Xerox Dorado и Dolphin).
smalltalk появился в начале 70-х, только речь наверно шла о массовых программистах. для них первой ide был наверно turbo-pascal. и это кстати одна из причин его бешеной поппулярности — цпрщение цикла edit-compile-lonk до "нажал кнопку и тебе показали место ошибки"
Здравствуйте, z00n, Вы писали:
Z>Здравствуйте, VladD2, Вы писали:
VD>>Надо сравнивать с тогдашними реалиями. Тогда даже объединение всех средств работы с проектом в одном продукте уже было новшеством. Тогда люди в основном работали из консоли. В лучшем случае это был Нортон. Z>Даже если у человека на было денег на workstation, это скорее был бы Brief или KEDIT.
Ага KEDIT. А далее выходишь в команд промт и давай батники вызвать. Сам так какое-то время работал.
И это был не очень удобно, как в прочем и тогдашний KEDIT.
Z>Но в то время уже давно (с середины 70-x) были, лисп-машины с настоящими IDE — на них, например, разрабатывали Smalltalk (Xerox Dorado и Dolphin).
А вот это уже чушь. Где они были то? У очень ограниченного круга людей имеющих доступ к очень дорогой аппаратуре. А простые смертные довольствовались фортраном или С с васиком в лучшем случае.
Z>Нортон коммандера тем более еще не было — первая версия вышла в 86-ом)
Дык все и работали в командной строке вплоть до 90-ых. Первые IDE как раз из нортона и вызвались.
Z>Весь UNIX был написан в редакторе ed- это не было большой проблемой так как вместо мониторов были телетайпы :)
Вот имнно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, BulatZiganshin, Вы писали:
VD>>Надо сравнивать с тогдашними реалиями. Тогда даже объединение всех средств работы с проектом в одном продукте уже было новшеством. Тогда люди в основном работали из консоли. В лучшем случае это был Нортон.
BZ>в середине 90-х? :))) и медведи заглядывали в окна, как же без этого :)
BZ>простые ide (turbo pascal) появились в начале 80-х, года с 87-го в них стали появляться отладчики. в конце 80-х были turbo pascal, rurbo c++, quick msc, ms power bench, так что обычные программисты (те что сейчас пользуются msvs) были уже об-ide-чены. рефакторингов/автокомплитов действительно до середины 90-х я не видел
А что собственно изменилось с 1983 (когда появилась первая IDE) до 1995-го когда появился первый интеллисенс (в распространненых IDE)? Подскажу — скорость процессоров. Ее стало достаточно для анализа кода в "реалтайме".
В середине 90-ых появились "Пни" т.е. первые пентиумы с 60-90 Мгц. Их даже не распаковку видео не хватало тогда. В конце же 90-ых машины уже легко справлялись с интелессенсом для простых языков.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>А что собственно изменилось с 1983 (когда появилась первая IDE) до 1995-го когда появился первый интеллисенс (в распространненых IDE)? Подскажу — скорость процессоров. Ее стало достаточно для анализа кода в "реалтайме". VD>В середине 90-ых появились "Пни" т.е. первые пентиумы с 60-90 Мгц. Их даже не распаковку видео не хватало тогда. В конце же 90-ых машины уже легко справлялись с интелессенсом для простых языков.
я так не думаю. во-первых, у большинства программистов стояли машины слабее. во-вторых, что по твоему — пни на 100% этим анализом загружались?
просто идёт постепенное развитие. ты предыдущую эпоху не застал, и тебе кажется, что is — это нечто принципиально новое и крутое. а в моей жизни это например была встроенная отладка
Здравствуйте, BulatZiganshin, Вы писали:
BZ>smalltalk появился в начале 70-х, только речь наверно шла о массовых программистах.
В конце, скорее. А то что было доступно ограниченному кругу лиц, а не было внутренней разработкой, вообще в начале 80-ых.
Лично я смог увидеть Смолток только в 90-ых.
BZ> для них первой ide был наверно turbo-pascal. и это кстати одна из причин его бешеной поппулярности — цпрщение цикла edit-compile-lonk до "нажал кнопку и тебе показали место ошибки"
Так и есть. К тому же Смолток не обладал IDE. Там была другая идеология — идеология имиджа. Свойства конечно схожи, но далеко не идентичны. IDE же имеет смысл только когда мы говорим о языках с традиционной файловой организацией.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, BulatZiganshin, Вы писали:
BZ>>smalltalk появился в начале 70-х, только речь наверно шла о массовых программистах.
VD>В конце, скорее.
насколько я помню, был смоллтолк-70, так что начало ращзарьотки — это конец 60-х. не знаю, была ли там среда с самого начала
BZ>> для них первой ide был наверно turbo-pascal. и это кстати одна из причин его бешеной поппулярности — цпрщение цикла edit-compile-lonk до "нажал кнопку и тебе показали место ошибки"
VD>Так и есть. К тому же Смолток не обладал IDE. Там была другая идеология — идеология имиджа. Свойства конечно схожи, но далеко не идентичны. IDE же имеет смысл только когда мы говорим о языках с традиционной файловой организацией.
ну зачем искуственно разграничивать. главное чтобы было удобно
Здравствуйте, BulatZiganshin, Вы писали:
BZ>я так не думаю. во-первых, у большинства программистов стояли машины слабее.
Дык, темболее!
BZ> во-вторых, что по твоему — пни на 100% этим анализом загружались?
Первый интеллисенс был очень ограниченным и был реализован для языков которые очень легко парсить и типизировать.
Самый первый случай интеллисенса который я мог наблюдать — это была Gupta SQLWindows (ныне Team Developer). Она была доступна (если не ошибаюсь) где-то в середине. Но там не было контекстного интеллисенса. SQLWindows был полупроцедурным языком у которого по началу не было текстового представления. Код переставлялся неким деревом. Так вот у него был боковой рулбар в котором был список имеющихся функций, которые, к слову, имели удобную структурированную систему префиксов. Но даже это здорово ускоряло разработку, особенно для новичка не знавшего местный АПИ. Потом был VB 4 (опять же если не ошибаюсь). Как известно Васик очень легко парсится и типизируется. В нем ведь даже не было наследования. Классы были очень примитивными. А вот первый интеллисенс для С++ был просто чудовшино медленным и много врал. В прочем, он и сейчас не сильно лучше. Хотя и техника другая, и времени на разработку было предостаточно. Но главное, что на технике вроде той что была в моем распоряжении в 1993-ем создать идее с интеллисенсом было практически невозможно. Даже список функцй не поместился бы в память (640 К весьма не много).
BZ>просто идёт постепенное развитие.
Несомненно. Но развиваться на машинах с 2 гигами памяти как-то значительно проще чем на машине с 2 килами :).
BZ>ты предыдущую эпоху не застал, и тебе кажется, что is — это нечто принципиально новое и крутое. а в моей жизни это например была встроенная отладка
Я ее застал. Конец скорее, но застал. И мне не кажется, я точно понимаю, что скажем стложность тогдашней IDE и современной не может идти ни в какое сравнение. То же самое можно сказать и любых других областях. И все это, как ты точно заметил, в следствии того, что идет постепенное развитие. Развитие оно идет везеде. Даже те же Лиспы развиваются. Например, по прошестрвии 50 лет возможно скоро появится первый не глючный компилятор лиспа для виндовс. :)) (злорадствую, не обращайте внимания)
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>>В конце, скорее.
BZ>насколько я помню, был смоллтолк-70, так что начало ращзарьотки — это конец 60-х. не знаю, была ли там среда с самого начала
Самый первый был 72, но его мало кто видел.
VD>>Так и есть. К тому же Смолток не обладал IDE. Там была другая идеология — идеология имиджа. Свойства конечно схожи, но далеко не идентичны. IDE же имеет смысл только когда мы говорим о языках с традиционной файловой организацией.
BZ>ну зачем искуственно разграничивать. главное чтобы было удобно
Затем, что другая идеология, другие средства. Вы же не называете REPL словом IDE?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>Так что тот же REPL может быть и не плох, особенно для чистого ФЯ (коим ОКамл не является), но опять же ему не плохо было бы быть встроеным в IDE.
Так встрой — хотя бы Nemerle Console
После F# без интерпретатора ломка начинается.
Как минимум нужны команды "загрузить файл" и "приликовать сборку".
Cкрипты для интерпретатора типа .fsi тоже хотелось бы.
Здравствуйте, kitsunekko, Вы писали:
VD>>Так что тот же REPL может быть и не плох, особенно для чистого ФЯ (коим ОКамл не является), но опять же ему не плохо было бы быть встроеным в IDE. K>Так встрой — хотя бы Nemerle Console
Кто-то уже это делал. Где-то был плагин.
K>После F# без интерпретатора ломка начинается.
Это пока что первый случай.
K>Как минимум нужны команды "загрузить файл" и "приликовать сборку". K>Cкрипты для интерпретатора типа .fsi тоже хотелось бы.
Откровенно говоря я считаю, что реализация вещей которые тебе не нужны и мало интересны не приведут к хорошему результату. Тут хорошо бы найти человека которому этот РЕПЛ был бы нужен самому.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>изюм тут вот в чём — интересная работа — это когда ты описываешь сложные алгоритмы. и хаскель позволяет писать их почти на естсевенном языке.
Вот это сказка. К сожалению, хаскель такой же тупой примитивный язык для тупых примитивных машин, как и все остальные языки программирования. Ну ладно, не такой же, пусть он лучше в этом плане большинства из них, но до естественного языка ему как пешком до ашхабада.
Языки с унификацией (пролог-семейство) делают маленький шаг по направлению к естественным языкам. И именно в силу этого свойства неприменимы на практике.
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, LaPerouse, Вы писали:
LP>Вот это сказка. К сожалению, хаскель такой же тупой примитивный язык для тупых примитивных машин, как и все остальные языки программирования. Ну ладно, не такой же, пусть он лучше в этом плане большинства из них, но до естественного языка ему как пешком до ашхабада.
Естественный язык хорош для девушек, а для машин лучше и выразительней типизированной лямбды пока не придумали
LP>Языки с унификацией (пролог-семейство) делают маленький шаг по направлению к естественным языкам. И именно в силу этого свойства неприменимы на практике.
Пх, прологовская унификация с бэктрэкингом — всего лишь один из великого множества алгоритмов. Чем он так важен, никто пока не объяснил.
.
и медведи заглядывали в окна, как же без этого 
