Секрет в том, что надо уметь воспроизвести звуки, которые вы слышите, т.е. владеть звуками изучаемого языка и всякими примочками типа редукций, элизий и т.п. Иначе вы воспринимаете звуки через русские, что приводит к коллизии совершенно разных слов, либо ожидаете услышать слова как они даются в озвучке при изучении, но в реальной жизни так никто не говорит.
Попробуйте Speekify, он как раз заточен под случай, когда в пассиве много слов и грамматики, а на слух воспринимается плохо.
Ну так активное слушание — это не замена пассивному. Это этап тренировки. 2-3 месяца по 30 минут ежедневных тренировок по активному слушанию и можно забыть про субтитры при пассивном просмотре фильмов и сериалов.
А как вы описываете, годами смотреть с субтитрами — это извращение имхо какое-то.
Если Вы хотите ознакомиться с наиболее частыми словами в конкретном тексте, то можно сервис WordsFromText использовать. Будет вам словарик по конкретному произведению.
От субтитров надо отвыкать, они не дают раскрыть канал восприятия на слух. Ну а чтобы легче было воспринимать на слух — надо практиковать активное слушание, это когда помимо самого слушания вы выполняете доп.задания, например повторяете услышанное как на Speekify, или записываете услышанное как на LyricsTraining.
проще объяснить состояние инкаплсулированного стейта в объекте, при всем при этом, легко в голове почти у каждого среднестатистического человека укладывается ограниченный контекст
Вы рассматриваете какие-то очень тривиальные примеры, оторванные от реальной практики. Спору нет, ООП даёт быструю иллюзию понимания. А осознание того, что оно ложно чуть менее, чем полностью, приходит только с годами опыта.
Попробуйте какие-нибудь простенькие паттерны типа абстрактной фабрики или моста объяснить человеку со стороны.
думать по разному сложно, человек ищет одну сторону мышления
Это довольно спорный тезис. Как же разносторонность мышления?
Допустим нам надо решить проблему 2+2.
Плохой пример. В данном случае, нет смысла даже в функции, это просто константа.
В дгугом просто забить и выполнить задание.
Честно говоря, я уже потерял вашу мысль… Изначально Вы писали, что "императивное программирование" интуитивно понятнее. Доминирующий вариант императивного программирования — ООП. Но теперь Вы, похоже, уже согласны, что ООП для человека без спец.подготовки — это сложно.
Так вещи — это конкретные конструкции. А начинать надо с идей и предпосылок.
Например, мне не встречалось людей, у которых возникали проблемы с пониманием Linux pipes, а это по сути реализация одной из основных идей ФП. Хотя тут можно возразить, что не так много людей знакомы с Linux pipes, но концептуально это всё равно достаточно просто.
Имхо, проблема ФП в том, что многие авторы книг и статей перебарщивают с математической терминологией, чем создают иллюзию, что всё ппц как сложно.
Видимо, вы имеете в виду дословный перевод алгоритмов, основанных на массивах, на функциональные языки. Но это ложная задача, для неизменяемых структур есть свои алгоритмы. А там где надо (например в БД записать или пользователю результат отдать), там сайд-эффекты управляемо возможны штатными средствами стандартной библиотеки.
человек понимает сразу как работает эта шайтан машина, что куда положить и т.д.
Ага, только это иллюзия понимания… Потом человек попадает на сайд-эффект и "весело" проводит неделю за отладкой в полном непонимании как работает эта шайтан машина.
Я ничего не отрицал, потому что изначально не понимаю, чем описание последовательности действий (процедурное программирование) проще, чем описание конвейера?.. Понятно только, что ООП (описание объектов и их взаимодействия) уже точно сложнее.
Тем не менее, всё производство давно уже конвейерное. И если вы хотите стабильный код, вам всё равно придётся отказываться от "последовательности действий" и эмулировать конвейер в императиве, наворачивая кучу паттернов. Просто это неудобно по сравнению с ФП, где всё из коробки под это заточено.
Я за ним слежу, и даже есть один проект в продакшене. Но по динамике развития, складывается ощущение, что там один Жозе его развивает (это видно по статискике github).
Хм, так вы посмотрите статистику за 2018-й год. На долю Жозе приходится примерно половина коммитов, но как минимум ещё 9 человек активно участвовали.
Но в целом, смотреть динамику развития Elixir по компилятору не очень правильно. Основное развитие идёт в тулинге и в сопутствующих библиотеках. Например, из свеженького Phoenix LiveView
Функциональный подход — «запишите формулу или постройте примитивную математическую модель происходящего»
Совсем нет. Функциональный подход — "опишите конвейер преобразований".
Соответственно, каждый этап самостоятелен и не лезет в детали реализации других этапов, а просто принимает входные данные и выдаёт свой результат.
Только людей с математическим складом ума сильно меньше.
Эм, хоть это никак не относится к выбору подходов, но я как-то не верю в существование программистов с другим складом ума.
Это, кстати, заблуждение — думать что между сайтами-визитками и хайлоадом ничего нет по середине. В моём понимании, большинство — это куча разнообразных проектов с многомиллионными бюджетами, но при этом не предполагающих особых нагрузок. Если посмотреть правде в глаза, то даже средне нагруженных проекты от силы 1% от веб-приложений наберётся (сайты-визитки я в расчёт даже не беру)
Я бы сформулировал, что если не предполагается нагрузка выше 10 rps в среднем за сутки, и хотя бы 50 rps в пиковые часы, то даже смотреть в сторону Go — совершенно нецелесообразно. Понятно, что запросы сильно разные бывают и цифры ориентировочные, но порядок примерно такой.
Ну, кстати, да. Про Node.js забыл.
А что касается массовости, массам и Go не нужен, потому что для большинства проектов вообще пофиг отвечает у тебя сервер за 100 ms или за 30 ms.
Слишком сильно зависит от бэкграунда, поэтому я бы сказал, что сравнить в общем случае невозможно. Кому-то быстрее Go получится освоить, кому-то — C#.
Я больше про то, что все эти "за 1 день" — не более, чем маркетинговый булшит.
Что-то начать писать можно на 1-й день на любом языке (особенно если у вас уже есть пяток ЯП в арсенале), но это не значит, что он освоен.
Потому что Go отъедает рынок у python, php, ruby и пр, где нет единого бинарника.
Это фантазии любителей Go. Python, PHP, Ruby и так для HighLoad не часто использовались. А писать, к примеру, какую-нибудь админку (внутренний проект) с развесистой бизнес-логикой для 1000 юзеров в месяц на Go — это надо сильно упороться.
Go играет на поле Scala, Elixir, Haskell, Rust, C-расширения. Причём первые 3 дают более приятные возможности для программирования.
Потому что иногда приходится возится с бинарником напрямую, и когда это один файл — это удобно.
Зачем с ним возиться напрямую? Вы по FTP что-ли деплоите, как в старые ламповые времена?
Секрет в том, что надо уметь воспроизвести звуки, которые вы слышите, т.е. владеть звуками изучаемого языка и всякими примочками типа редукций, элизий и т.п. Иначе вы воспринимаете звуки через русские, что приводит к коллизии совершенно разных слов, либо ожидаете услышать слова как они даются в озвучке при изучении, но в реальной жизни так никто не говорит.
Попробуйте Speekify, он как раз заточен под случай, когда в пассиве много слов и грамматики, а на слух воспринимается плохо.
Ну так активное слушание — это не замена пассивному. Это этап тренировки. 2-3 месяца по 30 минут ежедневных тренировок по активному слушанию и можно забыть про субтитры при пассивном просмотре фильмов и сериалов.
А как вы описываете, годами смотреть с субтитрами — это извращение имхо какое-то.
Если Вы хотите ознакомиться с наиболее частыми словами в конкретном тексте, то можно сервис WordsFromText использовать. Будет вам словарик по конкретному произведению.
От субтитров надо отвыкать, они не дают раскрыть канал восприятия на слух. Ну а чтобы легче было воспринимать на слух — надо практиковать активное слушание, это когда помимо самого слушания вы выполняете доп.задания, например повторяете услышанное как на Speekify, или записываете услышанное как на LyricsTraining.
Вы рассматриваете какие-то очень тривиальные примеры, оторванные от реальной практики. Спору нет, ООП даёт быструю иллюзию понимания. А осознание того, что оно ложно чуть менее, чем полностью, приходит только с годами опыта.
Попробуйте какие-нибудь простенькие паттерны типа абстрактной фабрики или моста объяснить человеку со стороны.
Это довольно спорный тезис. Как же разносторонность мышления?
Плохой пример. В данном случае, нет смысла даже в функции, это просто константа.
Честно говоря, я уже потерял вашу мысль… Изначально Вы писали, что "императивное программирование" интуитивно понятнее. Доминирующий вариант императивного программирования — ООП. Но теперь Вы, похоже, уже согласны, что ООП для человека без спец.подготовки — это сложно.
Так вещи — это конкретные конструкции. А начинать надо с идей и предпосылок.
Например, мне не встречалось людей, у которых возникали проблемы с пониманием Linux pipes, а это по сути реализация одной из основных идей ФП. Хотя тут можно возразить, что не так много людей знакомы с Linux pipes, но концептуально это всё равно достаточно просто.
Имхо, проблема ФП в том, что многие авторы книг и статей перебарщивают с математической терминологией, чем создают иллюзию, что всё ппц как сложно.
Видимо, вы имеете в виду дословный перевод алгоритмов, основанных на массивах, на функциональные языки. Но это ложная задача, для неизменяемых структур есть свои алгоритмы. А там где надо (например в БД записать или пользователю результат отдать), там сайд-эффекты управляемо возможны штатными средствами стандартной библиотеки.
А вдруг затык в том, что Вы непонятно объясняете функциональщину? xD
В шарпе слабенький паттерн-матчинг, но хоть какой-то добавили — уже плюс, тут спору нет.
Ага, только это иллюзия понимания… Потом человек попадает на сайд-эффект и "весело" проводит неделю за отладкой в полном непонимании как работает эта шайтан машина.
Я ничего не отрицал, потому что изначально не понимаю, чем описание последовательности действий (процедурное программирование) проще, чем описание конвейера?.. Понятно только, что ООП (описание объектов и их взаимодействия) уже точно сложнее.
Тем не менее, всё производство давно уже конвейерное. И если вы хотите стабильный код, вам всё равно придётся отказываться от "последовательности действий" и эмулировать конвейер в императиве, наворачивая кучу паттернов. Просто это неудобно по сравнению с ФП, где всё из коробки под это заточено.
Возможно. Но тот сегмент, который я выше упомянул, это как раз зачастую автоматизация бизнес-процессов с очень развесистой логикой.
Модель асинхронности Go мне, кстати, не нравится, в Erlang/Elixir гораздо интереснее и, на мой взгляд, удобнее.
Хм, так вы посмотрите статистику за 2018-й год. На долю Жозе приходится примерно половина коммитов, но как минимум ещё 9 человек активно участвовали.
Но в целом, смотреть динамику развития Elixir по компилятору не очень правильно. Основное развитие идёт в тулинге и в сопутствующих библиотеках. Например, из свеженького Phoenix LiveView
Совсем нет. Функциональный подход — "опишите конвейер преобразований".
Соответственно, каждый этап самостоятелен и не лезет в детали реализации других этапов, а просто принимает входные данные и выдаёт свой результат.
Эм, хоть это никак не относится к выбору подходов, но я как-то не верю в существование программистов с другим складом ума.
Это, кстати, заблуждение — думать что между сайтами-визитками и хайлоадом ничего нет по середине. В моём понимании, большинство — это куча разнообразных проектов с многомиллионными бюджетами, но при этом не предполагающих особых нагрузок. Если посмотреть правде в глаза, то даже средне нагруженных проекты от силы 1% от веб-приложений наберётся (сайты-визитки я в расчёт даже не беру)
Я бы сформулировал, что если не предполагается нагрузка выше 10 rps в среднем за сутки, и хотя бы 50 rps в пиковые часы, то даже смотреть в сторону Go — совершенно нецелесообразно. Понятно, что запросы сильно разные бывают и цифры ориентировочные, но порядок примерно такой.
Ну, кстати, да. Про Node.js забыл.
А что касается массовости, массам и Go не нужен, потому что для большинства проектов вообще пофиг отвечает у тебя сервер за 100 ms или за 30 ms.
Слишком сильно зависит от бэкграунда, поэтому я бы сказал, что сравнить в общем случае невозможно. Кому-то быстрее Go получится освоить, кому-то — C#.
Я больше про то, что все эти "за 1 день" — не более, чем маркетинговый булшит.
Что-то начать писать можно на 1-й день на любом языке (особенно если у вас уже есть пяток ЯП в арсенале), но это не значит, что он освоен.
Это фантазии любителей Go. Python, PHP, Ruby и так для HighLoad не часто использовались. А писать, к примеру, какую-нибудь админку (внутренний проект) с развесистой бизнес-логикой для 1000 юзеров в месяц на Go — это надо сильно упороться.
Go играет на поле Scala, Elixir, Haskell, Rust, C-расширения. Причём первые 3 дают более приятные возможности для программирования.
Зачем с ним возиться напрямую? Вы по FTP что-ли деплоите, как в старые ламповые времена?