А у тебя такие комментарии - в духе «asm, perl и lisp одинаково подходят для непрограммистов». Чтобы не увильнул, цитирую твой комментарий:

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

это можно сделать на любом тьюринг-полном ЯП. Хоть на brainfuck'е

вот это хорошо, что ты процитировал. Ибо очевидно, что я не говорил ничего подобного «asm, perl и lisp одинаково подходят для непрограммистов».

ИМХО для НЕпрограммистов хорошо подойдёт логичный в своей сути и логичный в реализации ЯП, пусть он будет даже далёким от железа. Например LISP годен. Или даже пайтон. Но никак не perl - его закорючки будут всё равно непонятны без знания теории программирования и без знания железа, лет 15..20 назад это был годный и быстрый интерпретатор, для написания одно-двух строчных «программ» администраторами. Ну ладно, может и 100 строчных. Максимум. Но это было давно, того же пайтона не существовало. И всяких пхп тоже. А сейчас они есть, и позволяют НЕ программисту просто взять, и уеб^Wнаписать. И не просто непрограммисту, а человеку, который программистом стать никогда не планирует.

Потому перловка для этого НЕ годна. Хотя на ней и можно писать всё что угодно. Как на BF или sed.

Чтоб код на питоне/перле заработал, нужно этот питон/перл поставить, не?

если ты маздайщик - это твоя проблема. Если слакварщик - проблема Патрега. Решённая.

ЗЫЖ если у тебя болгенос, то пинай Дениса, пусть думает. Это не твоя проблема.

вот это хорошо, что ты процитировал. Ибо очевидно, что я не говорил ничего подобного «asm, perl и lisp одинаково подходят для непрограммистов».

Теперь тебе очевидно, но именно это ты и сказал в цитируемом комментарии.

ИМХО для НЕпрограммистов хорошо подойдёт логичный в своей сути и логичный в реализации ЯП, пусть он будет даже далёким от железа. Например LISP годен. Или даже пайтон.

Вот именно что высокоуровневый язык, а не «любой тьюринг-полный ЯП», как ты ляпнул

Но никак не perl - его закорючки будут всё равно непонятны без знания теории программирования и без знания железа, лет 15..20 назад это был годный и быстрый интерпретатор, для написания одно-двух строчных «программ» администраторами.

Тут можно было бы поспорить, но после того как ты отказываешься от своих слов - это было бы бессмысленно.

cpan Plack plackup -MPlack::App::Directory -e 'Plack::App::Directory->new(root => '.')'

Кстати, множество перловых программистов предпочитает копипастить регулярки. Убить мало за такое.

Зачем рассуждать о том в чем мало понимаешь ?
Почитайте, как работают перловые рег. выражения, - они компилируются один раз при запуске программы, кроме случая когда в теле regexp используются переменные.

-O3? Ну, я не сильно ошибся. Я, правда, по привычке -O2 ставлю, т.к. для С эта опция даёт вполне достаточный уровень оптимизации, а -O3 иногда даёт несколько больший по размеру код (хотя и позволяет некоторые вещи лучше обработать). И, по-моему, -O3 это в большей степени для С++ подходит. Впрочем, возможно это дело привычки.

ну если мне не надо -O3, то у меня есть bash (:

А размер кода меня очень мало волнует...

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

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

В этом случае крайне заманчивый вариант с массивами фикс. длины лучше не использовать — не экономично может получиться.

ну можно попробовать что-то вроде «исключения», 99% обрабатываются на обычном массиве, только надо одну проверку ввести на размер - если вылазит, то в другую функцию, которую оптимизировать особо не надо, пусть там в куче выделяет сколько надо. Если что, есть макрос REALLOC, пусть долго, но это особый редкий случай.

Зарезервировать такой кусок памяти «навсегда» можно, но есть риск увалить систему.

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

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

а что ты хотел от языка для хомпаг?

в пыхе она, кстати, нифига не мощна и больше похожа на свалку, в общем пространстве имён-то

аки ваш CPAN. Только дублей почти нет и говнокод вычищается.

Вот только не надо делать вид, что ты не понял разницы между классом SimpleHTTPServer

и? http://search.cpan.org/search?mode=all&query=http server Results 1 - 10 of 1544 Found выбирай на вкус модуль, и будет у тебя http server на перловке. В чём проблема-то?

Для поднятия сервака достаточно двух бинарников - линухового ведра и python-static - и одного скрипта на питоне.

я к тому, что для поднятия сервака необходимо и достаточно сервака. Зачем тут пайтон?

И да, мне попадались хостинги(платные ессно), где сервак есть (и не sample, а нормальный), перловка есть, а вот пайтона нет, и не будет. Ибо админы тамошние против. Ибо не Ъ. Я, по наивности, спросил: Когда будет? Ответ был прост и краток: Никогда.

а можно вариант того же на перле или другом ЯП? Тогда всем станет ясно, какое-же говно пайтон.

Пример был приведен как ответ на ваши

У быдлокодера только два варианта, что-бы написать программу на пайтоне

Причем тут переписывание на другом ЯП? Python не панацея от быдло кода. Надеюсь так будет понятнее.

Вот именно что высокоуровневый язык, а не «любой тьюринг-полный ЯП», как ты ляпнул

я сказал «можно сделать». Если ты не знал, то «можно» в посте drBatty значит, что можно drBatty, а не любой обезьяне, которая Кнута читать не хочет. А вот обезьяне наверное нельзя. Для неё PHP придумали. И прочие «высокоуровневые».

Что угодно на BF? Ну-ка покажи-ка сохранение текстового файла на диск на BF (или pbrain хотя бы). Очень хочется на это посмотреть.

У меня как раз проблемы с питоном нет. Просто некоторые начали троллить, что в их поставке нет питона. Давайте уж тогда всё на JS писать. Стопроцентный десктопный рантайм де-факто.

Python не панацея от быдло кода. Надеюсь так будет понятнее.

панацея от быдлокода только одна, и это не пайтон, а эфтаназия быдлокодеров. Всегда ваш, К.О.

Однако быдлокодить на пайтоне таки сложнее, потому это хоть и не панацея, но лекарство. С побочными эффектами естественно.

и? http://search.cpan.org/search?mode=all&query=http server Results 1 - 10 of 1544 Found выбирай на вкус модуль, и будет у тебя http server на перловке. В чём проблема-то?

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

И да, мне попадались хостинги(платные ессно), где сервак есть (и не sample, а нормальный), перловка есть, а вот пайтона нет, и не будет. Ибо админы тамошние против. Ибо не Ъ. Я, по наивности, спросил: Когда будет? Ответ был прост и краток: Никогда.

Ну, ССЗБ.

Что угодно на BF? Ну-ка покажи-ка сохранение текстового файла на диск на BF (или pbrain хотя бы). Очень хочется на это посмотреть.

в BF есть операция «точка», которая выводит символ в файл. Да, в stdio. Ну и что, в C/C++ даже это отсутствует, и ничего, пользуемся как-то...

В Си есть линковка с функциями, позволяющими взаимодействовать с ядром и сохранять таки в файл, а не в stdio. И ещё имя этому файлу задавать. А брейнфак - сферический конь в вакууме, там даже закорючки для вызова системного прерывания нету. Вывод - неюзабельно даже как байткод.

У меня как раз проблемы с питоном нет. Просто некоторые начали троллить, что в их поставке нет питона

ну этот вопрос не суда, а к их маинтейнерам, которые питон не осилили.

Давайте уж тогда всё на JS писать. Стопроцентный десктопный рантайм де-факто.

100% будет только если ты опрос с JS напишешь...

Т.е. просто не будешь учитывать тех, у кого этот JS не работает (а такие есть даже на десктопе).

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

это везде так. Но в перловке есть огромная CPAN помойка, а вот с другими ЯП ещё хуже. В сишечке например такой помойки нет... Про пайтон вообще промолчу - жалкие 6 метров кода это смешно...

Т.е. просто не будешь учитывать тех, у кого этот JS не работает (а такие есть даже на десктопе).

elinks/dillo/netsurf/параноики?

я сказал «можно сделать». Если ты не знал, то «можно» в посте drBatty значит, что можно drBatty, а не любой обезьяне, которая Кнута читать не хочет. А вот обезьяне наверное нельзя. Для неё PHP придумали. И прочие «высокоуровневые».

Т.е. теперь ты хочешь сказать, что сделал пустой комментарий с целью почесать ЧСВ?

и где тут в треде была продемонстрирована потоковая обработка?

У нас есть код:

print sort {$a cmp $b} grep {$i++%2 or /\d/o} split //, "He1lo, p3r1-H4X0R !1!"'

Работает это так: 1) split порождает поток элементов в соответствии с заданным правилом (// - в данном случае) 2) grep - фильтрует поток элементов в соответствии с заданным правилом 3) sort - сортирует отфильтрованный поток в соответствии с заданным правилом 4) print - выводит полученную последовательность в выходной поток

Красивая концепция.

А у вас каша. "".join - вообще костыль.

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

Perl-таки круче. Не код - а песня. Perl позволил красиво решить задачу на должном уровне не вваливаясь ни на уровень объекта, ни в на уровень итератора, ни в контекст вывова метода объекта. А теперь представьте, в какие семантические уровни вы будете бегать чтобы реализовать управляющую структуру в вашей питоньей поделке, если мы вдруг начнем изменять/усложнять правила управления потоком?

PS: "".join - вообще костыль (но пипл хавает еще и не такое).

Лол, 6 мег - стандартная библиотека. PyPi и другие репозитории никто не отменял.

В Си есть линковка с функциями

чего-чего? при чём тут линкер-то? Ну напиши линковщик для BF, будет ldbf.

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

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

elinks/dillo/netsurf/параноики?

да. +100500 ламеров, которые боятся, что их «взломают».

я вполне ясно выразил своё мнение. Ты не согласен, или что-то непонятно?

Работает это так: 1) split порождает поток элементов в соответствии с заданным правилом (// - в данном случае) 2) grep - фильтрует поток элементов в соответствии с заданным правилом 3) sort - сортирует отфильтрованный поток в соответствии с заданным правилом 4) print - выводит полученную последовательность в выходной поток

Perl-таки круче. Не код - а песня.

а баш тогда - симфония

Лол, 6 мег - стандартная библиотека. PyPi и другие репозитории никто не отменял.

это всё равно ничто по сравнению с CPAN.

«весь веб пишется на той же яве или на технологиях Микрософт.» Это Вы чушь пишите полную. Идите посмотрите как устроены крупнейшие мировые проекты. ни явой и мелкософтом там и не пахнет. за редким исключением... Ebay, например, ну так он и режет данные, сейчас поиск обрезали - видимо не справляются.

А как делают внутрикорпоративные проектики - так ту равнятся нечему, как правило, делают малоквалицированные кадры - на чем умеют на том и делают или заказывают как попало и где попало. В РФ тоже самое - пилят на чем попало из чего попало - и работает это так же. Стоит зайти на какой-нибудь сайт или он валится от десяти человек одновременно либо ошибками сыпет. Это хорошим результатом назвать нельзя. Про дырки тоже...

«у нас ИТ индустрия соотвествует западной середины 90 годов.»

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

Теперь, когда ты уточнил, что это было не возражение, а почёсывание ЧСВ, возражать как бы не с чем ;) Чеши на здоровье. А на будущее - постарайся более ясно формулировать свои мысли.

Не делай вид, что ты ничего не понял. В bf нет ни одного средства для вызова подпрограмм, находящихся за пределами виртуальной машины bf. Механизм прерываний - один из способов вызова системных подпрограмм. Для bf есть линкеры и даже компиляторы (sic), но всё взаимодействие с внешним миром сводится к несчастному stdio. Как же записать файл с заданным именем лишь посредством BF? А никак, поэтому этот язык полноценен лишь в теории.

а баш тогда - симфония

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

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

Забыл сказать что одним из важных и удобных свойств Perl является возможность встраивания в конвеерную обработку (это лишь примитивный пример чтобы показать одну из базовых схем использования):

cat /etc/group | perl -ne'print reverse split //;' | perl -ne'print sort split //;'

PS: А если учитывать что на CPAN модулей over 100_000 ...

Помним. Скорбим.

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

Более того, даже для стартовых/управляющих скриптов он не слишком подходит - именно поэтому в systemd от них было решено отказаться.

Хэх! ...

... Так на грабли наступить можно. Но у меня от этого есть свой «рецепт» — внимание, подкреплённое ctags. :D

malloc() не сломался. Просто VLA позволяют немного экономить на вызовах. Ну и да, выделение памяти происходит в стеке. Например (взято из http://en.wikipedia.org/wiki/Variable-length_array):

float read_and_process(int n)
{
    float vals[n];
 
    for (int i = 0; i < n; i++)
        vals[i] = read_val();
    return process(vals, n);
}

Как только заканчивается read_and_process(), жизнь массива vals[n] так же прекращается.

Про alloca тут всё немного проще. Чтобы софтина не выпадала из реальности в кору, можно например в рантайме сделать что-то навроде:

#include <sys/resource.h>
    /* С чего всё начиналось. */
    const rlim_t kStackSize = 64L * 1024L * 1024L;   /* Делаем размер стека в 64Mb. */
    struct rlimit rl;
    int rc;

    rc = getrlimit(RLIMIT_STACK, &rl);
    if (rc == 0) {
        if (rl.rlim_cur < kStackSize) {
            rl.rlim_cur = kStackSize;
            rc = setrlimit(RLIMIT_STACK, &rl);
            if (rc != 0) {
                fprintf(stderr, "Облом. setrlimit() вернула = %d\n", rс);
            }
        }
    }
    /* Погнали дальше. */

Возможно, это и «грязный хак», но иной раз так делать приходится (конечно пример чисто _тестовый_, не стоит так в продакшоне делать — по 64Mb это сильно круто). И вообще, _ДО_ таких действий надо бы проверить — может дефолтного значения хватит за глаза. У пары malloc()/free() есть неоспоримое преимущество — как правило, ими пользоваться умеют (если только не забывают). У alloca — преимущество типа «выстрелил и забыл», но по сравнению с malloc() операции по выделению памяти производятся быстрее (хотя, надо заметить что это может зависеть от архитектуры).

Ну и да, действительно, мне приходится работать и с embedded и не с embedded, отсюда и несколько «специфичные» подходы к работе с памятью в том числе. Я не всегда знаю на какой именно архитектуре всё это будет работать, сколько там памяти, etc. Хотя, в принципе, по барабану. Многие параметры выясняются в рантайме, при старте. А так-то бывает и к ядру процессора поток приходится иной раз гвоздиками прибивать аккуратно (например при помощи pthread_get(set)affinity_np()). Главное чтобы оптимизатор (в том числе) код подтесал при сборке, а там уже по месту разберёмся.

Нет. Не так...

... Всё множество функций в С (в Linux) по работе с файлами это обёртки разной степени «высокоуровневости» над одним сисколлом — write().

Можете сделать так, подставив вместо STDOUT_FILENO любой fd, предварительно открытый через open()/fopen() и получите то же самое:

#include <unistd.h>
/* ... */
const char msg[] = "Message!";
write(STDOUT_FILENO, msg, sizeof( msg ) - 1);

«Прирост в скорости» в случае с функциями буфиризированного ввода/вывода типа fprintf()/fwrite() по сравнению с write() может быть достигнут только за счёт того, что write() буфирезирует вывод на уровне ядра, а эти ф-ии ещё и на уровне пользовательского процесса (в начале), а потом кучей кидают вывод в write(). Кажется что работает быстрее.

Наличие http-server'a в базовой поставке языка программирования - это минус, имхо. Если мне нужен будет http-сервер, я либо напишу его, либо возьму нужный модуль из cpan. Ты ещё скажи, что 99% языков отстой, потому что в базовой библиотеке у них нет не относящегося к ЯП функционала.

Не делай вид, что ты ничего не понял. В bf нет ни одного средства для вызова подпрограмм, находящихся за пределами виртуальной машины bf.

точка и запятая - достаточные операторы для вызова внешних подпрограмм. Например несложно передать сначала номер устройства, потом число символов, а потом сами символы. Для ввода вывода можно использовать также и любой кусок памяти, записывая/считывая туда необходимые данные. Что тут странного? У многих CPU вообще не было команд ввода/вывода, и брат до сих пор жив.

Механизм прерываний - один из способов вызова системных подпрограмм.

дался тебе этот механизм прерываний! что в нём особенного-то?

Для bf есть линкеры и даже компиляторы (sic), но всё взаимодействие с внешним миром сводится к несчастному stdio.

что sicаешь? компилятор на bf это тривиально. Написать программу на bf намного сложнее. А stdio просто потому, что IRL этот BF никому не нужен. Ибо код задалбывает писать, и если один раз написал, то уже не исправить - не разобраться.

Как же записать файл с заданным именем лишь посредством BF?

посредством продвинутого stdio очевидно!

А никак, поэтому этот язык полноценен лишь в теории.

он на практике неполноценен только потому, что у него слишком примитивный синтаксис. Написать можно что угодно, только писать ОЧЕНЬ ДОЛГО. А разбираться - вообще невозможно. Потому writeonly. Но на самом деле, никакой магии там нет. И ввод/вывод - это мелочь в BF.

Более того, даже для стартовых/управляющих скриптов он не слишком подходит - именно поэтому в systemd от них было решено отказаться.

ты, кстати, так и слил, когда я спросил, и чем-же тебе bash не подходит?

Тогда выбор непрограммистов Borland C++ Builder. Там вообще не нужны закорючки. Достаточно иметь мышь и один палец. А Perl язык очень простой. Просто некоторые не понимают, что чтобы начать его использовать не обязательно весь его знать.

Любой «продвинутый stdio» уже требует изменений в спецификацию bf, ибо надо различать, когда надо выводить на консоль, а когда в файл. Большего, кстати, и не требуется, ибо в Unix всё - файл. Но канонческий bf и этого не умеет.

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

Достаточные, но. Куда передать? В функцию? Как её вызвать, эту функцию? Только ещё одной закорючкой, уже не соответствующей каноническому bf.

Для ввода вывода можно использовать также и любой кусок памяти, записывая/считывая туда необходимые данные.

В bf уже появились обращения к системной памяти за пределами 30K виртуальной машины?

Например (взято из http://en.wikipedia.org/wiki/Variable-length_array):

и чем это отличается от alloca(3)? Тем, что многие компиляторы не осилят?

Возможно, это и «грязный хак», но иной раз так делать приходится (конечно пример чисто _тестовый_, не стоит так в продакшоне делать — по 64Mb это сильно круто). И вообще, _ДО_ таких действий надо бы проверить — может дефолтного значения хватит за глаза.

можно просто научится считать.

У пары malloc()/free() есть неоспоримое преимущество — как правило, ими пользоваться умеют (если только не забывают). У alloca — преимущество типа «выстрелил и забыл»

ну-ну...

int f()
{
    int *x = alloca(123*sizeof(int));
    return x;// выстрелил и забыл. про свои яйца, оставшиеся в стековом фрейме.
}// лифт с нами и с функцией уехал куда-то, а яйца остались.

Да, но начнем с того, что в bf нет сисколлов. Даже open. Есть putc и getc, а на них далеко не уедешь.

Наличие http-server'a в базовой поставке языка программирования - это минус, имхо. Если мне нужен будет http-сервер, я либо напишу его, либо возьму нужный модуль из cpan.

там простой пример на самом деле. Что-бы свой навелосипедить быстренько. Это как xmessage(1) или там xclock(1) - программы, написанные программистами для программистов.

он на практике неполноценен только потому, что у него слишком примитивный синтаксис. Написать можно что угодно, только писать ОЧЕНЬ ДОЛГО. А разбираться - вообще невозможно. Потому writeonly.

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

Тогда выбор непрограммистов Borland C++ Builder. Там вообще не нужны закорючки. Достаточно иметь мышь и один палец.

попробуй QT Designer, тебе понравится.

А Perl язык очень простой. Просто некоторые не понимают, что чтобы начать его использовать не обязательно весь его знать.

простой, но очень далёкий от совершенства. Годный лишь для написания непонятных одностроков, нубов пугать...

Любой «продвинутый stdio» уже требует изменений в спецификацию bf, ибо надо различать, когда надо выводить на консоль, а когда в файл. Большего, кстати, и не требуется, ибо в Unix всё - файл. Но канонческий bf и этого не умеет.

в «спецификации bf» нет никакого stdio. Не туда смотришь. Там есть просто «вывод в файл», в какой - не сказано. Stdout просто для удобства подцепили.

Достаточные, но. Куда передать? В функцию? Как её вызвать, эту функцию? Только ещё одной закорючкой, уже не соответствующей каноническому bf.

у тебя есть продвинутая команда условного перехода while. Этого достаточно для организации _любого_ алгоритма. В т.ч. и подпрограммы. В т.ч. и в системе (память в bf бесконечное, место для твоих гигов найдётся).

В bf уже появились обращения к системной памяти за пределами 30K виртуальной машины?

а бесконечность теперь меньше 30К? Или ты путаешь чью-то реализацию с ЯП?

файл создаётся, другое дело, что на HDD он естественно не записывается.

создаётся структура в памяти с идентификатором. У тебя есть другие предложения как это сделать? Причём, не просто «а я ненавижу пайпы и иноды», а настоящее предложение которое _хотя бы_ опишет недостатки текущей реализации.

Я бы и дальше спорил, но у тебя Слака на аватаре поэтому снисходительно промолчу :)