Здравствуйте, Pzz, Вы писали:

Pzz>А можно было взять mingw'ный компилятор Obj-C под венду, и просто перекомпилировать.

Нельзя. Работа с графикой. Очень платформо-зависима

Здравствуйте, maxkar, Вы писали:


M>Вот как раз зеленые потоки решают узкую задачу и добавляют кучу сложностей по управлению. Плюс требуют большой работы в JVM (например, весь I/O блокирующий переписать внутри). И в результате получается тот же фреймворк, с которым приходится дальше бороться. И вот совершенно не понятно, чем эти зеленые потоки принципиально лучше тех же Scala Future (примерно равно Java CompletableFuture).

В том-то и дело, что 99% кода не нужно знать ни про параллелизм, ни про асинхронность. А проблема фьюч, монад и корутин в том, что если где-то внизу есть асинхронный вызов, то фьючи, как раковая опухоль, расползаются по всему приложению. И в итоге приложение набито for comprehensions-ами тогда как собственно асинхронных вызовов в нем штук 10. Решения именно этой проблемы я жду от project loom. Нужно сделать кеш на фьюче? без проблем. Нужно получить её значение и вернуть вызывающей стороне? Делаешь future.get() и не заставляешь вызывающую сторону флетмаппить монады.

Здравствуйте, Homunculus, Вы писали:

Pzz>>А можно было взять mingw'ный компилятор Obj-C под венду, и просто перекомпилировать.

H>Нельзя. Работа с графикой. Очень платформо-зависима

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

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

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

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

Здравствуйте, Pzz, Вы писали:

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

Здравствуйте, Homunculus, Вы писали:

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

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

Я лично вообще всегда писал с оглядкой на портабабельность. Знаю, многие считают, что так делать не надо, потому, что "кроме windows и x86 все равно ничего не бывает". А я всегда так делал, и мой код легко переносится.

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

Здравствуйте, Pzz, Вы писали:

Ф>>Так вот, фрэймворки тебе позволяют быстрее разбираться в чужом коде (и в своём тоже) хотя-бы просто потому что тебе придётся читать в 10 и то дажи и 100 раз меньше кода, чем если бы фрэймворка не было. Фрэймворки уменьшают кол-во хаоса в проекте и значительно облегчают тебе жизнь при подходе к чужим (и своим тоже) творениям.

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

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

Здравствуйте, scf, Вы писали:

scf>Один из ужасных типажей, который мне попадается на собеседованиях — квадратно-гнездовой фреймворщик: может рассказать про конфигурацию хибернейта, но не способен написать программу, сортирующую текстовый файл.

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

Здравствуйте, Философ, Вы писали:

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

Ф>Нет не разрушается. Слава богу, одни и теже фрэймворки часто используются во многих проектах: читать и расследовать приходится один раз.

Если ты текст фреймворка наизусть знаешь, это, наверное, самая плохая характеристика для этого фреймворка.

Здравствуйте, scf, Вы писали:

scf> Решения именно этой проблемы я жду от project loom.

что насчет этой библиотеки http://www.gpars.org/ ?

Здравствуйте, vaa, Вы писали:

vaa>что насчет этой библиотеки http://www.gpars.org/ ?

Полистал доки — модель акторов, интрузивный код, заброшена с 2018 года. CompletableFuture лучше, не говоря уже о projectreactor.

Здравствуйте, maxkar, Вы писали:

M> private val cache = new HashMap[String, Future[AuthResult]]()

M> lock synchronized {
M> cache.getOrElseUpdate(sessionId, startAuth(sessionId))
M> }
А чем ConcurrentHashMap с computeIfAbsent не устраивает?

Здравствуйте, Shmj, Вы писали:

S>Давайте примеры правильных фреймворков.

.NET Framework — каждая версия ходит достаточно долго, какие-то breaking changes достаточно редки

Здравствуйте, Shmj, Вы писали:

S>Какое решение?

Решение — не использовать никакие фреймворки. Это мусор и зависимость от автора . помню бурления на хабре, как автор реакта или чего что-то не так сделал. Надо везде использовать чистый код, ну или (если прям край как надо) библиотеку под конкретное дело (хттп запрос или еще что).

Здравствуйте, morgot, Вы писали:

M>Здравствуйте, Shmj, Вы писали:

S>>Какое решение?

M>Решение — не использовать никакие фреймворки. Это мусор и зависимость от автора . помню бурления на хабре, как автор реакта или чего что-то не так сделал. Надо везде использовать чистый код, ну или (если прям край как надо) библиотеку под конкретное дело (хттп запрос или еще что).

Кстати, как отличить фрэймворк от библиотеки, по каким критериям?

Здравствуйте, Shmj, Вы писали:

S>1. Сначала нужно постичь все его тонкости и костыли. Обычно это происходит в процессе работы и даже одна фигня может занять легко пол дня. Но утешаешь себя мыслью что это только на первом проекте (на самом деле см. п. 2).
Нет, не нужно. Ибо тонкости ты постигнешь только в процессе применения, в случае если наткнешься на какие грабли. Если не будешь отклоняться от
границы применимости фреймворка и тебе не требуется выжимать максимум производительности — скорее всего на грабли ты не наткнешься и у тебя сразу все будет работать из коробки. Вот если наткнешься на проблемы — да, будет весьма весело, но времени потратишь один хрен меньше чем писать все с нуля.
S>2. Фреймворки быстро устаревают. Новые версии объявляют депрекейтед привычные вам подходы и вводят новые. Фактически вам придется возвращаться к п. 1 снова и снова, в связи с чем экономия времени сомнительна.
Более новые фреймворки чаще всего проще и легче в использовании, если какая то концепция устарела, это означает что ей на смену пришла более легкая концепция, с которой грабель будет меньше и код писать будет приятнее.

S>3. Фреймворки часто избыточны для ваших задач и вам придется мириться с тормозами — пока оно загрузит 100500 общих библиотек или подобного.
Лучше когда они избыточны. Хуже, когда внезапно тебе понадобилась определенная фича, а ее нет и проблематично прикрутить. И придется тебе лисапедить и хреначить нужную логику ручками, зачастую написав половину фреймворка.

S>В итоге вместо изучения вещей базовых — тратится время на изучение продукта жизнедеятельности тех или иных авторов. Надоело вкрай.
Все с точностью до наоборот. Без фреймворков ты будешь тратить большинство времени на примитивнийшие шаблоннейшие тривиальные вещи. И будешь либо лепить жутчайший копипаст и спагетти, либо писать по существу собственный фреймворк.

S>Какое решение?
Использовать максимум стандартных решений, смотреть на задачи, пытаться предугадать требования наперед и брать фреймворки с запасом по фичам. Если же требуется максимальная производительность и готового фреймворка нет — придется писать свой.

Здравствуйте, vaa, Вы писали:

M>>Решение — не использовать никакие фреймворки. Это мусор и зависимость от автора . помню бурления на хабре, как автор реакта или чего что-то не так сделал. Надо везде использовать чистый код, ну или (если прям край как надо) библиотеку под конкретное дело (хттп запрос или еще что).

vaa>Кстати, как отличить фрэймворк от библиотеки, по каким критериям?

Фреймворк привносит/диктует архитектуру, библиотека — нет.

Аё>>Девиз многих плюсников. Особенно тех, кто не может рвзвернуть строку in place.
Pzz>Ты вот две "половинки" строки поменяй меж собой местами in place, при том, что "половинки" могут быть разного размера. Потом поговорим.
Книжки надо читать.
Там все написано...

Здравствуйте, TG, Вы писали:

TG>Здравствуйте, vaa, Вы писали:

M>>>Решение — не использовать никакие фреймворки. Это мусор и зависимость от автора . помню бурления на хабре, как автор реакта или чего что-то не так сделал. Надо везде использовать чистый код, ну или (если прям край как надо) библиотеку под конкретное дело (хттп запрос или еще что).

vaa>>Кстати, как отличить фрэймворк от библиотеки, по каким критериям?

TG>Фреймворк привносит/диктует архитектуру, библиотека — нет.

Нашел более простое объяснение:
В случае с библиотекой вы решаете где и как использовать ее функционал.
И наоборот, не вы подключаете фреймворк к своему коду, а он подключает ваш код к себе.

Именно наличие инверсии управления – основная разница между библиотекой и фреймворком.

Даже стало как-то понятней откуда столько боли от них.

Здравствуйте, Pzz, Вы писали:

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

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

Здравствуйте, Pzz, Вы писали:

Pzz>Если ты текст фреймворка наизусть знаешь, это, наверное, самая плохая характеристика для этого фреймворка.

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