В принципе это может сработать. Стратегически "научитсья не перегружаться" и "не брать лишней ответственности" кмк работающие подходы.
Так например если хочешь в длительной перспективе уделять какой-то деятельности время "делать pet-project" / "изучать новое" / "чиатать" - хорошо работает сочетание: "делать это ежедневно" и "не нагонять, если пропустил".
Именно "не нагонять" - позволяет вернуться к необязательному (но стратегически важному делу), после вынужденного перерыва.
Это было просто невозможно большую часть истории человечества.
Мне кажется, что с такими терминами надо быть осторожными и сначала определится, что есть "истоиря человечества", ибо неясно что вы туда включаете: неолит? неолит + мезолит? верхний палеолит? палеолит? плиоцен? неоген?
ПС Вообще если послушать специолистов, то получается, что в каменном веке, скажем, общий рацион по калориям от собирательства был больше чем от охоты, но продукты охоты были "престижнее".
Позиция цельная и имеющая место быть. Пытается решить важный вопрос: как монетизировать OpenSource (а шире - как спасти OpenSource в ситуации, когда "почти все простые программы уже написаны, а чтобы писать комплексные программы нужны ресурсы").
Однако с точки зрения развития OpenSourse-проектов такая модель создаёт плохие стимулы: - а) нет стимула повышать качество ПО. - б) непонятно, как эту модель (платная поддержка и устранение багов) можно масштабировать на бОльшее число разработчиков - то есть монетизировать крупные проекты по такой системе вряд ли получится.
Судя по всему это какой-то сугубо академический подход (упоминания SSA-IR или его аналогов не нашёл, то, что они называют intermediate language основано на чём-то похожем на lambda-calculus (p.134)).
Собственно кажется, что сравнение с промышленными компиляторами, в этом случае малоосмысленно. В этом смысле отзываю изначальный вопрос про gcc - т.к. это просто два принципиально разных подхода.
ПС А может мне объяснить кто-нибудь (так получилось, что в под вашем постом, просто не знаю кого тэгнуть): почему практически все papaer-ы относятся к front-end (ну или к тому, что в промышленном компиляторе назвали бы так)?
Вы смешали несколько ситуаций в одну: 1. Не можешь вести бизнес - разоряйся, это называется "Creative destruction" или "созидательное разрушение". Собственно один из столпов капитализма. 2. Вести бизнес надо законно. Законы сейчас действительно защищают женщин. 3. Законы должны быть разумными. Законы о защите женщин неидеальны, но боле-менее разумны (хотя бы потому, что есть во всех развитых странах).
Насколько я понимаю, для коммерческого применения этот подход слегка хуже обычного, т.к. компилятор из-за огромного кол-ва проходов получается несколько медленнее
А значимо большее число проходов, в сравнении со стандартным подходом в компиляторостроении (скажем в gcc) действительно имеет место быть? Сколько проходов в типовом nanopass - компиляторе?
П.С. Спасибо, если не примете технический вопрос к содержимому статьи на личный счёт.
Всегда считал подход gcc (там не один десяток проходов и ан min-end и на back-end) превалирующим в сегодняшнем компиляторостроении (JIT-компиляторы, конечно имеют больше trade-off по скорости-качеству кода).
Объясните в чём, по-вашему, ключевые отличия nanopass от многопроходного компилятора?
Вроде бы у экономистов это общее место, просто формулируется чуть по-другому: очень существенная часть технического прогресса происходит благодаря глобализации, т.е. раньше вы каждое изделие разрабатывали (тратили человеко-часы инженеров \ технологов...) в 20 "экономических кластерах", потом в 3, теперь в одном.
Когда говорят о типах - примеры это всегда самое сложное. Потому, что вы вводите типы, чтобы сделать код более хм... разумным. Но когда вы приводите плохой пример - вы портите всё впечатление от разумных доводов. Скажем вместо того, чтобы типизировать вот эту функцию - её просто (ровно в таком виде) не надо писать никогда:
ну, если стажеры убегут с такими мыслями, значит будет тот работодатель, у которого они получат эти деньги. Верно ведь?
Ну ведь ровно так и есть. Условно взаимодействие со стажёром можно разделить на 2 этапа: 1. Натаскивание сеньором \ нач.отдела до уровня джуна - это если стажёр совсем зелёный, это чистый минус для компании. 2. А когда стажёра натаскали до уровня джуна уровня - для него вполне логично потребовать плату "в рынке".
Вот собственно и вопрос: зачем компаниям вся эта схема (если нет доступа, через базовые кафедры к заведомо хорошим студентам), если вчистую хуже пункта №2?
Среди IT-шников слишком много людей с рациональным складом мышления (к этому располагает наша работа). Поэтому многие вопросы из "хитрых психологических тестов" бессмысленны.
Приведу пару таких вопросов из своего опыта (которые должны что-то сказать психологу, но были бессмысленны для меня): - с каким животным вы себя ассоциируете: ответ "ни с каким". - этот карандаш хороший или плохой: ответ "карандаш не может быть хорошим \ плохим, это не свойство объекта".
Как программисту - мне видится большое межстрочное расстояние у этого шрифта большой недоработкой.
Т.е. получается, что применение шрифта с большим межстрочным расстоянием в пустую тратит ценный ресурс "высота экрана" и недоиспользует менее ценный ресурс "ширина экрана".
По первому пункту у меня почти обратные впечатления. В крайней точке - да корреляция есть: если речь сбивчивая, нелогичная, заторможенная (из разговора обычно ясно человек решение продумывает или банально ответ вспоминает), то и доходя до +/-технической части выясняется, что спец не очень.
Но если собеседовать джунов - то зачастую корреляция прямо обратная. Если ответы на вопросы "вылизанные" - то часто оказывается, что такой джун больше прочитал книг "как пройти интервью", чем книг "как стать хорошим программистом".
Идеальной ситуацией был бы какой-то открытый протокол для взаимодействия разных соцсетей (беглый гуглёж выдал ActivityPub). Это позволило бы иметь аккаунт в наименее "наглой по отношению к пользователю" соцсети.
Добровольный уход Meta - и последующее создание собственной соцсети ЕС, привёл бы к ситуации, когда такой протокол востребован. Эх боюсь такого не произойдёт ((
Расскажите пожалуйста про свой опыт: какие пункты договора являются обсуждаемыми (отпуск, условия работы, судя по всему), а какие нет (проводка денег) из вашей практики.
1. Читатели хабра: я знаю кто работодатель, но вам не скажу. Вы в двнный момент для меня меня "ресурс" и массовка. 2. Работодатель, я знаю, что ты считаешь себя крутой "жолтой" угрозой, но посмотри ты "зелёный".
Был бы крайне за вас, - если бы не п.1 и вы не относились ко мне (и другим читателям хабра), как к массовке.
Это будет не кражей, а не обоснованным обогащением. Активно возвращать ничего не надо - к вам придут, вы вернёте.
Есил вы обнаружите ошибку, вернётесь, и попытаетесь провернуть этот фокус ещё раз - вот это уже будет мошинничеством / кражей.
В принципе это может сработать.
Стратегически "научитсья не перегружаться" и "не брать лишней ответственности" кмк работающие подходы.
Так например если хочешь в длительной перспективе уделять какой-то деятельности время "делать pet-project" / "изучать новое" / "чиатать" - хорошо работает сочетание: "делать это ежедневно" и "не нагонять, если пропустил".
Именно "не нагонять" - позволяет вернуться к необязательному (но стратегически важному делу), после вынужденного перерыва.
Мне кажется, что с такими терминами надо быть осторожными и сначала определится, что есть "истоиря человечества", ибо неясно что вы туда включаете:
неолит?
неолит + мезолит?
верхний палеолит?
палеолит?
плиоцен?
неоген?
ПС
Вообще если послушать специолистов, то получается, что в каменном веке, скажем, общий рацион по калориям от собирательства был больше чем от охоты, но продукты охоты были "престижнее".
Позиция цельная и имеющая место быть.
Пытается решить важный вопрос: как монетизировать OpenSource (а шире - как спасти OpenSource в ситуации, когда "почти все простые программы уже написаны, а чтобы писать комплексные программы нужны ресурсы").
Однако с точки зрения развития OpenSourse-проектов такая модель создаёт плохие стимулы:
- а) нет стимула повышать качество ПО.
- б) непонятно, как эту модель (платная поддержка и устранение багов) можно масштабировать на бОльшее число разработчиков - то есть монетизировать крупные проекты по такой системе вряд ли получится.
Был с вами существенно не согласен, почти по каждому написанному пункту.
Залез вот сюда: nanopass.org -> papers -> http://andykeep.com/pubs/dissertation.pdf
Судя по всему это какой-то сугубо академический подход (упоминания SSA-IR или его аналогов не нашёл, то, что они называют intermediate language основано на чём-то похожем на lambda-calculus (p.134)).
Собственно кажется, что сравнение с промышленными компиляторами, в этом случае малоосмысленно.
В этом смысле отзываю изначальный вопрос про gcc - т.к. это просто два принципиально разных подхода.
ПС
А может мне объяснить кто-нибудь (так получилось, что в под вашем постом, просто не знаю кого тэгнуть): почему практически все papaer-ы относятся к front-end (ну или к тому, что в промышленном компиляторе назвали бы так)?
Вы смешали несколько ситуаций в одну:
1. Не можешь вести бизнес - разоряйся, это называется "Creative destruction" или "созидательное разрушение". Собственно один из столпов капитализма.
2. Вести бизнес надо законно. Законы сейчас действительно защищают женщин.
3. Законы должны быть разумными. Законы о защите женщин неидеальны, но боле-менее разумны (хотя бы потому, что есть во всех развитых странах).
К какому из пунктов у вас вопросы?
А значимо большее число проходов, в сравнении со стандартным подходом в компиляторостроении (скажем в gcc) действительно имеет место быть? Сколько проходов в типовом nanopass - компиляторе?
П.С.
Спасибо, если не примете технический вопрос к содержимому статьи на личный счёт.
Всегда считал подход gcc (там не один десяток проходов и ан min-end и на back-end) превалирующим в сегодняшнем компиляторостроении (JIT-компиляторы, конечно имеют больше trade-off по скорости-качеству кода).
Объясните в чём, по-вашему, ключевые отличия nanopass от многопроходного компилятора?
ПС
Список проходов в min-edn для gcc.
https://gcc.gnu.org/wiki/MiddleEnd
Вроде бы у экономистов это общее место, просто формулируется чуть по-другому: очень существенная часть технического прогресса происходит благодаря глобализации, т.е. раньше вы каждое изделие разрабатывали (тратили человеко-часы инженеров \ технологов...) в 20 "экономических кластерах", потом в 3, теперь в одном.
Потому, что именование должно быть разумным.
Когда вы нарушаете правило разумного именования, а потом типизируете эту функцию - вы просто "заметаете проблемы под ковёр".
Когда говорят о типах - примеры это всегда самое сложное.
Потому, что вы вводите типы, чтобы сделать код более хм... разумным.
Но когда вы приводите плохой пример - вы портите всё впечатление от разумных доводов.
Скажем вместо того, чтобы типизировать вот эту функцию - её просто (ровно в таком виде) не надо писать никогда:
Т.е. может существовать либо "библиотечная" ф-ия:
Либо прикладная функция:
Ну ведь ровно так и есть. Условно взаимодействие со стажёром можно разделить на 2 этапа:
1. Натаскивание сеньором \ нач.отдела до уровня джуна - это если стажёр совсем зелёный, это чистый минус для компании.
2. А когда стажёра натаскали до уровня джуна уровня - для него вполне логично потребовать плату "в рынке".
Вот собственно и вопрос: зачем компаниям вся эта схема (если нет доступа, через базовые кафедры к заведомо хорошим студентам), если вчистую хуже пункта №2?
Кажется вы не прошли тест на шизофрению.
Есть ещё один момент.
Среди IT-шников слишком много людей с рациональным складом мышления (к этому располагает наша работа). Поэтому многие вопросы из "хитрых психологических тестов" бессмысленны.
Приведу пару таких вопросов из своего опыта (которые должны что-то сказать психологу, но были бессмысленны для меня):
- с каким животным вы себя ассоциируете: ответ "ни с каким".
- этот карандаш хороший или плохой: ответ "карандаш не может быть хорошим \ плохим, это не свойство объекта".
Как программисту - мне видится большое межстрочное расстояние у этого шрифта большой недоработкой.
Т.е. получается, что применение шрифта с большим межстрочным расстоянием в пустую тратит ценный ресурс "высота экрана" и недоиспользует менее ценный ресурс "ширина экрана".
Про быстродействие не спорю, но пример не очень корректный.
stack на 3 уровня абстракции выше, чем make.
По первому пункту у меня почти обратные впечатления.
В крайней точке - да корреляция есть: если речь сбивчивая, нелогичная, заторможенная (из разговора обычно ясно человек решение продумывает или банально ответ вспоминает), то и доходя до +/-технической части выясняется, что спец не очень.
Но если собеседовать джунов - то зачастую корреляция прямо обратная. Если ответы на вопросы "вылизанные" - то часто оказывается, что такой джун больше прочитал книг "как пройти интервью", чем книг "как стать хорошим программистом".
Идеальной ситуацией был бы какой-то открытый протокол для взаимодействия разных соцсетей (беглый гуглёж выдал ActivityPub). Это позволило бы иметь аккаунт в наименее "наглой по отношению к пользователю" соцсети.
Добровольный уход Meta - и последующее создание собственной соцсети ЕС, привёл бы к ситуации, когда такой протокол востребован. Эх боюсь такого не произойдёт ((
Расскажите пожалуйста про свой опыт: какие пункты договора являются обсуждаемыми (отпуск, условия работы, судя по всему), а какие нет (проводка денег) из вашей практики.
Хм... текущая статья просто торг.
1. Читатели хабра: я знаю кто работодатель, но вам не скажу. Вы в двнный момент для меня меня "ресурс" и массовка.
2. Работодатель, я знаю, что ты считаешь себя крутой "жолтой" угрозой, но посмотри ты "зелёный".
Был бы крайне за вас, - если бы не п.1 и вы не относились ко мне (и другим читателям хабра), как к массовке.