MonoDevelop 2.0

А у меня наблюдалось. 20 минут назад, перед тем, как я тот пост накатал. 
Щас моно полностью похоронен с моей системы, так что проверять перманентность глюков уже не на чем, да и желания нету.
МОно стояло с офф. репов Суси. Может, глюки там и не перманентные - но тем хуже. Вот за что люблю C++ - так это за то, что если там глюк есть, то он есть стабильно, и выловить его очень легко. А вот во всяких делфях, монодотонетах и прочем - они вообще непонятно по какому принципу и из-за чего вылазят. ИНогда вылазят, иногда - нет, наверное расположению облаков на Юпитере подчиняются. Облачно - вызалят, ясно - не вылазят... Чёрт их разберёт, в общем.

UPD
А, ещё добило, что там проект обозвали "решение". Ну точно M$-Like. Хороните.

UPD2
Да и вообще, что за дебильно-маркетоидное словечко - "РЕШЕНИЕ"...

у Scala более чем приличная скорость, а Boo сам по себе тормоз, если что...

Да да. Хороший M$ - мертвый M$.

http://www.monodevelop.com/@api/deki/files/193/=NewProjectModel.png

"Solution Solution1", "Solution Solution2"

это не маркетоидное решение, а типа дзен такой - что у тебя будет не головняк и морока, а solution из каробки. Самовнушение :)

>> это не маркетоидное решение, а типа дзен такой - что у тебя будет не головняк и морока, а solution из каробки. Самовнушение :)


А-а-а гы-гы ))) 
Не знаю как там "искаропки", но среда разработки "искаропки" не завелась. Видимо, мне недоступен сей дзен. Или я не знаю в какой бубен ей врезать, шоб она заработала... 

> у Scala более чем приличная скорость

А как там с хвостовой рекурсией? Насколько я знаю, там есть проблемы по этой части.

> а Boo сам по себе тормоз, если что...

Может и такое. Но на некоторых задачах он обганял F#. Плюс смотря где ганять - на .Net скорость наблюдалась весьма приличная; Mono/Linux тормознее .Net в 2-3 раза, Mono/MustDie тормозней .Net раз в 5. Это то, что наблюдал сам. Очень много зависит от того, под чем пускать.

> Вот за что люблю C++ - так это за то, что если там глюк есть, то он есть стабильно, и выловить его очень легко. А вот во всяких делфях, монодотонетах и прочем - они вообще непонятно по какому принципу и из-за чего вылазят.

Ты на плюсах вообще пейсал? Делфи - кал, конечно, но говорить, что глюк выловить сложнее, чем в плюсах я бы не стал...

> Юзать "платформу", в которой безбожно глючит даже среда разработки - это, ИМХО, удел полных шизоидов...

4.2 На дебиане и убунте все нормально, на сусе и подавно. Не знаю, что там у тебя. Скорее всего что-то подростковое. ЧСВ так и прет.

Бгхм... Пейшу на плюсах большой проект (C++/Qt 4.5). Переполз из делфей, так что знаю, о чём говорю.

Core2Duo, 4 гига оперативы.
Open SuSE 11.1. Кеды четвертого размера. Монодевелоп искаропки (репозиторий http://download.opensuse.org/repositories/Mono/openSUSE_11.1/).
Установлен YaSTом. Последний mono-core из того же репозитория, куча прочего барахла оттуда же. 

ПОведение - вышеописанное. Может и подростковое, не знаю, голворю ж - не знаю, в какой бубен ему нужно врезать. Но искаропки не работает - это точно. По сравнению с QDevelop (версии 0.26, между прочим) или Qt Creator, с которыми не наблюдалось вообще ни единого бага.

В-общем, юзать данное поделие отпала всякая охота, посему и похоронил. А кому-то, может, и нравится...

> Или кросс-платформенность подразумевает только Linux и Windows?

Если хотите вендекапец, забудьте про слова "кросс-платформенность". Кросс-платформенность должна быть только между аппаратными платформами.

Да, и язык С# + биндинги GTK# - это удобно, хоть я и люблю Python и C больше. А .NET, WinForms и прочий хлам нас, как пользователей Linux, вообще не должен интересовать.

> Количество книг дарии донцовой в магазинах таки больше чем количество книг Тургенева.

> А количество дисков димоеблана больше чем количество дисков Битлов.

Вы должны понимать, что спрос рождает предложение.

>> Вы должны понимать, что спрос рождает предложение.

А агрессивный пеар рождает спрос.

"Пеар" я не наблюдаю - даже в этой новости больше комментариев вида "Qt рулит".

> Вы должны понимать, что спрос рождает предложение.

С одной стороны воодушевляет обращение "должны". С другой стороны - это пропаганда. Если бы действительно было "спрос рожадет предложение", то небыло бы сейчас кризиса.

Я бы с радостью переключился на обсуждение причин возникновения кризиса, но, боюсь, это будет немного offtopic. :)

>Scala, насколько я знаю, имеет проблемы с поддержкой хвостовой рекурсии, потому в ынтерпрайзе не участвует.

scala> def tailr(x:Long):Long = if (x == 0) x else tailr(x-1)
tailr: (Long)Long

scala> tailr(1000000000l)
res0: Long = 0

У скалы отсутсвие поддержки хвостовой рекурсии на уровне JVM, по такой мелкой причине как отсутствие в самой JVM поддержки оной.

Ее делает компилятор.

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

>Есть так же аннотация @tailrec которая указывает компилятору что функцию надо сделать хвосторекурсивной или выпасть с ошибкой компиляции, если он не может этого сделать.

странно, если ты заранее знаешь, что функцию можно написать без рекурсии, то зачем писать с рекурсией и потом заставлять компилятор разворачивать ее?

>странно, если ты заранее знаешь, что функцию можно написать без рекурсии, то зачем писать с рекурсией и потом заставлять компилятор разворачивать ее?

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

Например вот такой код развернуть нельзя:

def tailr(x:Long):Long = if (x == 0) x else x + tailr(x-1)

Компилятор производит оптимизации рекурсии,там где может - если не может не производит. Данна аннотация говорит что я предполагаю что функция будет развернута, а если компилятор не может - пусть скажет мне я поправлю так, чтобы смог.

Например перепишу вышеуказанный код вот так:
def tailr(x:Long):Long = {
def _tailr(acc:Long, x:Long):Long = if (x == 0) x else _tailr(acc + x, x-1);
_tailr(0,x)
}

и его уже компилятор сможет оптимизировать.

>странно, если ты заранее знаешь, что функцию можно написать без рекурсии, то зачем писать с рекурсией и потом заставлять компилятор разворачивать ее?

ааа:) Потому что компилятор должен работать, а человек - думать:)

> А кто такая Visual Studio и Visual Web Developer и зачем с ними нужна совместимость?

Это все лучшее от Майкрософт, которое нам любят навязывать в универе =) MonoDevelop все-таки Ъ

Кто знает где скачать 64х битные дебы?

>Кто знает где скачать 64х битные дебы?

Например, из репозитория Debian, когда они там появятся.

>>Кто знает где скачать 64х битные дебы?

>Например, из репозитория Debian, когда они там появятся.

Капитан Очевидность, перелогинтесь

> У скалы отсутсвие поддержки хвостовой рекурсии на уровне JVM, по такой мелкой причине как отсутствие в самой JVM поддержки оной.

> Ее делает компилятор.

Компилятор не всегда знает, будет ли рекурсивный вызов (особенно в динамических ЯП), потому нужна поддержка на уровне ВМ. А козлы из Сан никак не родят.

The use of tail recursion in Scala is fairly limited, because the JVM instruction set makes implementing more advanced forms of tail recursion very difficult. Scala only optimizes directly recursive calls back to the same function making the call.

и я о том.

>Компилятор не всегда знает, будет ли рекурсивный вызов (особенно в динамических ЯП), потому нужна поддержка на уровне ВМ.

Вообще-то именно компилятор генерирует хвосторекурсивный вызов. В CLRе генерируется инструкций .tail перед коллом.

Ну и как компилятор сгенерирует хвостовой вызов в таком случае (define (f g x) (g (something x))) ?

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

>Ну и как компилятор сгенерирует хвостовой вызов в таком случае (define (f g x) (g (something x))) ?

Более глубоким анализом в паре с местом применения? Конечно без инспекции стека тут никак.

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

это саботаж микромягких

> но среда разработки "искаропки" не завелась. Видимо, мне недоступен сей дзен. Или я не знаю в какой бубен ей врезать, шоб она заработала...

Нормально завелась среда (Monodeveloper). Как первый, так и второй.

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

А есть вообще приложения на Mono, заслуживающие внимания?

Насколько я понимаю тут есть два момента. Первое - решить можно ли соптимизировать и второе соптимизировать. Можно ли грохнуть стек компилятор решить может. А вот действительно его грохнуть может естественно только рантайм. В том же CLR префикс tail. обозначает лишь что хвостовой вызов из функции возможен, но есть туча условий когда рантайм откажется это делать.

Ну, например, MonoDevelop ;)

> Моно уже перестало требовать библиотеки гнома? 

Решай сам:

mono-2.0.1_6
    An open source implementation of .NET Development Framework
    Requires: bison-2.4.1,1, expat-2.0.1, gamin-0.1.10, gettext-0.17_1, gio-fam-backend-2.18.4, glib-2.18.4, gmake-3.81_3, libiconv-1.11_1, libtool-1.5.26, m4-1.4.12,1, p5-XML-Parser-2.36, pcre-7.8, perl-5.8.9_2, pkg-config-0.23_1, python25-2.5.4_1

> А вот во всяких делфях, монодотонетах и прочем - они вообще непонятно по какому принципу и из-за чего вылазят. ИНогда вылазят, иногда - нет, наверное расположению облаков на Юпитере подчиняются. Облачно - вызалят, ясно - не вылазят... Чёрт их разберёт, в общем.

Only Unchecked (=Runtime) Exceptions? :))