А если "ИП Иванов и компания" просит вас "брат дарагой наличкой или картой, терминал 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.
Потому, что сначала пытались заставить других думать, что "если он не горит за проект - то он 'Петрович'", а когда вас попросили примерить это на себя и приветси проекты за которые вам не стыдно, то выяснилось, что "каждому своё".
спасибо за ответ. Но я вот прочитал JavaBeans - и написано, что это не интерфейс, а скорее соглашения (фактически код-стайл придуманный корпорацией Sun Microsystems). Если бы это был (поддерживаемый языком \ платформой) интерфейс - вопросов нет.
А так колучается довольно сомнительный, но продвигаемый на уровне стандарта код-стайл. Зачем ему следовать, поясните пожалуйста?
ПС Разумность следования общим шаблонам я, разумеется, понимаю - обьясните зачем следовать JavaBeans на уровне здравого смысла.
3-4 уровни автоматизации (из 5-уровневой системы) самые плохие, если говорить о физических процессах. Человек УЖЕ теряет квалификацию, а автоматизированная система ЕЩЁ не способна адекватно справиться с проблемными ситуациями.
ПС В разработке это разумеется не так. Как в информационных системах и СПР на производстве - если честно не знаю.
Ну если заказчики таки хотят 60 лет - таки пишите. А там или шах или ишак (по факту сами придут к регулярной модернизации через 10-15 лет, только немного пожевав кактус).
Получается, что на таких объёмах внедрение этой технологии "нафиг не надо". 1.6 млн рублей в год для предприятий такого уровня - это ну в принципе ниже уровня "сигнал\шум".
А рисков (в том числе связанных с меньшей адаптивностью нейросетки при любых изменениях) после изменения процесса можно огрести ох как много.
Себе с карты на карту кидаю нормально.
А если "ИП Иванов и компания" просит вас "брат дарагой наличкой или картой, терминал 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.
Потому, что сначала пытались заставить других думать, что "если он не горит за проект - то он 'Петрович'", а когда вас попросили примерить это на себя и приветси проекты за которые вам не стыдно, то выяснилось, что "каждому своё".
спасибо за ответ.
Но я вот прочитал JavaBeans - и написано, что это не интерфейс, а скорее соглашения (фактически код-стайл придуманный корпорацией Sun Microsystems).
Если бы это был (поддерживаемый языком \ платформой) интерфейс - вопросов нет.
А так колучается довольно сомнительный, но продвигаемый на уровне стандарта код-стайл.
Зачем ему следовать, поясните пожалуйста?
ПС
Разумность следования общим шаблонам я, разумеется, понимаю - обьясните зачем следовать JavaBeans на уровне здравого смысла.
3-4 уровни автоматизации (из 5-уровневой системы) самые плохие, если говорить о физических процессах.
Человек УЖЕ теряет квалификацию, а автоматизированная система ЕЩЁ не способна адекватно справиться с проблемными ситуациями.
ПС
В разработке это разумеется не так.
Как в информационных системах и СПР на производстве - если честно не знаю.
Я хочу видеть в документации - чтобы "что за система" "роль нашей части системы" и "как мы сопрягаемся с соседними частями" было из документации ясно.
Этого обычно (после некоторого опыта работы в компании) достаточно, чтобы осознанно принимать решения по дизайну своей части системы.
Ну если заказчики таки хотят 60 лет - таки пишите.
А там или шах или ишак (по факту сами придут к регулярной модернизации через 10-15 лет, только немного пожевав кактус).
Сравнивая ЗП в вакансиях / резюме скажем 1С vs Go такого не скажешь.
ПС
Хотя да я помню в 2010 году ЗП в соседнем отделе "миддл ABAP разработчика" около 300к.
Получается, что на таких объёмах внедрение этой технологии "нафиг не надо".
1.6 млн рублей в год для предприятий такого уровня - это ну в принципе ниже уровня "сигнал\шум".
А рисков (в том числе связанных с меньшей адаптивностью нейросетки при любых изменениях) после изменения процесса можно огрести ох как много.