В смысле калькуляции солидарная система очень близка к накопительной.
Я бы даже сказал к лучшим реализациям накопительной — при которой отчисления идут в акции (т.е. приобретается «кусочек экономики») а не в какие-нибудь облигации и т.п.
Значительную разницу я вижу только в том, что при солидарной действительно возникает желание «усреднить» пенсии — т.е. вместо того, чтобы платить соц.пособия бывшим тунеядцам платят полноценные пенсии за счёт работавших (естественно всё делается через математический оператор «отложенного платежа» хД)
да на то, что сверх налогооблагаемой базы платят 10%.
Т.е. я вас понял так:
1. до 100тыс/месяц обложение 23% (или сколько там). Но с этих денег хотя бы мне пенсию будут платить. В целом ± честно.
2. сверх 100тыс/месяц баллы не идут (проверял в пенсионном калькуляторе) и это чистая благотворительность (в пользу тех моих одноклассников, которые побухивали вместо уроков, когда я сидел и ботал математику с IT)
Про пункт 2 я просто не знал и просил подтверждающую ссылку.
И был несколько удивлён этим фактом, т.к. периодически поглядывал одним глазом за пенсионной реформой (хотя бы в формате «хватит ли пенсии на кусочек хлеба, если считать что 'всё будет ± как сейчас'»)/
ПС
Да лучше на такие мусорные сайты, которые мешают читать и вымогают почту ссылок не давать.
Вот по 2020 году сразу ищется ссылка
Проблема в том, что соц.сети являются естественными монополиями.
Действительно если 60% друзей и потребляемого условным Джоном контента в ФБ — он перейдёт на ФБ (*)
И пока соц.сети являются естественными монополиями — рассказы о «частной цензуре» в существенной степени фарисейство (т.е. формально в сферическом вакууме верны, но по сути издевательство).
*) Решается это крайне сложно (как пытаются в Династии) через открытый API взаимодействия между «хранением» и «отображением» информации. Но получается неповоротливый монстр из комитетов по работе с комитетом по работе со стандартом описания протокола…
Ну общаться на уровне SO это попроще чем книгу по незнакомой области читать (как минимум я надеюсь что «незнакомость» в этом случае не будет так сильно вылазить).
1. Смешение табов и пробелов куда хуже чем отдельно табы или пробелы.
2. Табы «в целом» скорее уходящая CodeStyle конвенция. Но например в Linux Kernel Code Style они родимые (не заменяются пробелами, да ещё и по 8 символов) — а оттуда зачастую попадают в CodeStyle контор занимающихся системным ПО.
ПС
Абсолютно с вами согласен, что увольнять! джуниара! вместо того чтобы объяснить! — это совсем какой-то моветон.
Джун на то и джун, чтобы учиться на работе, а не с ходу выдавать желаемый код.
На практике наверное действительно лучше «начинать с середины». Особенно в ситуации когда некому задать FAQ (воспользоваться чужой интуицией).
Просто мне вот всегда было комфортнее когда понимаешь на пару уровней абстракции вглубь что делается.
Вот скажем той же интуиции в «функциональном стиле программирования» у меня совсем нет (вернее есть неправильно работающая унаследованная от императивщины).
Скажем написал «решето эратосфена» в функциональном (в смысле «filter \ list» а не в смысле «без сайд эффектов») и с ходу ошибся в О-сложности работы.
>> Пишите код, показывайте его людям, получайте фидбек.
А куда показать-то свой (достаточно тупой чтобы было интересно другим людям) код. Так чтобы сходу не послали на…
Вот интересно что раньше-то никогда в такой ситуации не бывал…
Да вероятно я неверно понял β-редукцию (или читал про упрощённый пример исчисления).
Я её понял просто как раскрытие (уж не помню корневой или листовой) \-функции
>> любая функция принимает ровно 1 аргумент,
Вещь теоретически крайне красивая.
Но.
В \- исчислении (тех местах, что я видел, я конечно тот ещё специалист) пишут же:
\ xyz.M(...) — т.е. явно в сигнатуре (до точке) указывают 3 аргумента.
Спасибо вам за ваш блог, отчасти он подвигнул меня начать учить FP (в частности остановился на Haskell, хотя есть вещи немного смущающие).
>> ИМХО лучше с практики начинать.
Ну в метро-то надо что-то делать. Тем более в теории я не глубоко (всего лишь главы про \-исчисление и комбинаторы книги «14 занимательных эссе о хаскел»).
Просто удивляет что не очень понимаю что там написано (собственно подозреваю что там пара базовых моментов недообъяснена для совсем новичка).
Можно я не в подходящей для этого теме вас немного помучаю:
1. Оптимизации в движке Haskell:
— они в основном на AST делаются (или в IR)?
— все далаются в compile-time или сам бинарник (exe\elf) занимается оптимизацией и (JIT\интерпретацией) — где-то видел такую версию, но неправдоподобно по скорости.
2. Зачем нужно каррирование? Как отдельная и важная парадигма отличительная черта парадигмы FP?
Пока вижу лишь «сахар» для «абстрактных фабрик» или виде затыкания дыр там где по синтаксису нужна функция 1й переменной, типа:
map ( (\x y -> x /= y) param_var) param_list
Который (сахар / поддержка паттернов) на отдельное важное свойство парадигмы не тянет
3. Что лучше из (относительно теоретического) почитать для улучшения скила в FP (важное дополнение — на русском).
Наверное тут тоже два вопроса:
— в какую сторону (теория типов \ CT \ частично рекурсивные функции \ ещё что-то)?
— на какой именно книге стоит остановиться?
1. Преждевременные оптимизации — зло.
Узнай место, которое замедляет программу, реализуй его на C(*).
Собственно про профилирование кода сказали, а дальше свернули куда-то не туда и стали говорить про всякие микрооптимизации, зачем?
*) по аналогии — мало кто пишет весь код сейчас на assembler, если узкое место CPU находят самую прожорливую ф-ию и переписывают её и только её (например используя параллельность по данным через SSE инструкции)
2. Не упоминуть про CPython (и другие интерпретаторы байткода), почему?
3. На фоне 1,2 то что описано в статье даст весьма незначительные улучшения.
3.1 Вот это чрезмерная оптимизация, даже в сравнении с остальными пунктами статьи.
>> Как это возможно? Дело в том, что при обработке большого набора данных без использования генераторов (итераторов) данные могут привести к переполнению L1-кэша процессора, что значительно замедлит операции по поиску значений в памяти.
Даже на фоне присутствующих в статье советов это уж совсем экономия на спичках.
Интерпретатор всё равно загрузится в L1-instraction-cache (который свой для кода\данных).
А уж пара промахов по data-cache дадут доли процентов на фоне общей неспешности внутренних мехазинмов python, типа __getattribute__ (которые вовсе не для производительности так проектировались).
>> Перспективы не радужные, все мужское население, которое остается без работы идет в строительство или перевозки.
Понял да, удачи вам.
Вот я сейчас в (чем-то) похожей ситуации.
Решил учить FP (решил ознакомиться с базисом — лямбда и комбинаторным исчислениями) и чувствую себя таким тупым, как те «троечники» которые в студенчестве вечно какие-то очевидные вещи не понимали.
И вот думаю то-ли я действительно тупее стал, то-ли требуется «период въезжания» в практически полностью новую тему.
>> до них сложно доходит понятие профессионализм и почему надо платить больше, чем бригаде забулдыг.
Ну я, конечно, в Мск а не провинции.
Но по моим понятиям профессионалы берут столько же сколько и забулдыги. Просто профессионалы (с хорошо налаженным конвейром работы и инструментом) делают работу за 1 день, а забулдыги за 3.
>> >> В моём понимании, при наличии заказчиков и прямых рук, конечно
>> а когда накосячили то платили за день исправлений… побелка с потолка осыпалась прямо в момент финальной приемки, не говоря уже о кривых стенах
Во-первых мы обсуждаем (условно) профессионалов не ниже некоторого среднего уровня что в IT, что в строительстве (см ремарку); соответственно неизбежные косяки не столь часты.
Во-вторых такие профессионалы ценят своё время и предварительно оценивают трудоёмкость работ профессионально <=> обычно адекватно.
В третьих человек идёт из опытного строителя в неопытного IT-шника (т.е.косячить в IT будет больше по определению).
ПС
Если хотите обсудить «уровень последствий для исполнителя» — то в IT он в среднем ниже чем в строительстве (хотя удивительно уровень ответственности выше и это нельзя сбрасывать со счетов).
Хотя в разработке каких-нибудь аэрокосмических систем не исключаю что и посадить могут (т.е. как всегда есть нюансы).
Это, конечно, хорошо обсудить за обедом.
Но тащить код способный удивить коллег, который потом читать (и желательно понять потратив не очень много времени) и при необходимости модифицировать, в средний-большой проект так себе идея (средний-большой условно если все разработчики проекта не сидят в одной комнате).
А С++ к этому если не принуждает, то активно подталкивает.
>> Как в таком случе с вашей точки зрения должен быть запрограмированн именно ваш автопилот: чтобы спасти своего пассажира или чтобы спасти максимальное количество людей?
Очевидно (для бизнеса) чтобы спасти своего пассажира.
Иначе такую машину никто не купит ;)
Ну надо отметить, что 3 и 4 уровни автоматизации (по SAEJ3016) работают весьма фигово.
Т.е. после некоторых систем содействия водителю надо переходить сразу на полностью автоматическое управление ТС.
Да два уточнения:
1. В авиации с автоматизированием работы пилота ещё как-то справляются, за счёт выделения отдельных часов для пилотов, когда они они обрабатывают нештатные ситуации. В вождении личного ТС будет совсем не так.
2. Наиболее вероятный сценарий аварии, на 4 уровне автоматизации будет выглядеть так:
«еду за рулём пью кофе 'готов в любую секунду взять на себя управление ТС при нештатной ситуации' вдруг (редкое событие или цепочка высоковероятных событий...) авто едет не туда, во рту бутерброд, в руке кофе, как управлять авто я уже подзабыл, а как управлять во внештатной ситуации никогда и не знал… бумц… хорошо хоть подушки безопасности есть»
>> Я сейчас учу Java (работал в банках, занимаюсь строительством коттеджей, 2 вышки)
А можно вопрос о мотивах?
В моём понимании, при наличии заказчиков и прямых рук, конечно, в строительной сфере, даже простым монтажником можно заработать на уровне программиста (да монтажникам надо в-job-ывать) — профессионалы хотят 10-25тыс\день работы.
А монтажники в коттеджных посёлках (по слухам и рассказам) получают в пару раз больше.
Ну т.е. в моём понимании уходить из строительства (при наличии наработанной клиентской базы) на ± начальные позиции в IT смысла особого нет.
>> Тем не менее это всё не значит, что нужно уже сейчас платить программерам как водителю автобуса
Несомненно. Я подчёркиваю лишь две вещи не надо думать что схватил бога за тестикулы:
а) не надо забывать, что нам просто повезло «оказаться в нужное время в нужном месте»
б) спрос на разработчиков может и упасть.
Я бы даже сказал к лучшим реализациям накопительной — при которой отчисления идут в акции (т.е. приобретается «кусочек экономики») а не в какие-нибудь облигации и т.п.
Значительную разницу я вижу только в том, что при солидарной действительно возникает желание «усреднить» пенсии — т.е. вместо того, чтобы платить соц.пособия бывшим тунеядцам платят полноценные пенсии за счёт работавших (естественно всё делается через математический оператор «отложенного платежа» хД)
Т.е. я вас понял так:
1. до 100тыс/месяц обложение 23% (или сколько там). Но с этих денег хотя бы мне пенсию будут платить. В целом ± честно.
2. сверх 100тыс/месяц баллы не идут (проверял в пенсионном калькуляторе) и это чистая благотворительность (в пользу тех моих одноклассников, которые побухивали вместо уроков, когда я сидел и ботал математику с IT)
Про пункт 2 я просто не знал и просил подтверждающую ссылку.
И был несколько удивлён этим фактом, т.к. периодически поглядывал одним глазом за пенсионной реформой (хотя бы в формате «хватит ли пенсии на кусочек хлеба, если считать что 'всё будет ± как сейчас'»)/
ПС
Да лучше на такие мусорные сайты, которые мешают читать и вымогают почту ссылок не давать.
Вот по 2020 году сразу ищется ссылка
Действительно если 60% друзей и потребляемого условным Джоном контента в ФБ — он перейдёт на ФБ (*)
И пока соц.сети являются естественными монополиями — рассказы о «частной цензуре» в существенной степени фарисейство (т.е. формально в сферическом вакууме верны, но по сути издевательство).
*) Решается это крайне сложно (как пытаются в Династии) через открытый API взаимодействия между «хранением» и «отображением» информации. Но получается неповоротливый монстр из комитетов по работе с комитетом по работе со стандартом описания протокола…
Ну общаться на уровне SO это попроще чем книгу по незнакомой области читать (как минимум я надеюсь что «незнакомость» в этом случае не будет так сильно вылазить).
2. Табы «в целом» скорее уходящая CodeStyle конвенция. Но например в Linux Kernel Code Style они родимые (не заменяются пробелами, да ещё и по 8 символов) — а оттуда зачастую попадают в CodeStyle контор занимающихся системным ПО.
ПС
Абсолютно с вами согласен, что увольнять! джуниара! вместо того чтобы объяснить! — это совсем какой-то моветон.
Джун на то и джун, чтобы учиться на работе, а не с ходу выдавать желаемый код.
На практике наверное действительно лучше «начинать с середины». Особенно в ситуации когда некому задать FAQ (воспользоваться чужой интуицией).
Просто мне вот всегда было комфортнее когда понимаешь на пару уровней абстракции вглубь что делается.
Вот скажем той же интуиции в «функциональном стиле программирования» у меня совсем нет (вернее есть неправильно работающая унаследованная от императивщины).
Скажем написал «решето эратосфена» в функциональном (в смысле «filter \ list» а не в смысле «без сайд эффектов») и с ходу ошибся в О-сложности работы.
>> Пишите код, показывайте его людям, получайте фидбек.
А куда показать-то свой (достаточно тупой чтобы было интересно другим людям) код. Так чтобы сходу не послали на…
Вот интересно что раньше-то никогда в такой ситуации не бывал…
Серьёзно?
Ссылкой поделитесь?
Да вероятно я неверно понял β-редукцию (или читал про упрощённый пример исчисления).
Я её понял просто как раскрытие (уж не помню корневой или листовой) \-функции
Вещь теоретически крайне красивая.
Но.
В \- исчислении (тех местах, что я видел, я конечно тот ещё специалист) пишут же:
\ xyz.M(...) — т.е. явно в сигнатуре (до точке) указывают 3 аргумента.
>> ИМХО лучше с практики начинать.
Ну в метро-то надо что-то делать. Тем более в теории я не глубоко (всего лишь главы про \-исчисление и комбинаторы книги «14 занимательных эссе о хаскел»).
Просто удивляет что не очень понимаю что там написано (собственно подозреваю что там пара базовых моментов недообъяснена для совсем новичка).
Можно я не в подходящей для этого теме вас немного помучаю:
1. Оптимизации в движке Haskell:
— они в основном на AST делаются (или в IR)?
— все далаются в compile-time или сам бинарник (exe\elf) занимается оптимизацией и (JIT\интерпретацией) — где-то видел такую версию, но неправдоподобно по скорости.
2. Зачем нужно каррирование? Как отдельная и важная
парадигмаотличительная черта парадигмы FP?Пока вижу лишь «сахар» для «абстрактных фабрик» или виде затыкания дыр там где по синтаксису нужна функция 1й переменной, типа:
map ( (\x y -> x /= y) param_var) param_list
Который (сахар / поддержка паттернов) на отдельное важное свойство парадигмы не тянет
3. Что лучше из (относительно теоретического) почитать для улучшения скила в FP (важное дополнение — на русском).
Наверное тут тоже два вопроса:
— в какую сторону (теория типов \ CT \ частично рекурсивные функции \ ещё что-то)?
— на какой именно книге стоит остановиться?
Узнай место, которое замедляет программу, реализуй его на C(*).
Собственно про профилирование кода сказали, а дальше свернули куда-то не туда и стали говорить про всякие микрооптимизации, зачем?
*) по аналогии — мало кто пишет весь код сейчас на assembler, если узкое место CPU находят самую прожорливую ф-ию и переписывают её и только её (например используя параллельность по данным через SSE инструкции)
2. Не упоминуть про CPython (и другие интерпретаторы байткода), почему?
3. На фоне 1,2 то что описано в статье даст весьма незначительные улучшения.
3.1 Вот это чрезмерная оптимизация, даже в сравнении с остальными пунктами статьи.
>> Как это возможно? Дело в том, что при обработке большого набора данных без использования генераторов (итераторов) данные могут привести к переполнению L1-кэша процессора, что значительно замедлит операции по поиску значений в памяти.
Даже на фоне присутствующих в статье советов это уж совсем экономия на спичках.
Интерпретатор всё равно загрузится в L1-instraction-cache (который свой для кода\данных).
А уж пара промахов по data-cache дадут доли процентов на фоне общей неспешности внутренних мехазинмов python, типа __getattribute__ (которые вовсе не для производительности так проектировались).
Понял да, удачи вам.
Вот я сейчас в (чем-то) похожей ситуации.
Решил учить FP (решил ознакомиться с базисом — лямбда и комбинаторным исчислениями) и чувствую себя таким тупым, как те «троечники» которые в студенчестве вечно какие-то очевидные вещи не понимали.
И вот думаю то-ли я действительно тупее стал, то-ли требуется «период въезжания» в практически полностью новую тему.
>> до них сложно доходит понятие профессионализм и почему надо платить больше, чем бригаде забулдыг.
Ну я, конечно, в Мск а не провинции.
Но по моим понятиям профессионалы берут столько же сколько и забулдыги. Просто профессионалы (с хорошо налаженным конвейром работы и инструментом) делают работу за 1 день, а забулдыги за 3.
>> а когда накосячили то платили за день исправлений… побелка с потолка осыпалась прямо в момент финальной приемки, не говоря уже о кривых стенах
Во-первых мы обсуждаем (условно) профессионалов не ниже некоторого среднего уровня что в IT, что в строительстве (см ремарку); соответственно неизбежные косяки не столь часты.
Во-вторых такие профессионалы ценят своё время и предварительно оценивают трудоёмкость работ профессионально <=> обычно адекватно.
В третьих человек идёт из опытного строителя в неопытного IT-шника (т.е.косячить в IT будет больше по определению).
ПС
Если хотите обсудить «уровень последствий для исполнителя» — то в IT он в среднем ниже чем в строительстве (хотя удивительно уровень ответственности выше и это нельзя сбрасывать со счетов).
Хотя в разработке каких-нибудь аэрокосмических систем не исключаю что и посадить могут (т.е. как всегда есть нюансы).
Т.е. когда делал ремонт, то отдавал примерно по 10-25 тыр за человекодень (двери \ окна \ шкафы \ кондиционеры \ потолки....) за монтаж.
Это, конечно, хорошо обсудить за обедом.
Но тащить код способный удивить коллег, который потом читать (и желательно понять потратив не очень много времени) и при необходимости модифицировать, в средний-большой проект так себе идея (средний-большой условно если все разработчики проекта не сидят в одной комнате).
А С++ к этому если не принуждает, то активно подталкивает.
Очевидно (для бизнеса) чтобы спасти своего пассажира.
Иначе такую машину никто не купит ;)
Т.е. после некоторых систем содействия водителю надо переходить сразу на полностью автоматическое управление ТС.
Да два уточнения:
1. В авиации с автоматизированием работы пилота ещё как-то справляются, за счёт выделения отдельных часов для пилотов, когда они они обрабатывают нештатные ситуации. В вождении личного ТС будет совсем не так.
2. Наиболее вероятный сценарий аварии, на 4 уровне автоматизации будет выглядеть так:
«еду за рулём пью кофе 'готов в любую секунду взять на себя управление ТС при нештатной ситуации' вдруг (редкое событие или цепочка высоковероятных событий...) авто едет не туда, во рту бутерброд, в руке кофе, как управлять авто я уже подзабыл, а как управлять во внештатной ситуации никогда и не знал… бумц… хорошо хоть подушки безопасности есть»
А можно вопрос о мотивах?
В моём понимании, при наличии заказчиков и прямых рук, конечно, в строительной сфере, даже простым монтажником можно заработать на уровне программиста (да монтажникам надо в-job-ывать) — профессионалы хотят 10-25тыс\день работы.
А монтажники в коттеджных посёлках (по слухам и рассказам) получают в пару раз больше.
Ну т.е. в моём понимании уходить из строительства (при наличии наработанной клиентской базы) на ± начальные позиции в IT смысла особого нет.
Несомненно. Я подчёркиваю лишь две вещи
не надо думать что схватил бога за тестикулы:а) не надо забывать, что нам просто повезло «оказаться в нужное время в нужном месте»
б) спрос на разработчиков может и упасть.