C/C++, Bash, Perl вот и все, что нужно для программированния в Линукс?

ANSI C достаточно для всего. Остальные языки - для упрощения решения конкретных задач программистами с конкретными личными предпочтениями =).

>ANSI C достаточно для всего. Остальные языки - для упрощения решения конкретных задач программистами с конкретными личными предпочтениями =).

Тогда может быть и не стоит обращать внимания на остальные языки, поддерживаемые Линукс? Нафиг они нужны - то??? Не, реально, пацаны, зачем надо знать Perl, если ту же задачу можно решить с помощью C/C++?

Давайте сделаем единый язык для нашей любимой ОС??? Или это утопия, и прелесть есть в каждом другом языке? Тогда почему другой любимый язык (программирования я имею в виду) не можеть внять в себя все те прелести, что есть в другом языке (программирования я имею в виду)???

палюбасику

>Администрируя Linux

Смотря на каком уровне. Мне кроме баша ничего не нужено. Нужен ли C++ для разработки - мнения у всех разные. Не обижайте тролликов, они хорошие

> Тогда может быть и не стоит обращать внимания на остальные языки, поддерживаемые Линукс? Нафиг они нужны - то??? Не, реально, пацаны, зачем надо знать Perl, если ту же задачу можно решить с помощью C/C++?

ты скакова сраёна? мобила есть? позвонить нада.

>Не, реально, пацаны, зачем надо знать Perl, если ту же задачу можно решить с помощью C/C++?

Начинать надо с того что любую задачу можно решить на асме.

> Любую задачу можно решить на

Ты уже неправ. Не все задачи можно решить.

На ассемблере можно написать что угодно, но жизнь коротка...(с)

Э-эээх, ну всё как обычно. Мнения разделились. И не совсем понятно на что.

>На ассемблере можно написать что угодно, но жизнь коротка...(с)

Может тогда в кодах писать программы.

К примеру как было в MS-DOS():

int 90h ----> CD 90

И так далее

> Может тогда в кодах писать программы.

Я за, когда-то так и делал, лабы в универе в машинных кодах писал, со стороны смотрелось несколько дико =)

> Администрируя Linux, а затем и разрабатывая ПО под эту ОС, мне кажется что большего и не надо.

Довольно много ПО для Линукса пишется на других языках.

Надо при старте иксов сразу загружать Squeak/Pharo и жить в них.

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

Во-первых, лисп и фортран. потому как Октава и Максима.
Во-вторых, питон.
В-третьих, sed и awk. Да, их может заменить perl. Так что при широком использовании perl'а можно обойтись и без них.

>К примеру как было в MS-DOS():
>int 90h
Это еще че за ботва?

Я бы таки добавил Python + SQL (если это можно назвать отдельным языком)

Си да перл, этого хватит.

линукс, да и вообще, юниксы, это прямое воплощение десятого правила Гринспуна
т.е. ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.
буквально - си как основной язык и всякие 'dsl' в виде юникс-утилит и скриптовых языков. Даже пародия на REPL есть - шелл.

Поэтому линукс, и вообще, юниксы, надо выкинуть и заменить лисп-системами :)

ну а пока они, к несчастью, существуют, просто писать на CL :)

>> Любую задачу можно решить на

Ты уже неправ. Не все задачи можно решить.

«Любая сложная проблема имеет простое и очевидное неправильное решение.» (ц)

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

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

Есть другие мнения.

это было твоё лучшее утверждение. жаль что ты на нём не остановился

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

Есть, bash не нужен уже хрен знает сколько лет, по крайней мере писать на нём не нужно и вредно.
Ну и конечно насчёт С++ можно поспорить, поскольку есть варианты для кого-то более интересные - CL например.

>Поэтому линукс, и вообще, юниксы, надо выкинуть и заменить лисп-системами :)

Экий ты толстый недоумок.

Ты смотри сам не лопни, деточка.

Но, на всякий случай, предлагаю тебе привести 10 аргументов на тему почему си и ляликс нужны, а лисп-системы - нет, не считая того, что первое уже есть :)

Но, на всякий случай, предлагаю тебе привести 10 аргументов на тему почему си и ляликс нужны, а лисп-системы - нет

Не 10, но тем не менее осваивать а потом разбираться во всех этих скобочках этого вашего лиспа это то еще извращенство. Программирование должно приносить удовольствие и удовлетворение, а ваши лиспы ни того ни другого предоставить не могут (разве что только в особо извращенной форме). А если учесть еще снижение скорости выполнения по сравнению с C/C++, то становится очевидным, что все эти лиспы да и функциональщина вообще нужны только профессорам для диссертаций или таким вот гикам-извращенцам как ты или CL-USER.

>Не 10, но тем не менее осваивать а потом разбираться во всех этих скобочках этого вашего лиспа это то еще извращенство. Программирование должно приносить удовольствие и удовлетворение, а ваши лиспы ни того ни другого предоставить не могут (разве что только в особо извращенной форме). А если учесть еще снижение скорости выполнения по сравнению с C/C++, то становится очевидным, что все эти лиспы да и функциональщина вообще нужны только профессорам для диссертаций или таким вот гикам-извращенцам как ты или CL-USER.

Это такой толстый троллинг или человек и вправду серьезно про «удовольствие и удовлетворение» на с++?

Таки не C++, а жаба или пайтон с руби.

Тем не менее, из лиспа ты только скобочки и уяснил для себя?

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

Блин, просто ну не любишь лисп, твое дело.

Есть немного…

Но то, что это рельно гибкий и мощный язык до которого многим далеко, должно быть очевидно.

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

10 аргументов на тему почему си...нужны

ну, RTOS на CL - это было бы круто

лисп-системы - нет

хотя лисп-системы тоже нужны, кто ж спорит

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

>Программирование должно приносить удовольствие и удовлетворение, а ваши лиспы ни того ни другого предоставить не могут
Странно. Вот вступительная фраза в PCL:
"If you think the greatest pleasure in programming comes from getting a lot done with code that simply and clearly expresses your intention, then programming in Common Lisp is likely to be about the most fun you can have with a computer. You'll get more done, faster, using it than you would using pretty much any other language."
И она, в той или иной форме, подтверждена множеством, в том числе, очень известных программистов. Врут, наверное?

>А если учесть еще снижение скорости выполнения по сравнению с C/C++
Снижение скорости выполнения программы(а оно, при современных оптимизирующих компиляторах CL, незначительное, особенно если писать в том же сишном стиле) пусть даже в 3 раза стоит повышения скорости написания и отладки этой программы на порядки. Макросы, к тому же, позволяют снизить издержки производительности при повышении абстракции, а вот в случае с сями - практически все известные мне крупные программы - тормозное и глючное говно.

>лиспы да и функциональщина
Лиспы это не функциональщина. Особенно CL. Это мультипарадигмальный язык с лучшими в природе подсистемами ООП и метапрограммирования.
И, опять же, success stories, в отличии от функциональщины, множество, в самых разных областях. Да и вендоры коммерческих реализаций CL не стали бы требовать за них по 2000 USD просто так, да?

>Точно такими же мощьными языками являются и жаба с пайтоном,
Нет.

> Да и вендоры коммерческих реализаций CL не стали бы требовать за них по 2000 USD просто так, да?

а в этих реализацих тоже невозможна 32-разрядная битовая арифметика?

Ruby говорят это более логичный Perl, но я не проверял

в перле мне не хватает оператора >> чтоб можно было «asdf» >> «/path/to/file/»

>> Да и вендоры коммерческих реализаций CL не стали бы требовать за них по 2000 USD просто так, да?

а в этих реализацих тоже невозможна 32-разрядная битовая арифметика?

ash, logand, logior & logxor.

> ash, logand, logior & logxor.

Love5an пробуя портировать мой бенчмарк для исключений под лисп плакался насчет тормозов ash и таки убедил меня написать специальную тормозную 28-битную версию, дабы компенсировать отставание лиспа и замерить не его, а скорость исключений: http://www.linux.org.ru/jump-message.jsp?msgid=4254952&cid=4259751

вот меня и заинтересовало, в 2000-баксовых лиспах тоже все так плохо?

врапа fixnum при переполнении нет нигде кроме как при (optimize (speed 3) (safety 0) (debug 0)), и то и это мало где.

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

Почему это все плохо - непонятно.

Не надо 28битной версии, лучше напиши что-нибудь вменяемое для сравнения разных языков, а не только сей и плюсов на x86, т.е. не полагаясь на размеры и семанитку сишного uint(ну, до разумных пределов) и хреноту с двиганием битов.

я свой тест, простой и понятный, и работающий, предложил, но, правда, почему он "неправильный" ты по-нормальному так и не объяснил.

>врапа fixnum при переполнении
и на это, естественно, нельзя полагаться, потому что это баг, и потому что нельзя гарантировать, что оно себя поведет как int в сишке при переполнении

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

> я свой тест, простой и понятный, и работающий, предложил, но, правда, почему он «неправильный» ты по-нормальному так и не объяснил.

В яве моя прога при 0% кидаемых исключений может выполнится за (допустим) 1 с, при 100% за 2 с, а при 50% — за 9 с. Поэтому то что ты меришь — якобы «скорость исключений» — не существует и ее можно смело засунуть в жопу. Достало объяснять.

> и на это, естественно, нельзя полагаться, потому что это баг, и потому что нельзя гарантировать, что оно себя поведет как int в сишке при переполнении

значит и 2000-баксовые лиспы не дает *прямого* доступа к ассемблерной команде shl? жаль.

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

могу сделать ее локальной и передавать в f на нее указатель, устроит?

ну, лучше в структуру запихуть перед тем как передавать по указателю, хотя пофиг

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

Это другой вопрос, но с ассемблерными вставками в лиспе сложно. Не потому, что их нет, есть иногда, потому что лисп это высокоуровневый язык, который очень сложно на ассемблер, особо x86, отмапить. Calling conventions другие могут быть, внутреннюю структуру объектов надо знать, как из объектов вычленять данные, и т.п.

> ну, лучше в структуру запихуть перед тем как передавать по указателю, хотя пофиг

там вообще-то требуется быстрый датчик случайных чисел, чтобы 0 и не-0 давались с заданными вероятностями 1/2^n и 1-1/2^n, и чтобы его состояние сохранялось через вызовы

в с/с++ это делается через глобальные переменные, как это сделать в лиспе?

>В яве моя прога при 0% кидаемых исключений может выполнится за (допустим) 1 с, при 100% за 2 с, а при 50% — за 9 с.
100% и 50% может, местами поменять?
Нихрена не понял.
Если поменять - дык это везде же так, сигнализация исключения и раскрутка стека они ж жрут ресурсы, ёмоё. Вот сколько они жрут, я и мерил в том тесте. И получается, в лиспе оно более lightweight, да.