Неправильно выразился, парсер, если ему отдавать сразу все работает очень медленно.
А заменить в джаве final static нельзя (на самом деле можно, но это будет слабоумие и отвага).
Как это работает, как парсится. Можно поподробней?
override def nextToken(): Token = {
if (hasEnqueuedTokens) dequeueToken
else super.nextToken() match {
case x: RScanToken if x.getType == foldOpen => buildFoldToken(x)
case x: Token => x
}
}
buildFoldToken рекурсивно собирает все токены начиная с { и по }, создает для них токен с адресом от { по }, внутри имеет список токенов, которые он поглотил, включая такие же фолды.
А уже в ANTLR идет так:
В итоге и обычный режим работает, и оптимизация тоже пашет. Парсить токены внутри FoldBlock можно когда потребуется. А главное, что lookahead убивается на корню, потому что он не нужен для случаев, когда альтернативы быть не может, но ANTLR честно их ищет.
А какие языки? :)
Java.
В чем посредственность на конкретных примерах? Было бы интересно узнать, как это можно избежать. Ну и для этого они и открытые, чтобы сообщество могло их дорабатывать.
Они не SLL. Запускаешь эти грамматики на тестовом множестве (2000+ файлов), так половина минимум падает с ошибками.
Увы, но предложенное вами решение крайне медленное. Сброс кеша в джаве таким же способом не удастся реализовать, особенно, если есть многопоточный анализ. Возможно в C# как-то по другому реализованы статики.
Дано: грамматика JavaScript 2019, на вход посылаем файл в 127 кб минифицированного кода — 38 секунд на обработку, 12% gc max. Без xmx4g запускать бессысленно.
Включаем упаковку блоков в токен (создается токен, в котором есть список токенов) — 12 секунд xmx64m дает 5% gc max, при xmx128m 1% gc max, парсим блоки в многопоточном режиме на 8 ядрах — 4 секунды. ATN создается на каждый новый инстанс парсера.
Поэтапная обработка — наше все
Если под поэтапностью вы понимаете разбор одного и того же файла разными парсерами, то да, но использовать AST, создаваемый ANTLR все равно не рекомендую, слишком много лишней информации.
Java, CSharp, Python, Php, JavaScript, TypeScript, C++, C, и многие другие языки достаточно просты, что бы сделать грамматику, которая будет работать без синтаксических ошибок в режиме SLL.
Вы что-то не так делаете в вашем парсере, что требуется включать такую фичу.
Впрочем я уже видел работу анализатора Positive Tech :D Воздержусь от критики.
Так сделано, например, в грамматике JavaScript.
Открытые грамматики реализованы крайне посредственно. Иногда можно встретить хорошее решение, но в общем случае лучше написать самому сразу SLL, чем давится ALL кактусом.
Для каждого пункта было бы неплохо добавить разъяснение и примеры кода как не надо и как надо (или наоборот, т.к. советы вредные). Особенно про ATN и SLL.
Будет отдельная статья, где объясню всю кухню работы с ANTLR4 на Java, данная статья была больше для того, что бы понять, есть ли интерес у людей к такой тематике.
override def nextToken(): Token =
if (hasEnqueuedTokens) dequeueToken
else if (templateMode) nextTokenTemplate
else nextTokenNonTemplate
private def nextTokenNonTemplate: Token = {
val token = _input.LA(1) match {
case '`' => parseTemplateLiteral
case _ => super.nextToken()
}
if (token.getChannel == Token.DEFAULT_CHANNEL)
lastToken = token
token
}
private def nextTokenTemplate: Token =
if (!insideTemplate) {
if (_input.LA(1) != '`')
throw new IllegalStateException("Template string must start with '`' character")
insideTemplate = true
val token = createToken(_input.index(), 1, templateLiteralDelimiter, Token.HIDDEN_CHANNEL)
templateStartToken()
token
} else if (_input.index() == closePosition) {
if (_input.LA(1) != '}')
throw new IllegalStateException("Close position is not at '}' character")
val token = createToken(_input.index(), 1, templateLiteralDelimiter, Token.HIDDEN_CHANNEL)
templateMiddleOrStopToken()
token
} else nextTokenNonTemplate
Это кусок кода для анализа TypeScript/JavaScript, гораздо выгоднее проанализировать собственными руками последовательность символов и сделать токен с шаблонной строкой, чем нагружать лексер, тем более, что в случае вложенности будут проблемы с анализом выражений. Для правила startTemplate токены TemplateLiteral* создавались не лексером, а руками. Код у правил удалил, потому что при просмотре превращается в кашу.
//////////////////////////////////////// Main Entry Points
startTypeScript
: typeScriptStmtList EOF
| EOF
;
//////////////////////////////////////// Secondary Entry Points
startTemplate
:
TemplateLiteralStart
// опционально, потому что TemplateLiteralStart может содержать окончание
(
expression[true,_yield,await]
(
TemplateLiteralMiddle
expression[true,_yield,await]
)*
TemplateLiteralStop
)?
EOF
;
parseTemplateString — находит индекс последнего символа шаблонной строки с учетом вложенности.
Уже после этот литерал парсится отдельно. Например вот так:
final def parse(): RLangOp = {
val result = parseInitial()
enqueue(result.folds ++ result.templates)
while (jobs.nonEmpty) {
val _j = Seq.empty ++ jobs
jobs.clear()
parseItems(_j)
}
result.op.asInstanceOf[RLangOp]
}
Внутри parseItems все folds, templates так же добавляются в очередь jobs
Полагаю, что с комментариями можно такую же штуку провернуть.
Должно быть что-то в таком духе у вас:
Если поиграетесь с режимами работы лексера (mode — его можно устанавливать до выполнения), то можно все в одном уместить, и с парсером так же удастся сделать.
Правила можно легко вызывать вот таким образом:
final def invokeRule[T](ruleName: String): T = resultOfRule[T](ruleName)
private def resultOfRule[T](ruleName: String): T =
resultField[T](getClass.getDeclaredMethod(ruleName).invoke(this))
private def resultField[T](value: AnyRef): T =
value.getClass.getDeclaredField("result").get(value).asInstanceOf[T]
Делаешь токен с новым типом, сохраняешь в него список токенов, регистрируешь каким-то образом токен, что бы можно было узнать о нем. Далее в местах, где есть блок, добавляешь альтернативу с новым типом токена. После анализа файла создаешь парсеры для сохраненных токенов и разбираешь их, пока не останется в регистре элементов. Лексер работает только один раз.
И вуаля, вместо 4 ГБ хипа хватает 128 мб.
Когда тебя каждые пять минут гоняют от одной задачи к другой — не поднимите. Вот вообще никак. Кроме истерзанных нервов ничего не будет. Да еще и при увольнении выскажут много чего интересного.
Если вы про нормальное производство (а не артель «Иванов и собутыльники»), и достаточно сложное изделие (а не про какую-нить втулку или шайбу), то у токаря есть технологическая карта на изделие, разработанная технологом, проверенная (не всегда, шутка про огурцы все так же актуальна;)) и подписанная кучей людей, и которая гарантирует результат (если ее не нарушать).
И вот технолог — это и есть тот человек, который получает/выясняет требования к изделию, убирает противоречия (в частности, с физическим миром и его законами), и планирует, как собственно это изделие должно быть сделано. И чтобы стать технологом, стажа токаря категорически недостаточно — нужно оттрубить несколько лет института (со всеми мозгодробительными предметами типа сопромата и материаловедения), а потом еще неопределенное количество лет — получать практический опыт (желательно в команде с уже состоявшимся технологом).
Технолог — это не токарь, и разница слишком огромна, примерно как между кандидатом наук и доктором наук.
К сожалению, в наших институтах ИТ архитекторов не учат (во всяком случае, мне об этом ничего не известно), так что приходится догоняться самостоятельно
Потому что вариативность того, с чем новоиспеченный ИТ архитектор может столкнуться так велика, что к тому времени, как он обучится — будет никому не нужен. В случае же отсутствия опыта работы "в поле" он вообще будет нести чушь и ахинею. Требовать невозможное от конкретных, уже существующих технических решений. Любой технолог по крайне мере в теории на 100% осознает как и что будет делать токарь Вася. И он может с гарантией сказать на что тот или иной токарь будет способен — от того и идут категории. Процесс унифицирован и стандартизирован до нельзя.
И как раз отсутствие понимания того, как работает программист у любого архитектора и приводит к появлению новых "чрезвычайно эффективных фреймворков и стандартов". Всякими js фреймворками уже весь инет забит, и выходят они каждый день — подаются как убийца предшественника и вообще единственный тру-фреймворк.
Подход, при котором вы полностью доверяете кодерам продукт на разработку почти всегда заканчивается бойлерплейтом и гавнокодом — что напрямую говорит об отсутствии квалификации. Если ваши архитекторы в упор не видят с чем исполнители будут иметь дело — то продукт будет завален костыльными решениями, гавнокодом другого рода — гавноархитектурой. И если проблему с отдельным кодером решить можно, то с архитектором — слишком дорого. Потому ОС Windows NT как технология — отличная штука, но даже с не особо хорошей реализацией — она реально хороша (говорю как заядлый линуксоид). А какая-нибудь поделка сделанная на коленке для полноценной демонстрации идеи, с самым идеальным кодом — кусок ненужного гуано — потому что архитектура в 100% не продумывается. Хотя за обе программы платят деньги.
И последнее, аналогом технологической карты для кодеров, которую делали бы ИТ архитекторы — это и будет сам код или блок-схема. Но в том-то и дело, архитектор не пишет кода, он программирует программирование других людей в заданном направлении. А вот технолог полностью определяет всю цепочку действий, которые осуществит конкретный токарь.
При всем уважении, токарному делу обучится — надо только прослушать курс (есть теоретическая база), а затем несколько лет тренировать руки под однотипные операции. Тогда да, будешь токарем первой категории, ну или станок купить.
С программистами такого же не замечал, сидит человек годами, а как писал говнокод, так и продолжает. Купить станок не поможет, потому что задачу автоматизации по какой-то причине до сих пор не смогли автоматизировать. Правда не ясно кто будет заниматься автоматизацией автоматизации процессов. Неужели программисты?
К тому же, выточить нужную деталь можно многократно меньшим количеством возможных последовательностей базовых действий. Даже обработка кнопки ОК в диалоге делается разными способами, хотя сама по себе она является базовым действием в рамках UI.
А теперь представьте себе что-то в духе сделай Х, потом Y, иначе Z, где каждое действие выполняется неопределенное количество времени, да еще требует какие-то сторонние результаты. Звучит просто? Когда встретитесь — увидите столько подводных камней.
Про задачи в стиле "обработать много гб данных, быстро и памяти много не требовать" говорить не хочется даже.
Токарь не имеет дел с задачами, требования которой противоречат друг другу, у программиста такое может быть, как раз из-за того, что отношение как к какому-то быдлу, мол можно за 30-70к нанять джуна и он быстро задачу решит нам. А потом во всем оказываются виноваты конечно же программисты. ПМ непогрешим, а тех дир вообще святой.
Однако в защиту товарища хотелось бы упомянуть, что обычно у нас капиталисты говорят о каких-то рисках и прочее, однако вот оборотной стороной (прибылью) никогда не делятся с работниками.
Не про безответственное отношение сотрудника, а про любителей каждую проблему выдавать за срочную и исключительно по вине сотрудника (неоплачиваемую).
Но опять же, лично мое мнение, что возможность вызвать сотрудника в случае ЧП в любое время — это реально важно. Факторы бывают разные. Невозможно все предусмотреть на всех уровнях.
Вы уже сами описали, что смешали работу нескольких специальностей.
Я же описывал именно "возможность" напрягать мозги в одном направлении в течении долгого времени. По опыту — максимум возможностей — 8 часов, и то после тренировок. И кстати результаты совпадают с общественной практикой, люди вообще больше 8 часов в день не могут продуктивно работать над чем-то в течении всего года. Замечу, речь именно о среднесуточной нагрузке в течении года, а не "две недели 60 часов отработал, а потом неделю отдыхал".
Когда есть возможность смешивать работу — ревью, очистка, отладка и т.д. — это облегчение работы.
аналитика, менеджера, программиста, тестировщика и DevOps.
При наличие более узкой области работы — возможно и получалось бы больше погружаться, хотя и тогда от постоянного изучения никуда не денешься, а вот со стороны заказчика это выглядит как конструктор собрать из уже готовых деталей — и на что там еще можно время потратить как не на отлынивание от работы!
Значит вы пока не работали над проектами, где один человек уже не в силах справляться со всеми этими функциями.
Но в целом — да. У нас так хаят "неквалифицированную рабочую силу", что забывают насколько "заказчики" бывают недалеки и неквалифицированны вообще во всех сферах кроме "заплатить меньше, получить больше".
Тоже посчитал — 3-4 часа в день именно на написание кода.
Зависит от тренировки. Если начинал с самого детства, то лет за 10 можно и 6-8 часов в день выдерживать. Зависит еще сильно от общего физического состояния.
В 14 лет с трудом выжимал из себя 15-40 минут непрерывной концентрации на коде — поэтому везде ходил с блокнотом и карандашом — писал всякую хрень. К 30 годам 6 часов непрерывной умственной нагрузки — даже усталости нет.
Однако при приближении к 8 часам есть снижение всех когнитивных навыков, т.е. вообще всех, падает реакция, глаза болят и висок ноет (левый). По 7-8 часов в день больше 14 дней подряд не выдерживаю, нужен отдых. Силой никто не гонит, просто "хочется еще".
Если так весь год работать, то нужен отпуск примерно 48 дней.
Субъективно, согласен — но пища для размышлений есть.
Поняв что надо сделать — надо понять как это сделать
Так ведь уже сказали, что декомпозиция осуществлена. Все остальные операции — уже очень легкие и не требуют существенного труда.
Концентрироваться на активной интеллектуальной задаче более 3-4 часов в день — значит накапливать усталость.
Описал выше. Тренировка и общая физическая подготовка. Стоит обратить внимание на ваше питание. Почитайте про то, как маленькие улучшения коммулятивно дают прирост в разы.
Я сейчас стараюсь разбивать свой рабочий день на две части по 3 часа
Такой же подход, отвлекаюсь на приготовление обеда и т.д. Отвлечение на другую деятельность лучше всего позволяет мозгу отдохнуть.
У многих же заказчиков, полное впечатление, представление о программировании как о копании траншеи — от забора до заката. Причем сразу — сел и давай кодить…
"Многие" даже траншеи не копали. На прошлой работе начальник вполне легко мог отвлечь посреди задачи, или вовсе что-то обсуждать.
Это не проблема кодинга, а проблема воспитания людей и коммуникации между ними. Вы же не сможете в деталях объяснить быт и труд шахтера? Каждый человек живет в своем мире, просто у кого-то он размером с горошину — представления о других людях соответственные.
Было время, когда маленькие одноклеточные "засрали" всю планету кислородом, от чего началось глобальное похолодание и массовое вымирание этих одноклеточных. Вся планета была покрыта ледяным щитом.
Подход при котором для начала люди хотя бы привели вычисления того, что данный подход действительно дает больше производства кВт энергии на каждый затрачиваемый кВт энергии.
Подход, при котором с небес для начала на землю спускаются и оценивают то, что есть на самом деле, а не то, во что хотелось бы верить. Земля усеянная ветряками и солнечными панелями — это утопия. Этот источник ЭЭ сугубо нишевый и никогда не сможет быть, как вы уже сказали, конкурентноспособным по отношению даже к грязным ТЭЦ, от которых необходимо избавляться, так как углеводороды лучше тратить на бытовую химию — те же пластики. Причем это еще вопрос, кто загрязняет среду больше ТЭЦ или производство панелей и ветряков, которые менять надо чуть и не каждые 2 года, тогда как ТЭЦ нуждается только в смене фильтра. Все эти шумихи сейчас существуют только потому, что на это тратятся огромные деньги в виде дотаций и прочих субсидий.
Количество людей можно легко вычислить на основе оценки количестве энергии (общей) поступающей в систему под названием "Земля". Так как основным источником является Солнце, а остальное скорее всего не составляет и 1%, то ими можно для упрощения пренебречь.
Получив оценку входящей энергии — нужно определить, сколько требуется каждому человеку для того, что бы жить. Таким образом и вычисляется максимально допустимая "наивная" оценка. Почему наивная? Потому что человечество не всю энергию само поглощает. Но она хороша тем, что это даст число, при котором последствия от перенаселения станут необратимыми и войнами и геноцидами уже ничего не исправишь, дает терминальную оценку, которую вполне можно разделить на 10, для гарантии безопасности человечества и использовать как предел численности населения. Вас такой ответ устроит? Заранее прошу прощения, что не привожу конкретную цифру, так как не обладаю точными исходными данными относительно того, какой поток энергии от солнца падает на землю. Особенно если учесть, что он является функцией от множества параметров.
Надо понимать, что солнечные панели и ветряки вместе с эрозией песчаных побережий для песка и загрязнением окружающей среды, вследствие добычи редкоземельных элементов, появятся сами, причем разумеется без того, что идет "вместе".
Все больше и больше статьи напоминают утопии для успокоения людей, не знающих ничего об инженерном деле. Надеюсь, что ухудшение инженерной культуры в современном обществе — всего лишь корреляция.
Так все же вопрос, откуда солнечные панели? И откуда возьмутся сотни тысяч квадратных километров площадей с солнечными панелями для каждого такого экополиса? Кто будет их обслуживать? Если автоматика, то кто будет обслуживать армию этих автоматов?
Если же сотни тысяч людей в городе не нужны… то вопрос, почему в этих городах будет жить пара тысяч человек? Куда остальные денутся? "Не впишутся в рынок"?
Продолжение идей "золотого миллиарда"? Да даже для него потребуется такой парк ветряков (которые не всегда работают), и настолько огромные площади, занятые солнечными панелями, что даже современная экономика их не сможет поддерживать.
И прошу, оставьте ваши шутки про "сахару в панелях", один песчаный шторм и все ваши панели можно либо в мусор отправлять, либо чистить придется. Кто этим займется?
И вопрос, куда девать отработанные солнечные панели? Перерабатывать? Энергии не хватит. На изготовление-то уходит море ЭЭ, а вы еще переработку желаете.
Неправильно выразился, парсер, если ему отдавать сразу все работает очень медленно.
А заменить в джаве final static нельзя (на самом деле можно, но это будет слабоумие и отвага).
buildFoldToken рекурсивно собирает все токены начиная с { и по }, создает для них токен с адресом от { по }, внутри имеет список токенов, которые он поглотил, включая такие же фолды.
А уже в ANTLR идет так:
В итоге и обычный режим работает, и оптимизация тоже пашет. Парсить токены внутри FoldBlock можно когда потребуется. А главное, что lookahead убивается на корню, потому что он не нужен для случаев, когда альтернативы быть не может, но ANTLR честно их ищет.
Java.
Они не SLL. Запускаешь эти грамматики на тестовом множестве (2000+ файлов), так половина минимум падает с ошибками.
Увы, но предложенное вами решение крайне медленное. Сброс кеша в джаве таким же способом не удастся реализовать, особенно, если есть многопоточный анализ. Возможно в C# как-то по другому реализованы статики.
Дано: грамматика JavaScript 2019, на вход посылаем файл в 127 кб минифицированного кода — 38 секунд на обработку, 12% gc max. Без xmx4g запускать бессысленно.
Включаем упаковку блоков в токен (создается токен, в котором есть список токенов) — 12 секунд xmx64m дает 5% gc max, при xmx128m 1% gc max, парсим блоки в многопоточном режиме на 8 ядрах — 4 секунды. ATN создается на каждый новый инстанс парсера.
Если под поэтапностью вы понимаете разбор одного и того же файла разными парсерами, то да, но использовать AST, создаваемый ANTLR все равно не рекомендую, слишком много лишней информации.
Java, CSharp, Python, Php, JavaScript, TypeScript, C++, C, и многие другие языки достаточно просты, что бы сделать грамматику, которая будет работать без синтаксических ошибок в режиме SLL.
Вы что-то не так делаете в вашем парсере, что требуется включать такую фичу.
Впрочем я уже видел работу анализатора Positive Tech :D Воздержусь от критики.
Открытые грамматики реализованы крайне посредственно. Иногда можно встретить хорошее решение, но в общем случае лучше написать самому сразу SLL, чем давится ALL кактусом.
Будет отдельная статья, где объясню всю кухню работы с ANTLR4 на Java, данная статья была больше для того, что бы понять, есть ли интерес у людей к такой тематике.
У лексера можно переопределить обработку токенов:
Это кусок кода для анализа TypeScript/JavaScript, гораздо выгоднее проанализировать собственными руками последовательность символов и сделать токен с шаблонной строкой, чем нагружать лексер, тем более, что в случае вложенности будут проблемы с анализом выражений. Для правила startTemplate токены TemplateLiteral* создавались не лексером, а руками. Код у правил удалил, потому что при просмотре превращается в кашу.
parseTemplateString — находит индекс последнего символа шаблонной строки с учетом вложенности.
Уже после этот литерал парсится отдельно. Например вот так:
Внутри parseItems все folds, templates так же добавляются в очередь jobs
Полагаю, что с комментариями можно такую же штуку провернуть.
Должно быть что-то в таком духе у вас:
Если поиграетесь с режимами работы лексера (mode — его можно устанавливать до выполнения), то можно все в одном уместить, и с парсером так же удастся сделать.
Правила можно легко вызывать вот таким образом:
DELETED
Делаешь токен с новым типом, сохраняешь в него список токенов, регистрируешь каким-то образом токен, что бы можно было узнать о нем. Далее в местах, где есть блок, добавляешь альтернативу с новым типом токена. После анализа файла создаешь парсеры для сохраненных токенов и разбираешь их, пока не останется в регистре элементов. Лексер работает только один раз.
И вуаля, вместо 4 ГБ хипа хватает 128 мб.
В 2020 бы заниматься разработкой поиска уязвимостей по регулярным выражениям…
Еще в 2012 году такое было.
Когда тебя каждые пять минут гоняют от одной задачи к другой — не поднимите. Вот вообще никак. Кроме истерзанных нервов ничего не будет. Да еще и при увольнении выскажут много чего интересного.
Технолог — это не токарь, и разница слишком огромна, примерно как между кандидатом наук и доктором наук.
Потому что вариативность того, с чем новоиспеченный ИТ архитектор может столкнуться так велика, что к тому времени, как он обучится — будет никому не нужен. В случае же отсутствия опыта работы "в поле" он вообще будет нести чушь и ахинею. Требовать невозможное от конкретных, уже существующих технических решений. Любой технолог по крайне мере в теории на 100% осознает как и что будет делать токарь Вася. И он может с гарантией сказать на что тот или иной токарь будет способен — от того и идут категории. Процесс унифицирован и стандартизирован до нельзя.
И как раз отсутствие понимания того, как работает программист у любого архитектора и приводит к появлению новых "чрезвычайно эффективных фреймворков и стандартов". Всякими js фреймворками уже весь инет забит, и выходят они каждый день — подаются как убийца предшественника и вообще единственный тру-фреймворк.
Подход, при котором вы полностью доверяете кодерам продукт на разработку почти всегда заканчивается бойлерплейтом и гавнокодом — что напрямую говорит об отсутствии квалификации. Если ваши архитекторы в упор не видят с чем исполнители будут иметь дело — то продукт будет завален костыльными решениями, гавнокодом другого рода — гавноархитектурой. И если проблему с отдельным кодером решить можно, то с архитектором — слишком дорого. Потому ОС Windows NT как технология — отличная штука, но даже с не особо хорошей реализацией — она реально хороша (говорю как заядлый линуксоид). А какая-нибудь поделка сделанная на коленке для полноценной демонстрации идеи, с самым идеальным кодом — кусок ненужного гуано — потому что архитектура в 100% не продумывается. Хотя за обе программы платят деньги.
И последнее, аналогом технологической карты для кодеров, которую делали бы ИТ архитекторы — это и будет сам код или блок-схема. Но в том-то и дело, архитектор не пишет кода, он программирует программирование других людей в заданном направлении. А вот технолог полностью определяет всю цепочку действий, которые осуществит конкретный токарь.
При всем уважении, токарному делу обучится — надо только прослушать курс (есть теоретическая база), а затем несколько лет тренировать руки под однотипные операции. Тогда да, будешь токарем первой категории, ну или станок купить.
С программистами такого же не замечал, сидит человек годами, а как писал говнокод, так и продолжает. Купить станок не поможет, потому что задачу автоматизации по какой-то причине до сих пор не смогли автоматизировать. Правда не ясно кто будет заниматься автоматизацией автоматизации процессов. Неужели программисты?
К тому же, выточить нужную деталь можно многократно меньшим количеством возможных последовательностей базовых действий. Даже обработка кнопки ОК в диалоге делается разными способами, хотя сама по себе она является базовым действием в рамках UI.
А теперь представьте себе что-то в духе сделай Х, потом Y, иначе Z, где каждое действие выполняется неопределенное количество времени, да еще требует какие-то сторонние результаты. Звучит просто? Когда встретитесь — увидите столько подводных камней.
Про задачи в стиле "обработать много гб данных, быстро и памяти много не требовать" говорить не хочется даже.
Токарь не имеет дел с задачами, требования которой противоречат друг другу, у программиста такое может быть, как раз из-за того, что отношение как к какому-то быдлу, мол можно за 30-70к нанять джуна и он быстро задачу решит нам. А потом во всем оказываются виноваты конечно же программисты. ПМ непогрешим, а тех дир вообще святой.
Однако в защиту товарища хотелось бы упомянуть, что обычно у нас капиталисты говорят о каких-то рисках и прочее, однако вот оборотной стороной (прибылью) никогда не делятся с работниками.
Не про безответственное отношение сотрудника, а про любителей каждую проблему выдавать за срочную и исключительно по вине сотрудника (неоплачиваемую).
Но опять же, лично мое мнение, что возможность вызвать сотрудника в случае ЧП в любое время — это реально важно. Факторы бывают разные. Невозможно все предусмотреть на всех уровнях.
Вы уже сами описали, что смешали работу нескольких специальностей.
Я же описывал именно "возможность" напрягать мозги в одном направлении в течении долгого времени. По опыту — максимум возможностей — 8 часов, и то после тренировок. И кстати результаты совпадают с общественной практикой, люди вообще больше 8 часов в день не могут продуктивно работать над чем-то в течении всего года. Замечу, речь именно о среднесуточной нагрузке в течении года, а не "две недели 60 часов отработал, а потом неделю отдыхал".
Когда есть возможность смешивать работу — ревью, очистка, отладка и т.д. — это облегчение работы.
Значит вы пока не работали над проектами, где один человек уже не в силах справляться со всеми этими функциями.
Но в целом — да. У нас так хаят "неквалифицированную рабочую силу", что забывают насколько "заказчики" бывают недалеки и неквалифицированны вообще во всех сферах кроме "заплатить меньше, получить больше".
Это решаемо, но в целом — да. Возможность хотя бы экстренно выйти на связь в случае ЧП — очень важна.
Либо же просто не работать в таких областях, где такое может произойти.
Зависит от тренировки. Если начинал с самого детства, то лет за 10 можно и 6-8 часов в день выдерживать. Зависит еще сильно от общего физического состояния.
В 14 лет с трудом выжимал из себя 15-40 минут непрерывной концентрации на коде — поэтому везде ходил с блокнотом и карандашом — писал всякую хрень. К 30 годам 6 часов непрерывной умственной нагрузки — даже усталости нет.
Однако при приближении к 8 часам есть снижение всех когнитивных навыков, т.е. вообще всех, падает реакция, глаза болят и висок ноет (левый). По 7-8 часов в день больше 14 дней подряд не выдерживаю, нужен отдых. Силой никто не гонит, просто "хочется еще".
Если так весь год работать, то нужен отпуск примерно 48 дней.
Субъективно, согласен — но пища для размышлений есть.
Так ведь уже сказали, что декомпозиция осуществлена. Все остальные операции — уже очень легкие и не требуют существенного труда.
Описал выше. Тренировка и общая физическая подготовка. Стоит обратить внимание на ваше питание. Почитайте про то, как маленькие улучшения коммулятивно дают прирост в разы.
Такой же подход, отвлекаюсь на приготовление обеда и т.д. Отвлечение на другую деятельность лучше всего позволяет мозгу отдохнуть.
"Многие" даже траншеи не копали. На прошлой работе начальник вполне легко мог отвлечь посреди задачи, или вовсе что-то обсуждать.
Это не проблема кодинга, а проблема воспитания людей и коммуникации между ними. Вы же не сможете в деталях объяснить быт и труд шахтера? Каждый человек живет в своем мире, просто у кого-то он размером с горошину — представления о других людях соответственные.
И мешали этим кодить.
Такая же фигня, людей "навешивали" на успевающих, при этом научить их было чему-то нереально из-за "пнх".
А ничего, что последствием кислородной катастрофы стало как раз оледенение, цианобактерии? И речь не про четвертичное, а гуронское оледенение.
Было время, когда маленькие одноклеточные "засрали" всю планету кислородом, от чего началось глобальное похолодание и массовое вымирание этих одноклеточных. Вся планета была покрыта ледяным щитом.
Так частная собственность же "священна". Ты чего хочешь отобрать у бедных капиталистов прибыль?
Решится все по старинке на самом деле. В начале 20 века уже проходили это все.
Подход при котором для начала люди хотя бы привели вычисления того, что данный подход действительно дает больше производства кВт энергии на каждый затрачиваемый кВт энергии.
Подход, при котором с небес для начала на землю спускаются и оценивают то, что есть на самом деле, а не то, во что хотелось бы верить. Земля усеянная ветряками и солнечными панелями — это утопия. Этот источник ЭЭ сугубо нишевый и никогда не сможет быть, как вы уже сказали, конкурентноспособным по отношению даже к грязным ТЭЦ, от которых необходимо избавляться, так как углеводороды лучше тратить на бытовую химию — те же пластики. Причем это еще вопрос, кто загрязняет среду больше ТЭЦ или производство панелей и ветряков, которые менять надо чуть и не каждые 2 года, тогда как ТЭЦ нуждается только в смене фильтра. Все эти шумихи сейчас существуют только потому, что на это тратятся огромные деньги в виде дотаций и прочих субсидий.
Количество людей можно легко вычислить на основе оценки количестве энергии (общей) поступающей в систему под названием "Земля". Так как основным источником является Солнце, а остальное скорее всего не составляет и 1%, то ими можно для упрощения пренебречь.
Получив оценку входящей энергии — нужно определить, сколько требуется каждому человеку для того, что бы жить. Таким образом и вычисляется максимально допустимая "наивная" оценка. Почему наивная? Потому что человечество не всю энергию само поглощает. Но она хороша тем, что это даст число, при котором последствия от перенаселения станут необратимыми и войнами и геноцидами уже ничего не исправишь, дает терминальную оценку, которую вполне можно разделить на 10, для гарантии безопасности человечества и использовать как предел численности населения. Вас такой ответ устроит? Заранее прошу прощения, что не привожу конкретную цифру, так как не обладаю точными исходными данными относительно того, какой поток энергии от солнца падает на землю. Особенно если учесть, что он является функцией от множества параметров.
удалено
Надо понимать, что солнечные панели и ветряки вместе с эрозией песчаных побережий для песка и загрязнением окружающей среды, вследствие добычи редкоземельных элементов, появятся сами, причем разумеется без того, что идет "вместе".
Все больше и больше статьи напоминают утопии для успокоения людей, не знающих ничего об инженерном деле. Надеюсь, что ухудшение инженерной культуры в современном обществе — всего лишь корреляция.
Так все же вопрос, откуда солнечные панели? И откуда возьмутся сотни тысяч квадратных километров площадей с солнечными панелями для каждого такого экополиса? Кто будет их обслуживать? Если автоматика, то кто будет обслуживать армию этих автоматов?
Если же сотни тысяч людей в городе не нужны… то вопрос, почему в этих городах будет жить пара тысяч человек? Куда остальные денутся? "Не впишутся в рынок"?
Продолжение идей "золотого миллиарда"? Да даже для него потребуется такой парк ветряков (которые не всегда работают), и настолько огромные площади, занятые солнечными панелями, что даже современная экономика их не сможет поддерживать.
И прошу, оставьте ваши шутки про "сахару в панелях", один песчаный шторм и все ваши панели можно либо в мусор отправлять, либо чистить придется. Кто этим займется?
И вопрос, куда девать отработанные солнечные панели? Перерабатывать? Энергии не хватит. На изготовление-то уходит море ЭЭ, а вы еще переработку желаете.