LINUX.ORG.RU

Немного мыслей про bash, какой-то он не очень

 ,


0

1

Захотелось изучить программирование, просто ради интереса. Посоветовали bash, потому что несложный (так мне сказали). Но вот синтаксис что-то не обрадовал. Мне одному показалось что он какой-то не от мира сего? По сравнению с тем же питоном и Си... код на баше выглядит каким-то непонятным, я бы сказал чрезмерно усложненным. Но ради чего это усложнение- непонятно.

А еще куча мелких нелогичностей всплывает по мере изучения. Например, условия сравнения.

Флажки (-lt, -gt и т.д.) работают только для чисел, а знаки (>, < и т.д.) только для строк- ну кто придумал эту тупость? Зачем придумывать дублирующий функционал (вот эти флажки), а потом намерено делать так, чтобы одно работало только с числами, а другое только со строками?

И много еще такой фигни в баше?)


Ответ на: комментарий от Kroz

Там даже ввели такую штуку как Type Hinting, когда поняли что без типов совсем грустно.

А зачем эта косметика нужна? Много хайпа, а выхлоп-то нулевой.

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

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

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

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

Ничуть. Так как у меня вот под рукой простейший, но всё-таки web сервер на bash. Самодично я писал HTTP стабу (REST авто-ответчик), и автотесты enterprise solution'а на bash. Только после этого я попытался сделать это же на Python, и понял, что Python для таких задач намного удобней.

И, да, мы всё-таки говорили про обучение программированию. Bash не очень удобен в работе с массивами, с ООП у него совсем беда... продолжать?

Kroz ★★★★★
()
Последнее исправление: Kroz (всего исправлений: 1)
Ответ на: комментарий от anonymous

Там даже ввели такую штуку как Type Hinting, когда поняли что без типов совсем грустно.

А зачем эта косметика нужна? Много хайпа, а выхлоп-то нулевой.

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

Да и без документации - читаемость самого кода важна.

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

Мне кажется, что ООП — дебри, которые знать вкатывающемуся в программирование, мягко говоря, не стоит. Я не защищаю bash как метод вката, но цепочка sh -> awk -> perl по принципу «как пришлось» выглядит явно получше JS и PHP.

Самолично я вкатывался через Pascal и сишечку.

anonymous
()
Ответ на: комментарий от Kroz

Для этого уже были docstring'и. В каждом первом рассказе про вот это вот (type hinting) подразумевают, что это типизация, хотя типизацией и какими-либо контрактами (контракты ведь надо исполнять?), отличными по сути от соглашения использовать docstrings такого-то формата, не пахнет и в помине.

читаемость самого кода

Читаемость кода с таким выхлопом в лужу (если он неправильный) падает быстрее, чем с указанием типов и ограничений в docstrings. Кому-то придёт в голову, что раз этот артефакт крякает, как взаправдашняя сигнатура типов, то он и есть настоящая сигнатура и что питон теперь хаскель на минималках.

В общем, довольно-таки не совсем очевидная вещь, делающая явно не то, что она должна делать. Вдобавок к тому переоценённая.

anonymous
()

Захотелось изучить программирование

Посоветовали bash

Тебя обманули.

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

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

Хочешь программировать — начинай по заветам Столярова с паскаля. Освоишь паскаль - берись за си или раст. :) В любом случае привыкай не быть рабом одного языка, а знать несколько разных и уметь выбирать под задачу. Если какой-нибудь «программист» при тебе будет употреблять выражения «программист на паскале», «программист на си», «программист на плюсах» — гони его в шею, это не программист.

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

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

Я бы рекомендовал Pascal, так как там типы, указатели и т. п - то, чего в python нет, и что дает хорошее понимание о настоящем программировании.

Подписываюсь.

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

disregard that, пожалейте мою больную головушку.

anonymous
()
Ответ на: комментарий от hobbit

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

Мне и этого по сути хватит для начала) А там глядишь дойду до чего посерьезнее.

Хочешь программировать — начинай по заветам Столярова с паскаля. Освоишь паскаль - берись за си или раст. :)

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

Если какой-нибудь «программист» при тебе будет употреблять выражения «программист на паскале», «программист на си», «программист на плюсах» — гони его в шею, это не программист.

У нас пол отдела таких, но это новички. Если их прогнать, они не смогут развиваться и стать «настоящими программистами». Правда есть один дядя уже 10 лет на Java прогает, другого не знает. Но бабос сшибает. Но на джаве проги некрасивые получаются, как-то установил в линукс пару прог на джаве, а там окна ну вообще в систему не вписываются. Потом мне сказали что это особенность джавы, ну ее тогда.

divlns
() автор топика
Ответ на: комментарий от anonymous

Мне кажется, что ООП — дебри, которые знать вкатывающемуся в программирование, мягко говоря, не стоит.

ООП - это основа из основ. Без этого сейчас никуда.

Я не защищаю bash как метод вката, но цепочка sh -> awk -> perl по принципу «как пришлось» выглядит явно получше JS и PHP.

И первое и второе так себе.

Самолично я вкатывался через Pascal и сишечку.

Вот. Плюсую. Сам так вкатывался (ну, перед этим Basic немного пощупал, но это не критично).

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

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

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

Не знаю что это, но я пользовался разными линуксами, и прог на паскале не видел. Может что-то консольное есть, но графических на паскале не видел. Обычно там на Си/C++, иногда питон и джава. Может и можно на апскале графические проги создавать, но раз так никто не делает, видимо это не выгодно или через чур сложно.

divlns
() автор топика
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от divlns

Паскаль это скучно, надо брать что-то на чем проги делают.

1) Я же говорю — привыкай, что одним ЯП у тебя ограничиваться не получится. Паскаль даёт навыки строгой типизации.

2) Внезапно, Double Commander, лучший графический двухпанельный ФМ для линукса, написан на паскале.

На паскале это будет долго и нудно, нужны готовые музыкальные библиотеки

Есть биндинги того же ffmpeg и не только его.

У нас пол отдела таких, но это новички. Если их прогнать, они не смогут развиваться и стать «настоящими программистами»

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

Может и можно на апскале графические проги создавать, но раз так никто не делает, видимо это не выгодно или через чур сложно.

Всего-навсего инерция мышления.

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

hobbit ★★★★★
()
Последнее исправление: hobbit (всего исправлений: 1)
Ответ на: комментарий от Kroz

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

anonymous
()

Флажки (-lt, -gt и т.д.) работают только для чисел, а знаки (>, < и т.д.) только для строк- ну кто придумал эту тупость? Зачем придумывать дублирующий функционал (вот эти флажки), а потом намерено делать так, чтобы одно работало только с числами, а другое только со строками?

Причём тут bash? это флажки test aka [, а не баша.

man test

Зачем придумывать дублирующий функционал (вот эти флажки), а потом намерено делать так, чтобы одно работало только с числами, а другое только со строками?

В подавляющем большинстве языков строки и числа — разные сущности. И это правильно

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

Ради использования в качестве непосредственно шелла, а не только скриптового языка. Не всё, что красиво выглядит и красиво пишется в скрипте, удобно использовать в интерактивной командной строке. Синтаксис shell (POSIX Shell, и Bash тоже) как раз компромисс между обеими удобствами, с упором на использование в командной строке, а не скрипты.

anonymous
()
Ответ на: комментарий от hobbit

лучший графический двухпанельный

Вы, очевидно, перепутали того с этим https://krusader.org/ и этот ни разу не на паскале.

anonymous
()
Ответ на: комментарий от Kroz

Я уже не говорю о том, что этой основы как минимум в трёх нынешних языках нет вообще. Без ООП везде и всюду выжить можно.

Касательно твоего высказывания про не такое ООП в JS можно сказать, что и в питоне, и в Java оно не такое. Такое оно в Smalltalk и в парочке других языков.

anonymous
()
Ответ на: комментарий от hobbit

Double Commander, лучший графический двухпанельный ФМ для линукса, написан на паскале

На Lazarus. Уточнение довольно важное, потому что разница, как между программой на C++ и программой на Qt.

P.S. Паскаль — лучший язык для обучения. Уточнение добавлено исключительно из занудства.

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

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

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

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

Я не понял, а когда и кому изученный паскаль мешал учить сишечку, кроме людей с синдромом утёнка?

Мне так вот наоборот помог, я считаю.

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

В паскаль есть встроенный ассемблер. Учить «ассемблер с сахаром» ака С смысла немного. Хотя сишечка после паскаля учится за вечер, а вот сделать из сишника программиста может потребоваться много лет (впрочем, Эдик и в 40+ продолжает писать убогий говнокод, в данном случае болезнь дошла до неоперабельной стадии), больно сильно она неокрепшие умы калечит.

gremlin_the_red ★★★★★
()

Учи Паскаль.

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

Ну, ок, пусть будет docstrings, сути это не меняет: явное указание типов повышает читабельность кода. А если эти типы указаны не в виде комментариев (как в python), а конструкцией языка, это гарантирует что то, что написано, то и есть на самом деле.

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

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

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

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

Я учился си после питона, у меня было такое небольшое развлечение: реализуй обычную скучную частоиспользуемую функцию из стандартной библиотеки питона на си. Чтобы писать с таким же привычным удобством и качеством на си. Работало оно конечно быстрее намного, но зачастую внезапно оказывалось что повторить точно такое же поведение (или приближено, без динамики, ооп, всего этого, только результат) весьма не тривиальная задача на многие тысячи KLOC. Поэтому что бы там не говорили, а питон вне конкуренции по скорости и удобству разработки.

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

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

anonymous
()
Ответ на: комментарий от Kroz

Явное указание типов не обязательно повышает читаемость кода, особенно там, где на это явное указание плевали и плевать будут. Эти самые type declarations в питоне являются не комментариями, а конструкцией языка (по крайней мере, на первый взгляд), что не помогает, а вводит в заблуждение.

Я не говорю, что статическая типизация нужна всегда и везде.

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

Если хочешь взглянуть на то, что по моему мнению стоило бы сделать в питоне вместо куцых и не говорящих ни о чём докстринг-заменителей, посмотри на Racket и Typed Racket до кучи. Там есть те самые декларации в виде тех же контрактов. Контракты там стоят не просто так, их проверят, если надо. Более того, вместо ничего не значащего контракта «целое число» ты можешь вывести предикат на «число больше нуля и меньше n», писать сигнатуры на классы, модули и тому подобное, а в typed racket ко всему этому и оптимизация есть, то есть наша динамика мутировала в хаскель на минималках.

рекомендовал начинать с Питона

Почему не perl, не pascal, не Си, не ruby? Они хотя бы не пытаются заявить о том, чего нет, это как раз включает хвалёную «простоту».

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

что повторить точно такое же поведение

Мы нашли того самого сказочного программиста на фортране, но только вместо фортрана питон.

anonymous
()
Ответ на: комментарий от hobbit

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

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

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

Всё нормально, потом я стал писать на питоне как принято на си и тоже получил ускорение теперь уже в питоне. Ценой безопасности кода правда. Ещё оказалось, что достаточно разумно выносить горячие участки из питона в си, или хотя бы в цитон с отключенным GIL (по производительности как си).

А фортран и сегодня без конкурентов для математики, к сожалению.

anonymous
()
Ответ на: комментарий от gremlin_the_red

В паскаль есть встроенный ассемблер.

Ой-вей, торагой, прямо в стандарте языка встроенный ас-Семблер есть?

В C11 и C++11 asm таки есть, пусть и в приложении.

У меня есть довольно большие сомнения по поводу хотя бы интероперабельности библиотек на разных реализациях Pascal. С Си такого нет.

а вот сделать из сишника программиста может потребоваться много лет

Ваши пассажи по поводу Eddy_em пусть слушает он, а не я.

По вашим постам в /development/ ваших навыков особо не видно в любом случае.

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

Кажется, вы не слышали рассказ про программиста на Фортране, который пишет на любом языке как на Фортране. Было где-то в коллекции fortune cookies.

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

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

anonymous
()

Флажки (-lt, -gt и т.д.) работают только для чисел, а знаки (>, < и т.д.) только для строк- ну кто придумал эту тупость? Зачем придумывать дублирующий функционал (вот эти флажки), а потом намерено делать так, чтобы одно работало только с числами, а другое только со строками?

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

Теперь про строки и сравнения. Строка «10» находится перед строкой «9» в алфавитном порядке, но число 10 находится после 9. Поэтому когда сравнивать нужно числа, хочется один результат, а когда сравниваются строки — другой. Это не тупость. Это просто ты не додумался, что бывают разные ситуации, а другие до тебя — додумались. Тебя ещё много таких открытий ждёт, через это все проходят.

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

Объясни пожалуйста пару вещей)

Вот это сравнение в кавычках и без- это одно и то же?

var=a

if [[ $var > "c" ]]

if [[ $var > c ]]

Оба выдают false (т.к. 61 < 63) - это эквивалентная запись?

И почему если условие false, то отрабатывает такой цикл?

for var in a , b , c_d
do
  echo "Begin"
  if [[ $var > "c" ]]
  then  
    continue
  fi    
  echo "End"
done

a = 61, b = 62, запятую в ascii не нашел, но видимо тоже < 63, так почему continue отрабатывает и печатается «End»?

И как посчитать «c_d» - там же 3 символа (оно как раз не отрабатывает в этом условии).

divlns
() автор топика
Ответ на: комментарий от divlns

Оба выдают false (т.к. 61 < 63) - это эквивалентная запись?

Насколько я понимаю, да.

так почему continue отрабатывает и печатается «End»?

Из всех итераций только с c_d будет истина в условии, и End будет пропущено.

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

i-rinat ★★★★★
()
Ответ на: комментарий от anonymous

Ты почему-то защищаешь статическую типизацию там, где её в помине нет

Я говорю о том, что статическая типизация - это инструмент, которым нужно овладеть, и научиться 1) пользоваться там, где это уместно 2) не пользоваться там, где это не уместно 3) уметь различать эти два сценария.

рекомендовал начинать с Питона

Почему не perl, не pascal, не Си, не ruby? Они хотя бы не пытаются заявить о том, чего нет, это как раз включает хвалёную «простоту».

Pascal - да. У него есть преимущества и недостатки по сравнению с Питоном, но вцелом, для обучения программированию я бы посоветовал Pascal и/или Python.

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

Ruby - я с ним не имел дела. Не люблю говорить о том, чего не знаю.

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