Анонсирован (http://forum.dlang.org/thread/kutmdh$1on8$1@digitalmars.com) проект Lumen (https://github.com/Dav1dde/lumen), в рамках которого создан плагин, позволяющий задействовать поддержку языка программирования D (http://dlang.org/) в интегрированной среде разработки KDevelop и текстовом редакторе Kate, а также других редакторах KDE, использующих компонент KTextEditor. Плагин обеспечивает поддержку автодополнения кода, семантического анализа и отладки (интеграция с GDB). В своей работе Lumen использует DCD (https://github.com/Hackerpilot/DCD), специализированный серверный процесс для обеспечения работы автодополнения кода в любом текстовом редакторе с поддержкой плагинов или скриптов.<center><iframe width="640" height="480" src="//www.youtube.com/embed/Vo2POmn2_9U?rel=0" frameborder="0" allowfullscreen></iframe></center>
URL: http://forum.dlang.org/thread/kutmdh$1on8$1@digitalmars.com
Новость: https://www.opennet.ru/opennews/art.shtml?num=37793
А вот это уже другое дело! Меня реально заинтересовало! Есть есть плагин для полноценной работы с языком - то это уже большой шаг.И кстати, как там QtD? 5-ю держит или проект издох? Я был бы счастлив от связки Qt + D + IDE.
> А вот это уже другое дело! Меня реально заинтересовало! Есть есть плагин
> для полноценной работы с языком - то это уже большой шаг.
> И кстати, как там QtD? 5-ю держит или проект издох? Я был
> бы счастлив от связки Qt + D + IDE.А что в этом вашем D такого хорошего?
На фоне плюсов в D хорошо всё.
На фоне нормальных языков - ничего.
Насчет "нормальных языков", вот очень меткая цитата:
http://www.linux.org.ru/forum/development/9500118#comment-95...
"Нормальные" это какие?
> "Нормальные" это какие?Для ленивых я таки зацитирую, это действительно жизненно:
Программы, пригодные для использования, почему-то получается написать лишь на языках, непригодных для программирования.
Такой вот парадокс.
> На фоне плюсов в D хорошо всё.
> На фоне нормальных языков - ничего.Я бы не забывал, что D позиционируется как язык общего назначения, на котором, тем не менее, можно делать системные(!) вещи.
Плюс нафаршированность языка (делегаты, замыкания, диапазоны вместо итераторов, полная интроспекция, мощнейшая система шаблонов (см. миксины)) и при всём при этом н чувствуется никакой громоздкости.Может, и не взлетит, но вещь весьма достойна внимания.
PS: и не лишена некоторого шарма. Смотри, например, "Вольдемврот.... э... Вольдемортовские типы".
D позицианируется как системный язык. Для прикладной разработки языки быстрой разработки (из готовых компонентов) - Java, C#, ... Так написано в предисловии.
Отсюда: http://dlang.org/overview.html
D is a general purpose systems and applications programming language
Большой шаг? В MonoDevelop сто лет уже плагин с нормальной поддержкой есть.
Если честно, не знал. Там D 2.0? Надо бы попробовать.
Да, я в курсе. К сожалению, Monodevelop штука довольно примитивная, так что появление поддержки в KDevelop очень интересно.
Язык D не взлетел по одной простой причине: зачем что-то писать на D, когда есть C++. Все сложности расписанные челом по ссылке в одном из постов выше не так уж и серьёзны как может показаться, кроме того быстрых GC ещё никто не изобрёл.
> быстрых GC ещё никто не изобрёл.портится анонимус, портится. раньше умные вещи говорил, а теперь лжёт и бредятину несёт.
inb4: нет, гугли сам. если сможешь.
Это примерно как с человеческими языками, если сравнивать. Си это язык, а остальное, это его диалекты. А вообще, мне кажется D лишним, т.к. в плюсах наворочено всего на все случаи жизни на десяток лет вперед и наверно жизни не хватит чтобы даже плюсы осознать на все 100%.
Вот в D и попытались выкинуть все лишнее и сделать более удобным нужное, чтобы не надо было тратить половину жизни на изучение языка.
Открою тайну — на изучение языка надо тратить всю жизнь (трудовую).
Вот такая вот селяви и следствие пословицы "век учись" для программера.
Всё остальное самообман.
А когда же программы (не учебные) писать ? :)А если серьезно, то чем сложнее и дольше в изучении язык, тем тяжелее подобрать команду для проекта, так как либо код будет слишком сложен для молодых и будет уходить много времени на поднятия их уровня, либо придется умышленно отказаться от использования языковых изысков.
Нельзя не согласиться. Но зато ценность в спецах, которые знают то, чего другие не знают, очень возрастает. Ну собственно и ценник за зряплату :)
Ну собственно и баги потом в состоянии отловить не каждый Василий. И на кой Х мне нужен такой язык? Зачем я буду платить этим избранным и что делать когда такой товарищ меня покинет? Через два года он сам не разберется в своих вывертах. Сложность - она как раз в простоте. Как сделать так, чтобы пришедший после меня не тратил своё время на понимание рафинированных конструкций, доступных только избранным. Даже избранным нужно для этого время. Далеко не нулевое.
Поверьте - ловить в "простом понятном С" баги - тоже занятие очень на любителя. Особенно фокусы вида "угадай где произошло переполнение буфера".Некий баланс нужен, в D он, как мне кажется, есть - по крайней мере, чужой код я вполне себе отлаживал, без особых проблем - а там и метапрограммирование было, и CTFE.
> Поверьте - ловить в "простом понятном С" баги - тоже занятие очень на любителя.В простом и понятном си тоже можно писать программы как полная долбанашка. Я тут как-то видел файлик - 500 кило, однако. Одним файлом ;).
> Особенно фокусы вида "угадай где произошло переполнение буфера".
А вот это нам расскажет GDB и стектрейс...
> Некий баланс нужен, в D он, как мне кажется, есть
В целом он даже не так уж дурно смотрится, но вот странность компилеров и не меньшая странность сабжевых субъектов, укурившихся до написания демона раскраски кода - несколько портит картину.
>В простом и понятном си тоже можно писать программы как полная долбанашка. Я тут как-то видел файлик - 500 кило, однако. Одним файлом ;).Угу, я тоже видел. Но в данном случае код как раз написан довольно хорошо - просто здоровый он, просто статистически баги неизбежны. И вот вид этих багов - то, что они не логические, а всяка порченая память и неверные диапазоны индексов - быстрому отлову не особо способствует.
> А вот это нам расскажет GDB и стектрейс
Дык - но расскажут, где упало. А потом бывает увлекательный процесс поиска - какая дрянь затерла служебные структуры маллока :-)
> В целом он даже не так уж дурно смотрится, но вот странность компилеров и не меньшая странность сабжевых субъектов, укурившихся до написания демона раскраски кода - несколько портит картину.
Эм... При чем здесь компилятор к демону?
> всяка порченая память и неверные диапазоны индексов - быстрому отлову не
> особо способствует.Ну да, это, конечно, не логические баги. А какие? :)
>> А вот это нам расскажет GDB и стектрейс
> Дык - но расскажут, где упало. А потом бывает увлекательный процесс поиска
> - какая дрянь затерла служебные структуры маллока :-)Ну это уже какая-то экзотическая редкость. Обычно как раз все просто и понятно.
> Эм... При чем здесь компилятор к демону?
При том что те кто сильно др@чит на чрезмерно концептуальные вещи обычно страдают бзиками несовместимыми с реальным миром. По поводу чего получается так как кто-то на ЛОРе сказал :). Вот тут эталонный пример - язык улучшили, зато для его подсветки надо наср@ть целым отдельным демоном в систему. Что за непотребство?!
> Дык — но расскажут, где упало. А потом бывает увлекательный процесс поиска
> — какая дрянь затерла служебные структуры маллока :-)valgrind знает.
>А если серьезно, то чем сложнее и дольше в изучении язык, тем тяжелее подобрать команду для проекта, так как либо код будет слишком сложен для молодых и будет уходить много времени на поднятия их уровня, либо придется умышленно отказаться от использования языковых изысков.Ваш идеальный язык: php
Простота вхождения и скорость обучения до состояния написания первых крупных программ поражают. Молодые программисты смогут уже через пару дней осилить язык до уровня, когда уже будут делать свои первые в корпоративный svn/cvs и рассказывать на форумах о божественности данного языка.
Обучению данному языку способны все и таким образом подобрать команду для проекта не составляет никакого труда. Также преимуществом данного языка является низкая з/п типичного программиста, а также возможность быстрой заменой выросшего в уровне программиста (и требующего бОльшую з/п) на менее требовательного без видимой потери для проекта.
Для каких-то задач, вполне возможно. Для моих ближе всего к идеалу как раз D.
На изучение языка должно уходить неделя времени. Если это не так, то язык - говно запутанное. Описание любого языка Вирта занимает не более 30-35 страниц с примерами.
Смотря что считать изучением. Если "написать что-то свое", то неделя это очень много, обычно хватает пары дней, если же "уметь сходу понять написанное другими" и "уметь эффективно использовать все возможности языка", то для некоторых языков и полгода может быть мало.
>На изучение языка должно уходить неделя времени.Глупости говорите! За неделю можно прочитать и в общих чертах понять спецификацию ЯП, но не более. Ну, да - после этого вы будете в состоянии набыдлячить пару кило текста которое гордо назовете программой, но по настоящему до вменяемого кода вам придется идти не один и не два месяца (а с учетом уровня ваших постов, процесс может и на годик-другой затянуться)!
Попробуйте, к примеру, за неделю изучить ява-скрипт, - и после такого "изучения" ваш "перл" с радостью опубликуют коллеги ..... в разделе "как не надо писать код"
Я и не говорю про доскональное изучение. Хотя принципы везде одни и те же. Имея представление об одном языке гораздо проще изучить другой. Best practices - это другое. Ковыряние в stl - тоже.Попробуйте за неделю в крестах разобраться. Да там только на прочтение Страуса гораздо больше времени уйдёт. Си по этому критерию может претендовать на хороший язык. ПлюсЫ - нет.
Я вам скажу, что и читать Страуструпа не каждый сможет, он достаточно строго описывает чисто плюсы, подразумевая что вы знакомы с си. лучше начинать со Стивен Прата. А вообще, чем больше заинтересованный человек читает про плюсы, тем больше осознаёт убогость и не зрелость остальных языков. Согласен, читать плюсы очень трудно, а понимать ещё труднее, но после его частичного изучения вы сами почувствуете, как у вас мозг перевернется и будите смотреть на мир ИТ другими глазами))
Плюсы могучи, но уж больно много там внимания приходится уделять тому, чтобы не найти себе поблемы. Невиртуальные деструкторы - очевидный пример.Второй минус - там исторически сложился очень тяжеловесный подход к написанию кода - жирные иерархии классов и т.п. Сейчас уже умеют делать проще, но многие профи так привыкли, библиотеки так написаны... В результате частенько видим многословность джавы с рисками плюсов.
>Сейчас уже умеют делать проще, но многие профи так привыклиНа самом деле, когда Страуструп писал свой труд, то на тот момент времени и о динамической типизации-то имели самое общее понятие (на примере SmallTalk в основном). Да и о STL тогда никто ничего не слышал.... все это куда позже (лет на пять) прикрутили, а адепты сипп за это схватились и стали кричать на всех углах о гениальности Страструпа. Не, дед, конечно, пан-гениален, но все же немного не в том аспекте, куда сейчас слоняется вектор развития современных ЯП, ИМХО. Отсюда и неадекват школьников изучивших его как классику, и еще не понявших, что в ИТ классика устаревает быстрее, чем стареет ее автор.
Ну, гениален он как раз в том, что язык получился такой, что его куда угодно оказалось возможным приспособить, хотя иногда - с отчетливым скрипом. То, что сотворил Степанов, а особенно Александреску - яркий пример. boost::spirit - тоже, но уже за гранью добра и зла. А дальше надо было бы делать для этого адекватные инструменты - но комитетчики фактически не дали довести это до нужного уровня - см. те же зарезанные концепты.А когда концепты таки есть - динамическая типизация оказывается пережитком, выросшим из тех времен, когда вывод типов в мейнстримных языках был чем-то экзотическим и было ровно два варианта - либо пишем дикие описания типов, либо не имеем типов вообще. Сейчас вполне реально иметь и выгоды от статической типизации - самодокументирование и быстрый отлов ошибок - и простоту кодописания, как в языках с динамической типизацией. Собственно, как раз в D это использовано очень удачно и на всю катушку - мне в голову не придет выяснять, какой Range ко мне прилетел - лишь бы соответствовал нужному концепту.
>>На изучение языка должно уходить неделя времени.
> Глупости говорите! За неделю можно прочитать и в общих чертах понять спецификацию
> ЯП, но не более.а что ещё надо-то? всё равно большинство «мэйнстримных» языков семантически друг от друга не отличаются.
> Попробуйте, к примеру, за неделю изучить ява-скрипт
ой, это сложно. может, до пары дней сократишь? никак не могу придумать, что там неделю делать.
> и после такого «изучения»
> ваш «перл» с радостью опубликуют коллеги ….. в разделе «как не
> надо писать код»понимаешь, в чём дело: если для тебя js кажется мегасложным — это не значит, что он такой и есть. это всего лишь значит, что у тебя багаж знаний хреновый, и ты в js не видишь давно знакомых вещей. сильно советую тебе перейти от максимы «я в мире самый умный и больше всех знаю, меня никто не может превзойти» к более обоснованой: «я таки очень глупый и невежественный, умнее и образованней меня почти все вокруг».
> Открою тайну — на изучение языка надо тратить всю жизнь (трудовую).
> Вот такая вот селяви и следствие пословицы «век учись» для программера.
> Всё остальное самообман.вы прочитали кукареканье петушка, предвидящего растрату своей бесполезной жизни на бесполезное изучение бесполезного языка.
Сложность кода никуда не девается. Либо имеем адекватно слохный язык - либо, как в джава-мире - сложность выпихиваем в библиотеки и фреймворки (и DSL аннотаций). И тогда оказывается, что язык освоить за неделю вроде как можно, а писать на нем - нет, потому что надо еще и концепции этих самых фреймворков изучить.А вот на сях я нечто большое сейчас писать все же не взялся бы. Либо его надо закрывать жирнейшим слоем надстроек, чтобы о таких вещах, как переполнение буфера, не думать, либо будут проблемы. Но в первом случае уж лучше тогда взять язык, где эти надстройки сделаны до меня. Это даже если не говорить о "выразительности", "способах описания абстракций" и других штуках, которые становятся понятными, когда берешься подддерживать проект пятилетней давности и выясняется, что понять, как думал автор - не можешь, а исходник помогает примерно как ассемблеровский - т.е. команды есть, а смысл разобрать проблематично.
>Либо его надо закрывать жирнейшим слоем надстроек, чтобы о таких вещах, как переполнение буфера, не думать, либо будут проблемыИменно так и подумали пацаны из Купертино. И не только они. Собственно их "жирнейший слой" открыт под свободной лицензией (ссылку сейчас найти сходу не могу, но Огрызок точно открывал либы, работающие ниже какава, и реализующие управление выделением и уборкой памяти под динамические структуры)
Может быть вполне, я с макосью не знаком, как и с Objective C. Но вот на чистых сях писать лично мне не хотелось бы. А из того, что видел - мне понравился именно D, либо на худой конец плюсы без наследования в пользовательском коде.
Ура, блин!
Как раз искал какой-нибудь IDE для D, а кроме эклипса и нету ничего, все остальное под винду.
По нашему мнению язык D является очень перспективным. C++11 это кастылизация инвалида.
> По нашему мнению язык D является очень перспективным. C++11 это кастылизация инвалида.На, скушай: https://www.opennet.ru/openforum/vsluhforumID3/91480.html#22
> В своей работе Lumen использует DCD, специализированный серверный процессДожили. Так, а для перемещения курсора нам еще не пора создать отдельный серверный процесс? Кедятина она такая - плодит ср@ч в списке задач всем чем может. От мускульной базы до демонов подстветки текста.
А чем плоха идея абстрагировать дополнялку от её клиента? Тем, что лишний PID съест? Скорость IPC там, ясное дело, не проблема - что не так?
> А чем плоха идея абстрагировать дополнялку от её клиента?Ничем. Вынести в shared либу, etc. Но у кедерасов - как обычно все...
> Тем, что лишний PID съест?
А также будет постоянно кушать память, загаживать собой список процессов и тому подобные прелести. Вот дэмо то.
> Скорость IPC там, ясное дело, не проблема - что не так?
Ну вот я предлагаю для доведения концепции до ума забомбить демон который курсор в программах будет двигать. Для логической полноты картины, так сказать.
Память оно будет есть одинаково, если что. PID - неприятно (и что-то с бардаком в PS вообще делать надо), но есть и жирные плюсы. Например, тот же компилятор D написан так, что память он не освобождает. Вообще. Весь расчет на то, что он откомпилировал один модуль и умер. Такой подход позволяет поднять его скорость работы раз в пять, если не ошибаюсь. Второе. Компилятор - штука сложная, и иногда они падают. Лично я ронял и gcc, и dmd, и не раз. Да, именно на стадии синтаксического разбора Отдельный процесс хоть за собой ничего не утянет. И учтите при этом, что гарантировать качество "подсветчика" клиент подсветки не может и не должен.В общем, как по мне - абсолютно оправданное решение.
> с бардаком в PS вообще делать надо),Я вот сделал. Например, #@$нув кеды на#$%, ибо задолбали. Сразу список стал раза в три лаконичнее. XFCE такими заскоками не страдает. А также не тyпит, не пытается сватать мускульные базы и решения для всего и вся типа хранения почт и контактов для своих кривых недоклиентов, заинтегрированные в систему хуже чем IE в win95. Короче, мне десктоп надо а не универсальный ответ на все вопросы жизни и всего такого, с встроенной кофе-машиной и автоматической ж@повытиралкой и всякими средствами для склеротиков-имбецилов.
> но есть и жирные плюсы. Например, тот же компилятор D написан так, что память он
> не освобождает. Вообще. Весь расчет на то, что он откомпилировал один
> модуль и умер.Я не понял при чем тут компилятор. Чуваки запилили демон для раскраски исходников, как я понял. Долбануться, следующим должен появиться демон для таскания курсора во всех редакторах которые используют этот кульный компонент с кульным плагином. Это было бы по кедовски - загадить список процессов какой-то требухой, смысл существования которой мало кому очевиден кроме ее авторов. Почему это нельзя сделать просто шаред библой, приписанной к PID того кому она нужна - не особо понятно.
> В общем, как по мне - абсолютно оправданное решение.
Вот вы и пользуйтесь всей этой кедарасией наздоровье, а с меня - хватит. Мне такой феерический гадеж процессами поперек глотки. Как не посмотришь список - там от кедарасии по 100500 процессов. Скачать файлик? Отдельный процесс! Который к тому же вечно виснет и глючит. Вот это да, истинно по кедорасовски! Гадить процессами часто и много, загаживая ими вообще все что можно в принципе загадить. F...k you, dear KDE. F...k you. Искренне рад что избавился от оных.
>Я вот сделал. Например, #@$нув кеды на#$%, ибо задолбали. Сразу список стал раза в три лаконичнее. XFCE такими заскоками не страдает. А также не тyпит, не пытается сватать мускульные базы и решения для всего и вся типа хранения почт и контактов для своих кривых недоклиентов, заинтегрированные в систему хуже чем IE в win95. Короче, мне десктоп надо а не универсальный ответ на все вопросы жизни и всего такого, с встроенной кофе-машиной и автоматической ж@повытиралкой и всякими средствами для склеротиков-имбецилов.Это ты рассказываешь человеку, который сидит в тайловом WM, если что :-) Но сейчас даже ядерных процессов в ps я вижу штук 40, наверное.
>Я не понял при чем тут компилятор. Чуваки запилили демон для раскраски исходников, как я понял. Долбануться, следующим должен появиться демон для таскания курсора во всех редакторах которые используют этот кульный компонент с кульным плагином. Это было бы по кедовски - загадить список процессов какой-то требухой, смысл существования которой мало кому очевиден кроме ее авторов. Почему это нельзя сделать просто шаред библой, приписанной к PID того кому она нужна - не особо понятно.
Смотри - код синтаксического разбора - он чужой, за его качество КДЕшники и близко ручаться не могут. При этом желательно, чтобы если оно упадет (а за компиляторами это водится) - за собой всё остальное не тащило. Вариант только один - дёргать отдельный процесс, от сегфолта больше ничего не спасёт. Другое дело, что именно в случае D можно сам dmd дергать и получать дерево в JSON - но они ж универсальную тулзу делают.
> Это ты рассказываешь человеку, который сидит в тайловом WM, если что :-)А что, кеды не радуют? :)
> Но сейчас даже ядерных процессов в ps я вижу штук 40, наверное.
Согласен - может анноить. Хотя по ps -AFH оно остается как чайлд kthreadd и не особо мозолит глаза. Хотя тоже поразвели, блин, с*ки.
> и близко ручаться не могут. При этом желательно, чтобы если оно
> упадет (а за компиляторами это водится) - за собой всё остальное
> не тащило. Вариант только один - дёргать отдельный процесс,Пошли бы они с такими методами, имхо. Воркэраундинг падучих глюкастиков путем развешивания демонов - ну-ну, удачи этим пудакам в таком подходе. А я то думаю - накукуй они свое убер-глюкавое kio, вечно плодящее по 100500 зависших процессов так делали. А это оказывается - чтобы глюки в этом шите не чинить. Вот оно что. А потом как посмотришь в список процессов - а там 100500 повисших наименований этого добра висит.
> они ж универсальную тулзу делают.
Ну да, кедарасы уже делали универсальную буетень для хранения контактов в мускульной базе. Я, правда, упорно не догоняю зачем мне этот шит в системе. Им пользуется только кедарасовский уродский IM клиент и такой же кривой почтарь, и более - НИКТО. В результате масса "общего" г@вна - для двух горбатых программ, которыми я пользоваться не собираюсь. В данном случае кедарасы остались верны этой традиции и опять сделали какое-то супре-решение всего и вся. Которое опять пытается всех осчастливить. Заткнув глюки шита по принципу "да ну нафиг чинить краши, мы лучше замаскируем их под пенька".
А я давно на LXDE сижу. Тоже когда то кеды достали. Недавно думал вернусь на кеды, а вы меня расстроили, похоже с 2006 года ничего не изменилось.
> Вот вы и пользуйтесь всей этой кедарасией наздоровье, а с меня —
> хватит. Мне такой феерический гадеж процессами поперек глотки. Как не посмотришь
> список — там от кедарасии по 100500 процессов. Скачать файлик? Отдельный
> процесс! Который к тому же вечно виснет и глючит. Вот это
> да, истинно по кедорасовски! Гадить процессами часто и много, загаживая ими
> вообще все что можно в принципе загадить. F…k you, dear KDE.
> F…k you. Искренне рад что избавился от оных.даёшь всё в ядре! а то как не посмотришь — для кучи вещей отдельные процессы! совсем с ума посходили! то ли дело в Правильной ОС, например: внесли графику в ядро модулем — и отлично получилось.
намёк ясен, нет?
На самом деле, анонимус прав: если у вас n-количество процессов, запущенных одновременно, и нуждающихся в определенном сервисе, то сделать этот сервис в качестве отдельного демона - оптимум. Но... Crazy, а Вы уверены, что рядовой кедераст запустит достаточное количество клиентов потребляющих этот сервис? В смысле, достаточное, что бы издержки межпроцессного общения перекрывались количеством сэкономленной памяти? Честно сказать, я вот думаю, что на стандартном десктопе одновременно будет работать _от силы_ пара клиентов-приложений. А в этом случае, оптимум уже общая библиотека. Не?
Меня здесь интересует в основном то, что при падении совершенно факультативного сервиса (подсветка) по любой мыслимой софтовой причине его клиент (возможно - с несохраненными изменениями) не упадет. Я не знаю иного способо защитититься от падения по сегфолту кроме выноса в отдельный процесс. А учитывая, что парсер - это плагин, скорее всего сторонний и возможно - весьма кривой - вынос в отдельный процесс - идея очень правильная.
> кривой - вынос в отдельный процесс - идея очень правильная.Ах вот зачем они kio сделали не либой а отдельными процессами, на скачку каждого файла свой. Теперь я наконец понимаю почему это гуано перманентно виснет и загаживает собой список процессов. Оказывается эти чудики вместо починки глюков просто заметают мусор под ковер. Вот оно чего.
Зато плазма уже не падает. Гм... почти не падает.