LINUX.ORG.RU

Выбор языка программирования

 


0

5

Здравствуйте, коллеги!

Понимаю, что данная тема из разряда holywar, но так уж вышло.

Я более-менее знаю С, С++. Последний мне не нравится.

Поверхностно знаком с Python. Он не плох, только уж слишком тормознутый. Еще в минусы падает, сложная переносимость между устройствами, тут и разноверсица, и возможные сложности с использованием библиотек. Да. Многое решает venv, но это ужасно не удобно.

В общем, со всем можно было бы смириться, кроме тормознутости. До смешного. Сделал в питоне функцию, которая выполняет банальнейшее XOR шифрование, потом то же самое сделал на С и замерил скорость при работе с блоком данных в 100Мб.

Результат убил на повал. Сишный код оказался быстрее более чем в 1000 раз! Это как, вообще? Понятно, что функцию шифрования можно написать на С и подцепить ее в питоновском сприпте, но постепенно оказывается, что нужно что-то еще ускорить на С. И еще что-то. И еще… В результате от питона ни фига не остается.

Вроде, ну если знаешь С и С++, то пиши и радуйся жизни! Но, С++, как я написал выше, мне не нравится. А на чистом С работа со строками - издевательство.

Раз уж я знаю С, то что стоит изучить любой другой язык?

Вот я и решил копнуть Rust и Golang…

Что сказать… Посмотрев немного на Rust у меня остатки волос встали дыбом! Нагородили хрен знает что! У меня создалось впечатление, что Rust это просто набор костылей.

Возможно я не прав, даже скорее всего, но вот на него переползти с С для меня окажется или непосильной задачей, или ооочень сложной.

Golang? С ним вроде попроще. Но снова чувство костылинга. Плюс, зачем-то изголянее с объявлением переменных. Ну нафига тип переменной идет после ее названия? Типа, Golang не С? Впрочем, у Rust то же самое. Ну зачем???

Еще сильно поразило, что в Go и Rust нет нормальной перегрузки функции, типа int wise_func(char * str) и int wise_func(char * str, int len), Как в С++. Ну и функций с параметрами по умолчанию нет ни там, ни там. Алё! Разрабы! Вы ухи объелись?

Вроде, с помощью костылинга можно решить эти проблемы, но, блин, опять костыли!

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

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

Да, BASH еще более тормознутый и разбирать свой же скрипт, через месяц после написания, то еще удовольствие, но хотя бы bash скрипты без проблем переносимые!

В общем, я в печали. Хочется некий язык общего назначения что бы он был быстрым и был лишен неудобств старичка С, но, по ходу, нет гармонии в мире IT.



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

Для скриптов не подходит нифига. Пока Clojure запустится и раскочегарится, Питон все посчитать успеет.

Рекомендую обратить внимания на бабашку, там используется small clojure interpreter, как раз для ускорения загрузки.

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

На MS Windows вероятно и то, и то придется ставить.

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

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

Для PHP инсталлер есть, но он и не нужен. Его распаковал в папку и он оттуда работает. Можно хоть вместе со своими пых-приложениями свой интерпретатор прикладывать.

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

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

у тебя в любом случае как зависимость твоего скрипта будет интерпритатор. Так что это равнозначно для всех случаев кроме баша наверно. Разница лишь в том насколько сложно юзверю эту зависимость разрешить.

чтобы поставлять runtime вместе (или вместо скрипта). Если он относительно небольшой в скомпилированном виде.

кмк это костыль. используй компилируемые языки если хочешь бинарь.

надо изучать, какие там плюсы/минусы..

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

Noob_Linux ★★★★
()

Хаскелл на данный момент является лучшим языком для новых проектов. Исключительная выразительность языка и мощная система типов позволят Вам быстро писать элегантный и надежный код. Язык еще не столь распространён. пока ваши конкуренты используют устаревшие технологии на базе нетипизированных лямбла-исчислений или императивного подхода с элементами динамической типизации, вы сможете в разы поднять свою эффективность, задействовав System F - последнее достижение науки в области статической типизации. Но это еще не все. В жизни любого стартапа наступает момент, когда он превращается в продукт и сопровождению проекта привлекаются дополнительные разработчики. На этом этапе распространённость и доступность языка начинает играть решающую роль. Благодаря активной популяризации Хаскелла и функционального программирования в среде коммерческих программистов, а также поддержке этого языка со стороны лидера производства оффисных приложений и операционных систем - корпорации Майкрософт, Вы можете быть уверены, что в будущем Вам не придется переписывать свой проект на С++, как это было с печально известной разработкой Пола Грэма. Хаскелл обеспечит вам гарантии успеха и стабильности Ваших начинаний. Выберите Хаскелл сейчас и через несколько лет Вы сможете наслаждаться результатами своих трудов - успешным проектом, выполненным с учетом всех современных технологий и индустриальных стандартов. Хаскелл - Ваш проводник к успеху в мире разработки программного обеспечения. Выбирайте Хаскелл.

anonymous
()

Мне кажется, или никто не упомянул Common Lisp? А зря. Высокая скорость исполнения сочетается с высокой скоростью разработки. Интерактивная разработка позволяет исследовать возможные пути решения проблем с огромной эффективностью. Также рекомендую освоить Emacs со Slime - ты меня еще не раз поблагодаришь.

anonymous
()

Конечно же dlang. Писать можно в сишном стиле, или плюсовом, или джавовском. Постепенно переходя на более идиоматичный стиль. Можно писать скрипты на нем за счет очень быстрой компиляции. Быстродействие как у С/С++, удобство и интуитивность как у Питона. Либ поменьше, правда. Но сишные либы можно использовать без проблем (есть фича ImportC, позволяет сишный код импортировать как дишный без ограничений), для плюсовых биндинги могут понадобиться.

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

Мне кажется, или никто не упомянул Common Lisp? А зря. Высокая скорость исполнения сочетается с высокой скоростью разработки

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

P.S. Или у нас тут завёлся второй борщелиспер, или Лавсан перелогинься.

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

ваши преемники будут разбираться пару лет.

И кстати, по крайней мере у них будет пара лет, CL хоть и (λ(λ(λ(λ)))) зато он уже десятки лет такой. У исследователей кода на Питоне, Расте, и т.п. эта «пара лет» будет, или через пару лет надо будет всё переписывать, потому что то, что было год назад уже deprecated, а обратную совместимость не завезли?

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

IMHO D искусственно сложный.

Вот например массивы (https://dlang.org/spec/arrays.html). После прочтения мне не ясно, как и в каких случаях нужно освобождать память применительно к array. В спеках вообще про аллокацию/деаллокацию очень мало написано. :-(

Поискал на форуме, нашел например https://forum.dlang.org/thread/ajxnomrxplzdkmxntzki@forum.dlang.org и https://forum.dlang.org/thread/qwjexechvgeseywkxhce@forum.dlang.org

Описывается много вариантов, некоторые из которых deprecated, c GC и без и т.п. и т.д, ссылки на какие-то блоги, но мало ссылок на спеки :-(

MirandaUser2
()

Сишный код оказался быстрее более чем в 1000 раз!

Просишь AI studio реализовать для этого кода мультипоток и оптимизировать и радуешься что код выполняемый за 20 минут закрывается за 30 секунд

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

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

Так это зависит от того, как ты эту память получил. Если через ГЦ, то ГЦ за нее и отвечает и тебе не нужно думать об этом. А если вручную ты ее выделил - то сам и освобождай, как и в С или С++.

По умолчанию используется ГЦ, поэтому не нужно думать об освобождении

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

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

Почему?

pipenv и poetry — говно из жопы, первое ещё и медленное. Их ещё и отдельно накатывать нужно. Намного проще сделать pip install -r requirements.txt в докер контейнере, чем возиться в нём с костылями. Сборки — это ещё хуже. Даже локально, для venv всего 4 команы:

python venv .venv
# или source .venv/bin/activate
pip installl blah blah
pip freeze > requirements.txt
pip install -r requirements.txt

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

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

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

После прочтения мне не ясно, как и в каких случаях нужно освобождать память применительно к array. В спеках вообще про аллокацию/деаллокацию очень мало написано. :-(

у D жеж вроде сборщик мусора. что вы собрались деаллокировать ручками?

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

Так это зависит от того, как ты эту память получил.

И почему же об этом ничего не сказано в спеках? С примерами для GC/без GC.

Это нормальные вопросы для новичка, сообщество там хорошее, нетоксичное.

Охотно верю в сообщество. Но предпочитаю опираться на официальную документацию. Если в документации плохо прописаны такие базовые вещи, то видимо стоит отложить знакомство с D до лучших времён. :-/

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

pipenv и poetry — говно из жопы, первое ещё и медленное

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

pip freeze > requirements.txt

Вот за такую херню надо руки отрубать.

Просто, удобно, из коробки

«Просто, удобно, из коробки» как раз у меня. Чел прост распаковывает и запускает. И никаких pip install :)

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

Из спек (https://dlang.org/spec/garbage.html):

D is a systems programming language with support for garbage collection. Usually it is not necessary to free memory explicitly.

D also provides the mechanisms to write code where the garbage collector is not involved.

Когда я далее по спекам читаю про разные типы (такие как например array включая все его разновидности), я ожидаю, что для них явно будут описаны правила использования во всех режимах (GC/noGC и пр.).

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

массив вообще не надо деаллоцировать, если ты не создал его ручками по какому-нить new. есть у тебя gc или нет его.

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

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

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

Ну ты сам уже ответил:

Чел прост распаковывает и запускает

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

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

Если в документации плохо прописаны такие базовые вещи, то видимо стоит отложить знакомство с D до лучших времён.

Это ты пришел из языка с ручным управлением и поэтому у тебя подгорает, почему в языке с гц не написано про ручное управление памятью на первой странице. У меня также было - первая программа была плюсовой программой, которую недавно написал и портировал под плюсы и у меня было куча багов с двойным освобождением памяти, я там в гневе писал на форуме какое гавно этот ваш Ди. Мне объяснили все, и когда я тупо убрал все ручное освобождение памяти - все заработало. В итоге язык очень зашел. Ручное управление в нем более чем возможно, но это не для новичков. И к динамическим массивам, выделяемым на куче с помощью ГЦ ручное управление отношения не имеет и поэтому в документации отсутствует.

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

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

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

я в основном на языках с GC пишу, но от Dlang действительно ожидал, что это BetterC++, и gc/nogc в нём равноправны. Но документация определенно ориентирована на GC (хотя нигде это явно не заявляется %-/ ), а core.stdc.stdlib.malloc() и core.stdc.stdlib.free() только местами упоминаются.

Но в целом, несмотря на странные спеки, разобраться можно, и с помощью rdmd писать скрипты (https://dlang.org/rdmd.html).

#!/usr/bin/env rdmd
import std.stdio;
void main()
{
    writeln("Hello, world with automated script running!");
}
MirandaUser2
()