Как у вас, программистов, зарождаются проекты?

но… нифига! для ублажения своего эстетического вкуса это можно сделать. но остальной веб, с миллионами жутких генераторов флуда в сети, это никак не изменит.

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

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

значит ты в основном что-то там считаешь и соотв.автоматизируешь то что делаешь.

разводил-бы поросят - пришли бы идеи по автооткорму :-)

чем занимаешься по работе или хобби, про то идеи и приходят.

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

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

Пошучу

«С кем поведёшься, от того и наберёшься».

С кем поведёшься, от того и залетишь.

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

IPX кто-то помнит?

Как локальная сеть предприятия долгое долгое время работала.

И всё это в сочетании с Novell netware.

Для меня важен процесс. Например недавно потратил несколько дней на написание программы, которая при старте делает exit (3 машинных инструкции). Был очень доволен.

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

Я люблю писать программы, когда цели, как таковой, нет. Или она есть чисто в теории, но очевидно, что я её не достигну. К примеру у меня в планах написать программу, которая загружает данные в S3. Программа должна быть написана на C без зависимостей (включая libc). Это значит, что в ней должны быть реализованы: асинхронный ввод-вывод (для многопоточной загрузки больших объектов), криптографические алгоритмы и TLS протокол, HTTP протокол. В принципе объём тут на год работы и очевидно, что я это никогда не сделаю, запала у меня не хватит, но это не важно, важно получаемое удовольствие даже только от обдумывания и планирования такой задачи.

Звучит странно.

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

Немного о разработке.

У меня своё core, которое не имеет зависимостей к стороннему API и в добавок кроссплатформенно:

• динамическое управление объектами в run-time (в памяти и мета файлах);
• динамическое управление переменными в run-time;
• API, позволяющее использовать: деревья, списки, память, таблицы, строки, …

Расскажу немного о таблицах.
Строки таблиц могут содержать данные любых базовых типов и объекты.
При этом возможно в колонках строк можно использовать разного типа данные (например в первой строке первый элемент строка, а в следующей объект).
Возможно создание произвольного количества индексов для таблиц.
Таблицы также могут быть сохранены в мета файлах (любой сложности и иерархии).
Конечно работа с таблицами реализована весьма эффективно.
Например доли секунды требуются для создание таблицы, содержащей например миллион натуральных чисел, получения их суммы и удаления элементов в трёх циклах.
Конечно не панацея, но «Представляете как в таких условиях легко было работать?» (как говорил «папа» в фильме «Джентельмены удачи»).

А вот теперь спрошу вас.
В ныне разрабатываемых стандартах С++ такие возможности есть?
Сам и отвечу.
И близко нет.

И акцентирую то, что компиляторы при этом не при деле.
Стоят в сторонке, хмурятся и нервно кусают губы.

Пошучу о нынешних стандартах.

«Из C++ хотят сделать Python».
Цель вообщем-то интересная и возможно даже полезная, но зачем при этом усложнять синтаксис компилятора?
С виду всё выглядит «правильно» и якобы по другому никак.
Хотя конечно кое-какую функциональность в компиляторы и линкер следует добавить (но похоже этого никогда не будет).

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

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

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

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

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

Посмотреть не дам, это очень неаккуратная вещь, подражающая почтовому клиенту.

динамическое управление переменными в run-time;

Это очень плохо. Переменные должны быть статическими. Человечество не зря 50 лет шло к статической типизации.

API, позволяющее использовать: деревья, списки, память, таблицы, строки, …

Это есть в любом языке, включая C и Basic. Более того, львиная доля из этих структур данных на практике не пригождается. Нужны массивы и словари. Или даже гомогенная структура (ведь массив по сути такой же словарь).

Расскажу немного о таблицах.

Нужна поддержка SQL для запросов по таким таблицам. Причём интегрированного в языке в типизированном виде. Можно посмотреть, как это сделано в PL/SQL.

Строки таблиц могут содержать данные любых базовых типов и объекты.

Это очень плохо. Объекты поддерживать нельзя. Это лишнее. Таблица суть реляция, отношение. К объектам это не имеет отношения. Должны быть только данные базовых типов. Да и в целом ООП показало себя плохим подходом, от объектов лучше держаться подальше, включая терминологию.

При этом возможно в колонках строк можно использовать разного типа данные (например в первой строке первый элемент строка, а в следующей объект).

Это очень плохо. Должна быть строгая типизация.

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

Это очень долго. Например на Java такая операция выполняется за 2-3 миллисекунды. А ведь Java это не самый быстрый язык. Нужно оптимизировать скорость.

Это очень плохо. Должна быть строгая типизация.

Вам бы на какой-нибудь форум 1С зайти и сказать - «Ребята должна быть лишь строгая типизация и ни какой иной».
Мир алгоритмов весьма велик …

Это очень плохо. Должна быть строгая типизация.

Вам бы на какой-нибудь форум 1С зайти и сказать - «Ребята должна быть лишь строгая типизация и ни какой иной».

На мой взгляд до этой мысли доходит любой программист. Не раз видел, как те же программисты, выросшие на javascript, причём не просто выросшие, а поучаствовавшие в относительно нетривиальном проекте, потом участвуют в проекте с typescript и их мировоззрение прямо меняется. Когда они видят, сколько багов TypeScript ловит прямо в редакторе. Когда они осознают, что вот эту опечатку они бы ловили ещё час, а может быть и закоммитили бы с ней (особенно этим грешат ветки с обработкой ошибок, которые никто никогда не тестирует).

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

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

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

К примеру моё хоби по генеалогии, переросло в небольшой проект.

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

«И лучше выдумать не мог».

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

Прочитайте внимательно, то что в моём посте сказано.
Приведу copy/paste из него

И акцентирую то, что компиляторы при этом не при деле.
Стоят в сторонке, хмурятся и нервно кусают губы.

Можно динамически в run-time создавать объекты о которых компилятор ничего не знает и эффективно их использовать.
Это API можно использовать в любом ЯП.
Кроме этого поддержана возможность сохранения объектов в файлах (мета файлы) и использовать.
Например можете программно создать некоторое хранилище данных и сохранить в файле.
Это предоставит возможность использовать его в любых ЯП.

Core хранилища данных ныне разрабатываю.
В нём будет много полезных фич, которые упрощают разработку многих проектов.
Хранилище данных возможно использовать для разных потребностей:

• некая СУБД;
• хранилище каких-либо рессурсов;
• …

Затем первым делом разработаю локаль и произведу рефакторинг API.
Хранилища могут содержать множество объектов любой сложности и иерархии.

На мой взгляд до этой мысли доходит любой программист.

Контрпримеры: Smalltalk, Erlang. Позднее связывание позволяет менять систему на лету, что полезно по крайней мере для прототипирования.

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

Контрпримеры: Smalltalk, Erlang

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

Позднее связывание позволяет менять систему на лету, что полезно по крайней мере для прототипирования.

JVM позволяет менять систему на лету, не жертвуя типобезопасностью.

Erlang не промышленный

ясно.

Приведу пример того как это API ускоряет разработку.

Сегодня на habr опубликовали статью
https://habr.com/ru/articles/949036/ Почему памятники надо ставить тем, кто автоматизирует MS Word

Как у меня?

Даю на вход некоему алгоритму сначала како-то количество файлов типа xslx.
API анализирует их, сопостовляет архитектуру каждого из xlsx и формирует метаданные, которые позволят в память загрузить любой из
проанализированных xslx.
Затем программист может использовать всего лишь одну функцию для загрузки любого xlsx и работать с ним.
Вышеописанные действия пробовал использовать для анализа doc документов, генератора отчётов FastReport, ,,,
Всё корректно функционирует.

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

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

ИМХО вы сами себя ограничиваете лишь какими-то методами разработки, которые для вас «всё и вся».
Зря!
Мир алгоритмов и задач весьма велик.

Это был пост к посту vbr о целесообразности использования динамических объектов, …

Статическая типизация даёт стабильность и безопасность, динамическая — необычные и легковесные способы решения задач. Иногда их получается совмещать, как это делает Go с интерфейсами или C++ с шаблонами.

Статическая типизация либо невыразительна, либо слишком переусложнена (привет Haskell). И она не всесильна. Ей поклоняются как индийскому богу, в то время как такие языки как питон продемонстрировали, что корректность может быть проще достигнута через тестирование.

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

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

Erlang - «промышленный». его Ericsson создавал для телекома и он там активно используется. правда, корявый он до жути.

тащемта, кроме телекома его практически нигде и нет.

забавно что сторонник статической типизации

требует таковой тока от доменов над данными но полностью приемлет отсутсвие типизации(что статической что динамической) над кодом - хотя бы на уровне соблюдения не только фактического заголовка но и текстуальной приводимости

мдя

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

Т.е. я не против того, чтобы можно было писать код вида

var x: any = parseJson(input);
print(x.name);

Который будет идентичен коду вида

var x: Map<String, Object> = parseJson(input);
print(x.get("name"));

Кажется в C# есть немного похожая фича с ключевым словом dynamic.

Erlang - «промышленный». его Ericsson создавал для телекома и он там активно используется. правда, корявый он до жути.

Я в курсе его истории. Но сегодня это мёртвый язык, как и Smalltalk. Его пытались оживить, заменив Erlang на другой язык (Elixir), но пациент скорее мёртв, чем жив.

тащемта, кроме телекома его практически нигде и нет.

Да и в телекоме его нет. Телеком стал просто сетевым провайдером, ничего там соединять больше не надо, под капотом обычные IP-сети, которые обрабатываются на всяких железных роутерах. Когда-то и амазон на лиспе был написан, много чего забавного было раньше, сейчас всё куда скучней.

требует таковой тока от доменов над данными но полностью приемлет отсутсвие типизации(что статической что динамической) над кодом - хотя бы на уровне соблюдения не только фактического заголовка но и текстуальной приводимости

Я ничего не понял.

живее всех живых. в телекоме его полно и на нём активно пишут софт. просто он как DSL для телекома и только там и используется. а так, когда я работала на ОПСОСа там даже курсы Erlang'а предлагали всем желающим. есть целая индустрия курсов, сертификации и вот этого всего.

у тебя совершенно неправильные представления о телекоме. не надо гнать пургу.

Не в курсе о телекоме …

Попробовал в yandex произвести поиск «телекоме какой ЯП использует»

Вот ответ

C++ — основной язык разработки в телекоме, но также используются Go и Python. 
habr.com
В зависимости от задачи и компонента системы в телекоме применяют разные языки программирования:
Модуль управления мобильными устройствами. Используют C++.
Модуль управления базовой станцией. Для этого компонента применяют C++ и Go.
Ядро сети. Для работы с ядром сети, которое базируется на облачных технологиях, используют C++.
Система управления сетью и бизнес-поддержка системы. Для этих целей применяют JavaScript, Python, Go.

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

а на Эрланге до сих пор пишут монстры телекомовского оборудования вроде Ericsson и Siemens, так что наши местные ОПСОСы готовят специалистов, чтобы поддерживать и развивать софт, который поставляется с оборудованием. на их оборудовании работает весь наш телеком.

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

Спасибо!

Скорее всего yandex где-то что-то слышал …

это не страшно

Попробовал задать вопрос «yandex не ахти правда ли это?»

Ответ

Нельзя однозначно сказать, правда ли утверждение «Яндекс не ахти». Мнения о работе сервисов Яндекса могут быть разными.
В некоторых отзывах пользователи высказывают негативные впечатления от работы сервисов Яндекса. Например, в 2023 году на сайте DTF обсуждали проблемы с качеством работы мобильных приложений Яндекса, служб поддержки и правил оказания услуг. 
dtf.ru
otzovik.com
С другой стороны, есть и положительные отзывы. Например, пользователи отмечают сервис Яндекс Картинки, который, по их мнению, не имеет аналогов. 
otvet.mail.ru
Таким образом, мнение о работе Яндекса и его сервисах зависит от личного опыта и восприятия пользователя.

Попробовал задать вопрос «yandex не ахти правда ли это?»

Вообще-то yandex поиск мне нравится.
Yandex прекрасно осведомлён о Русских ресурсах и его ответы много лучше иных поисковых систем.
Да и по вопросам разработки даёт хорошие ссылки …

Есть ли смысл в языке, в котором ДТ и СТ одновременно?

Мадам, вы, наверное, работали в «телекомах», когда Go еще не «всплыл»? а была мода на «Java» и «Erlang»? Увы и ах, но всякие там «ынтырпрайные архитекторы» и другая околошваль, определяющая на чем будем писать, сильно падки на моду.

Так то по мне, в телекомах должен быть C/С++ и Rust, по основной деятельности. Бухгалтерию и другую обслугу не берем в расчет - там может и Java даже присутствовать.

С/С++ с их вечными проблемами управления памятью это точно то что нужно для надёжных систем связи, да да.