Аргумент в поддержку Mono

На Mono?

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

Моя фотоколлекция за последние 5-6 лет:

$ find /home/family/Our/Photos -iname '*.jpg'|wc -l
15093

$ du -hs /home/family/Our/Photos
60G /home/family/Our/Photos

F-Spot работает без нареканий. Digikam в коллекции использовать не могу, так как виснет при работе с БД, лежащей на NFS :) Но когда для тестов запускал - сильно тормозит на перелистывании больших альбомов. При чём что самосбор в Gentoo, что готовый бинарник в Ubuntu.

> Факты в студию. Мы посмеёмся.

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

> Примеры таких "внешних библиотек", пожалуйста.

Как только займетесь чем-нибудь кроме курсовых и дипломных - вопрос отпадет.

> Пример enterprise-приложения, которое не запускается на обновлённой в
> минорной версии jre?

Инсталлятор Oracle в 2000.

> ничего личного, но сомневаюсь, что учавствовали в жабских проектах

Сомнение в разуме - путь к знанию. Если разговор пришел к обсуждению меня, то можно его продолжить обсуждением вас и вашего опыта общения с mono/.net, а можно просто закончить.

> Я пишу на С++/C и не имею проблем с компиляцие под линух, винду и
> т.д.

Поздно начал. Плюс деньги не считаешь.

Java поддерживает то же самое, с помощью сторонних компиляторов, gjc и Новосибирского

> По факту моно и openjdk это единственные свободные воплощения безопасного байткода (typesafe) который исполняется не медленней чем "производительность С" * 0,5.

т.е. как минимум в два раза быстрее С? о_0

o_O ну и математика у вас :)

x * 0,5 -- половина, а не x/0,5 -- в два раза.

> o_O ну и математика у вас :)

А ты читать не умеешь.

перечитай еще раз его пост и нарису уравнение, которое он преждожил

J >= c*0.5

Таки в 2 раза быстрее.

>> o_O ну и математика у вас :)

> А ты читать не умеешь.

> перечитай еще раз его пост и нарису уравнение, которое он преждожил

> J >= c*0.5

> Таки в 2 раза быстрее.

Блин, вот что чёртовы экспериментаторы от АПН сделали со школьным образованием!!!... И это после программы Колмогорова в 1970-х годах, когда в школе с 6 класса изучалась теория можеств!!!

Математическое образование -- один из главных оборонных ресурсов страны. Без него ракеты не полетят, корабли не поплывут и пушки в цель не попадут. Я слышал, в конце хололдной войны был западный проект по развалу математического образования в СССР путём выделения грантов "учителям-новаторам", которые помогут развалить созданную Колмогоровым систему школьного математического образования. И развалили-таки!!!...

А кодер без знания элементов математики -- увы, сейчас явление обычное.

так кто же все-таки прав, а?

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

Кастую учителя математики 4 класса.

+1

RTFL!!! ЛОЛьно! На башорг, однозначно!

И чего серьезного enterpriZe написано на это моне??? :)) НИ-ЧЕ-ГО!

Потому как есть мегарулезные Spring и (для особо крипных энтерпрайZов) EJB.

Neil McAllister - это, видать, сетевой тролль. :)))

>Bioreactor

ну вы знаете да куда вам?

>> Пример enterprise-приложения, которое не запускается на обновлённой в
>> минорной версии jre?

> Инсталлятор Oracle в 2000.

Не знаю, не пользовался этой проприетарной хнёй.

Что, больше нет?

Да, Banshee - это вещЪ

Gnome вымирает, его во всю уже отделяют от gtk+ правильные дистрибутивы...

Инфа 100%? мне это важно. Пруфлинки, в общем.

> Как так? Там же 16 разрядная шина адреса. То есть по сути это аналог 8088, причём обратно совместимый с 8080.

У 8088, как и у 8086, шина адреса 20 разрядная.(Хотя на уровне физических выводов микросхемы возможно мультиплексируеццо на меньшее количество выводов, не помню точно).

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

Нет, адресная шина там честная 20-битная. Там шина данных, в отличии от 8086 не 16 бит, а 8. Чтобы была простая совместимость с массой 8-битных контроллеров и памяти.

Похвально. Развивается проект.

Основным языком mono является С#. Это довольно таки красивый язык. Что не удивительно, учитывая родство с Java. Пусть это покажется небольшим троллингом, но тот же C++ никак не назовешь красивым.

Для примера возьмем одну из основных библиотек - работу с коллекциями/контейнерами. Сравнение изящных дженериков из C# и тяжеловесных шаблонов из STL явно не в пользу последнего. Потому как в STL почти нет ООП. Неудобно создавать собственные контейнеры, а тем более наследовать их. Хотя, конечно, если стоит задача выжать из компьютера всю производительность, каковой он обладает, то C++ выигрывает. Но по красоте решения будет явным аутсайдером.

Еще тут один кадр что-то заявлял про GC... Вообще-то, введение GC - это не только автоматическая сборка мусора, это еще другой уровень мышления. А бывает и так, что GC оказывается производительнее ручного управления памятью. Не только проще, но и шустрее. Например, если много циклических связей, а некоторые большие куски данных изредка становятся ненужными. Тогда написание аналогичного управления памятью на C++ становится нетривиальной задачей... Да и вряд ли окажется красивым такое решение. То есть, в некоторых случаях средний по качеству mono код оказывается производительнее среднего по качеству C++ кода. И уж точно надежнее. А большинство кода - средние по качеству.

Если сравнивать mono с java, то как тут уже заметили, C# был создан на ошибках Java. Конечно, были внесены свои изъяны, но те же делегаты - чертовски удобная штука, особенно когда их много. А необходимость в делегатах возникает при следовании модели событийного (event-based) программирования. В той же Java замучаешься прописывать вручную обработку слушателей (event listeners). Хотя некоторые IDE предлагают автоматизацию, но генерируемый код не блещет эффективностью. А чтобы создать эффективную обработку слушателей, нужно писать вручную что-то по типу java.awt.AWTEventMulticaster. Замучаешься... Когда в C# это есть "из коробки".

Теперь ложка дегтя. На мой взгляд явовские библиотеки выше по качеству моновских. Дотнетовские тоже выше. Видимо, разные квалификации разработчиков. В общем, увесистая ложка дегтя. Был неприятный опыт. Исправятся ли когда-нибудь?..

Другой минус моно не связан с программированием. Писать на моно не кульхацкерно. Таким кодом не всегда похвалишься. И всегда найдется кучка альтернативно мыслящих, которым не понравится сам выбор технологии. Не задача, не то, как она решена, а средство решения. Начнут приставать с глупыми вопросами. Например, у писателей на С/питоне/перле таких проблем гораздо меньше.

>использовать mono для разработки игр для Windows и Macos без изменения кода, простой компиляцией на целевую платформу

что только не придумают чтоб не использовать QT (c)

> С#. Это довольно таки красивый язык. Что не удивительно, учитывая родство с Java.

Сестренки-красотки, ага. Ну и что с того, что умственно отсталые.

> Хотя, конечно, если стоит задача выжать из компьютера всю производительность, каковой он обладает, то C++ выигрывает.

1. Вы не компилировали OpenOffice из исходников?
2. Вы не компилировали Eclipse из исходников?
3. Вы не пользовались OOo и Eclipse?

Продукты одного масштаба сложности (я так думаю), а как соберёшь их и попользуешься... сразу почувствуешь разницу не в пользу C++.

>> С#. Это довольно таки красивый язык. Что не удивительно, учитывая родство с Java.

> Сестренки-красотки, ага. Ну и что с того, что умственно отсталые.

Неудивительно — ведь их исполняемые среды (VES и JVM, соответственно) написаны на C++. :))
Был бы использован типобезопасный язык Eiffel или Oberon там... Так ведь нет — на старом и дырявом "ведре" C++ всё (кроме библиотек API, слава богу, хоть это оставили в покое) реализовано...

> Конечно, были внесены свои изъяны, но те же делегаты - чертовски удобная штука, особенно когда их много. А необходимость в делегатах возникает при следовании модели событийного (event-based) программирования. В той же Java замучаешься прописывать вручную обработку слушателей (event listeners).

Сравнил один костыль с другим по удобству ходьбы. Делегаты растут от отсутствия удобных замыканий.

>Сравнил один костыль с другим по удобству ходьбы. Делегаты растут от отсутствия удобных замыканий.

Замыкание это функция + контекст ее исполнения, так? В терминологии не силен.

> Сравнил один костыль с другим по удобству ходьбы. Делегаты растут от отсутствия удобных замыканий.

Делегаты - это объектная обертка для function callback. Замыкания - это дальнейшее развитие идеи. И не факт, что замыкания так уж и нужны.

>> Хотя, конечно, если стоит задача выжать из компьютера всю производительность, каковой он обладает, то C++ выигрывает.

> 1. Вы не компилировали OpenOffice из исходников? > 2. Вы не компилировали Eclipse из исходников? > 3. Вы не пользовались OOo и Eclipse?

> Продукты одного масштаба сложности (я так думаю), а как соберёшь их и попользуешься... сразу почувствуешь разницу не в пользу C++.

Кстати о птичках. Еще во времена Eclipse v3 я пользовался этой IDE. И ставил ее исключительно из исходников. Качал пакет всего один раз, а устанавливал его сразу под Windows, Linux X11 и Linux GTK. Последний был тогда еще жутким тормозом и крайне падучим.

На С++ можно делать практически все. В том числе написать самую эффективную программу под конкретную задачу. Вопрос стоит в цене. Слишком дорого. И часто не нужно...

> Делегаты - это объектная обертка для function callback. Замыкания - это дальнейшее развитие идеи. И не факт, что замыкания так уж и нужны.

Значит тебе просто не попадались языки с вкусно оформленными замыканиями.

>> Делегаты растут от отсутствия удобных замыканий.
> Замыкание это функция + контекст ее исполнения, так? В терминологии не силен.

Типа того. Хочешь сказать, что делегат --- тоже замыкание? Возможно. Но дико неудачное в применении.

>> Замыкание это функция + контекст ее исполнения, так? В терминологии не силен.

>Хочешь сказать, что делегат --- тоже замыкание? Возможно. Но дико неудачное в применении.

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

>Делегаты растут от отсутствия удобных замыканий.
Серьёзно?
Чем же closures C# неудобны? Вы может путатете lambda expressions c closures?

Для Ъ, в C# 3, есть labmda expressions, как замена синтаксиса с анонимными функциями-делегатами в v2

>делегат --- тоже замыкание? Возможно.
??????????????????????????????????????
Советую почитать, что такое замыкания.
Хотя-бы в wikipedia

Вы просто имим не пользовались.
Пример
int SumOfArrayElements(int[] array)
{
    int sum = 0;
    Array.ForEach( array, x => sum += x );
    return sum;
}

> Серьёзно? Чем же closures C# неудобны?

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

> Для Ъ, в C# 3, есть labmda expressions, как замена синтаксиса с анонимными функциями-делегатами в v2

Да-да-да, а в C# 5.25 ими наконец-то можно будет нормально пользоваться.

> Советую почитать, что такое замыкания. Хотя-бы в wikipedia

Я почитал. Увидел упорядоченность по включению.

Аха, так вы всё-же closures с lamba путаете.
Прикольно.

> int SumOfArrayElements(int[] array)
> {
> int sum = 0;
> Array.ForEach( array, x => sum += x );
> return sum;
> }

Даааа, только дотнетчик может так испохабить (reduce arr + 0)

:)
И только самонадеянный дилетант может путать замыкания и анонимные функции, даже не подозревая насколько это смешно.

> И только самонадеянный дилетант может путать замыкания и анонимные функции, даже не подозревая насколько это смешно.

Обосновывать не забываем. А то лопнешь от смеха и унесёшь эту тайну великую с собой.

Что вам обосновать?
То что closures и lambda expressions смязаны как рот и звук - часто вместе, но это совершенно разные веши.

Ещё раз советую почитать чтонибудь с целью просвещения.

Узнаю любимый лор: назовут быдлом, потом уйдут от ответа.

Вам что непонятно?
Вам ссылки привести на описание лямбда выражений и замыканий?

> Вам что непонятно?

Мне непонятен вывод о дилетанстве. Вернее, понятно, что оно получено путём домысливаний и перетасовки, но меня не покидают сомнения в правомочности такого метода.

Ну, аргументация проста.
Если человек путает базовы понятия программирования, то он дилетант в программировании.

Или вы со мной несогласны?

>Вы просто имим не пользовались.
>Пример >int SumOfArrayElements(int[] array)
>{
> int sum = 0;
> Array.ForEach( array, x => sum += x );
> return sum;
>}

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

#include <iostream>
#include <vector>
#include <algorithm>

#include <boost/lambda/lambda.hpp>
 
using namespace boost::lambda;

int main() {
  int numbers[] = {1,2,3};
  int sum = 0;
  std::for_each(numbers, numbers + 3, std::cout<<_1<<'\n');
  std::for_each(numbers, numbers + 3, sum+=_1);
  std::cout<<"\nSum is:"<<sum<<'\n';
  return 0;
}

Признаком воинствущего дилетанта(бандерлога), так-же является фраза
>Мне как-то неинтересно постоянно заниматься изучением языка, завязанного на платформу, с которой я нигде не встречаюсь.
В ответ на просьбу рассказать, что-же вам не нравится.
Т.е. вы рассуждаете о том, чего не знаете, что и есть главный признак Бандерлога.

Хм.. разве sum+=_1 в вашем примере это функия? ( x => sum += x - функция )
Я, конечно-же отстал от развития С++, так как малова-то им пользуюсь последние лет 5, но, насколько я понимаю, это развернётся в inline код или вызов внешней функции.

идея closures примитивно проста: на момент инициализации переменной - функции, вы получаете доступ к переменны из блока кода, где эта функция "создаётся"

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

Насколько я помню, такое в С++ напрямую сделать невозможно, соответественно это трудно назвать closures. Всякаю эмуляция - чревата.
http://en.wikipedia.org/wiki/Closure_(computer_science)