Мои проги на PureBasic

Где и в какой момент я обязан согласиться с эулой, запрещающей реверсить файл в формате chm?

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

Статья 1280
…
«информация, полученная в результате декомпилирования, может использоваться лишь для достижения способности к взаимодействию независимо разработанной программы для ЭВМ с другими программами, не может передаваться иным лицам, за исключением случаев, когда это необходимо для достижения способности к взаимодействию независимо разработанной программы для ЭВМ с другими программами, а также не может использоваться для разработки программы для ЭВМ, по своему виду существенно схожей с декомпилируемой программой для ЭВМ, или для осуществления другого действия, нарушающего исключительное право на программу для ЭВМ. »

И это ещё в том случае, если лицензия была получена. А если нет?

И это ещё в том случае, если лицензия была получена. А если нет?

В случае форматов файла, в том числе chm, лицензия на что конкретно должна была быть получена? И о декомпиляции какой конкретно программы в этом случае ты говоришь?

А, вспомнил, троллинг тупостью – твой способ общения. Ты понимаешь смысл процитированного закона и словосочетания «декомпиляция»?

Это проблемы не-Си программистов. Си-программистам всё понятно и = с == они не путают. А возможность присваивать внутри if - прекрасна и даёт языку дополнительную «выразительность», для тех, кто не страдает фобиями на этот счёт. Что же касается опечаток, то так можно и x вместо y где-нить написать и на этом основании тоже что-нить обвинить.

kb.fileformat.app

а можно ссылку на что-то официальное, а не на мухосранск и забор?

Если не KDE, то есть xchm. Но как и с любым мелкомягким форматом, порой работает через одно место…

Это безусловно справедливо для классического бейсика с номерами строк, GOTO и GOSUB…но именно тогда я сделал вывод «пора валить». :)

Скажем так, FORTRAN, идеями которого питались при создании BASIC, в то время выглядел примерно также и даже страшнее с его форматом записи программы, пошедшем от перфокарт. Потом по этому поводу возникла такая пословица у программистов: «На любом языке программирования можно писать как на FORTRAN».

На сколько я понял в asm все эти инстр укции - циклы, условия, выбор превращаются в goto. Если компилятор не сможет дать оптимизииованный код, то можно использовать goto. На форуме обсуждался этот вопрос, ограничивать себя нет смысла методом исключения этой возможности, просто надо знать где использовать.

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

На фортране, тем не менее, были хотя бы приличные SUBROUTINE.

Си-программистам всё понятно и = с == они не путают.

Ну ладно, определи тут ошибка или так и надо if( foo=bar() )

Отвечу примером из K&R:

while ((c = getchar()) != EOF) {
  putchar(c);
}

Есть ли тут ошибка? Ответ: если не запутался в трëх соснах скобках, то так писать можно. Читаемость, конечно, так себе, как раз-таки из-за обилия скобок.

А твоëм примере это может быть и ошибкой, если нужно не получить значение из функции в переменную, а потом проверить условие на ненулевое значение переменной, а именно сравнить значение переменной с результатом работы функции.

Это проблемы не-Си программистов. Си-программистам всё понятно и = с == они не путают.

Неплохо если бы в C и C++ запретили использовать в if «=».

И носило меня, как осенний листок.
Я менял языки, менял города.
Надышался я пылью заморских ЯП,
Где не пахнут цветы, не светила луна.
И выбрал PicBasic и Rust.

Определи, есть ли тут ошибка:

x = y + 5;

А вдруг тут должно было быть не x а z? А вдруг не y а j? а вдруг не 5 а 10? А вдруг не плюс а минус?

Твой вопрос из той же серии. Разумеется, без контекста оценить правильность одной строчки невозможно.

Читаемость, конечно, так себе, как раз-таки из-за обилия скобок.

Читаемость улучшается так:

while((c=getchar()) != EOF) {

Набор утилит интересный. Вспоминая себя, тоже писал подобное на C++, Pascal, Delphi, asm. Многое сохранилось.

З.Ы. Консольный Расчет Трансформатора на Turbo Pascal писал. )

Неплохо если бы в C и C++ запретили использовать в if «=».

Компиляторы нынче умные пошли, и на такой подозрительный код кидают ошибку (warning). Даже с рекомендацией как ее исправить. И даже на вот такой код

if(x==1)x=2; y=3; z=4;

В Python вообще любят такие вещи:

print(*sorted(set(map(int,input().split())).difference(set(map(int,input().split())))))

У них еще и «моржовый оператор» есть для таких случаев. Вот, уроды. А потом, без «unit test» никуда

Правильно любят, если оно на самом деле так. Ещё бы set(map(…)) из твоего примера вынести отдельно(если язык позволяет) - и совсем хорошо было бы.

Так есть уже такая сишка - называется руст. Запрещено и не только это.

Наговор. Ни в одной серьёзной кодовой базе подобного не видел. Не говоря уж о том, что map давно считается устаревшим и вместо него предлагается использовать более читаемые list comprehensions.

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

Компиляторы нынче умные пошли, и на такой подозрительный код кидают ошибку (warning).

Лучше бы они отпечатки пальцев программистов снимали и плохим говорили - «Ты кто такой? Досвидание.».

Я смотрю вы - ярый противник функционального программирования? А в таких языках как Python, R, функциональщина - один из способов увеличить производительность, так как выполняется скомпилированный на С код библиотек, а не интерпретируемые операции Python и R.

Если бы пайтон был встроен в Windows и Android, то можно было бы и с ним помучится. А он на каждый чих тянет с собой несколько мегабайт библиотек.

а не интерпретируемые операции Python и R

Как работает цикл? Разве он не интерпретирует имена функций? Да так почти все интерпретируемые языки работают. Тот же AutoIt3, я тоже всем рассказываю, что он вызывает функции написанные на языке С++. И там тоже есть обфускация, то есть инструмент, который преобразует имена функций и переменных в минималистические короткие однобуквенные, но после использования всех однобуквенных начинают использоваться двубуквенные и т.д. в зависимости от числа функций и переменных. Но это всё равно интерпретация, распознавание кода, связывание имен с указателями. Пишем цикл для GUI и он на протяжении всей работы интерпретирует конструкцию. Ну да, многие считают если код не напрягает проц и не создаёт задержки, то не обязательно его вылизывать по скорости.

По-моему, здесь спутаны термины. Процедурное программирование с функциональным. Функциональное программирование - это Lisp, Scala, Haskell, и т.д.

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

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

Блин, ностальджи. Я на первом курсе универа тоже такое на Делфях/Лазарусе клепал, правда, не выкладывал никуда. Хотя, калькулятор всякого в комплексной форме для WinCE на 4pda какое-то время висел. Мне как раз на электротехнику было надо.

По-моему, здесь спутаны термины. Процедурное программирование с функциональным. Функциональное программирование - это Lisp, Scala, Haskell, и т.д.

Функциональное программирование - это концепция с разной степенью полноты, реализованная в разных языках, в том числе и в Python.

В языках Python и R - это

1. Конвейер вызова функций.
2. Лямбда-функции (короткие анонимные функции).
3. Функции высшего порядка (функции, принимающие другие функции)
4. Замыкания и Декораторы (когда функция «запоминает» свое окружение в перерывах между вызовами).
5. Каррирорование.
6. Рекурсия.
7. Работа с коллекциями.
8. Работа с неизменямыми типами (str) и т.д.

На увеличиние скорости через скомпилированный на C код, стиль написания, по-моему, слабо влияет

Насчет скорости, так как Python и особенно R очень не быстрые интерпретируемые языки, то писать циклы на них для обработки коллекций - достаточно затратные операции. Лучше найти подходящую функцию из ядра этих языков или подключаемых модулей или библитотек, где все написано на С/С++,Fortran или сейчас Rust еще подтянулся. И эта скомпилированная функция выполнит операции над миллионами элементов переданной коллекций намного быстрее. Конечно для 1,2,10 элементов это не критично, но для большого кол-ва - вполне себе выгода ощущается. В моем примере это была функция map, которая преобразовывала строки в целые числа.

Лучше найти подходящую функцию из ядра этих языков или подключаемых модулей или библитотек, где все написано на С/С++,Fortran или сейчас Rust еще подтянулся. И эта скомпилированная функция выполнит операции над миллионами элементов переданной коллекций намного быстрее.

Ну, это да, но я не уверен, что это прям часть функционального программирования.

И далеко не во всех задачах можно так удачно ускориться.

Например, у меня на прошлой работе типичная задача (прям, как из мема про перекладывание json’ов в json’ы): получить json с идентификаторами объектов из одного сервиса, пройти по списку, дообогатить каждый идентификатор связанными данными из базы, сгенерировать и отдать json на выход.

Тут самые тяжёлые операции по затратам времени при профилировании были: парсинг и генерация json (использовался встроенный модуль json - он хоть и написан на C, но чудовищно неэффективный по сравнению с orjson, msgpack, simdjson, когда счёт идёт на миллисекунды), и хождение в базу за данными, которые требуются для дообогащения - не ускоришь практически никак, да и большая часть времени теряется не в Python, а в round-trip’ах хождений в БД по сети.

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

Но большинство веб-разработчиков занимаются совсем не этим. И тут ускорить радикально становится сложнее. Не знаю, как тут поможет функциональное программирование. В частности, даже при вынесении части функциональности в модуль на C или Rust, появляются большие накладные расходы на преобразование типов Python в типы C/Rust, а затем на обратное преобразование. Когда занимаешься математикой, то видимо всё проще: можно запустить C-шный код сразу работать над массивом из миллиона элементов. Да ещё и придумать хитрые трюки, чтобы не преобразовывать их каждый раз туда-обратно, т.к. это просто числа.

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

Если бы пайтон был встроен в Windows и Android, то можно было бы и с ним помучится.

Отсутствие встроенного в Windows PureBasic вам же не помешало его установить и использовать. Аналогично и с Python, который очень просто скачивается и ставится, да к тому же в отличие от PureBasic еще и бесплатен.

А интерпретаторы Python, возможно, есть для каждой ОС, и даже для работы на «голом железе» - microPython.

Но Python действительно «медленный» при исполнении программ язык - интерпретатор с динамической типизацией и отсутствием нормальной многопоточности. При этом, по моим ощущениям, на Windows он работает медленнее чем на Linux.

Когда я его начал изучать, так как он применяется почти во всех сферах разработки, в том числе и в моей области - обработка данных, то я сначала плевался с его и его концепций, и не верьте тем, кто говорит, что это простой язык - нет, не простой, на нем просто начать писать всякие «Hello, World», а потом надо вникать во внутренние структуры, механизмы и хаки, чтобы программы «не тупили».

На Python достаточно быстро разрабатывать, прототипировать, делать MVP. Иногда на этом и можно остановится, так как под Python написана куча библиотек на C/C++ и Fortran, испольуя которые программы на Python в общем-то имеют приемлемую скорость работы. То есть, если делать аналогию с автомобилем, Python - это салон автомобиля с удобными, мягкими сидушками, кожанным рулем переключалкой, тормозом и т.д., а Движок авто - это скомпилированные библиотеки С++, которым управляют из салона-Python.

Если прототип на Python не удовлетворяет по скорости, то его переписывают на каком-то из компиляторов C++, Rust, Go, и даже Mojo (кмпилируемый язык с Python-подобным синтаксисом, который может использовать и программы на Python)…

И самый большой плюс Python - он самый популярный язык и по нему много работы.

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

Кроме того, начиная с 3.11 Python сильно ускорили, и эта работа продолжается до сих пор. В частности, работают над JIT компилятором, да и по другим направлениям стараются ускорить.

И в целом… Скорость исполнения Python, по моему опыту, довольно редко становится непреодолимым препятствием. В 95% случаев применения, её вполне достаточно даже в Highload (как примеры - YouTube, Instagram, и другие). Гораздо сложнее придумать масштабируемую архитектуру, потому что в реальном Highload затыки часто не из-за того, что какая-то ручка медленно работает, а в том, что вся система в целом медленно работает, например, нет возможности ускорить получение данных из СУБД - и тут хоть на ассемблере код ручки пиши - ничего не решит.

Производительность имеет значение только как метрика всей системы в целом. Нет смысла оптимизировать 100% системы, если тормозит 20%, и эти 20% могут быть совсем не в Python.

Производительность имеет значение только как метрика всей системы в целом. Нет смысла оптимизировать 100% системы, если тормозит 20%, и эти 20% могут быть совсем не в Python.

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

Почему всё так?

ЛЕНЬ.
ЖДУТ ХАЛЯВЫ.

Кстати даже хорошие проекты трудно отнести к хорошим системным разработкам, потому что API разрабатывается «под проект» и для других он мёртв.

При чём здесь лень?

Создать универсальный проект, который удовлетворит потребности всех, чертовски сложно:

1. Это удлиняет и усложняет разработку многократно
2. Это превращает проект в огромную кашу с кучей ручек управления под все гипотетически возможные потребности

По опыту работы с библиотеками/фреймворками, авторы которых пытались угодить под любые потребности: оно либо всё равно неудобное, потому что всё не учтёшь, либо безумно тормозное, т.к. супер-универсальное решение всегда менее эффективно, чем заточенное под узкую задачу. Впрочем, чаще всего, оно представляет собой комбинацию обоих недостатков.

Халява тут особо не при чём.

ИМХО ныне весьма актуальна разработка хороших кроссплатформенных библиотек.
Но лишь хороших.

В некоторых тредах об этом пишут.

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

Создать универсальный проект, который удовлетворит потребности всех, чертовски сложно:

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

Для ускорения есть PyPy - работает очень быстро.

Да в курсе, но там есть ограничение - используется не весь Python, а его подмножество. Также знаю и пробовал Numba, Nuitka.

Вторая млодость приходит …

Когда-то для СМ ЭВМ разработал возможность хранения текстов программ в простейшем хранилище данных.
Ныне веду разработку хранилища данных (любой сложности архитектуры) архитектуру которого для memory и хранения в файлах
может задать программист и конечно модифицировать в процессе потребностей хранения данных.
Весьма непростая задача, но у меня уже ранее разработана архитектура хранения любых данных.
Ныне не ломаю её, а добавляю новую функциональность.
Это API действительно устранит для проектов необходимость в создании велосипедов хранения данных.
Кстати у той же Microsoft архитектура хранения данных весьма схожа с велосипед, велоспедом погоняемая.

Да в курсе, но там есть ограничение - используется не весь Python, а его подмножество. Также знаю и пробовал Numba, Nuitka.

В PyPy весь Python, он на 100% совместим с CPython. Несовместимы только некоторые расширения.

О каких данных речь?
Всё что угодно (в т.ч. конечно создание разного рода СУБД).

Обязательно сделаю конвертов для некоторых типов графических и книг, … в свой формат данных.
В чём профит?
Единый API для работы с данными, а не куча велосипедов.
Кстати весьма тривиально многие форматы данных при необходимости возможно будет и расширить.

Собственно о такого рода системного API ранее были посты, а
«Кто выще бье, тот краще грает» - «не очень».

Не претендую, что это панацея, но пока API для работы с данными весьма эффективно и просто в использовании.

В частности для XML уже давно сделал конвертер в свой формат представления данных.

Да его и нет вовсе!

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

В чём профит?

Стыдно даже и объяснять …

вот понимаешь центральный вопрос всегда не «сколько жрет?» а «какая от него польза?»

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

а польза от нее - примерно 3-5 литров молока и ценный навоз для огородов некоторые еще пух вычесывают и свитера вяжут

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

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

поэтому если от ИИ польза есть - будем кормить электричеством >сколько попросит а если нету - скажем «прощай наш железный друг!» и все дела

вот понимаешь
центральная программа всегда не «сколько жрет?»
а «какая от неё польза всегда?»

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

а польза от программы - примерно 3-5 гигов памяти сожрать
и ценный навоз для форумов принесть
некоторые еще флуд вычесывают и топики стригут

и если тебя устраивает ценная программа - ей быть!
а если не устраивает - все ее перечисленные достоинства роялей не играют, совсем
даже если она сядет на диету и начнет память жрать как ящерица

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

поэтому если от ИИ польза есть - будем кормить электричеством сколько попросит
а если нету - скажем «Ты кто такой? Давай досвидание.»
и все дела

Отсутствие встроенного в Windows PureBasic вам же не помешало его установить и использовать

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

есть Nim (бывший Nimrod) у которого синтаксис типа питона, семантика нечто среднее между турбо паскалем и С++, и притом оно конпелируется через сишечку с более минималистичным рантаймом.

ещё есть RED который конпелируемый REBOL. там тоже всё довольно минималистично.

а вот недавно книжку Book of Shen перечитывал про лисп Shen поверх кучи разных других движков – типизированный лисп с прологом, Yacc парсером и рядом прочих ништяков. там тоже прикольно.