Серверные программы написанные на каком языке вы предпочитаете? (Опрос)

[korisk]

Интересует уровень доверия к ПО в зависимости от языка программирования.
Спасибо за ответы.

[allez]

Не хватает варианта "Мне без разницы".

[drBatty]

идиотский вопрос. Вы ещё на форуме автомобилей спросите:

с каким инструментом вы поедете:

• отвёртка
• домкрат
• ключ 10х12

и уберите мультивыбор. Так и хочется послать ТСа куда-нить подальше с ОДНИМ из этих инструментов...

[drBatty]

Интересует уровень доверия к ПО в зависимости от языка программирования.

ещё более веселее. Какое может быть доверие к быдлокодеру, который делает XYZ на не предназначенном для того ZYX?

[korisk]

Интересует уровень доверия к ПО в зависимости от языка программирования.

ещё более веселее. Какое может быть доверие к быдлокодеру, который делает XYZ на не предназначенном для того ZYX?

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

Например простенький прокси для проброса портов:
Есть вариант на Perl, Python, C, C++ и bash(с помощью nc). Какой вы опробуете первым?

[neol]

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

[drBatty]

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

не бывают. Бывают ситуации, когда есть годная программа на python'е, а администратор сервера ненавидит питон ибо упёртый.

А программу пишет программист, а не ЯП. Если программист говнокодер, то он пишет говнокод. И ЯП к этому ортогонален.

Например простенький прокси для проброса портов:
Есть вариант на Perl, Python, C, C++ и bash(с помощью nc). Какой вы опробуете первым?

я попробую обойтись без костылей.

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

тут наверное речь не о программах, а о костылях. По типу моих sed/bash скриптов.

[antares0]

bash(с помощью nc).

Это в моем представлении и есть правильное использование маленького сервера на C. По жизни пишу на "другом" но из перечисленых варинатов лучше С.

[eddy]

Естественно, сишные CGI.

[Женя Подсыпальников]

Почему-то склонен считать,
что в С++ больше попыток "рисовать", "защищать" и "тестировать".

В общем практическом случае - то туфта, конечно,
хило написать можно везде

[SLEDopit]

Естественно, сишные CGI.

Тут можно спорить до посинения, но C -- не самый лучший выбор для CGI. Хотя бы как минимум из-за существенно большей трудоёмкости и времени работы для одного объёма работы, если сравнивать с некоторыми другими языками. Ну и к тому же, одним CGI тут дело не ограничивается. Точнее даже вообще не в нём дело.
Если я правильно понял вопрос ТС, то его можно перефразировать так: если бы вам предложили выбрать nginx ( apache, postgresql, etc ) написанный на C / python / brainfuck / etc , какой-бы вы выбрали?

[eddy]

C -- не самый лучший выбор для CGI.

Для меня — самый. Язык элементарный, все понятно. Работает. Не тормозит.

одним CGI тут дело не ограничивается

Ограничивается: веб-морда элементарно на html с жабоскриптом пишется.

Если я правильно понял вопрос ТС, то его можно перефразировать так: если бы вам предложили выбрать nginx ( apache, postgresql, etc ) написанный на C / python / brainfuck / etc , какой-бы вы выбрали?

А, я неправильно понял.

Кстати, в узкоспециализированной элементарщине вообще никакой веб-сервер ставить не надо: пишем демона, который помимо обработки POST-запросов еще и GET-запросы обрабатывает и выплевывает нужные веб-страницы.

[drBatty]

Если я правильно понял вопрос ТС, то его можно перефразировать так: если бы вам предложили выбрать nginx ( apache, postgresql, etc ) написанный на C / python / brainfuck / etc , какой-бы вы выбрали?

а есть выбор?

Для меня — самый. Язык элементарный, все понятно. Работает. Не тормозит.

php чем не подходит? У тебя не работает/тормозит? Ключевое слово "у тебя".

[eddy]

php чем не подходит?

Жестокая гадость же! И нафига учить еще один ЯП?

Ключевое слово "у тебя".

А мне до остальных дела нет.

[SLEDopit]

Для меня — самый. Язык элементарный, все понятно. Работает. Не тормозит.

Круто. Только вот сколько времени нужно на написание простенького сайтика а-ля персонального блога с возможностью комментирования, регистрации и хранения всей информации в базе данных ( хотя бы sqlite3 ) на С? И сколько на том же python'e?

И нафига учить еще один ЯП?

Действительно. Зачем Ритчи вообще С придумал? Писали бы все себе на asm'е.

[drBatty]

Жестокая гадость же! И нафига учить еще один ЯП?

для экономии времени.

Круто. Только вот сколько времени нужно на написание простенького сайтика а-ля персонального блога с возможностью комментирования, регистрации и хранения всей информации в базе данных ( хотя бы sqlite3 ) на С? И сколько на том же python'e?

кстати, вы не правы. Разница не очень велика.

[SLEDopit]

кстати, вы не правы. Разница не очень велика.

Не велика, потому что python, а не php или просто в принципе не велика?
Ну и потом для python'a есть django/flask/etc. С ним задачу можно реализовать меньше чем за полдня. Для С тоже есть какие-то фреймворки. Но не уверен, что они настолько же ускоряют работу.
ps. Ну и даже если сравнивать всё "по-честному", то на python'e всё равно быстрее получится. Там не нужно о доброй половине тех вещей париться, которые в C опустить просто не получится.

[drBatty]

Не велика, потому что python, а не php или просто в принципе не велика?

в принципе не велика. Все эти встроенные строки недолго накостылить и на сишечке, как и пхпшные/питоновские структуры данных(списки/словари). И ещё не факт, что будет лучше.

Ну и потом для python'a есть django/flask/etc.

это да, но вы про "написание простенького сайтика а-ля персонального блога". Зачем там jango? https://www.google.ru/search?q=django+vulnerability вот этого не будет зато (:

Ну и даже если сравнивать всё "по-честному", то на python'e всё равно быстрее получится. Там не нужно о доброй половине тех вещей париться, которые в C опустить просто не получится.

вот только в C парится нужно всего раз. В отличие от php, в котором строки-то есть, но вот сравнивать их нельзя как обычные величины, надо strcmp(). В питоне наверняка тоже полно таких тонкостей. Всё это вместе взятое нивелирует то, что в сишечке нужно подбирать за собой ошмётки памяти.

Ну и ещё раз: пишет не ЯП, пишет кодер.

[azsx]

а кто нибудь знает аналогичные проекты cms на c?
вот пример http://cppcms.com/wikipp/en/page/main

[eddy]

Только вот сколько времени нужно на написание простенького сайтика а-ля персонального блога с возможностью комментирования, регистрации и хранения всей информации в базе данных ( хотя бы sqlite3 ) на С? И сколько на том же python'e?

Без понятия. А вот веб-морда для управления всякой хренью создается где-то за месяц. На пхытоне, возможно, знающий пхытон написал бы быстрей. Но нафига мне такое уродство? Пхытон только для GUI годится, если нужно для CLI'шных программ сделать по-быстрому какую-нибудь гуйню.

для экономии времени.

Вряд ли.

Там не нужно о доброй половине тех вещей париться, которые в C опустить просто не получится.

Зато придется париться по поводу других вещей. Скажем, как передавать и хранить бинарные данные? Пхытон даже не имеет типов данных! Недоязычок какой-то.

[drBatty]

как передавать и хранить бинарные данные?

php::строки разве не подходят?

[SLEDopit]

Скажем, как передавать и хранить бинарные данные?

Бинарные данные -- как раз такая штука, от которой следует бежать при первой возможности. И использовать исключительно в случаях, когда деваться больше некуда. Тем не менее, обрабатывать бинарные данные в python'е вполне можно. И типы данных там есть.

вот этого не будет зато (:

Несомненно, у вас уязвимостей будет значительно меньше. Ядро то, я надеюсь, вы тоже своё написали? А то в линуксовом СТОЛЬКО уязвимостей, что даже скачивать страшно.

[eddy]

как передавать и хранить бинарные данные?

php::строки разве не подходят?

Мы про пхытон говорили. Хотя, пыхпых и пхытон - одного поля навоз.

И использовать исключительно в случаях, когда деваться больше некуда.

Неправда. Всякие JSON'ы нужны лишь если мы хотим дать человеку возможность непосредственно редактировать эти данные, а если ему туда лезть не надо, бинарные еще и места мало занимают.

И типы данных

какой ужас!

[SLEDopit]

Неправда. Всякие JSON'ы нужны лишь если мы хотим дать человеку возможность непосредственно редактировать эти данные, а если ему туда лезть не надо, бинарные еще и места мало занимают.

Правда. Я не говорю исключительно про json/xml или какой-то иной конкретный формат. Если есть возможность, то текстовый формат всегда лучше бинарного. Как минимум по той простой причине, что он читабельнее для человека и не нужно мучаться со специальными утилитами для его чтения/редактирования. К тому же, посмотрите на файлы в своей системе: /etc/passwd, /etc/shadow , /etc/group и прочие. Они, почему-то, все как на подбор в текстовом формате, а не бинарном. Хотя, казалось бы, прямое редактирование этих файлов в обход стандартных утилит на слишком приветствуется.
Любителям повсеместно воткнуть бинарный формат часто рассказывают занимательную историю: в далёкие-предалёкие времена, когда только-только на свет появился Боинг 747 ( а это был аж 1969 год ), системы бронирования мест внезапно перестали качественно выполнять свою задачу. А всё потому, что они использовали бинарный формат для хранения своих данных: им нужен был какой-то жалкий один байт на каждого пассажира. Только в 747 внезапно влезало больше 255 человек, к чему программа была явно не готова. (:

[drBatty]

Бинарные данные -- как раз такая штука, от которой следует бежать при первой возможности.

ничего, что все ваши словари/списки и прочая ерунда == бинарные данные?

Несомненно, у вас уязвимостей будет значительно меньше. Ядро то, я надеюсь, вы тоже своё написали? А то в линуксовом СТОЛЬКО уязвимостей, что даже скачивать страшно.

передёргиваете.
1. ядро у всех есть
2. в ядре баги оперативно закрывают
3. И самое главное: сколько будет стоить взлом вашего бложика на джанго, который вы напейсали за полдня, и бложика Эдуарда на сишечке? Уверен, ваш поломает четвёртый пионер. А бложик Эдуарда может достичь высокой популярности, и всё равно туда никто не полезет. А кто полезет, то ломать ничего не станет.

Посему хитрый план Эдди имеет право на жизнь -- у него как влитой стоять будет, а вы будете латать дыры 24/7/365.

Такие дела...

[drBatty]

то текстовый формат всегда лучше бинарного.

для передачи/внешнего хранения. И только.

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

число double читабельно? Какого ляда вы юзаете double???

К тому же, посмотрите на файлы в своей системе: /etc/passwd, /etc/shadow , /etc/group и прочие. Они, почему-то, все как на подбор в текстовом формате, а не бинарном.

вы ещё /proc/cpuinfo вспомните, и доказывайте на его примере "текстовость CPU".

Хотя, казалось бы, прямое редактирование этих файлов в обход стандартных утилит на слишком приветствуется.

не приветствуется, но допустимо. Есть и возможность чтения.

Любителям повсеместно воткнуть бинарный формат

демагогия детектед.

в далёкие-предалёкие времена, когда только-только на свет появился Боинг 747 ( а это был аж 1969 год ), системы бронирования мест внезапно перестали качественно выполнять свою задачу. А всё потому, что они использовали бинарный формат для хранения своих данных: им нужен был какой-то жалкий один байт на каждого пассажира. Только в 747 внезапно влезало больше 255 человек, к чему программа была явно не готова. (:

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

а я напомню:

Или самая дорогая точка?

Иногда утверждается, что ошибка была вызвана тем, что при написании программы была поставлена точка вместо запятой. В языке ФОРТРАН, на котором была написана программа, выражение изменило свой смысл:

DO 17 I = 1, 10

было интерпретировано как

DO17I = 1.10

то есть как присвоение переменной DO17I — так как пробельные символы не учитываются языком.[10] Есть легенда (впрочем, неподтвержденная), что подобная ошибка была в одной из программ НАСА для вычисления орбиты, однако это программа использовалась в проекте Меркурий, а не Маринер, и эта ошибка была исправлена до запуска корабля.

http://ru.wikipedia.org/wiki/%D0%9C%D0%B0%...D%D0%B5%D1%80-1

[eddy]

Они, почему-то, все как на подбор в текстовом формате, а не бинарном

Что тут удивляться? Эти файлы редактируют руками, вот они и в текстовом формате!

[SLEDopit]

передёргиваете.

Отнюдь. У вас просто явно двойные стандарты. Я совершенно не понимаю, в чём разница между ядром и django'й в данном вопросе. Да и аргументы ваши достаточно забавны:

1. ядро у всех есть

есть то оно может и у всех. но разбираются в нём менее 5% счастливых обладателей. и ещё процентов 10 от этих 5 могут что-то пофиксить или накостылять там. В django процент существенно выше, потому что эта штука изначально заточена под девелоперов. Домохозяйкам оно не нужно.

2. в ядре баги оперативно закрывают

Да просто моментально. Никто и глазом моргнуть не успел, как #12309 взяли и пофиксили (и вы точно уверены, что его пофиксили?) (:

3. И самое главное: сколько будет стоить взлом вашего бложика на джанго, который вы напейсали за полдня, и бложика Эдуарда на сишечке? Уверен, ваш поломает четвёртый пионер. А бложик Эдуарда может достичь высокой популярности, и всё равно туда никто не полезет. А кто полезет, то ломать ничего не станет.

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

зы. Да и целых 22 бага на cvedetails это же явно от того, что тысячи разработчиков со всего мира просто ленятся. Ещё и бэкдорят, наверняка. А вот в ведре хорошо ищут. Уже больше 1000 накопали. И, разумеется, один обычный разработчик в любом случае напишет продукт существенно превосходящий по качеству многолетний труд сообщества разработчиков.

число double читабельно? Какого ляда вы юзаете double???

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

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

Как связаны ошибка программиста и формат хранения данных?

[eddy]

Как связаны ошибка программиста и формат хранения данных?

Дык, в вашем примере было то же самое: тупая ошибка программиста.

[drBatty]

есть то оно может и у всех. но разбираются в нём менее 5% счастливых обладателей. и ещё процентов 10 от этих 5 могут что-то пофиксить или накостылять там. В django процент существенно выше, потому что эта штука изначально заточена под девелоперов. Домохозяйкам оно не нужно.

ядро ВСЕ обновляют. А вот джанго... Работает -- ладно. Ядро все подряд ковыряют, причём обычно -- за зарплату, вполне официально. Джанго ковыряют на коленке 3.5 гика. Остальные "девелоперы", тупо копируют и берут бабло за своё костыляние.

Не, ну будьте честными...

Да просто моментально. Никто и глазом моргнуть не успел, как #12309 взяли и пофиксили (и вы точно уверены, что его пофиксили?) (:

12309 это не баг. Это целый огромный fuckup архитектуры. Такое бывает. Бывает в любой сложной системе, просто в других системах делают вид, что всё хорошо, и заметают мусор под ковёр. У нас это исправили.

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

это верно. Я и не говорю, что способ Эдди простой. Вы разве этого ещё не поняли? Да, написать движок на сишке в разы более трудоёмкая(хотя и выполнимая) работа. Это вам не джанго костылять.

число double читабельно? Какого ляда вы юзаете double???

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

дык у вас в коде таки double, или string?

Как связаны ошибка программиста и формат хранения данных?

как связана ошибка программиста выбравшего внутренний формат unsigned char, с форматом хранения данных? Да точно также, как и любая другая ошибка, в т.ч. и запятая вместо точки, которую так просто пропустить в текстовом файле. Потому что в текстовом файле разницы между "." и "," нет никакой. Как и между "А" и "A", как и ещё Over9000 примеров. Да и вообще, надеяться на человеческий фактор как минимум глупо.