LINUX.ORG.RU

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

 ,


0

6

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


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

вы смогли бы увидеть, что в чистом C нет средств для этого.

Опять голословные заявления. А по-просту: бред!

И тут вы такой раз! И перечень этих самых средств. Не?

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

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

class myMap : protected HashMap внезапно проблема отсутствует

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

class myMap : protected HashMap внезапно проблема отсутствует

Ты уверен в этом?

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

Вот тут образуется дыра с непредсказуемым поведением потомка

Образуется, ведь классы сильно связаны. Если в таком случае меняешь предка - ревьюишь всех потомков.

Наследование - просто еще одна фича, которую можно использовать неправильно. Отсутствие таких фич - преимущество в философии какого-нибудь Go, но не C и C++, которые из такого целиком состоят. Не говоря о том, что масса кода на C++ пишется без ООП, и ей все недостатки ООП побоку.

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

C - простой язык. А выразительность и понятность текстов зависят лишь от кодописца. Но написать на С нечитаемое говно в разы сложней, чем на тех же крестах. О пхытоне вообще молчу!

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

Да что ты говоришь! Одни только шаблоны чего стоят! Напишешь на шаблонах код - вот тебе и нечитабельное говно!

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

Ну т.е. вместо вполне себе конкретного списка вида:

  • вот это сокращает объем копипасты;
  • вот это позволяет вовремя очищать ресурсы не полагаясь на аккуратность программиста;
  • вот это позволяет избежать определенного класса ошибок еще в compile-time;
  • вот это позволяет сделать информирование об ошибках более простым и надежным…

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

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

Одни только шаблоны чего стоят!

А что ты используешь в си для обобщенного кода?

Копипаста? Сам понимаешь, чем она грозит.

Макросы? Они в плане читаемости еще хуже, чем шаблоны. А ошибиться при их использовании легче.

void*? Во-первых, более тормозное решение. Во-вторых, так же плохо читаемое. В-третьих, выстрелить себе в ногу гораздо легче.

Напишешь на шаблонах код - вот тебе и нечитабельное говно!

Ну это как напишешь. И как читать умеешь. В любом случае, альтернативы в Си еще хуже.

Ну и да, никто ж не заставляет шаблонить.

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

Пусть каждый сам выбирает, на чем ему говнокодить. Вы предпочитаете кресты(или что там у вас), он сишечку.

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

Объем копипасты снижает использование макросов и обиблиотечивание своих сниппетов.

Вовремя очищать ресурсы - забота кодописца, не надо это валить на ЯП! ЯПы не для этого придуманы!

Вот с третьим - да, в gcc сейчас намного более вменяемые варнинги и ошибки. А в шланге - ещё лучше. Но при чем здесь ЯП?

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

Кстати, ты-то сам на чем быдлокодишь?

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

Пусть каждый сам выбирает, на чем ему говнокодить. Вы предпочитаете кресты(или что там у вас), он сишечку.

Речь не о навязывании чего-либо. Речь об обосновании использования конкретного инструмента.

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

Тоже самое можно сказать про Rust. Или C++.

В любом случае это все современные языки. Rust по определению. C++ и D по объему добавляемых туда новых возможностей (а так же по темпам своего развития).

Но вот рекомендация использовать чистый C в современных условиях она, как бы это помягче сказать, требует гораздо более веских обоснований, нежели в случае D, Rust, C++, Vala, Swift, Crystal и пр. современных альтернатив.

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

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

Объем копипасты снижает использование макросов и обиблиотечивание своих сниппетов.

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

Вовремя очищать ресурсы - забота кодописца,

Да.

не надо это валить на ЯП!

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

ЯПы не для этого придуманы!

Очередное время офигительных историй.

Вот с третьим - да, в gcc сейчас намного более вменяемые варнинги и ошибки. А в шланге - ещё лучше. Но при чем здесь ЯП?

Скорее всего вы не понимаете о чем идет речь.

Кстати, ты-то сам на чем быдлокодишь?

В основном на плюсах. По надобности на Ruby. Если перелистать учебники, то смогу еще на пару-тройке других, включая упоминавшися ранее D.

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

Вовремя очищать ресурсы - забота кодописца, не надо это валить на ЯП!

Вот странное мнение. Я всегда считал, что не царское это дело — освобождать память. Что может делать машина — пусть делает машина.

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

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

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

Речь об обосновании использования конкретного инструмента.

Важность выбора языка крайне преувеличена. Язык программирования - это не только технический инструмент. Это еще и способ коммуникации и выражения идей. А это уже сфера гуманитарная. И исходить тут нужно от людей во многом. Выбрав наиболее правильный язык(как инструмент) для своего продукта, вы в итоге можете проиграть из-за второго, гуманитарного аспекта.

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

Если перелистать учебники, то смогу еще на пару-тройке других, включая упоминавшися ранее D.

Где ссылка на гитхаб?

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

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

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

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

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

Писать систему реального времени на Visual Basic-е или CRM-ку на чистом C? Почему бы и нет, ведь выбор языка не важен.

Или давайте начнем переписывать древнюю систему на Cobol-е, которая проработала 50 лет, на Nim, чтобы она еще 50 лет работала.

Не, ну а чё, выбор-то не важен.

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

Я уже сказал: С - очень простой язык

Да.

и писать на нем очень легко.

Нет.

Зайди ко мне на гитхаб: там и всякая обработка данных, и сетевые демоны, и сервер-сайд веб-морд, и прошивки микроконтроллеров ... Да куча всего, и все это - на С!

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

И этот человек будет мне говорить, что шаблоны лучше макросов?

Вам больше не буду. Это бесполезно.

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

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

Есть разные подходы. RAII просто помогает не ошибиться. И делает код гораздо чище. Но все гарантирует только сам программист.

Автоматические системы тем или иным способом определяют доступность объектов и удаляют все недоступные.

Самый простой способ - подсчет ссылок. Каждая новая ссылка на объект увеличивает счетчик ссылок на него, а каждое уничтожение ссылки - уменьшает. Когда счетчик равен 0, тогда мы и удаляем объект. Достоинства: детерминированное время удаления. Недостатки: возможность циклических ссылок.

Ну а во многих языках сейчас используется GC. Он в рантайме определяет доступные объекты, фактически строит граф объектов от root(переменные на стеке, например). Недоступные удаляет.

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

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

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

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

Вы понимаете разницу между «важность выбора преувеличена» и «выбор неважен»?

Я говорил первое, а вы спорите со вторым=)

Соломенное чучело и все такое.

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

D вполне прилично на первый взгляд выглядит

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

Хороший язык (уж лучше хайповых го и раста). Но не полетел.

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

Вы понимаете разницу между «важность выбора преувеличена» и «выбор неважен»?

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

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

Тужился-тужился, а в итоге слился с синдромом утёнка. Нравится сишка - кто же запрещает, только не нужно засирать весь лор.

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

Так можно отвечать на каждый второй твой комментарий:

Нравится растишка - кто же запрещает, только не нужно засирать весь лор.

Михаил

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

У раста есть объективные преимущества. А эдик 17 страниц пытался родить хоть одну причину использовать Си, но так и не смог.

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

У раста есть объективные преимущества.

Нравится растишка - кто же запрещает, только не нужно засирать весь лор.

Арсений

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

Нравится растишка - кто же запрещает, только не нужно засирать весь лор.

Eddy_Em ☆☆☆☆☆
()

Оказывается у нас тут не только утёнки, но и лемминги.

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

Я видел, не так давно, но там баг касался С++.

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

Достоинства: детерминированное время удаления. Недостатки: возможность циклических ссылок

Сразу видно, что это писал поклонник GC. Главный недостаток ссылок в том, что они тупые: там где руками и дураку понятно, что это надо удалять, не гоняя в цикле счётчик, автомат будет вычитать, и возможна ситуация, что счётчик бы тут 0, но вот оно вот прямо сейчас понадобится и трогать не стоит. И делается это не тогда, когда правильно и непонятно как прервать когда надо. Да, можно и что-то потерять, но это именно ошибка, а не недостаток языка. Отсюда получается простой вывод - правильный код с автоматической чисткой всегда медленнее. Те кто утверждает обратное, выдают следствия вместо причины, то есть попусту либо нагло врут, либо просто некомпетентны. Да, возможно, стоило бы провести тесты на предмет необходимости решения КОНКРЕТНОЙ задачи методом чистки в момент освобождения ресурсов или в отложенные моменты. Но это может и проведено, и доказано, что на конкретном железе и профиле нагрузки так правильнее, а те кто сравнивают используют синтетические тесты и радуются, что если всё засрать, то до чистки всё как бы быстрее.

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

Зайди ко мне на гитхаб:

Зашел ради хохмы. В первый проект, который мне показался не связанный с низкоуровщеной. И вот:

gint fill_filelist(gchar *filename, Window *window){
	gint nb_inserted = 0;
	GDir *dir;
	GError *err = NULL;
	const gchar *dir_entry;
	gchar *dirname = g_path_get_dirname(filename); // (1)
	DBG("Open directory %s", dirname);
	dir = g_dir_open(dirname, 0, &err);
	if(dir == NULL){
		g_err(err->message);
		g_error_free(err);
		return 0;
	}
	free_filelist(window); // clear list if it was already created
	while((dir_entry = g_dir_read_name(dir))){
		gchar *full_path = g_build_filename(dirname, dir_entry, NULL);
		if(!g_file_test(full_path, G_FILE_TEST_IS_DIR)){
			nb_inserted += add_file_to_list(full_path, window);
		}
	}
	g_dir_close(dir);
	g_free(dirname); // (2)
...

Смотрим на точку (1). Тут выделяется память под dirname. И в точке (2) эта память освобождается.

Но только в случае, если до точки (2) управление дошло. А вот если по условию if(dir == NULL) произошел досрочный выход из функции, то память, выделенная под dirname, утекла.

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

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

Почему до сих пор не отправил патч? Это opensource, детка. Здесь никто никому ничего не должен.

Геннадий

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

Почему до сих пор не отправил патч?

Так ведь «Здесь никто никому ничего не должен.» Что распространяется и на оправку патчей.

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

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

Геннадий

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

эдик просто не слышал о Ci, статичных анализаторах, clang fsanitize, и прочих приятных вещах которые доступны нормальным людям в 2019 году

ну и код его никто не ревьюит

хорошо хоть он проверяет malloc() на NULL, ибо гномисты вообще забили на это ИБО МЫ Ж ПИШЕМ ПОД ЛЯЛИКС А ТАМ ВСЕГДА «optimistic memory allocation strategy», А НА ПОСИКС МЫ ЛОЖИЛИ БОЛТ.

Так-то на любом языке можно наговнокодить что угодно.

Но вообще да, бить себя лапой в грудь и орать что легко писать на C это не оч красиво.

reprimand ★★★★★
()

Уже задавал вопрос, но он утонул в срачах. Ща вроде поспокойней. Кто то щупал Zig (https://ziglang.org/). Есть у кого-то какие нибудь впечатления ?

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

Zig is a general-purpose programming language designed for robustness, optimality, and maintainability.

шо такое optimality? если оптимальность, то в чем?

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