Это Lisp. По факту самый простой синтаксис для освоения. Но зашоренность сознания привычным С-like синтаксисом может мешать восприятию, это да.
К тому же Вы ж сами писали, что получать результат быстро — это круто.
Тут в 5 строках алгоритм отрисовки треугольника Серпинского. А фракталы — это интересно и весело. Теперь прикиньте сколько кода писать на JS пришлось бы для того же результата :-D
Я не могу назвать «кашей» мультипарадигмальный язык.
Смотрите в чём фишка: мультипарадигмальный язык не позволяет вам по факту использовать ни одну парадигму в чистом виде. Для обучения — это, на мой взгляд, самое ужасное. У школьника ещё не выкристаллизовалось понимание концепции, а его заставляют её применять на языке, который эту концепцию не поддерживает даже на 80%.
Для промышленного применения это катит, т.к. можно применять фичи какой-то концепции даже не понимая её… такой "херак-херак и в продакшн". Но тут надо понимать какой вы хотите результат — заложить основу для становления кодеров за еду, в стиле Индии и Китая, или основу для становления профессиональных программистов.
Если есть возможность давать более востребованные знания новым поколениям…
Так я и предлагаю давать более востребованные знания, а не плодить кодеров-индусов из русских )))
Да что тут считать. Берём статистику по языкам на гитхабе и всё видно
Вы делаете прогноз на 10 лет, просто по текущему кол-ву открытых репозиториев на github? Ваше право, конечно, но имхо слабоватая метрика для прогнозов.
JavaScript сейчас колбасит только так. Учить его сейчас, чтобы найти работу в 2017 году — можно. С горизонтом 10 лет — бессмысленно.
А более удобных синтаксисов и так уже навалом.
Это невероятно важно как для меня лично, так и для всего сообщества Эликсира в целом.
Я так понимаю, wunsh.ru — это Ваш личный проект… Почему Вы от лица всего сообщества Эликсира второй раз вещаете? Переводите себе спокойно статьи, к чему эти понты?
То есть — «всё как в жизни». Типа того. А ещё есть иерархия объектов по наследованию — опять таки — как в жизни.
Ага, именно "типа того". А по факту ничего общего с тем, как в жизни :-)
Да ещё и у каждого своё инстинктивное понимание. Некоторые вообще взаимоисключающие. Впрочем не будем про ООП, на Хабре уже есть много холиваров на эту тему, из которых понятно, что ничего не понятно и общепринятых определений нет :-)
Я всегда считал (читал) что «функция высшего порядка» — это «функция возвращающая функцию».
Там 2 критерия в определении:
принимает одну или более функций в качестве аргумента
возвращает функцию в качестве результата
Любого из этих критериев достаточно, чтобы функцию назвать функцией высшего порядка.
Это уж слишком «низкий» подход у вас.
Да нет, просто идеи ФП заимствуют для императивных мейнстрим-языков и они уже не совсем императивные. Те же ФВП теперь где только не встретишь..
1) Получим объект(!) типа Массив элементов.
2) Определим, есть ли «наш элемент» в данном объекте вызвав («дёрнув») метод этого объекта.
Ну если уж про ООП, то надо ещё про паттерн Iterator добавить. А то Вы подменяете реализацию алгоритма на её использование. А использование вообще не сильно отличается:
Если посмотреть на то, что человек, который явно понимает ФП, написал статью, но судя по коментам — не совсем правильно понимает базовые понятия ФП, то становится понятно что функциональное программирование — довольно «путанная штука».
Swift и уж тем более C — не являются функциональным ЯП. Haskell автор не знает на достаточном уровне. Я его и сам не знаю толком, но в статье совсем уж детские грабли в Haskell-коде.
Что до путанности, посмотрите статьи про ООП и вообще офигеете. Абсолютно ни у кого нет чёткого понимания, что входит в это понятие, а что нет. И по каждому ассоциированному термину влёгкую можно начать холивар. ФП в этом плане отлично формализовано, что конечно не страхует от того, что кто-то может что-то напутать. Человеческий фактор не отменить, зато всегда можно глянуть точное определение.
1) Получим массив элементов.
2) Определим, есть ли «наш элемент» в данном массиве?
Это тоже функциональный подход.
Императивный подход:
1) Получим указатель на массив элементов и целевой элемент
2) Определим длину массива
3) В цикле от 0 до длина-1 будем сравнивать i-ый элемент массива с целевым.
4) Если элемент совпал, то return true
5) return false
Это просто вещественная переменная нужной точности.
Поясните… Вероятность — это не просто вещественная переменная. Допустим для 0.5 она означает, что обе ветки и if и else исполняются равновероятно. Булева же логика может исполнить только одну ветку.
Обычно вероятность пытаются эмулировать через random, но это ничего общего с человеческой логикой. Её эмулируют нейросети, но пока на очень-очень базовом уровне.
Понимаете, тут много стереотипов… Я тоже буквально полгода назад думал, что Smalltalk устарел… А посмотрел на Pharo и охренел от возможностей среды разработки… IDE для Java и Python выглядят против неё как Gimp vs Photoshop :-)
Haskell с относительно недавнего времени стремительно набирает популярность. TIOBE его хэдлайнером ноября обозвали xD
Racket — это современный диалект Scheme, который в свою очередь используется в классической книге по Computer Science — «Structure and Interpretation of Computer Programs». Плюс на нём идет довольно крутая движуха разнообразных DSL, что весьма интересно, особенно при обучении.
И выбор прост: брать что-то промышленное на данный момент (пусть оно и изменится через 5 лет) или брать то, что массово не востребовано в ромышленности?
Хм, откуда взялся такой критерий? По-моему выбор: брать то, на чём удобно демонстрировать чистые концепции, или то, где куча разнородных концепций перемешаны в дикую кашу. Вы за какой пункт из этих двух?
Вообще-то, дистанционные формы образования всё популярнее.
Есть обучение, а есть самообучение… Почитать вики — это про самообучение. В целом оно даже эффективнее, так как движется интересом, но без соответствующих навыков или менторства может быть слишком сложно.
А насчёт меня — я что, должен был Вам скопипастить оттуда сюда, чтобы показать, что я умею найти нужную мне в каждый момент времени информацию? :) самому не смешно?
Да нет, конечно. Вопросы вообще были для примера… Просто некоторые ответы неправильные, некоторые неточные. Если Вам интересно восполнить этот пробел в знаниях, рекомендую книжку «Семь моделей конкуренции и параллелизма». В комментариях на мой взгляд не лучшее место расписывать, т.к. правильные ответы с пояснениями потянут на отдельную статью.
И именно это знание, знание теории управления, принадлежит к числу нетленных, не устаревающих со временем, что мегаважно в наш век перемен.
Ладно, надо будет глянуть «Закон Времени», раз рекомендуете. А то всё равно пока слишком размыто выглядит.
Ну и пусть раз в 5 лет мейнстрим меняется — ну так обновлять программу обучения всё равно нужно.
Ахах, Вы слишком хорошего мнения о минобре, новую программу лет 5 только согласовывать будут.
Да и потом, с чего Вы взяли, что предложенные языки неадекватны?.. за исключением Паскаля, остальные вполне себе используются в production, хоть и во втором эшелоне по популярности, а С так вообще — в первом, просто он уже достаточно стабилен, чтобы не дёргаться каждый год в новые фичи.
P.S. Если отвлечься от школы и переключиться на действующих программистов… Перечислите, если не трудно, список языков, которые Вы считаете перспективными с горизонтом 10 лет?
Неужели нельзя на чём-то реально и массово востребованном на рынке нельзя объяснять?
Учить надо на том, что проще понять.
Конкуренция со стороны Java и Python-программистов мне параллельна, пусть поддерживают legacy хоть ещё 100 лет )))
Я вижу, что они уже неактуальны для многих новых проектов, поэтому для меня эти 2 языка выглядят как захламлённый Паскаль :-)
Если цель обучать под JVM, то любой из Kotlin, Scala, Clojure будет лучше Java.
А Python по моему прогнозу лет через 5 останется только как инструмент для сисадминов… всякие сценарии автоматизировать. Конечно, я могу ошибаться, но это мы узнаем только в 2021 году :-)
Ну а лет через 10 актуальными будут только те языки, которые позволят эффективно использовать сотни ядер и квантовые компьютеры, т.е. чисто декларативные. Все мои рекомендации исходят из этого убеждения.
Мне вот кажется, что попытка решить самостоятельно «до» может дать нехилое понимание не только того, что мы используем, но и ответить на извечные вопросы «зачем» и «почему».
Да, это так. Но всё-таки это надо как-то дозировать в образовательном процессе… ведь одна из его целей — в сокращении количества набитых шишек.
Потому то и нужно быть человеком, а не роботом, чётко исполняющим любые инструкции
Анекдоты показывают как раз чёткую логику. Как записан алгоритм, так и исполнять. Компьютер так и делает (за редким исключением), человек так не делает почти никогда.
«Может быть» == вероятность самореализации строго больше нуля.
«да нет, наверное» == вероятность самореализации строго меньше 0,5
Изучать Паскаль, чтобы на нем продемонстрировать работу циклов?
Вы передёргиваете… Структурное программирование не ограничивается циклами. Какие ещё языки Вы бы выбрали для демонстрации именно этой концепции в чистом виде?
В образовательных целях предпочел бы какой-нибудь другой ORM.
Вот Вы считаете, что LINQ — это ORM и вендорозависимое решение. А по факту, это не ORM и такой же подход можно реализовать во многих языках, где есть ФВП.
Мне вот кажется логичной мысль не завязывать образовательный процесс на проприетарное относительно дорогое решение
Ну что Вы привязались к Паскалю, он ведь 1 из списка, образовательный процесс на него не будет завязан, он будет его синтаксис использовать для демонстрации структурного программирования. Я уж молчу про то, что LCL — это OpenSource (Lazarus).
Вы же чуть выше говорили, что изучать нужно сами основы, а не конкретный продукт конкретной конторы, который неизвестно еще, будет ли жив через пару-тройку пятилеток.
Правильно. В школе и не нужно изучать ASP.NET MVC и т.п. Это был ответ на Ваш вопрос по поводу внеклассной программы для тех, кто очень увлёкся программированием. И смысл в том, что они найдут чем заняться вне школы для любого ЯП.
К стыду своему признаю, что тут я вообще не авторитет.
Так это не стыдно. Их слабая известность — это недостаток текущей системы образования. Поизучайте их на досуге и поймёте почему те, кто уже ознакомился, хотели бы чтобы этим концепциям учили сразу… вместо того, чтобы пробиваться к ним годами через пот и слёзы промышленного программирования.
А Python, Go? Не сложнее паскаля и бейсика, имхо.
Python гораздо сложнее, как любой мультипарадигмальный язык. Go — на мой взгляд не простой, а урезанный… Чуть в сторону и уже приходится извращаться.
Было бы довольно внезапно, неск лет в школе изучая специальные какие-то языки, выйдя во взрослую жизнь, обнаружить, что они в принципе никому не нужны…
Так именно поэтому и не надо учить в школе Java/Python… Они подвержены моде, как любой мейнстрим.
Концепции по большей части моде не подвержены, поэтому всё что останется для перехода к production — это изучить синтаксис модного к тому моменту языка. Что как мы знаем занимает 2-3 недели, включая основную часть стандартной библиотеки.
А теперь подумайте сколько лет понадобится чтобы переключиться на что-то типа Haskell после 10 лет изучения Java.
Можно добавить, что большинство банков требует от ИП декларацию за 2 предыдущих отчётных периода, т.е. за предыдущие 2 года. Поэтому если Вы зарегистрировались недавно, то с ипотекой всё ещё сложнее.
Это Lisp. По факту самый простой синтаксис для освоения. Но зашоренность сознания привычным С-like синтаксисом может мешать восприятию, это да.
К тому же Вы ж сами писали, что получать результат быстро — это круто.
Тут в 5 строках алгоритм отрисовки треугольника Серпинского. А фракталы — это интересно и весело. Теперь прикиньте сколько кода писать на JS пришлось бы для того же результата :-D
Смотрите в чём фишка: мультипарадигмальный язык не позволяет вам по факту использовать ни одну парадигму в чистом виде. Для обучения — это, на мой взгляд, самое ужасное. У школьника ещё не выкристаллизовалось понимание концепции, а его заставляют её применять на языке, который эту концепцию не поддерживает даже на 80%.
Для промышленного применения это катит, т.к. можно применять фичи какой-то концепции даже не понимая её… такой "херак-херак и в продакшн". Но тут надо понимать какой вы хотите результат — заложить основу для становления кодеров за еду, в стиле Индии и Китая, или основу для становления профессиональных программистов.
Так я и предлагаю давать более востребованные знания, а не плодить кодеров-индусов из русских )))
Вы делаете прогноз на 10 лет, просто по текущему кол-ву открытых репозиториев на github? Ваше право, конечно, но имхо слабоватая метрика для прогнозов.
JavaScript сейчас колбасит только так. Учить его сейчас, чтобы найти работу в 2017 году — можно. С горизонтом 10 лет — бессмысленно.
А более удобных синтаксисов и так уже навалом.
Я так понимаю, wunsh.ru — это Ваш личный проект… Почему Вы от лица всего сообщества Эликсира второй раз вещаете? Переводите себе спокойно статьи, к чему эти понты?
Ага, именно "типа того". А по факту ничего общего с тем, как в жизни :-)
Да ещё и у каждого своё инстинктивное понимание. Некоторые вообще взаимоисключающие. Впрочем не будем про ООП, на Хабре уже есть много холиваров на эту тему, из которых понятно, что ничего не понятно и общепринятых определений нет :-)
Там 2 критерия в определении:
Любого из этих критериев достаточно, чтобы функцию назвать функцией высшего порядка.
Да нет, просто идеи ФП заимствуют для императивных мейнстрим-языков и они уже не совсем императивные. Те же ФВП теперь где только не встретишь..
Ну если уж про ООП, то надо ещё про паттерн Iterator добавить. А то Вы подменяете реализацию алгоритма на её использование. А использование вообще не сильно отличается:
Процедурный стиль:
in_array(arr, obj)ООП:
arr.include?(obj)ФП:
Enum.member?(arr, obj)Что до путанности, посмотрите статьи про ООП и вообще офигеете. Абсолютно ни у кого нет чёткого понимания, что входит в это понятие, а что нет. И по каждому ассоциированному термину влёгкую можно начать холивар. ФП в этом плане отлично формализовано, что конечно не страхует от того, что кто-то может что-то напутать. Человеческий фактор не отменить, зато всегда можно глянуть точное определение.
Это тоже функциональный подход.
Императивный подход:
1) Получим указатель на массив элементов и целевой элемент
2) Определим длину массива
3) В цикле от 0 до длина-1 будем сравнивать i-ый элемент массива с целевым.
4) Если элемент совпал, то return true
5) return false
Обычно вероятность пытаются эмулировать через random, но это ничего общего с человеческой логикой. Её эмулируют нейросети, но пока на очень-очень базовом уровне.
Haskell с относительно недавнего времени стремительно набирает популярность. TIOBE его хэдлайнером ноября обозвали xD
Racket — это современный диалект Scheme, который в свою очередь используется в классической книге по Computer Science — «Structure and Interpretation of Computer Programs». Плюс на нём идет довольно крутая движуха разнообразных DSL, что весьма интересно, особенно при обучении.
Есть обучение, а есть самообучение… Почитать вики — это про самообучение. В целом оно даже эффективнее, так как движется интересом, но без соответствующих навыков или менторства может быть слишком сложно.
Да нет, конечно. Вопросы вообще были для примера… Просто некоторые ответы неправильные, некоторые неточные. Если Вам интересно восполнить этот пробел в знаниях, рекомендую книжку «Семь моделей конкуренции и параллелизма». В комментариях на мой взгляд не лучшее место расписывать, т.к. правильные ответы с пояснениями потянут на отдельную статью.
Ладно, надо будет глянуть «Закон Времени», раз рекомендуете. А то всё равно пока слишком размыто выглядит.
Да и потом, с чего Вы взяли, что предложенные языки неадекватны?.. за исключением Паскаля, остальные вполне себе используются в production, хоть и во втором эшелоне по популярности, а С так вообще — в первом, просто он уже достаточно стабилен, чтобы не дёргаться каждый год в новые фичи.
P.S. Если отвлечься от школы и переключиться на действующих программистов… Перечислите, если не трудно, список языков, которые Вы считаете перспективными с горизонтом 10 лет?
Конкуренция со стороны Java и Python-программистов мне параллельна, пусть поддерживают legacy хоть ещё 100 лет )))
Я вижу, что они уже неактуальны для многих новых проектов, поэтому для меня эти 2 языка выглядят как захламлённый Паскаль :-)
Если цель обучать под JVM, то любой из Kotlin, Scala, Clojure будет лучше Java.
А Python по моему прогнозу лет через 5 останется только как инструмент для сисадминов… всякие сценарии автоматизировать. Конечно, я могу ошибаться, но это мы узнаем только в 2021 году :-)
Ну а лет через 10 актуальными будут только те языки, которые позволят эффективно использовать сотни ядер и квантовые компьютеры, т.е. чисто декларативные. Все мои рекомендации исходят из этого убеждения.
В булевой логике нет понятия «вероятность».
Ахах, давайте вообще школу отменим, можно же википедию почитать… Только вот не читают, включая Вас, судя по ответам на предыдущие вопросы :-)
Что за управление? Менеджеров хотите готовить?
Вот Вы считаете, что LINQ — это ORM и вендорозависимое решение. А по факту, это не ORM и такой же подход можно реализовать во многих языках, где есть ФВП.
Ну что Вы привязались к Паскалю, он ведь 1 из списка, образовательный процесс на него не будет завязан, он будет его синтаксис использовать для демонстрации структурного программирования. Я уж молчу про то, что LCL — это OpenSource (Lazarus).
Правильно. В школе и не нужно изучать ASP.NET MVC и т.п. Это был ответ на Ваш вопрос по поводу внеклассной программы для тех, кто очень увлёкся программированием. И смысл в том, что они найдут чем заняться вне школы для любого ЯП.
Так это не стыдно. Их слабая известность — это недостаток текущей системы образования. Поизучайте их на досуге и поймёте почему те, кто уже ознакомился, хотели бы чтобы этим концепциям учили сразу… вместо того, чтобы пробиваться к ним годами через пот и слёзы промышленного программирования.
Python гораздо сложнее, как любой мультипарадигмальный язык. Go — на мой взгляд не простой, а урезанный… Чуть в сторону и уже приходится извращаться.
Концепции по большей части моде не подвержены, поэтому всё что останется для перехода к production — это изучить синтаксис модного к тому моменту языка. Что как мы знаем занимает 2-3 недели, включая основную часть стандартной библиотеки.
А теперь подумайте сколько лет понадобится чтобы переключиться на что-то типа Haskell после 10 лет изучения Java.