Здравствуйте, Rtveliashvili Denys, Вы писали:

А>>а чем не устраивает Scala? все пункты жалобы там норм + богатые возможности, библиотеки, IDE..

RD>Последний раз на Scala смотрел года три назад. Она не хотела нормально общаться с Java кодом а IDE тормозило.

даже год назад еще тормозило. они придумали быструю фоновую компиляцию (fsc). проблема закрыта.
общение с Java вызывает проблемы при кривом Java коде. — ambigous reference имеет место. Scala смотрит глубже ессно. решается прямым указанием скопа.

А>даже год назад еще тормозило. они придумали быструю фоновую компиляцию (fsc). проблема закрыта.

Это хорошо.

А>общение с Java вызывает проблемы при кривом Java коде. — ambigous reference имеет место. Scala смотрит глубже ессно. решается прямым указанием скопа.

Не помню деталей, но у меня ни Scala не видела Java классы, ни Java не видела Scala код. Может уже исправили это, не знаю.

Здравствуйте, Rtveliashvili Denys, Вы писали:

А>>общение с Java вызывает проблемы при кривом Java коде. — ambigous reference имеет место. Scala смотрит глубже ессно. решается прямым указанием скопа.

RD>Не помню деталей, но у меня ни Scala не видела Java классы, ни Java не видела Scala код. Может уже исправили это, не знаю.

наверняка твой косяк. Java из Scala видится без проблем. обратно- с ограничениями. но для эффективного программинга последнее значение не имеет

А>наверняка твой косяк. Java из Scala видится без проблем. обратно- с ограничениями. но для эффективного программинга последнее значение не имеет

Не знаю чей был косяк. Но тогда на попытки заставить Scala работать я убил где-то около 4х часов и в результате бросил.

Сегодня снова попробовал поставить Scala и по крайней мере простые вещи работают. Но пришлось ставить не .deb пакет, а .tgz, править вручную конфиги и IDE завелось лишь на NetBeans. На eclipse не запустилось, их плагин ожидает старую версию одной из библиотек. Было бы здорово, если бы всё работало сходу. Но ничего, и так покатит.

RD>Сегодня снова попробовал поставить Scala и по крайней мере простые вещи работают. Но пришлось ставить не .deb пакет, а .tgz, править вручную конфиги и IDE завелось лишь на NetBeans. На eclipse не запустилось, их плагин ожидает старую версию одной из библиотек. Было бы здорово, если бы всё работало сходу. Но ничего, и так покатит.

лучшие собаководы и я рекомендуем Intellij. наиболее гуманная из психотропных scala ide

А>лучшие собаководы и я рекомендуем Intellij. наиболее гуманная из психотропных scala ide

Спасибо, попробую её. Про IntelliJ у меня остались весьма тёплые воспоминания.

Здравствуйте, korvin_, Вы писали:

_>Конечно, тип Some в моем примере.

А где он сохраняется то? Не помню, чтобы у Лиспов были метаданные где-то. Или это как в Яве, чисто на время компиляции — только для проверок?

_>Number здесь равносилен Number'у в джаве например, т.е. он является надтипом для все остальных числовых типов. В документации же все есть.

Дык в Яве как раз это основной источник тормозов. Нельзя для числе общий тип вводить. Они ведь разного размера. В Яве для обобщенного хранения и обработки числе их запихивают в объекты. А это по объекту на значение.

VD>>Так же не ясно что означает "generalized from ..."?

_>Вероятно это особенность работы интерпретатора, означает, что результат вызова get имеет тип "...", но для вывода значения на экран оно было приведено к более общему типу. В исходном коде все остается строго, например.

А компилятор то у этого Рокета есть?

Здравствуйте, Rtveliashvili Denys, Вы писали:

RD>Меня он заинтересовал вот чем:
RD>1. typed racket
RD>Но такое ощущение, что на этапе компиляции происходит type erasure. Не уверен, так ли это на самом деле.

Дык Лисп же. У него природа такая.

RD>2. якобы есть всякие хорошие штуки в стандартной библиотеке, такие как thread-local variables

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

RD>3. не поленились написать документацию

RD>4. и даже написали IDE

RD>Правда он не очень "способный", но всяко лучше просто текстового редактора.

Все что ты перечислил есть в Scala и Nemerle. Более того в них есть еще и макросы. В Скале они пока что в зачаточном сстоянии и не могут изменять синтаксиса. В Немерле же они в некоторых аспектах по круче лисповских (доступна информация о типах). Плюс это нормальные синтаксические языки, так что не придется ломать сознание программируя на них.

По сокрости они по любому лучше любых лиспов (за Немерл уж точно ручаюсь). Для них есть и полноценные IDE. В них доступны все библиотеки базовых фрэймворков, плюс куча опен-сорсных.


RD>Сделал буквально пару тестов и увидел, что:

RD>1. вызов ничего не делающей процедуры без аргументов, дёрнутой из shared object стоит 150 наносекунд (вместо 3 наносекунд, которые тратит аналогичный код на C).

RD>2. почему-то происходит inlining для рекурсивных вызовов.

О том и речь. И это при том, что на свете есть языки изначально разрабатывавшиеся как типизированные и не имеющие таких проблем. Хотя в Скале есть странности. Например, циклы разворачиваются в замыкания и подтормазивают. В немерел такого нет. Плюс макросы полноценные.

Здравствуйте, VladD2, Вы писали:

VD>А где он сохраняется то? Не помню, чтобы у Лиспов были метаданные где-то. Или это как в Яве, чисто на время компиляции — только для проверок?

Так в самом типе и храниться. В Лиспе МакКарти 58-го года? Наверное не было. Type erasure вроде нет:

> (ann (Some 1) Some)
. Type Checker: Polymorphic function make-Some could not be applied to arguments:
Argument 1:
  Expected: a
  Given:    One

Result type:     (Some a)
Expected result: Some
 in: (Some 1)

> (ann (Some 1) (Some One))
- : (Some One)
#<Some>
>

VD>Дык в Яве как раз это основной источник тормозов. Нельзя для числе общий тип вводить. Они ведь разного размера. В Яве для обобщенного хранения и обработки числе их запихивают в объекты. А это по объекту на значение.

Дык в яве поэтому и существуют примитивные типы (int, double, и т.д.), которые и используются, когда нужна математика. Number используется только там, где нужно обобщение.

VD>А компилятор то у этого Рокета есть?

На оффсайте все есть.

Здравствуйте, VladD2, Вы писали:

VD> Плюс это нормальные синтаксические языки, так что не придется ломать сознание программируя на них.

Да, видел

Автор: dimgel
Дата: 18.10.12

я эти "нормальные синтаксические" языки. Глаза сломать точно придется, за обилием закорючек не видно сути.

VD> По сокрости они по любому лучше любых лиспов (за Немерл уж точно ручаюсь). Для них есть и полноценные IDE. В них доступны все библиотеки базовых фрэймворков, плюс куча опен-сорсных.

Чем докажешь?

VD> О том и речь. И это при том, что на свете есть языки изначально разрабатывавшиеся как типизированные и не имеющие таких проблем.

Типизированность тут не особо при делах.

Здравствуйте, Rtveliashvili Denys, Вы писали:

RD>Есть ли у кого-нибудь практический опыт использования Racket для написания реального софта?

RD>С одной стороны я вижу что он в основном используется для обучения. И его IDE DrRacket мягко говоря не впечатлило (а есть ли другие?).

RD>А с другой стороны вроде бы далеко не примитивный язык с якобы неплохим Foreign Function Interface, многопоточностью, ленивостью (если надо) и т.д.


RD>Я пока что пользовался Haskell, но очень утомило следующее:

RD>1. Dependency Hell. Это просто убивает. Собрать мало-мальски сложный софт с множеством зависимостей почти невозможно, т.к. cabal в них путается. И если даже удалось проблему победить, то очередной "cabal update" ломает всё. Известные "решения" этой проблемы слишком похожи на костыли.

RD>2. Для почти любого кода со сложным состоянием (не факториалы же считаем) нужно дико извращаться с records (и захламлять этим local scope), писать свои монады по поводу и без и всё это быстро превращается в кромешный ад.

RD>3. Даже в коде средней сложности приходится либо писать массу невменяемых конструкций, либо городить башни из monad transformers. В любом случае код становится нечитаемым.

RD>2. Средства разработки, мягко говоря, удручают.


RD>Думал о переходе на Ocaml, но слышал что:

RD>1. Там свои проблемы со сборкой.

RD>2. FFI уродлив.

RD>3. Есть странные ограничения на длину массивов.

Я для своих задач слез с OCaml на Nemerle (Research в SEO). Пока — доволен. Хотя пришлось ломать всю имеющуюся инфраструктуру и пилить имеющиеся наработки.