Плюсанул, хотя со Scala не согласен, там слишком много разнородных концепций намешано в кучу. А для обучения лучше подходят чистые концепции аля Haskell, Scheme(всё-таки для обучения лучше Racket, чем Common Lisp), Smalltalk. Про SML ничего сказать не могу, я с ним не знаком )
Я уж молчу про обучение нормальным языкам, а не динозаврами, но даже не в этом суть
А какие языки нормальны для обучения? На мой взгляд, язык для обучения должен быть достаточно фундаментален, чтобы на его примере можно было показывать основные концепции, не подверженные быстрому устареванию. Т.е. получается, что для обучения можно применять C, Pascal, Smalltalk (есть в варианте для самых маленьких — Scratch), Haskell, Racket.
Советовать учить PHP, Ruby, Python, Java, C# в школе, я бы не стал… это всё либо станет неактуальным к моменту, когда они закончат школу и универ, либо 100 раз ещё изменится. Да и не все же должны прикладными программистами становиться… Подумайте о других предметах, везде даётся классический базис. С чего бы именно программу по Computer Science надо переписывать каждый год и учить тому, что заведомо будет неактуально лет через 20?
хочу, чтобы не просто какие-то конструкции ЯП можно было бы описать в терминах ТК, а чтобы само приложение было написано в терминах ТК. Короче, в Haskell есть конструкции, которые типа из ТК, но всё-равно приложения пишутся в терминах функций, типов, классов, а не ТК.
Для меня это выглядит логичным, потому что программисты, может быть за редким исключением, не мыслят в терминах теории категорий при разработке программы.
Но в любом случае, успехов Вам, может правда кому-то пригодится и такой ЯП.
Да, он по мотивам Haskell. Насчёт "мало ТК в Haskell" у меня возникает вопрос: Вы хотите много теории категорий в языке, чтобы что? Какой-то практический смысл в этом будет? Или просто just for fun эзотерический ЯП создать?
Вам намекнули, что "A опосредованно знает D" — это уже не ассоциативность, а транзитивность, которая вообще не про скобки. А вот что Вы подразумеваете под отношением "знает" и как его транзитивность следует из ассоциативности композиции функций или наоборот — это уже загадка.
На мой взгляд мобильной версией сайта просто неудобно пользоваться… Если статьи ещё можно читать, то комментарии писать и т.д. — почти нереально… все элементы управления малюсенькие и никак не учитывают возможность ими пользоваться на маленьком экране.
Откуда вы все в моем коменте находите происки JavaScript? :)
Ну, расскажите нам подробнее какие ещё есть отрасли, где такая же катавасия с технологиями, что они всего по 3 года живут.
нет в индустрии программирования такого объема знаний, который необходимо постигать десятилетиями.
Объём всё-таки довольно приличный, если всю индустрию взять, то и на 30+ лет изучения наберётся… Впрочем, на практике вся индустрия не нужна, нужна пара конкретных областей и немного из смежных, так что лет за 10 вполне реально выйти на плато. Но по факту мало кто выходит, т.к. по работе технологический стек может быть весьма ограниченным, что приводит к эффекту своеобразной зашоренности.
учитывая тот факт, что в программировании из нулевого стажа совсем не следует нулевой опыт практического программирования
гхм, мы тут вообще-то опыт и обсуждаем, а не стаж..
сам я занимаюсь rocket science, т.ч. в обозримом будущем у нас не наблюдается фазы "ничто не вечно под луною".
s/вечно/ново/
К rocket science эта фраза точно так же применима… Просто люди склонны переоценивать инновационную составляющую на порядки, в виду слабого знакомства с тем, что уже было :-)
Во первых, 3 года по меркам индустрии — это много, сравнимо со средним сроком актуальности конкретно взятой технологии.
Индустрия не ограничивается JavaScript. Так что в среднем срок актуальности технологий всё-таки ближе к 10 годам. Но суть даже не в этом… Когда у Вас наберётся приличный багаж знаний, Вы будете замечать общие моменты и мысль "ничто не ново под Луною" будет всё чаще всплывать при знакомстве с очередной супер-пупер-модной технологией.
Ниже уже писали, что годы могут пройти и без повышения левела, так что it depends…
На небольшом кол-ве лет проще делать выводы, т.к. можно прикинуть какое-то минимальное кол-во лет, требующееся для достижения конкретного уровня. Конечно, исключения возможны, но чаще за пару лет у людей возникает иллюзия компетентности, а не компетентность… Если уровень растёт, то человек это сам осознает постфактум.
Даже если это сарказм, то какой-то дурной… Всю статью можно свести к паре предложений:
"Не зацикливайтесь на ярлыках, а лучше вообще забудьте о них. Лучше делайте что должно для профессионального роста."
Автор же, отбрасывая одни ярлыки, тут же обвешивается с ног до головы другими: библиотекарь, ученый, художник, плотник. Имхо, это тупо.
бросаются словом «хакер» (и связанными с ним «хак», «хакфест» и «хакатон»), как будто рандомно ломать что-то на кусочки или вламываться в несанкционированную систему — хорошо.
Для программиста как-то несолидно в стиле жёлтой прессы ассоциировать слово "хакер" со взломом.
UPD: В Clojure есть хвостовая рекурсия, но немного кривенькая в плане внешнего вида.
Давайте уж по-честному, recur — это воркэраунд, необходимый как раз из-за отсутствия оптимизации хвостовой рекурсии на уровне байт-кода.
Поддержать что-то на стадии компиляции в байт-код — это тоже вариант, но это как раз то, что я назвал подстройкой под Java. Хотя ниже вспомнили случай (JSR 292), когда JVM всё-таки реализовала что-то не для Java. Но это скорее редкость по сравнению с CLR/DLR, на развитие которых существенное влияние оказывают, что C#, что F#, что VB.NET, что Iron-языки.
Scala, Kotlin, Ceylon, JRuby, Clojure, Groovy и многие другие jvm языки не противоречат этому утверждению?
Я думаю, в исходном утверждении имелось в виду, что возможности IL не ограничены возможностями C#. Ну, к примеру, было бы так, что в Java нет хвостовой рекурсии, а в Clojure — есть. Но получается, что в Clojure её тоже нет, потому что в Java она не особо нужна, а ради какой-то Clojure в JVM никто ничего добавлять не будет. Т.е., к сожалению, все JVM-языки вынуждены подстраиваться под Java и вторичны к ней.
Здесь подразумевается AOT или JIT?
Возможно, имели в виду .NET Native, а так и AOT и JIT тоже есть.
Плюсанул, хотя со Scala не согласен, там слишком много разнородных концепций намешано в кучу. А для обучения лучше подходят чистые концепции аля Haskell, Scheme(всё-таки для обучения лучше Racket, чем Common Lisp), Smalltalk. Про SML ничего сказать не могу, я с ним не знаком )
А какие языки нормальны для обучения? На мой взгляд, язык для обучения должен быть достаточно фундаментален, чтобы на его примере можно было показывать основные концепции, не подверженные быстрому устареванию. Т.е. получается, что для обучения можно применять C, Pascal, Smalltalk (есть в варианте для самых маленьких — Scratch), Haskell, Racket.
Советовать учить PHP, Ruby, Python, Java, C# в школе, я бы не стал… это всё либо станет неактуальным к моменту, когда они закончат школу и универ, либо 100 раз ещё изменится. Да и не все же должны прикладными программистами становиться… Подумайте о других предметах, везде даётся классический базис. С чего бы именно программу по Computer Science надо переписывать каждый год и учить тому, что заведомо будет неактуально лет через 20?
Физика начинается с 6-го класса, а химия — с 7-го, или сейчас что-то поменялось?
Для меня это выглядит логичным, потому что программисты, может быть за редким исключением, не мыслят в терминах теории категорий при разработке программы.
Но в любом случае, успехов Вам, может правда кому-то пригодится и такой ЯП.
Да, он по мотивам Haskell. Насчёт "мало ТК в Haskell" у меня возникает вопрос: Вы хотите много теории категорий в языке, чтобы что? Какой-то практический смысл в этом будет? Или просто just for fun эзотерический ЯП создать?
Спасибо за ответ. Теперь стало понятнее, что Вы хотели донести.
Уже ведь есть PureScript.
Вам намекнули, что "A опосредованно знает D" — это уже не ассоциативность, а транзитивность, которая вообще не про скобки. А вот что Вы подразумеваете под отношением "знает" и как его транзитивность следует из ассоциативности композиции функций или наоборот — это уже загадка.
На мой взгляд мобильной версией сайта просто неудобно пользоваться… Если статьи ещё можно читать, то комментарии писать и т.д. — почти нереально… все элементы управления малюсенькие и никак не учитывают возможность ими пользоваться на маленьком экране.
Ну, расскажите нам подробнее какие ещё есть отрасли, где такая же катавасия с технологиями, что они всего по 3 года живут.
Объём всё-таки довольно приличный, если всю индустрию взять, то и на 30+ лет изучения наберётся… Впрочем, на практике вся индустрия не нужна, нужна пара конкретных областей и немного из смежных, так что лет за 10 вполне реально выйти на плато. Но по факту мало кто выходит, т.к. по работе технологический стек может быть весьма ограниченным, что приводит к эффекту своеобразной зашоренности.
гхм, мы тут вообще-то опыт и обсуждаем, а не стаж..
s/вечно/ново/
К rocket science эта фраза точно так же применима… Просто люди склонны переоценивать инновационную составляющую на порядки, в виду слабого знакомства с тем, что уже было :-)
Индустрия не ограничивается JavaScript. Так что в среднем срок актуальности технологий всё-таки ближе к 10 годам. Но суть даже не в этом… Когда у Вас наберётся приличный багаж знаний, Вы будете замечать общие моменты и мысль "ничто не ново под Луною" будет всё чаще всплывать при знакомстве с очередной супер-пупер-модной технологией.
Ниже уже писали, что годы могут пройти и без повышения левела, так что it depends…
На небольшом кол-ве лет проще делать выводы, т.к. можно прикинуть какое-то минимальное кол-во лет, требующееся для достижения конкретного уровня. Конечно, исключения возможны, но чаще за пару лет у людей возникает иллюзия компетентности, а не компетентность… Если уровень растёт, то человек это сам осознает постфактум.
Даже если это сарказм, то какой-то дурной… Всю статью можно свести к паре предложений:
"Не зацикливайтесь на ярлыках, а лучше вообще забудьте о них. Лучше делайте что должно для профессионального роста."
Автор же, отбрасывая одни ярлыки, тут же обвешивается с ног до головы другими: библиотекарь, ученый, художник, плотник. Имхо, это тупо.
Для программиста как-то несолидно в стиле жёлтой прессы ассоциировать слово "хакер" со взломом.
Мудрость приходит с годами, но иногда годы приходят одни. ©
Смотря где. Если в среднем по России, то это очень много. Особенно учитывая что 3 года опыта — это по факту в лучшем случае миддл.
Странно, что умолчали о замене интерактивным командам git, типа
git add -i,git rebase -i.Я вообще без них workflow в git не представляю.
Нет. Почему Вам везде мерещится JavaScript?
dynamicи компания пришли из IronRuby/IronPython.Давайте уж по-честному,
recur— это воркэраунд, необходимый как раз из-за отсутствия оптимизации хвостовой рекурсии на уровне байт-кода.Поддержать что-то на стадии компиляции в байт-код — это тоже вариант, но это как раз то, что я назвал подстройкой под Java. Хотя ниже вспомнили случай (JSR 292), когда JVM всё-таки реализовала что-то не для Java. Но это скорее редкость по сравнению с CLR/DLR, на развитие которых существенное влияние оказывают, что C#, что F#, что VB.NET, что Iron-языки.
Я думаю, в исходном утверждении имелось в виду, что возможности IL не ограничены возможностями C#. Ну, к примеру, было бы так, что в Java нет хвостовой рекурсии, а в Clojure — есть. Но получается, что в Clojure её тоже нет, потому что в Java она не особо нужна, а ради какой-то Clojure в JVM никто ничего добавлять не будет. Т.е., к сожалению, все JVM-языки вынуждены подстраиваться под Java и вторичны к ней.
Возможно, имели в виду .NET Native, а так и AOT и JIT тоже есть.