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)
Ответ на: комментарий от zx_gamer

Опираться на x86 нельзя.

у арм тоже вроде есть. точно не помню

alysnix ★★★
()
Ответ на: комментарий от 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)
Ответ на: комментарий от Forum0888

Я не видел ни одно класса, в котором бы не было конструктора копирования. Конструктор перемещения и перемещающий operator= есть везде, где C++11 или выше.

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

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

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

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

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

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

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

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

Битовый массив нужен затем чтобы делать не 64 проверки когда надо узнать есть ли общие единички, а всего лишь одну.

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

Я не видел ни одно класса, в котором бы не было конструктора копирования.

Сильно. А что имеется в виду? User-defined copy ctor? А как быть с intentionally non-copyable classes?

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

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

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

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

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

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

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

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

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

qulinxao3 ★★
()

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

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

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

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

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

еще_один_осознал.жпг

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

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

unDEFER ★★★★★
() автор топика

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

P.S. Сахар «Колокольчик» - юмора укольчик.

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

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

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

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

не так далеко осталось для решительного:

Так что погнал я переписывать всё на С++
alysnix ★★★
()
Ответ на: комментарий от alysnix

Оно у меня на C, но для видеокарты тот же код компилируется как C++.

И я просто чешу репу стоит ли использовать возможности C++, и если да, то какие?

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

И я просто чешу репу стоит ли использовать возможности C++, и если да, то какие?

про это книжки пишут. а повторяться не хочется.

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

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

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

Дружище, попробуй SDL перевести на C++ и поймешь, чем отличаются.
У меня три дня ушло (один день правда банально ступил).

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

Не понимаю о чём вы. У популярных проектов я смотрел исходники, знаю на чём они. А причём здесь SDL?

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

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

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

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

Не понимаю о чём вы.

О том, что на Си можно реализовать любые алгоритмы (и на C++ конечно можно).
Си и C++ ИМХО хороши для системной разработки (API, ...).

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

Это всё хорошо. Список я знаю. Я не решил пока какие из этих возможностей стоит использовать.

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

Я так и не понял. Вы C++ binding создали для SDL за 3 дня или просто заинклудить sdl в C++ такие проблемы?

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

Ну как сказать? Из библиотек я использую только системные и SDL. С ними вопросов нет, а вот с ЯП вопросы.

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

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

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

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

Да как вы так умудряетесь? Вроде и ответить на вопрос, а всё равно ничего не понятно.

unDEFER ★★★★★
() автор топика
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.