Для "влияния" на биткоин надо 50+% proof of work (это если заранее проигнорирповать некоторые варианты, например "срочный форк" исключающий китайский proof of work из консенсуса).
И какое же такое "влияние" останется у китая, после того, как ферма переместится в казахстан?
> Опять же удивляться тому, что люди обучаются и уходят, неблагодарные. Вы в каком году живёте? Люди работают за деньги, какая благодарность вообще вы о чем?
Вопрос в том, что с т.з. сеньора в такого джуна, пришедшего в команду, надо вкладываться. В начале вообще по балансу "потрачено на него времени vs решено им задач" может минус выходить и нехилый. И именно поэтому надо заранее прикидывать варианты: время, когда уже потраченные на него "силы и время" он начнёт возвращать настанет ли?
Дают задачу, посчитать количество смен знака в последовательности. Решаю, просят пофункциональней. Предлагаю варианты, но недостаточно хардкорные видимо. На каком-то рабочем решении остановились, пошли дальше.
Мне кажется, что основная фишка Scala - наличие функционального подхода, который позволяет писать "маломутабельный" код (остальное - в виде синтаксического сахара под "maybe", "record classes" и т.п. много где есть).
И если рассматривать Scala-разработчиков в этом аспекте (а работодатель имеет на это право) - то это вполне разумный кэйс "брать разработчика с уже повёрнутыми на FP мозгами".
В педагогике, во всяком случае в прикладной педагогике - так как это объясняет преподаватель кружка родителям, есть понятия "знание -> умение -> навык". Каждый следующий уровень - качественно отличается от предыдущего.
Вы и говорите на разных языках. Ваш оппонент о "знании", а вы как минимум об "умении".
Ну в целом логично: если банк подозревает, что эти вот переводы - уход от налогов, но за них он получает комиссию, то вряд ли у него ярко вырежанный конфликт интересов.
А если "ИП Иванов и компания" просит вас "брат дарагой наличкой или картой, терминал 5 минут назад сломался", - то он плюёт не только на налоги но и на вас с высокой колокольни. И это не проблема ЦБ и Сбера.
==================================== Этот пролог был добавлен чуть позднее: Ну вот смотрите в Scala есть иммутабельность коллекций, но это нетранизитивный признак, т.е. в данные в иммутабельной коллекции могут поменяться "подвержены эффектам" - т.е. List[SomeClass] это совсем не иммутабельная штука.
Но блин мутабельность данных штука-то удобная: начиная с банального "счётчик у дерева - сколько раз посетили", заканчивая честно-мутабельным полем у структуры. Но тадам: у нас есть хаскель, который умеет управлять эффектами. Надо только вместо монады State ввести нормальный эффект "мутабельная переменная", с которой было бы удобно работать.
Разумеется надо: - а) помечать мутабельность явно (непосредственную и транзитивную) - б) с этим надо уметь работать, видимо точно так, как с монадой State, с точки зрения выполнения инвариантов (кода программистом \ работающей программы при оптимизациях компилятором) -в) безболезненно вносить мутабельное поле в структуру данных, без изменения большого куска кода (или в соответствии с п.а) - пусть много кода меняет средство разработки).
Дальше ответ на ваш вопрос - но он наверное более технический. ==========================================
Сахара - чтобы поддерживать мутабельные структуры а не городить огород, кажый раз через State или городить огород "недо-замену" на иммутабельных структурах Более того, чтобы поддерживать мутабельные структуры "обычном синтаксисте - ХЗ как его назвать, expression-syntax, без перехода в do-notation).
Зачем компилятору протаскивать \ снимать признак: Ну вот предположим было: data Student = Student { name :: String, gender :: Gender }
Вдруг мы осознали, что в современном мире живём и нужно: data Student = Student { name :: String, mut gender :: Gender }
Компилятор доправит нас здесь (и явно везде вверх по структурам данных \ типам): data var Student = Student { name :: String, mut gender :: Gender }
В итоге: - В типах выражены те структуры, которые не immutable - ну и соответственно подсказка для компилятора, что и насколько агрессивно можно параллелить \ менять порядок исполнения - подозреваю что правила для компилятора будут те же, что и с монадой State.
- var (транзитивно мутабельный) отличается от mut (непосредственно мутабельный). При удалении/добавлении mut(вдруг я осознал, что mut gender : :Gender - излишне современно) - можно попросить компилятор "привести в порядок все зависящие от него типы\структуры на предмет var"
Если в нём засахарить монаду State (как в Kotlin засахарена монада Option), разумеется протаскивать \ снимать признак "где-то в кишках ссылается на mutable type" надо встроенным средством рефакторинга - то может быть.
В текущем виде - очень больно программировать многие вещи.
Опросы - это очень biased выборка относительно голосования (или если хотите альтернативную трактовку: дошедшие до урн голосования это biased выборка относительно всего населения) Не все кого опрашивают - голосуют.
Скажем Екатерина Шульман (которую весьма сложно заподозрить в симпатиях к власти) говорит: "митингуют молодые, голосуют пожилые, а выбирают на основании голосования".
на мой взгляд проблема в том, что некоторые из упомянутых мест надо вот прям реально учить. Из-за того, что "фишки Х в языке нет", нужно использовать подходящий паттерн. Подходят Y или Z, но у нас принято использовать Z.
Ну вот скажем я могу довольно много рассказать про "абстрактные сборщики мусора" (предполагаю достаточно много, чтобы сойти за "сеньёр-помидора в вакууме") - ну они все построены на взаимозависимости пространственной и временной локальносте и удобстве многопоточного вызова. Но вряд ли моих знаний хватит хватит на то, чтобы удовлетворить требованиям на Java middle developer. Просто там же действительно надо use-case знать.
Причём в первом же абзаце обозначена проблема. Недавно сознательно написал такой код: res = sync_and_do_something(data) if (is_err(res)) { close_and_release(data); return 1; } close_and_release(data); return 0;
Потому, что совпадение низкоуровневого поведения при успехе и неуспехе - это так получилось. При любом техническом или функциональном изменении они разойдутся и появится описанная выше проблема, когда содержательно разный код "продолжить работу vs закрыть работу" описывается одной функцией со 100500 параметров.
ПС К стати мне кажется, что функциональное программирование (при существующих его недостатках) частично решает описанную проблему, т.к. там принято в более явном виде разделять "основную логику" от "побочной, передаваемой как лямбды". Мне сложно это описать более явно, но вот есть ощущение, что в ФП такой стиль \ привычки, что этой проблемы скорее не возникнет.
Подождите, но насколько я помню B2 - это формально около 5000 словарного запаса (чего недостаточно для редъявляемых требований, но всё же).
Опять вас же не B2 в программировании спрашивают, а "презентовать себя", "рассказать о работе". Самые большие пробелы (в бытовом общении, смоллток и т.п.) можно и не заполнять если переезжать не хотите.
Язык, кроме знания ситнаксических конструкций, это: - понимание сильных и сбалых сторон. - знание "тонких" мест, где можно наесться далеко не шоколада. - знание стандартной библиотеки и библиотек в наиболее часто употребимых подходах - знание API вовне языка (да сегодня это чаще SQL \ JSON \ Google Protobuf - но не всегда). - знание архитектурных особенностей - знание дизайн-особенностей (дизайн-паттернов "как все делают" и "как надо делать"). - знание\понимание работы системы сборки ......
Я понимаю, что через 5 минут можно и "hello world" написать и со StackOverflow какой-то код утащить (а остальное по аналогии со знакомым языком сделать). Но если ты хочешь быть на языке Х востребованным специалистом (и перекрыть дисэдватнэдж 65 лет) - то умение StackOverflow-ить недостаточно.
Как Parler банить или Epic Store - таб быстро получается. А как налоги с цифрового контента платить или отвечать кто решения принимает - так у нас лапки регламент.
К сожалению в настоящий момент на рынке цифровых платформ тяга к монополизации такова, что чем быстрее государства действующие в интересах своих граждан разберутся как эти платформы превратить в нормальный рынок - тем лучше.
ПС Касательно России два момента: а) действует ли наше государство в наших интересах - вопрос наш Российский, и Гугл тут против нас играть может, а за нас - очень вряд ли. б) действовать наши власти будут как обычно - посмотрят что делают во всём мире (см примеры Франции и Австралии с "национализацией" налогов по месту получения прибылей) и сдерут лучшие практики добавив национального калорита. Будет ли национальных калорит в нашу с вами пользу - см. пункт "а".
День тишины - изначально вполне разумная идея (что человек должен голосовать не как "информационный пузырь" подскажет а своим умом). И следование разумным законодательным инициативам похвально.
У меня остался только один вопрос: блокирование оппозиционных и провластных каналов синхронное или работает только в одну сторону?
Вы, наверное, очень хороший менеджер, с очень хорошими soft skills.
Потому, что сначала пытались заставить других думать, что "если он не горит за проект - то он 'Петрович'", а когда вас попросили примерить это на себя и приветси проекты за которые вам не стыдно, то выяснилось, что "каждому своё".
Для "влияния" на биткоин надо 50+% proof of work (это если заранее проигнорирповать некоторые варианты, например "срочный форк" исключающий китайский proof of work из консенсуса).
И какое же такое "влияние" останется у китая, после того, как ферма переместится в казахстан?
> Опять же удивляться тому, что люди обучаются и уходят, неблагодарные. Вы в каком году живёте? Люди работают за деньги, какая благодарность вообще вы о чем?
Вопрос в том, что с т.з. сеньора в такого джуна, пришедшего в команду, надо вкладываться. В начале вообще по балансу "потрачено на него времени vs решено им задач" может минус выходить и нехилый.
И именно поэтому надо заранее прикидывать варианты: время, когда уже потраченные на него "силы и время" он начнёт возвращать настанет ли?
Мне кажется, что основная фишка Scala - наличие функционального подхода, который позволяет писать "маломутабельный" код (остальное - в виде синтаксического сахара под "maybe", "record classes" и т.п. много где есть).
И если рассматривать Scala-разработчиков в этом аспекте (а работодатель имеет на это право) - то это вполне разумный кэйс "брать разработчика с уже повёрнутыми на FP мозгами".
спасибо за хорошую формулировку.
Меня как-то убидили почитать ТРИЗ - и всё время чтения чувствовал, что
меня неё...что-то не так, но сформулировать кроме как "фигня какая-то" не мог.В педагогике, во всяком случае в прикладной педагогике - так как это объясняет преподаватель кружка родителям, есть понятия "знание -> умение -> навык".
Каждый следующий уровень - качественно отличается от предыдущего.
Вы и говорите на разных языках.
Ваш оппонент о "знании", а вы как минимум об "умении".
Ну в целом логично: если банк подозревает, что эти вот переводы - уход от налогов, но за них он получает комиссию, то вряд ли у него ярко вырежанный конфликт интересов.
Себе с карты на карту кидаю нормально.
А если "ИП Иванов и компания" просит вас "брат дарагой наличкой или картой, терминал 5 минут назад сломался", - то он плюёт не только на налоги но и на вас с высокой колокольни. И это не проблема ЦБ и Сбера.
====================================
Этот пролог был добавлен чуть позднее:
Ну вот смотрите в Scala есть иммутабельность коллекций, но это нетранизитивный признак, т.е. в данные в иммутабельной коллекции могут поменяться "подвержены эффектам" - т.е. List[SomeClass] это совсем не иммутабельная штука.
Но блин мутабельность данных штука-то удобная: начиная с банального "счётчик у дерева - сколько раз посетили", заканчивая честно-мутабельным полем у структуры.
Но тадам: у нас есть хаскель, который умеет управлять эффектами. Надо только вместо монады State ввести нормальный эффект "мутабельная переменная", с которой было бы удобно работать.
Разумеется надо:
- а) помечать мутабельность явно (непосредственную и транзитивную)
- б) с этим надо уметь работать, видимо точно так, как с монадой State, с точки зрения выполнения инвариантов (кода программистом \ работающей программы при оптимизациях компилятором)
-в) безболезненно вносить мутабельное поле в структуру данных, без изменения большого куска кода (или в соответствии с п.а) - пусть много кода меняет средство разработки).
Дальше ответ на ваш вопрос - но он наверное более технический.
==========================================
Сахара - чтобы поддерживать мутабельные структуры а не городить огород, кажый раз через State или городить огород "недо-замену" на иммутабельных структурах
Более того, чтобы поддерживать мутабельные структуры "обычном синтаксисте - ХЗ как его назвать, expression-syntax, без перехода в do-notation).
Зачем компилятору протаскивать \ снимать признак:
Ну вот предположим было:
data Student = Student { name :: String, gender :: Gender }
Вдруг мы осознали, что в современном мире живём и нужно:
data Student = Student { name :: String, mut gender :: Gender }
Компилятор доправит нас здесь (и явно везде вверх по структурам данных \ типам):
data var Student = Student { name :: String, mut gender :: Gender }
В итоге:
- В типах выражены те структуры, которые не immutable - ну и соответственно подсказка для компилятора, что и насколько агрессивно можно параллелить \ менять порядок исполнения - подозреваю что правила для компилятора будут те же, что и с монадой State.
- var (транзитивно мутабельный) отличается от mut (непосредственно мутабельный). При удалении/добавлении mut(вдруг я осознал, что mut gender : :Gender - излишне современно) - можно попросить компилятор "привести в порядок все зависящие от него типы\структуры на предмет var"
Если в нём засахарить монаду State (как в Kotlin засахарена монада Option), разумеется протаскивать \ снимать признак "где-то в кишках ссылается на mutable type" надо встроенным средством рефакторинга - то может быть.
В текущем виде - очень больно программировать многие вещи.
или Rust
Опросы - это очень biased выборка относительно голосования (или если хотите альтернативную трактовку: дошедшие до урн голосования это biased выборка относительно всего населения)
Не все кого опрашивают - голосуют.
Скажем Екатерина Шульман (которую весьма сложно заподозрить в симпатиях к власти) говорит: "митингуют молодые, голосуют пожилые, а выбирают на основании голосования".
Проблема как раз в том, что "кухарок" не допускают к управлению страной, а только людей "окончивших правильные вузы".
на мой взгляд проблема в том, что некоторые из упомянутых мест надо вот прям реально учить. Из-за того, что "фишки Х в языке нет", нужно использовать подходящий паттерн. Подходят Y или Z, но у нас принято использовать Z.
Ну вот скажем я могу довольно много рассказать про "абстрактные сборщики мусора" (предполагаю достаточно много, чтобы сойти за "сеньёр-помидора в вакууме") - ну они все построены на взаимозависимости пространственной и временной локальносте и удобстве многопоточного вызова.
Но вряд ли моих знаний хватит хватит на то, чтобы удовлетворить требованиям на Java middle developer. Просто там же действительно надо use-case знать.
Причём в первом же абзаце обозначена проблема. Недавно сознательно написал такой код:
res = sync_and_do_something(data)
if (is_err(res)) {
close_and_release(data);
return 1;
}
close_and_release(data);
return 0;
Потому, что совпадение низкоуровневого поведения при успехе и неуспехе - это так получилось. При любом техническом или функциональном изменении они разойдутся и появится описанная выше проблема, когда содержательно разный код "продолжить работу vs закрыть работу" описывается одной функцией со 100500 параметров.
ПС
К стати мне кажется, что функциональное программирование (при существующих его недостатках) частично решает описанную проблему, т.к. там принято в более явном виде разделять "основную логику" от "побочной, передаваемой как лямбды".
Мне сложно это описать более явно, но вот есть ощущение, что в ФП такой стиль \ привычки, что этой проблемы скорее не возникнет.
Подождите, но насколько я помню B2 - это формально около 5000 словарного запаса (чего недостаточно для редъявляемых требований, но всё же).
Опять вас же не B2 в программировании спрашивают, а "презентовать себя", "рассказать о работе".
Самые большие пробелы (в бытовом общении, смоллток и т.п.) можно и не заполнять если переезжать не хотите.
Язык, кроме знания ситнаксических конструкций, это:
- понимание сильных и сбалых сторон.
- знание "тонких" мест, где можно наесться далеко не шоколада.
- знание стандартной библиотеки и библиотек в наиболее часто употребимых подходах
- знание API вовне языка (да сегодня это чаще SQL \ JSON \ Google Protobuf - но не всегда).
- знание архитектурных особенностей
- знание дизайн-особенностей (дизайн-паттернов "как все делают" и "как надо делать").
- знание\понимание работы системы сборки
......
Я понимаю, что через 5 минут можно и "hello world" написать и со StackOverflow какой-то код утащить (а остальное по аналогии со знакомым языком сделать).
Но если ты хочешь быть на языке Х востребованным специалистом (и перекрыть дисэдватнэдж 65 лет) - то умение StackOverflow-ить недостаточно.
Как Parler банить или Epic Store - таб быстро получается.
А как налоги с цифрового контента платить или отвечать кто решения принимает - так у нас
лапкирегламент.К сожалению в настоящий момент на рынке цифровых платформ тяга к монополизации такова, что чем быстрее государства действующие в интересах своих граждан разберутся как эти платформы превратить в нормальный рынок - тем лучше.
ПС
Касательно России два момента:
а) действует ли наше государство в наших интересах - вопрос наш Российский, и Гугл тут против нас играть может, а за нас - очень вряд ли.
б) действовать наши власти будут как обычно - посмотрят что делают во всём мире (см примеры Франции и Австралии с "национализацией" налогов по месту получения прибылей) и сдерут лучшие практики добавив национального калорита. Будет ли национальных калорит в нашу с вами пользу - см. пункт "а".
День тишины - изначально вполне разумная идея (что человек должен голосовать не как "информационный пузырь" подскажет а своим умом). И следование разумным законодательным инициативам похвально.
У меня остался только один вопрос: блокирование оппозиционных и провластных каналов синхронное или работает только в одну сторону?
Т.е. та контора стимулировала разработчиков делать большие коммиты (с вероятной мотивацией: "большой => неделимый на более мелкие части => сложный")?
Вы, наверное, очень хороший менеджер, с очень хорошими soft skills.
Потому, что сначала пытались заставить других думать, что "если он не горит за проект - то он 'Петрович'", а когда вас попросили примерить это на себя и приветси проекты за которые вам не стыдно, то выяснилось, что "каждому своё".