Re[22]: Тенденции языков
От: jazzer Россия Skype: enerjazzer
Дата: 22.05.15 09:42
Оценка: +1
Здравствуйте, Sinclair, Вы писали:

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


KP>>и это приводит к...?

S>Нуу... к тому же самому — утечке, нет?

Каким образом? Или речь прерывании потока каким-нибудь хакерством за пределами языка, типа KillThread какой-нибудь? Ну тогда да, против лома нет приема. С тем же успехом можно прибить поток, в котором крутится сам сборщик мусора.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[15]: Тенденции языков
От: fddima  
Дата: 22.05.15 14:39
Оценка:
Здравствуйте, AlexRK, Вы писали:

Банальная задача расширяемости (плагинов) — сводится к той проблеме которую я описал.
Возможно кому-то привычнее видеть краш всего процесса, вместо выгруженного плагина с аккуратно залогированным экзепшном, хотя — похоже все IDE, которые я видел — так не думают. А многие даже позволяют работать дальше.
Задача расширяемости — часто встречается и в рамках одного продукта, как один из видов разделения зон ответственности, владения, жизненного цикла.
Отредактировано 22.05.2015 14:41 Mystic Artifact . Предыдущая версия . Еще …
Отредактировано 22.05.2015 14:39 Mystic Artifact . Предыдущая версия .
Re[2]: Тенденции языков
От: __SPIRIT__ Россия  
Дата: 22.05.15 17:07
Оценка: :)
Здравствуйте, hi_octane, Вы писали:

Что-то очень похоже что ты ищешь замену плюсам. А это малость бессмысленно. Если проект большой и старый с плюсов никто не уйдет. Если проект новый, писать на плюсах по меньшей мере странно. Разве что много сторонних и специфичных либ нужно будет использовать. В 90% случаях писать на плюсах == домножить оценку минимум на 1.5-2

Тот же JS более чем реальная замена на клиентской стороне(гусары молчать! ему еще подрасти нужно). Тренд то вполне уверенный, тонкий клиент + облако. И не важно тонкий клиент это вэб, приложение или мобильник. Как результат динамические языки и функциональщина проникает в мэинстрим. А на сервере плюсы не нужны.

Из постепенно проникающих языков я бы выделил Erlang.

З.Ы.
Понятно что очередь умирать не скоро дойдет до CAD/CAM и подобных систем но тренд он такой
Re[16]: Тенденции языков
От: AlexRK  
Дата: 22.05.15 17:14
Оценка: +1
Здравствуйте, fddima, Вы писали:

F>Банальная задача расширяемости (плагинов) — сводится к той проблеме которую я описал.

F>Возможно кому-то привычнее видеть краш всего процесса, вместо выгруженного плагина с аккуратно залогированным экзепшном, хотя — похоже все IDE, которые я видел — так не думают. А многие даже позволяют работать дальше.
F>Задача расширяемости — часто встречается и в рамках одного продукта, как один из видов разделения зон ответственности, владения, жизненного цикла.

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

Понятно, что в существующих ОС такой подход не работает и мы имеем выбор из различных, но плохих вариантов.
Re[17]: Тенденции языков
От: fddima  
Дата: 22.05.15 17:37
Оценка:
Здравствуйте, AlexRK, Вы писали:

ARK>Я немного думал над этим вопросом и пришел к выводу, что с точки зрения корректности лучшим способом является полный запрет расширяемости в рамках одного процесса, как это сделано в Singularity. Там любое расширение — это уникальный процесс, общающийся по типизированным каналам с родителем.

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

ARK>Понятно, что в существующих ОС такой подход не работает и мы имеем выбор из различных, но плохих вариантов.

Во всех существующих ОС такой подход как раз работает, и это единственный путь выполнить что-нибудь в "песочнице". Проблема в том, что это довольно дорого с любой сточки зрения, но в осмысленных случаях — он успешно используется.
Re[18]: Тенденции языков
От: AlexRK  
Дата: 22.05.15 17:45
Оценка:
Здравствуйте, fddima, Вы писали:

ARK>>Я немного думал над этим вопросом и пришел к выводу, что с точки зрения корректности лучшим способом является полный запрет расширяемости в рамках одного процесса, как это сделано в Singularity. Там любое расширение — это уникальный процесс, общающийся по типизированным каналам с родителем.

F> Если под процессом, понимается изолированный юзер-спейс, то — это один из наихудших вариантов, особенно для исходного примера. Код собственно говоря хочет работать с документом (state), используя stateful API, а не с набором сообщений (непосредственно или через прокси — это не так важно).

Да, именно изолированный юзерспейс. В Singularity каналы предоставляют stateful API. Только вот использовать его "как попало" нельзя — для канала задаются четкие правила — что, когда и откуда идет, обойти которые нельзя (компилятор запрещает). Ошибки являются частью контракта канала.

F> Но вообще-то в исходном примере была простая лямбда.


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

ARK>>Понятно, что в существующих ОС такой подход не работает и мы имеем выбор из различных, но плохих вариантов.

F> Во всех существующих ОС такой подход как раз работает, и это единственный путь выполнить что-нибудь в "песочнице". Проблема в том, что это довольно дорого с любой сточки зрения, но в осмысленных случаях — он успешно используется.

Понятно, что работает. Всё работает. И виндовс работает, и линупс работает, и QNX тоже. Только вот как, сколько в коде ошибок и насколько он устойчив — вопрос риторический.
Re[19]: Тенденции языков
От: fddima  
Дата: 22.05.15 18:17
Оценка: +2
Здравствуйте, AlexRK, Вы писали:

F>> Если под процессом, понимается изолированный юзер-спейс, то — это один из наихудших вариантов, особенно для исходного примера. Код собственно говоря хочет работать с документом (state), используя stateful API, а не с набором сообщений (непосредственно или через прокси — это не так важно).

ARK>Да, именно изолированный юзерспейс. В Singularity каналы предоставляют stateful API. Только вот использовать его "как попало" нельзя — для канала задаются четкие правила — что, когда и откуда идет, обойти которые нельзя (компилятор запрещает). Ошибки являются частью контракта канала.
1. Research проекты это хорошо. Я даже за, когда я его смотрел, мне нравилось. Практической же пользы, для нас, программистов наших дней — толку от него вообще никакого.
2. Как иронично, что когда мы обсуждаем error code vs exceptions — показывать ресерч платформу, где есть exceptions.
3. Коммуникационные каналы сразу станут мусором, как только перестанет быть возможным вложить туда то, что хочется.

F>> Но вообще-то в исходном примере была простая лямбда.

ARK>Ну, я в контексте плагинов чуть развил тему.
Отлично. Независимые куски, процессы — они падают, а IPC отваливается. Это вовлекает необходимость обработки ошибок.
TReply SyncRequest<TRequest, TReply>(TRequest request);

Вот сигнатура метода. Этот метод, может упасть: на сериализации сообщения, на передаче сообщения, на десериализации сообщения. При чём ошибка передачи сегодня одна — завтра другая. Сегодня мы используем WCF over pipe, а потом когда задолбались с тем, что оно нихрена не работает — изменили канал, на собственный (с верой что оно будет работать лучше). Так вот — методу SyncRequest — совершенно пофигу на 3 вещи, и даже не знает о:
1. Реализации сериализатора.
2. Реализации канала.
3. Реализации десериализатора.
При этом внешний (вызывающий) код, на котором лежит отвественность обработки ошибки — с исключениями — получает более-менее внятную диагностику, безо всякого протаскивания кодов ошибок в сигнатуры.

А вот другой метод:
void PostAsync<TMessage>(TMessage request);

Данный метод никогда не валится, потому что складывает сообщения в очереди. Но, исключения всё равно могут пораждаться при отсылке инфраструктурой. Если же я залогирую безликие коды ошибок — это существенно усложнит процесс.
Более того, никто не мешает включить дебаг/трейс (всё есстественно в релизной конфигурации), в .NET в частности, и снять стэк-трэйс при постановки сообщения в очередь, если нужно связать сообщение с местом посылки. И то, это всё ещё будет очень безлико.

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

Я не давно заглянул в код Add-In COM Shim — и увидел сплошную лапшу и макрос навроде:
#define SUCCESS(x) if (!(x)) goto error;
.
Это просто ужасно. Это нормально для небольшого C/C++ кода. Это абсолютно ужасно для нового, якобы безопасного языка.
Sinclair, вот и исключениями, то не очень доволен — но лучше уж исключения, чем уг с протаскиванием кодов ошибок.

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


F>> Во всех существующих ОС такой подход как раз работает, и это единственный путь выполнить что-нибудь в "песочнице". Проблема в том, что это довольно дорого с любой сточки зрения, но в осмысленных случаях — он успешно используется.

ARK>Понятно, что работает. Всё работает. И виндовс работает, и линупс работает, и QNX тоже. Только вот как, сколько в коде ошибок и насколько он устойчив — вопрос риторический.
Windows, Linux, OSX — имеют отличные стабильные ядра, и собственно говоря пока не предвидится, что бы их кто-нибудь превзошел.
Ошибки безусловно есть везде, но и мир на месте не стоит. А Singularity всё равно содержит какое-то (5%?) количество нативного кода. Увы. Докажете его безопасность?
Отредактировано 22.05.2015 18:22 Mystic Artifact . Предыдущая версия . Еще …
Отредактировано 22.05.2015 18:21 Mystic Artifact . Предыдущая версия .
Отредактировано 22.05.2015 18:19 Mystic Artifact . Предыдущая версия .
Re[20]: Тенденции языков
От: AlexRK  
Дата: 22.05.15 18:44
Оценка:
Здравствуйте, fddima, Вы писали:

F> Вот сигнатура метода. Этот метод, может упасть: на сериализации сообщения, на передаче сообщения, на десериализации сообщения. При чём ошибка передачи сегодня одна — завтра другая. Сегодня мы используем WCF over pipe, а потом когда задолбались с тем, что оно нихрена не работает — изменили канал, на собственный (с верой что оно будет работать лучше). Так вот — методу SyncRequest — совершенно пофигу на 3 вещи, и даже не знает о:

F> 1. Реализации сериализатора.
F> 2. Реализации канала.
F> 3. Реализации десериализатора.
F> При этом внешний (вызывающий) код, на котором лежит отвественность обработки ошибки — с исключениями — получает более-менее внятную диагностику, безо всякого протаскивания кодов ошибок в сигнатуры.
F> А вот другой метод:
F> Данный метод никогда не валится, потому что складывает сообщения в очереди. Но, исключения всё равно могут пораждаться при отсылке инфраструктурой. Если же я залогирую безликие коды ошибок — это существенно усложнит процесс.
F> Более того, никто не мешает включить дебаг/трейс (всё есстественно в релизной конфигурации), в .NET в частности, и снять стэк-трэйс при постановки сообщения в очередь, если нужно связать сообщение с местом посылки. И то, это всё ещё будет очень безлико.

Это все понятно, в общем-то повторение уже написанного ранее.

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


Не согласен с коннотацией терминов (богатые возможности против лапши). Я предлагаю не лапшу, а предсказуемый код, глядя на который можно сразу сказать, что здесь может что-то пойти не так. Впрочем, ИМХО, обсуждение зашло в тупик, позиции сторон ясны, а консенсус вряд ли возможен.

F> Sinclair, вот и исключениями, то не очень доволен — но лучше уж исключения, чем уг с протаскиванием кодов ошибок.


Ну, кому как.

ARK>>Понятно, что работает. Всё работает. И виндовс работает, и линупс работает, и QNX тоже. Только вот как, сколько в коде ошибок и насколько он устойчив — вопрос риторический.

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

Стабильные ядра, написанные без использования исключений.
(У меня там, кстати, QNX, а не OSX, как пример того, что "работают" ОС с разной степенью надежности.)

F> А Singularity всё равно содержит какое-то (5%?) количество нативного кода. Увы. Докажете его безопасность?


Это возможно, вручную (неверифицируемое ядро маленькое). Вот тут доказали для L4: http://ssrg.nicta.com.au/projects/TS/l4.verified/
А вот подобное доказательство для систем, написанных на C++ с исключениями, уже малореально.
Re[21]: Тенденции языков
От: fddima  
Дата: 22.05.15 19:34
Оценка:
Здравствуйте, AlexRK, Вы писали:

ARK>Это все понятно, в общем-то повторение уже написанного ранее.

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

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

ARK>Не согласен с коннотацией терминов (богатые возможности против лапши). Я предлагаю не лапшу, а предсказуемый код, глядя на который можно сразу сказать, что здесь может что-то пойти не так. Впрочем, ИМХО, обсуждение зашло в тупик, позиции сторон ясны, а консенсус вряд ли возможен.
Я тут в треде приводил пример, как в реальном мире нередко обрабатываются коды ошибок — они тупо душаться.
Об этом же написали и в соседних ветках.

ARK>Стабильные ядра, написанные без использования исключений.

Вообще-то, ядро современной ОС, это сплошная, беспрерывная и невидимая обработка исключений, генерируемых, скажем MMU. Т.е. сама идея исключений эксплуатируется пошире, чем нам тут пытаются рассказать.
То, что ядра пилили на C — то и выбора не было. Стоит ли их пилить на C++ с применением исключений — это уже дело тех кто занимается написанием ядер. Для меня плюсы и минусы обоих подходов, будут в этом случае не очевидны.

ARK>(У меня там, кстати, QNX, а не OSX, как пример того, что "работают" ОС с разной степенью надежности.)

Какие-либо гарантии о времени (я про QNX), — это ещё не показатель надежности, и то сильно упирается в железо.
Боюсь, что надежность QNX невозможно сравнить с линуксом, ввиду гораздо более узкого применения первых, и гораздо более широкого применения последних. Поэтому я его и убрал. Хотя, может кто-то и сравнивал. Х.з.

F>> А Singularity всё равно содержит какое-то (5%?) количество нативного кода. Увы. Докажете его безопасность?

ARK>Это возможно, вручную (неверифицируемое ядро маленькое). Вот тут доказали для L4: http://ssrg.nicta.com.au/projects/TS/l4.verified/
ARK>А вот подобное доказательство для систем, написанных на C++ с исключениями, уже малореально.
Тут спору нет. Но и работающей системы нет.
Re[5]: Тенденции языков
От: antropolog  
Дата: 23.05.15 03:32
Оценка: :)))
Здравствуйте, MTD, Вы писали:

MTD>Это бла-бла-бла про якобы просадку производительности и про завуалированный goto.


это не завуалированный а самый ни на есть непосредственный goto, хотя goto лучше хотя бы тем, что видно по коду где окажешься.
Re[12]: Тенденции языков
От: antropolog  
Дата: 23.05.15 03:35
Оценка: :))
Здравствуйте, MTD, Вы писали:

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


пожалуйста, приведи пример хоть немного реального кода с кодами возврата, который можно переписать на исключения и он не будет выглядеть унылым говном.
Re[10]: Тенденции языков
От: antropolog  
Дата: 23.05.15 03:39
Оценка: :))) :))
Здравствуйте, VladD2, Вы писали:


VD>Основная проблема с кодами возврата не контроль компилятора, а куча болепрлэйт-кода засоряющего код, и необходимость тратить на него время.


да покажите же наконец эту кучу бойлерплейт кода хоть в одном реальном проекте, и заодно покажите как бы это классно выглядело с исключениями, посмеёмся всеми шрёдерами
Re[13]: Тенденции языков
От: s22  
Дата: 23.05.15 03:41
Оценка:
Здравствуйте, antropolog, Вы писали:

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


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


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


Раньше лет 5 назад все типовые конфигурации 1с были сплошные "попытка исключение конецпопытки" (в 1с исключения встроены изначально) сейчас практически все переписали на коды возврата.
Причина в том, исключение скрывает ошибку ухудшая тестирование, вроде все отработало и нормально, а результат не корректный.

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

Я думаю по этой причине исключения не используются и в гугл.
Отредактировано 23.05.2015 3:47 s22 . Предыдущая версия .
Re[13]: Тенденции языков
От: MTD https://github.com/mtrempoltsev
Дата: 23.05.15 06:22
Оценка:
Здравствуйте, antropolog, Вы писали:

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


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

Пример реального кода на кошерных кодах возврата от Adobe
Автор: MTD
Дата: 21.02.13


На досуге предлагаю написать итератор без исключений, с помощью конструктора без исключений создать объект с гарантией, что если объект создан то он в валидном состоянии и т.д.
Re[14]: Тенденции языков
От: AlexRK  
Дата: 23.05.15 07:39
Оценка:
Здравствуйте, MTD, Вы писали:

MTD>Пример реального кода на кошерных кодах возврата от Adobe
Автор: MTD
Дата: 21.02.13


Адский код. Хороший пример, но тут кривое API. Непонятно, зачем возвращается код ошибки из каждого метода. Надо было его засунуть внутрь объектов sAIPanelFlyoutMenu/sAIPanel/etc., если уж у них каждый вызов может закончиться фейлом. Каждый метод такого объекта внутри проверил бы состояние, и в случае ошибки просто сделал бы return, а юзер проверил бы ошибку один раз после всех обращений к объекту.

MTD>На досуге предлагаю написать итератор без исключений, с помощью конструктора без исключений создать объект с гарантией, что если объект создан то он в валидном состоянии и т.д.


Про итератор не знаю, а с конструктором, ИМХО, должно быть так — внутри не должно быть никаких вызовов, которые могут закончиться ошибкой, в противном случае следует применить factory method (мало того, я считаю это хорошей практикой вообще, а не только для языков без исключений).
Re[15]: Тенденции языков
От: Mamut Швеция http://dmitriid.com
Дата: 23.05.15 08:05
Оценка:
MTD>>Пример реального кода на кошерных кодах возврата от Adobe
Автор: MTD
Дата: 21.02.13


ARK>Адский код. Хороший пример, но тут кривое API. Непонятно, зачем возвращается код ошибки из каждого метода. Надо было его засунуть внутрь объектов sAIPanelFlyoutMenu/sAIPanel/etc.,


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


dmitriid.comGitHubLinkedIn
Re[11]: Тенденции языков
От: Mamut Швеция http://dmitriid.com
Дата: 23.05.15 08:18
Оценка: +1
VD>>Основная проблема с кодами возврата не контроль компилятора, а куча болепрлэйт-кода засоряющего код, и необходимость тратить на него время.

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



Ну например что-то типа тут.

— Помечаем, что мы ответственны за получение исключений из дочерних процессов
— Запускаем дочерний процесс
— Ждем сообщений из дочернего процесса
— Обрабатываем приходящие сообщения (включая исключения)

Так как это — init функция, у нее в спеках прописано, что она возвращает или {ok, Pid} или {error, Reason). А могла бы выкидывать исключение.

Так же, например, тут. И много где еще.


dmitriid.comGitHubLinkedIn
Re[15]: Тенденции языков
От: MTD https://github.com/mtrempoltsev
Дата: 23.05.15 08:21
Оценка:
Здравствуйте, AlexRK, Вы писали:

ARK>Адский код. Хороший пример, но тут кривое API. Непонятно, зачем возвращается код ошибки из каждого метода.


Ну так ошибка может возникнуть в любом месте.

MTD>>На досуге предлагаю написать итератор без исключений, с помощью конструктора без исключений создать объект с гарантией, что если объект создан то он в валидном состоянии и т.д.


ARK>Про итератор не знаю


То код работы с коллекциями (которого в реальном коде процентов 80) превращается в что-то типа такого:

Iter i;
if (!GetIter(i, data)) return -1;
while (i.HasNext())
{
    X x;
    if (!i.Get(x)) return -1;
    ...
    if (!i.Next()) return -1;
}


Вместо:

for (Iter i : data)
    X x = i.Current();


Ну круто. И что характерно никаких преимуществ перед исключениями.
Re[16]: Тенденции языков
От: AlexRK  
Дата: 23.05.15 08:32
Оценка:
Здравствуйте, MTD, Вы писали:

MTD>То код работы с коллекциями (которого в реальном коде процентов 80) превращается в что-то типа такого:


MTD>
MTD>Iter i;
MTD>if (!GetIter(i, data)) return -1;
MTD>while (i.HasNext())
MTD>{
MTD>    X x;
MTD>    if (!i.Get(x)) return -1;
MTD>    ...
MTD>    if (!i.Next()) return -1;
MTD>}
MTD>


Непонятно. Это все не нужно. GetIter не должен завершаться с ошибкой. HasNext и Next должны быть одним методом MoveNext, для которого тоже нет резона возвращать ошибку.
Get/Current — тут да, наверное ошибка может быть.

Мой вариант без исключений:

for (Iter i : data)
{
    X x;
    if (i.Get(x))
    {
    }
}
Re[17]: Тенденции языков
От: MTD https://github.com/mtrempoltsev
Дата: 23.05.15 09:17
Оценка: 3 (1) +4
Здравствуйте, AlexRK, Вы писали:

ARK>Непонятно. Это все не нужно. GetIter не должен завершаться с ошибкой.


Это почему? А если память, например, не удалось выделить?

ARK>HasNext и Next должны быть одним методом MoveNext


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

ARK>для которого тоже нет резона возвращать ошибку.


А MoveNext невалидному итератору? Ты уверен, что стоит так замаскировать баг?

ARK>Get/Current — тут да, наверное ошибка может быть.


ARK>Мой вариант без исключений:


В идеальном мире, где ошибки бывают только там где хочет программист.
Отредактировано 23.05.2015 9:19 MTD . Предыдущая версия .
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.