Здравствуйте, Klapaucius, Вы писали:
Собственно, если подытожить, я вижу здесь достаточно простую ситуацию. В виде VisualF# я вижу некоторую базу, которая может стать хорошей IDE. Безусловно, работы еще много. Но фундамент есть. А вот в Лексахе я такой базы не вижу. Поэтому с точки зрения IDE именно — не с точки зрения РЕПЛа и его возможностей — ситуация у F# на мой взгляд гораздо лучше.
ВВ>>А можно пример ленивого кода на Хаскелле, который нельзя перевести на код с явными санками?
K>Речь не о том, что можно перевести в принципе, а о том, что можно использовать на практике, т.е. то, что удобно и работает с приличной скоростью. Lazy и прочее не обеспечивают ни первого ни второго, и, соотвественно, почти никогда не используются.
Неочевидно. Почему санки, неявно создаваемые компилятором, будет более эффективны, чем явные? Скорее, наоборот. Возможность, явного аннотирования как раз является некоторым средством оптимизации и позволяет использовать ленивость только там, где она действительно нужна.
Если все так хорошо с lazy by default, то откуда вообще берутся всяческие Eager Haskell, Concurrent Haskell?
Складывается впечатление, что ты имеешь в виду некий конкретный язык, где эти явные санки реализованы не лучшим образом. Я не знаю, как дела обстоят в Алисе, но неужели в Омеге или Pure все тоже настолько плохо?
K>IDE появились для языков и библиотек в которых на каждое 2+2 полагается три экрана бойлерплейтной обвязки, а сам + именуется как-нибудь вроде НоВГорлоЯУспелВоткнутьИТамДваРазаПовернутьМоеОружье (перегружено для 256 вариантов аргументов). Отсюда очевидны и виды проблем, которые ИДЕ решают, т.е. генерация бойлерплейта и, что более актуально, потому что никаким совершенствованием языка тут делу не поможешь — автоматизированное преобразование кода и навигация по коду. Функциональность репла — т.е. возможность быстро испробовать небольшой фрагмент кода в ИДЕ появится могла только в самой зачаточной форме — ведь в языках, для которых иде разрабатывались не бывает кусков кода одновременно работающих и небольших. Наоборот, репл характерен для языков в которых не нужно писать мегабайты бойлерплейта, а типичная программа вычисляет факториал — так что навигация по ней тривиальна, как, собственно, и ее ручное преобразование. Когда же эти языки внезапно стали применять на практике — проблема навигации по коду встала в полный рост.
Как-то ты сгущаешь краски. Современные IDE появились в общем не так давно — на то они и "современные". То, что там раньше так называлось, сейчас уже в общем и неважно. Я не уверен, что генерация бойлерплейта — основная задача ИДЕ. Основная задача ИДЕ, на мой взгляд, сократить кол-во ошибок компиляции. Ну т.е. пишу я блокноте, компилирую, у меня получается n>100 ошибок, я их начинаю исправлять. Задача ИДЕ сократить это n до минимально возможной цифры — т.е. ИДЕ должна уметь показывать мне ошибки по мере набора кода. Это ИМХО главная задача. Плюс рефакторинг. Но рефакторинг тоже не должен сводиться к генерации бойлерплейта. Я вообще ни разу не пользовался этими "генераторами бойлерплейта", но пользу от ИДЕ тем не менее вижу.
Да и языки современные не настолько плохие. Так или иначе присутствует все же некоторая "модульность" — пусть и не на уровне функции (хотя может и на уровне функции). Нет таких законов природы, по которым в том же C# "не бывает кусков кода одновременно работающих и небольших". Да, пусть там этот кусок будет классом, а не функцией — но какая разница? Идеологии РЕПЛа это никак не противоречит. Сильно связанный код, конечно, встречается, но по-моему это в рамках любой парадигмы плохо.
