LINUX.ORG.RU

Человеческая замена C для своих задач

 ,


0

3

Хочется найти простой кроссплатформенный компилируемый язык для программирования всякой мелочи для себя. Отправной точкой можно назвать C, но хочется поменьше рутины, возможностей на ровном месте выстрелить в ногу и наличия удобных базовых структур, вроде строк, динамических массивов и прочих списков. В кандидатурах сейчас пока C++ (не хочется лезть в дебри именно плюсов, с другой стороны писать в духе C с классами кажется как-то не комильфо), Pascal (начинал с Delphi когда-то, но уже почти не помню), Vala (тыкал немного, напрягает, что надо тянуть Glib и с поддержкой + кроссплатформой не очень), Go, D (на первый взгляд тоже ситуация с поддержкой и библиотеками не радует), Rust (какой-то инопланетный, но идея с управлением памятью интересна).

Ответ на: Ну примерно так, да... от Moisha_Liberman

Мне хватило услышанного, чтобы я понял, что с С++ я вообще никаких дел иметь не собираюсь! И если у меня вдруг возникнет нехватка ООПщины, то я приму галоперидола и успокоюсь.

Eddy_Em ☆☆☆☆☆ ()
Ответ на: Re: Дайте угадаю? от anonymous

Ну да. Соглашусь.

Проприетарного кода на крестах поболее будет

А если сюда ещё приплюсовать такое адское поделие как managed c++, точнее C++/CLI, то...

Только С++ это весьма условно и... Ну, в общем, сложно всё. Не будем плюсовать. ;)

Moisha_Liberman ()
Ответ на: В любом языке есть... от Moisha_Liberman

Re: В любом языке есть...

А по временам это здорово экономит время и усилия и ресурсы. goto cleanup: и всё почистили.

Удивительная хрень. Нет чтобы просто добавить что-то типа. defer, но ведь тогда код получится не Ъ-тру. И это тупизм, уже и писак стандартов, и Си поклонников. Нормальную очистку можно только через goto реализовать. И единственный адекватный выход — это defer. Даже есть ГНУ-расширение, реализующее этот дефер. Но оно настолько же тупое как Си. И единственная причина, по которой дефера нету в стандарте — это все программисты Си, боясь, что их засмеют, назовут не ь-трю, раскрыть свой реальный уровень интеллекта, не пишущие об этом нигде.

Зато у них есть норетёрн, какое достижение. Если учесть, что ГСС (кстати правильно ГГС, т.к. Си — это говно) в состоянии распознать вызов exit-ов, то необходимость сего решения ещё сильнее возрастает.

Нормальный ЯП делается сообществом с любовью и при модерации бородатых дядек. Си — это общий сортир, куда каждый срёт, и дядьки те просто сортируют говно.

И эта философия пропитывает каждого программиста Си до мозга костей.

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

Мне хватило услышанного, чтобы я понял, что с С++ я вообще никаких дел иметь не собираюсь!

Это ты правильно понял. Твоих 8-битных мозгов не хватит на кресты. Сиди лучше в своей песочнице и не высовывайся.

anonymous ()
Ответ на: Re: В любом языке есть... от anonymous

Глядя на объёмы стандартов...

Си — это общий сортир, куда каждый срёт, и дядьки те просто сортируют говно.

С++ это общий сортир, куда каждый срёт...

Поправил. Не благодарите.

В остальном — позвоните Оккаму. Пусть он Вас побреет. У него есть бритва. =)))

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

Владимир 123456

Привет копрофилам вселенной.

Есть два подхода в программировании — а точнее к программированию это вообще отношения не имеет, но не суть — это когда компилятор делает всё возможное, и программист просто пишет свой код. И второй. Второй выбор для тех кому не хватает ума открыть для себя GNU Assembler и играться с камнем пока это не осточертеет. Потом закрыть его и больше к нему не возвращаться. Нормальный программист в курсе, что такое стек, регистры. И прочее. Как там всё устроено. Потому что хавает низы в первую очередь, а потом приправляет это хай-левлом, постепенно поднимаясь с каменного дна.

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

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

Программисты второго типа — этакие дворовые мальчишки с пирочинным ножём, которые думают, что у их ножа сразу 500 функций, и в то числе и втирать зад.

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

Программисты второго типа — этакие дворовые мальчишки с пирочинным ножём, которые думают, что у их ножа сразу 500 функций

Чем-то напомнил спор про раст и с/с++ с анализаторами. Одни всё суют в язык, другие считают что

всё что может делать инструмент, должен делать инструмент. И инструмент этот должен обрастать инструментами для помощи.

chinarulezz ★★★★★ ()
Ответ на: Оккама позвать? от Moisha_Liberman

Re: Оккама позвать?

Он никогда не был стройным. Это часть его философии. Не указывать программистам, как им писать. Вам не нужно знать весь C++, чтобы писать на нем программы. Тем более, если речь про стандартную библиотеку. Не нравится фича оттуда - не используйте.

anonymous ()
Ответ на: В любом языке есть... от Moisha_Liberman

Re: В любом языке есть...

Ну т.е. конструктивного ответа не будет? Жаль.

А по временам это здорово экономит время и усилия и ресурсы. goto cleanup: и всё почистили

RAII сэкономит время, усилия и ресурсы еще лучше. При этом вы от него ничего не теряете. Ничего.

Не нравится RAII(деструкторы, видимо), но хотя бы with/using/try-with-resource или defer был бы полезен даже в Си.

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

Чем-то напомнил спор про раст и с/с++ с анализаторами. Одни всё суют в язык, другие считают что

Я не разделяю, если ты не понял, язык и плагины. Так что твоё «напомнил» — неудачное отклонение от сути.

anonymous ()

Человеческая замена C для своих задач

IMHO, современному программисту необходимо и достаточно знать три языка:

  • C++
  • Kotlin
  • JavaScript (современный Python)

Если ты не программист, то достаточно Kotlin или JavaScript (в зависимости от твоих задач). Kotlin - кроссплатформенный.

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

Если не пугает jvm, то kotlin. Если пугает, то только C++. Можно попробовать D.

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

Kotlin Native работает без всякого JVM, кроссплатформенно.

anonymous ()
Ответ на: Глядя на объёмы стандартов... от Moisha_Liberman

Re: Глядя на объёмы стандартов...

трындеть то, конечно могут все, но вот бенчсарки говорят, что С не так хорош. Или насильники отупели ? Ни в одной категории С не взял первое место. https://www.techempower.com/benchmarks/#section=data-r18&hw=ph&test=json

Ну, любители простого язычка, поясните свою илитарность, или только на лорчике трынлеть ?

anonymous ()
Ответ на: Re: Глядя на объёмы стандартов... от anonymous

но вот бенчсарки говорят, что С не так хорош

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

P.S.: а потом говорят, что всякие Расты быстрые, сравнивая его с этой улиткой, лол, кек.

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

точно! https://github.com/BurntSushi/ripgrep#quick-examples-comparing-tools

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


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

kostyarin_ ()
Последнее исправление: kostyarin_ (всего исправлений: 2)
Ответ на: комментарий от gag

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

//usr/bin/env go run $0 «$@»; exit package main

import ( «fmt» «os» )

func main() { fmt.Println(«Hello world!») cwd, _ := os.Getwd() fmt.Println(«cwd:», cwd) fmt.Println(«args:», os.Args[1:]) }

На компиляцию, запуск и отработку на мобильном sandy bridge уходит около 300 мс.

Вот по-настоящему быстрый компилятор (luajit):

local lfs = require"lfs"                                                                                                                                    
print("Hello world!")                                                           
print("cwd:", lfs.currentdir())                                                 
print("args:", ...)                                                             
$ time luajit /tmp/test.lua 1 34 56
Hello world!
cwd:    /tmp
args:   1       34      56

real    0m0,002s
user    0m0,000s
sys     0m0,000s
$

На самом деле, конечно, это jit-компилятор.

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

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

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

В каком месте goawk быстрее? Ты его описание-то смотрел? Или просто увидел большие цифры у гнутой реализации?

Я те линк на бенч дал, анонимус, там всё написано. Си посасывает местами, неслабо так, у языка со сборщиком мусора, да с причмокиванием. А какого-то феноменального отрыва там и в помине нету. Ну если только отрыва от Си, этого днища.

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

Всё ясно. Там выше ссылку на ripgrep дали - тебе в самый раз будет

Ссылку на то как медленный Си сосёт у медленного Раста? Да, мне было интересно посмотреть на это порно.

kostyarin_ ()

Самая большая проблема любого языка программирования состоит в том, что на 99.99% его используют «остроконечники» и «тупоконечники».

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

Одни всё суют в язык, другие считают что

Если язык не обеспечивает какое-то свойство программы (отсутствие use-after-free, скажем), то имеем теорему Райса о невычислимости нетривиальных свойств программ. То есть статические анализаторы могут отловить только какие-то частные случаи.

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

Если честно...

То я удивлён. =))) Как ни странно, но Вы даже почти поняли что именно и с чем сравнивается по приведённой Вами ссылке.

Хорошая попытка но нет, недолёт.

В приведённой Вами ссылке сравнивается реализация grep на rust с тем же GNU grep. И, казалось бы (азохнвей!) С-реализация сливает.

Но. Вообще-то, в rust-реализации использована либа, которая реализует pcre2 и реализует их (регулярки) через SIMD. Почитайте, у Вас в ссылке это написано.

В grep используется своя реализация (внутренняя!) регулярок, которая поддерживает не только Линукс, а ещё и всякие там dos, AIX, ещё полно всякой фигни. Нет, спрашивать запустится ли реализация на rust в AIX, я не буду, т.к. ответ будет «а нам и ненадо». Это не ответ для кроссплатформеного ПО, но пусть будет так.

Для корректного теста следовало бы подчистить код и использовать libpcre2. Эта реализация намного быстрее будет и даже будет быстрее, чем pcre, входящие в состав glibc (это тоже кроссплатформенно, т.к. будет работать там, где есть glibc, в т.ч. и на всяких AIX). Тут можно задуматься ещё и об объёме кода, но кто же в наши времена о таких мелочах думает? =))) Разве что сишники?

Дальше больше и хуже. Проблема в использовании SIMD. Инстриники штука хорошая за исключением нескольких «но». Во-первых, они должны быть в целевом процессоре. Даже NEON-инструкции при схожей семантике имеют слегка другой синтаксис. Так что, Вам стоит переписать используемую Вами либу так, чтобы она работала и на x86_64 и на ARM. Иначе, это как-то выглядит как на хер ненужно в наши времена.

Во-вторых, безумная векторизация это не панацея. Сами по себе инстриники штука хорошая в том же gamedev. Т.е., когда на хосте запущена игрушка, то навряд ли Вы будете на том же хосте считать что-то требующее повышенных ресурсов. Проблема в том, что общая производительность здесь просядет из-за массовых пересылок между основными ядрами проца и сопроцессора. У Вас либо вздёрнется система по шине, либо кеш будет холодным. Так что, я не уверен в том, что использование инстриников где-то за пределами какой-то мультимедии (видео и аудио, тот же gamedev) это полезная штука. Ну либо в каких-то вычислительных задачах (привет тем же матрицам). В поиске регулярок в файле? Да вы там пиз...... эээ... «с ума сошли»!

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

Спасибо за наводку. Всё стало ясно. Уж лучше самописный браузер (там писать немного) на С с тем же WebKitGtk, чем такая ярая антинаучная херня. Теперь мне стало понятно почему в других тестах rust грузит проц на ~100%.

Для тестов оно хорошо. А вот для практической работы в многозадачной системе... да ну его на хер.

Moisha_Liberman ()
Ответ на: Re: Оккама позвать? от anonymous

Не понял?

Вам не нужно знать весь C++, чтобы писать на нем программы.

Это что, шутка? Ну в наши времена уже можно говорить о «программировании на Qt» в противовес «программированию на С++», но тогда Ваши же слова можно переписать как

Вам не нужно знать C++, чтобы не писать на нем программы.

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

Тогда лучше уж грамотно на С, чем кое-как на С++. Хоть не стыдно будет за получаемые за работу деньги.

Moisha_Liberman ()
Ответ на: Re: В любом языке есть... от anonymous

Для того, чтобы дать ответ...

Конструктивный, я должен Вам напомнить как именно в С происходит работа с ресурсами.

Тогда вот это вот Ваше утверждение:

RAII сэкономит время, усилия и ресурсы еще лучше. При этом вы от него ничего не теряете. Ничего.

Оказывается голословным.

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

Всё просто и красиво. RAII не нужен. В С. В С++ иного выхода нет. Почему, собственно, RAII и распространён так широко в С++ и, по сути, больше ни где.

Moisha_Liberman ()
Ответ на: Если честно... от Moisha_Liberman

И да, забыл!

Я там бегло глянул код на rust. Сделайте милость — либо jemalloc выкиньте из рустовой реализации, либо тогда уж реализацию GNU с ним же перепишите. В дополнение к выше сказанному.

Просто потому, что сравнивать код нужно по-честному, а не в стиле малолетнего долб..., ну Вы поняли, да? Типа «ахаха! Сишечка сасёт!!11адын-адын».

Мы тут вроде как все собрались в той или иной степени программисты-профессионалы, да? Давайте уж как-то более приличествующе случаю. По-профессиональному? ;)

Moisha_Liberman ()
Последнее исправление: Moisha_Liberman (всего исправлений: 1)
Ответ на: Re: В ядре целая подсистема... от anonymous

А я и вспоминать не буду.

Угу. Про пространство имён тактично умолчи.

Если мне нужен код «в стиле ООП» из-за безусловных удобств записи и использования, то я его получу. Если мне нужен будет «именно ООП», то я и его получу ценой несколько бОльших усилий. Но зачем? Зачем решать несуществующую задачу?

Не всегда программирование это работа с объектами и только.

Moisha_Liberman ()