LINUX.ORG.RU

Какими ЯП вы пользуетесь?

 ,


5

6

Сабж. Интересно, какой язык программирования наиболее популярен среди обитателей LOR.

  1. Python 642 (44%)

    ********************************************************************************************************************************************************************************************************************************************************************************************************************************

  2. C 621 (42%)

    *********************************************************************************************************************************************************************************************************************************************************************************************************************

  3. C++ 605 (41%)

    *************************************************************************************************************************************************************************************************************************************************************************************************************

  4. JavaScript 433 (30%)

    ***********************************************************************************************************************************************************************************************************************

  5. Другой 402 (27%)

    ********************************************************************************************************************************************************************************************************

  6. Java 370 (25%)

    ****************************************************************************************************************************************************************************************

  7. PHP 324 (22%)

    *****************************************************************************************************************************************************************

  8. C# 141 (10%)

    **********************************************************************

  9. Ruby 127 (9%)

    ***************************************************************

  10. Lua 127 (9%)

    ***************************************************************

  11. Go 109 (7%)

    ******************************************************

  12. Lisp 94 (6%)

    **********************************************

  13. Haskell 73 (5%)

    ************************************

  14. Rust 51 (3%)

    *************************

  15. Erlang 47 (3%)

    ***********************

  16. Objective-C 45 (3%)

    **********************

  17. Vala 20 (1%)

    *********

  18. OCaml 20 (1%)

    *********

  19. Swift 18 (1%)

    ********

  20. Nim 13 (1%)

    ******

Всего голосов: 4282, всего проголосовавших: 1465

Deleted

Проверено: beastie ()
Последнее исправление: JB (всего исправлений: 1)

Bash, JS (учу), Python (пишу, но не знаю)

daniilArch ★★
()
Ответ на: комментарий от Zhbert

Эдик вроде как-то хвастался, что вообще все на сях делает.

Хорошо, что хоть не пишет приложения на qt под гном. Если вы понимаете о чём я.

shayger
()
Ответ на: комментарий от h578b1bde

Так точно, можешь опровергать.

Что ж, извольте.
Исходное: "shell - программа управления исполнением процессов ОС (в том числе и интерактивного). Её языковые возможности базируются на том, что процессы могут передавать своим потомкам окружение и аргументы командной строки, взаимодействовать друг с другом, передавая потоки данных через файлы и посылая сигналы, и получать код завершения потомков. Ну и плюс возможность делать довольно примитивные макроподстановки (включая сюда сравнительно недавно появившуюся целочисленную арифметику)."
Ваше: "Работать с аргументами, файлами, посылать сигналы и получать код завершения можно и в C. По твоей логике, C создан для управления исполнением процессов ОС (в том числе и интерактивного) и в данном опросе не нужен."
В исходном утверждении говорится о том, что язык shell спроектирован для управления исполнением процессов, и поэтому его синтаксис определяют набор операций для управления окружением, аргументами командной строки, файловым вводом/выводом, обработкой сигналов и кодов завершения процессов (то есть именно то, что нужно для управления процессами). А вовсе не то, что в shell можно «Работать с ...».
Ладно. Положим, что «По твоей логике» (это не моя логика, это вообще мало напоминает логику, но об этом ниже) «C создан для управления исполнением процессов ОС». Тогда не могли бы Вы привести примеры синтаксических конструкций языка С для:

  1. работы с аргументами;
  2. работы с файлами;
  3. посылки сигналов;
  4. получения кода завершения?

Касательно логики. Показываю на пальцах:
 — Самолёт предназначен для совершения полётов в атмосфере. Поэтому его конструкция обеспечивает разгон, набор высоты, снижение и приземление.
 — Ёжик, если его посильнее пнуть, разгоняется, набирает высоту, а затем снижается и приземляется. Ёжик - это самолёт.

По поводу того, что shell предназначен для управления исполнением процессов возражения есть?

Да. Если я с помощью sh, например, запишу в отдельный файл каждую вторую строчку из каждого текстового файла с вчерашними изменениями — это будет управление исполнением каких процессов?

Тут был бы вполне уместен пример кода.

В том же C даже этого нет.

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

Тогда о чём был твой первый комментарий в этом треде?

О том, что «shell, по большому счёту - не алгоритмический язык».

argv_0_
()

Не вижу Паскаля. Не Делфи, а именно Паскаля. Где?

camac
()

а где поскаль? несправедливость

gribf
()
Ответ на: комментарий от argv_0_

язык shell спроектирован для управления исполнением процессов

Поясни что ты подразумеваешь под управлением исполнением процессов.

# работы с аргументами;

http://www.gnu.org/software/libc/manual/html_node/Program-Arguments.html#Prog...
По-сути то же самое и в баше, где вместо argc используется переменная с именем # и вместо argv массив @.

# работы с файлами;

Да, в sh вместо вызова обычных функций для работы с файлами как в C используются синтаксические конструкции вроде >, >>, &> и т.д. Следует заметить что похожие конструкции есть в C++.

# посылки сигналов;

http://www.gnu.org/software/libc/manual/html_node/Signaling-Another-Process.html
В баше аналогично.

# получения кода завершения?

http://www.gnu.org/software/libc/manual/html_node/Process-Completion-Status.html
В баше для этого используется переменная ?, да.

Касательно логики. Показываю на пальцах:
— Самолёт предназначен для совершения полётов в атмосфере. Поэтому его конструкция обеспечивает разгон, набор высоты, снижение и приземление.
— Ёжик, если его посильнее пнуть, разгоняется, набирает высоту, а затем снижается и приземляется. Ёжик - это самолёт.

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

Тут был бы вполне уместен пример кода.

Лень. По-сути обычное использование find, head и tail с нужными аргументами и перенаправлением в файл.

О том, что «shell, по большому счёту - не алгоритмический язык».

Но ведь тред совсем не об этом.

h578b1bde ★☆
()

Ассемблер x86 забыли... Дискриминация однако

xcray
()
Ответ на: комментарий от h578b1bde

# работы с файлами;

Да, в sh вместо вызова обычных функций для работы с файлами как в C используются синтаксические конструкции вроде >, >>, &> и т.д. ... ...

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

По-сути обычное использование find, head и tail с нужными аргументами и перенаправлением в файл.

Вот. Именно эти «find, head и tail» (Которые, замечу сразу, совершенно самостоятельные сущности, и к shell не имеют никакого отношения. Вообще. От слова «совсем».) и будут исполняться в процессах, которым shell сформирует окружение, передаст аргументы командной строки, подготовит, если надо будет, каналы ввода/вывода, получит и обработает их коды завершения. То есть будет управлять исполнением этих процессов (и для этого в языке shell есть все необходимые средства). И, скорее всего, больше почти ничего делать не будет. То есть практически вся работа будет выполнена внешними по отношению к shell командами.

Но ведь тред совсем не об этом.

Он, может быть, и был бы совсем не об этом, если бы не тот комментарий. :) А так, по факту, он уже.

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

Аналогии вообще sucks и хромые от рождения.
А почту голубями пересылать не получится - потери пакетов слишком большие, и задержки запросто могут превышать TCP timeout. Только пинги. Да ито напоиграцца.

argv_0_
()

«Питон» - написало 44% пользователей из браузера на C++ и js, запущенного на ОС, написанной на Си. Ежели этот ваш питон так хорош, то почему у меня в системе нет ни одной графической или текстовой програмки, на нем написаной? Конфуции, рассуждающие про «для каждой задачи свой инструмент», видимо заняты осваиванием инструмента под очередную задачу

makoven ★★★★★
()
Последнее исправление: makoven (всего исправлений: 2)

Ruby 121 (9%)

Я думаю всего нас 300.

special-k ★★★
()
Ответ на: комментарий от argv_0_

Вы не делаете различий между языком C, и библиотекой С

А без неё жизнь есть?

Именно эти «find, head и tail» (Которые, замечу сразу, совершенно самостоятельные сущности, и к shell не имеют никакого отношения. Вообще. От слова «совсем».)

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

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

Всё это скрытые от программиста внутренности, точно также как машинные инструкции для C.

А почту голубями пересылать не получится

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

h578b1bde ★☆
()
Ответ на: комментарий от h578b1bde

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

Не распарсил.

Всё это скрытые от программиста внутренности, точно также как машинные инструкции для C.

Но именно в этом и состоит работа shell. Да и не скрывают это ни от кого - всё документировано.

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

RFC 1149 :)

argv_0_
()
Ответ на: комментарий от matumba

Поражает то, откуда появилось столько дилетантов, которые зная убожество и ограничения «макроядра», всё равно впряглись продвигать это гуано - неужто никто не чувствовал, что лепит глиняного колосса?

Может всё намного проще и с макроядрами всё ОК, а дилетант - это ты?

mbivanyuk ★★★★★
()
Ответ на: комментарий от argv_0_

Не распарсил.

Вызов внешних утилит на баше и вызов функций в C в реализации (использовании) выглядят одинаково.

Да и не скрывают это ни от кого

Имелась в виду абстракция.

RFC 1149 :)

Да, я про этот RFC/эксперимент в курсе, поэтому и уточнил что почтовые голуби вполне успешно использовались раньше вплоть до наступления эры интернета.

h578b1bde ★☆
()
Ответ на: комментарий от h578b1bde

Имелась в виду абстракция.

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

Вызов внешних утилит на баше и вызов функций в C в реализации (использовании) выглядят одинаково.

Разве что выглядят... На самом деле общего мало.
Но сейчас наверное уже во всех предках Bourne Shell можно объявлять и вызывать свои функции. Синтаксически вызов строися так же, как исполнение команды, но функция исполняется в контексте вызывающего shell. Вот это как-то больше похоже на сишный вызов функции.

argv_0_
()

Другой: Assembler, BASIC, Pascal. UPD: ах, да, еще до кучи bash и awk.

Infra_HDC ★★★★★
()
Последнее исправление: Infra_HDC (всего исправлений: 1)

28% отметивших «Другой» вариант как бы намекают на полноту покрытия ;)

northerner ★★★
()

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

barberry ★★
()

А где Perl или это уже не ЯП?

dmnord
()

Вообще beastie надо побить ссаными тряпками)) ещё можно простить нуба, который запостил данный опрос, но модератора который повесил такое без Perl'а... надо лупить!!! Языки типо Rust на которых ещё написать ничего не успели, присутствуют, а Перла нет? Смешно. BrainFuck ещё добавьте)))

golodranez ★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.