C++ Qt

привет плюсы и война с ними вместо решения задач. Большая часть разработки на С++ — война с ним.

JavaFX

вы же в курсе насколько древняя эта гадость и насколько неудобные абстракции там юзают?

Чтото там для питона.

 а чем лучше жс? обе безтиповые гадости

Так и есть же, для всякой индюшатины зачем что-то кроме жиэса и юнити?

Смищно, можно использовать реквест хеджинг, к одному придет гц, к другому — нет девяточки увеличатся.

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

чего-чего? в шарпах нет и половины из этого списка dotty.epfl.ch/...​aprogramming/staging.html.
И из этого списка: www.typescriptlang.org/...​notes/typescript-4-1.html
и ещё из многих списков.

Сравните типы в С# и таковые в Scala, TS, хошкеле и прочих языках посвежее. Сравните ваш притрушенный захардкоденный linq и коллекции в котле или в скале. Сравните прибитые гвоздями к язку async/await и IO монады и прочие таски, да хотя бы те же фьючи. Алсо посмотрите на явные реактивные штуки по типу akka-streams и fs2. Абсолютно всё что там есть не годится в сравнение со свежими вещами.

в науку вам надо, в науку. А не в разработчики.

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

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

с привязкой к конкрентому яп — scala.

Эх, жаль на собеседовании не задают таких вопросов...

задают, кек, если приходить неподготовленным на собес.

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

зачем писать на дарте, если он ничем не лучше а иногда даже хуже?

Вы C# и WPF видели, на чем-то помимо Scala что-то нативное разрабатывали?

Да, видел. Лучше комбинации языка + экосистемы на котором есть работа пока не придумали

что-то нативное разрабатывали?

Щас бы С# интерпретируемый в IL называть нативочкой. У него толстый рантайм(превед дотнет фреймворк редистрибутабле), а у нативочки рантайма по хорошему быть не должно.

Как работают истинно компилируемые языки

 Да, давайте разведем дискуссии про истинность коньпеляции, даже плюсики используют промежуточное представление сейчас и «истинно» конпелируемое, как вы выражаетесь, именно оно. А нужно это в том числе и затем, что портировать такую жирную байду как стандарт С++ под всё что угодно это очень сложно и переделывать каждый раз нет смысла.

В общем, есть представление, как стартуют приложения под Android?

какая разница как они там стартуют, если кроссплаформа заматывает эти все «а вы знаете» так что нужно использовать эти знания по минимуму в исключительных случаях?

Когда вы найдете ответы на все эти комментарии, у вас отпадут ваши вопросы.

 у меня вопросов нет, у меня есть претензии к травителям за «трушность» ,"нативность" и «жава апплеты/ асп/ впф это хорошая технология».

Я писал еще начиная с С++ около 20 лет тому назад

И?

Потом back на Java так же имею опыт работы на Scala.

И?

В общем, на всем, кроме Ruby, Go, Python

И?

Haskel

а вот это зря, меньше бы за всякие «прогрессивные технологии» топили.

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

Кстати, если вы такой синьор и знаете все от и до, может ответите на такую элементарную задачку: «может ли статся, что выражение val v = new Foo произведет null» на этой самой скале?

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

, но .NET framework называть устаревшим, это, пожалуй, через чур.

так и есть. И С# и нет хреньмворк вещи очень древние, парадигмы с их выпуска не менялись, а приехало очень много качественно много нового. Вон как например с типами в TS, с HKT и метой в скале.

сли бы прозвучао MFC — да, это уже легенда

уже история

Все остальное от Лукавого.

аргументы? точно ли в 100% вещей нужно именно настолько все быстро что на кроссплатформенную прослойку нету места, и маленькие платформозависимые кусочки не срабатывают?

который мне показали на React Native... Это было нечто.

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

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

Нам нужны пруфы, билли. Где пруфы билли? Можно на нативке наговнокодить так что работать будет хуже кроссплатформы.

В основном, с головы по доке. Источники — conditional types, recursive conditional types variadic parameters и variadic type parameters. Гораздо более простой пример на котором можно потренироватся — реверснуть тьюпл.

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

www.typescriptlang.org/...​sDIhRgBQUoBOqRo4k7fttIIIA

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

Лет через 10 может и до ТФ дойдут

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

Років 10 тому ми б сперечалися який вид фабрики краще, реальність застосування TDD, як розробляти та підтримували різні версії API

и фабрика, и TDD и API в данном контексте ничем не лучше.

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

сперечалися який вид фабрики кращ

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

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

 Я то как раз знаю. А кроме этого знаю как избегать такой необходимости, можно ведь немножечко напрячь мозги и сэкономить себе немного времени. «сварщик» даже не выбирает между двумя вариантами, любая проблема в его понимани всегда должна решаться по месту, даже если это ведет к сильной трате ресурсов в будущем. В понимании «сварщика», выполнение задачи «как следует», это всегда криминал, и его никогда не оправдывает усилий. Обычно это выглядит так: -«если вы сделаете вот так а не вот так, у вас не будет вот таких проблем, это даст экономию n часов» — «да ну не, не вылезет, когда вылезет поправим, инжиниринг ради инжиниринга, и.т.д.» Далее проблема вылазит и требует решения. Если «сварщики» голову на плечах имеют, после какой-то итерации они приходят к мысли, что надо с этим что-то делать. Если нет — так и продолжают заливать воду в бочку без дна.

Ну и переход на личности означает только то, что аргументы закончились.

В науку вам надо.
Практическое программирование не для вашего склада ума.

Дядь, откуда вы знаете кто я такой?

Со скоростью звука,

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

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

Programming defeatism, ещё никогда и ни к чему хорошему это не приводило.

достаточно раз в сутки его перезагружать.

а если перезагружать нельзя? Или если оно колбасит данные с такой скоростью что оно ловит ООМ за 20 минут а надо ему работать минимум 8 часов?

а не сварщиков

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

спрашивали меня. рассказывал.
попросили написать что-то по транзакционному инкременту.

Ваше знание джавы не ставилось под сомнение.

а есть сварщики, которым достаточно владеть инструментами. и им — респект и уважуха

 В нашем случае владение инструментом без того что вы называете

настоящий computer science

не будет настолько высоким, и когда вот такие «сварщики»-программисты без задней мысли программируют в своей неповторимой манере как в песенке из НТР, ничего из этого хорошего не происходит. Если не обращать внимания на проблемы, они от этого не исчезают, они больно бьют по затылку.

в настоящий computer science
хочет? конечно пусть лезет.

Пусть лезет защищать PhD, там «настоящие актуальные CS». Содержимое классических учебников — это не «настоящие CS», это хорошо известные факты, которые УЖЕ открыты.

Тред не читай @ сразу отвечай @ переходи на личности. Г-н Сидоренко ворвался с шашкой в тред и срубил с горяча — ваш геймплей программинг это уныло, низкооплачиваемо и путь в никуда. Я же заметил, что на самом деле, если цель — зарелизить игру и сорвать с неё денег, то вовсе не нужно вникать в глубины строения движков и что-то делать «как следует», метод костылей и победятла в этом случае сработает достаточно хорошо. Если же писать движки — то из каждого угла торчит по куску из математики. В пейперах по тому как из функции плотности построить поверхность уровня и так далее понарисовано каких-нибуть формул из дифференциальной геометрии. Для эффективного понимания того что там написано, это действительно надо. С другой стороны можно сказать что это уже НЕ геймдев, а разработка движков — и вы будете правы. Но Г-н Сидоренко говорил о разрботке движков а не прямом таки победятельном геймдеве?

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

Пример: SpaceX ищет программистов ракеты на GDC, тк современные студенты не умеют работать с памятью

И так далее.

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

Вот я и говорю, чтобы построить нормальную реализацию поверх актеров нужен инжиринг. На голом Any => Unit без трассировки никак нельзя понять что этот Any => Unit делает, только если в навернете пачку абстракций, которые гарантируют что месседж уйдет куда попало, заруинить такую конструкцию не просто, а очень просто.

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

 По большому счету таки приводит к изменению состояния рантайма, и многократному за время обрабобтки сообщения. И если actorRef ! mesaga вызывает в процессе более одного другого актора — то таки да это именно то о чем я писал — каскад изменений локальных состояний акторов(ЧТО И ЕСТЬ ИЗМЕНЕНИЕ ГЛОБАЛЬНОГО СОСТОЯНИЯ), который без трассировки нельзя отследить. Ну а если вам не особо нужен висящий стейт в приложении, а несколько обработчиков накинуть — актеры тут не осбо то и нужны, какая-нибуть фьючка или конкаррент эффект для этой задачи будет в несколько раз более простым решением.

Если конкретно наг*внокожено

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

нет состояния объекта, когда "во время пути собака смогла подрасти"

Состояние актера и конфиграция актор системы, оно все есть. В популярных реализациях — точно есть.

окей, поверх голых класов тоже надо много инжиниринга воротить, пока не все в облачных faas

 К счастью оно уже наворочено, zio называется, или например cats-effect, monix там какой-нибуть.