Энергия - не конкурент Шаттлу вообще. Она могла вывести 100т чего угодно, а Шаттл при примерно тех же габаритах - 24т (и 70 тонн скорлупы и кожаные мешки) ограниченного размера. 24т на НОО может вывести банальный Протон.
Главная стоимость - стоимость двигателей первой ступени. Твердотопливные ускорители Шаттла можно было ронять в океан (а вот F1 нет, что и привело к забвению).
А вот ускорители Энергии изначально предполагалось сажать с парашютом и двигателями мягкой посадки.
Просто вторая ступень работает на водороде, который имеет очень низкую плотность, поэтому вторая ступень огромная, хотя весит меньше половины всего корабля. У Шаттла каждый ускоритель весил больше, чем бак второй ступени и шаттл вместе взятые. Что у Энергии не знаю, но явно похоже.
Бессмысленный для большинства случаев - типичная работа "Шаттла" это вывод пары десятков тонн спутников на НОО вручную. Корабль, оправданный для разовых операций, типа ремонта Хаббла, использовался в основном для операций, не требующих присутствия человека вообще.
Проблема не в челноке, как таковом, а в искусственной монополии, которая привела не к экономии (как хотели), а к завышенных в несколько раз расходах (удивительно, да?).
И ради этого была вечная гонка - потому что любая остановка приводила к гигантским расходам. А не остановка - привела к двум катастрофам.
Про себя ничего рассказывать не надо, качаете с оф.сайта и ставите.
Просят рассказать. Обманывать? Или есть прямая ссылка для скачивания?
Вопрос ущербности каждый сам решает для себя.
Ограничение на количество пользователей и одновременно на время хранения сообщений. У слака - только время хранения, что позволяет делать общедоступные слаки для техподдержки бесплатно.
Всё имеет свою цену. Сахар тоже. Когда он приводит к запутанности вывода типов (и это не только компилятор/анализатор путается, люди тоже) - это дорогая цена.
Это весьма полезная возможность, особенно в отсутствии дефолт-параметров
Вот, кстати, лучше б дефолт-параметры были.
А для конструирования объектов так вообще необходимая, так как у конструкторов нет имени.
А кто их запрещал иметь? Ну кроме зацикленности авторов на С++
Просто перегруженные методы это, по сути своей, аналог синтаксического сахара. Позволяет вместо 5 методов с разными именами написать 5 перегруженных. Собственно ничего более это не даёт.
Зато создаёт проблемы- как в выводе типов, так и с null'ами.
А если сделать два метода с параметрами-интерфейсами, а потом сделать единый интерфейс-наследник - то тут сообщения об ошибках вместе с руганью разработчика могут вызвать Ктулху (я сам натыкался на это).
Сравнивая Сатурн-5 и H1 нужно помнить ещё про то, что разработка двигателя f1 началась в 1955 году. 12 лет от ТЗ до первого полёта.
Причём аргументы для разработки до 61го года была, мягко говоря, неубедительными. Но понимание было и работы финансировались.
Да, чтобы делать KMM для iOS/Mac надо иметь мак.
А чтобы делать для windows — надо иметь windows.
Под android и linux вот компилируется везде :)
Использую KMM. Писать интерфейсы для Windows это адская боль — интеропта с .NET нет и не планируется (приоритет мобилкам, а там Микрософт стал Некрософтом), а делать UI на Win32 API это жёстко.
Зато в платформенно-зависимой части кода можно ковыряться в системе сколько хочешь — тут тебе и реестр и прочие системные запросы.
Вот сейчас пробуем ReactNative натянуть на KMM- посмотрим, что выйдет…
Если компилятор переставит местами инструкции записи, то флаг g_flag может получить значение true до того, как будут записаны все данные
Да что все о перестановках?
Достаточно иметь разные переменные на разных кэшлайнах, а потоки- на ядрах, имеющих собственный кэш. И пожалуйста- до ядра «читателя» разные переменные (линии кэша) доезжают в произвольном порядке.
Если честно, никогда не видел, чтобы ХРюши собеседовали отдельно от технических работников. Ни когда собеседовался, ни когда собеседовал. Вот первые/последние минут 15- да, обычно есть, но не всё собеседование.
Байку про рулетку все ж помнят?
PS: https://tibedox.ru/best/tyoshcha-i-ruletka
Если Вы покупали IDEA, то получили письмо.
А в письме явно сказано, что "все лицензии продляются до 1 октября". А локальные сервера - бессрочно.
А что будет 1 октября, будут ли все упомянутые страны существовать и не будет ли земля ядерной пустыней - сказать теперь никто не возьмётся.
Так что я не понимаю сути Ваших претензий
Энергия - не конкурент Шаттлу вообще. Она могла вывести 100т чего угодно, а Шаттл при примерно тех же габаритах - 24т (и 70 тонн скорлупы и кожаные мешки) ограниченного размера. 24т на НОО может вывести банальный Протон.
Главная стоимость - стоимость двигателей первой ступени. Твердотопливные ускорители Шаттла можно было ронять в океан (а вот F1 нет, что и привело к забвению).
А вот ускорители Энергии изначально предполагалось сажать с парашютом и двигателями мягкой посадки.
Просто вторая ступень работает на водороде, который имеет очень низкую плотность, поэтому вторая ступень огромная, хотя весит меньше половины всего корабля. У Шаттла каждый ускоритель весил больше, чем бак второй ступени и шаттл вместе взятые. Что у Энергии не знаю, но явно похоже.
Корабль без системы спасения.
Бессмысленный для большинства случаев - типичная работа "Шаттла" это вывод пары десятков тонн спутников на НОО вручную. Корабль, оправданный для разовых операций, типа ремонта Хаббла, использовался в основном для операций, не требующих присутствия человека вообще.
Проблема не в челноке, как таковом, а в искусственной монополии, которая привела не к экономии (как хотели), а к завышенных в несколько раз расходах (удивительно, да?).
И ради этого была вечная гонка - потому что любая остановка приводила к гигантским расходам. А не остановка - привела к двум катастрофам.
4 года назад мне был интересен свой сервер. Но сейчас мне уже не надо.
Но буду знать, спасибо.
Просят рассказать. Обманывать? Или есть прямая ссылка для скачивания?
Ограничение на количество пользователей и одновременно на время хранения сообщений. У слака - только время хранения, что позволяет делать общедоступные слаки для техподдержки бесплатно.
Нет. А надо?
Только бесплатная версия ещё ущербнее, чем для слак, а платная стоит дорого.
Плюс бесплатную - ставит самому и так просто не дают - надо всё о себе рассказать.
Чем это лучше слака?
kotlin/jvm + rust
Тут путаница в терминах. Я против перегузки: https://ru.wikipedia.org/wiki/%D0%9F%D0%B5%D1%80%D0%B5%D0%B3%D1%80%D1%83%D0%B7%D0%BA%D0%B0_%D0%BF%D1%80%D0%BE%D1%86%D0%B5%D0%B4%D1%83%D1%80_%D0%B8_%D1%84%D1%83%D0%BD%D0%BA%D1%86%D0%B8%D0%B9
Она не нужна для ОПП. Более того, это некоторая замена ООП для процедурных языков типа C (не C++).
Ничего плохого про методы по-умолчанию не скажу.
Я ругаю только перегрузку методов.
Я ж писал - когда есть два метода с типами-интерфейсами и класс, который наследует оба интерфейса.
Ну не сильно - потому что, опять же, всегда есть ровно один метод и его проще найти.
Вы про перегузку? Можно пример, когда они помогают (т.е. никак нельзя назвать два метода разными именами)?
А в чём проблема назвать их по-разному? У них разная суть - объём цилиндра и объём куба.
То, что второй использует целые числа - просто бред.
Да. Много раз. А совместно с extension-методами в kotlin это создаёт ещё больше проблем.
Нет.
Потому что метод остаётся один. И в наследнике он будет ровно такой же.
Смесь множественного (по факту дефолтных методов) наследования и перегрузки - это плохо.
Всё имеет свою цену. Сахар тоже. Когда он приводит к запутанности вывода типов (и это не только компилятор/анализатор путается, люди тоже) - это дорогая цена.
Вот, кстати, лучше б дефолт-параметры были.
А кто их запрещал иметь? Ну кроме зацикленности авторов на С++
Конечно нет никакого тру-ООП.
Просто перегруженные методы это, по сути своей, аналог синтаксического сахара. Позволяет вместо 5 методов с разными именами написать 5 перегруженных. Собственно ничего более это не даёт.
Зато создаёт проблемы- как в выводе типов, так и с null'ами.
А если сделать два метода с параметрами-интерфейсами, а потом сделать единый интерфейс-наследник - то тут сообщения об ошибках вместе с руганью разработчика могут вызвать Ктулху (я сам натыкался на это).
Мда, про перегруженные методы ещё Мейер писал, что это несовместимо с ООП.
Но создатели java не читатели были :(
Причём аргументы для разработки до 61го года была, мягко говоря, неубедительными. Но понимание было и работы финансировались.
А чтобы делать для windows — надо иметь windows.
Под android и linux вот компилируется везде :)
Использую KMM. Писать интерфейсы для Windows это адская боль — интеропта с .NET нет и не планируется (приоритет мобилкам, а там Микрософт стал Некрософтом), а делать UI на Win32 API это жёстко.
Зато в платформенно-зависимой части кода можно ковыряться в системе сколько хочешь — тут тебе и реестр и прочие системные запросы.
Вот сейчас пробуем ReactNative натянуть на KMM- посмотрим, что выйдет…
Да что все о перестановках?
Достаточно иметь разные переменные на разных кэшлайнах, а потоки- на ядрах, имеющих собственный кэш. И пожалуйста- до ядра «читателя» разные переменные (линии кэша) доезжают в произвольном порядке.