http://habrahabr.ru/blogs/Dura_Lex/86026/
Для Ъ:
В Британии издают закон о ответственности овнеров вафли за то что делают их клиенты. Как минимум, за нарушение копирайтов.
Законопроект оценивается в один миллиард долларов, но по заверениям медиа-индустрии он привлечёт более 2.72 миллиарда долларов прибыли.

Круто, да?
С одной стороны мб и правильно, но между строк видно что денег с злых хитителей фильмов через торренты особо не взять, будут идти обратно по инстанциям.
Интересно на что они хотят потратить один миллиард долларов. Может кто знает на что можно потратить такую сумму в рамках такого законопроекта?
Забавно то что они гарантируют такую прибыль.

Условия:
1) Не требует Gnome || KDE (не критично).
2) Стандартный режим просмотра предусматривает обзор списка альбомов(хотя альбомы не важны, но если есть, то должен быть список) + обзор изображений в виде тамбнейлов(как в пикаса).
3) Поддержка тегов и удобной работы с ними(поиск, автокомплит при задании).
4) Своё хранилище изображений. Не важно какое. Хоть какой-нить MongoDB, хоть файлы. Главное чтобы при импорте файлов он перемещал всё в одну красивую директорию(возможно, с суб-директориями по тегам/альбомам/как угодно).
5) При добавлении мог и умел удалять дубликаты по размеру изображения, имени и самому изображению(пикаса только по имени умеет).

Вот и всё. Мне даже не важна интеграция с веб-сервисами. Мне важно всё упорядочить по тегам и без дубликатов.

В 2006 году Facebook отправили заявку на получения патента на данную технологию и вот свершилось чудо — в минувшую пятницу патент был опубликован. Теперь появление записи вида «Белка добавил N фотографий в фотоальбом «Как я грызу мозги лоровцев»» попадает под этот патент.

Кстати, данный патент кстати прямо распространяется на open-source технологию Activity Streams.

Остаётся ждать пока Facebook запатентуют само слово «социальная сеть» и как таковой вид сервиса.

Покачать головой

Перемещено boombick из Internet

... заменить HTML на XML, а визуализацию на qt-виджеты?
Грубо говоря, написать браузер, но такой, который вместо html-быдлокода требовал ты валидный xml от qt-дизайнера?
По функционалу QtGUI позволяет сделать все фичи что делают через JS и HTML, но через qt оно проще, легче и быстрее.
По сложности написания - фигня. Накидать GUI на Qt проще чем на html. Другая проблема что нужно будет сделать специальный qt-дизайнер(или допилить этот, или добавить виджетов) для некоторых задач, что в вебе есть а в кути обычными виджетами сделать не очень просто.
Фактически, получится что можно использовать любой веб-фреймворк и движок темплейтов для написания кода для браузера. Т.е. на стороне сервера изменений нет, а вот клиент - да, очень преобразится.
К чему это я. Да к тому что надоели все эти войны о WPF, Сильверлайт/Мунлайт, Моно, HTML5, JS, Java.
Ведь фактически Сильвер/Мунлайт является реализацией такой мысли, только реализацией людей, которые узко мыслят.
Что думаете?

Уже месяца 3 как влюбился в данный стиль, однако слушаю не так много групп. Всего 3 пока есть в плейлисте: 65 days of static, Mono, Explosions in the sky.
Есть у нас любители? Посоветуйте что ещё послушать.
Очень хочется что-то больше в стиле Mono.

Вот изучаю grails и groovy. Конечно, появляются вопросы, что легче и удобнее задать живому человеку, а не выискивать выдержки из тысяч текстов.
В общем, есть ли у нас русское коммьюнити? Конференция в jabber, например, или irc?

Специально(или нет?) сделал малоинформативный тайтл. Просто не пришло в голову что написать.
А тема нашего разговора сегодня - веб-фреймворки, а точнее что мы сейчас имеем и что мы можем сделать, изменить. Начнём из далека.
Сейчас у нас есть огромное количество различных веб-фреймворках на разных, но, в основном, популярных языках:

• Python
• Ruby
• PHP
• Lisp
• Java

etc Что мы имеем?

• На пайтоне всё медленное, требует не хилых машин, а как следствие - не хилых оптимизаций.
  По статистике(я провёл небольшой опрос среди знакомых и не очень) получается что ~10% времени уходит на разработку(основной кодинг логики, версия 0.1, если угодно). Не важно что это - GAE, Pylons, Django. Не важно что за проект - форум, соцсеть, личный сайт, блог. Одна фигня.
  На что тратится остальное время? Темплейты - да, но часто оно меняется по сложности. Кому сложный сайт с AJAX и JQuery, а кому простой сайтец времён web1.0(как я такое мог сказать... ну, в общем, я думаю вы поняли про что я). Возьмём условно - 20%.
  На что уходят ещё 70%? Чем занимаются веб-кодеры на пайтоне в 7! раз дольше чем основной логикой? Оптимизацией! KVS, быдлокод etc etc. Что можно сказать? Всё круто, да только оптимизировать такой код лично для меня дорого. Да и глядя на то что мой код(да простейший) рендерит страницу за 0,9сек(без KVS), когда другой портал(на том-же VDS) рендерит похожее, да только с большей информацией и несколькими ещё запросами в БД, за 0,5сек(без KVS). Обидно, не правда ли? Оптимизация сильно исправляет положение но... Зачем тратить время на оптимизацию своего кода, когда зло глубже? И да, как сказал уже не помню кто: «Использование KVS это не оптимизация, а кешинг». Что намекает на то что код на пайтоне практически не оптимизируем(можно поспорить, но зачем если правда рядом?)
• Руби. Как много в имени его. Как оно рекламируется, как оно всем нравится, как оно гламурно. И что? Руби считается одним из самых малопроизводительных языков(тоже спорно, но давайте просто скажем что в этом плане он не лучше пайтона, так будет честнее).
  Признаюсь, сам не юзал. Хотя, конечно, приходилось немного кодить для redmine. У кого не спрошу «а почему ты юзаешь?» дык почти все отвечают: «по работе нужно».
  В общем, на одну полку с пайтоном. Чисто так, «округляя».
• PHP. Это язык, в первую очередь, который создан для веба. Производительность? Не скажу что так плохо как у руби или пайтона. Скорость разработки? Фреймворков не мало. Не плохо, жить можно(но не мне).
  Но! Этот язык является сильно ограниченным. Да, есть гтк-биндинг и другие плюшки, но всё это больше похоже на клоунаду.
  Признаться, сам язык не так плох как о нём думают. Однако! Это полностью интерпретируемый язык. Да! Есть сотни компиляторов и оптимизаторов. Но зачем, простите, ипаться с тем что не заложено «внутри»?
  Я говорю что PHP плох. Почему? Есть более простые, серьёзные, удобные, хорошие языки.
• Тут спорить не буду и не хочу. Как выразился тв. «архимаг»: «у лиспа одно спасение - веб». Лично я не вижу применения для него в вебе.
  Быстрый интерпретатор? Может быть. Возможность делать всё что хочешь? Да.
  Но я такое юзать не буду. Не принципиально, просто не буду(уже сто раз говорил чем лисп плох, все согласны, кроме самих лисперов).
• Джава она и в африке джава. Как и эрланг(вы не против что в одном пункте?) это фантастическая платформа для гигантских приложений, где производительность не проблема. Главное чтобы не падало, а точнее падало, но только было максимум механизмов для удержания таких систем на плаву.
  Я к такому отношусь негативно. Почему? Да я готов поспорить что на таких системах теряется уйма производительности(везде, не нужно говорить что я не знаю каких-то механизмов, просто я не хочу раздувать эту тему).

Что можно добавить в этот список? Всякие асп.нет, веб-фреймворки на xml(был тут на лоре один человек) etc etc. Оно не интересно с точки зрения использования в реальном мире.

Картина, мягко говоря, не самая лучшая. Да, есть деньги - будет хоть на брейнфаке с JVM. Но кризис, студентота. Что делать? Думать о оптимизации раньше!

Да! C, C++ и.... D.

• C. Кто не писал на этом языке или считает его ущербным? Да школота и только.
  Нет, у меня не фанатизм, я не считаю что «C - бох» и на него нужно молиться, как некоторые. Но при том что язык низкоуровневый, он ещё и обладает неплохим синтаксисом.
  Всё круто, да вот только нет OOP, что заставило бы в веб-фреймворке делать массу костылей. Не столько костылей сколько вообще не красивый код. Да и управление памятью... Не хочется этим заниматься в веб-фреймворке при написании приложения.
  Да и сам язык хоть и хорош, но только для низкоуровневого.
• С++. Просто для того чтобы не обделять. Язык съедобен, но только с Qt(раньше кодил на C++ без кути, но сейчас просто принципиально не хочу). Ну и всё, просто глупо что-то ещё здесь говорить.
• D. Вам хиханьки и хаханьки, а другим - профит.
  Сам язык является таким C++, но каким он должен быть. Удобным, красивым, быстрым, с функциональщиной и ООП. Да всё в нём есть.
  Оптимизация? Его создатели - короли оптимизации. Сам по себе компилятор оптимизирует ещё в компайл-тайме всё что можно и нельзя. На выходе получаем убершустрый код.
  

Я видел веб-фреймворки(не путать с веб-тулкитами) на плюсах. Мне было страшно. Весь код был в костылях и тысячах темплейтов. Мне было жалко кодеров.
Лично я вижу очень хорошую нишу для D - веб.
Увы, пока язык только развивается, по сему пока приходится писать костыли и придумывать иные пути реализации. Однако, и того что есть достаточно для многих и многих вещей.
Недели 3 назад я начал исследовать данный вопрос и пришёл к выводу - реализуемо, реально, может быть простым и функциональным.

Последний год я использую Python, а в частности Pylons, для вебкодинга(сам я прикладник-сетевик, но деньги нужны, да и потом понравилась логика веб-фреймворков, т.е. сам я html не пишу, ofc). Больше всех мне понравился Pylons. Так-же очень понравились некоторые идеи GAE.
В общем, подумав хорошенько, я решил начать написание веб-фреймворка. Без фанатизма, начиная с самых опасных частей, которые могут убить проект и-за не реализуемости.
И вот оно - Dylons(ха-ха, да-да):
https://launchpad.net/dylons

Работает шустро, проблем нет. Как бэк-енд юзается моя же обёртка - libdfcgi на базе libfcgi.
Олсо, есть абстрактный слой для бекэнда. Хочешь - прикрути свой наследуя нужный класс.
Сейчас над данным экспериментом трудятся два человека - я и мой знакомый. Я пишу основную систему, а он - небольшой темплейт-енжин.
Сейчас самая большая проблема - ORM. QtDSQL просто не существует, т.е. обёртки нет, да и его производительность не на столько велика.
Одна из целей треда - сообщить о таком эксперименте и о том, что нам нужны люди. Не только желающие заняться ORM, но и просто кодеры, что хотят высказать своё мнение о том что хорошо бы сделать и что они хотели бы от Dylons.
Для затравки, вот экземпл.

Далее, пойдём дальше.
В ди нет пока возможностей распаралелливания(да даже на x86_64 нет компилятора, сам юзаю x86-либы). Нет OpenMP(хотя написать то можно, но сложно). Использование в продакшне - ферма. Хотя оно не плохо.

По сему я стал отталкиваться от распаралелизации и вообще шустрой VM. Здесь я слаб. Вижу Parrot. И что? Как там? Говорят не плохо. Но на сколько шустро?

Какие вообще есть мысли у Вас по этому поводу?

Разгребаю код на пайтоне, джанго. Писал один интересный человек, который верил в функциональщину. Почти тру лиспотролль.
Что хочу сказать. Его функциональные фишки отжирают овер 90% времени обработки запроса и рендера.
Оптимизировал самое очевидное и получил не хилый профит.
Опыт кодинга на C и D помог не мало.
Пайтон не медленный(а даже если и медленный, то не так уж как говорят), его замедляют люди, юзающие функциональщину без раздумий о том что «находится за сценой».
Когда код, в котором 7 раз создаются новые лиспы с помощью генераторов и вызывается 5+N раз конструкторы, можно написать не менее элегантно не используя принципы и функционал функциональщины.
Вообще, конечно, важно умение использовать инструменты, но с функциональщиной оно наиболее опасно и менее всего очевидно. Увы.
Вот такой вот возгляд с другой стороны на вашу функицональщину. А я пошёл спать.

Давно юзаю пчелайн. Давно не устраивают цены на гпрс, звонки и смс. Давно было лень перейти на что-то иное.
Сейчас приспичило что пипец.
В общем. Нужен самый выгодный тариф для гпрс(28%)+звонки(70%)+смс(2% от общих трат).
Очень желательно без абонентской платы.
И да, ещё ищется тариф для родных, звонки+смс(70/30%).

Что посоветуете?

Для проекта на Pylons нужно определиться с ORM. Юзаю SQLAlchemy. Однако, подумываю перейти на Storm или что-нить другое. Ибо в SQLAlchemy нет вообще средств для диагностики(даже счётчика запросов в сессии).

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

PS: Сам пока видел что на разных гуглорезультатах разные результаты бенчмарков. Хз кому верить. Где шторм проигрывает в сухую, где SQLAlchemy, где кто-то выдаёт не реальные цифры.

Давно знаю про этот момент, ибо узнал на опыте. Однако всегда было лень заниматься этим. Сейчас вот столкнулся так что пришлось готовить костыли, а не хочется. Суть проблемы видна в данном дампе:

>>> a = dict()
>>> a
{}
>>> a['a'] = '+'
>>> a
{'a': '+'}
>>> a['b'] = '+'
>>> a
{'a': '+', 'b': '+'}
>>> a['c'] = '-'
>>> a
{'a': '+', 'c': '-', 'b': '+'}

Использую pylons. Сейчас дошёл до стадии когда нужно оптимизировать контроллеры используя KVS.
Проблема одна - не знаю как узнать текущее(выполененное) количество запросов в текущей сессии чтобы иметь представление о том как всё страшно/хорошо.

В логгер, конечно, оно всё сыпится, но нет желания городить большой костыль, да и в многопоточной среде я не смогу гарантировать что он будет работать правильно. (Нужно рассказать идею - скажите)
Уже обгуглил всё что можно, прочитал все фаги и хелпы. Может, конечно, упустил что-то, но, надеюсь, меня кто-нить сможет ткнуть носом.

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

Помню как оно было в 98ом: «Линукс это не реально! Хакеры только могут использовать его! Да ну! Русский там не поддерживается! Софта нет вообще! Не реально сложно! Драйверов нет!».
Что оставалось делать? Исправлять проблемы! Русский? Перешли на юникод! Консоль ужасна? Вот иксы! Вот вам Гном, КДЕ! Софт? Вот пайтон! Вот сразу куча софта! Кодеки? Драйвера? Всё пишется! Сложно? Вот вам убунта, мендрива, федора!

Но критики и сейчас желают Линуксу смерти. Что они говорят? Да всё тоже самое! Сложно, нет драйверов, проблемы, глюкилагибаги, нет софта, ужасно, ничегонеработает.

Что делало всё это время линукс-сообщество? Игнорировало все эти тухлые помидоры продолжая совершенствовать ядро ПО для него.

Вот сейчас захотел управлять видеоплеером с модильного через синезуб.
Что мне нужно было сделать?
1) sudo apt-get install bluez-utils
2) Вставить usb-bt
3) Проверить устройство и получить его адрес: hciconfig
4) Загрузить приложение на телефон:
4.1) Скачать j2me-приложение
4.2) Подключить телефон через date-кабель к usb
4.3) Открыть PCMANFM
4.4) Выбрать устройство на сайд-панели(откроется ms-карта)
4.5) Закинуть на карту
4.6) Установить на телефоне
5) Запустить anyremote:
anyremote -f /usr/share/anyremote/cfg-data/Server-mode/mplayer.cfg -s bluetooth:19
6) Открыть приложение на телефоне, вбить адрес и законнектиться

Всё! Мне страшно сколько нужно было бы проделать действий в windows или макоси. Да ещё и не факт что всё бы заработало.

Уже сколько раз убеждаюсь что linux проще windows'а.
Просто вот не понимаю что могут ещё иметь эти критики против linux. Вот не понимаю.
Крик души, да.

Не многим более часа спустя, после боя колоколов, мною был создан тред о языке D. В содержании я описал свой относительно поверхностный взгляд на его текущее состояние. Благодаря некоторым личностям мне удалось взглянуть ближе на «внутреннее» состояние проекта, коммьюнити, языка, реализаций. И да, мне есть что высказать отдельно, в данном треде.

Маленькое введение:
На данный момент язык D является успешно воскрешаемым системным языком программирования высокого уровня. Хочется подчеркнуть два слова: «Системный», «Высокоуровневый». Данные слова редко когда можно встретить рядом. Так получилось что что «Системный» стало синонимом слов: «сложный», «ручной», «быстрый», «низкоуровневый». А «Высокоуровневый»: «медленный», «лёгкий», «большой», «безопасный».

Язык D включает в себя самое лучшее:

• он быстрый - компиляция идёт напрямую в бинарный код, как в c, cpp, pascal
• он лёгкий - синтаксис не сложен. Поддерживаются все возможности CPP. Внешне синтаксис и семантика почти идентичны аналогам в C#.
• он безопасный - за памятью следит сборщик мусора, более не нужно следить за памятью вручную. А сам GC очень быстр ибо его создателями были и являются мировые специалисты по оптимизации. Благодаря конструкциям try, можно легко отловить все проблемы и ошибки, при этом легко оперируя объектами{ом} ошибки.

За пруфами - http://www.digitalmars.com/

Я узнал о том что у нас есть русское коммьюнити, которое активно занимается D - d@conference.jabber.ru
Я пообщался с людьми и смог узнать много нового. И так, обо всём по порядку.

Сейчас есть 2 реализации, на которые стоит обратить внимание:

• DMD - официальная реализация. Сейчас активно развивается D2.0, который сейчас очень даже жив и используется всеми. Последний релиз был несколько дней назад. Сейчас данную реализацию используют почти все, в т.ч. и я.
• LDC - фронтэнд к LLVM. В данный момент слабо развивается, не поддерживает D2.0. Как говорят в коммьюнити, лучшим вариантом для ldc будет вовсе отказ от цели «поддержка D2.0». Увы, это охначает что половина последних проектов прост не запустится и не будет запускаться на LDC. Лично я, пока, забыл про LDC.

Развитие языка, в общем смысле этого слова, представляет из себя странный процесс: основные разработчики занимаются компилятором и стандартом, а всё остальное делают коммьюнити. Лично я пока не заметил чтобы хоть одна коммерческая компания приложила руку к развитию D.

По сему, всё что было и есть в D - творение рук человеческих, а не «лап коммерческих». Что удивительно, коммьюнити успело сделать уже многое:

• Биндинг к GTK - gtkD. Развивается активно. Увы, сейчас есть пара багов из-за изменений в последнем DMD(ну не успели пока).
• Биндинг к QT - qtD. Достаточно большая и сильная разработка. Заявлено что будет реализация биндингов ко всему функционалу QT - в т.ч. и DB, OGL etc.
• Полноценный 3D-движок на opengl с поддержкой glsl - moonglide. Сейчас активно разрабатывается. О всех подробностях разработки всегда можно наблюдать на d@c.j.r.
• Продвинутая система сборки - xfBuild. Сейчас всё больше и больше используется вместо dsss(ныне почти не развивается). Даёт действительно большие возможности. Отличная альтернатива make.
• Интерпретатор+скриптовой язык - miniD. Уже вышел miniD2, который поддерживает D2.0!
• Хорошая библиотека GUI для opengl-based приложений - hybrid. Сейчас используется в moonglide. Очень и очень хорошая либа.
• 2D движок для игр с редактором - ArcLib. От создателя DreadMoon Linux!

И ещё десятки биндингов и хороших проектов: http://www.dsource.org/projects/ http://h3.team0xf.com/ http://talks.dprogramming.ru/

Всё это делает коммьюнити, при этом не просто как «лисперы» и «хаскелеводы», ибо оно нужно и иначе никак, а так, ради забавы. Всё это развивается, несколько людей думают заняться хорошим ORM, кто-то хочет сделать нормальный биндинг python, кто-то переписывает свой проект на D. Язык имеет большой потенциал и развитие идёт. Одна проблема - люди. Цель данного треда - призвать новых людей, заинтересовать всех кого можно. Лично я сейчас прекратил разработку редактора на python и начинаю изучать глубже сам язык D чтобы помочь gtkD в написании биндингов.

Если у вас есть лишнее время, вам надоело считать байты на сях, вы уже погрязли в скобках лиспа и не знаете как из них выбраться, если вы осознали что до релиза(а не промежуточных отчётов-сырцов) UnladenSwallow ждать ещё не мало, если вам надоело что очередной билд вашего приложения течёт из-за того что вы забыли добавить ещё 2-3 звезды(разыменование) в начало переменной, то

присоединяйтесь к нам: d@conference.jabber.ru.

Надпись на этикетке: жир - 0%, бЕлки - ни одной, ккал - овер9к

Как знают некоторые, я планировал написать свой едитор с использованием gtksourceview. У меня был выбор между языками: D, Vala, Python.
Я могу поспорить что D всех нагнёт по своему функционалу и возможностям. Да что там, вы посмотрите на семантику и синтаксис! И это _системный_ язык.
Однако, есть небольшая разница между «стандартом» и «реализацией».
Есть 3, как я знаю, реализации компилятора(хотя один из них по сути интерпритатор):
1) gdmd(gdc) - GNU D Compiler. http://dgcc.sourceforge.net/ Началось всё в 2006ом, заглохло не на много позже - через год, в 2007ом. Больше ничего не выходит, юзает D1.0.
2) dmd - не может юзать x86_64, деградация синтаксиса в последних версиях(что 1.0, что в 2.0), баги, закрытый код etc etc. В общем, хороший вариант, да вот очень сомнительный.
3) ldc - всё более или менее. Единственная надежда. Однако... слабая поддержка D2.0, баги. Стабильности никакой. gtkD при всём желании не компилится, при этом выдавая нормальную ошибку в нормальной строчке, но их не реально логически «состыковать» чтобы решить проблему.
Остальное:
1) dsss - тулза вроде make, но проще, удобнее, красивее. Не развивается уже сколько лет.
2) gtkD - не двигается. Вообще. Новых биндингов для виджетов нет, новых фич нет etc.

Страшно.
Теперь вопросы к вам, дорогие ЛОРовцы:
1) Вам нравится D?
2) Что вам не нравится в D?
3) Вы помогаете D?
4) Почему не помогаете?
5) У вас есть возможность помочь?
6) Почему не помогаете?

Пока, я трактую состояние компиляторов D как «не стабильное, с большими проблемами, без возможности писать что-то и получать разумный ответ». Сам я не системный программист. Скорее прикладник. По сему я просто не могу, не хочу, не обладаю возможностью допиливать компиляторы D. Будет хороший компилятор с поддержкой всех топовых платформ - я могу писать биндинг. Это максимум.
Собственно, цель треда - выявить проблемы D и заставить всех ленивых системнокодеров помочь такому языку.

Как некоторые знают, я писал плагин для geany для получения возможности написания плагинов с помощью пайтона.
Застрял я на том что небыло достойных биндингов scintill'ы к пайтону.
Посему я начал активно продвигать gtksourceview. Написал в рассылку, поговорил с людьми из чатика(IRC).
Пока я сделал один вывод - всем лень, ни у кого нет времени, никто не хочет менять то что и так как-то работает.
Не знал что делать. Думал: «мб написать так нужный мне плагин/патч для мульти-сниппетов?». Ан нет. Посмотрел я сырцы. Ужаснулся. Нет, мысль есть, код не так ужасен, есть даже в некоторых местах комменты. Но частенько замечаю велосипеды и костыли.
Словом, не хочу я писать что-то внутри джини. Думаю, это одна из причин игнорирования предложения о переходе на gtksourceview.
Ну да ладно.
Что нам стоит дом построить^Wредактор уровня джини сколотить?
Я относительно недавно вооружился политикой: «старое пусть останется старым, а мы должны юзать новое, но не хуже чем старое».
Посему ясно было три факта:
1) Используется GTK для ГУИ
2) Используется GTKSourceView бранча с новым hl-движком и фолдингом
3) Берутся многие принципы geany: простота, лёгкость, скорость, надёжность, возможность юзать плагины.
Всё супер. Остался вопрос, который впервые я решил поставить без ограничений: Какой язык программирования выбрать?
Условия:
1) Язык должен быть компилируемым(хоть в байт-код, llvm-код)
2) Современность. Код должен быть относительно современным, без байтоводства, ручной сборки мусора и всякой старой фигни что нужно было оставить ещё в 90ых.
3) У языка должно быть будущее. Нет смысла писать на каком-то языке, который умрёт через год максимум.
4) Скорость. Редактор должен быть легковесным.
Мой выбор остаётся пока между:
1) Python. Язык лёгкий. Я гарантирую что закончу разработку на нём. Если начну. Проблема - скорость и легковесность. Для некоторых недостаточно того что предлагает пайтон. Есть решение - Unladen Swallow(LLVM), но когда ещё оно будет тем на чём можно всё писать... Более минусов нет. Одни плюсы.
2) D-lang. Язык не очень старый, пришёл на замену Си и плюсов. Всё просто супер. Почти доработан. Александреску дал хороший пинок вперёд. Давно интересовался данным языком. Синтаксис похож на джаву(или сисярп). Скорость - компиляция идёт в байт-код для LLVM. Одна проблема - отсутствие аудитории и, как следствие, биндингов к гтк и его приложениям(как gtksourceview). Возможно, придётся самому допиливать gtkD и писать биндинг к gtksourceview. Ужас, да и только. Напишу ли я на нём - хз.

Теперь, немного о том зачем я придумал делать новый велосипед, зачем он и чем отличается от остальных:
1) Лёгкость интерфейса. Гибрид Geany и Scribes.
2) Оптимизированное управление с клавиатуры. Scribes + Vim + emacs + TextMate. Совместим все удобства. Выбирем то что нужно, что привычнее, удобнее.
3) Полноценные сниппеты, хороший автокомплит, просмотр символов, нормальный менеджер проектов.
4) Хороший API для плагинов(ну или хоть чуть лучше чем в джини).
Эм. Ну вроде всё. Лень вспоминать что ещё меня до жути не устраивало в джини. Суть думаю ясна.
Давайте, критикуйте. Кидайте какашки, предлагайте помощь, давайте советы и пишите своё мнение. И да, высказывайте мнение на счёт выбора языка.

Как некоторые уже знают, я пишу плагин для geany, суть которого заключается в возможности писать плагины на пайтоне. Своеобразное ядро-мост.
GTK-виджеты уже нашёл как перекидывать.
Остался вопрос на счёт scintilla, ибо её использует geany как виджет-редактор.
Всё, конечно, супер. Однако на пайтоне есть только 2 достойных биндинга: pygtkscintilla(RIP in 2004), pyqscintilla(RIP in PyQT). Кто-нить что-нить юзал? Какие советы?
Мне тут говорят что сцинтилла тоже RIP'нулась ибо давно не выходило новых версий, да и фиг его знает будут ли.
Советуют юзать GTKSourceView(для которого есть даже родной биндинг к пайтону). Однако джини то юзает сцинтиллу..
Конечно, есть идея взять свежие сырцы джини и перевести его на gtksourceview, но сколько оно времени займёт и получу ли я профит от этого - хз.
Может даже легче самому начать писать свой редактор, но понимаю что некоторые вещи мне одному сложновато будет писать.
В общем, что посоветуете?

Знакомый рассказал про TextMate. Начал поиск похожего под никсы. Наткнулся в гугле на пару тредов.
Нашёл офигенный, не иначе, редактор - http://scribes.sourceforge.net
Понравились сниппеты, компактность, питоноплагины, удалённое редактирование etc:
http://scribes.sourceforge.net/features.html
(Олсо, у него один минус - нет табов)

Говорят что TM имеет эти и не только фичи, но хочется заюзать такое у себя. Однако... NNNOOO! Оно просит гном. Полностью. На ланчпаде Scribes даже называют «редактор для гнома». В общем, я расстроен.
Сам юзаю Geany. Ясно что удалённое редактирование он не умеет. Сниппеты.. пришлось самому гуглить чужие из разных редакторов и делать похожие у себя.

В общем, я в поисках. Хотя думаю что на geany останусь.
Что мб посоветуете?
Сразу оговорюсь что к ви и его детям я отношусь как.. как к пережитку прошлого. А имакс я не люблю из-за лиспа. Посему прошу не флудить.

Занимаюсь сейчас больщим проектом(считайте что форум). Есть необходимость в практически реалтайм-общении. Особо пока оптимизацией не занимался, пока работаю на sqlite(via SQLAlchemy) как БД. Pylons как web-framework.
Недавно делал тред на тему кеширования и оптимизации запросов. Из него сделал выводы что очень полезно юзать KVS для сокращения запросов к основной БД.
Однако я подумал, если все так хвалят KVS, может есть смысл сделать небольшой ORM на базе KVS?
Правда особо не гуглил на существование таковых, но что вы можете рассказать о таких решениях? Есть смысл?

Как пример основы хотелось бы привести именно Tokyo Cabinet с сервером Tyrant. Забавно то, что сам Tyrant создан как БД, хранящаяся на hdd, однако поддерживается репликация, балансировка и остальные фичи масштабирования.
Собственно, что вы думаете?

Уже долгое время использую MPD с NCMPCPP, но понимаю что оно не нужно как демон, да и вообще не удобно рефрешать всю бд каждый раз при обновлении музыки. Да и открыть определённый файл нет возможности, если его нет в директории с музыкой.
В общем, устал и хочу лучшего.
Не обязательно чтобы был nc-интерфейс или вообще консольный, но главное чтобы он был
1) легковесным
2) удобным
3) компактным(или имел такой режим). Небыл бы как, скажем, ритмбокс или подобные(баньши etc).
4) имел возможность скробблинга в last.fm
И, конечно, хочется чтобы можно было исопльзовать плагины и через консоль получать информацию о текущем треке.

Оставляю тред на ночь, утром-днём проверю, ожидаю массу советов >:3