LINUX.ORG.RU

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

 , , , ,


2

4

Пытаюсь выбрать язык программирования для личного проекта.

Хочется, чтобы у языка были:

  • библиотека для загрузки/выгрузки изображений с поддержкой широкого круга форматов
  • биндинги для sdl2
  • работа с битовыми массивами размером больше чем 64 элемента (с поиском единиц)
  • перегрузка оператора индекса в том числе при присвоении
  • ассоциативные массивы с лаконичным доступом к элементам
  • документацией с поддержкой мобильного просмотра в 2023 году-то
  • поддержкой компиляции для мобильных архитектур
  • нормальный полиморфизм, а не как в Rust
  • востребованность на рынке труда

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

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

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

Что выбрать?

★★★★★

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

Да, но потом надо еще сделать два JMP: один если бит 1, другой если 0 и в них расписать ту операцию, которая предполагается с битовым массивом.

Если массив обычный, то просто ()

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

Ну и Си++ язык высоко уровня. Опираться на x86 нельзя. У какого-нибудь эдакого процессора аналога BT может не быть.

Я вполне могу себе такое представить, учитывая что кое-где в оборудовании до сих пор Z80 применяется.

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

Да, но потом надо еще сделать два JMP: один если бит 1, другой если 0 и в них расписать ту операцию, которая предполагается с битовым массивом.

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

опять же с битами получается куда больше кешхитов чем с булами. не надо бояться битов!

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

https://www.opennet.ru/opennews/art.shtml?num=58639

Оно вот точно надо? Гугл опять какую-то хрень для себя мутит, а вы лезете…

Конечно, есть люди, которые хотят полной свободы и пишут gcc-go, но у него пока все не очень с производительностью, нет программы «go» (что гуглу make не нравятся?), версии отстают от гугловой реализации.

Но вы будете этим пользоваться?

Вот и я нет. Закопайте свой Go куда-нибудь поглубже.

Кстати, есть одно не очень популярное мнение, с которым я, однако, согласен: если мы уж заплатили цену интерпретации (вместо компиляции в машинный код), то надо писать на таком языке, который компилируемым сделать невозможно (функциональное программирование: lisp, erlang, и т.п.), либо это должен быть скриптовый язык, такой как Perl, Tcl, Python и т.п.

Кроме узких задач (где сама среда подталкивает писать на java) программа на Си++ будет значительно быстрее и (или) экономнее java (по понятным причинам), хотя код почти не будет отличаться (разве что в Си++ будут описаны конструктор копирования, конструктор перемещения, перемещающий operator=).

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

(разве что в Си++ будут описаны конструктор копирования, конструктор перемещения, перемещающий operator=).

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

Forum0888
()
Последнее исправление: Forum0888 (всего исправлений: 4)
Ответ на: комментарий от zx_gamer

Пост не о классах был, а о том «Где просто, там ангелов со сто. Где мудрено, там ни одного.».
ИМХО ООП раньше использовал, а ныне нет.
Возможно и имеются задачи в которых его полезно использовать, но все же пожалуй «мне туда не надо.».
В многих задачах используется понятие «объект».
ООП является лишь одной из возможных реализаций API для работы с ними.

Forum0888
()
Последнее исправление: Forum0888 (всего исправлений: 3)
Ответ на: комментарий от unC0Rr

На Haskell с наскоку не написать ничего толком, если не знаешь языка

Да в общем-то и зная тоже особо ничего напишешь (а то, что и написано - скорее вопреки, чем благодаря). Зато можно наяривать paper-ы про зигоморфизмы.

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

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

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

Абстрактные классы и структуры не в счет

Это ортогональное понятие к копированию не имеющее никакого отношения. И, на самом деле, Вы глубоко заблуждаетесь: подавляющее число классов со сколь-нибудь сложным состоянием намеренно делают non-copyable, и даже не потому что их нельзя скопировать чисто технически, а потому что если Вам приходится их копировать Вы что-то делаете не так.

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

ээээ ровно для того для чего в том же питоне есть либы позволяющие глубокое распараллеливание переносом на gpu

в целом векторизация эт же simd как он есть

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

qulinxao3 ★★
()

Забавное дело. Переписал я на Rust часть проекта, всё нравится, провёл кучу экспериментов и улучшений кода, дошло дело до оптимизации.

Оптимизировал насколько это возможно - всё упирается в скорость обращения к памяти и распараллеливание улучшений не даёт. Но хочется быстрее и задумал я попробовать Cuda. Давно хотел её освоить, да задачи подходящей не было. А тут прямо самое оно, задача в самую точку - мякотка. И тут я понимаю что Cuda на Rust, это слишком узкий опыт, который я не хочу получать. Да и взаимодействие с OpenGL там пока не запилено, а оно мне с прицелом на будущее пригодится.

Так что погнал я переписывать всё на Си…

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

Кстати на CUDA экран 1920x1080 рендерится в 15 мс из которых 10 мс - копирование с видеокарты обратно на компьютер. На процессоре тот же алгоритм отрабатывает за 240 мс. Загвоздка только в инициализации вычислений - это занимает 400 мс. Но для игры, где текстур надо будет загрузить много и их можно не загружать в память компьютера получится ускорение до 50 раз!

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

Вообще склоняюсь к тому что библиотеку потенциально широкого применения сделать на Си, а уж для приложения можно и возможности С++ использовать..

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

я книжки не читаю. но знаю что они есть.

если вкраце - неймспейсы, нормальные классы, RAII, темплейты(если использовать их без угара), кое-что полезное в системной библиотеке. текстовый код компактней, при том же качестве бинарного кода.

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

Не только.
Например рефакторинг freetype и SDL для использования ними едиными
названиями кроссплаформенными (не просто названиями) базовых типов данных (очень удобно).

Много чего, но бодягу разводить не буду.

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