[01:21:51] <ada_ru> (I_vlxy_I) Сегодня была встреча РГ21 (рабочая группа стандартизации с++). В кулуарах сильно удивлялись, что Ада куда-то там развивается и вообще живёт.
[01:22:39] <ada_ru> (I_vlxy_I) То есть типа как бы там видели что в gcc какие-то коммиты идут, но думали это так, кому то там потребовался фронтенд вот его и вкорячили. Очередной музейный экспонат.
[01:23:42] <ada_ru> (FROL256) надеюсь что С++ когда-нибудь станет музайным экспонатом )
[01:24:13] <ada_ru> (I_vlxy_I) Ну, это случится позже чем то же случится с адой и с Си и с дофига какими еще языками.
[01:25:58] <ada_ru> (FROL256) да, скорее всего, а жаль ... мечты, мечты )
[01:26:58] <ada_ru> (I_vlxy_I) и даже локально от плюсов не всегда можно избавиться.
[01:27:23] <ada_ru> (I_vlxy_I) в некоторых областях очень сложно. даже если сильно хочется.
[01:27:48] <ada_ru> (I_vlxy_I) всё равно часть стороннего кода придется как минимум читать. плюсового.
[01:27:53] <ada_ru> (FROL256) да я не спорю )
[02:10:20] <ada_ru> (I_vlxy_I) Выходит разработчик на Аде должен знать С++ или, хотя бы, Си, но разработчик С++ вовсе не обязан знать даже про существование Ады.
[02:12:49] <ada_ru> (t91x0) Это разработчик на golang не обязан ничего знать, а С++нику нужно знать даже про autotools какие-нибудь
[02:13:28] <ada_ru> (I_vlxy_I) разработчик на голанге должен знать еще и Си. Обычно.
[02:14:01] <ada_ru> (I_vlxy_I) с одной стороны, а с другой неплохо бы знать немного js 🙂 и протоколы, протоколы, уух!
[02:14:19] <ada_ru> (I_vlxy_I) плюс для гошки иногда пишут еще и Makefile. хз зачем
[13:53:59] <ada_ru> (Sergei) отвечает на <(geniepro)
Sergei) …>
А можно примеры таких бирж? В моём понимании, такой метод сводит на нет преимущества крипты, которая, хотя и "медленная", но как средство перевода - самое быстрое из возможных. На мой взгляд, такие биржы не адаптированы к крипте в полной мере - так же как в случае обычной валюты доставку мы получаем с задержкой, когда рынок уже ушёл. Получается медленная торговля здесь обусловлена правилами работы биржы, а не свойствами крипты. Интересно, есть ли у них аргументы, почему надо задерживать доставку.
[13:55:33] <ada_ru> (Sergei) отвечает (t91x0) на <Именно. Переводы на …>
Как я уже написал в ответе geniepro, не вижу, почему при работе с криптой надо пользоваться локальной ДБ, а не блокчейном - может
[14:00:41] <ada_ru> (Sergei) Видимо они просто хотят привязать клиента к бирже таким образом.
[14:05:33] <ada_ru> (Sergei) Сегодня с утра прочёл о языке Julia. Ранее замечал растущую популярность на github. Кто-то пробовал этот язык?
[14:08:03] <ada_ru> (Sergei) отвечает на <(geniepro)
как-то э…>
Компилятор не может сам определить, куда попадёт управление, а куда нет. Это ведь Тьюринг доказал ещё.
[14:10:14] <ada_ru> (nitrocerber) тут нужно флоу анализис. натравливаешь например кодепир на это дело - он с ходу выдаст что на таком-то диапазоне такой-то переменной у тебя вылезет краш.
[14:10:29] <ada_ru> (nitrocerber) ну, как с ходу... от объёмов зависит)
[14:10:41] <ada_ru> (nitrocerber) некоторые кодбейзы он и по неделе гоняет, говорят))
[14:14:03] <ada_ru> (Sergei) отвечает (nitrocerber) на <тут нужно флоу анали…>
Тьюринг привёл в качестве контрпримера анализ кодом анализа самого кода анализа и показал бесконечную рекурсию, на основе чего и доказал, что не всякую программу можно проанализировать. А так да, для каких-то отдельных случаев это возможно. Но и проверять исключительно в рантайме не ошибка, потому как общего решения проблемы анализа кода без выполнения не существует.
[14:15:07] <ada_ru> (nitrocerber) Quis custodiet ipsos custodes?)
[14:15:40] <ada_ru> (Sergei) отвечает (nitrocerber) на <Quis custodiet ipsos…>
Похоже, но несколько не то.
[14:16:06] <ada_ru> (Sergei) Даже если следовать Расселу, проблема неполноты вылазит в арифметике
[14:16:30] <ada_ru> (Sergei) Godel's proof
[14:16:36] <ada_ru> (nitrocerber) ну из той же серии... кто верифицирует верификатор. и верификатор верификатора. итд, добро пожаловать в рекурсию)
[14:17:20] <ada_ru> (nitrocerber) покуда нет ограничения на длинну программы, нифига гарантированно правильно не будет
[14:19:13] <ada_ru> (Sergei) Даже в ограниченных программах. ну да, что-то есть. По Расселу мы должны тогда применить ранжирование верефикаторов на порядки. Как в логике. Первого порядка, второго и т.д. Но всё же, это разные проявления принципа. К тому же, пример Тьюринга не исключает, что другие программы тоже могут не анализироваться. Просто он ограничился одним примером.
[14:19:54] <ada_ru> (Sergei) Гёдель полее подробно проанализировал это другим аппаратом
[14:20:56] <ada_ru> (Sergei) Он сказал, что теоремы от арифметики нельзя доказать средствами логики
[14:22:04] <ada_ru> (nitrocerber) я слишком тупой, чтобы не то, что оппонировать, но даже поддерживать такую дискуссию. выпускайте умных!
[14:22:29] <ada_ru> (I_vlxy_I) отвечает (Sergei) на <Сегодня с утра прочё…>
я
[14:22:49] <ada_ru> (I_vlxy_I) года три назад
[14:23:15] <ada_ru> (Sergei) отвечает (nitrocerber) на <я слишком тупой, что…>
Всё предельно просто. Нельзя сказать, какой будет результат у произвольной программы, проанализировав её текст без пошагового выполнения.
[14:24:04] <ada_ru> (Sergei) отвечает (I_vlxy_I) на <я>
я думал это ответ на "выпускайте умных"
[14:24:13] <ada_ru> (Sergei) ну и как тебе Юля?
[14:24:55] <ada_ru> (I_vlxy_I) неплохо. то есть явно лучше чем матлаб, как язык. и приятней питона.
из нюансов - тамошний REPL это jit-компайлер. поэтому оно тормозит, но работает быстро.
[14:25:24] <ada_ru> (I_vlxy_I) то есть первый вызов свежего кода случается через какое-то время, так как идет компиляция через llvm
[14:25:47] <ada_ru> (Sergei) "тормозит, но работает быстро"
я тоже так подумал
"приятней питона" - а вот с этого места по-подробнее
[14:25:56] <ada_ru> (I_vlxy_I) там даже анотации типов бывают, которые, как обычно, ни на что не влияют (ибо динамическая типизация).
[14:26:27] <ada_ru> (Sergei) отвечает (I_vlxy_I) на <там даже анотации ти…>
анотация типов без типизации это зло
[14:26:41] <ada_ru> (I_vlxy_I) ну, то есть на производительность влияют. так то. может в рантайме трапнется. я хз.
[14:26:57] <ada_ru> (I_vlxy_I) синтаксически в плане работы с матрицами — это матлаб. это плюс.
[14:27:10] <ada_ru> (Sergei) отвечает (I_vlxy_I) на <ну, то есть на произ…>
Был такой язык, Mercury, его убила анотация типов.
[14:27:15] <ada_ru> (I_vlxy_I) работает джулия в плане числогрызни быстрее питона
[14:27:25] <ada_ru> (I_vlxy_I) (если мы про питон а не про с++ говорим)
[14:27:43] <ada_ru> (I_vlxy_I) в плане матриц (умножение) оно работало естественно медленней матлаба.
[14:28:21] <ada_ru> (I_vlxy_I) В плане кастомных алгоритмов - на пару-тройку порядков быстрее 😊
[14:28:50] <ada_ru> (Sergei) в википедии ещё заявляют что он для low-lrvrl systems programming
[14:29:35] <ada_ru> (I_vlxy_I) эммм.... не представляю
[14:30:36] <ada_ru> (I_vlxy_I) то есть оно же как работает - там интерпретатор, который jit-компилятор, который юзает инфраструктуру llvm и, быть может, clang для компиляции на горячую кода что ему нужно исполнять.
[14:30:45] <ada_ru> (I_vlxy_I) Сборщик мусора также присутствует, как я понимаю.
[14:31:07] <ada_ru> (I_vlxy_I) Каким боком это к low level system programming?
[14:31:26] <ada_ru> (I_vlxy_I) но может конечно изменилось что.
[15:27:47] <ada_ru> (Sergei) @I_vlxy_I А вот если сравнивать Julia и Go. Для одних и тех же задач. Мог бы что-то прокомментировать?
[15:28:08] <ada_ru> (I_vlxy_I) Что у них нет общих задач. Ну или почти нет.
[15:29:42] <ada_ru> (Sergei) то есть go всё-таки не такой универсальный язык , как C++?
[15:37:06] <ada_ru> (I_vlxy_I) не такой. и джулия ваще не универсальная
[15:37:46] <ada_ru> (I_vlxy_I) где-то го прям сильно лучше. а где-то. где с++ можно применить, го применить не выйдет.
[15:38:01] <ada_ru> (Sergei) отвечает (I_vlxy_I) на <не такой. и джулия в…>
а вот можно детальнее. Мне казалось, при чтении описания, go претендует на место "турбо" C. Чего в нём таки там не хватает, на твой взгляд?
[15:38:29] <ada_ru> (Sergei) C++ без вариантов всех обходит, но я не о нём
[15:39:08] <ada_ru> (Sergei) есть люди, которые никогда не будут тратить время на изучение template programming
[15:40:34] <ada_ru> (I_vlxy_I) ну, Го практически не живет например без сборщика мусора. он не везде применим.
[15:41:30] <ada_ru> (I_vlxy_I) у Го, как ни крути, хреново без шаблонов. То есть во всех статически типизированных языках это есть.
[15:41:45] <ada_ru> (I_vlxy_I) Шаблоны такие сложные как в плюсах конечно не нужны, но хотя бы что-то жабаподобное хоть.
[15:42:20] <ada_ru> (I_vlxy_I) Ну и производительность там понятно ниже плюсовой.
[15:42:48] <ada_ru> (Sergei) хорошо. А вот это хвалёная go многопоточность, она в каком-то из современных языков ещё была имплементирована, или Go одинок?
[15:42:54] <ada_ru> (I_vlxy_I) С гуями есть проблемы (но это уже скорее к инфраструктуре библиотечной относится и к текущей нише Го)
[15:43:09] <ada_ru> (I_vlxy_I) дык там не многопоточность, там многогорутинность 😊
[15:43:17] <ada_ru> (I_vlxy_I) технически это всё может в один поток дуть
[15:44:03] <ada_ru> (I_vlxy_I) у erlang'a подобное сделано СИЛЬНО лучше и легковесней. но он совсем нишевый.
[15:44:27] <ada_ru> (I_vlxy_I) сейчас вот в плюсы вкрутят корутины - будет хорошо 😊
[15:44:48] <ada_ru> (Sergei) то есть, это просто удобное программирование корутинами в го? Потому, что корутины ещё много где есть, в той же Юли
[15:45:18] <ada_ru> (I_vlxy_I) ну, там еще каналы и там раскидывание этих самых корутит по потокам автоматом.
[15:45:21] <ada_ru> (I_vlxy_I) как-то так.
[15:45:38] <ada_ru> (I_vlxy_I) а потоков будет столько, сколько ядер примерно.
[15:46:06] <ada_ru> (I_vlxy_I) ну, то есть это для конкарренси, а не для паралелизма всё в основном. не для увеличения производительности, а для асинхронности прежде всего.
[17:35:55] <geniepro> Sergei) Как я уже написал в ответе geniepro, не вижу, почему при работе с криптой надо пользоваться локальной ДБ, а не блокчейном - может
За последние сутки у биткойна было меньше 4 транзакций в секунду. Насколько я помню, на подтверждение транзакции уходит в районе часа.
Всё это не способствует стандартной технике торговли на бирже, когда на этой самой бирже в секунду проходят сотни транзакций, и бирж этих десятки.
Блокчейн оооочень медленный...
[17:36:53] <ada_ru> (I_vlxy_I) а ибо нефиг. спекулянты должны умереть, и блокчейн своей тормознутостью их как раз и убьет.
[17:37:52] <geniepro> alizar 20 октября 2010 в 17:32
Лондонская биржа поставила европейский рекорд по скорости транзакций
Новая торговая платформа MillenniumIT (Linux, Sun Solaris Unix, БД Oracle) позволила сократить среднюю задержку обработки транзакций до 126 микросекунд, в то время как у основных европейских конкурентов LSE этот показатель гораздо выше. Например, на биржах BATS Europe и Chi-X он составляет 250 и 175 мкс, соответственно. У других бирж доходит до 300 или 400 мкс.
[17:38:38] <geniepro> Правда, о мировом рекорде LSE говорить не приходится, потому что показатели NYSE по скорости выше: средняя задержка 98 мкс, 99% транзакций — 144 мкс, 99,9% транзакций — 298 мкс. А мировой рекорд принадлежит Сингапурской бирже (менее 90 мкс).
[17:38:42] <ada_ru> (I_vlxy_I) дык надо бороться за высокие показатели, а не низкие же!
[17:38:47] <ada_ru> (I_vlxy_I) Европейцы - молодцы!
[17:40:33] <ada_ru> (Sergei) @I_vlxy_I Алексей, что бы ты ответил тем, которые уверены, что Go - это язык системного программирования?
[17:40:49] <ada_ru> (Sergei) и пытаются тебя заставить на нём программировать?
[17:41:11] <ada_ru> (Sergei) кроме того, что нельзя управлять памятью
[17:41:34] <ada_ru> (Sergei) речь идёт о программировании библиотек, например
[17:50:01] <ada_ru> (I_vlxy_I) ну, програмирование библиотек - это ж на любом ЯП делается. я как-то не понял вопроса
[17:50:31] <ada_ru> (I_vlxy_I) Go не сможет так же нежно обнять железку как Си, или даже плюсы. Или Ада.
[17:50:56] <ada_ru> (Sergei) вот. верная мысль. а мне именно железку надо программировать
[17:58:03] <ada_ru> (Oleg) Эх долбанный яваскрипт
[17:58:10] <ada_ru> (Oleg) Я тут погряз
[17:58:16] <ada_ru> (Oleg) В vue.js
[17:58:32] <ada_ru> (Oleg) Мне как железячнику это не понять
[17:58:41] <ada_ru> (I_vlxy_I) ну, т.е. что-то там можно. и напрямую с памятью поработать, если нужно и всякое такое. Но это всё будет через преодоление. То есть с языком придется бороться - GC отключать там, встроенными удобными типами (типа map) тоже не пользоваться. С лямбдами - или не использовать, или аккуратно использовать.
Горутины, каналы - тоже либо очень долго курить как рантайм с ними работает, либо не использовать от греха.
Недостающие возможности - реализовывать руками.
Сторонние либы тоже не попользовать - они же без этих ограничений писаны.
В итоге бОльшая часть удобства Go уйдет, останется наверно только удобство сборки и скорость сборки. И всё.
[17:59:41] <ada_ru> (Oleg) С Адой под AVR кто нибудь работал?
[17:59:49] <ada_ru> (I_vlxy_I) отвечает (I_vlxy_I) на <ну, т.е. что-то там …>
И нужно будет постоянно оглядываться не юзаешь ли случайно какую-нибудь штуку которая тебе что-то испортит. Жить в страхе. Не, нафиг-нафиг.
[18:00:23] <ada_ru> (Sergei) отвечает (I_vlxy_I) на <И нужно будет постоя…>
спасибо. А то начитаются статей и "на go мы всё сделаем в разы быстрее"
[18:00:45] <ada_ru> (Sergei) даже если речь идёт о почти embedded
[18:01:54] <ada_ru> (I_vlxy_I) ну, то есть если на железяке уже линух крутится какой-нибудь, то о Go можно думать, если нужна прога в юзерспейс обычная. Если там бареметал какой, или дрова какие - сразу нафиг.
[18:02:38] <ada_ru> (Sergei) я так смотрю его в GPU код вообще не научились компилить, например
[18:02:48] <ada_ru> (Sergei) Julia можно
[18:03:10] <ada_ru> (I_vlxy_I) Я люблю Го, сейчас вот утилитку на нем пишу (которая прям напрямую дергает сишные функции, да), в каком то даже смысле системную, но вот чтобы пихать его в суровй embedded... ну такоэ..
[18:04:23] <ada_ru> (I_vlxy_I) отвечает (Sergei) на <Julia можно>
дык это не принципиальная лажа языка, это просто разные области где их применяют - джулия она для математики в первую очередь, как матлаб например, поэтому GPU там очень важно и нужно для ускорения вычислений. А Го - он в основном на серверах юзается, всякие restful сервисы, утилиты, опять таки, системные. там GPU даром не нужен.
[18:04:48] <ada_ru> (Sergei) тоже важная мысль
[18:05:04] <ada_ru> (Sergei) потому как, вообще, задача чисто математическая
[18:05:41] <ada_ru> (Sergei) но народ принимает решения на основе популярности, а не понимания
[18:06:18] <ada_ru> (Sergei) потом, кто-то где-то уже успел написать что "го - универсальный язык для всего"
[18:06:34] <ada_ru> (Sergei) и теперь надо долго дискутировать
[18:06:44] <ada_ru> (Oleg) Джулиу математики обхаяли :-)
[18:06:47] <ada_ru> (I_vlxy_I) если математическая, то ну нафиг Го. Вот серьёзно. Там даже банально с матрицами не удобно работать. А экосистема Го вообще под это не заточена и комьюнити туда особо не копает.
[18:07:00] <ada_ru> (Oleg) Читал на их форуме
[18:07:12] <ada_ru> (Sergei) вообще, речь идёт о линейной алгебре, как раз ...
[18:07:16] <ada_ru> (Sergei) и вот говорят - на го
[18:07:19] <ada_ru> (I_vlxy_I) Перегрузки операторов нет, нифига нет. Матричных операций в языке тоже нет. Всё функциями. Нафиг.
[18:08:41] <ada_ru> (Sergei) ну ладно, попробую им разъяснить, что просто "нельзя так просто взять, и написать тяжёлое приложение с громадными матрицами на го"
[18:10:13] <ada_ru> (Oleg) Только сишечка :-)
[18:10:46] <ada_ru> (I_vlxy_I) вот линейная алгебра для го: https://github.com/gonum/gonum
[18:10:49] <ada_ru> (I_vlxy_I) можно заценить
[18:11:15] <ada_ru> (I_vlxy_I) то есть наверно что-то можно. но оно будет хуже джулии, код будет читаться и восприниматься тоже хуже
[18:12:13] <ada_ru> (I_vlxy_I) просто потому, что, ну блин. без адекватного синтаксиса для матриц, чуть чуть сложная формула уже будет жестью жесткой.
[18:12:24] <ada_ru> (Sergei) <прислал фото>
[18:12:32] <ada_ru> (Sergei) это будет моя презентация
[18:13:43] <ada_ru> (Sergei) оно вообще (go) умеет делать доступ по адресу в памяти?
[18:13:52] <ada_ru> (I_vlxy_I) да, это может.
[18:14:22] <ada_ru> (I_vlxy_I) вот мой говнокод недавний:
var title [128]uint16
GetWindowText(hwnd, (*uint16)(unsafe.Pointer(&title)), 128)
[18:14:48] <ada_ru> (Sergei) фу как негигиенично
[18:15:00] <ada_ru> (I_vlxy_I) да, этот код грязен 😊
[18:15:19] <ada_ru> (I_vlxy_I) А что делать? win32 api, все дела.
[18:15:42] <ada_ru> (I_vlxy_I) Пример перемножения матриц на Go: https://godoc.org/gonum.org/v1/gonum/mat#Dense.Mul
[18:17:01] <ada_ru> (I_vlxy_I) Ну и на сях код был бы примерно таким же, так то.
[18:17:33] <ada_ru> (Sergei) Я не различаю С и С++, пока не идёт речь о dll экспорте
[18:17:54] <ada_ru> (Sergei) но вот на С++ там темплейтики
[18:18:36] <ada_ru> (Sergei) и, что немаловажно - частичная специализация
[18:18:56] <ada_ru> (I_vlxy_I) шаблоны не помогли бы дернуть Win32 API функцию 😊
На тему матриц и математики - да, шаблоны это хорошо.
[18:19:59] <ada_ru> (I_vlxy_I) наверно даже для человека который не умеет и не хочет уметь в языки программирования, но хочет запрогать математики кусок, я бы предложил скорее джулию нежели го.
хотя бы потому, что в джулии искаропки есть например repl. интерактивность бывает важна.
[18:20:24] <ada_ru> (Sergei) а, да, это сильный аргумент, спасибо
[18:21:31] <ada_ru> (Sergei) отвечает (Oleg) на <Читал на их форуме>
ссылку можно?
[18:21:53] <ada_ru> (Oleg) Надо искать
[18:21:58] <ada_ru> (Oleg) Так не помню
[18:22:36] <ada_ru> (Sergei) ну тогда не важно, я сам могу придумать, почему С лучше
[18:23:19] <ada_ru> (I_vlxy_I) математики бывают сильно разными, так то. и задачи у них и инструменты тоже
[18:23:42] <ada_ru> (Oleg) Обсуждали почему они питон используют
[18:24:32] <ada_ru> (Oleg) Резюме - некогда программирование изучать - наукой надо заниматься - библиотек под питон тьма
[18:25:18] <ada_ru> (I_vlxy_I) в джулии была (не знаю сохранилась ли) тенденция делать все базовые либы на самой джулии. ну, типа высокооптимизированный jit же, не медленней плюсов, так нафига нам сишные либы?
поэтому изначально и либ там было меньше (на состояние 2014-2015 года) и работали они еще медленнее. Сейчас небось подтянули это всё.
[18:26:46] <ada_ru> (Sergei) Ну да, всё это мне приводят как контраргумент "мало либ у Юли, а вот под питон есть всё", но потом делают парадоксальный вывод "потому будем писать на го"
[18:27:07] <ada_ru> (Sergei) придётся позаниматься личностной психологией
[18:27:52] <ada_ru> (Sergei) а го через ллвм или через своё что-то?
[18:28:15] <ada_ru> (I_vlxy_I) а вывод не такой и парадоксальный, так то.
поясняю - в мире рестфул сервисов и вебни есть мощная тенденция переписывать сервис с руби и питона на го, так оно становится и сильно шустрее и багов становится меньше.
[18:28:23] <ada_ru> (I_vlxy_I) отсюда, видимо, тенденция и на математические умы накладывается.
[18:29:04] <ada_ru> (I_vlxy_I) отвечает (Sergei) на <а го через ллвм или …>
два компилятора - один (основной) полностью свой (у него корни в plan9 вроде), а другой в виде фронтенда к gcc.
[18:29:11] <ada_ru> (I_vlxy_I) gccgo, так сказать.
[18:29:51] <ada_ru> (Sergei) фу. Это если надо делать свой кодоген, с юлей будет понятней, наверное
[18:30:27] <ada_ru> (Sergei) но про python->go интересно, учту.
[18:31:17] <ada_ru> (Sergei) всё же llvm посовременней чем gcc, мне кажется
[18:31:28] <ada_ru> (I_vlxy_I) угу.
[18:31:38] <ada_ru> (I_vlxy_I) llvm это хорошо
[18:58:45] <ada_ru> (Oleg) Питон при всём при том никуда не денется и go его не победит даже в вебе
[18:58:50] <ada_ru> (Oleg) Только частично
[18:59:02] <ada_ru> (Oleg) А джулию надо посмотреть
[18:59:14] <ada_ru> (Oleg) Хоть я и не математик
[19:00:17] <ada_ru> (I_vlxy_I) ну, так то даже перл пока никуда не делся особо.
[19:00:28] <ada_ru> (I_vlxy_I) его еще побеждать и побеждать
[19:00:44] <ada_ru> (Oleg) Кстати да :-)