Африка плохой пример. Там почти все страны автократии или гибридные режимы. А у более-менее демократических экономические показатели как раз выше (опять же — обычно).
Как не странно результатом программирования будет программа.
И главная особенность программы — это то что она состоит из последовательно выполняющихся шагов.
Ловите императивного программиста.
С одной стороны, для программ на Прологе или функциональных языках, это не обязательно так.
С другой стороны, машина Тьюринга — это буквально математическая абстракция, состоящая из последовательно выполняющихся шагов. Да и вообще математические теории модели с дискретным временем вполне существуют.
Чего бы нам хотелось от людей, которые вышли из школы. Ну наверно:
Умения отличать здравые рассуждения от бреда. Всякого, и политического, и медицинского, и научного
Несколькими строчками ниже автор иронически интересуется, зачем в школе учат каким-то ненужным школьнику вещам, не для кроссвордов ли? Так для умения находить бред и учат! Как человек, выбравший направление «Литература+ Родной язык + Иностранный язык», и забивший на всё остальное, поймёт, что физик врёт? А никак, это можно сделать только сопоставив предлагаемые утверждения со своими знаниями, хотя бы школьными.
Короче, взаимоисключающие параграфы.
И вообще, если учить тому, что точно понадобится, начинать, конечо, нужно с кулинарии. Серьёзно, жаль что в моё время этому учили только девочек.
Каждый предмет делить на базовый и углубленный уровень. Не с 9 класса, а с 1-го. И не надо грузить ребенка знаниями, которые ему не интересны.
Ну тогда всем учителям придется учиться играть в Геншин (или что там сейчас популярно).
Вот серьёзно? Первоклашки должны выбирать, что им изучать? Люди, бывает, и за 30 решают сменить профессию. Сейчас они хотя бы что-то могут вспомнить из школьной программы
Заголовок спойлера
по информатике
, а так вообще шансов не будет.
Кстати говоря, я, понаблюдав за тем, как люди решают задачи во время профессиональной деательности, и самообучаясь пришёл к противоположному выводу насчёт обучения только нужному. Учить (в школах, вузах и т.п.) стоит только тому, что самому человеку кажется ненужным. Потому что если что-то действительно нужно знать, у человека хватит мотивации изучить это самостоятельно. А решение проблем без кругозора быстро вырождается в запросы к Гуглу наподобие «какой стороной паяльника удобнее всего забивать в стену шурупы». Потому что ачальство поставило задачу вставить в стену шурупы, где-то сышал, что их можно забить, а сам владеет только паяльником, но очень хорошо.
Насчёт математики:
Дядька задался вопросом, а как вообще человек решает проблему/задачу, если он не знает для нее готового решения. В качестве подопытных он в основном использовал маленьких детей, садюга. Вот это самое умение найти решение без подсказок он и называл продуктивным мышлением.
у него там много интересных наблюдений и выводов. Главный для этой статьи – продуктивное мышление насмерть убивается заучиванием готовых решений. Ой… не может быть… то есть 200 примеров на упрощение выражений… и потом еще 200 на использование суммы квадратов…
А зачем продуктивное мышление нужно конкретно при изучении суммы квадратов?
Во-первых, это несправедливо по отношению к школьной математике. Там не только стопицот примеров на каждую тему, но и текстовые задачи и геометрия и какие-то нестандартные примеры, особенно задачи со звёздочкой или олимпиадные.
Во всех этих случаях нужно догадаться, какой метод решения применить, а иногда и скомбинировать несколько. Вполне продуктивное мышление, я считаю.
Во-вторых, математика всё же не очень хорошо подходит для проблемно-ориентированного обучения. Допустим, для парабол можно придумать пример с баллистой (хотя и тут у многих возникнет вопрос, зачем это в XXI веке). Но почти все проблемы в математике очень абстрактные и формулируются через другие математические проблемы. Так что с какими-нибудь топологиями групп Ли возникнут затруднения. Это, конечно, не школьная программа, а матфаковская, но you get the point.
никакой гениальности не заметил ни при прочтении в школе
«Евгений Онегин» — это книга про проблемы с общением взрослых людей, очень жизненная, кстати. Так что в школе понять в школе её довольно затруднительно: опыта нет.
Сравните с «Незнайкой на Луне» Носова… персонажей там хорошо если косвенно хотя бы сотня наберётся, сюжет относительно линейный и без каких-то мажорных параллельных линий
Это в «Незнайке на Луне»-то? По-моему, это никак не эталон линейного сюжета и небольшого количества персонажей. Скорее, наоборот, особенно по меркам детской литературы. Давно перечитывали?
Вот потому и нужна система, в которой хорошим учителям хорошо платят за обучение жаждущих учиться учеников.
Угу. Запретить любые виды частного обучения.
А зачем запрещать? Достаточно платить таким учителям хорошую зарплату. У государства, всё-таки, больше денег, чем у богатых людей, оно может себе это позволить.
Я думаю, даже если только поднять учителям зарплаты, и использовать правильные критерии оценки их работы, ситуация с образованием начнет улучшаться (профессия учителя станет более престижной, повысится конкуренция и так далее).
Да, советская система образования не спасала. И никакая массовая система образования не спасет. Но советская система давала какую-никакую базу для критического мышления
Ну да, ну да. Именно поэтому люди, учившиеся 40 лет назад, по статистике гораздо больше верят во всякую дичь, вроде теорий заговора и гомеопатии.
Пороки неприятны, когда их недостаток вы ощущаете на своей спине. Например, вот барин гуляет, а вам недоимку платить. Или, скажем, барин скопидом, а вам для него ткать. Или вот барин до девок охочий, а вы девка.
Но когда прошло двести лет, вы уже не ощущаете этих недостатков на своей спине.
Люди, которые лично ощущали эти недостатки двести лет назад, книг не читали. Эта литература писалась не для них.
Вы же не удивляетесь, что информация о компаниях с плохой репутацией особым секретом не является. Почему вдруг думаете, что с работниками другая ситуация?
Наблюдаемое принципиальное отличие в том, что репутация компании достаточно свободно лежит в интернете. А репутация работников — это какие-то закрытые черные списки которых никто своими глазами не видел.
Если честно, я не понимаю почему нет? Условно, если я живу в мире, где общество приносит в жертву 10 девственниц в год, а рядом есть мир, где принесли в жертву 10000 девственниц (желательно не своих), и теперь не приносят жертв вообще, т.к. боги порадовались и стало ну вообще хорошо.
При этом люди из соседней страны кричат «убивать девственниц нехорошо, они тоже люди». Звучит как-то странновато не находите? Да, приносить людей в жертву плохо, но если это работает
Это не работает. Никаких богов нет, и от принесения в жертву ничего не меняется. Просто люди из первого мира поняли, что напрасно положили 10000 человек и пытаются остановить хотя бы других.
Совершенно очевидно, что тесты должны быть привязаны именно к тому, к чему привязан внешний вид/поведение фронтенда. Если у вас обычная верстка по БЭМ и сырой JS типа
то любые варианты будут хуже селекторов классов. Если же, как в вашем примере, Реакт и material-ui, и вы, вообще говоря, не можете гарантировать какой DOM у вас будет на выходе, то тогда, конечно, дата-атрибуты выгядят неплохим вариантом. Только это костыль, который приходится делать за неимением лучшего.
Миллениалы изобрели процедурное программирование со всеми его недостатками.
Даже первый вопрос — «Зачем нам вообще нужны классы?» — неправильный, потому что разговор про ООП нужно начинать не с классов, а с интерфейсов. И, как ни странно, применительно к Питону, на этом же можно и заканчивать, потому что интерфейсов в чистом виде там нет, а без них ООП теряет значительную часть своей полезности. Поэтому разработчикам и остаётся писать конструкции c протоколами.
По сути, такой код:
from typing import Protocol
class ProtocolType(Protocol):
// ...
def my_func(x: ProtocolType):
это кривоватый способ написать:interface SomeType {
function my_func() {в других языках. И не надо пытаться сделать вид, что такая реализация ООП — это какое-то достоинство Питона.
мы должны понять, как же организовать наши функции. Ответ в данном случае довольно прост: использовать пространства имён. Создавайте модули, в которых вы структурируете ваши функции согласно архитектуре приложения
Только смотрите, случайно не оберните эти функции в объявление класса, а то не дай бог получится нормальное ООП. По сути, вы предлагаете то же самое ООП, только методы почему-то нужно писать вне классов. Чем это будет удобнее? Объяснения нет.
JavaScript — это ООП-язык с самого начала, просто использующий прототипное наследование, и даже оно лучше классического Java-наследования.… JavaScript никогда не нуждался в классах, которые в него добавили в 2015 году.
Это всё вообще какие-то фантазии, вы уж простите. Любой, кто поработал хотя бы немного с ООП в JS, знает, что лучше бы там были обычное ООП и наследование.
Я не увидел в статье серьёзных аргументов в пользу отказа от ООП. Настолько, что, честно говоря, даже неясно, понимает ли автор то, о чём пишет, или просто где-то слышал, что ООП это не круто, а ФП круто. Все аргументы сводятся к «оказывается, код можно как-то написать и без классов» и вырванным из контекста цитатам из авторитетов (причём, если тот же авторитет пишет что-то с чем вы не согласны, нужно обязательно добавить «ну это же было давно и неправда»). Хотелось бы статью с примерами кода, из которых было бы понятно, как лучше.
Вот собрал я свои глупые микросервисы(ввод данных, обработка, вывод) в один сияющий монолит, хорошо. Как его скейлить?
Использовать более производительный сервер, очевидно. 99% онлайн-софта никогда не встретится с проблемами масштабирования, которые бы не решались таким способом.
ради увеличения мощности одного компонента, например ввода данных, мне нужно скейлить весь монолит, оставляя обработчик данных и вывод работать вхолостую?
Это теория, а на практике обычно будет ровно одна критичная в смысле производительности подсистема, которую и нужно будет оптимизировать, а остальным можно будет пренебречь.
Так и запишем: биткоин лучше денег в фантастической ситауции, которая почти никогда не происходит.
Африка плохой пример. Там почти все страны автократии или гибридные режимы. А у более-менее демократических экономические показатели как раз выше (опять же — обычно).
С одной стороны, для программ на Прологе или функциональных языках, это не обязательно так.
С другой стороны, машина Тьюринга — это буквально математическая абстракция, состоящая из последовательно выполняющихся шагов. Да и вообще математические теории модели с дискретным временем вполне существуют.
Так что не согласен.
Сначала автор пишет:
Несколькими строчками ниже автор иронически интересуется, зачем в школе учат каким-то ненужным школьнику вещам, не для кроссвордов ли? Так для умения находить бред и учат! Как человек, выбравший направление «Литература+ Родной язык + Иностранный язык», и забивший на всё остальное, поймёт, что физик врёт? А никак, это можно сделать только сопоставив предлагаемые утверждения со своими знаниями, хотя бы школьными.
Короче, взаимоисключающие параграфы.
И вообще, если учить тому, что точно понадобится, начинать, конечо, нужно с кулинарии. Серьёзно, жаль что в моё время этому учили только девочек.
Ну тогда всем учителям придется учиться играть в Геншин (или что там сейчас популярно).
Вот серьёзно? Первоклашки должны выбирать, что им изучать? Люди, бывает, и за 30 решают сменить профессию. Сейчас они хотя бы что-то могут вспомнить из школьной программы
Кстати говоря, я, понаблюдав за тем, как люди решают задачи во время профессиональной деательности, и самообучаясь пришёл к противоположному выводу насчёт обучения только нужному. Учить (в школах, вузах и т.п.) стоит только тому, что самому человеку кажется ненужным. Потому что если что-то действительно нужно знать, у человека хватит мотивации изучить это самостоятельно. А решение проблем без кругозора быстро вырождается в запросы к Гуглу наподобие «какой стороной паяльника удобнее всего забивать в стену шурупы». Потому что ачальство поставило задачу вставить в стену шурупы, где-то сышал, что их можно забить, а сам владеет только паяльником, но очень хорошо.
Насчёт математики:
А зачем продуктивное мышление нужно конкретно при изучении суммы квадратов?
Во-первых, это несправедливо по отношению к школьной математике. Там не только стопицот примеров на каждую тему, но и текстовые задачи и геометрия и какие-то нестандартные примеры, особенно задачи со звёздочкой или олимпиадные.
Во всех этих случаях нужно догадаться, какой метод решения применить, а иногда и скомбинировать несколько. Вполне продуктивное мышление, я считаю.
Во-вторых, математика всё же не очень хорошо подходит для проблемно-ориентированного обучения. Допустим, для парабол можно придумать пример с баллистой (хотя и тут у многих возникнет вопрос, зачем это в XXI веке). Но почти все проблемы в математике очень абстрактные и формулируются через другие математические проблемы. Так что с какими-нибудь топологиями групп Ли возникнут затруднения. Это, конечно, не школьная программа, а матфаковская, но you get the point.
Если каждый человек сможет сам готовить, тогда огромная индустрия ресторанов останется без доходов. Хотя, подождите-ка…
Я думаю, даже если только поднять учителям зарплаты, и использовать правильные критерии оценки их работы, ситуация с образованием начнет улучшаться (профессия учителя станет более престижной, повысится конкуренция и так далее).
Посмотрите комедию "Изобретение лжи", там много примеров.
Совершенно очевидно, что тесты должны быть привязаны именно к тому, к чему привязан внешний вид/поведение фронтенда. Если у вас обычная верстка по БЭМ и сырой JS типа
то любые варианты будут хуже селекторов классов. Если же, как в вашем примере, Реакт и material-ui, и вы, вообще говоря, не можете гарантировать какой DOM у вас будет на выходе, то тогда, конечно, дата-атрибуты выгядят неплохим вариантом. Только это костыль, который приходится делать за неимением лучшего.
Citation needed
Даже первый вопрос — «Зачем нам вообще нужны классы?» — неправильный, потому что разговор про ООП нужно начинать не с классов, а с интерфейсов. И, как ни странно, применительно к Питону, на этом же можно и заканчивать, потому что интерфейсов в чистом виде там нет, а без них ООП теряет значительную часть своей полезности. Поэтому разработчикам и остаётся писать конструкции c протоколами.
По сути, такой код:это кривоватый способ написать:
interface SomeType {
в других языках. И не надо пытаться сделать вид, что такая реализация ООП — это какое-то достоинство Питона.function my_func() {
Только смотрите, случайно не оберните эти функции в объявление класса, а то не дай бог получится нормальное ООП. По сути, вы предлагаете то же самое ООП, только методы почему-то нужно писать вне классов. Чем это будет удобнее? Объяснения нет.
Это всё вообще какие-то фантазии, вы уж простите. Любой, кто поработал хотя бы немного с ООП в JS, знает, что лучше бы там были обычное ООП и наследование.
Я не увидел в статье серьёзных аргументов в пользу отказа от ООП. Настолько, что, честно говоря, даже неясно, понимает ли автор то, о чём пишет, или просто где-то слышал, что ООП это не круто, а ФП круто. Все аргументы сводятся к «оказывается, код можно как-то написать и без классов» и вырванным из контекста цитатам из авторитетов (причём, если тот же авторитет пишет что-то с чем вы не согласны, нужно обязательно добавить «ну это же было давно и неправда»). Хотелось бы статью с примерами кода, из которых было бы понятно, как лучше.
Использовать более производительный сервер, очевидно. 99% онлайн-софта никогда не встретится с проблемами масштабирования, которые бы не решались таким способом.
Это теория, а на практике обычно будет ровно одна критичная в смысле производительности подсистема, которую и нужно будет оптимизировать, а остальным можно будет пренебречь.