А зачем этот зазубренный максимум? Лично вам как работодателю или коллеге? У вас это «все-все-все» применяется? Вот сильно сомневаюсь. К тому-же по моему опыту обычно так: есть те, кто может запомнить только если понял до мелочей и те, кто может выучить как стишок. Первые могут рассказать куда меньше, чем вторые, но при этом с практической точки зрения первые безмерно полезнее, чем вторые. Вы все еще думаете, что вам нужен максимум? ;)
По поводу логических задачек. Они славятся тем, что нужно «догадаться». Если ты не догадался, то однозначно не решил. К тому-же такие задачки как с носками и монетками вообще неоднозначны. Скажем решил человек задачку положив половину монеток в каждый из носков, а потом запихнул носок в носок. Решил? Да. Но если мы говорим о программисте, то лучше будет если он ее не решит. Потому, что на практике массив и массив с вложенным массивом не одно и то же. Вот и думай теперь хорошо, что он решил или нет.
Хотите задачку? Дайте математическую. Для примера. Найти наименьшее натуральное число сумма цифр которого равна 40. Вроде бы ничего сложного. Правда? Но при этом вы проверите как хорошо соискатель знает основы математики, исчисления, как хорошо ориентируется за что отвечает каждый разряд. Начнет-ли он хаотично метаться или пойдет равномерно. Будет использовать прямой перебор или будет, к примеру, использовать максимальное число в каждой разрядности. Решил? Молодец! А 42? И тут могут быть несколько сценариев от мгновенного ответа до повторения части вычислений. Хотите устроить стресс-тест? Не вопрос. Предложите решить эту же задачу с помощью программы. На любом другом языке. Сейчас мало кто требует только один язык. Наверняка в резюме будет Python, а может быть что-то из модного типа Lisp или Haskell. Предложите ему ноут с Linux. Логинитесь в консоль и отдаете. Безусловно нужного языка быть не должно. Мало того, что вы мгновенно узнаете правду ли он написал по поводу администрирования, так еще и узнаете как он себя поведет в экстренной ситуации. Даже если соискатель действительно не первый раз видит Linux он как минимум должен попросить пароль. И даже если первый- не беда. Пусть признается, что нужна помощь и ее стоит оказать и посмотреть как себя поведет дальше и как он решит задачу. Как минимум можно использовать традиционный путь или функциональный подход. Не знаю как вам, а лично мне так нравится куда больше. Во всяком случае намертво заклинить не должно. А потерять перспективного кандидата только потому, что он не умеет монетки по носкам раскладывать — глупо.
Я не понимаю зачем джуну задавать столько таких вопросов. Если ты с этим всем работаешь несколько лет, то ты все это хочешь-не хочешь, а запомнил. Но тогда речь пойдет не о джуне. А джун это может только выучить как стишок. Компаниям нужен человек, который хорошо учит стихи и прозу? По-моему лучше послушать как человек рассуждает и понять нормально ли он впишется. А остальное приложится.
С решением же логических задачек вообще непонятно. Уже давно известный факт, что умение их решать говорит лишь о умении решать логические задачи. Не более того. Сильно сомневаюсь, что это хоть как-то относится к профилю хоть одной компании.
Может быть кто-то знает ответы на эти вопросы. Зачем это все?
Ну вы смешной. 28 лет. Я это решил в 40. Поверьте. Вам вообще переживать не за что. Освоите основные темы и вперед на собеседования. Тут главное не затягивать. Для многих компаний 30 лет- граничный возраст для джунов. Где-то да зацепитесь. А дальше как по масле пойдет.
Я знаю людей, которые становились программистами и в 35, и в 40, и даже в 50. И никто из них не был гением. Самые обычные люди. Не вижу причин почему бы у вас не получилось. Желание есть, упорство есть. Возраст подходящий. Если не будете зацикливаться, то все у вас получится. Удачи.
Начиная от того что сам по себе язык не быстрый (хотя и порядком шустрее R или матлаба)
Я бы хотел уточнить. Вы же про Python говорите? Сам по себе или его расширения? И почему вы ставите рядом по скорости R и Matlab? R медленный. И никто это не скрывает. А вот Matlab в развернутых тестах находится между C++ и Java. Python к ним подтягивается если использовать что-то тип Numba или PyPy.
Сам я этим не занимаюсь, но в связи с тем, что этим занимается моя жена, я немножечко в теме. И что меня сразу удивило, что SQL вынесен как отдельный язык. А что можно делать такую работу и при этом ни иметь с ним дело? Как по мне это выбор без выбора. SQL просто нужен. И я бы не стал писать про понятность и однозначность синтаксиса. С простыми запросами все ясно. А если вы пишите действительно сложные запросы, то там черт ногу сломит. А если при этом у вас в базе сотни тысяч строк, а то и миллионы и писать запрос постепенно его усложняя- вообще не вариант просто потому, что это займет часы, то вы точно не будете говорить о простоте и понятности.
Почему Matlab-у написали в качестве недостатка платность? Даже если говорить о самой дорогой коммерческой лицензии, то я бы не сказал, что это безумно дорого. $2500 для фирмы, которой нужен специалист подобного направления это совсем не большие деньги. Это всего-лишь месячная зарплата. Может две. Это много? Давайте посмотрим. Рядом с Matlab упоминалась Octave. То, что она сильно не дотягивает до него- пока не очень важно. Она дико ме-е-е-дленная. Что бы понять всю глубину глубин под дико я понимаю примерно 1000 раз. Т.е. то, что Matlab делает за минуту Octave делает почти 17 часов!!! Если вы никуда не спешите, то нет проблем. Хотя это все-таки то же перебор. А если у вас emergency и нужно срочно понять где лажа? Вы написали модель (или подправили под конкретный случай), опробовали на части данных, запустили процесс. Т.е. пару часов уже ушли. Но это еще не конец. Моделирование идет уже 10 часов, а результата все нет. Ваш начальник уже весь седой, заказчик охрип и медленно понимает, что его ждут финансовые потери, а может быть и суды, а у вас Octave не спеша колбасит циферки. Все-еще думаете, что $2500 это дорого? А если нужна научная или студенческая лицензия, то там и говорить не о чем.
И вообще я бы разделил статью как минимум на две части. О удобных и о быстрых. Ну или хотя-бы ввел показатель времени расчета одного и того-же на разных языках. Какой-бы ни был R классный он медленный. Если вам нужно анализировать громадные объемы — это большая проблема. И если с Python можно ускорится при помощи PyPy или Numba примерно до скорости С++, то с R и Octave вам остается только ждать сутками, а это приемлемо далеко не во всех случаях.
И еще я бы не стал писать «Какой язык». Я бы писал «Какие языки». У каждого из них есть свои сильные и слабые стороны. Скажем если вы все делаете на Matlab, то Python вам точно лишним не будет. Даже просто что бы помочь привести данные к нужному виду или автоматизировать процессы.
На мой взгляд не хватает теста на Matlab. Все-таки его можно в данной области считать стандартом. К тому-же он достаточно быстрый. Ну вообще было-бы интересно.
Рядники — интересная штука. Но что меня в них всегда смущало, что они находятся в непосредственной близости от оборудования. А значит обслуживающий их персонал будет обслуживать их там-же. И тут уже очень сильно зависит от того, кто это будет делать. Скажу честно. Часть наших подрядчиков я бы даже в ЛАЦ не пустил. А не то что б к оборудованию.
Ну и с рядниками есть еще вопрос как их использовать если оборудование не предполагает использование холодного-горячего коридора? Например коммутационное оборудование Ericsson забирает воздух с лицевой стороны и выбрасывает его вверх.
Но больше всего мне не нравится, что нужно подводить трубки от внешнего блока через ряды с оборудованием. Оптика и сигнальные кабели с медными трубками — плохие соседи. Как показывает практика как бы хорошо ты не планировал трассы все равно будут исключения. И как потом обслуживать магистрали кондиционеров среди оптических патчкордов? А если случится протечка? Ну и отельный разговор по поводу того как расширять оборудование. Далеко не всегда закупается все оборудование сразу. Допустим купили часть, сделали кабелировку, запустили. Подвели хладоген. Все работает. А потом нужно доставить еще часть стоек. Как проходить трассу через работающее под трафиком оборудование? Не знаю как вам, а мне больше нравится когда мухи отдельно, котлеты отдельно.
По-моему именно для программистов будет интересна игра на checkio.org. Что бы двигаться вперед вам нужно писать программы на Python и теперь еще и на JS. Вам предлагаются заковыристые задачки разной сложности. Для прохождения уровня нужно набрать определенное количество очков. Для этого вы можете решить несколько простых задач или меньшее количество сложных. После этого вы можете открыть задачи на соседних островах-уровнях. Прелесть в том, что задачи предлагаются разными людьми и они очень разные.
Ваш опыт описывает лишь единичный случай, чего маловато для доказательства (привет, матстатистика). Хотя и у меня никакой статистики нету, возможно Вы и правы.
Со статистикой все не так просто. Скажем нам нужно получить оперного певца. Мы возьмем 100 детей, а лучше 1000 и постараемся из них всех вырастить певца. Есть голос у многих, но настоящий талант у одного на миллион. Поэтому вполне может быть мы ничего не получим на выходе. Именно поэтому на практике поступают совсем по-другому. Сначала ищут детей с великолепными данными, а потом их учат.
Тут кстати не все так плохо. Как по мне, так даже поприличнее, нежели у многих мейнстримовых языков. Хотя тут, возможно, заслуга коммьюнити, а не самого языка.
От выстрела в ногу не защищен вообще никто. Я недавно воспроизвел это на Python. Хотя казалось бы он делает все, что бы мы не морочились.
В функциональных языках, по-моему, благодаря их гибкости, вероятность зачудить гораздо выше.
Я несколько неверно выразился. Скорее нужно сказать «не имеет смысла». Ведь сложность Haskell далеко не в синтаксисе…
Да и синтаксис там, к слову, сложный — можно навводить новых операторов с кастомным приоритетом. А потом городить всякие (*) <$> (+3) <*> (*2) $ 2. А вот в Lisp вообще нету операторов и их приоритета ;)
Как по мне смысл может быть, а может и не быть, в зависимости от целей. Скажем если ваша цель писать на Lisp в определенном проекте учить Haskell как-то вообще бессмысленно. А вот если вы пишете на Java, но хотите понимать что происходит в нововведениях, то языки можно и посравнивать что бы выбрать наиболее подходящий именно вам. И выбранный язык не обязательно будет самым быстрым или самым понятным. Ведь выбор порой не всегда рациональный.
С вводом новых операторов на мой взгляд вообще нужно быть предельно осторожным. Безусловно хорошо когда они есть и бывает очень удобно их применять, но существует совсем не нулевая вероятность, что другой человек поймет это совсем по-другому, а может и вообще не будет понимать, а просто поступит исходя из своего опыта и даже не задумается.
Кстати, скобочек в Clojure зачастую меньше выходит, нежели в Java.
Вопрос не в том, что их много. Вопрос в том, как они используются. В Java скобки разные для блока и для функции. Конечно бывают случаи когда смотришь на вызов функции и не можешь понять ")))))" или "))))))" правильно. Но все эти скобки на одной строке, а не в пределах страницы. И если вам действительно не нравятся скобки в куске на Java вы можете от них легко избавится использую поля а не гетеры. Или переписать вот так:
Хотя, при изучении программирования с 0, думаю, разницы бы особой не было.
В этом вопросе я готов спорить до хрипоты опираясь на свой опыт. Я подучиваю свою дочку программированию. И не давать ей выбора- не мой путь. Поэтому я ей рассказал с самого начала общие подходы и предложил начать именно с функционального программирования. Просто что-бы понять что это хотя бы в самых азах. Скажу сразу, что идея ФП ей понравилась. Мы взяли Lisp и начали писать простенькие программки. И очень быстро дочка сказала, что Lisp ей не нравится. Не идеями, а именно синтаксисом. И это мы говорим о ребенке с великолепной памятью, развитым пространственным мышлением и отличными математическими способностями.
А вот с Java и после с Python у нее вообще не было никаких проблем.
и конечно возможность стрельнуть в ногу себе и своему коллеге разумеется
Вот именно это меня и смущает. Я сторонник кода, который можно разобрать даже с жесткого бодуна. Просто в свое время учился программировать у людей, которые всю жизнь делали системы управления для критически важных систем. В основном для космоса. И когда то, что ты писал уезжает на АЭС выстрел в ногу выглядит несколько с другого ракурса.
Так себе гуру, если чЭсна :)
Кто это был я сейчас не вспомню, но кто-то с мировой известностью из мира Lisp. Так что какие есть ;)
Haskell вообще некорректно сравнивать.
А почему не корректно? Хотелось бы узнать ваше мнение в общих чертах.
Со Scala все тоже сложно. Многие, в том числе и я, считают язык слишком переусложненным. Интероп с Java кстати у Clojure проще нежели у Scala: как минимум не надо возится с преобразованием коллекций и прочей бюрократией, нет проблемы дженериков (нет дженериков — нет проблем) и т.п.
Что-то получили, что-то потеряли. Но тут я готов терпеть Scala. Очень уж мне не нравится синтаксис Lisp-a. Я долго не мог начать учить Python из-за его отступов, но в конце-концов я с собой справился и рад этому. Но вот со скобочками я ничего не могу с собой поделать.
Функциональные языки- это все очень здорово. Даже больше. Каждый, кто более-менее серьезно и регулярно пишет программы приходит к тому, что их таки нужно учить. И это действительно приносит свои плоды.
Но все безоблачно только в самых основах. Простые примеры вроде бы понятны и все отлично работает. Пока ты на мелководьи водичка теплая, светит солнышко и вокруг тебя плавают маленькие рыбки. Но вот когда начинаешь погружаться чуть глубже, начинаешь видеть глубоководных чудовищ. И тут уже не до смеха.
Я хорошо запомнил статью, в которой автор писал на Haskell разбор файлов, которые ему отдает ATC. И вроде бы Haskell славится скоростью, но его программа колбасилась с файлами по пол-часа. Комментарии было читать очень интересно и его программа в результате стала гораздо лучше, но я не сказал-бы что все они мне дались легко. Для понимания многих из них пришлось хорошо покурить доки. Но даже несмотря на все старания программа не стала молниеносной.
Я сам время от времени пишу скрипты для обработки файлов, но на Python. Обычные скрипты с использованием максимально простого синтаксиса. Даже порой с избытком простоты. Я отдаю их жене и она уже их использует. И еще время от времени вносит в них правки. И при этом она вообще не программист. Она математик. И они все еще отлично разбирают файлы. Файлы с миллионами строк.
И после всего этого как-то не очень верится в простоту функциональных языков.
Ну и учить Lisp и его производные советовать я бы лично точно не стал. Все-таки его синтаксис просто безумие чистой воды. И то, что гуру Lisp советуют в случаях, когда вы не можете разобраться со скобками- перепишите или поверьте написанному, говорит о очень многом. Тот-же Haskell выглядит куда более читаемым, а Scala так вообще выглядит привычнее некуда и при этом совместима с Java.
В общем не все так безоблачно в функциональном королевстве.
Разве с вами кто-то спорил? Вы спросили умеет-ли Vim? Вам ответили — умеет.
Мне, честно говоря, вообще не понятен посыл одно против другого. Зачем? Тем более для таких разных инструментов. По-моему куда лучше смотрится Vim + IDE.
Лично я не вижу ничего зазорного в том, что бы проект писать в IDE, а скажем какие-то файлы открывать в Vim и производить поиск или анализ. Если информации много. Скажем сотни тысяч строк, то выискивать что-то руками или простым поиском- гиблое дело. А если строки очень похожи, то вообще жесть. И при этом даже несложная регулярка поможет вам сэкономить кучу времени и нервов.
Я все понимаю, но меня слегка смущают цифры. Я только что запустил AndroidStudio и ей потребовались 600М. Странно? Вот и я так думаю.
Vim — один из самых дебильных редакторов. Более недружелюбного и уродского еще нужно поискать. Но его сила ни в удобстве. И даже ни в его фичах. Его основная сила в том, что на любой Unix и Unix-like системе он будет. И какой бы жидкий канал не был он будет отлично работать.
По поводу логических задачек. Они славятся тем, что нужно «догадаться». Если ты не догадался, то однозначно не решил. К тому-же такие задачки как с носками и монетками вообще неоднозначны. Скажем решил человек задачку положив половину монеток в каждый из носков, а потом запихнул носок в носок. Решил? Да. Но если мы говорим о программисте, то лучше будет если он ее не решит. Потому, что на практике массив и массив с вложенным массивом не одно и то же. Вот и думай теперь хорошо, что он решил или нет.
Хотите задачку? Дайте математическую. Для примера. Найти наименьшее натуральное число сумма цифр которого равна 40. Вроде бы ничего сложного. Правда? Но при этом вы проверите как хорошо соискатель знает основы математики, исчисления, как хорошо ориентируется за что отвечает каждый разряд. Начнет-ли он хаотично метаться или пойдет равномерно. Будет использовать прямой перебор или будет, к примеру, использовать максимальное число в каждой разрядности. Решил? Молодец! А 42? И тут могут быть несколько сценариев от мгновенного ответа до повторения части вычислений. Хотите устроить стресс-тест? Не вопрос. Предложите решить эту же задачу с помощью программы. На любом другом языке. Сейчас мало кто требует только один язык. Наверняка в резюме будет Python, а может быть что-то из модного типа Lisp или Haskell. Предложите ему ноут с Linux. Логинитесь в консоль и отдаете. Безусловно нужного языка быть не должно. Мало того, что вы мгновенно узнаете правду ли он написал по поводу администрирования, так еще и узнаете как он себя поведет в экстренной ситуации. Даже если соискатель действительно не первый раз видит Linux он как минимум должен попросить пароль. И даже если первый- не беда. Пусть признается, что нужна помощь и ее стоит оказать и посмотреть как себя поведет дальше и как он решит задачу. Как минимум можно использовать традиционный путь или функциональный подход. Не знаю как вам, а лично мне так нравится куда больше. Во всяком случае намертво заклинить не должно. А потерять перспективного кандидата только потому, что он не умеет монетки по носкам раскладывать — глупо.
С решением же логических задачек вообще непонятно. Уже давно известный факт, что умение их решать говорит лишь о умении решать логические задачи. Не более того. Сильно сомневаюсь, что это хоть как-то относится к профилю хоть одной компании.
Может быть кто-то знает ответы на эти вопросы. Зачем это все?
Я знаю людей, которые становились программистами и в 35, и в 40, и даже в 50. И никто из них не был гением. Самые обычные люди. Не вижу причин почему бы у вас не получилось. Желание есть, упорство есть. Возраст подходящий. Если не будете зацикливаться, то все у вас получится. Удачи.
Я бы хотел уточнить. Вы же про Python говорите? Сам по себе или его расширения? И почему вы ставите рядом по скорости R и Matlab? R медленный. И никто это не скрывает. А вот Matlab в развернутых тестах находится между C++ и Java. Python к ним подтягивается если использовать что-то тип Numba или PyPy.
Почему Matlab-у написали в качестве недостатка платность? Даже если говорить о самой дорогой коммерческой лицензии, то я бы не сказал, что это безумно дорого. $2500 для фирмы, которой нужен специалист подобного направления это совсем не большие деньги. Это всего-лишь месячная зарплата. Может две. Это много? Давайте посмотрим. Рядом с Matlab упоминалась Octave. То, что она сильно не дотягивает до него- пока не очень важно. Она дико ме-е-е-дленная. Что бы понять всю глубину глубин под дико я понимаю примерно 1000 раз. Т.е. то, что Matlab делает за минуту Octave делает почти 17 часов!!! Если вы никуда не спешите, то нет проблем. Хотя это все-таки то же перебор. А если у вас emergency и нужно срочно понять где лажа? Вы написали модель (или подправили под конкретный случай), опробовали на части данных, запустили процесс. Т.е. пару часов уже ушли. Но это еще не конец. Моделирование идет уже 10 часов, а результата все нет. Ваш начальник уже весь седой, заказчик охрип и медленно понимает, что его ждут финансовые потери, а может быть и суды, а у вас Octave не спеша колбасит циферки. Все-еще думаете, что $2500 это дорого? А если нужна научная или студенческая лицензия, то там и говорить не о чем.
И вообще я бы разделил статью как минимум на две части. О удобных и о быстрых. Ну или хотя-бы ввел показатель времени расчета одного и того-же на разных языках. Какой-бы ни был R классный он медленный. Если вам нужно анализировать громадные объемы — это большая проблема. И если с Python можно ускорится при помощи PyPy или Numba примерно до скорости С++, то с R и Octave вам остается только ждать сутками, а это приемлемо далеко не во всех случаях.
И еще я бы не стал писать «Какой язык». Я бы писал «Какие языки». У каждого из них есть свои сильные и слабые стороны. Скажем если вы все делаете на Matlab, то Python вам точно лишним не будет. Даже просто что бы помочь привести данные к нужному виду или автоматизировать процессы.
Ну и с рядниками есть еще вопрос как их использовать если оборудование не предполагает использование холодного-горячего коридора? Например коммутационное оборудование Ericsson забирает воздух с лицевой стороны и выбрасывает его вверх.
Но больше всего мне не нравится, что нужно подводить трубки от внешнего блока через ряды с оборудованием. Оптика и сигнальные кабели с медными трубками — плохие соседи. Как показывает практика как бы хорошо ты не планировал трассы все равно будут исключения. И как потом обслуживать магистрали кондиционеров среди оптических патчкордов? А если случится протечка? Ну и отельный разговор по поводу того как расширять оборудование. Далеко не всегда закупается все оборудование сразу. Допустим купили часть, сделали кабелировку, запустили. Подвели хладоген. Все работает. А потом нужно доставить еще часть стоек. Как проходить трассу через работающее под трафиком оборудование? Не знаю как вам, а мне больше нравится когда мухи отдельно, котлеты отдельно.
Со статистикой все не так просто. Скажем нам нужно получить оперного певца. Мы возьмем 100 детей, а лучше 1000 и постараемся из них всех вырастить певца. Есть голос у многих, но настоящий талант у одного на миллион. Поэтому вполне может быть мы ничего не получим на выходе. Именно поэтому на практике поступают совсем по-другому. Сначала ищут детей с великолепными данными, а потом их учат.
От выстрела в ногу не защищен вообще никто. Я недавно воспроизвел это на Python. Хотя казалось бы он делает все, что бы мы не морочились.
В функциональных языках, по-моему, благодаря их гибкости, вероятность зачудить гораздо выше.
Как по мне смысл может быть, а может и не быть, в зависимости от целей. Скажем если ваша цель писать на Lisp в определенном проекте учить Haskell как-то вообще бессмысленно. А вот если вы пишете на Java, но хотите понимать что происходит в нововведениях, то языки можно и посравнивать что бы выбрать наиболее подходящий именно вам. И выбранный язык не обязательно будет самым быстрым или самым понятным. Ведь выбор порой не всегда рациональный.
С вводом новых операторов на мой взгляд вообще нужно быть предельно осторожным. Безусловно хорошо когда они есть и бывает очень удобно их применять, но существует совсем не нулевая вероятность, что другой человек поймет это совсем по-другому, а может и вообще не будет понимать, а просто поступит исходя из своего опыта и даже не задумается.
Вопрос не в том, что их много. Вопрос в том, как они используются. В Java скобки разные для блока и для функции. Конечно бывают случаи когда смотришь на вызов функции и не можешь понять ")))))" или "))))))" правильно. Но все эти скобки на одной строке, а не в пределах страницы. И если вам действительно не нравятся скобки в куске на Java вы можете от них легко избавится использую поля а не гетеры. Или переписать вот так:
Тогда скобок будет меньше ;) Но я не очень люблю эту конструкцию потому, что она снижает читаемость.
В этом вопросе я готов спорить до хрипоты опираясь на свой опыт. Я подучиваю свою дочку программированию. И не давать ей выбора- не мой путь. Поэтому я ей рассказал с самого начала общие подходы и предложил начать именно с функционального программирования. Просто что-бы понять что это хотя бы в самых азах. Скажу сразу, что идея ФП ей понравилась. Мы взяли Lisp и начали писать простенькие программки. И очень быстро дочка сказала, что Lisp ей не нравится. Не идеями, а именно синтаксисом. И это мы говорим о ребенке с великолепной памятью, развитым пространственным мышлением и отличными математическими способностями.
А вот с Java и после с Python у нее вообще не было никаких проблем.
Вот именно это меня и смущает. Я сторонник кода, который можно разобрать даже с жесткого бодуна. Просто в свое время учился программировать у людей, которые всю жизнь делали системы управления для критически важных систем. В основном для космоса. И когда то, что ты писал уезжает на АЭС выстрел в ногу выглядит несколько с другого ракурса.
Кто это был я сейчас не вспомню, но кто-то с мировой известностью из мира Lisp. Так что какие есть ;)
А почему не корректно? Хотелось бы узнать ваше мнение в общих чертах.
Что-то получили, что-то потеряли. Но тут я готов терпеть Scala. Очень уж мне не нравится синтаксис Lisp-a. Я долго не мог начать учить Python из-за его отступов, но в конце-концов я с собой справился и рад этому. Но вот со скобочками я ничего не могу с собой поделать.
Но все безоблачно только в самых основах. Простые примеры вроде бы понятны и все отлично работает. Пока ты на мелководьи водичка теплая, светит солнышко и вокруг тебя плавают маленькие рыбки. Но вот когда начинаешь погружаться чуть глубже, начинаешь видеть глубоководных чудовищ. И тут уже не до смеха.
Я хорошо запомнил статью, в которой автор писал на Haskell разбор файлов, которые ему отдает ATC. И вроде бы Haskell славится скоростью, но его программа колбасилась с файлами по пол-часа. Комментарии было читать очень интересно и его программа в результате стала гораздо лучше, но я не сказал-бы что все они мне дались легко. Для понимания многих из них пришлось хорошо покурить доки. Но даже несмотря на все старания программа не стала молниеносной.
Я сам время от времени пишу скрипты для обработки файлов, но на Python. Обычные скрипты с использованием максимально простого синтаксиса. Даже порой с избытком простоты. Я отдаю их жене и она уже их использует. И еще время от времени вносит в них правки. И при этом она вообще не программист. Она математик. И они все еще отлично разбирают файлы. Файлы с миллионами строк.
И после всего этого как-то не очень верится в простоту функциональных языков.
Ну и учить Lisp и его производные советовать я бы лично точно не стал. Все-таки его синтаксис просто безумие чистой воды. И то, что гуру Lisp советуют в случаях, когда вы не можете разобраться со скобками- перепишите или поверьте написанному, говорит о очень многом. Тот-же Haskell выглядит куда более читаемым, а Scala так вообще выглядит привычнее некуда и при этом совместима с Java.
В общем не все так безоблачно в функциональном королевстве.
Мне, честно говоря, вообще не понятен посыл одно против другого. Зачем? Тем более для таких разных инструментов. По-моему куда лучше смотрится Vim + IDE.
Лично я не вижу ничего зазорного в том, что бы проект писать в IDE, а скажем какие-то файлы открывать в Vim и производить поиск или анализ. Если информации много. Скажем сотни тысяч строк, то выискивать что-то руками или простым поиском- гиблое дело. А если строки очень похожи, то вообще жесть. И при этом даже несложная регулярка поможет вам сэкономить кучу времени и нервов.
Vim — один из самых дебильных редакторов. Более недружелюбного и уродского еще нужно поискать. Но его сила ни в удобстве. И даже ни в его фичах. Его основная сила в том, что на любой Unix и Unix-like системе он будет. И какой бы жидкий канал не был он будет отлично работать.