Уровень «быдлокодовости» зашкаливает. Сама идея оборачивать всё функции никуда не годится. Проблема решается гораздо проще.
> Под Windows есть функция WinAPI CaptureStackBackTrace, которая позволяет прогуляться по стеку и получить вызовы из фреймов.
А под линукс есть backtrace. А под другую платформу есть что-либо ещё. Может даже libunwind. Вот так и надо действовать, а не засерать свой код тупыми макросами.
Во время флеймов были ещё эти долбаные инвайты. Я всё хотел что-нибудь написать, чтобы получить инвайт, потому что здесь было интересно. Получил инвайт, но хабр уже превратился в болото к тому времени. Теперь захожу разве что раз в месяц.
Хабр превратился в коллекцию хороших статей про программирование.
Неужели? Как-то я этого не заметил. Наоборот, про программирование здесь полная лабуда (причём это не только моё мнение). Если что-то и появляется достойное внимания, то это на 99% перевод, и я сзаду иду на англоязычный первоисточник вместо того, чтобы продираться через кривой язык переводчика.
Было круто, когда бушевали флеймы. Флеймы затушили, стало уныло.
Вот такая интересная вещь: если ты на работе для решения какой либо задачи начал изобретать супер-пупер алгоритм, вместо того чтобы просто взять стандартный из книжки или простую вариацию на тему стандартного опять-же из книжки, то с тобой что-то явно не так. Практически на 100% твой супер-пупер алгоритм будет переусложнён, с кучей багов и алгоритмическая сложность у него будет плохая.
У меня на практике был пример, когда человек написал свой супер-алгоритм сортировки, а потом мы долго искали, где баг. А знал бы он, что можно сделать schwartzian transform, а потом тупо отсортировать стандартной функцией, пусть даже это будет не максимально оптимально, то никаких багов бы не было, и с алгоритмической сложностью всё нормально.
С моей точки зрения, на интервью надо давать задачи приближенные к реальности с прицелом на алгоритмы. И если человек начал на интервью изобретать алгоритм, чтобы решить задачу, то бац — red flag. А если он говорит, что тут мы применим такой и такой стандартный алгоритм, то это наш человек — знает и умеет решать задачи на практике.
За многолетний опыт профессионального программирования реально приходилось думать над нестандартными алгоритмами штучное количество раз. И то потом получалось, что легче и надёжнее применить комбинацию стандартных алгоритмов.
Без HFT у тебя spread будет на порядок больше того, что наблюдается сейчас. Для простых смертных HFT приносит пользу: уменшает spread, увеличивает liquidity, балансирует биржи. Нормальный трейдинг никуда не пропал и не был вытеснен HFT фирмами. Просто не надо с HFT соревноваться в быстроте, а продолжать трейдить полагаясь на фундаметальные основы рынка.
Тащить монады в C++ — гиблое дело. Без поддержки в языке на уровне Хаскеля все C++ решения на монадах будут через задницу. Да ещё и работать эти решения будут на порядок медленнее, потому что там с десяток уровней абстракции на каждую простейшую императивную операцию.
k/kdb испльзуется и ещё как. К сожалению, потому что K — это write-only язык, особенно, если на нём пишут кванты, у которых обычно нет никакой культуры программирования.
А зачем пробрасывать исключения через границу jancy->c++ или c++->jancy? Подход, который отлично работает не только в случае разных языков, но и просто разных модулей — это ловить все исключения на границе между языками/модулями и преобразовывать их в ошибки, которые понимаются другим языком/модулем. А после перехода границы, можно снова выбрасить исключение имеющее смысл уже для данного модуля. В общем, мне кажется, что ваша «ненадёжность» исключений основывается на их неправильном использовании.
Далее, с кодами возврата не всё гладко. Во первых, у вас появляется соглашение о том, что является ошибкой (null, -1, etc), а что нет. Во вторых, типа ошибки нигде нет. Напротив, в Питоне, например, тип ошибки — это тип исключения, и разные типы ошибок можно обрабатывать по-разному. В третьих, синтаксический сахар для обрабоки ошибок мне показался неудобным. Как пробросить ошибку через несколько уровней вызовов и сделать так, чтобы код промежуточных уровней остался не затронутым, т.е. не знал вообще что на нижнем уровне происходит ошибка, а на верхнем она обрабатывается? В вашем подходе на каждом промежуточном уровне прийдётся писать try.
> Под Windows есть функция WinAPI CaptureStackBackTrace, которая позволяет прогуляться по стеку и получить вызовы из фреймов.
А под линукс есть backtrace. А под другую платформу есть что-либо ещё. Может даже libunwind. Вот так и надо действовать, а не засерать свой код тупыми макросами.
Неужели? Как-то я этого не заметил. Наоборот, про программирование здесь полная лабуда (причём это не только моё мнение). Если что-то и появляется достойное внимания, то это на 99% перевод, и я сзаду иду на англоязычный первоисточник вместо того, чтобы продираться через кривой язык переводчика.
Было круто, когда бушевали флеймы. Флеймы затушили, стало уныло.
Напоминает джавовские типы Integer, Float, и т.д. Джававская модель дженериков тоже требует wrapper-ов для примитивных типов.
У меня на практике был пример, когда человек написал свой супер-алгоритм сортировки, а потом мы долго искали, где баг. А знал бы он, что можно сделать schwartzian transform, а потом тупо отсортировать стандартной функцией, пусть даже это будет не максимально оптимально, то никаких багов бы не было, и с алгоритмической сложностью всё нормально.
С моей точки зрения, на интервью надо давать задачи приближенные к реальности с прицелом на алгоритмы. И если человек начал на интервью изобретать алгоритм, чтобы решить задачу, то бац — red flag. А если он говорит, что тут мы применим такой и такой стандартный алгоритм, то это наш человек — знает и умеет решать задачи на практике.
За многолетний опыт профессионального программирования реально приходилось думать над нестандартными алгоритмами штучное количество раз. И то потом получалось, что легче и надёжнее применить комбинацию стандартных алгоритмов.
А на dropbox — жалкие 4GB.
Далее, с кодами возврата не всё гладко. Во первых, у вас появляется соглашение о том, что является ошибкой (null, -1, etc), а что нет. Во вторых, типа ошибки нигде нет. Напротив, в Питоне, например, тип ошибки — это тип исключения, и разные типы ошибок можно обрабатывать по-разному. В третьих, синтаксический сахар для обрабоки ошибок мне показался неудобным. Как пробросить ошибку через несколько уровней вызовов и сделать так, чтобы код промежуточных уровней остался не затронутым, т.е. не знал вообще что на нижнем уровне происходит ошибка, а на верхнем она обрабатывается? В вашем подходе на каждом промежуточном уровне прийдётся писать try.
> Таким образом Вирт посчитал возможность в случае падения приложения её хоть как-то отладить, лишней. Оберон стал еще проще
Это же очевидно! Программы на Обероне просто не могут упасть. Они сразу работают после первой-же успешной компиляции.