Обновить
2
0.5

Пользователь

Отправить сообщение
  1. Это будет не кражей, а не обоснованным обогащением. Активно возвращать ничего не надо - к вам придут, вы вернёте.

  2. Есил вы обнаружите ошибку, вернётесь, и попытаетесь провернуть этот фокус ещё раз - вот это уже будет мошинничеством / кражей.

В принципе это может сработать.
Стратегически "научитсья не перегружаться" и "не брать лишней ответственности" кмк работающие подходы.

Так например если хочешь в длительной перспективе уделять какой-то деятельности время "делать 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, теперь в одном.

Потому, что именование должно быть разумным.

Когда вы нарушаете правило разумного именования, а потом типизируете эту функцию - вы просто "заметаете проблемы под ковёр".

Когда говорят о типах - примеры это всегда самое сложное.
Потому, что вы вводите типы, чтобы сделать код более хм... разумным.
Но когда вы приводите плохой пример - вы портите всё впечатление от разумных доводов.
Скажем вместо того, чтобы типизировать вот эту функцию - её просто (ровно в таком виде) не надо писать никогда:

def concat(a: int, b: int) -> str:
    return str(a) + str(b)



Т.е. может существовать либо "библиотечная" ф-ия:

def concat(a: str, b: str) -> str:
    return a + b
.....
x = concat(str(a), str(b))

Либо прикладная функция:

def getForm15Result(a: int, b: int) -> str:
    return str(a) + str(b)

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

Ну ведь ровно так и есть. Условно взаимодействие со стажёром можно разделить на 2 этапа:
1. Натаскивание сеньором \ нач.отдела до уровня джуна - это если стажёр совсем зелёный, это чистый минус для компании.
2. А когда стажёра натаскали до уровня джуна уровня - для него вполне логично потребовать плату "в рынке".

Вот собственно и вопрос: зачем компаниям вся эта схема (если нет доступа, через базовые кафедры к заведомо хорошим студентам), если вчистую хуже пункта №2?

Кажется вы не прошли тест на шизофрению.

Есть ещё один момент.

Среди IT-шников слишком много людей с рациональным складом мышления (к этому располагает наша работа). Поэтому многие вопросы из "хитрых психологических тестов" бессмысленны.

Приведу пару таких вопросов из своего опыта (которые должны что-то сказать психологу, но были бессмысленны для меня):
- с каким животным вы себя ассоциируете: ответ "ни с каким".
- этот карандаш хороший или плохой: ответ "карандаш не может быть хорошим \ плохим, это не свойство объекта".

Как программисту - мне видится большое межстрочное расстояние у этого шрифта большой недоработкой.

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

Про быстродействие не спорю, но пример не очень корректный.

stack на 3 уровня абстракции выше, чем make.

По первому пункту у меня почти обратные впечатления.
В крайней точке - да корреляция есть: если речь сбивчивая, нелогичная, заторможенная (из разговора обычно ясно человек решение продумывает или банально ответ вспоминает), то и доходя до +/-технической части выясняется, что спец не очень.

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

Идеальной ситуацией был бы какой-то открытый протокол для взаимодействия разных соцсетей (беглый гуглёж выдал ActivityPub). Это позволило бы иметь аккаунт в наименее "наглой по отношению к пользователю" соцсети.

Добровольный уход Meta - и последующее создание собственной соцсети ЕС, привёл бы к ситуации, когда такой протокол востребован. Эх боюсь такого не произойдёт ((

Расскажите пожалуйста про свой опыт: какие пункты договора являются обсуждаемыми (отпуск, условия работы, судя по всему), а какие нет (проводка денег) из вашей практики.

Хм... текущая статья просто торг.

1. Читатели хабра: я знаю кто работодатель, но вам не скажу. Вы в двнный момент для меня меня "ресурс" и массовка.
2. Работодатель, я знаю, что ты считаешь себя крутой "жолтой" угрозой, но посмотри ты "зелёный".

Был бы крайне за вас, - если бы не п.1 и вы не относились ко мне (и другим читателям хабра), как к массовке.

Информация

В рейтинге
2 153-й
Зарегистрирован
Активность