Я считаю, что язык С++ и вся его философия находятся в прямом конфликте с требованиями функционального программирования.
Насколько я понимаю (помню Страуструпа), философия С++ заключается в том, чтобы позволять выбирать лучшие абстракции для каждой конкнретной предметной области. Для многопоточности да, сишные структуры и указатели на них — не лучший выбор. Но в прицнипе никто не мешает, а некоторые даже рекомендуют, при программировании многопоточных вещей использовать неизменяемые данные, копировать их вместо перемещения или передачи ссылки и избавлять функции от сторонних эффектов, насколько это возможно. В тексте справедливо замечено, что по умолчанию это не гарантируется, но философия С++ как раз в том и состоит, чтобы навязывать программисту как можно меньше умолчаний. Стрелять себе в ногу — это почетное право, а не обязанность.
Конечно, идея смотреть на функциональные языки в контексте многопоточности — здравая. Могу подтвердить, правда, не Хаскеллем, а Эрлангом — после полугода программирования исключительно на нем, код на плюсах тоже стал намного более функциональнообразным со всеми приятными бонусами в виде потокобезопасности и читаемости.
Но ведь и объектная парадигма возникла не на пустом месте. Да и императивный код с циклами тоже может быть весьма полезным, особенно там, где побочные эффекты неизбежны и порядок вычисления критически важен. С++ позволяет не только порождать сложноотлаживаемые ошибки в промышленном количестве, но и работу работать, как ни странно, причем на всех уровнях. От функциональных блоков на контроллерах нижнего уровня на АЭС, до казуальных квестов под айпад с андройдом, причем одновременно.
При этом С++ движется и в сторону параллельного программирования, хотя и не всегда так здорово, как хотелось бы. PPL и AMP, например, как раз и предназначены для задействования многоядерных платформ и GPU. Все мы там будем. Хотя и не сразу. Хотя, наверное, и не все.
Насколько я помню, в немецком наборе знаки препинания тоже отбиваются, но тонкой шпацией (один пункт что ли, не вспомню). Во французском используются более широкие, более заметные шпации, поэтому, наверное, и в компьютерный набор попал пробел перед знаком.
Столкнулся с этим пару лет назад, когда прислали французский текст для локализации, а там вот оказался как раз такой неразрывный пробел, который ломал отрисовку шрифтов. Начал разбираться, чтобы в дальнейшем ничего не ломалось, оказалось, что в типографике все очень нетривиально. По-моему, даже в русском допустимо отбивать знаки на полукругулую. Но в компьютере никто такого к счастью не требует. Кроме французов.
Поделили размер указателя на размер структуры и получили 0. Что вообще здесь хотели сделать?
Найти количество элементов в массиве судя по всему. Кстати, распространенная ошибка. Еще бывает sizeof(Something*123) или даже sizeof(SOME_CONST). Почему-то sizeof часто понимают неправильно, а он и не возражает конечно же.
Насчет типов, зависит от языка и фронтенда самой базы. Если есть нормальная интроспекция, хватит одних бинарных. LevelDB (младший брат BigTable) как раз только бинарные ключи-значения и обслуживает. Но, например, Riak поверх нее уже сам приводит все в кортежи строк, чисел, списков и т. п.
Ну и денормализация — это тоже личный выбор архитектора. В реляционных базах тоже можно нахамить, чтобы летало.
Есть еще один подвох. No SQL создает ложное впечатление, что можно не знать SQL. Все просто же: положить/достать. Большая консистентная мапа, ура! А на самом деле, если не язык запросов, то уж правила Кодда знать как раз обязательно. Они не на пустом месте появились, мы можем делать вид, что работаем с произвольными кортежами, но в большинстве случаев данные представляют собой все те же таблицы и отношения между ними. Больше чем теоретики реляционных баз про это все не думал никто.
Питон для математика — это Sage. И еще куча мелких модулей на все случаи жизни. Питон нужен просто как удобный язык для того, чтобы связывать все вместе. Это даже не дубина, а клей для дубины. Поэтому заморачиваться типами должен не математик, а разработчик модуля.
Строки — больное место везде. В Джаве они еще реализованы более-менее удачно. Оператор == проверяет ссылки, равно как и для любого другого объекта любого класса, а для проверки содержимого строк есть специальный метод. Можно один раз запомнить и потом не спотыкаться. Похоже сделано и в Objective C, не помню, чтобы у кого-то были с этим серьезные проблемы.
В шарпе такой же Equals, но оператор == переопределен. Как по мне, это костыль. В итоге нормальный ссылочный тип ведет себя как значение и ломает мозг программистам. Я уверен, если сейчас опросить у тысячи шарпистов, является ли строка значимым типом, половина ответит «да».
В плюсах строки — это вообще все и ничто одновременно. Десяток разных реализаций я точно видел. Далеко не все перегружают оператор ==, но стандартные, например, таки да. Но это, опять же, порождает класс проблем. Потому что null-terminated строчки со стандартной библиотекой Си никто тоже не отменял, а головы у программистов не сменные. Постоянно кто-то пытается складывать одно с другим в неправильном порядке, прибавлять чар к литералу или гонять строчки туда-сюда через c_str там, где это вовсе не нужно. К вопросу о строгости, компилятор это все жует не отрыгивая. Спасает только CppCheck.
Питон такие проблемы обходит просто. Он их не порождает. Я не могу иметь неинициализированную переменную, потому что не могу декларировать переменную без инициализации. Строки — отдельный примитив языка, не объект как в Джаве и не список, как в Эрланге, поэтому они вполне могут сравниваться по ==. Переполнить массив невозможно, потому что вместо массивов списки. Сломать счетчик в цикле — потому что цикл проходит по неизменяемому ленивому ренджу. И так далее, и тому подобное.
На Хабре когда-то была статься, кстати вот она habrahabr.ru/post/111707/, про то, как работает мозг. Она не явно, но весьма отчетливо защищает антропоморфизм в информационных системах.
Думать в рамках людей и сообщений удобно. Тем более это решает массу проблем с синхронизацией процессов. Если каждый процесс, ну или «воркер», «актер», общается с остальными только через асинхронную очередь, никаких дедлоков или спинлоков не будет же. Там есть, правда, подвох. Персистентные хранилища, например, когда их надо использовать несколькими процессами. Но это обходится, например, введением отдельного воркера, который обслуживает именно хранилища и отдает данные по запросу «коллег».И отдельного супервизора, который следит, например, чтобы тот воркер не помер. В итоге получается система, которая отлично масштабируется и обеспечивает самонадежность.
Но это в первую очередь хорошая модель для головы, не только для железа. Изолированные процессы, которые ведут себя как люди, но при этом не капризничают, не срутся друг с другом и не уходят к конкуренту через полгода — отлично же. Главное, не начать с ними разговаривать.
Вообще-то в Питоне строгая типизация. Но динамическая, да, в том плане, что имя байндится к значению без аннотации типа. При этом Питон обеспечивает полную интроспекцию, то есть инварианты типа можно, если нужно, проверять явно.
Если лезть в образование, то там клубок причин еще больший. Еще более пугающий. Легко сказать, «средняя школа должна». А кто пойдет в среднюю школу учить грамотности? Вот даже если мы с вами сейчас соберемся и пойдем в школу вместо того, чтобы клавиатуры чесать, в России примерно пятьдесят тысяч школ, — мы до пятницы точно не управимся, а на субботу у меня планы.
В высшем образовании чуть проще. Я даже поработал несколько лет на четверть ставки, — вполне себе годное хобби, пока основная работа позволяет. Но если уйти в академию с головой, придется забыть о карьере. А это дважды нехорошо: во-первых, зарплаты преподавателя не хватает на шлюх и кокаин, во-вторых, без связи с индустрией придется постепенно превратиться в физика и начать писать на Фортране.
Тут сразу много причин и следствий в одном клубке. Попробуем разобраться.
Физикам не нужно оружие, физикам нужна дубина для охоты на зайцев. Удобная, неломающаяся дубина. Ок, они действительно лучше знают, что им нужно, чем все программисты вместе взятые.
Физики используют Фортран. Ну, Фортран — не самая плохая дубина. Есть лучше, конечно, но обычно новую дубину приносят новые люди. А новые люди не хотят идти туда где Фортран. Замкнутый цикл.
Физики используют С++ — вот это проблема. Но проблема-то надуманная. Заберите С++, верните Фортран — профит! Или не Фортран, а Питон, Лисп, R на худой конец. Маткад опять же.
Программисты используют С++ — это да, беда. Но беда иллюзорная. На самом деле ведь программисты не используют С++. В лучшем случае — безопасное подмножество (MISRA, HICPP), в худшем случае — опасное подмножество (Си с этим, как его, клястером). Иногда мне кажется, что С++ целиком использует в целом мире один Александреску, поэтому у него такой задумчиво-печалный вид на каждой конференции.
Программисты вроде как используют С++, но С++ против такого использования. Вот это действительно проблема, и ее можно решить. Статический анализ помогает. Кроме шуток, это очень полезная, хотя и недооцененная часть рабочего процесса. На самом деле, не обязательно даже покупать PVS, чтобы приобщиться к хорошему, достаточно сказать компилятору, к примеру, "-Wall -Wextra -pedantic -Weffc++" и перестать смотреть на него, как на телевизор. Все, что говорит компилятор, надо читать осмысленно — это наш первый и главнейший союзник в борьбе со злом.
Потом можно попробовать и другие анализаторы, почему нет. Анализ делает за меня самую скучную и нервную работу, делает ее быстро, надежно и не просится в отпуск. Как можно не любить статический анализ? Но одного анализа недостаточно. Надо еще учиться писать код, да. Учиться надо много, упорно и постоянно. Пользуясь случаем, хочу напомнить, что новый стандарт С++11 сказочно хорош, и все мы там будем, так что кто еще не ознакомился — самое время.
Еще надо уважать общепринятые стандарты программирования. Или хотя бы принять свой собственный стандарт и уважать его лично. Причем, не просто скобки / табы / с большой буквы, а нормальный такой стандарт уровня JSF AV C++.
Но это все касается программистов. А физикам просто нужен калькулятор побольше. Это не проблема, это задача для тех, кто такие калькулторы разрабатывает.
В ленинке не знаю, в библиотеке киевского политеха на смартфон реагируют нормально. Правда, могло что-то и поменяться за пару лет. Другое дело, что снимки на смартфон получаются довольно убогие.
Я сейчас пописываю на досуге программку для обработки снимков страниц. В идеале хочется как раз чтобы можно было пролистать книгу перед камерой — и получить электронную книжку в чем-то вроде дежавю. Формулы, чертежи, графики чтобы были, а не просто текст. Но это пока перспектива дальняя, с моими темпами тут хотя бы постраничную обработку за вменяемое время закончить.
В плане планирования не все так страшно на самом деле. Что должны учить, а точнее какие знания должны быть на входе и какие на выходе, определяется паспортом дисциплины. В рамках собственно плана обычно определенная свобода все же имеется. Я давал СКВ в рамках технологий создания программного обеспечения, например. Взял и вписал в план.
Странно, что утверждения упоминаются в открывающей цитате, но не в тексте. В шарпе утверждения, конечно, не самые красивые, но есть. Едва ли имеет смысл использовать if и throw, там где можно обойтись Assert. Собственно, они для сохранения инвариантов и нужны.
Программисту и должно быть насрать на клиента. Это неотъемлимая и наиболее приятная часть профессии. Существует негласное, но очевидное разделение: управленцам насрать на код, программистам насрать на клиента. При таком балансе каждый может заниматься своим и только своим делом и преуспевать в нем.
Но идея забирать тех, кому нечего сказать о паттернах, в управленцы — отличная! И есть кому о клиенте подумать, и сообщество чистится.
Программист, научный работник. За компьютерами около двадцати лет, с самого детства больше чем на полтора месяца от монитора не отходил.
Я бы открыл кафе с вегетарианской едой. Так, чтобы сразу и халяль, и кашрут, и ЗОЖ. Без алкоголя, но с отдельным балконом для курения. Не то что бы тут такой уж большой спрос, но ведь предложения-то вообще нет, так что, думаю, это был бы успех.
На самом деле, я не то что бы любитель вегетарианской еды. Скорее даже не любитель. Терпеть не могу тофу и соевые эти заменители. Ненавижу практически. С другой стороны, после двадцати лет программирования, я и людей-то не очень люблю. Так что в принципе оно раз на раз и выходит.
Зависит от. По большому счету, хорошее фундаментальное исследование делается не для живых людей, а для еще не рожденных. Но я имел в виду, что за пределами исследовательской деятельности тоже есть куда приложить мозг, и в изобилии. Поэтому и расставил коннотации таким образом.
Насколько я понимаю (помню Страуструпа), философия С++ заключается в том, чтобы позволять выбирать лучшие абстракции для каждой конкнретной предметной области. Для многопоточности да, сишные структуры и указатели на них — не лучший выбор. Но в прицнипе никто не мешает, а некоторые даже рекомендуют, при программировании многопоточных вещей использовать неизменяемые данные, копировать их вместо перемещения или передачи ссылки и избавлять функции от сторонних эффектов, насколько это возможно. В тексте справедливо замечено, что по умолчанию это не гарантируется, но философия С++ как раз в том и состоит, чтобы навязывать программисту как можно меньше умолчаний. Стрелять себе в ногу — это почетное право, а не обязанность.
Конечно, идея смотреть на функциональные языки в контексте многопоточности — здравая. Могу подтвердить, правда, не Хаскеллем, а Эрлангом — после полугода программирования исключительно на нем, код на плюсах тоже стал намного более функциональнообразным со всеми приятными бонусами в виде потокобезопасности и читаемости.
Но ведь и объектная парадигма возникла не на пустом месте. Да и императивный код с циклами тоже может быть весьма полезным, особенно там, где побочные эффекты неизбежны и порядок вычисления критически важен. С++ позволяет не только порождать сложноотлаживаемые ошибки в промышленном количестве, но и работу работать, как ни странно, причем на всех уровнях. От функциональных блоков на контроллерах нижнего уровня на АЭС, до казуальных квестов под айпад с андройдом, причем одновременно.
При этом С++ движется и в сторону параллельного программирования, хотя и не всегда так здорово, как хотелось бы. PPL и AMP, например, как раз и предназначены для задействования многоядерных платформ и GPU. Все мы там будем. Хотя и не сразу. Хотя, наверное, и не все.
Столкнулся с этим пару лет назад, когда прислали французский текст для локализации, а там вот оказался как раз такой неразрывный пробел, который ломал отрисовку шрифтов. Начал разбираться, чтобы в дальнейшем ничего не ломалось, оказалось, что в типографике все очень нетривиально. По-моему, даже в русском допустимо отбивать знаки на полукругулую. Но в компьютере никто такого к счастью не требует. Кроме французов.
Найти количество элементов в массиве судя по всему. Кстати, распространенная ошибка. Еще бывает
sizeof(Something*123)или дажеsizeof(SOME_CONST). Почему-то sizeof часто понимают неправильно, а он и не возражает конечно же.Ну и денормализация — это тоже личный выбор архитектора. В реляционных базах тоже можно нахамить, чтобы летало.
Есть еще один подвох. No SQL создает ложное впечатление, что можно не знать SQL. Все просто же: положить/достать. Большая консистентная мапа, ура! А на самом деле, если не язык запросов, то уж правила Кодда знать как раз обязательно. Они не на пустом месте появились, мы можем делать вид, что работаем с произвольными кортежами, но в большинстве случаев данные представляют собой все те же таблицы и отношения между ними. Больше чем теоретики реляционных баз про это все не думал никто.
Строки — больное место везде. В Джаве они еще реализованы более-менее удачно. Оператор == проверяет ссылки, равно как и для любого другого объекта любого класса, а для проверки содержимого строк есть специальный метод. Можно один раз запомнить и потом не спотыкаться. Похоже сделано и в Objective C, не помню, чтобы у кого-то были с этим серьезные проблемы.
В шарпе такой же Equals, но оператор == переопределен. Как по мне, это костыль. В итоге нормальный ссылочный тип ведет себя как значение и ломает мозг программистам. Я уверен, если сейчас опросить у тысячи шарпистов, является ли строка значимым типом, половина ответит «да».
В плюсах строки — это вообще все и ничто одновременно. Десяток разных реализаций я точно видел. Далеко не все перегружают оператор ==, но стандартные, например, таки да. Но это, опять же, порождает класс проблем. Потому что null-terminated строчки со стандартной библиотекой Си никто тоже не отменял, а головы у программистов не сменные. Постоянно кто-то пытается складывать одно с другим в неправильном порядке, прибавлять чар к литералу или гонять строчки туда-сюда через c_str там, где это вовсе не нужно. К вопросу о строгости, компилятор это все жует не отрыгивая. Спасает только CppCheck.
Питон такие проблемы обходит просто. Он их не порождает. Я не могу иметь неинициализированную переменную, потому что не могу декларировать переменную без инициализации. Строки — отдельный примитив языка, не объект как в Джаве и не список, как в Эрланге, поэтому они вполне могут сравниваться по ==. Переполнить массив невозможно, потому что вместо массивов списки. Сломать счетчик в цикле — потому что цикл проходит по неизменяемому ленивому ренджу. И так далее, и тому подобное.
На Хабре когда-то была статься, кстати вот она habrahabr.ru/post/111707/, про то, как работает мозг. Она не явно, но весьма отчетливо защищает антропоморфизм в информационных системах.
Думать в рамках людей и сообщений удобно. Тем более это решает массу проблем с синхронизацией процессов. Если каждый процесс, ну или «воркер», «актер», общается с остальными только через асинхронную очередь, никаких дедлоков или спинлоков не будет же. Там есть, правда, подвох. Персистентные хранилища, например, когда их надо использовать несколькими процессами. Но это обходится, например, введением отдельного воркера, который обслуживает именно хранилища и отдает данные по запросу «коллег».И отдельного супервизора, который следит, например, чтобы тот воркер не помер. В итоге получается система, которая отлично масштабируется и обеспечивает самонадежность.
Но это в первую очередь хорошая модель для головы, не только для железа. Изолированные процессы, которые ведут себя как люди, но при этом не капризничают, не срутся друг с другом и не уходят к конкуренту через полгода — отлично же. Главное, не начать с ними разговаривать.
В высшем образовании чуть проще. Я даже поработал несколько лет на четверть ставки, — вполне себе годное хобби, пока основная работа позволяет. Но если уйти в академию с головой, придется забыть о карьере. А это дважды нехорошо: во-первых, зарплаты преподавателя не хватает на шлюх и кокаин, во-вторых, без связи с индустрией придется постепенно превратиться в физика и начать писать на Фортране.
Физикам не нужно оружие, физикам нужна дубина для охоты на зайцев. Удобная, неломающаяся дубина. Ок, они действительно лучше знают, что им нужно, чем все программисты вместе взятые.
Физики используют Фортран. Ну, Фортран — не самая плохая дубина. Есть лучше, конечно, но обычно новую дубину приносят новые люди. А новые люди не хотят идти туда где Фортран. Замкнутый цикл.
Физики используют С++ — вот это проблема. Но проблема-то надуманная. Заберите С++, верните Фортран — профит! Или не Фортран, а Питон, Лисп, R на худой конец. Маткад опять же.
Программисты используют С++ — это да, беда. Но беда иллюзорная. На самом деле ведь программисты не используют С++. В лучшем случае — безопасное подмножество (MISRA, HICPP), в худшем случае — опасное подмножество (Си с этим, как его, клястером). Иногда мне кажется, что С++ целиком использует в целом мире один Александреску, поэтому у него такой задумчиво-печалный вид на каждой конференции.
Программисты вроде как используют С++, но С++ против такого использования. Вот это действительно проблема, и ее можно решить. Статический анализ помогает. Кроме шуток, это очень полезная, хотя и недооцененная часть рабочего процесса. На самом деле, не обязательно даже покупать PVS, чтобы приобщиться к хорошему, достаточно сказать компилятору, к примеру, "-Wall -Wextra -pedantic -Weffc++" и перестать смотреть на него, как на телевизор. Все, что говорит компилятор, надо читать осмысленно — это наш первый и главнейший союзник в борьбе со злом.
Потом можно попробовать и другие анализаторы, почему нет. Анализ делает за меня самую скучную и нервную работу, делает ее быстро, надежно и не просится в отпуск. Как можно не любить статический анализ? Но одного анализа недостаточно. Надо еще учиться писать код, да. Учиться надо много, упорно и постоянно. Пользуясь случаем, хочу напомнить, что новый стандарт С++11 сказочно хорош, и все мы там будем, так что кто еще не ознакомился — самое время.
Еще надо уважать общепринятые стандарты программирования. Или хотя бы принять свой собственный стандарт и уважать его лично. Причем, не просто скобки / табы / с большой буквы, а нормальный такой стандарт уровня JSF AV C++.
Но это все касается программистов. А физикам просто нужен калькулятор побольше. Это не проблема, это задача для тех, кто такие калькулторы разрабатывает.
Я к тому, что даже при разрешенных смартфонах проблема остается. Сканировать все-таки надо по-человечески, а не на камеру с рук.
Везде свои порядки, конечно.
Я сейчас пописываю на досуге программку для обработки снимков страниц. В идеале хочется как раз чтобы можно было пролистать книгу перед камерой — и получить электронную книжку в чем-то вроде дежавю. Формулы, чертежи, графики чтобы были, а не просто текст. Но это пока перспектива дальняя, с моими темпами тут хотя бы постраничную обработку за вменяемое время закончить.
Но идея забирать тех, кому нечего сказать о паттернах, в управленцы — отличная! И есть кому о клиенте подумать, и сообщество чистится.
Я бы открыл кафе с вегетарианской едой. Так, чтобы сразу и халяль, и кашрут, и ЗОЖ. Без алкоголя, но с отдельным балконом для курения. Не то что бы тут такой уж большой спрос, но ведь предложения-то вообще нет, так что, думаю, это был бы успех.
На самом деле, я не то что бы любитель вегетарианской еды. Скорее даже не любитель. Терпеть не могу тофу и соевые эти заменители. Ненавижу практически. С другой стороны, после двадцати лет программирования, я и людей-то не очень люблю. Так что в принципе оно раз на раз и выходит.