тогда уж: perl -n -e somecode somefile. Ведь с данными надо, что-то сделать?! В питонах можно так:

python -c "import sys;[sys.stdout.write(' '.join(line.split(' '))) for line in sys.stdin]" < somefile

А у тебя объёма памяти хватает только для одного языка? Почему нельзя выбрать два и срвнить?

По теме вопроса: я рекомендую питон, потому что его знаю. О других языках ничего плохого сказать не могу.

Ведь с данными надо, что-то сделать?!

ты в том коде с ними тоже нифига не делаешь. просто открываешь файл, читаешь. а это равносильно perl -n file.

А ты освой таки кресты по-хорошему. Современный C++ очень много чего умеет, что раньше было разумнее на скриптоте писать.

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

По природе я очень нетерпелив

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

Проверенный факт: те, кто употребляет в подобном контексте фразочки со словом «начальство» - неудовлетворенные зануды и вообще отстойные.

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

Или можно взять перл/пайтон/раби.

Ты прав, храбрый анонимус в белом.

{-# LANGUAGE OverloadedStrings #-}

import Control.Monad
import Data.Conduit
import qualified Data.Conduit.Binary as C
import qualified Data.Conduit.List as C
import qualified Data.Conduit.Text as CT
import qualified Data.Text as T
import qualified Data.Text.ICU as ICU
import System.Environment
import System.IO

main :: IO ()
main = do
  args <- getArgs
  if null args
    then return ()
    else do
      let re = ICU.regex [ICU.UnicodeWord] (T.pack $ head args)
      C.sourceHandle stdin
        $= CT.decode CT.utf8 
        $= CT.lines
        $= C.map (grepLine re)
        $= C.filter (/= Nothing)
        $= C.map (\(Just match) -> T.append match "\n") 
        $= CT.encode CT.utf8
        $$ C.sinkHandle stdout

grepLine re line = ICU.find re line >>= ICU.group 0 

Лепи веб-интерфейс к своим наколенным творениям. ПЫХ-ПЫХ в помощь.

Не совсем, примитивная работа со строками (split/join) там есть. Да и целью было - показать, что не все запускается через python script.py :)

Из которых 1000 давным-давно заброшена, а 90 из оставшихся 100 несовместимы с твоим любимым $lispimplementation. Плавали, знаем.

1. Они все совместимы с sbcl и запускаются как минимум на машине автора quicklisp'а.

2. Заброшена — не значит, что не работает. В TeX когда последний раз изменения вносились? Он тоже заброшен?

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

Tcl

лаконичности

K

jq

Взято из книги «Seven languages in seven weeks»

Цитатка ниочём, но, впрочем, она ничем не противоречит тому, что я сказал, вот кроме

Heavy I/O and scripting do not lend themselves to functional languages.

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

Конечно же хаскелл

https://www.fpcomplete.com/school/starting-with-haskell/libraries-and-framewo...

но до лаконичности perl'а им далековато

Уже обхоливорили; перл получился короче питона только на экстремально коротких(=> неинтересных) программах.

Очередной тред, в котором каждый нахваливает своё болото. Бери питон и не парься.

2. Заброшена — не значит, что не работает. В TeX когда последний раз изменения вносились? Он тоже заброшен?

Ты про исходный код или про инфраструктуру? texlive ежегодно обновляется.

Ты про исходный код или про инфраструктуру? texlive ежегодно обновляется.

quicklisp почти еженедельно

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

python + tkinter

Хорошо, что ты пошел своим путем.

Есть ли какой-либо удобный язык, которым можно перемалывать гигабайты логов, время от времени рисовать GUI к перемалывалке логов, который бы был лаконичным, эффективным и вот с такенными здоровыми аккумуляторами?

быстрее gawk? Чудес не бывает. Перловка будет работать точно также, а какой-нить питон тебя совсем опечалит.

Советую плюсы. Многопоточность из коробки, регексов в рабочем состоянии из коробки нет, но есть в кутях, бусте и ещё куча других вариантов. «Батарейки» для данной задачи не нужны, будут только мешать: если язык «батареечный», то либо за его плечами стоит крупная корпорация, либо все стандартные либы оптимизированы через задницу. Поэтому, в вашем случае лучше не язык выбирать, а тупо самую быструю регеспную либу под плюсы (кстати, на регексах мир клином не сошёлся, есть и другие варианты для синтаксического анализа).

Tcl/Tk, но синтаксис непривычный.

Например имена файлов на одном разделе в одной ОС и другой - это как разные строки видятся, неужели python 3.x решает эту проблему?

это проблема «другой ОС».

да и батареек мало.

Да даже на обычной коробке, стоящей под столом, awk со свистом всему вокруг просрёт.

возьми, и попробуй.

Например?

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

это ты так стебёшься, да?

Советую плюсы.

регексов в рабочем состоянии из коробки нет

есть в glibc, вполне рабочее.

самую быструю регеспную либу под плюсы

наверное в glibc и есть «самая быстрая».

mechanize, работа с irda, gsm, gps, единый репозиторий. Tcllib - хорошая попытка, дай бог жизни этому проекту и энтузиастов. Маловато правда модулей, но мэйнтейнер молодец. Очень красивый и документированный код пишет/собирает.

это проблема «другой ОС»

«нет, на этот раз нас»... в общем, если почти всё кроссплатформенно, то это «почти» оборачивается гемором

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

Перловка будет работать точно также

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

Вероятно, что просто никто не использует Tcl для работы с этим, всё-таки далеко не самый быстрый и компактный язык.

компактный язык

Это ты про что? Код на тикле если не самый компактный, то один из, ибо почти нет синтаксиса, все заточено под мету. Tcl — это то, чем должен был бы стать лисп, если бы туда не засунул свои грязные рученки энтерпрайз.

Tcl — это то, чем должен был бы стать лисп, если бы

... одной из целей лиспа не была скорость выполнения.

Постоянная трансляция из текста и обратно делают Tcl очень тормозным. Хотя, как замена sh/csh был бы почти идеален.

одной из целей лиспа не была скорость выполнения

так оно и есть. Изначально не была.

Постоянная трансляция из текста и обратно делают Tcl очень тормозным

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

Tcl - это высокоуровневый язык.

Высокоуровневый язык не обязан быть тормозным: C++, Haskell, Lisp, Java, Racket.

Он служит всего лишь клеем

Так я и говорю: (почти) идеальная замена для sh/csh.

есть в glibc, вполне рабочее.

Справедливости ради, починили регекспы, вроде, только с версии 4.9.

Изначально не была.

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

возьми, и попробуй.

Постоянно беру и пробую. Часто плюю, на перле, лиспе или си пишу.

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

Хочу заметить что shell был разработан немногим позже. И явно не имеет скорость выполнения в приоритетах.

Вообще идея, что «Tcl - высокоуровневый язык» настолько же странна, как «Bash - высокоуровневый язык». Ещё пятнадцать лет назад деление на языки для написания скриптов и языки программирвоания было достаточно чётким. Первым «ни то ни сё», насколько я помню, был питон. Разработанный как скриптовый язык, он оброс метаклассами, модулями, декораторами и стал претендовать на нишу языка программирования (по крайней мере синтаксически). Оставалась проблема производительности, но на неё забили под девизом «компьютеры нынче дешёвые, а программисты дорогие». Также был пример PHP, где синтаксически скриптовый язык поневоле использовали как язык программирования. Так теперь Javascript, Tcl и Perl (особенно Perl 6) считаются вполне нормальными языками программирования.

Все эти деления на скриптовые и не скриптовые неадекватны, отсюда и непонятки. Исторически так сложилось, это ошибка. На самом деле, проще всего было бы разделять языки на компилируемые и интерпретируемые. Чем больше крен в сторону статики и компиляции, тем более низкий уровень. Все остальное — искуственные усложнения и запутывания (возможно, отчасти, сознательные, из маркетинговых соображений). В общем случае, да, быстрый высокоуровневый язык — это оксюморон. Но тут еще подмешивается кривизна реализации конкретных ЯП, поэтому, скорость, не слишком надежный критерий. Но в ощем случае, это так, чудес на свете не бывает.

Редкостный бред. Нет никаких «компилируемых» и «интерпретируемых» языков.

Это условно. Я не случайно написал, «крен в сторону того или этого». Чисто интерпретируемых языков сегодня, наверное, не существует.

Чем больше крен в сторону статики и компиляции, тем более низкий уровень.

Haskell, Ocaml, Scala, C# - низкоуровневые языки, окей.

Да ещё и с санк-ликом размером с аварию в Персидском заливе.

Решил подискутировать с anonimous?