|
2.8, тоже Аноним (ok), 14:26, 29/09/2010 [^] [^^] [^^^] [ответить] [п©б╘п▒Б┬≥Б∙≈ п©б╘п▒Б┬≥Б∙≥п©б╘п▒Б┬≥Б∙⌡п©б╘п▒Б┬≥Б∙▓п©б╘п▒Б┬≥я▒я▐Б√░п▒Б√═Б■─п©б╘п▒Б┬≥ц╥я▐Б√░п▒Б√═Б√└п©б╘п▒Б┬≥Б∙⌡я▐Б√░п▒Б√═Б■─я▐Б√░п▒Б√═Б√▒]
| +2 +/– |
1. Делаем свой фреймворк на нормальном языке.
2. Заворачиваем его в компилятор нового языка. Тем самым:
2.1. теряем совместимость с кем бы то ни было;
2.2. но избавляемся от недостатков "веревки достаточной длины...";
2.3. снижаем порог вхождения;
2.4. имеем возможность портирования кода на новые платформы посредством портирования компилятора.
3. Рекламируем новый язык, надеясь, что повторится история с РНР.
4. Если повезет - имеем армию крепостных разработчиков, которым без открытого компилятора деваться некуда.
Примерно так, полагаю. Разве что не хватает пункта 0: "Становимся компанией №1 в Интернете" ;)
| |
|
|
|
3.21, Толстый (ok), 19:20, 29/09/2010 [^] [^^] [^^^] [ответить] [п©б╘п▒Б┬≥Б∙≈ п©б╘п▒Б┬≥Б∙≥п©б╘п▒Б┬≥Б∙⌡п©б╘п▒Б┬≥Б∙▓п©б╘п▒Б┬≥я▒я▐Б√░п▒Б√═Б■─п©б╘п▒Б┬≥ц╥я▐Б√░п▒Б√═Б√└п©б╘п▒Б┬≥Б∙⌡я▐Б√░п▒Б√═Б■─я▐Б√░п▒Б√═Б√▒]
| +2 +/– |
>> Качественное ПО, которое необходимо народу/на_рынке, будет иметь успех независимо от языка,
>> на котором оно написано.
> Только язык может внести свои коррективы. Скажем если мне для запуска байды
> на яве надо 100 мегов явы скачать, а потом оно будет
> полминуты стартовать каждый раз натужно хрустя диском - спасибо, но я
> другую программу поищу. Без такого безобразия. И крайне маловероятно что ваша
> программа уникальна и незаменима. Туда же идут и дотнеты с их
> 200 меговыми сетапами и установкой по часу.
Время запуска - это статический оверхед. Загружеатся в память виртуальная машина только один раз. Отчего долго - от того что там много разной функциональности. KDE приложения тоже с задержкой стартуют первый раз, по той же самой причине.
| |
|
|
5.40, User294 (ok), 01:07, 30/09/2010 [^] [^^] [^^^] [ответить] [↓] [п©б╘п▒Б┬≥Б∙≈ п©б╘п▒Б┬≥Б∙≥п©б╘п▒Б┬≥Б∙⌡п©б╘п▒Б┬≥Б∙▓п©б╘п▒Б┬≥я▒я▐Б√░п▒Б√═Б■─п©б╘п▒Б┬≥ц╥я▐Б√░п▒Б√═Б√└п©б╘п▒Б┬≥Б∙⌡я▐Б√░п▒Б√═Б■─я▐Б√░п▒Б√═Б√▒]
| –1 +/– |
Более того - в случае манагед кода очень трудно сразу быстро и на глаз засечь утечки памяти, даже весьма большие. Которые как ни странно там не только бывают но и вполне штатное явление природы. В случае прог выделяющих память обычными методами - видно все и сразу, так что если жрач памяти линейно растет в течение долгого времени и не стабилизируется - значит оно скорее всего течет и надо чинить, при том кто и сколько жрет видно более-менее в реальном времени. А в случае манагед - там вообще на глаз такое не поймаешь. Кто там его этот GC знает когда он там мусор собрать изволит. И вот прога жрала 100 мегов а стала через полдня жрать 200. И вот думай - толи это так и задумано, толи GC не отдуплился еще, толи просто течет что-то внаглую. В результате - я видел случаи когда большие утечки памяти оставались не пойманы годами т.к. все думали что это оно просто так работает.
| |
|
6.54, User294 (ok), 22:00, 30/09/2010 [^] [^^] [^^^] [ответить] [п©б╘п▒Б┬≥Б∙≈ п©б╘п▒Б┬≥Б∙≥п©б╘п▒Б┬≥Б∙⌡п©б╘п▒Б┬≥Б∙▓п©б╘п▒Б┬≥я▒я▐Б√░п▒Б√═Б■─п©б╘п▒Б┬≥ц╥я▐Б√░п▒Б√═Б√└п©б╘п▒Б┬≥Б∙⌡я▐Б√░п▒Б√═Б■─я▐Б√░п▒Б√═Б√▒]
| +/– |
>Сборщик мусора при правильном использовании позволит достичь большей производительности.
В основном он позволяет просрать предсказуемость этой самой производительности (потому что живет своей жизнью малоподконтрольной програмеру) и наделать трудноуловимых багов. По опыту тестирования барахла на манагед языках, если что.
А еще - ну допустим захочется вот написать *надежную* программу. Которая не загнется при нехватке памяти в системе и прочая. Мало ли, демон там, который полгода в батч-режиме будет фигарить (в зависимости от того что это - это может считаться и как прикладная программа и как системная). На unmanaged это даже можно - заранее при старте выделяем себе кус памяти, юзаем его. И готово. У нас уже никто его не отхапает, он наш. Поэтому мы будем спокойно работать не боясь навернуться от того что не удалось что-то выделить через 2 дня с момента старта. А вот в случае с принудительным автоматическим управлением памятью в этом плане наступает полная ж. Грубо говоря - сколь-нибудь надежную программу написать нереально вообще. Наступил oom - попробовали выделить памяти - померли/заглючили/сломались. А какие еше варианты, если нужного куска памяти чисто физически уже неоткуда взять в системе? Типичная картина.
| |
|
|
4.33, User294 (ok), 00:24, 30/09/2010 [^] [^^] [^^^] [ответить] [↑] [п©б╘п▒Б┬≥Б∙≈ п©б╘п▒Б┬≥Б∙≥п©б╘п▒Б┬≥Б∙⌡п©б╘п▒Б┬≥Б∙▓п©б╘п▒Б┬≥я▒я▐Б√░п▒Б√═Б■─п©б╘п▒Б┬≥ц╥я▐Б√░п▒Б√═Б√└п©б╘п▒Б┬≥Б∙⌡я▐Б√░п▒Б√═Б■─я▐Б√░п▒Б√═Б√▒]
| –2 +/– |
> Время запуска - это статический оверхед. Загружеатся в память виртуальная машина только
> один раз.
Ага, только как-то так получается что у меня нет ява-приложений и поэтому каждый раз надо втыкать на то как оно там 30 секунд винчом хрустит. Спасибо, сами этим и пользуйтесь. А мне это не надо. Видимо остальным тоже. Так, глядя на популярность программ на этом при наличии возможности добровольного выбора.
> Отчего долго - от того что там много разной функциональности.
Да, поэтому особенно прикольно ради хелловорлда в 10 кило качать еще 100 с хреном мегов рантайма. Очень напоминает ералаш про наручные часы с телевизором. И 2 огромных чемодана батареек к ним. Поэтому чувак охотно их обменял при первом удобном случае, помнится :)
> KDE приложения тоже с задержкой стартуют первый раз, по той же самой причине.
KDE у меня стартует вместе с системой. Секунд за 10-20 взлетает вся система вообще. И софта юзающего кути у меня более 1 программы, так что вот уж что-что а кутево-кдешные программы не тормозят при старте т.к. почти все либы которые им нужны и так сразу в памяти сидят. Это и gtk касается в общем то. Алсо, никто не предлагает качать на систему без кутей и кед Qt и kdelibs как один монолитный кус на сто мегов. В конце концов, оно на подкомпоненты порезано и кроме дефолтного тулкита системы - качаются только реально нужные довески. Поэтому если ни одной программе в системе не нужен какой-нить там модуль вебкита, мегов так на эн - он и качаться не будет. Ну а всяким микрософтам и санко-ораклам такой подход ессно незнаком, они в своих девяностых намертво застряли и/или погрязли в изобретении кривых велосипедов с квадратными колесами. Поэтому их велосипеды ездят только по специальным дорогам.
| |
|
|
6.39, User294 (ok), 00:56, 30/09/2010 [^] [^^] [^^^] [ответить] [п©б╘п▒Б┬≥Б∙≈ п©б╘п▒Б┬≥Б∙≥п©б╘п▒Б┬≥Б∙⌡п©б╘п▒Б┬≥Б∙▓п©б╘п▒Б┬≥я▒я▐Б√░п▒Б√═Б■─п©б╘п▒Б┬≥ц╥я▐Б√░п▒Б√═Б√└п©б╘п▒Б┬≥Б∙⌡я▐Б√░п▒Б√═Б■─я▐Б√░п▒Б√═Б√▒]
| +/– |
> А у меня Okular в GNOME запускался быстрее, чем в KDE4 (разв 10, ололо).
Ткнул на окуляр. Он появился через примерно ~секунду (за это время появилось полностью инициализированное окно в котором можно жать контролы и открывать документ). Я даже точно время померять не смог. Ну, даже если он появится за 0.1 секунды - врядли я увижу при этом большую разницу :).Хоть я и сомневаюсь что вы 0.1 секунды от старта до появления окна можете точно померять (интересно, какой тулзой?).
> После чего весь этот сраный KDE отправился в помойку. В который раз.
Гном имхо не сильно лучше. Вон его оконный манагер например - туп как пробка и вообще ничего не умеет. И некрасивый до кучи. Из GTK-based окружений понравился XFCE. Конечно попроще кед раз так в эн, зато все относительно компактно и аккуратненько. А в какойнить хубунте и вовсе epic win: приятная тема сразу по дефолту, набор софта куда лучше чем в гноме бубунты, etc :). Сразу остается очень приятное впечатление от среды. Задолбают монструозностью кеды? Уйду на XFCE тогда, если всякие непоймуки и аконади станут насильно впариваемой неотключаемой и невыпиливаемой фичой (да, я тоже не люблю bloat от ненужного мне функционала высосанного из пальца).
| |
|
7.48, Knuckles (ok), 12:36, 30/09/2010 [^] [^^] [^^^] [ответить] [п©б╘п▒Б┬≥Б∙≈ п©б╘п▒Б┬≥Б∙≥п©б╘п▒Б┬≥Б∙⌡п©б╘п▒Б┬≥Б∙▓п©б╘п▒Б┬≥я▒я▐Б√░п▒Б√═Б■─п©б╘п▒Б┬≥ц╥я▐Б√░п▒Б√═Б√└п©б╘п▒Б┬≥Б∙⌡я▐Б√░п▒Б√═Б■─я▐Б√░п▒Б√═Б√▒]
| +/– |
> Ткнул на окуляр. Он появился через примерно ~секунду (за это время появилось
> полностью инициализированное окно в котором можно жать контролы и открывать документ).
> Я даже точно время померять не смог. Ну, даже если он
> появится за 0.1 секунды - врядли я увижу при этом большую
> разницу :)
Ага. А если комп не топовой конфигурации, а, скажем, 3-4 летней давности, то разница уже будет 5-7 секунд против 1-2. Уже более ощутимо, да?
> Гном имхо не сильно лучше.
По крайней мере он не тормозит и глюков в поставляемых приложениях поменьше.
>Вон его оконный манагер например - туп
> как пробка и вообще ничего не умеет. И некрасивый до кучи.
Зато с гномом компиз прекрасно дружит. И работает лучше, чем KWin.
> Из GTK-based окружений понравился XFCE.
У него одна проблема (или достоинство, кому как) - он может называться DE только с большой натяжкой.
| |
|
|
|
|
|
|
|
2.32, Crazy Alex (??), 23:28, 29/09/2010 [^] [^^] [^^^] [ответить] [↓] [п©б╘п▒Б┬≥Б∙≈ п©б╘п▒Б┬≥Б∙≥п©б╘п▒Б┬≥Б∙⌡п©б╘п▒Б┬≥Б∙▓п©б╘п▒Б┬≥я▒я▐Б√░п▒Б√═Б■─п©б╘п▒Б┬≥ц╥я▐Б√░п▒Б√═Б√└п©б╘п▒Б┬≥Б∙⌡я▐Б√░п▒Б√═Б■─я▐Б√░п▒Б√═Б√▒]
| +/– |
Угу, чтобы еще это чудо на полностью управляемо коде жило и тормозило? Нет уж, нехай эти архитекторы тратят свои силы на загубленные десяток подобных проектов - а то, не дай бог, сконцентрируются на одном и таки пропихнут.
А как надо языки писать - сомтрите на D2. Вот та сделано УДОБНО для программиста, и при этом при надобности есть все возможности - от прямого вызова c-функций (и создания .so, используемый из C) и отказа от GC до функциональщины, от метапрограммирования, проектированного Александреску и генерации кода при компиляции до создания в рантайме экземпляра класса по имени как штатной возможности языка. О куче удобного syntax sugar вроде
foreach(i, item; array) writefln("index %s - value %s\n", i, item) еще надо упомянуть. При этом компилируется быстрее, чем Go.
| |
|
3.42, pavlinux (ok), 01:38, 30/09/2010 [^] [^^] [^^^] [ответить] [п©б╘п▒Б┬≥Б∙≈ п©б╘п▒Б┬≥Б∙≥п©б╘п▒Б┬≥Б∙⌡п©б╘п▒Б┬≥Б∙▓п©б╘п▒Б┬≥я▒я▐Б√░п▒Б√═Б■─п©б╘п▒Б┬≥ц╥я▐Б√░п▒Б√═Б√└п©б╘п▒Б┬≥Б∙⌡я▐Б√░п▒Б√═Б■─я▐Б√░п▒Б√═Б√▒]
| +/– |
> О куче удобного syntax sugar вроде
> foreach(i, item; array) writefln("index %s - value %s\n", i, item)
> writefln("index %s - value %s\n", i, item)
#define foreach(i, item, array) for (i = 0; i < sizeof(array)/sizeof(array[0]); i++, item = array[i] )
Где сахер-то?
> еще надо упомянуть. При этом компилируется быстрее, чем Go. | |
|
|
|