Заголовок же кликбэйтный: 1. в статье нету "почему" в статье есть "как". 2. в статье нету "не вошёл в IT", в статье есть "вошёл в самое начало и остановился".
ПС К стати не бойтесь идти дальше. Даже если ЗП не изменится - рабочие условия почти наверняка изменятся в лучшую сторону. Чем "глубже" в IT тем в принципе отношение к программисту лучше.
Э... вообще-то "метод Серёжи" - это удешевление разработки взамен увеличения технического долга.
И применять или нет такой метод - зависит от жизненного цикла приложения. Если я пишу скрипт автоматизации, который мне надо 2 раза запиустить и лог которого я буду проверять глазами - то я и напишу ровно такой скприт автоматизации + юнит тесты.
А "интеграционное тестирование" проведу методом "grep -r ........" Ничего в этом зазарного нет.
Я не очень понимаю в чём содержательный посыл вашего замечания? Если это: "есть какая-то часть, которую рассчитать трудно" => "считать вообще не надо". То я с ним не согласен, и это просто повод не принимать расчёты если вдруг вам их результаты не нравятся. Если в этом есть какой-то другой смысл - то уточните.
Это скорее намёк, что за условные 10 лет мои траты будут куда ближе к "средним по экономике" чем в каждый конкретный день, просто из-за усреднения.
Конечно "репрезентативность трат" - всё равно важная оговорка. Ведь все конечные потребители благ (ну НДС устроен так, что должен включать только конечных) платят 6% налога в среднем, но каждый конкретный, несмотря на усреднение может платить несколько другой %.
В принципе проще учесть НДС на экспорт, тогда получается 6%. Тогда получим 6% эффективной налоговой ставки по экономике. Что в 3 с лишним раза меньше чем 20% про которые нам рассказывают форумные экономисты.
С т.з. экономики какой из переделов платит НДС разницы нет. Разница появляется, если отчисления идут в бюджеты регионов: так-то НДС был изобретён во Франции вместо налога с продаж, чтобы налог платился по месту "работы" а не по месту "покупки".
Но поскольку у нас он платится всё равно в Федеральный бюджет, так что без разницы как его разделят: производитель резины, резиновых игрушек и магазин игрушек.
Да получается 6% если учесть НДС на импорт. Но вообще как только начинают рассказывать про "реальный", а не номинальный налог в условной Германии - неплохо было бы рассчитать и реальный, а не номинальный, налог и в России тоже. Если я сегодня купил чебурек 2 капучино футболку и 0.0001квартиры (и мои траты репрезентативны) - то НДС с этого всего я заплатил как раз те самые 6%.
============================================= Рассчёт. 1.Да наверное НДС на импорт тоже надо считать. 2. то, что вы пытаетесь посчитать - это доля НДС в федеральном бюджете. Вообще мне смысл непонятен.
Чтобы посчитать эффективную ставку НДС надо делить на ВВП, т.к. именно "добавленная стоимость" <=> "ВВП" и есть база НДС в масштабах страны.
Т.е. если брать 2021 год (я писал, что мне более разумным кажется 2019, но не суть) это будет:
(4 609,4 + 3 348,7) / 131 000 = 6,07% (с импортом в принципе вдвое больше) но далеко не 20% про которые любят говорить.
Если мы будем обсуждать "уровень насильственных преступлений вне маргинальной среды" - то этот уровень кратно упал, скажем в моём родном Тамбове, где я периодически бываю.
Уровень взаимной вежливости, правовой культуры, просто хорошего отношения друг к другу - с 90х вырос несказанно. Также и бытового ощущения защищённости от насильственных преступлений условно "на улице".
Знаете если сравнивать личный опыт - мне даже непонятно как можно хоть как-то близко сравнивать эти и те годы. В 90х если бы "простые" люди попытались не пропускать "крутые" автомобили их бы насильственно остановили дальнейщие варианты: избиение \ вымогательство денег \ насильственные действия сексуального характера. В 2016 в Тамбове спокойно работали "синие ведёрки".
Разумеется здесь "кто-то платит 20% кто-то не платит вообще". Но реальность "в среднем НДС в России 3%" очень сильно отличается от любимых в интернете цифр в 20%.
ПС Уточню, что последним "нормальным" годом считаю 2019 потому, что два ковидных года с ручным управлением налогами имеют ИМХО искажённую картину.
Я бы так сказал: - выстроенный процесс - это "нижняя" планка результатов вашей работы, когда работа или сделана достаточно хорошо (по тем критериям, которые вы закладывали) или не принята вообще. Убирает кучу головной боли. - сильная команда - это верхняя планка (на момент сегодня).
Ну Россия за эти 30 лет переняла у Запада гораздо более умелые (более действенные и вызывающие меньше возмущения) способы пропаганды и давления на недовольных. Это раз.
Во вторых вот это: > Полицейские будут отлавливать подпольщиков, продающих симки и оборудование, по ночам подпольщики будут отлавливать полицейских и членов их семей, отчего первые будут умерять свой пыл и ловить лишь тех, кого им разрешили местные авторитеты.
В моей реальности звучит настолько дико (я не готов говорить "за всех людей на планете", как некоторые тут), что ставит под вопрос всю адекватность комментария.
Если бы я получил такую табличку - то я бы первым делом задумался о том, что данные в ней очень biased (возможно coupled с компетенциями оценивающих PM-ов).
Действительно с чего бы выходцам из разработки иметь вот такие (в порядке убывыния) сильные стороны: 1. Целеполагание и планирование 2. Управление командой 3. Управление людьми 4. Технические компетенции 5. Выстраивание процессов
Гипотеза, которая сразу - что тимлид дольше обсуждает с PM-ом, за то он и ставит высокую оценку.
When you're designing a new language, don't slavishly follow the bizarre conventions of predecessor languages
Вы правы абсолютно по всем позициям.
И вот мы в самом начале беседы: Хаскель пректасный язык для обучения студентов и написания грамотных комментариев (без шуток - моя ремарка о "хороших прктиках" была не просто так). Но если при таких достоинствах его вклад в индустрию ПО близок к о-малому, значит недостатки in real world всё-таки есть и существенны. И на них не следует закрывать глаза.
Это особенно начинаешь замечать когда начинаешь часто пихать туда/сюда функции, например на акторных фреймворках это заметно.
Akka была изначально написана на Scala, а не более "взрослом", тогда точно, Хаскель, ИМХО ровно потому, что её изначально пытались сделать для людей, а не "кому не нравится тот сам не прав". Я как раз основной мой поинт в том, что такой подход более рабочий.
Двусвязный список это такая структура данных, которая часто прохоидится в универе и почти никогда не используется на практике.
И да вы же не пытаетесь сказать, что: "ценность двусвязного списка переоценена" => "ценность двусвязного списка 0"?
МЛ в целом кажется более супериор синтаксисом откровенно говоря... А так да, умение читать разные синтаксисы в целом полезно и неплохо расширяет кругозор
Мы прыгаем с пункта на пункт, в целом все звучат так: 1. семантическая насыщенность фрагмента на Haskell выше чем на JavaScript 2. Синтаксис хаскеля странен и в нём есть как ошибки, так и помарки *) a.map(f1).filter(f2).map(f3) >> map f3 $ filter f2 $ map f3 a **) странные отступы в while при записи на той же строке или громоздкий $ для доступа к полям data 3. Люди действительно знают C-syntax лучше чем Haskell. И пытаться принуждать к неудобству людей заради их же блага работает только если морковка НУ ОЧЕНЬ вкусная.
Ну и независимо от этого с какой-то точки "новая концепция", познакомится с которой несомненно хорошо, становится вещью в себе не добавляя никакой ценности вокруг. Не важно знание это 150го паттерна проектирования, обход C-types "по улитке" или умение на автомате парсить сложную Haskell-запись.
Маленький компилятор DSL-языка (но поскольку там нужны IR-оптимизации, пусть и неполноценные, то надо хранить состояние, лазить по операциям туда-сюда и оптимизировать их). Маленький - в смысле без циклов.
Действительно говорим о разном. Можете ткнуть конкретно на кого что тут спихнуто.
Я говорю вот о чём:
Все статьи которые я вижу - в них по счастливому стечению обстоятельств формулировка задачи и внешние API удобны для Haskell (в данном случае у вас презумпция: если получать структуру комментов - сразу всё дерево, а не пошагово, разумеется парсить DOM-дерево на Хаскель будет удобнее чем на Го).
Мой Pet-project для изучения Haskell. Прям с ходу влетаю в то, что мне нужен двусвязный список, с полноценными вставкой \ удалением. Далее мысли: 1. Возможно 2 Map (в прямом обратном направлении, потом всё это в data instance functor && traverse). 2. Погуглить что есть. Ничего лучше не нашёл. Т.е. у того, что я видел под капотом что-то похожее по ассимптотической сложности. 3. Долго думал. 4. Решение: разделить проходы в прямом и обратном направлении (благо задача почти игрушечная, позволяла). Использовать односвязный список, иногда его переворачивать. Использовать разные newtype для прямого и обратного списков для типобезопасности.
То есть когда я пишу программы вселенная мне не предоставляет "удобные для Хаскеля" интерфейсы. И я бы что-то хотя бы отдалённо похожее хотел бы видеть в статьях про Хаскель. Но в основном это success stories - идущие вразрез с тем опытом, который получил я.
Для меня хаскель удобен для всех задач,
Ровно одна боевая задача - генерация примеров для тестирования нашего DSL. Потому, что Haskell а) чудо как хорош с Parsec, б) заставляет делать другую реализацию интерпретатора, что предотвращает "тянуть ошибки на автомате из проекта в его верификатор".
Замысловатый код — плохой и так делать не надо.
Я вот совсем не знаю JavaScript (1 раз писал для себя расширение кое-что посчитать в GoogleSpreadSheets). Т.е. опыт в Haskell раз в 50 больше чем в JS =) Написанное вами не выглядит страшно, хотя может где-то под капотом являться, слышал в JS любят неявные побочные эффекты. Просто надо помнить что что делает. Написанное на Haskell выглядит. Мне кажется нетипичный синтаксис и любовь коммюнити к наворотам - действительно одина из проблем языка (если ставить целью его проход в массы)
> Хаскель разгромно выигрывает в интернет-статьях и точно так же разгромно проигрывает в широте использования написанного на нём ПО.
Если так судить то лучшая платформа для программированич это excel. не шучу, на их макросах больше кода написано чем на всех остальных языках вместе взятых. Точно так же как сайты-визитк на вордпрессе куда более распрострнанены чем любые экспрессы/джанги/мвц/… 80% если я правильно помню статистику от вордпресса.
Во-первых вы пропустили ключевое "по широте использования написанного на нём ПО". Ну и да кто ж сказал, что excel (встроенные макросы или VisualBasic?) плохой? Если люди реально пользуются - значит good enough (ну и эффект первого застолбившего поляну, конечно).
Но в целом при такой разнице конечных подходов обсуждать локальный подход в статье малоосмысленно. Я просто вижу, что практически каждый аргумент интерпретируется нами по-разному и каждый остаётся при своём мнении. Для меня - крайне мало задач, для которых Хаскель был бы удобен, поэтому вкладывать и дальше своё время в изучение малоосмысленно. У вас вероятно ситуация другая.
====================================== Не заню стоит ли отвечать, но пусть будет для истории.
Тут не хватает глагола "что моя реакция".
Ваша реакция процитирована. Она как минимум раздражённая, как максимум - подберите эпитет сами. Мне даже пришлось дисклеймер, что "не атакую Хаскель" написать, т.к. ситуация грозила скатиться в срачик.
Во-первых там 3 строки, 4 включая сигнатуру
А если с empty-line, перед ф-ией то 5. Что даст вклад 5 в: wc -l *.hs
Во-вторых читать что написано научиться можно легко, а писать простыни кода без ошибок — не очень.
Хаскель довольно хорошо страхует от ошибок в семантически-разряженном коде. Поэтому какой код писать на Хаскеле - дело вкуса и привычек коммюнити. По мне привычки писать замысловатый код - плохие практики для целей... (впрочем про разность целей написано выше).
Задача №1 решается примерно так:
Вы постулировали удобный для Haskell АПИ и у вас всё хорошо. Имеете право. Можете повторить это ещё и ещё. Но в моей практике технология: "мы делаем на ней только удобное, если что-то не удобно - скидываем головную боль на соседний отдел", - нужна в сложном проекте только в каких-то совсем экзотических условиях (скажем SQL - пример такой технологии, да).
Заголовок же кликбэйтный:
1. в статье нету "почему" в статье есть "как".
2. в статье нету "не вошёл в IT", в статье есть "вошёл в самое начало и остановился".
ПС
К стати не бойтесь идти дальше. Даже если ЗП не изменится - рабочие условия почти наверняка изменятся в лучшую сторону. Чем "глубже" в IT тем в принципе отношение к программисту лучше.
Э... вообще-то "метод Серёжи" - это удешевление разработки взамен увеличения технического долга.
И применять или нет такой метод - зависит от жизненного цикла приложения.
Если я пишу скрипт автоматизации, который мне надо 2 раза запиустить и лог которого я буду проверять глазами - то я и напишу ровно такой скприт автоматизации + юнит тесты.
А "интеграционное тестирование" проведу методом "grep -r ........"
Ничего в этом зазарного нет.
Я не очень понимаю в чём содержательный посыл вашего замечания? Если это:
"есть какая-то часть, которую рассчитать трудно" => "считать вообще не надо".
То я с ним не согласен, и это просто повод не принимать расчёты если вдруг вам их результаты не нравятся. Если в этом есть какой-то другой смысл - то уточните.
Это скорее намёк, что за условные 10 лет мои траты будут куда ближе к "средним по экономике" чем в каждый конкретный день, просто из-за усреднения.
Конечно "репрезентативность трат" - всё равно важная оговорка.
Ведь все конечные потребители благ (ну НДС устроен так, что должен включать только конечных) платят 6% налога в среднем, но каждый конкретный, несмотря на усреднение может платить несколько другой %.
Это по техническим причинам невозможно.
В принципе проще учесть НДС на экспорт, тогда получается 6%. Тогда получим 6% эффективной налоговой ставки по экономике. Что в 3 с лишним раза меньше чем 20% про которые нам рассказывают форумные экономисты.
С т.з. экономики какой из переделов платит НДС разницы нет.
Разница появляется, если отчисления идут в бюджеты регионов: так-то НДС был изобретён во Франции вместо налога с продаж, чтобы налог платился по месту "работы" а не по месту "покупки".
Но поскольку у нас он платится всё равно в Федеральный бюджет, так что без разницы как его разделят: производитель резины, резиновых игрушек и магазин игрушек.
Да получается 6% если учесть НДС на импорт.
Но вообще как только начинают рассказывать про "реальный", а не номинальный налог в условной Германии - неплохо было бы рассчитать и реальный, а не номинальный, налог и в России тоже.
Если я сегодня купил чебурек 2 капучино футболку и 0.0001квартиры (и мои траты репрезентативны) - то НДС с этого всего я заплатил как раз те самые 6%.
=============================================
Рассчёт.
1.Да наверное НДС на импорт тоже надо считать.
2. то, что вы пытаетесь посчитать - это доля НДС в федеральном бюджете. Вообще мне смысл непонятен.
Чтобы посчитать эффективную ставку НДС надо делить на ВВП, т.к. именно "добавленная стоимость" <=> "ВВП" и есть база НДС в масштабах страны.
Т.е. если брать 2021 год (я писал, что мне более разумным кажется 2019, но не суть) это будет:
(4 609,4 + 3 348,7) / 131 000 = 6,07% (с импортом в принципе вдвое больше) но далеко не 20% про которые любят говорить.
Если мы будем обсуждать "уровень насильственных преступлений вне маргинальной среды" - то этот уровень кратно упал, скажем в моём родном Тамбове, где я периодически бываю.
Уровень взаимной вежливости, правовой культуры, просто хорошего отношения друг к другу - с 90х вырос несказанно.
Также и бытового ощущения защищённости от насильственных преступлений условно "на улице".
Знаете если сравнивать личный опыт - мне даже непонятно как можно хоть как-то близко сравнивать эти и те годы.
В 90х если бы "простые" люди попытались не пропускать "крутые" автомобили их бы насильственно остановили дальнейщие варианты: избиение \ вымогательство денег \ насильственные действия сексуального характера.
В 2016 в Тамбове спокойно работали "синие ведёрки".
Есть два нюанса:
1. При ЗП 1.5 млн в год вы начинаете платить 22% -> 10% в ПФР
2. При ЗП 5 млн в год вы начинаете платить 13% -> 15% НДФЛ.
Подскажите почему вы в своих рассчётах учли факт №2, но не учли намного более существенынй факт №1?
Забавный факт: если мы поделим "годовой ВВП РФ == вся добавленная стоимсть произведённая в РФ" / "Собрано всего НДС", то получим, что эффективная ставка налога = 3%
Пруф:
http://www.consultant.ru/document/cons_doc_LAW_308390/8e2dd0994342861d9616fc6cb51fd401f8b41f9e/
Разумеется здесь "кто-то платит 20% кто-то не платит вообще".
Но реальность "в среднем НДС в России 3%" очень сильно отличается от любимых в интернете цифр в 20%.
ПС
Уточню, что последним "нормальным" годом считаю 2019 потому, что два ковидных года с ручным управлением налогами имеют ИМХО искажённую картину.
"назад в 90е" разумеется не хочу.
Но учитывая, что Россия из 90х выбралась - ставлю на то, что обратно она не скатится.
Я бы так сказал:
- выстроенный процесс - это "нижняя" планка результатов вашей работы, когда работа или сделана достаточно хорошо (по тем критериям, которые вы закладывали) или не принята вообще. Убирает кучу головной боли.
- сильная команда - это верхняя планка (на момент сегодня).
Ну Россия за эти 30 лет переняла у Запада гораздо более умелые (более действенные и вызывающие меньше возмущения) способы пропаганды и давления на недовольных. Это раз.
Во вторых вот это:
> Полицейские будут отлавливать подпольщиков, продающих симки и
оборудование, по ночам подпольщики будут отлавливать полицейских и
членов их семей, отчего первые будут умерять свой пыл и ловить лишь тех,
кого им разрешили местные авторитеты.
В моей реальности звучит настолько дико (я не готов говорить "за всех людей на планете", как некоторые тут), что ставит под вопрос всю адекватность комментария.
Если бы я получил такую табличку - то я бы первым делом задумался о том, что данные в ней очень biased (возможно coupled с компетенциями оценивающих PM-ов).
Действительно с чего бы выходцам из разработки иметь вот такие (в порядке убывыния) сильные стороны:
1. Целеполагание и планирование
2. Управление командой
3. Управление людьми
4. Технические компетенции
5. Выстраивание процессов
Гипотеза, которая сразу - что тимлид дольше обсуждает с PM-ом, за то он и ставит высокую оценку.
Э... вы сейчас написали что считаете мошенинками людей, пользующихся вашими рекламными акциями. Вы в рекламе ваших акций такое пишите?
В суд подаёте?
Вы правы абсолютно по всем позициям.
И вот мы в самом начале беседы:
Хаскель пректасный язык для обучения студентов и написания грамотных комментариев (без шуток - моя ремарка о "хороших прктиках" была не просто так).
Но если при таких достоинствах его вклад в индустрию ПО близок к о-малому, значит недостатки in real world всё-таки есть и существенны. И на них не следует закрывать глаза.
Akka была изначально написана на Scala, а не более "взрослом", тогда точно, Хаскель, ИМХО ровно потому, что её изначально пытались сделать для людей, а не "кому не нравится тот сам не прав".
Я как раз основной мой поинт в том, что такой подход более рабочий.
cd linux_***
grep -r "struct list" *.h | wc -l
Ваши ставки?
И да вы же не пытаетесь сказать, что: "ценность двусвязного списка переоценена" => "ценность двусвязного списка 0"?
Мы прыгаем с пункта на пункт, в целом все звучат так:
1. семантическая насыщенность фрагмента на Haskell выше чем на JavaScript
2. Синтаксис хаскеля странен и в нём есть как ошибки, так и помарки
*) a.map(f1).filter(f2).map(f3) >> map f3 $ filter f2 $ map f3 a
**) странные отступы в while при записи на той же строке или громоздкий $ для доступа к полям data
3. Люди действительно знают C-syntax лучше чем Haskell. И пытаться принуждать к неудобству людей заради их же блага работает только если морковка НУ ОЧЕНЬ вкусная.
Ну и независимо от этого с какой-то точки "новая концепция", познакомится с которой несомненно хорошо, становится вещью в себе не добавляя никакой ценности вокруг.
Не важно знание это 150го паттерна проектирования, обход C-types "по улитке" или умение на автомате парсить сложную Haskell-запись.
Маленький компилятор DSL-языка (но поскольку там нужны IR-оптимизации, пусть и неполноценные, то надо хранить состояние, лазить по операциям туда-сюда и оптимизировать их).
Маленький - в смысле без циклов.
Я говорю вот о чём:
Все статьи которые я вижу - в них по счастливому стечению обстоятельств формулировка задачи и внешние API удобны для Haskell (в данном случае у вас презумпция: если получать структуру комментов - сразу всё дерево, а не пошагово, разумеется парсить DOM-дерево на Хаскель будет удобнее чем на Го).
Мой Pet-project для изучения Haskell. Прям с ходу влетаю в то, что мне нужен двусвязный список, с полноценными вставкой \ удалением. Далее мысли:
1. Возможно 2 Map (в прямом обратном направлении, потом всё это в data instance functor && traverse).
2. Погуглить что есть. Ничего лучше не нашёл. Т.е. у того, что я видел под капотом что-то похожее по ассимптотической сложности.
3. Долго думал.
4. Решение: разделить проходы в прямом и обратном направлении (благо задача почти игрушечная, позволяла). Использовать односвязный список, иногда его переворачивать. Использовать разные newtype для прямого и обратного списков для типобезопасности.
То есть когда я пишу программы вселенная мне не предоставляет "удобные для Хаскеля" интерфейсы. И я бы что-то хотя бы отдалённо похожее хотел бы видеть в статьях про Хаскель.
Но в основном это success stories - идущие вразрез с тем опытом, который получил я.
Ровно одна боевая задача - генерация примеров для тестирования нашего DSL. Потому, что Haskell
а) чудо как хорош с Parsec,
б) заставляет делать другую реализацию интерпретатора, что предотвращает "тянуть ошибки на автомате из проекта в его верификатор".
Я вот совсем не знаю JavaScript (1 раз писал для себя расширение кое-что посчитать в GoogleSpreadSheets). Т.е. опыт в Haskell раз в 50 больше чем в JS =)
Написанное вами не выглядит страшно, хотя может где-то под капотом являться, слышал в JS любят неявные побочные эффекты. Просто надо помнить что что делает.
Написанное на Haskell выглядит.
Мне кажется нетипичный синтаксис и любовь коммюнити к наворотам - действительно одина из проблем языка (если ставить целью его проход в массы)
Во-первых вы пропустили ключевое "по широте использования написанного на нём ПО".
Ну и да кто ж сказал, что excel (встроенные макросы или VisualBasic?) плохой? Если люди реально пользуются - значит good enough (ну и эффект первого застолбившего поляну, конечно).
Но в целом при такой разнице конечных подходов обсуждать локальный подход в статье малоосмысленно. Я просто вижу, что практически каждый аргумент интерпретируется нами по-разному и каждый остаётся при своём мнении.
Для меня - крайне мало задач, для которых Хаскель был бы удобен, поэтому вкладывать и дальше своё время в изучение малоосмысленно. У вас вероятно ситуация другая.
======================================
Не заню стоит ли отвечать, но пусть будет для истории.
Ваша реакция процитирована. Она как минимум раздражённая, как максимум - подберите эпитет сами. Мне даже пришлось дисклеймер, что "не атакую Хаскель" написать, т.к. ситуация грозила скатиться в срачик.
А если с empty-line, перед ф-ией то 5. Что даст вклад 5 в:
wc -l *.hs
Хаскель довольно хорошо страхует от ошибок в семантически-разряженном коде. Поэтому какой код писать на Хаскеле - дело вкуса и привычек коммюнити.
По мне привычки писать замысловатый код - плохие практики для целей... (впрочем про разность целей написано выше).
Вы постулировали удобный для Haskell АПИ и у вас всё хорошо. Имеете право. Можете повторить это ещё и ещё.
Но в моей практике технология: "мы делаем на ней только удобное, если что-то не удобно - скидываем головную боль на соседний отдел", - нужна в сложном проекте только в каких-то совсем экзотических условиях (скажем SQL - пример такой технологии, да).