Дебианизм оперденей головного мозга

[metaclass]

Как известно, ребе theiced постоянно критикует меня за использование разнообразного софта, который по его мнению, написан криворукими уродами, как то - дебиан, дельфи, винда xp, firefox итд итп. Ну, он всегда критикует, это привычно.

Но после того, как я осилил рисование плат в Eagle, который по юзабилити упорот где-то на уровне среднем между "опердень на кларионе под windows95 написанная руССкими программистами методом портирования опердени под DOS" и "клиент-банк, который писали программисты налоговой инспекции, после того как их уволили из НИИГиТ", я начинаю сомневаться в собственной адекватности, может я действительно от 15 летней работы с чужими и своими оперденями сошел с ума и теперь могу пользоваться только софтом, который пишут невменяемые люди и который требует для работы стояния на ушах.

Comments

[theiced.livejournal.com]

>А до этого - да, игрушка.

а память в рандомные моменты времени всё равно начинает жрать не в себя.

>У кого лучше динамика за последние лет пять (не из тройки лидеров Java/C#/C++)?

у руби например :)

>Сразу видно, theiced не одну программу написал на Хаскеле. Наверняка же спрашивал у умных людей, это они ему и посоветовали свё в IO запихивать, ага.

theiced никогда не утверждал что он мегаспец по хаскелю (тут скорее ближе к "знаю название" чем к "спец"). говорю что видел.

[theiced.livejournal.com]

мне на каждый пункт писать строгий анализ? не вопрос. только это... оно времени сожрёт неплохо. давайте вы его оплатите?

[theiced.livejournal.com]

>руби это разве не тот язык, на который переползают оперившиеся 20-летние php-программисты? :) причем, php умудряется и работать быстрее и иметь синтаксис/объектную модель максимально приближенную к привычным плюсам и жаве.

не то.

>я тут могу чушь сказать, так как на руби пишет уж очень много молодежи на работе (а я смотрю с удивлением как у них по два часа генерится простейший xml или демоны, что на рубях написаны, сами по себе отгнивают), но очень похоже на "next big thing" в области клепания сайтиков

xml не нужен. твиттер вон на руби стартанули, теперь в свете неебических нагрузок переписывают некоторые части на жабе.

<поскипан бред>

>тут еще ребе Метакласс жалуется на firefox, я лично не вижу ему альтернативы для того же вебдевелопмента (уж очень firebug и firelogger удобны), хотя и пользуюсь "для себя" маргинальной оперой

ctrl-shift-i в хромиуме жать пробовали?

[craneop.livejournal.com]

Ребе, не надо глубокого анализа. Просто вы привели аргументы, которые по идее должны быть самыми сильными, а по факту они слабые. Я в частности, про жабу.

[theiced.livejournal.com]

>все претензии к Торвальдсу :)

угу, именно к нему.

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

а я про что сказал. приходится пользоваться ;)

>да и удобнее он в некоторых аспектах

в каких?

[permea-kra.livejournal.com]

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

*trolle mode on* Единственный мейнстримный язык с правильной объектной моделью - эрланг.

[vaddimka.livejournal.com]

удобное бренчевание (можно работать над несколькими бренчами не создавая две копии файлов проекта)

локальные коммиты, локальная история изменений

status показывает все в более человеческом (чем svn) виде

передача по сети в сжатом виде, можно работать хоть через gprs при желании (в том же svn получение каждого файла - отдельный запрос к серверу)

ну и плюс удобная обвязка, гиториусы всякие

хотя что в svn, что в гите, мне не хватает того что в ClearCase называют композитными бейзлайнами

[thesz.livejournal.com]

>а память в рандомные моменты времени всё равно начинает жрать не в себя.

Представляете, у других ЯП то же самое. У C++, Java, C#, Tcl... У Ассемблера, ядрёна-матрёна!

Что делать?

>у руби например :)

Год назад: 501 users have uploaded 7202 versions of 1870 packages.

Сейчас: 708 users have uploaded 13254 versions of 2904 packages.

Есть ли такая статистика для Ruby?

>theiced никогда не утверждал что он мегаспец по хаскелю (тут скорее ближе к "знаю название" чем к "спец"). говорю что видел.

Хорошо. Говорю, что видел.

Я смело уподоблю theiced lovesan по глубине вникания в проблему.

[vaddimka.livejournal.com]

ммм
works for me :)
модель простовата, но эффективна

возможно эрланг очень правильный язык с большим будущим, но тот же rabbitmq сервер в одной конторе с завидным постоянством умудряется ложиться на бок, жрать память хуже явы и не работать (при этом никто не может толком отладить это чудо)

не понял претензии

[nealar.livejournal.com]

svn через жопорез работает отлично

[develop7]

не уметь им пользоваться стало нельзя

неа. есть же hg-git. Его даже на гитхабе рекламируют (и пишет его, кстати, schacon)

[theiced.livejournal.com]

все эти плюсы есть в меркуриале жеж. вы о чём?

[theiced.livejournal.com]

про жабу я вообще аргументов не приводил ;)

[vaddimka.livejournal.com]

а я его не юзал, не попадался мне он еще как-то
надо глянуть

Re: не понял претензии

[vaddimka.livejournal.com]

работать-то работает, но на каждый файл делается отдельный GET, что при тормозных пингах вызывает серьезные задежки

[theiced.livejournal.com]

так ёпрст. я ж гит не с цвсом, упаси ктулху, сравнивал.

[redplait.blogspot.com (from livejournal.com)]

не за год, но с июля 2010 - было Hosted Projects: 8,903
сейчас: Hosted Projects: 9,166
обе цыфры сняты отсюда: http://rubyforge.org/

[permea-kra.livejournal.com]

Все хорошо, только это не объектная модель, это, блять, сахар для таблицы указателей.

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

[develop7]

как следствие, не удаляемого без изменения истории

А зачем нужно удалять бранчи?
Кстати, аналогом бранчей в Git являются bookmarkи в Mercurial.

[vaddimka.livejournal.com]

по-моему вы забываете про темплейты, немаловажная часть (хотя многие их панически боятся)
+перегрузку по типу аргументов (хотя последнее и является "сахаром для таблицы указателей")
но то и другое вместе весьма удобно

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

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

по поводу бранчей

[x-den.livejournal.com]

за реализацию named branches в меркуриале отрубить бы пальцы.

первые версии не умели нормально закрывать бранчи - начали различать "активные" и "неактивные", у которых нету топологического хэда. хрен с ним, что когда из активного бранча add_perdelka делаешь add_svistelka, add_perdelka становится неактивным, хоть ты хотел только распараллелить разработку. чтобы он опять стал активным, нужно его найти среди 100500 закрытых ранее неактивных бранчей, апнуться в него, а потом сделать и закоммитить изменения.

решили поправить это дело: сделали commit --close-branch. но вот засада: бранч остается топологическим хэдом и старые версии меркуриала (привет, ubuntu 10.04) будут считать закрытый бранч активным, а hg view еще и будет показывать его хэд вверху, чтобы "удобнее было".

отдельным приветом разработчикам идут неудаляемые имена бранчей: меркуриал будет ругаться, если попытаешься реюзнуть имя бранча add_perdelka через 3 года активной разработки забыв, что уже был такой, меркуриал будет упираться. в принципе, можно это force-нуть, но тогда log -b add_perdelka стряхнет пыль старины и покажет заодно коммиты, до которых тебе нету дела.

ну и венец творения, имя бранча в метаданных коммита. то есть если, допустим, есть бранч васи пупкина fix_operden из ревизий r100:120, и ты хочешь взять из него r105:115, которые без конфликтов накладываются на r99, и сделать начиная с r99 свой бранч fix_operden_more, то мэйнтэйнер опердени пися камушкин, когда попытается смержить ваши фиксы, будет материть вас обоих почем свет, потому что коммиты r105:115 из fix_operden и r100:110 из fix_operden_more будут иметь разные хэши и меркуриал будет считать их совершенно несвязанными, порождая конфликт на ровном месте.

впрочем все вышесказанное не отменяет того, что я люблю меркуриал за его простоту, расширяемость и пистон.

[permea-kra.livejournal.com]

Я не забываю. Да, на темплейтах можно строить свою объектную модель. Но это хак, за которым ещё и руками следить надо.

Что-то более удобное придумали гораздо ранее плюсов. Только оно не совместимо с моделью испольнения плюсов, поскольку требует гуманного асинхронного обмена сообщениями либо TCO. Ни того, ни другого в плюсах нет, не было и не будет.

[x-den.livejournal.com]

например, чтобы без головной боли использовать подход branch-per-issue. сейчас нужно либо делать корявые имена, сравнимые иногда по длинне с самим диффом(содержание которых со временем все равно забудется), либо делать бранчи вида fix_operden1, fix_operden2, ... fix_operden100500.

ну и да, букмарки рулят.

[x-den.livejournal.com]

эм, bitbucket-ом вполне можно пользоваться для личных нужд. мертворожденный он вот почему:

1. корявые бранчи: vasia_pupkin и john_doe, имеющие свои "локальные" копии репозитория operden не могут без последующих плясок с бубном иметь бранчи с одинаковыми именами.
2. среди "мейнстримных" OSS-проектов большинство на git, т.е. по дефолту github имеет большую аудиторию и больше подходит для social coding.
3. меркуриал не умеет трекать множественные remote-repositories. т.е. в гит можно сделать remote update и потом в gui-морде поглядеть, что нового в vasia/master, john/master и что jim сделал новые бранчи jim/fix_a и jim/add_b

проблемы с именованными бранчами я описал тут (http://metaclass.livejournal.com/606819.html?thread=9107043#t9107043). букмарки, в принципе, решают их все.

а rebase меняет историю и там, и там. поэтому его и не рекомендуется делать в published репозиториях: удаленные ревизии кто-то может запушить обратно. только в меркуриале это сделать проще, т.к. hg push по умолчанию засылает все отсутствующие коммиты (включая таковые из удаленного бранча), а git - только из активного бранча.

про теги в репозитории: коротко, в разных бранчах один и тот же тег может ссылаться на разные ревизии. то есть возможна ситуация, когда 'hg update some_tag' из бранча A и из бранча Б апнет в разные ревизии. длинно - написано тут (http://mercurial.selenic.com/wiki/Tag#How_do_tags_work_with_multiple_heads.3F). этого можно избежать достаточно простыми гайдлайнами по расстановке тэгов, но возможность выстрелить в ногу останется.

[gds.livejournal.com]

про bitbucket:
2 -- github -- это всего лишь сайт. Я на него захожу раз в четыре недели. Social coding -- видимо не для меня, потому что не предлагают, ибо говно пишу. Но это не относится к hg/git.
3 -- у меня в $repo/.hg/hgrc часто (по надобности) описаны

[paths]
repo1 = ssh://gds@superserver.local/repo/superproject
repo2 = ssh://gds@very.super.server.global/repo/superproject
repo3 = https://hg@bitbucket.org/gds/projectname

про отсылку веток, "git - только из активного бранча" -- интересно, не знал. Ну и остальное прочитал. Полезно, благодарю.