Ремесло программиста

Объявление

форум на движке phpBB доступен для тестирования
www.strategia.space
www.strategia.space/forum/
по предложению Лиса - канал на Matrix - #remdev:matrix.org

Информация о пользователе

Привет, Гость! Войдите или зарегистрируйтесь.


Вы здесь » Ремесло программиста » Яр » Возможный перезапуск проекта "Яр"


Возможный перезапуск проекта "Яр"

Сообщений 1 страница 30 из 31

1

Платформа CL разочаровала. Что осталось?

Oberon (BBCB) - идеален в плане горячей замены, есть сообщество в России, есть даже русифицированная версия. Достаточно простой и маленький, чтобы ворочать в одно лицо. Есть кроссплатформенный гуй (по слухам, хотя WinE - это та ещё кака, но говорят, нативный тоже уже допилили). Нормально спроектирован - статическая типизация позволяет делать код быстрым. Есть корутины, есть сборка мусора (кривоватая).

LuaJit - достаточно быстр. Нет корутин. Есть сомнения в целесообразности - всё же это интерпретатор. Хотя такой интерпретатор, который иногда быстрее Си.

Tcl - прекрасен, но медленный. Корутины есть. Есть врождённый кросс-платформенный гуй. Собирается быстро, объём умеренный. Всё же впиливать в него работу с двоичным кодом придётся полностью с нуля. Почти никому не нужен.

v8 - скорее всего, не удастся менять его на уровне генератора машинного кода, т.к. он сложный. Язык плохой, его нельзя эффективно компилировать. Написан на ещё более плохом С++. Зато очень популярный. Есть гуй, если считать за таковой веб или электрон. Есть развитые средства метапрограммирования (babel, typescript и т.п.)

golang - всё же великоват на мой взгляд, да и ругают его. Сектой называют.

На самом деле, я уже почти выбрал Оберон, потому что ни на что иное сил не хватит точно. Но можно попробовать меня разубедить :)

Отредактировано budden (2018-09-19 23:26:02)

2

А, да, и кстати, чтобы вы знали моё мнение.

FreePascal я никогда не возьму из-за GPL, и ни к какому Алфору, который на него завязан, и близко не подойду. И он устарел (нет корутин, насчёт лямбд не знаю, но в Дельфи они недавно появились). Но даже если не устарел, то это неважно. Лицензии достаточно.  Java, Питон, Си, С++, 1Скрипт - это вообще полное Г. Насчёт .net core есть некие сомнения - может быть, есть смысл. Но скорее всего, ООП всё убило.

Отредактировано budden (2018-09-19 23:32:14)

3

FreePascal я никогда не возьму из-за GPL

А что там не так?

4

Есть такое понятие - вирусная лицензия.

5

budden написал(а):

FreePascal я никогда не возьму из-за GPL, и ни к какому Алфору, который на него завязан, и близко не подойду.

Он не завязан на него. Первично вообще на C#, ну и в разные другие компилицию автор добавлял для переносимости ПО.
Алфор исходники FreePascal и других вариантов языков/библиотек сборки никак не изменяет, получается, у него с такой лицензией трудностей вообще нет.
К тому же он как автор поддерживает KOL и, смотрю, документирует перевод проектов с него на AL-IV.
FreePascal и так по сути единственный вариант на что возможен непосредственный перенос проектов с Делфи. Многие давно так поступили.
Не, можно даже на Java, правда, трудозатраты вырастут в разы.

Java, Питон, Си, С++, 1Скрипт - это вообще полное Г

И у него там тоже разные притязания к ним написаны.
Медленные, в т.ч. вариант на С++ оказался медленнее FreePascal по скорости исполнения, не говоря уже про время сборки,  wxWidgets тормозит, а у Qt плохая лицензия.
У Питона помимо низкого быстродействия плохо с доками и поддержка разных возможностей отнимает слишком много времени.
Для оценки нужно изучение исходников. Сам по себе AL-IV даёт неплохое сравнение стеков конечной сборки.

Оберон, потому что ни на что иное сил не хватит точно

Оберон вполне себе подходящая игрушка для этого. Тот же Глагол это вариант его русификации с некоторыми изменениями и сделан всего одним человеком.
И помимо этого у них на сайте было обсуждение русификации для школы.
Но по возможностям взаимодействия с внешним миром там вроде совсем бедно.

6

> Он не завязан на него.
Это в теории. А на практике, как я понял, поддержка иных технологий, кроме Паскаля, сейчас отсутствует. Когда язык multi-target, нужно, чтобы у него хотя бы один Target совмещал все его возможности, иначе список возможностей становится неполным.

Далее, я всецело за то, чтобы патчить компиляторы. Во FreePascal нет корутин (я сегодня проверил, если не прав - прошу поправить). Это значит, что патчить компилятор придётся. Для горячей замены тоже компилятор нужно менять.  И для интроспекции (например, для GC). Зачем брать FreePascal и вкладывать большой труд в GPL, когда есть пермиссивно лицензированные Golang, javascript-ы, Oberon. Далее, вопрос о лицензии на компилятор не так-то прост. Для gcc может получиться так, что программа таки подпцепит GPL. Этот вопрос разбирался, но я так понял, его просто решили замять и никому ничего не предъявлять. Но зачем мне это?

7

Кроме того, я же прекрасно помню, как мы обсуждали вопрос про эффективность работы Алфора с памятью и я нашёл там косяк, который может приводить к медленной работе (точно не помню, но это что-то из серии хранения списка объектов, ссылающихся на данный, что весьма сомнительно как общее решение для управления ссылками и памятью). Вы лишь написали о моей некомпетентности, я прекрасно это помню, но ответа по существу так и не поступило. Т.е. с технической точки зрения Алфор мне неинтересен и по этой причине тоже. Если команда авторов и доброжелателей Алфора хотя бы удосужится отвечать на вопросы, а не обзывать задающих, тогда можно будет подумать об изменении своего отношения к этому проекту. Далее, горячая замена кода при многоэтажной компиляции, которую реализует Алфор, крайне затруднительна - компилятор находится в среде ОС и связанные  с этим настройки заведомо хрупкие. но я уже видел CL и Оберон с компиляторами на борту и линковкой образов не выходя из программы. Ни один бекенд алфора этого предложить не может.

Отредактировано budden (2018-09-20 22:38:37)

8

А Оберон - да, потенциально он хорош. Но инженерный подход Вирта, делать всё маленьким и простым даже в ущерб качеству И ПРАВИЛЬНОСТИ, меня сильно волнует. Видимо, там придётся переписывать абсолютно всё. Шансы на успех здесь есть только по той причине, что проект достаточно компактный и ключевые решения приняты правильно (стат. типизация, сборка мусора, компилятор на борту).

Отредактировано budden (2018-09-20 22:45:53)

9

Во FreePascal нет корутин (я сегодня проверил, если не прав - прошу поправить).

Официально нет, но есть костыли. Самый адекватный у Лазаруса. Разбрасывает на ядра процессора.

Отредактировано utkin (2018-09-20 22:42:48)

10

http://wiki.freepascal.org/Microthreading - если речь об этом, то их скорее нет. Но даже если они и были бы, всё равно вопрос лицензии перевешивает. Он не лучше голанга (в котором тоже корутины, тоже быстрый компилятор среднего качества, простой язык и нет ООП, которое есть ошибка).

11

Т.е. если оберон испарится, следующим я попробую голанг. А FPC я попробую не раньше, чем появится пролив им. тов. Сталина, который сделает вопросы американских лицензий, в т.ч .GPL,  неактуальными.

12

если речь об этом, то их скорее нет.

http://www.festra.com/wwwboard/messages/12899.html
Касательно самих микротрендингов - мельком глянул - скорее они есть, чем нет. Там приличные классы.

Отредактировано utkin (2018-09-20 22:45:25)

13

utkin написал(а):

Разбрасывает на ядра процессора.

Правильные корутины должны быть ортогональны числу ядер. Но не суть, всё равно FPC - это без меня.

Отредактировано budden (2018-09-20 22:45:28)

14

Правильные корутины должны быть ортогональны числу ядер.

Они там ортогональные, если Вы вручную не начнете там управлять. Там есть функция определения числа ядер в процессоре. Как я понял из описания код не может определить физические это ядра или эмулируемые, но в целом это уже не важно в данном случае.

15

budden написал(а):

например, для GC

GC там не нужен и деструкторы тоже.

поддержка иных технологий, кроме Паскаля, сейчас отсутствует

Вообще-то исходно C#. Ну что вы все выдумываете?

Поддержка компиляции в языки программирования C++, Java, Python приостановлена. Предыдущая версия 0.90.8 будет оставаться доступной для скачивания;

Ну пупец, автор не занимается теми пару месяцев (потому что нужен выбор, нужны решения или другие приоритеты) и уже говорите, что не поддерживается.
А пару месяцев до этого он добавлял компиляцию в Python. Самые последние версии это как правило эксперименты. Вся история написана на оф. сайте.
И там  давным давно были снимки с OpenGL под C#|++|Delphi|Java.

budden написал(а):

Далее, я всецело за то, чтобы патчить компиляторы.

Это кривая и вообще чужая дорога. А с Вашими требованиями к лицензиям ещё и противоречивая.

Зачем брать FreePascal и вкладывать большой труд в GPL, когда есть пермиссивно лицензированные Golang, javascript-ы, Oberon.

Непосредственно AL-IV не вкладывается туда. Зачем это нужно?

Ни один бекенд алфора этого предложить не может.

Python позволяет без компиляции. Это раз. Во-вторых, она небезопасна, не говоря уже про то, для чего она нужна и откуда у неё растут ноги.

budden написал(а):

Вы лишь написали о моей некомпетентности, я прекрасно это помню, но ответа по существу так и не поступило.

Потому что в вики для каждой базовой структуры данных указана асимптотика.
Одно дело - вопросы по существу, другое дело про базовые знания. И вот представляете, Вы такой приходите и задаёте про массивы вопросы первого курса проф. спец-ти, которые гуглятся на раз-два, или которые являются открытыми научными проблемами. Но не к преподу, а к обычному занятОму спец-ту, который не Ваш коллега, ни нач-к и не подчинённый, но Вы хотите от него внимания, которого он Вам ни разу не предлагал. Док-ция по боку и вообще вопросы о чём-то своём.
Например, т-щ Джавадов не компетентен в мат. части, о чём даже говорит открыто. Итог -  в своём теоретическом идеале занимается решением выдуманной им же самим якобы проблемы других языков:
http://plana.mybb.ru/viewtopic.php?id=596#p2517
Utkin не замечает теорию графов и делает сугубо ограниченное средство - редактор дерева. А до этого у него возникли нестыковки с теорией в "универсализации синтаксиса", хотя его предупреждали.
Каждая такая оценка/предупреждение/замечание - вообще-то вполне инженерная и м.б. даже трудоёмкая работа.
То что Вы хотите - горячая замена кода, типизация и сборка мусора - не то чтобы взаимоисключающие требования, но цели, которые они достигают по измерению быстродействия и надёжности м.б. противоположны.
Если Вам интересно управление временем жизни объектов по их владению - см.  доки AL-IV непосредственно или гуглите  Rust (язык программирования) или ещё что-то.

16

>  Ну что вы все выдумываете?
Возможно, я что-то не заметил. Если там есть поддержка C# - то и слава Богу.

> Вы такой приходите и задаёте про массивы вопросы первого курса
Это смотря куда прихожу и зачем. Например, в академию или в магазин.

> автор не занимается теми пару месяцев
Но динамика-то есть в сторону снижения поддержки разных языков. Будет другая динамика - будут и другие суждения.

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

17

Собственно, возвращаясь к вопросу Алфора. Если он завязан на C#, C, C++ или, не к ночи будь помянут, Питон, то это всё неинтересно и не утешает после FPC, даже .net core не утешает. Далее, если он был бы завязан, допустим, на платформу с GC, но при этом GC в нём недоступно, то это тоже не годится. Короче пока - никак не вижу, чтобы мои пути с Алфором хоть как-то могли пересечься.

18

budden написал(а):

Но динамика-то есть в сторону снижения поддержки разных языков.

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

budden написал(а):

Короче пока - никак не вижу, чтобы мои пути с Алфором хоть как-то могли пересечься.

Но подходы подобны - решение перебором :rolleyes:

19

Ну, если уж речь об этом, поддержка нескольких бекендов - это только для очень богатых. Потому что нужно затратить усилия по числу поддерживаемых бекендов, а гарантированно доступные возможности будут равны пересечению возможностей этих бекендов. При том, что обычно бекенды вообще не пересекаются. Достаточно взять хотя бы числовые типы данных и сразу всё окажется плохо. Попробуем пересечь tcl, lua и C - в пересечении как бы пустое множество не оказалось бы, с учётом того, что Си очень мало говорит о диапазонах целых, в tcl целые числа неограниченной точности (и как следствие, они живут на куче и невозможно понять, сколько памяти занимает число), а в lua нет плавающих. Другой вариант - делать числовые типы "какие получатся" - это настолько страшно, что лучше тогда вообще ничего не делать.

Отредактировано budden (2018-09-21 17:50:37)

20

А, нет, вру про lua.

21

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

22

При том, в наше время создание хоть минимально конкурентоспособного ЯП  находится, в принципе, за пределами хоббийных возможностей одиночки. Это нужно или несколько лет фулл-тайм (меня вот на год хватило, я шёл очень коротким путём и всё равно ещё год нужен был, как минимум), или команда. Или работать 5-10 лет. Даже для одного бекенда. Т.е. мне представляется, что команда AL-IV, если она состоит из 1-2 хоббийщиков, имеет все шансы надорваться.

23

Вопрос в том, нужно ли это самому человеку. Игрушка и средство для собственного труда - две совершенно разные штуки. А так почти у всех ЯП один автор,  ценитили приходят после.

budden написал(а):

Например, в академию или в магазин.

Езжайте! Да, когда свернете налево, ну вы-то направо, там проезд запрещен, обрыв. Но вам туда можно.

С. Альтов

24

Покопался ещё с Обероном. С помощью сообщества вроде сделал шрифты побольше - там нет масштабирования в среде, пришлось забить его гвоздями в исходном тексте. Правда, стало коряво.

25

Пока - тут: http://zx.oberon2.ru/go.htm?https://bit … ntbuilder/

26

Есть такое понятие - вирусная лицензия.

Специально посмотрел Free Pascal на гитхабе. Там  есть LGPL2, чем не компромисс?

27

LGPL - тоже вирусная, и через вставляемые компилятором артефакты (кусочки себя) может заразить и собранное приложение. Во всяком случае, производная работа (а именно в неё я собираюсь вкладывать значительные усилия) тоже будет под  LGPL. Кроме того, компонентный Паскаль намного интереснее "просто Паскаля". Сборка мусора - великая вещь.

Отредактировано budden (2018-10-08 00:44:54)

28

Завёл тему на своём форуме. Ссылка пока явно не нужна, ведь вверху появилась кнопочка "вече" - не знаю, кому и спасибо говорить.

Отредактировано budden (2018-10-08 14:09:29)

29

Сандро?

30

utkin написал(а):

Сандро?

- Да...


Вы здесь » Ремесло программиста » Яр » Возможный перезапуск проекта "Яр"