[01:06:20] <vlad2> Ха-ха-ха. Классика. Ошибка "The operation completed successfully" со стектрейсом и всеми делами :)
[17:16:01] <Jordan> Влад. Вопрос. Ты занимаешься поддержкой кода разных проектов? В смысле исправляешь, улучшаешь, подчищаешь и т.д?
[17:16:32] <Jordan> Много ли в проектах встречается дублированногокода и явного копипаста?
[17:25:03] <vlad2> Ну основной проект один. Но есть смежные, в которые тоже приходится влезать.
[17:25:37] <vlad2> В среднем по индустриия бы сказал, что в коде неплохо.
[17:25:53] <vlad2> Есть копипаст, но не в каких-то страшных формах.
[17:26:19] <Jordan> На каком языке? С++
[17:26:50] <vlad2> Главной проблемой я бы назвал монструозность компонент и отсутствие тестов.
[17:26:56] <vlad2> Да, С++.
[17:28:09] <Jordan> STL используют?
[17:28:25] <vlad2> Ну и посколько все это развивается с 90-х, то кучу наслоений с соответсвующими проблемами (давно забытые юзкейсы, зачем это надо и т.д.)
[17:28:39] <vlad2> Да, STL везде, кроме очень древнего кода.
[17:37:17] <vlad2> Jordan, тебе не надоело бодаться? :) http://forum.oberoncore.ru/viewtopic.php?f=86&t=4646
[17:37:52] <vlad2> Конечно пост очень провокационный и выводы весьма спорные. Но это ж бесполезно... :)
[17:41:20] <Jordan> Немного надоело.
[17:41:29] <Jordan> Я там ответил.
[17:41:43] <Jordan> http://forum.oberoncore.ru/viewtopic.php?f=86&t=4644&p=83997#p83997
[17:44:38] <vlad2> Гы, там даже "bubble sort" есть, позорище :)
[17:45:01] <Jordan> Потому что проще
[17:45:20] <Jordan> Был бы обобщенный qsort, использовали бы его
[17:45:42] <vlad2> Угу.
[17:46:28] <Jordan> Я же не ради вредности.
[17:52:58] <vаlexey> "В связи с этим возникла мысль - а не является ли строгий и минималистичный дизайн формальной системы Оберона наилучшим средством для такой регистрации?"
[17:53:15] <vаlexey> Гы-ы. В каком месте Оберон (хоть система, хоть язык) описан формально и строго? :-)
[17:53:37] <vаlexey> Там в общем то даже синтаксис языка не строго описан ;-)
[17:53:51] <Jordan> репорт, который как хочет так и понимает. :-)
[17:55:23] <vаlexey> если хочется строгого, формального и непротиворечивого репорта, то его нужно переписать например на Controlled English'e :-)
[17:55:59] <vаlexey> То есть это необходимое условие, но не достаточное :-)
[17:58:34] <vаlexey> Жесть: http://lenta.ru/news/2013/11/27/madworld/
[18:02:30] <Jordan> В ББ самая распространенная структура односвязный список.
[18:03:49] <vаlexey> ну, понятное дело - его проще всего реализовать.
[18:03:58] <vаlexey> а другая простая структура данных вшита в язык - массив.
[18:04:12] <Jordan> Его реалоцировать нужно в ручную
[18:04:17] <Jordan> Список проще
[18:04:24] <vаlexey> у них разные применения
[18:04:41] <Jordan> Как сказать.
[18:05:09] <Jordan> На современных процессорах, простой поиск в массиве даже быстрее
[18:05:14] <vаlexey> да как ни говори :-) у списка O(1) вставка элемента, и O(n) произвольный доступ. У массива наоборот.
[18:05:29] <Jordan> На огромных данных
[18:05:39] <vаlexey> поиск в массиве палюбому быстрее. хоть на каком процессоре :-)
[18:06:09] <Jordan> Нет без кэша медленнее :-)
[18:06:19] <vаlexey> неа. ПОИСК быстрее
[18:06:31] <Jordan> Обращение к озу 250 тактов
[18:06:34] <Jordan> Сейчас
[18:06:35] <vаlexey> вставка - возможно медленнее.
[18:06:55] <vаlexey> и? при поиске по списку не нужно обращаться к памяти? :-)
[18:06:59] <Jordan> Если реалоцировать шагами умножать на 2 или 4 или 10
[18:07:11] <vаlexey> причем ты в случае списка будешь делать БОЛЬШЕ обращений к памяти чем в случае массива
[18:07:13] <vаlexey> при поиске
[18:07:29] <Jordan> Нужно, вот только в кэш при переборе массива, сохранется чать массива
[18:07:46] <Jordan> А всё понял. Да я о том же.
[18:07:47] <vаlexey> еще раз - ты сказал про поиск. а не про вставку.
[18:08:02] <vаlexey> поиск по списку ВСЕГДА медленнее.
[18:08:25] <Jordan> http://www.rsdn.ru/forum/philosophy/2929998.1
[18:08:30] <Jordan> да да медленнее
[18:09:01] <vаlexey> а вставка в массив (точнее в вектор), на малых объемах - да, быстрее.
[18:09:05] <vаlexey> Точнее - может быть быстрее.
[18:09:14] <vаlexey> Потому что скажем в жабе это не совсем так.
[18:09:40] <vаlexey> Ибо там сборщик мусора компактифицирующий, и небольшой список также оказывается целиком в кеше. (то есть он не размазан по всей ОЗУ)
[18:09:56] <Jordan> Не знал.
[18:10:12] <Jordan> Это очень хорошо.
[18:10:13] <vаlexey> другое дело, что элементов списка в кеш поместится меньше чем элементов массива
[18:10:53] <Jordan> если ещё и двухсвязный и 64 бит указатели.
[18:11:27] <vаlexey> Кроме того, тут еще зависит от того, как там левая пятка компактифицируещего сборщика мусора захочет :-) То есть в среднем списки на жабе работают быстрее чем в каких-нибудь плюсах, но они там работают с непредсказуемой скоростью.
[18:11:57] <Jordan> Интересное решение с таким сборщиком мусора.
[18:12:15] <Jordan> Некая самоопимизация.
[18:12:43] <vаlexey> ну, современные системы исполнения, типа той же jvm вообще штуки весьма интеллектуальные
[18:12:55] <vаlexey> что добавляет гибкости и шустрости, но сильно снижает предсказуемость.
[18:13:28] <vаlexey> ну, то есть такая среда исполнения позволяет писать простой, наивный код, и он работает достаточно шустро. до поры до времени :-)
[18:14:09] <Jordan> В ББ какой? Обычный? Без плюшек?
[18:14:27] <Jordan> Всё это дело наживное.
[18:14:45] <vаlexey> обычный, без плюшек.
[18:15:00] <vаlexey> он там даже более чем обычный - он там КОНСЕРВАТИВНЫЙ
[18:15:16] <vаlexey> то есть, вообще говоря, сборщик ББ не гарантирует что он сможет собрать весь мусор
[18:15:23] <vаlexey> что совсем не будет утечек
[18:16:12] <Jordan> Что простите?
[18:16:20] <vlad2> Причем даже info21 не в курсе этого. Или делает вид, что не в курсе :)
[18:16:44] <Jordan> Хм. А как же безопасность?
[18:17:24] <vаlexey> А это безопасно! Просто некоторые кусочики памяти могут не освобождаться :-)
[18:17:44] <vаlexey> Нет, на самом деле это конечно маловероятно. Но возможно.
[18:17:52] <Jordan> Ясно.
[18:18:20] <vаlexey> За счет того, что в ББ довольно мало указателей.
[18:18:26] <vlad2> Грубо говоря, если открытый файл закрывается в финализаторе по факту сборки, то он _может_ остаться открытым сколько угодно, даже если ссылок на него не будет. Просто потому, что в памяти лежит мусор, похожий на ссылку на эот файл.
[18:18:51] <vаlexey> Кстати, обнуление указателей на стеке там сделано ровно для того же самого - не для безопасности какой-то, а скорее всего для того, чтобы сборщику мусора жилось лучше.
[18:18:53] <Jordan> Цена за маленький язык. Дублирование кода. И чем это лучше для программиста не понятно.
[18:19:09] <vlad2> Тогда надо было все обнулять.
[18:19:25] <vlad2> Это хорошо видно на примере О7 :)
[18:19:37] <vlad2> "Язык, который был проще, чем надо" %)
[18:24:17] <vаlexey> Jordan: ну, это лучше если ты делаешь что-то мелкое. ты быстро разберешься в языке, ты можешь реализовать какую-то тулзень и можешь решить свою задачку.
[18:24:37] <vаlexey> то есть в нанопроекте дублирование не примет размах бедствия
[18:24:48] <Jordan> Тулзени разные бывают. Тот же ББ проект не маленький.
[18:24:51] <vаlexey> особенно если ты - единственный разработчик.
[18:25:15] <vаlexey> ББ - проект или маленький, максимум средний. До 200 тысяч строк кода - это маленький проект :-)
[18:26:01] <Jordan> Представь сколько в нём тысяч строк дублированного кода. Это не просто код, а усилия программиста.
[18:26:32] <vаlexey> Во, про отношение к проблеме в дизайне КП/Оберона (если его рассматривать в качестве универсального языка) на оберонкоре: http://demotivators.to/media/posters/4067/449445_ne-vizhu-zla-ne-slyishu-zla-ne-govoryu-o-zle.jpg
[18:26:59] <Jordan> :-D
[18:27:42] <Jordan> Может на КП и не предполагается писать проги > 200 тыщ строк
[18:27:52] <vаlexey> ну, продублировать односвязный список - не проблема.
[18:28:17] <vаlexey> Проблема в другом - из за этого там обычно используются древние неоптимальные структуры данных для всего подряд.
[18:28:24] <Jordan> двухсвязный сложнее, дерево уже не просто.
[18:28:45] <vаlexey> то есть если сортировка, то скорее всего это будет сортировка пузырьком
[18:28:58] <vаlexey> если контейнер - то скорее всего односвязный список.
[18:29:27] <Jordan> Из за простоты реализации.
[18:29:48] <Jordan> С stl сложность можно снизить.
[18:29:48] <vаlexey> ну да. писать меньше, меньше шансов ошибиться.
[18:30:22] <Jordan> Тот же forech при переборе или while
[18:34:16] <Jordan> си это молоток, кп это молоток с ручкой :-)
[18:36:01] <vаlexey> в принципе, такой подход (как в ББ) имеет право на существование. Когда например мы учимся и хотим ВЕСЬ код написать самостоятельно. Чтобы не было ощущения некой магии в черных ящиках которые мы использовали.
[18:36:10] <vаlexey> На самом деле такой опыт ОЧЕНЬ ценен.
[18:36:37] <vаlexey> Иначе потом да, вырастают программисты которые говорят "это невозможно реализовать потому что нет нужного компонента"
[18:37:24] <vаlexey> А Си штука коварная на самом деле. Там же есть макросы, особенно в современно Си они еще и типизированные. Это инструмент обобщенного программирования. Так что там с повторным использованием кода и обобщенкой таки лучше чем в КП
[18:37:32] <Jordan> На ББ это единственный способ.
[18:37:49] <Jordan> С дженериками есть выбор или, или.
[18:38:01] <vlad2> Да, картинка правильная :)
[18:39:48] <vаlexey> Jordan: ну, ты пойми адептов ББ - они почувствовали наконец полный контроль над кодом. То есть из за отсутствия нормальной обобщенки, они пишут код самостоятельно. Не доверяя чужим компонентам. В этом есть некий особый кайф. Особенно если у тебя есть время, и тебе не нужно БЫСТРО (очень быстро) выходить на рынок и конкурировать с чужими решениями.
[18:39:52] <vlad2> Да, я согласен с Алекчеем - такой подход ценен до какого-то масштаба.
[18:41:25] <vаlexey> Их беда ровно в одном - они пытаются экстраполировать свой опыт на всю индустрию в целом. И считают что вот только так  и есть правильно.
[18:41:50] <Jordan> В точку.
[18:42:58] <vlad2> Дальше какого-то масштаба начинается философия на тему "потеряной дороги" и попытки решить проблему уменьшением масштаба.
[18:44:05] <vаlexey> ну, это ж распространенный прием - все что не может быть решено через наш метод, то не нужно и вообще ересь.
[18:44:21] <vаlexey> ну, это как с многозадачностью в ранних версиях iOS :-D
[18:45:13] <vlad2> С последующей перестановкой с ног на голову - проблема больших систем от того, что они написаны не на обероне, а не от того, что они большие. Потому что если бы они были на обероне, то они не были бы большими.
[18:45:29] <vаlexey> ага
[18:50:32] <Jordan> После ваших ответов, минимализм приобретает другой оттенок.
[18:50:48] <Jordan> Я о КП и ББ.
[18:51:00] <Jordan> Король то голый.
[18:54:34] <vаlexey> Ну, не то что бы голый. Но он употребим не везде.
[18:54:55] <vаlexey> Для некого класса задач - это реально король. Для других задач... ммм.. не король :-)
[18:58:02] <vаlexey> ну, то есть очень важно понимать, что не существует решения на все случаи жизни. нет языка на все случаи жизни, и нет даже методологии написания приложений на все случаи жизни.
[18:59:21] <vаlexey> нема серебряной пули :-)
[19:03:53] <Jordan> Я согласен. Но в 90%-ых случаях опять изобретать велосипед, довольно утомительно. Уж лучше пусть компилятор пыхтит над шаблонами. Чем работать за компилятор.
[19:04:22] <vаlexey> угу.
[19:05:03] <vаlexey> Jordan: про растры и вектор - там есть масса нюансов. например до определенного dpi вектор гарантированно будет хуже смотреться нежели растр изготовленный специально для данного разрешения.
[19:05:54] <Jordan> Понял. Это всё пример. Что бы показать автоматический подход и ручной трудоёмкий.
[19:06:08] <vаlexey> но конечно все идет к тому, что dpi растет и скоро большинство рисованной графики будет таки в векторе.
[19:06:50] <vаlexey> вообще ты пример не очень удачный выбрал.
[19:07:44] <vаlexey> gui неплохо бы проектировать не только под разрешение, но еще и под физический размер экрана. тогда решение будет конфеткой. если делать автоматику - то обычно выходит одинаково средненький GUI - не ужасный но и не блеск.
[19:08:04] <vаlexey> Особенно это конечно смартфонов касается - ибо там не только для глаза но и для пальца проектируешь.
[19:09:01] <vаlexey> поэтому, в среднем, качество UI у iOS приложений существенно выше чем у Android-приложений.
[19:09:28] <vаlexey> Просто потому что для первых вариантов актуальных размеров экрана сейчас всего 4.
[19:09:38] <vаlexey> А у Андроида из десятки.
[19:09:41] <vаlexey> *их
[19:16:07] <Jordan> Влад. Сколько онлайн компилятор занимает строк кода?
[19:16:34] <Jordan> оберон 07
[19:20:14] <vаlexey> интересно, что Дейкстра сказал бы про Perceptual Computing? :-)
[19:20:46] <vаlexey> Боюсь он когда писал то самое в 1983 году, он имел ввиду совсем другие компьютеры.
[19:20:51] <vаlexey> И другие применения.
[20:10:26] <Jordan> Секрет раскрыт? kkkk это кто?
[20:52:13] <vаlexey> kkkk это kkkk :-) какая разница какой кусок мяса скрывается за этим ником?
[20:53:51] <Jordan> Интересно.
[20:55:30] <Jordan> Так ты знаешь?
[20:59:38] <vаlexey> думаю я мог бы узнать. материала достаточно. но не хочу. во-первых лениво, а во-вторых это не имеет значения.
[21:20:53] <vlad2> Я на 90% склоняюсь к тому, что в какие-то оменты за кккк сидит Кузьминский.
[21:21:59] <vlad2> Jordan: в компиляторе сейчас порядка 160кб. Строчки не считал. Немного на самом деле. Т.е. оно все еще в категории маленьких проектов.
[22:20:17] <vlad3> ААА!!! "В цеху Макеевского ракетного центра с величайшей осторожностью монтируют головную часть, способную донести ядерный боезаряд до целей, удаленных на тысячи километров. В каждой из таких головных частей ракеты Р-29 ("Синева") — от 4 до 10 боевых блоков. И каждый нацелен на вполне конкретный объект вероятного противника."
[22:20:35] <vlad3> _конкретный объект вероятного противника_
[22:21:54] <vlad3> противник, конечно, вероятный, а вот объект - конкретный ;-]
[23:37:49] <vlad2> /me поднял тест и нашел regression
[23:37:57] <vlad2> типа тесты рулят :)
[23:50:32] <vаlexey> http://forum.oberoncore.ru/viewtopic.php?f=86&t=4644#p84019
[23:50:43] <vаlexey> гы. опять эту ущербную арифметику выспоминают
[23:51:01] <vаlexey> вспоминают
[23:51:25] <vаlexey> особенно если учесть что Оберон-2 стал "меньше" просто за счет переформулирования ЕБНФ-грамматики
[23:51:30] <vаlexey> сама грамматика проще не стала, стала сложнее
[23:51:31] <vlad2> Ага. Типа убеждают сами себя :)
[23:52:47] <vаlexey> причем я списывался с Зуевым (он профессионально, сколь помнишь, занимается компиляторами, в основном С++), и он говорил что да, арифметика у Свердлова абсолютно ущербна.
[23:53:04] <vаlexey> И что чтобы хотя бы грамматики сравнить, нужно ВСЕ грамматики сравниваемых языков переписать в едином стиле.
[23:53:25] <vаlexey> и на одном, черт побери, языке. А то где-то там БНФ где то ЕБНФ где-то еще какой-то диалект используется.
[23:54:07] <vlad2> Да даже если. Все равно это будут попугаи.
[23:54:18] <vlad2> И ьрэйфак будет круче всех :)
[23:54:19] <vаlexey> (и это при том. что такая статистика все рвно мало что говорит даже по грамматикам - нужно хотя бы классы нетерминалов построить)
[23:54:47] <vаlexey> какую-нибудь цикломатичную оценку сложности на этот граф напустить :-)
[23:55:18] <vаlexey> но самая мякотка ведь не грамматика, а семантика. а вот как её формализовать...
[23:57:19] <vаlexey> хотя вот системы типов небось можно как-то формализовать