Re: Функционал и инте рфейс
Михаил Миронов пишет: Покотиленко Костик пишет: В Пнд, 16/03/2009 в 15:06 +0300, Михаил Миронов пишет: Проверил список демонов на одной из машин snmpd, courier-imap, courier-pop3, portmap, acpid, dbus, syslog, klog, mysql, apache, cupsd, exim4, freeradius, smartmon, samba, winbind и еще несколько других - все не скриптовые. Единственный найденный скриптовый - xen spamassassin тоже скриптовый, но это его минус, причём большой. Ага. Про него забыл. Значит 2 скриптовых. amavisd -- -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Функционал и инте рфейс
Покотиленко Костик пишет: Не вопрос. Она у него даже малость поуже, чем у C. Проблема в том, что C из своей ниши вылазит... Посмотрим что успешно пишут на Си: драйвера, демоны, серверные, клиентские, десктопные приложения, и т.д. Успешно?! Что считать критерием успеха? Если обосновать написание драйверов на Си ещё как-то можно, то чем ближе к концу указанного списка, то тем труднее обосновать выбор Си, как языка для реализации. Потому что писать на нём правильно и аккуратно крайне непросто, и умеют это делать единицы, а делают слишком многие. А тот факт, что количество приложений, написанных на Си велико никак не говорит об успешности написания этих приложений, да, деньги уплачены, а качество отвратительное. Успешность - слишком неточный термин. Судя по контексту написанного Константином, для меня меня этот термин означает совсем другое. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Функционал и инте рфейс
Покотиленко Костик пишет: [skip] Если посмотреть выше, то речь шла о демонах, а не парсерах текстовых файлов. Или Вы считаете их равнозначными задачами? Есть у меня и демоны на тикле, например, собирают и обрабатывают данные с цисок и других АТС. Написать то же самое на С большая работа (на тикле используются события для прослушивания множества сокетов, а на С придется создавать отдельные потоки), потому и не предлагаю как тестовую задачу (притом демоны умеют держать в in-memory SQLite database те данные, которые не удалось записать в persistent database), не говоря уж о реализации самой логики обработки. Ну, вообще говоря, есть довольно неплохая GLib2 или QtCore, в которых соответствующие примитивы. Вообще говоря, есть libevent, с помощью которой на Си событийно писать проще. Но вообще прикладуху на Си писать не интересно, борьба с языком(слишком низкоуровневый) и развивается паранойя при использовании каждого указателя. Прикол в том, что уровень языка Си выбирается программистом посредством выбора библиотек нужных уровней. На libc конечно тяжело прикладуху писать. Выбор за тобой, а не за языком, используй glib, gtk+, или что тебе больше подходит для конкретной задачи. Уровень языка Си уже определён - он чуть выше ассемблера, и использование библиотек на этот уровень почти не влияет. Как я уже писал, на Си легко работать с объектной моделью, не сложнее чем на C++ или другом языке. Надо тебе крупноузловая сборка - пожалуйста, надо под микроскопом поработать - пожалуйста. А вот языки высокого уровня ограничивают тебя высотой своего уровня. А может Вы просто не пробовали на языках высокого уровня работать с нижним уровнем? -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Функционал и инте рфейс
Artem Chuprina пишет: Покотиленко Костик - debian-russian@lists.debian.org @ Wed, 18 Mar 2009 15:03:57 +0200: Ну так как, пробовать будем? Неа. Если посмотреть выше, то речь шла о демонах, а не парсерах текстовых файлов. Или Вы считаете их равнозначными задачами? Есть у меня и демоны на тикле, например, собирают и обрабатывают данные с цисок и других АТС. Написать то же самое на С большая работа (на тикле используются события для прослушивания множества сокетов, а на С придется создавать отдельные потоки), потому и не предлагаю как тестовую задачу (притом демоны умеют держать в in-memory SQLite database те данные, которые не удалось записать в persistent database), не говоря уж о реализации самой логики обработки. Ну, вообще говоря, есть довольно неплохая GLib2 или QtCore, в которых соответствующие примитивы. Вообще говоря, есть libevent, с помощью которой на Си событийно писать проще. Но вообще прикладуху на Си писать не интересно, борьба с языком(слишком низкоуровневый) и развивается паранойя при использовании каждого указателя. ПК Прикол в том, что уровень языка Си выбирается программистом посредством ПК выбора библиотек нужных уровней. На libc конечно тяжело прикладуху ПК писать. Выбор за тобой, а не за языком, используй glib, gtk+, или что ПК тебе больше подходит для конкретной задачи. ПК Как я уже писал, на Си легко работать с объектной моделью, не сложнее ПК чем на C++ или другом языке. Надо тебе крупноузловая сборка - ПК пожалуйста, надо под микроскопом поработать - пожалуйста. А вот языки ПК высокого уровня ограничивают тебя высотой своего уровня. Как только ты на C выбираешь достаточно высокий уровень, ты немедленно получаешь высокоуровневый подъязык с неудобным синтаксисом и ... правильно, все равно заботой о распределении памяти (почистить за тобой все равно никто не сможет). Таким образом, у тебя в любом случае неудобный синтаксис и в любом случае распределение памяти. Ты от них уйти не можешь. При языке высокого уровня же ты можешь вынести в отдельную библиотеку то, что таки да, надо сделать на C (хинт: вообще-то бОльшую часть работы с низким уровнем и на них можно сделать достаточно эффективно - тот же бинарный протокол на tcl реализовать в разы проще, чем на C). Кстати, Tcl - это сишная библиотека хорошего качества, рекомендую. :) -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Функционал и инте рфейс
Artem Chuprina пишет: Покотиленко Костик - debian-russian@lists.debian.org @ Mon, 16 Mar 2009 19:04:24 +0200: [skip] ПК По этому - чуть шо, получаем какую-то ругань, никому, кроме ПК потенциального хакера не полезную. По ней же ничё не скажешь, кроме ПК версии python. Ну почему ничё? Хотя у перла, как мне кажется, обычно с руганью лучше, но и тут, в общем, можно сказать, что именно слетело. Нету в fields второго элемента. На C ты в этом месте, вероятно, получил бы сегфолт. Ну или (если бы сегфолт вылетел в твоих тестах и ты бы закрылся от него проверкой) невнятное сообщение мама, тут чего-то не хватает. Сегфолт он скорее всего получил бы совсем не здесь и потом бы долго удивлялся, что-то программа свалилась на ровном месте, где никаких указателей нет. Ошибки при работе с памятью обычно вылезают на поверхность за много километров от места взрыва. В этом, я считаю, особая прелесть работы с памятью напрямую, тут отладчик зачастую бессилен помощь. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Функционал и инте рфейс
Покотиленко Костик пишет: В Вто, 17/03/2009 в 21:47 +0900, Alexander Danilov пишет: Artem Chuprina пишет: Покотиленко Костик - debian-russian@lists.debian.org @ Mon, 16 Mar 2009 19:04:24 +0200: [skip] ПК По этому - чуть шо, получаем какую-то ругань, никому, кроме ПК потенциального хакера не полезную. По ней же ничё не скажешь, кроме ПК версии python. Ну почему ничё? Хотя у перла, как мне кажется, обычно с руганью лучше, но и тут, в общем, можно сказать, что именно слетело. Нету в fields второго элемента. На C ты в этом месте, вероятно, получил бы сегфолт. Ну или (если бы сегфолт вылетел в твоих тестах и ты бы закрылся от него проверкой) невнятное сообщение мама, тут чего-то не хватает. Сегфолт он скорее всего получил бы совсем не здесь и потом бы долго удивлялся, что-то программа свалилась на ровном месте, где никаких указателей нет. Ошибки при работе с памятью обычно вылезают на поверхность за много километров от места взрыва. В этом, я считаю, особая прелесть работы с памятью напрямую, тут отладчик зачастую бессилен помощь. Решал много проблем такого рода, не так уж и сложно. Идёшь по пятам аномалий и приходишь к источнику, и, дебагер тут может быть помощником. Это когда аномалия более-менее воспроизводима, а когда бабахнуло через несколько часов после начала работы интерактивного приложения и пользователь не помнить чего он/она там нажимал/нажимала, помогает только пересмотр всего кода с переписыванием подозрительных участков, и то не всегда. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Функционал и инте рфейс
Alexey Pechnikov пишет: Hello! Тот же самый демон намного быстрее написать на скриптовом языке. Существенная разница в производительности будет только на этапе загрузки, что для демона несущественно в принципе. Зато отладка будет намного эффективнее, не нужно перекомпилировать под разные архитектуры и проч. Так что вот как раз демон писать на С не имеет смысла. Как вы думаете, почему в /etc/init.d/ лежат шелловские скрипты?.. Best regards. Демоны почему-то чаще всего пишут не на скриптовых языках. И скажите, неужели Вы думаете, что в /etc/init.d лежат сами исполняемые файлы демонов??? -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Функционал и инте рфейс
Alexey Pechnikov пишет: Hello! On Monday 16 March 2009 14:28:11 Михаил Миронов wrote: Демоны почему-то чаще всего пишут не на скриптовых языках. Ошибаетесь. Большинство написанных в последние несколько лет демонов как раз скриптовые. Вот лет 10 назад да, писали на С в основном, сейчас же очень много написано на скриптовых языках. Проверил список демонов на одной из машин snmpd, courier-imap, courier-pop3, portmap, acpid, dbus, syslog, klog, mysql, apache, cupsd, exim4, freeradius, smartmon, samba, winbind и еще несколько других - все не скриптовые. Единственный найденный скриптовый - xen Докажите свое мнение. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Функционал и инте рфейс
Покотиленко Костик пишет: В Пнд, 16/03/2009 в 15:06 +0300, Михаил Миронов пишет: Проверил список демонов на одной из машин snmpd, courier-imap, courier-pop3, portmap, acpid, dbus, syslog, klog, mysql, apache, cupsd, exim4, freeradius, smartmon, samba, winbind и еще несколько других - все не скриптовые. Единственный найденный скриптовый - xen spamassassin тоже скриптовый, но это его минус, причём большой. Ага. Про него забыл. Значит 2 скриптовых. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
