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

B>Проблемы той же Java, связанные с исключениями, связаны с тем, что во-первых в языке присутствуют unchecked exceptions, а во-вторых в стандартной библиотеке есть общий базовый класс для checked exceptions, с помощью которого в говнокоде постоянно утекают абстракции через throws Exception.
Периодически встречал заявления, что checked exceptions в джаве — это была неудачная идея. Я лично далёк от джава-мира так что интересно насколько эти идеи общепринятые. Во многих проектах они используются? Как себя в этом плане стандартная библиотека ведёт?

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

ARK>Софт для марсохода написан на С.

Многое на C++

Most of the onboard autonomous driving software on MER and MSL is written in C++:
Dense Stereo Vision
Autonomous Terrain Assessment
Local and Global Waypoint Planning
Multi-sol Driving
Visual Odometry
Slip Checks
Keepout Zone Prediction

https://www.youtube.com/watch?v=3SdSKZFoUa8

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

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

ARK>>Софт для марсохода написан на С.

EP>Многое

YouTube 1:04:20 — no exceptions, no multiple inheritance, no RTTI, динамическое выделение памяти только в модуле управления движением по поверхности. Что используют: namespaces, operator overloading, одиночное наследование, системы статического анализа, команду из сотни тестеров.

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

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

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

B>Checked exceptions это эквивалент использования union types для обработки ошибок с синтаксическим сахаром (просто сравните реализацию fn2 в обоих случаях).
B>Не более того. Разница с unchecked exceptions состоит в том, что пользователь API здесь может не ждать сюрпризов и утечек абстракции, помимо того, что уже объявлено в сигнатуре, и он обязан либо обработать ошибку, либо задекларировать её и делегировать обработку на уровень выше.

Да, так и есть.

B>Проблемы той же Java, связанные с исключениями, связаны с тем, что во-первых в языке присутствуют unchecked exceptions, а во-вторых в стандартной библиотеке есть общий базовый класс для checked exceptions, с помощью которого в говнокоде постоянно утекают абстракции через throws Exception.

Верно. ИМХО, только лишь наличие checked exceptions не делает язык предсказуемым, необходимо одновременное отсутствие unchecked. Поэтому Java в качестве надежного языка у меня вызывает некоторые сомнения. Да еще и сборщик мусора...

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

EP>Многое на C++

Да, верно. Что-то я не увидел это в прошлой презентации. Очень рискованное решение, однако.

Но:

So we limited our code to “Embedded C++” constructs

Exceptions: none
Templates: none
Iostream: none
Multiple inheritance: none
Operator overloading: almost none (only “new” and “delete”).
Dynamic Allocation: Guarantee no system heap corruption using a dedicated memory pool and Placement New.

Хе-хе.

Так что в контексте исключений замена C на С++ в данном случае ничего не изменила.

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

ARK>Очень рискованное решение, однако.

Почему? По сравнению с чем?

ARK>Но:

Да, видел.

ARK>

ARK>Templates: none

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

ARK>Так что в контексте исключений замена C на С++ в данном случае ничего не изменила.

В контексте исключений — исключения реализуются и на C, например через setjmp+longjmp — поэтому о том и речь, смотреть нужно на используемые в коде механизмы, а не на язык

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

ARK>>Очень рискованное решение, однако.
EP>Почему? По сравнению с чем?

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

EP>Шаблоны не используют из-за определённых предубеждений, о чём он и сказал в видео — мол нужно убедить многих.


В презентации написано, что из-за распухания кода.

ARK>>Так что в контексте исключений замена C на С++ в данном случае ничего не изменила.
EP>В контексте исключений — исключения реализуются и на C, например через setjmp+longjmp — поэтому о том и речь, смотреть нужно на используемые в коде механизмы, а не на язык

Насколько мне известно, исключений там нет ни в каком виде.

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

ARK>вообще язык слишком велик

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

ARK>чем больше язык, тем сложнее создать инструменты статического анализа

Отчасти да, но "статический анализ" можно делать и в самом языке, через систему типов, что проще внешнего анализатора.
Например единицы измерений и размерности довольно просто реализуются внутри C++. Для C же (или другого "простого" языка) пришлось бы писать внешний анализатор, либо и вовсе не делать такой анализ, что и произошло с Mars Climate Orbiter:

Due to complications arising from human error, the spacecraft encountered Mars at a lower than anticipated altitude and disintegrated due to atmospheric stresses. Mars Reconnaissance Orbiter has since completed most of the intended objectives for this mission.
...
The primary cause of this discrepancy was that one piece of ground software supplied by Lockheed Martin produced results in a United States customary unit ("American"), contrary to its Software Interface Specification (SIS), while a second system, supplied by NASA, that used those results expected them to be in metric units, in accord with the SIS. Software that calculated the total impulse produced by thruster firings calculated results in pound-seconds. The trajectory calculation used these results to correct the predicted position of the spacecraft for the effects of thruster firings. This software expected its inputs to be in newton-seconds.

EP>>Шаблоны не используют из-за определённых предубеждений, о чём он и сказал в видео — мол нужно убедить многих.
ARK>
ARK>В презентации написано, что из-за распухания кода.

Он в конце так и сказал (1:22:11) — мол я был бы рад их использовать, нет технических проблем, но трудно убедить остальных, так как у многих есть предубеждения насчёт распухания кода.

ARK>>>Так что в контексте исключений замена C на С++ в данном случае ничего не изменила.
EP>>В контексте исключений — исключения реализуются и на C, например через setjmp+longjmp — поэтому о том и речь, смотреть нужно на используемые в коде механизмы, а не на язык
ARK>Насколько мне известно, исключений там нет ни в каком виде.

* Exceptions in C with Longjmp and Setjmp
* Exception Handling in C without C++

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

ARK>>вообще язык слишком велик
EP>Можно ограничить подмножество — что собственно они и сделали. Причём на запретные конструкции элементарно делается верификатор.

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

EP>Отчасти да, но "статический анализ" можно делать и в самом языке, через систему типов, что проще внешнего анализатора.

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

EP>Для C же (или другого "простого" языка) пришлось бы писать внешний анализатор, либо и вовсе не делать такой анализ, что и произошло с Mars Climate Orbiter:

Да, тут опростоволосились.

ARK>>>>Так что в контексте исключений замена C на С++ в данном случае ничего не изменила.
EP>>>В контексте исключений — исключения реализуются и на C, например через setjmp+longjmp — поэтому о том и речь, смотреть нужно на используемые в коде механизмы, а не на язык
ARK>>Насколько мне известно, исключений там нет ни в каком виде.

EP>* Exceptions in C with Longjmp and Setjmp
EP>* Exception Handling in C without C++

Да не, я понимаю, что в С исключения можно эмулировать. Я говорю, что в марсоходе их нет.

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

ARK>В таком случае надо вернуться на шаг назад и доказать, что исключения могут заменить union-типы _всегда_ (и, как вы понимаете, это доказательство должен делать не я).
Исключения не могут заменить union-типы всегда — это легко проиллюстрировать примером, в котором union-тип используется для ветвления кода в стеке вызовов:

(R1|R2|R3) fn1(P... params) { ... }

void fn2(P... params) {
    var x = fn1(params)
    x match 
       case R1 : doSomething1(x)
       case R2 : doSomething2(x)
       case R3 : doSomething3(x)
    return x
}

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

void fn1(P... params, Consumer<R1> c1, Consumer<R2> c2, Consumer<R3> c3) {
    if (/*condition to return R1*/) {
         c1.consume(r1);
    } else ...
}

void fn2(P... params) {
    fn1(params,
        r1 -> doSomething1(r1),
        r2 -> doSomething2(r2),
        r3 -> doSomething3(r3)
}

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

ARK>Верно. ИМХО, только лишь наличие checked exceptions не делает язык предсказуемым, необходимо одновременное отсутствие unchecked. Поэтому Java в качестве надежного языка у меня вызывает некоторые сомнения. Да еще и сборщик мусора...

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

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

DE>Периодически встречал заявления, что checked exceptions в джаве — это была неудачная идея. Я лично далёк от джава-мира так что интересно насколько эти идеи общепринятые. Во многих проектах они используются? Как себя в этом плане стандартная библиотека ведёт?
В Java-мире нет консенсуса на этот счет. В стандартной библиотеке есть много checked-исключений, часто они используются и в прикладном коде. Мне лично нравится идея декларировать контракты методов полностью, включая возможные ошибки. На мой взгляд, единственная проблема, которая с ними реально есть, это отсутствие generic-исключений:

interface Consumer<V,E[]> {
     void consume(V value) throws E[]
}

class Logger {
     <V,E[]> void trace(V value, Consumer<V,E> consumer) throws E[] {
           log.trace("Value: {}", value);
           consumer.consume(value);
     }
}

class MyService {
     void handle(String string) throws IOException, CustomCheckedException { ... }
     
     void doSomething(String string) {
          try {
              logger.trace(string, s -> handle(string));
          } catch (IOException | CustomCheckedException e) {
              ...
          }
     }
}

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

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

KP>Тот, кому важны микросекунды – C++ тоже не возьмет по причине слишком больших накладных расходов в виде обработки исключений, подсчете ссылок и т.д. Посмотри на тесты скорости: в 50% случаев Rust обгоняет C++, в 30% обгоняет C и это без unsafe.

Посмотрел не первый тест. Раст обгоняет обгоняет С++ только потому что код теста многопоточный, а С++-код однопоточный. С Раст действительно обошел немного, но думаю дело или в многопоточности или в выделении памяти.

Однопоточный вариант ~ на секунду отстает от С++ (т.е. на 20%) и на 1.5 от С.

И (сюрприз!) почти на секунду отстает от моновского C#. Но это уже с жельничаю. Этот тест тоже сногопоточный.

Зато Java на доли секунды, но все же, обогнала Раст в однопоточном варианте.

Так почему ты не делаешь вывод, что Ява вполне себе замена всем этим навомодным языкас и С++ в придачу?

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

VD>Посмотрел не первый тест. Раст обгоняет обгоняет С++ только потому что код теста многопоточный, а С++-код однопоточный. С Раст действительно обошел немного, но думаю дело или в многопоточности или в выделении памяти.
Тесты конкретно на Alioth'е для Раста сделаны не очень правильно.

У нас есть реализация TLS на Rust — она обгоняет по скорости OpenSSL'ную (которая на С) и при этом внутри ещё и безопасна. Все unsafe-операции сосредоточены на периметре.

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

VD>Так почему ты не делаешь вывод, что Ява вполне себе замена всем этим навомодным языкас и С++ в придачу?

Она была бы отличной заменой C++, будь JVM установлена на компьютерах по умолчанию или весила бы не 150-250 Мб в зависимости от платформы.

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

KP>Она была бы отличной заменой C++, будь JVM установлена на компьютерах по умолчанию или весила бы не 150-250 Мб в зависимости от платформы.

Какие проблемы, в наше время, скачать ~60 мег (размер JRE)? Сейчас и сотни мег не проблема. С Явой как раз очень удобно получается, каждое приложение может нести рантайм (возможно урезанный) с собой. Большинство значимых расширений для Эклипса, например, предлагаются (в том числе) и в виде архива включающего Эклипс, сам плагин к нему и JRE. Остается только скопировать на винт и запустить.

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

VD>Какие проблемы, в наше время, скачать ~60 мег (размер JRE)? Сейчас и сотни мег не проблема.

Зависит от того, что ты пишешь. У нас все (или почти все) продукты на писаны на C++ (Maya, 3D Max, ACAD и т.д.). Мы пишем один из компонентов, общий для всех продуктов. Если мы его попытаемся выкатить в виде "вот вам компонент, а вот это рантайм для него", не нужно быть предсказателем что бы понять куда нас пошлют.

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

Если же подходить к вопросу философски, то мой выбор языков для проекта идет по цепочке Python -> Java -> C++.

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

KP>Зависит от того, что ты пишешь. У нас все (или почти все) продукты на писаны на C++ (Maya, 3D Max, ACAD и т.д.). Мы пишем один из компонентов, общий для всех продуктов. Если мы его попытаемся выкатить в виде "вот вам компонент, а вот это рантайм для него", не нужно быть предсказателем что бы понять куда нас пошлют.

3D Max и Автокад — это сугубо телескопные, причем виндовые приложения. Для них сам бог велел использовать донет в качестве расширений.

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

Включить в состав плагина JRE или его огрызок тоже никаких проблем не составит.

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

Это зависит только от того насколько сложный плагин и что в нем делать надо. Если это что-то простенькое — несомненно. Если кода много, то разговоры про рантаймы смешы.

Дотнет, вообще, является частью ОС. Если писать в расчете на 4.0, то работать будет практически везде. Да и в автомате проинсталлировать можно.

KP>Если же подходить к вопросу философски, то мой выбор языков для проекта идет по цепочке Python -> Java -> C++.

Попробуй Nemerle и Scvala. Если освоишь, потом от Python и Java совсем плеваться будешь. Да и от C++, тоже. Для твоих задач оба языка оптимальны. Ну, плюсы для числодробильных вычислений возможно понадобятся, но их не сложно включить в проекты.

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

VD>3D Max и Автокад — это сугубо телескопные, причем виндовые приложения. Для них сам бог велел использовать донет в качестве расширений.

У ACAD есть версия для OSX. Есть чисто линуксовые продукты. Мы пишем компонент для всех них

VD>Вы там совсем развлечениями занимаетесь, если пытаетесь плагины к этим продуктам на Go писать.

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

VD>Дотнет, вообще, является частью ОС. Если писать в расчете на 4.0, то работать будет практически везде. Да и в автомате проинсталлировать можно.

Да кого интересует Windows-only решение?

VD>Попробуй Nemerle и Scvala. Если освоишь, потом от Python и Java совсем плеваться будешь. Да и от C++, тоже. Для твоих задач оба языка оптимальны. Ну, плюсы для числодробильных вычислений возможно понадобятся, но их не сложно включить в проекты.

Scvala – это Scala я полагаю. Пробовал, не понравилось. Эдакий C++ для JVM с элементами Perl в области написания одноразового (в том смысле что через пару месяцев не поймешь что нагорожено) кода. От Nemerle плеваться начинаю даже не начав осваивать – это ж я что, должен венду ставить или с Mono сексом заниматься? Увольте

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

KP>Да кого интересует Windows-only решение?

Перечисленные тобой продукты и есть Windows-only. Ну разве что ACAD (это автокад?) на ACAD портировали. Я даже не знал об этом.

KP>Scvala – это Scala я полагаю. Пробовал, не понравилось. Эдакий C++ для JVM с элементами Perl в области написания одноразового (в том смысле что через пару месяцев не поймешь что нагорожено) кода.

Ты явно смотрел краем глаза и увидел что-то не то. В Скале, конечно, много накручено. Но язык очень добротный. В нем есть все что нужно для жизни. Просто изучи его как следует и изменишь мнение.

KP>От Nemerle плеваться начинаю даже не начав осваивать – это ж я что, должен венду ставить или с Mono сексом заниматься? Увольте

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

Далее, делая продукты для "венды" не ставить "венду" довольно странно. Экзотично, я бы сказал.

С Mono особых проблем тоже нет. И немерл с ним работает.

Сейчас еще есть два варианта:
1. Core CLR.
2. .NET Native.

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

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

VD>Перечисленные тобой продукты и есть Windows-only. Ну разве что ACAD (это автокад?) на ACAD портировали. Я даже не знал об этом.

У меня таки есть подозрение, что работая в Автодеске я лучше знаю о том, какие из наших продуктов Windows-only, а какие нет

VD>Ты явно смотрел краем глаза и увидел что-то не то. В Скале, конечно, много накручено. Но язык очень добротный. В нем есть все что нужно для жизни. Просто изучи его как следует и изменишь мнение.

Может про Scala я и не прав и стоит посмотреть на него еще раз. У меня пока что ощущение того, что слишком уж он наверченный.

VD>Ну, плеваться не читай — это не о языке, а о тебе. Надеюсь ты это понимаешь.

Да, Влад, я понимаю. В первую очередь то, что "одноплатформенный" язык в 2016 – это мусор. Именно поэтому я даже не пытаюсь начать использовать довольно прикольный Swift. Хотя он просто отличная замена Python мог бы оказаться (и может и окажется).

VD>Далее, делая продукты для "венды" не ставить "венду" довольно странно. Экзотично, я бы сказал.

У нас продукты на всех платформах. На работе никто не будет использовать язык который не позволит написать компонент для всех них разом. А дома у меня нет и не будет Windows, очень уж убога ОС, а уж лицензионное соглашение 10-ки вообще за гранью добра и зла.

VD>С Mono особых проблем тоже нет. И немерл с ним работает.

Мы недавно на практике узнали как же это выглядит – нет проблем с Mono. Некие умники догадались написать сервис на C# (.NET 3.5) Все шло хорошо до тех пор, пока клиенты не захотели этот же сервис, но на Linux, что логично, так как сервера на Windows прошлый век. И тут выяснилось, что пока его изрядно не переписали ничего не работало, так как далеко не все что есть даже в столь дремучем .NET реализовано в последнем Mono. А если реализовано, то работает так же как и в .NET.

VD>Области новые и несомненно по трахаться с ними придется, но независимость, в итоге, будет хорошая.

Зачем, если есть то, что работает? C++, JVM, Go?