bormotov
0
В системе Фантом вы не видите никаких серьёзных проблем со ссылками, поэтому я предполагаю, что у вас в голове есть какая-то модель её функционирования.


повторюсь: ОС Фантом на одном физическом хосте — это (грубо) одна копия jvm/.net или любой другой VM. А разные программы в ОС Фантом — это суть разные нити внутри этой самой jvm. Есть сейчас какие-то вопросы по управлению ресурсами внутри одной копии jvm? Примерно такой-же набор вопросов в ОС Фантом.

Ключевое отличие от текущей ситуации с jvm:
— если вы однажды сказали new SomeClass — вам не нужно предпринимать какие-то дополнитлеьные усилия по его сохранению/восстановлению между перезапусками самой системы — это делает ОС сама.
— память-диск-сеть — для вашего процесса представляется единым API, который суть просто передать ссылку на объект.

Само по себе persistance никакой не прорыв — есть в каком-то виде наверное вообще для всего.
Сетевая прозрачность тоже давно известная штука, у jvm есть RMI, например. У того же erlang сетевая прозрачность вообще в базовой концепции. Наверняка можно найти еще примеров успешных промышленных реализаций в этом направлении для других популярных инструментов.

Разница только в том, что в Фантом дадут всё это сразу, в удобном виде, как базовое API.

Навскидку, если сейчас на jvm взять комплект akka + akka-cluster + akka-persistance, то можно с помощью напильника и какой-то матери получить примерно такую же среду выполнения как планируется в Фантоме. Список современных инструментов, у которых разное проникновение в промышленность, и для которых в виде библиотек реалихзована персистентность и сетевая прозрачность можно продолжать.

ответы

1. конечно, у каждого ресурса есть владелец
2. при завершении процесса, сборщик мусора освободит все ресурсы, которыми владел процесс
3. Очевидно, что если владелец передал ссылку на ресурс куда-то наружу, но не передал (разделил?) право владения, то возникает вопрос выбора — что с этим ресурсом делать.

Сборку мусора по счетчику ссылок, в терминах владения можно сформулировать так: если объект получил у «системы» ресурс, и передал ссылку на него в другой объект — то в этот момент он разделил право владения ресурса с тем другим объектом. У ресурса число ссылок — суть число владельцев.

Посмотрите на Rust, из того, что сейчас на слуху, это самое интересное место, где люди пытаются вот эти вопросы владения/передачи как-то красиво формализовать, что бы обеспечить автоматическое управление ресурсами.
bormotov
0
как это копирование или некопирование данных влияет?

Вы предлагаете каждому ресурсу добавить метку — PID владельца.

это не я предлагаю. Вот, у меня windows вокруг, там есть такая утилита ProcessExplorer, которая залезает во внуренности системы, и показывает очень много чего. Мне, на самом деле, не важно технически, как именно это сделано, потому, что совершенно очевидно, всё это начинается со списка процессов, и далее там как-то к этим процессам подвязано.

Вот есть документ в памяти, сейчас его владелец — ОС. Документ передали на редактирование какому-то приложению, что произойдёт?


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

Процесс приложения при редактировании выделил у менеджера памяти пару новых блоков и добавил их в объект документа. Кто владелец новых блоков? Что с ними произойдёт при убиении процесса?


Вот та функция внутри программы внутри jvm/.Net/итд (которой дали ссылку на объект) запросил еще памяти, ему выдали, что происходит? Кто владелец новых блоков?

Могу сходу ответить на «что происходит после завершения функции» — если эти ссылки из этой функции никому больше не попали (функция не отдала эту ссылку в результатах своей работы), у них будет ref count = 0, и эти блоки освободит сборщик мусора.
bormotov
0
я сходу не знаю какой-то одной ссылки, если dz знает — может сам выдаст.

Запущенная программа имеет процесс, который владеет ресурсами ОС.


«Процесс» — это такая запись в таблице процессов? А этот самый PID — это номер этой записи? Есть еще что-то важное? Область памяти в которую загружен код, какие-то стандартные дескрипторы stdin, stdout — это всё не важно. Это по сути тоже какие-то данные в той же таблице, которые можно узнать, зная PID.

Что значит «владеет ресурсами»? Вот, в программе вызывают malloc(), что дальше происходит? Понятно, что основной результат — адрес блока памяти. Но что значит «владеет ресурсами ОС»?

Если ОС память выдает, то в той самой «таблице процессов» находит PID откуда пришел malloc(), и записывает «выдано памяти, по такому-то адресу, такого-то размера». То есть, «процесс владеет ресурсами ОС» — это тоже тупо запись в каких-то структурах данных внутри ОС, связанных с этим PID?

Что значит «освободила ресурсы»? Отправила программа в ОС «сообщение»" free()? Никто не заставляет программу освобождать память, перед тем как сказать system.exit()? Что в этом случае происходит? ОС смотрит в те самые таблицы-итд, находит там PID, находит все ресурсы с ним связанные, выполняет какие-то манипуляции с этими дескрипторами, размерами и так далее. Так?

Что вообще такое «освобождение памяти»? Это отметка, что начиная с такого-то адреса, такой размер блока — свободен. Отметка, опять таки, в какой-то структуре внутри ОС. Как это сейчас принято делать, списки? Деревья?

То есть, всё вот это — это просто изменение данных в системных структурах. Больше никаких физических действий не происходит.

Что изменятся если у нас диск от ОЗУ неотличим? Правильно — ни-че-го.
И это «неотличимо» работает давно, называется «виртуальная память». Если верить википедии, понятие «Вритуальная память» существует с 1956 года. На практике используется с 1969.

То есть, какова бы ни была среда выполнения, ОС (эта самая среда),

— запускает процессы
— выделяет им ресурсы — malloc
— умет освобождать конкретные ресурсы по просьбе процесса — free
— умеет освобождать все ресурсы, по завершению процесса — я думаю, что сама запускает free по всему списку

И мы только что разобрались, что всё это, просто суть данные в каких-то таблицах/списках/деревьяъ/структурах, как там оно реализовано.

Что такое «протекаюзщая программа»? Программа, которая не вызвает free. Но с точки зрения ОС, это означает, что где-то там в её структурах, есть данные про эти куски памяти. И как только программа говорит system.exit() — ОС знает, все эти ресурсы свободны, и сама вызывает free.

Кто или что помешает в ОС Фантом реализовать system.exit()?
bormotov
0
На эту тему автор пишет уже больше десяти (двадцати?) лет, в разных местах.

процессов в традиционном понимании в этой ОС нет


Вот у вас сейчас, в классической ОС, программа — это такой файл на диске. Она «остановлена»? Что случается, если вы её «запускаете»? Просто подумайте. А теперь представьте, что диска как такового нет — всё некая память, которая не пропадает сама по себе. Как изменится ваш ответ на тему «запуск программы»?

Разница между «запущенной программой» и «незапущенной», только в простом факте: «запущенная» программа получает некие события «извне», и может сама какие-то события генерировать, и куда-то там отправлять. Например запросить кусок памяти, обратиться по сети к какой-то другой программе.

Что означает для программы «завершила работу»? Перестала обрабатывать события извне. По своей внутренней воле. И перестала сама генерировать события. Последнее событие, которое она сгененрировала — сообщила системе — system.exit(0)
bormotov
0
Только программы периодически перезапускают.


при невозможности рестарта процесса


Любой объект можно создать когда нужно, а когда не нужно — убить.
С чего вдруг какие-то процессы в Фантоме станут неубиваемые или неперезапускаемые? Кто запретит? Таки лично dz будет приходить и говорить, что грешно процессы перезапускать?

Особенно странно звучит эта гипотеза в рамках концепции платформы, которая принципиально 100% managed.
bormotov
0
этот мой «гипотетический пример» — он везде вокруг. По крайней мере, пока Фантом не начал массовый захват мира ;)

Но вы опять по какую-то ОС — забудьте. В случае Фантома, если довольно грубо, то ОС — это современная программа. Программы Фантома — нити внутри современной программы. Нить возвращает программе стек? Остальные все ресурсы во владении самой программы? Вот так и будет в Фантоме. Нет никакого ни юзер- ни другого спейса. Прослойка VM и сразу железо.

Если вы сейчас в программе запускаете нить, что бы она сделала для вас полезную работу, нить в ходе этого нажрала гигабайты памяти, что происходит?
Либо, ссылка на эти гигабайты осталась в стеке, после освобождения стека протухла, и гигабайты подберет сборщик мусора, или нить отдала «полезное нажратое» вам в качестве результата — «на, слушай, сам выкинь, да!» (анекдот про бумеранг)
bormotov
0
Разница в том, что при закрытии приложение освобождает утекшие ресурсы


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

Куда переносятся какие ресурсы из нити? Вот будет всё то же самое.

Сейчас, например у jre память можно жестко ограничить при запуске, и процесс внутри, будет получать отлупы.
Всё ровно то же будет происходить в Фантоме, никакой качественной разницы не будет.
То, что условно памяти станет несколько ТБ, я заметной разницей не считаю ;)

Попробую совсем тезисов: архитектура фантома не дает каких-то там заметных преимуществ в автоматическом управлении ресурсами. Наличие мозга у программиста всё еще требуется, аккуратность работы — всё еще важна важна. В то же время, каких-то заметных недостатков тоже нет — если программист с мозгом и аккуратен, на него не свалятся какие-то внезапные проблемы.
bormotov
0
Сейчас утечка памяти живёт до закрытия приложения. Если файловой системы нет, утечки не на виду.

Если утечка не на виду, может это и не утечка вовсе?

Вопрос был в том, не является ли архитектура Фантом особенно к ним уязвимой.

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

Хотя, за счет более стройной архитектуры в целом, может оказаться, что инструментарий для мониторинга/анализа и может быть даже автоматических каких-то реакций в таких ситуациях, будет проще реализовать.
bormotov
0
Возьмем, например, String. Это data class? Он может протекать?
Возьмем, например, какой-нибудь BinaryTree. Это будет data class? Оно сможет протекать? Там будут виртуальные методы? Или, с другой стороны — нужно ли требовать где-то у таких классов отсутствие виртуальных методов?

«Нет сериализации».
Те же самые String и BinaryTree — их совсем нельзя будет сериализовать? Кто-то запретит мне из них сделать json или xml? Так и представляю, приходит dz и ufm, и грозят пальцем «ай-ай-ай, не сериализуй! Грешно! Будешь всю жизнь в SOAP долбиться!»

Что сейчас происходит, если программист забывает какую-то ссылку внутри?
Скорее всего в случае Фантома будет ровно то же самое. И просто «добавить персистентность» и «избавить от сериализации» на уровне системы, не сделает автоматически всех программистов умными.

Как и «добавь вывод типов» — тоже. Как и «добавь зависимые типы» — тоже не сделает.
Инструменты со строгой типизацией помогают человеку меньше ошибаться.
Вывод типов компилятором — помогают меньше писать руками.
Зависимые типы — позволяют исключить еще целый класс ошибок, и еще меньше писать руками. Чем больше вы добавляете мозгов/математики инструменту на уровне концепции, чем больше инструмент может проверить, по сути сужая область в которой программист может нафигачить — тем меньше ошибок.

Но персистентность — это ведь ортогональная штука ко всему этому. Отсутствие сериализации — это просто выкидывание целого класса тупой работы. Это уменьшает количество ошибок, но не концептуально, а рутинно — меньше работы — меньше ошибок.
Да и потом, давно уже всю сериализацию генерируют, не?
javaxb, protobuf, и вот это всё.
Но если у меня есть «документ», как суть, как понятие, он же как-то будет в системе представлен? Будет это data class, или будет это вполне себе smart class — у которого будет внутри какого-то метода while true, но не такой явный, который моймает компилятор, а заумный?

Если человек хочет прострелить себе ногу — он её прострелит.
Могу только повторить тот пример, с которого начал — представьте сейчас любую программу на managed платформе, у которой внутри запускаются отдельные потоки. Вот это примерно то же самое. Просто у современных программ есть какие-то отдельные концепции типа «файл», «база данных», «сеть», а Фантому эти концепции ненужны. И просто не нужно будет мне из какого-то BinaryTree, делать BinaryTreeJson, но не потому, что dz меня предаст анафеме, а просто с точки зрения здравого смысла — зачем заниматьая какой-то фигнёй, если можно прям сам объект отдать, и там всё правильно поймут?
bormotov
0
«файл» — в данном случае, суть «документ», и конечно, есть же сейчас понятие data class?

Не понимаю, как экземпляр data class может чо-то там сам решать, ну разве что только если у него будут в комплекте какие-то ACL, которые что-то там ограничат. В любом случае — он эе откуда-то взялся, его кто-то создал, и ссылку на него куда-то передал. Или вместе с понятием «владение» или просто, расрашил (полайкал, ретвитнул :)

И вот этот data class — он сам по себе протекать не может. В него кто-то может че-то напихивать — да. Но ровно так-же, кто-то другой, должен уметь проверить, че там напихали, и лишние удалить.

А код, который со всем этим работает, по-любому нужно уметь останавливать, хотя бы для того, что бы обновить на новую-свежую версию, которая «уже не протекает»
bormotov
+1
Я еще в школу ходил, игрушки были еще 2D, но люди уже понимали, что «отрисовывать» то, что не видно — нет никакого смысла. Можно сказать не «реже», а «вообще не нужно».

Пытаясь вернуться в контекст статьи — если в коллекции «поле» 30000 объектов, то перед отрисовкой нужно сделать viewField.filter(isVisible()), вдруг в итоге останется вообще один объект, потому что игрок носом уперся в стену.
bormotov
+3
вы правы, вот только «рано остановились», нужно довести эту логику до денег.

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

А практика (увы, подкрепить цифрами не могу) написания кода показывает, что функциональный оптимизировать легче. Он гораздо более наглядно передает суть «что тут вообще происходит», чем императивная лапша.
bormotov
0
Довольно часто из лаконичности и краткости следует понятность.

Это я не пытаюсь возразить вам, даже наоборот, поддерживаю — нужно очень четко решать и договариваться где когда и зачем. Потому, что вот эти самые «лаконичность краткость понятность» — очень субъективные штуки.
bormotov
0
Остановка приложения — это Uninstall.

Это как-то очень странно звучит.

Приведу простой пример, который (надеюсь) будет понятен всем:
Приложение, написанное на Java/C#/несуть. Допустим, какая-то обработка данных, которые откуда-то поступают, их как-то обрабатывают, результат обработки — куда-то складывают. Для обработки очередной порции данных, запускают 1-2, да хоть 100500 нитей, из которых в каждый момент времени может получаться довольно замысловатый граф обработки. Но по мере завершения работы, нити останавливают.

До этого места всё понятно?

Теперь, представьте, вот это гипотетическое приложение — операционка. А одна гипотетическая нить в нем — приложение пользователя. Пользователю прислали документ, он его открыл, что-то в нём исправил сохранил и окно закрыл.

Значит ли, что пользователь сделал Uninstall того куска кода, который отрисовывает окно, документ в нём, обрабатывает события итд? Очевидно — нет. Как был в бинарнике приложения кусок кода — так он там и остался. Должен ли быть «запущен» тот кусок кода или нужно «останавливать нить»?
Не знаю, но не вижу никаких проблем поступать хоть так, хоть эдак.
bormotov
+1
Согласно персистентной модели, приложение запускается один раз и на всю жизнь.


Тут нужно обратить внимание, что никто не запрещает приложению завершать работу.
«Вся жизнь» — то время, которое необходимо приложению, что бы выполнить полезную для пользователя работу.
bormotov
0
то есть это SQL Server performance monitoring
bormotov
0
потратил минуту на сайте Quest Software не нашел даже раздел где брать на посмотреть.
Только маркетинговое бла-бла-бла, как круто они умеют всё мониторить.
bormotov
+1
Боты, увы, это самый очевидный «ответный шаг», как только будет рейтинг, и этот ответ обесценит сам рейтинг.

А сейчас еще модно нейронки тренировать, не удивлюсь если кто-то решит сделать бота на модных технологиях :)
bormotov
+1
конечно, всякие очки начнут иметь смысл как только будет глобальный рейтинг.

Думаю, по ходу дела, еще может всякое напридумываться, по каким критериям ранжировать.
Поэтому общая идея такая — все метрики по ходу игры куда-то складывать.

еще навскидку
— количество таймаутов
— сколько раз сдавался
— сколько ходов сделал до выигрыша
— сколько ходов «продержался», максимум, минимум, среднее

в общем, казалось бы, такая простая игра, но перевод её в многопользовательскую открывает бездны :)

Одна беда со всем этим — достаточно просто пишутся боты, да и математика для бота не сильно сложная. По ходу игру совсем примитивная-локальная, в «сложных» — посчитать вероятности…

В любом случае — спасибо, вспомнил юность, залип на час

— а если сделать командную… :))))
bormotov
+1
и да, конечно общее затраченное на раздумья время тоже как-то можно учитывать в рейтингах
bormotov
0
не-не-не, когда играют двое, из расстановки флагов можно получать более точную оценку кто лучше играет.

Хотел дописать, что к глобальному рейтингу, нужно не просто победы считать, а очки.

Например, противник подорвался на мине, которую я правильно пометил флагом — мне плюс дополнительный балл.
Или, я открываю одним нажатием несколько клеток (это при правильной расстановке флагов) — тоже можно как-то болше баллов давать.
bormotov
+1
Очень сложно в одной статье описать целый язык. Даже если вкратце пробежаться по синтаксису, возможностям и особенностям, то получится очень большой текст, фактически — перепечатка документации по языку.


Познакомьтесь со статьями на википедии про Lisp, Smalltalk, Scheme, Python, Ruby… Список можно продолжать, пока языки не закончатся… APL, K. J…

Ни одна из этих статей не являются документацией по языку, но дают хорошее представление (и не только)
bormotov
+2
Давайте посчитаем, мне так сложно сравнить. Возьмем более круглые значения для ровности

10 типов документов, 60 событий в минуту (1 в секунду). 3600*10 строк в час? 24 часа?
864000 строк в сутки?

Взял навскидку из багрепорта посылку, там логи порядка 100М за сутки — 440803 строки, например. Похоже на вашу ситуацию? Всего в два раза меньше.

У нас «правильное логгиирование» обязует разработчика использовать loglevel'ы, вполне опредленным образом

* DEBUG — то, что будет читать только разработчик
* INFO — то, что может почитать инженер поддержки, но не факт
* WARNING — то, что читает инженер поддержки
* ERROR — то, что обязательно читает инженер поддержки, и на что реагируют алерты.

итак, из этик 440К строк:

* DEBUG — ~356K
* INFO — ~81K
* WARNING — 3K
* ERROR — 86 строк

Еще раз — я не против ELK. Даже очень за. Но вот сейчас мне хватило просто grep и wc -l, что бы выдать вам эти цифры. Ровно так-же, зная имена модулей, и дальше по архитектуре приложения, я могу получать простым grep'ом нужные срезы. Вот, например, есть у нас некий «ServiceManager» — он в этот лог написал ~253K строк. И в то же время, было всего 123 строки, когда этот самый «ServiceManager» писал «Can't connect to host».

Это просто одна команда:

grep ServiceManager" some.log | grep «Can't connect to host» | less

Вы говорите, что практически невозможно написать такую команду?

bormotov
0
Писать логи — легко. Ниже написал комментарий «в общем виде». Складывание в ELK и прочие инструменты — конечно, но эти инструменты должны облегчать жизнь вполне конкретным людям. То есть задачу «писать правильно лог» — нужно рассматривать как одно из требований к продукту.

> В результате все равно гиганские стены текста.

Простите, не понимаю. Лог, а по-русски, «протокол» — это такой поток записей. Причем, в общем случае, на эти записи накладываются совсем небольшие требования, типа «иметь отметку времени» и «иметь loglevel». Если вам этих требований для структурирования мало — никто не мешает в log message добавить то, что облегчит вам фильтрацию. Хоть grep'ом, хоть ELK, хоть еще чем-то.

Не вижу вообще никаких проблем. Если это ваш продукт — вы сами пишите логи для себя.
Когда люди готовят для себя еду, они же не насыпают туда килограммы соли или перца, что есть невозможно? Бывает, в первый раз сыпанул, но есть же второй раз, третий раз…
bormotov
0
Что бы правильно писать лог, нужно как можно более четко понимать зачем. Если говорить более формально — какой у вас общий процесс (вашей работы) работы, в котором потребуется читать этот лог?

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

Инструмент разработки — не важен, даже если никаких удобных библиотек нет, и у вас просто вывод строк в stdout, туда можно и нужно писать так, что бы достигать цель. Навскидку, целей две:

* оперативное оповещение о проблемах
* разбор инцидентов

После того, как с целями разобрались, нужно выяснить, кто пользователи. Опять-же, навскидку

* дежурный службы поддержки
* сервисный инженер
* разработчик

Далее, для известных целей и пользователей, нужно определить объем и характер информации в логе, который необходим, и объем и характер информации, который достаточен.

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

Аналогично можно предположить, что для сервисного инженера, который будет разбираться с инцидентом, километровые traceback'и мало что скажут, а вот возможность четко понять какой модуль (с прикладной точки зрения) и в какой момент поломался, или что именно сделал «не так» — важно.

И точно так же можно предположить, что разработчику, который будет чинить баг в коде, километровый traceback с номерами строк в исходниках, может облегчить локализацию проблемы, а так-же значения аргументов при вызове функций и что там ему еще нужно будет, что бы смоделировать у себя ловить трудновоспроизводимую ошибку, написать для неё тест, починить, и отдать исправление в релиз.

Когда вы распишите эти три момента (цели, пользователи, требования каждого пользователя), будет более-менее четка картина, что, когда и как писать логи.

Какие сообщения на какой loglevel выводить, нужны ли логах traceback'и или нет, и вот это всё.

После «пилота», непременно нужно провести фазу тестирования: смоделировать проблемы, взять пользователя, выдать ему лог с зафиксированной проблемой и получить обратную связь.

bormotov
0
если вы копаетесь в логах несколько часов — значит вы их неправильно пишите.

даже если на продакшине всегда включен DEBUG — кому-то использовать grep религия не позволяет?
bormotov
+1
написать всегда есть смысл — затрат мало.
bormotov
0
Подавляющее большинство лабораторного оборудования имеет интерфейсы для подключения в ЛИС/МИС.
RS-232 наиболее распространён, но уже давно появляются приборы у которых свой отдельный эзернет, и подключение по tcp. Внутри этого rc-232/tcp бегает или ASTM, или HL7, или что-то своё. В любом случае, производитель прибора выдает спецификацию, и почти всегда работает так, как в спецификации.

На счет морфологии, бекмановская гематология одна из наиболее продвинутых. Но насколько я смог заметить, полностью от микроскопии никто не отказывается. Если прибор выдает патологию, то очень вероятно, что лейкоцитарную формулу будет считать еще и врач глядя в микроскоп.
bormotov
+3
про оракловый оптимизатор вообще никаких интриг:

Дж. Льюис, ORACLE: Основы стоимостной оптимизации.

На русском издавали, например «Питер», аккурат десять лет назад.
bormotov
+2
Планировщик запроса — это просто алгоритм. Он может быть плохим, конечно. Книжка которую я читал про оракловый, охватывала версии оракла 8, 9, 10, и автор прям наглядно показывал, как планировщику от версии к версии добавляют мозгов, и ситуации, когда эти «более умные» мозги принимают решения хуже, чем было.

Меня удивляет отношение человека, с опытом 10 лет.

В моём понимании, «планировщик запроса» — это такая данность, как восход Солнца. И довольно глупо ругать Солнце, что оно утром светит в окно и мешает спать. Самое простое — добавить к «окно на восток», хорошие светонепроницаемые шторы.

И кажется, профессионал должен не ругать Солнце, а сразу высказать, какие шторы, для каких случаев, и почему.




Кстати, отдельный вопрос — когда вообще нужно собирать результаты из 20-ти таблиц? Можно хотя0бы намекнуть на прикладную область, и что за данные такого рода запросом вытаскивали?

bormotov
+1
Про оракловый оптимизатор даже книга отдельная есть, где не просто рассказывают «как оно работает», а на каждый аспект набор тестов, которые можно взять и по-запускать на своей базе.

После чтения такой книги, очень странно слышать слова «негативные отзывы от специалиста с 10 лет работы».
bormotov
0
Решил авторизоваться через fb



Это прекрасно.
bormotov
+2
им не нужно повышать вот так свой уровень.

Сейчас «развлекаюсь» тем, что у новым задачам линкую писанные мною несколько лет назад, на эту же тему.
bormotov
0
У нас в рамках компании один стиль. Сколько бы проектов не было.

не обращая внимания на несущественные особенности

Вы считаете, что мои слова «стиль затрагивает не только форматирвание» — это несущественные особенности, и не обращаете на них внимание?

Есть еще интересный факт — умение читать разные стили, совсем не избавляет от требования писать в рамках одного проекта в одном стиле (который принят в этом проекте). Даже не касаясь производительности и бизнес-показателей — это элементарное уважение к коллегам.

Точки с запятой в конце строк — смешно, а вот, скажем, алиасы таблиц в sql-запросах, единый подход к выбору имен идентификаторов — тоже смешно? Идем дальше — единый порядок аргументов функций для API?

Вот, из недавного, что меня удивляло: модуль, который дает удобные методы работы с целым пластом данных. Среди них всякие выборки/срезы. Среди них — есть срезы по времени. Для меня очевидно, что если функция принимает аргументы date_start, date_end, то у всех функций с аналогичной семантикой в этом модуле (а лучше, во всём проекте), если есть два таких аргумента, они как минимум должны называться одинаково.
А еще, например, в Oracle PL/SQL, нет удобного способа вернуть курсор с данными поэтому у процедур из которых нужно возвращать данные, последний аргумент что-то типа P_RC IN OUT REF_CURSOR.
Хорошее требование, всегда этому аргументу давать одинаковое имя? Или RC, RC1, P_RC, P_RC1, P_CURS, CUR — нормально, все ведь прочтут, все натренировали толерантность и не испытывают боль?

Пример с RC/итд из реального исходника -
 grep "OPEN .* FOR" some_source.pkg
— 91 штука всего, 6 разных вариантов, преобладает P_RC.
bormotov
0
Конечно художник в единицу времени приносит больше ценности бизнесу. Но если он за дополнительные 25 минут сможет заменить 250 часов работы маляров — зачем тогда маляры?

О какой толерантности может идти речь, если яркие личности со своим стилем становятся счастливее и работают эффективнее? (на минутку стал на другую сторону)

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

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

Посмотрите по ссылкам, везде разговор о стиле начинается со слов «общий стиль облегчает общение». Чем больше людей, тем важность «двигались в одну сторону» сильнее перевешивает важность личного счастья каждого, потому что количество общения внутри коллектива растет экспоненциально. И явного, и неявного — через написание-чтение кода.

Нет, я не верю, в сферических коней в вакууме, и в то, что солнце встает на западе.

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

Для бизнеса выгоднее подавлять «собственный стиль» даже выраженный в алгоритмах и архитектуре. Единственный практический способ не подавлять — «взваливать» на такого человека «всех остальных», что бы он всех тянул. Но это равнозначно тому, что у всем остальным насаждать его стиль. Иначе, если код понятен только одному человеку, то фактически один человек работает. А нужно, что бы десяток или несколько десятков.

Это же простая арифметика: если написать код красиво у «художника» занимает 5 минут, а потом у десятка «маляров», чтение кода вместо 5 минут занимает 30, то бизнес теряет 250 минут. Если «художник» потратит 30 минут на написание кода, который «маляр» поймет за 5 минут, то потери будут всего 25 минут (плюс, конечно, личное несчастье, и неудовлетворенность «художника»). А что бы бизнес ничего не терял — разрыв нужно сокращать.

Внезапно, единый стиль оформления исходника — это первый шаг к сокращению разрыва, к увеличению эффективности общения в команде. Как только команда начинает говорить на «одном языке», начинает сокращаться разрыв между «художником» и «малярами» по остальным пунктам.
bormotov
0
Для меня это, как «солнце встает на востоке», но отличный вопрос, некоторым людям нужен пруфлинк, иначе они не воспринимают, даже очевидные вещи.

Первое, что я сделал — погуглил «why styleguide matter». Но из более-менее общего сходу вылезла только статья https://www.smashingmagazine.com/2012/10/why-coding-style-matters/
на какое-то исследование не тянет совсем. Еще вылезли пачки готовых style guide, на очень много какие вещи.
Но самоеудивтельное для меня оказалось статья в википедии https://en.wikipedia.org/wiki/Style_guide
если точнее, кот этот абзац:
A style guide establishes and enforces style to improve communication. To do that, it ensures consistency within a document and across multiple documents and enforces best practice in usage and in language composition, visual composition, orthography and typography. For academic and technical documents, a guide may also enforce the best practice in ethics (such as authorship, research ethics, and disclosure), pedagogy (such as exposition and clarity), and compliance (technical and regulatory).


еще интерсная цитата нашлась в PEP-8 питоновском:
Donald Knuth explains the traditional rule in his Computers and Typesetting series: «Although formulas within a paragraph always break after binary operations and relations, displayed formulas always break before binary operations»
со ссылкой Donald Knuth's The TeXBook, pages 195 and 196.

Дальше — больше! нашелся документ 1995 года, с такими словами
The classic text on programming style remains Kernighan and Plauger The Elements of Programing Style (1974)

И к этой книге нашлась интересная аннотация (и небольшой обзор), которая начинается со слов
This book written by Brian W. Kernighan and P. J. Plauger is one of the first studies of programming style. It advocates the notion that computer programs should be written not so much to satisfy the compiler or personal programming «style», but also should strive for general «readability» and «understandability» by humans with the specific goal to make software maintenance easier.


вот еще статья, но опять-таки, не научная, без цифр
http://www.perlmonks.org/?node_id=776607

А еще нашлась ссылка на McConnel, «Code Complete», которая тоже просто книга, а не научный труд. Но там в PDF'е 897 страниц, из них последние 30 — ссылки на источники. Есть ссылка в том числе и на «The Elements of Programming Style», и например, на

Woodfield, S. N., H. E. Dunsmore, and V. Y. Shen. 1981. «The Effect of
Modularization and Comments on Program Comprehension.» Proceedings of the Fifth
International Conference on Software Engineering, March 1981, 215–23

туда ссылается вот такой текст:

Woodfield, Dunsmore, and Shen conducted a study in which
graduate and senior undergraduate computer-science students
answered questions about two programs: one that was divided into
eight routines along functional lines, and one that was divided into
eight abstract-data-type routines (1981). Students using the
abstract-data-type program scored over 30 percent higher than
students using the functional version.

Конечно, это не только про форматирование текста исходника…

Думаю, коллег, которым именно нужен пруфлинк, можно смело отсылать в «Code Complete», и далее по ссылкам.

p.s. Нет, я не знаю как научно обосновать, что солнце встает на востоке
bormotov
0
а потом они подумали, что всё равно фигня получается, дали SDK для Objective C, а теперь вообще продвигают Swift. Я по времени не путаю?

Тогда еще вопрос — ну вот, Apple «отпустило», но получается пинок JS'у дали настолько хороший, что он уже сам дальше полетел?