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


Стандарты EcmaScript утверждаются по следующей схеме: 2000й год, заказчица Маша, которая ничего не знает и не понимает в программировании, приходит к разработчику Васе и говорит "хочу сайт, на котором отображается моя коллекция котиков и чтобы при клике на котике он мяукал, махал хвостиком и следил глазами за мышкой". Вася садится, чешет репу и думает, а как ему вставить звук на сайт, а как следить за мышкой, а как потом рисовать кота, который машет хвостом да еще глазами вращает. В итоге после штурма интернетов и десятков вопросов на проф форумах вида: а как лучше воспроизвести звук, а как нарисовать анимацию хвоста, а как поворачивать объекты в зависимости от положения курсора, он понимает, что с этим всем геморроится на JS+HTML это лютый трешь и проще налабать все на Flash и вставить на сайт в виде объекта. И вот таких Васей набирается 10-100-1000-10000 по мере выхода в сеть все больше вот таких Маш. И только после этого садится рабочая группа EcmaScript и принимает стандарты по API работы со звуком, с изображениями, с графикой, а параллельно им садится рабочая группа по HTML5 и выпускает теги audio, video, canvas и другие. Вся разработка идет от потребности конечного пользователя, а вовсе не от удобства разработчиков. Да, отдельные вещи в стандарт добавляют чисто для разработчиков, но двигателем всего этого являются Маши со своими котами. И так везде.


Тут не поспоришь.


Лучше даже не начинать обсуждение, если вы в каждом вопросе исходите из того, к чему лично вы привыкли или что лично вы используете. Получится как в той самой басне Крылова про лебедя, рака и щуку, когда каждый будет отстаивать свой язык или фреймворк. Если вы делаете что-то для людей, то вы должны мыслить как инженер, т.е. к задачам подбирать инструменты, а не наоборот - имея инструменты, думать какие задачи ими можно решить, а какие нет. Языки семейства Pascal остались давно уже популярными только в академических кругах и среди тех людей, которые так и не смогли изучить ничего нового с начала нулевых.



Это рейтинг от GitHub по популярности языков на 2020й - вы тут видите вообще хоть одну строку с языками данного семейства? И посмотрите, на каком месте стоит тот же JavaScript. А теперь ответьте вопрос - во сколько раз отличаются вероятности найти единомышленников при разработке среды на FreePascal и при разработке её на JavaScript/Java/C#?


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


Тут я с вами категорически не соглашусь хотя бы потому, что вы ставите в один ряд теплое и мягкое. Внешний вид Windows (как и любой другой ОС) это действительно следование моде. Но как вы сюда поставили "ПО в браузере" - совершенно не понятно. При чем тут мода вообще? Завтра что, мода поменяется и все с браузера перейдут... куда? На ПО мобильников? На ПО на компьютерах? У меня вариантов даже нет, что в ближайшем будущем измениться может.


Господа, не хочется ни с кем спорить, но и промолчать тяжело, когда делаются настолько очевидные ошибки в рассуждениях. Если вы хотите сделать хороший продукт, то нельзя в его основу закладывать полумертвые языки, аудитория которых стремится к нулю. Нельзя закладывать и фреймворки, поддержка которых остается под большим сомнением в будущем (как это было с KOL на Delphi). Нельзя исходить только из своих задач и делать только так, чтобы лично тебе было удобно. Нельзя делать ПО под одну конкретную платформу. Нельзя закрывать сообщество, а наоборот нужно расширять его и привлекать как можно больше молодежи. Нельзя начинать со спецификаций инструмента, если не понятно для чего этот инструмент в итоге вообще будут применяться. И наконец сразу следует метить продукт на Open Source и закладывать возможные варианты монетизации, если внешнего финансирования вдруг не хватит или сложность задач превысит свободное время энтузиастов.

Все эти ошибки можно было сделать в начале 2000х, когда размещение ПО на хостинге narod.ru считалось трендом, выбор у вас был только между Borland (Delphi/C++) и Visual Studio (Basic/C++), про Open Source никто не знал, Linux был ОС для гиков, самым крутым мобильником был Siemens, а монетизировать вы могли что-то только продажей CD со своим софтом на горбушке и аналогичных ему местах. Это время давно ушло, мир давно поменялся, сейчас другие стандартны, другие пользователи и другие задачи у них. Но и другие возможности конечно. Начинать нужно с понимания этого факта. А пока его нет и говорить тут не о чем.

Так нехватка читаемости схем в том числе стала двигателем затеи с созданием онлайн-конференции. Да, есть какие-то неудобства / отсутствие возможностей, как для разработчика пакета, в текущей версии HiAsm, но цель митингов именно в раздумьях "что сделать, чтобы схемы писались и читались лучше". Т.е. я не вижу какого-то однобокого взгляда на разработку спецификации. В первую очередь, приоритет на будущих ( ) программистах на HiAsm.

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

Редактировалось 1 раз(а), последний 2021-01-12 03:06:38

3 сообщения от Dilma и не одного ответа "Что будет с HiAsm в 2021 году?"

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

11 лет назад меня тошнило только одного вида яваскрипта и ничего с этого времени не изменилось, всё только подтвердилось, заселением блокнотов с хромо-костылём и "Машек" не в состояние сделать простое нативное консольное приложение. Не понимал я эту гонку за трендами тогда и не понимаю сегодня, те кто писал приложения на Symbian разве перестали это делать? Будущие я вижу в облаке, а там всё что угодно работает в том числе на паскале в windows xp.

Появление HiOn-a (замете после майнкрафта) я воспринимал исключительно как способ монетизации проекта (провальный), а не попытку сделать HiAsm next, по сей день я выбираю приложение которое создает иконку на рабочем столе, а не закладку в браузере

Вернёмся снова на 11 лет назад, в те времена далекий 2020(1) казался будущем в котором у нас будет HiAsm способный генерировать код на любой желанный ЯП. Собираем допустим свой первый винамп в 2011 компилируешь его в паскаль, тот же винамп в 2013 уже собирается в C#, в 2015 открывая туже схему из 2011 портируешь с небольшими особенностями в Android, и вот на дворе 2018 двигаясь но волне трендов снова портируешь свой винам весом в 500кб из 2011 в мультиплатформу, Android, iOS, Linux, Windows, Metro итд. За все эти годы каждый пакет эволюционировал вместе с HiAsm-ом элементы стандартизировались, собирая одну схему, запускаешь её на чем угодно, а вишенка на торте это сам HiAsm который сам себя собирает. Стандартизировать визуального отображения схемы помогло бы как автору пакета, так и пользователю пакета, сделать друг другу удобно. Как пример пакет C# бесспорно он хорош, но почему то мне удобно и привычно сделать тоже самое на Windows пакете и всё потому что я знаю где лежит А и Б и как их вместе соединять.

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

Редактировалось 4 раз(а), последний 2021-01-12 07:20:18

Разве формат хранения схемы не зависит от визуала? Под форматом я не имею ввиду JSON либо еще что-то, а именно описание сериализованных структур.
Или неужто какой-нибуть полиморфный контейнер можно было описать в sha в виде обычного MultiElement-a?

--- Добавлено в 2021-01-12 10:50:59

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

Редактировалось 3 раз(а), последний 2021-01-12 10:51:52

10-20-100-200 удаленных разработчиков по всему миру можно найти для любого проекта. Но только если этот проект будет популярен у пользователей. Если не будет популярен - большое количество разработчиков на C++ ничем не будет отличаться от меньшего количества на чем-то другом.

Вопрос языков и платформ - это то, что должно волновать разработчиков, а не конечных пользователей. Для конечного пользователя продукт должен выполнять его требования. Если избранный разработчиками (исходя из своих соображений) язык это выполняет - задача решена.

По поводу "зарабатывания денег на моде". Если Microsoft прекращает поддержку старых ОС, чтобы лучше продавались новые - мне это не нравится, но терпимо. А когда очередной Твиттер/Гугл/Фейсбук перестают работать в старом браузере, а новый браузер монополиста не работает в старой ОС (потому что он так захотел и потому что Microsoft прекратил поддержку) - это неприемлемо. В Фейсбуке не воспроизводится видео - мне надо поменять браузер. Чтобы поменять браузер - мне надо поменять ОС. Это неприемлемо. Потому что все вокруг хотят косить бабло.

Netspirit, мне даже и добавить нечего

Судя по описанию, для этого HiAsm 3 должен был уже иметь такой подход, какой я только выше предлагал исследовать - единая схема, отсутствие пакетов как класса, что уже, конечно же, было не так. Пакет Windows был гвоздями прибит в Delphi/Pascal + KOL. И никакая группа энтузиастов за вменяемое время не смогла бы реализовать мультиплатформу на базе прибитых гвоздями к конкретному языку и библиотеке компонентах. Так что, как мне видится, Winamp 2011 года на HiAsm 2011 года был обречен остаться в 2011 изначально в неизменном виде.

Что забавно, я бы такое сказал скорее про соседний форум minecraft Там сейчас частая тема "Прощай MCGL", "Я ухожу" и т.п. Тут как-то совсем не ощущается такая атмосфера. Возможно, из-за того, что актива людей сильно меньше.

ИМХО, все просто: много людей пользуются такими приложениями, а конкретно вы нет. Много людей разрабатывают быстро с помощью js, а вы нет. Много новичков быстро находят контрибьюторов и единомышленников, а вы нет. Современное (каким бы плохим оно не было) вытесняет старое (каким бы хорошим оно не было), а все цепляющиеся за старое остаются на отшибе истории. Хорошо ли это, плохо ли - это просто реальность. И если сравнивать шансы, то, конечно, на современных популярных инструментах сделать популярный продукт проще, быстрее и выгоднее, чем на чем-то сильно устаревшем, о чем и говорит статистика.

Чтобы продукт был популярен, продукт должен быть разработан (хоть минимально). Чтобы продукт был разработан, нужны разработчики. Колесо сансары сделало свой оборот. Для простоты допустим, что шанс найти разработчика в свой начинающийся проект = 0.1%. Хороших разработчиков на условном старом слабораспространенном языке Elphi по всему миру 1000 чел. Чтобы найти и договориться на собеседование с этими 1000 придется потратить уйму времени (наверняка большинство из них спокойно работают на своих местах и не желают ничего менять и даже не ищут альтернатив). Итого, ваш проект умер, еще не начав набирать популярность.
А теперь представим условный современный распространенный язык AvaCript. Только в вашем городе уже наберется 1000 хороших разработчиков, пишуших на нем. Найти их и договориться на собеседование получится уже гораздо быстрее, и даже если не найдется именно их, то точно найдутся куча джунов (иногда даже готовых работать за идею), которым можно поручить рутину, сосредоточившись на архитектуре. Итого, ваш продукт выходит на рынок, вытесняя недоделку на Elphi с полпинка.
Конечно, это все числа с потолка, но я пытался лишь передать масштаб, каким его вижу я.

То, что это неприятно и подбешивает - полностью согласен. Однако не вижу никаких различий в ваших же предложениях между "Прекращают поддержку ОС -> терпимо", "Прекращают поддержку браузера -> Полундра", кроме вывода. На мой взгляд предпосылки совершенно одинаковые, но отношение почему-то разное. И там и там прекращают поддерживать старое, но в одном случае это терпимо, а во втором - ужас. Хоть убей не понимаю. Для меня очевидно, что если хочешь оставаться на старой платформе из 2000, то изволь и софтом под эту платформу пользоваться из 2000, и не жалуйся, что в них нет фич из 2020. В конце концов, даже если это переводить в бабло, то на поддержку старых платформ тратится тем больше бабла, чем старее платформа и чем больше этих старых платформ накапливается. И рано или поздно такой бизнес просто умирает, оставляя пользователя вообще без софта. А на его место приходит новый софт, который гарантированно не поддерживает старую платформу (для реалистичности примера - вы ведь не собираетесь писать HiAsm Next с поддержкой запуска в DOS? Да даже хотя бы Windows 98 или Win ME)

Мне этот вопрос никто не задавал, чтобы отвечать на него.


Это наиболее объективная оценка, которую вы вообще сможете сделать сегодня. Если вы готовы предложить какую-то более релевантную - с удовольствием посмотрим.


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


Вы очень поверхностно владеете темой. JavaScript популярен не потому, что он в трендах, а потому, что весь вектор разработки ушел в WEB и мобильное направление, а в WEB до недавнего времени нельзя было писать ни на чем, кроме JavaScript и его популярность это следствие монополии и ничего больше, никакие тренды тут вообще ни при чем. Подождите еще 10-15 лет, когда Web Assemble выйдет на стадию рабочего инструмента и избавит web от монополии хотя бы частично, и вот только тогда говорите о трендах. Сейчас же вы сидите обсуждаете какой плохой или хороший JS, но скорей всего вы не понимаете и не осознаете какие фундаментальные причины явились следствием ухода пользователей и разработчиков в WEB и мобильные платформы. Вы сейчас выглядите точно так же, как те люди 40 лет назад, которые с пеной у рта доказывали, что GUI и вышедшая тогда Windows 3.11 никому не нужна и это пустая трата ресурсов компа. Команды и консоль это наше все, а ваши финтифлюшки никому не нужны и вообще тошнит от одного их вида Я уже молчу про тот знаменитый в последствии мем про 640Кб. Все это мы сто раз проходили уже.


Я не думаю, что есть смысл обсуждать будущее Pascal. Вы же прекрасно понимаете, что если язык устарел, то никакие облака его не спасут. Пройдет еще 20-40-60 лет, умрут последние хранители этого языка и он канет в лету. Я не припомню еще ни одного случая, когда полумертвый язык внезапно обретает популярность и бомбит на всех площадках.


Я выше же уже написал, что hion как продукт не завершен, он не предлагает никаких инструментов для выполнения конкретных задач. Более менее завершена среда, но в ней нет ни одного пакета, который что-то вменяемое позволяет делать. О какой монетизации там вообще речь-то идет? Вы ничего не путаете?


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


Конечно нет.


Лихо вы однако "ну только если"... А до этого "только если" вы что делать будете? В одни руки на паскале строчить? Не проще изначально взять язык, разработчики для которого ищутся без всяких "только если"?


Это так, но к вопросу какое это отношение имеет?


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


Это извечный спор, ему конца и края нет. Все таки вас никто не заставляет пользоваться Facebook, ровно как и Windows.


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

Я думаю нет смысла дальше особо спорить: те, кто хотят тянуть старое за уши и дальше будут тянуть его и никакие аргументы тут не помогут.

Редактировалось 2 раз(а), последний 2021-01-13 02:33:20

https://forum.hiasm.com/plan/


Dilma Что будет с HiAsm в 2021 году?

На Ваш ответ предусмотрел следующий вопрос:



Согласен. И странно звучит, но читая наш диалог, мне выглядит ситуация так, что есть атмосфера противостояния на счет внесения изменений в визуальный язык. И с какой-то причины, создатель языка является их противником

Редактировалось 1 раз(а), последний 2021-01-13 11:01:20

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

И на C собрали и на C#, да что-то разработчиков от этого не прибавилось.

sаmakacd, возможно я не совсем понимаю, о чем именно идет речь, говоря о зависимости формата хранения данных и их отображения на экране. Что я имею ввиду: вот есть у вас полиморфный контейнер, пусть в файле он хранится у нас как

PolyElement {
SubElementClass1 {
....
}
SubElementClass2 {
....
}
}

Т.е. мы создали полиморфный контейнер и в нем два наследники с разными классами SubElementClass1 и SubElementClass2. Вот это описание накладывает какие-то ограничения на то, как этот контейнер должен выглядеть в среде? Абсолютно нет. Вы можете отобразить его как вкладки:



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



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

Второй тип стандарта, потребность в котором стала очевидна, но который так и не успели реализовать - это стандарт на реализацию базовых элементов любого пакета. Что это значит? У нас в каждом пакете есть около сотни одинаковых элементов для работы с примитивами типа строк, матриц, массивов, чисел, потоками данных т.д. и вот все они по хорошему должны быть стандартизованы. Берем мы скажем элемент конкатенации строк и создаем стандарт: обязательное название элемента StrCat, он должен содержать один метод с названием doStrCat с произвольным количеством аргументов Str и одно событие с названием onResult. Так же в элементе должно быть свойство с названием Mask, которое представляет из себя строку, в которой все вхождения %Str№% заменяются на значения соответствующих аргументов. Жестко регламентировав таким образом базу вы добьетесь того, что большие куски всех схем будут переносимы без правок между пакетами и будут там совершенно правильно работать. Вот это и надо прорабатывать.


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


Noor, C++ это хороший вариант, однозначно лучше, чем Delphi. Однако использование в WEB все же выглядит более перспективным, потому что позволяет делать множество из тех вещей, которые в настольных приложениях сделать нельзя.


А кто-то этих разработчиков звал/искал? Или как вы себе этот процесс представляете - выкладываешь ты на условный github ПО на С++/C# и на следующий день у тебя 100 контрибьютеров, готовых каждый день по десятку пул реквестов слать с правками и доработками?

А почему должно было? Выше же правильно написали:

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