Вот у меня понятие есть события есть диспетчер которому в любое время может придти 1 2, 10 событий (сообщений) и он их в зависимости от своей логики обрабатывает в очереди например

Вот у меня понятие есть события есть диспетчер которому в любое время может придти 1 2, 10 событий (сообщений) и он их в зависимости от своей логики обрабатывает в очереди например

think outside of the box короч

Да потому что вся логика в итоге сводится к 1+1

Это будет та же очередь тот же стек те же деревья

Кота еще могу завести

Да потому что вся логика в итоге сводится к 1+1

рано тебе видимо пока

https://www.youtube.com/watch?v=VNGFep6rncY&t=0s&list=WL&index=8

на вот можешь отвлечься)

удачи

Я просто хочу разложить все на низком уровне

Ок закроем тему

Я просто хочу разложить все на низком уровне

А что если сейчас и есть низкий?)

Ну тогда я примитивная амеба

Да потому что вся логика в итоге сводится к 1+1

Система всегда сложнее простой суммы её частей

Хз может не понимаю

Я просто хочу разложить все на низком уровне

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

объект как компьютер в сети

а все эти ифы и циклы - это все нутро - оно не интересно

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

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

но это уже вопрос к декомпозиции....

и всеравно ты будешь писать процедурное говно по итогу) как все)

что значит "явной формы"?)

Не могу назвать завершенной концепцию обьектов в которой нет статической типизации) По сути типизация — это формализация описываемых сущностей, нечто, что можно проверить без запуска кода (ака в compile time), с этой точки зрения весь эликсир описан в духе "карч как-то так"

Не могу назвать завершенной концепцию обьектов в которой нет статической типизации) По сути типизация — это формализация описываемых сущностей, нечто, что можно проверить без запуска кода (ака в compile time), с этой точки зрения весь эликсир описан в духе "карч как-то так"

ммм.... не вижу связи. Объекты выше этого всего

Математика выше объектов

Формальная запись — тоже

+ я вроде как видел наркоманов которые мутили сложные системы типов на эрланге)

Математика выше объектов

объекты как категории?)

+ я вроде как видел наркоманов которые мутили сложные системы типов на эрланге)

Не сомневаюсь)) Но они по прежнему динамические

объекты как категории?)

Нет, типизация как формальное описание происходящих в коде событий и связей

Нет, типизация как формальное описание происходящих в коде событий и связей

ну то есть внутри объекта)

Да, например так

Но ведь её нет же

ну так нутро объекта не интересно)

Но ведь её нет же

это детали реализации языка

я не считаю что статическая типизация нужна

ну то есть.... не так

что она "необходима" всем и каждому.

Нет, это вообще не детали языка, что с уверенностью нам демонстрирует flowtype

Вам бы проповеди в церкви читать

Звучит как то так

Нет, это вообще не детали языка, что с уверенностью нам демонстрирует flowtype

тогда тем более не вижу проблемы)

что она "необходима" всем и каждому.

Да, каждому — не нужна, она нужна даже если кто-то решит помочь людям или найдет способ всё это автоматизировать. А пока no money — no honey

сложна, я не шарю

тогда тем более не вижу проблемы)

Я к тому что это не обязательно хардкодить в язык, но совсем не двавать возможности описывать код без его запуска — это неправильно

ну тут соглашусь

Вам бы проповеди в церкви читать

Я реп читаю

А ну тоже норм

Пропагандистский наверное)

Дисс на мутабельность

Возможно вопрос не по теме, но есть ли в джаве либа для тестов которая проверяла б все Entity  на соответствие JPA спеке

Возможно вопрос не по теме, но есть ли в джаве либа для тестов которая проверяла б все Entity  на соответствие JPA спеке

не знал что твои сущности должны каким-то спекам соответствовать... они ж сущности

что она "необходима" всем и каждому.

Типизация прежде всего необходима компилятору чтобы он смог составить таблицу адресов и смещений и скомпилировать вызов метода или загрузку свойства объекта в одну ассемблерную инструкцию. Без типизации компилятору или рантайиу пришлось бы реализовать перебор подписчиков сообщения (а-ля message-passing в ооп-модели) или поиск нужного свойства по цепочке родителей как в прототипном наследовании. А это на порядки медленней - сотни если не тысячи инструкций. И то что может казаться что такой динамический язык как js довольно быстро работает то это целиком заслуга v8, миллиона строчек кода и диких костылей чтобы вместо честного перебора что-то предсказать закешировать и спекулятивно скомпилировать. И получаются это у них только за счет того что пытаются внутри статически протипизировать js за счет кешей, скрытых классов и т.п. Так что как ни крути без типизации никуда - будет ли она явно в языке либо скрыта через кучу костылей вроде кешей и спекулятивных оптимизаций

Типизация прежде всего необходима компилятору чтобы он смог составить таблицу адресов и смещений и скомпилировать вызов метода или загрузку свойства объекта в одну ассемблерную инструкцию. Без типизации компилятору или рантайиу пришлось бы реализовать перебор подписчиков сообщения (а-ля message-passing в ооп-модели) или поиск нужного свойства по цепочке родителей как в прототипном наследовании. А это на порядки медленней - сотни если не тысячи инструкций. И то что может казаться что такой динамический язык как js довольно быстро работает то это целиком заслуга v8, миллиона строчек кода и диких костылей чтобы вместо честного перебора что-то предсказать закешировать и спекулятивно скомпилировать. И получаются это у них только за счет того что пытаются внутри статически протипизировать js за счет кешей, скрытых классов и т.п. Так что как ни крути без типизации никуда - будет ли она явно в языке либо скрыта через кучу костылей вроде кешей и спекулятивных оптимизаций

компилятору не нужна типизация если у тебя нет компилятора, think about it

и не надо мне рассказывать про hidden классы в V8 будь добр

есть два аспекта системы типов - то для чего оно в Си - что бы знать сколько памяти выделять, и для того что бы люди с OCaml могли тыкать в тебя пальцем

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

не стоит забывать что типы именованные как в Java это не очень гибко

ERROR: S client not available

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

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

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

короч это все о гибкости, скорости и компромисах.

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

дело spectre/meltdown живет в наших сердцах

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

Кстати это очень даже интересно. Я последние пол года пилю библиотеку для стейт-менеджмента в приложении, она непосредственно отвечает за планирование выполнения задач и message passing и разруливает всё это через графы зависимостей и алгоритмы на них) Unsolved problem in computer science в каждом втором абзаце материалов по теме, и всё в таком духе

Кстати это очень даже интересно. Я последние пол года пилю библиотеку для стейт-менеджмента в приложении, она непосредственно отвечает за планирование выполнения задач и message passing и разруливает всё это через графы зависимостей и алгоритмы на них) Unsolved problem in computer science в каждом втором абзаце материалов по теме, и всё в таком духе

а какой язык и есть чо посмотреть?

потому что в больших проектах много людей. А сделать так что бы у тебя на большом проекте все были адекватные сложно)

Нужно просто выбрать язык который не позволяет неадекватно писать

это какой же?

это какой же?

volapük

Хачкель какой-нибудь, там где дрочево на чистоту в общем

Это не от языка зависит, внезапно

Мешает творить херню — api

Начиная, естественно, от stdlib языка, но по большей части этим занимается api библиотек/фреймворков с которыми непосредственно работаешь каждый день

В хаскеле невероятное количество абсолютно невменяемых библиотек, которые естественно собирают все грабли что есть

Как и везде, собственно. Эмпирически, процент годноты никогда не меняется

Начиная, естественно, от stdlib языка, но по большей части этим занимается api библиотек/фреймворков с которыми непосредственно работаешь каждый день

Ну а какие библиотеки по сути зависит от самого языка, его философии

Ну в принципе да

В хаскеле невероятное количество абсолютно невменяемых библиотек, которые естественно собирают все грабли что есть

Думается это от того что энтузиасты двигают, а не смесь энтузиасты/энтерпрайз

https://github.com/formapro/pvm хоть и на пхп, но кому-то может быть полезно это к вопросу о документации и иллюстрации работы проектов

ну и ui https://github.com/formapro/pvm-ui

Спасибо, схоронил

Читали? https://habr.com/company/jugru/blog/419179/

да, нет, говно

в соседнем чате уже обсудили