Регулярно сталкиваюсь со случаями, когда фрилансер выполняет заказ, физически находясь в конторе заказчика. Получается, что фриланс это не всегда удалённая работа.
Я когда-то пробовал превратить Vim в IDE, но не для Haskell, а для Perl, PHP и JS. Сейчас уже не вспомню, по каким конкретно причинам не зашло. В общем — время загрузки, конфликты с уже установленными плагинами, некоторая непредсказуемость поведения, тогда как по удобству, интуитивности и фичерам всё равно до полноценного IDE не дотягивало. Остался на PhpStorm с плагином CamelCade для Perl. Кроме того, я ценю Vim в первую очередь как мощный и быстро доступный универсальный текстовый редактор, и этой цели после загромождения кучей плагинов он как-то перестал активно содействовать. Вполне возможно, что всё это решаемо, но я не гуру, и тогда не было особого желания копаться в потрохах и тратить время на выяснение.
Для Haskell пока не пробовал. Я абсолютный новичок в Haskell. Года четыре назад пытался изучать этот язык — кажется, пробовал Emacs, плагин для Eclipse, и даже Leksah. Последний IDE оказался (на мой взгляд) слишком нестандартным и сырым. Eclipse работал (когда был в настроении), Emacs, емнип, тоже. Но я быстро попал в Cabal hell, поагонизировал пару вечеров и снёс всё к чертям. :)
Недавно узнал о Stack, и как он решает проблему Cabal hell, так что решил попробовать снова. Гугление быстро привело к Atom. Порог вхождения низкий, функциональности для учёбы вполне хватает. Читаю Real World Haskell, доки по Stack — пока всё работает предсказуемо.
Может, стоит снова попробовать… Если решусь — отпишусь о результатах.
А можно подробней? Это или что-то другое? У меня пока что очень неплохо работает Atom с набором пакетов atom-haskell. Причём, установка довольно прямолинейная, практически без бубна, поддерживается stack.
Вообще, каждому своё. Для интроверта техподдержка может оказаться адом.
До того, как стал работать программистом, поработал 3.5 года в техподдержке.
Первое собеседование в техподдержку большого интернет-провайдера не прошёл. Отсеялся после технического экзамена на групповой динамике. Уже выходя из здания примерно понял промахи, а погуглив, составил стратегию для прохождения следующего собеседования. Язык жестов, улыбаться, хвалить, безграничный оптимизм. И 20 капель валерианки для душевного равновесия.
Полгода в хелпдеске другой крупной фирмы, предоставляющей услуги интернета и кабельного телевидения. Уволили за слишком длинные разговоры с клиентами и общую медлительность в работе с приложениями — что не удивительно, т.к. это был первый раз, когда реально пришлось работать (а не ваньку валять) за компьютером с очень разными интерфейсами.
Два года в той фирме, в которой первый раз провалил собеседование. К концу первого года стал впадать в депрессию: достаточно трёх-четырёх звонков типа "у вас всё плохо", "какие вы плохие", "у меня нет интернета, я вас уничтожу", чтобы задать фоновую атмосферу всему дню. И слишком мало технического вызова. Начал было увольняться, но тут начальника (благослови Бог этого доброго человека) перевели начальствовать над более технически продвинутой командой, а он меня взял без собеседования. Ещё год, и тут я уже взвыл. Чёрная непреодолимая депрессия с чуть-ли не физической невозможностью зайти в здание фирмы, чтобы начать работу. Бросил и стал искать что-то другое.
Год в техподдержке относительно небольшой фирмы, предоставляющей услуги хостинга, регистрации доменных имён и электронной коммерции. В другой фирме предлагали бОльшую зарплату, но я уже пару лет копался в HTML, CSS и JS, так что пошёл в сторону интереса. За первые полгода стал "ведущим инженером поддержки", начал осваиваться с серверной частью и стал писать сценарии из смеси JS с PHP, чтобы автоматизировать проверки сервисов. Ещё через полгода депрессия вернулась, и я подал письмо об увольнении.
Дальше было что-то сверхъестественное: мне предложили перейти на должность интегратора новой CRM, что включало в себя разработку клиентского (в смысле браузера) и серверного кода (PHP) плюс LAMP-менеджмент и всё, что лень делать системщикам. От такого шанса отказываться грех, так что ещё через год мне стали передавать проекты уже систем самой фирмы. Пришлось за две недели (и за последующие два года) изучить Perl, но это того стоило.
Мораль сей басни такова: кому хорошо в поддержке/обслуживании клиентов — и хорошо, особенно, если зарплата радует. А кому нравится решать сложные технические задачи, и/или решать логические задачи и много работать с текстом — такие работы, особенно техподдержка, следует рассматривать в качестве трамплина, дающего возможность прокачать скилл общения с людьми и при удачно выбранной области деятельности — хорошенько практически покопаться в ранее чисто теоретической целевой предметной области, что сильно повышает шансы получить в ней работу джуниора.
Без амбиций можно и дворником работать. Или в котельной — как Цой.
Зачем бросаться в крайности? Мир не чёрно-белый, есть и другие варианты. Не всем быть космонавтами, и не всем этого хочется.
«Мы не настолько богаты, чтобы покупать дешевые вещи». К этим 300 рублям добавьте работу тестеров и менеджера. И время на правку багов, которые вылезут при эксплуатации. Выйдет дороже, чем день работы сеньора, который сразу сделает нормально.
Одна знакомая мне фирма заказала относительно крупный проект у вот такого сеньора с огромным опытом и, соответственно, требованиями к зарплате (порядка 150$ в час). Менеджмент наивно положился на известность, крутость, опыт, ответственность и т.д., и не привлекла к составлению требований своих технических специалистов. В результате проект после сдачи допиливается уже год (или больше), естественно, за дополнительные деньги. Например, везде, где используется SQL, были допущены инъекции. На одной из встреч, на которой уже присутствовали местные программисты, на вопрос о безопасности был получен лаконичный ответ: этого не было в требованиях. Вот вам и сеньор...
А вообще, независимо от этого конкретного случая, в том же Израиле рынок забит требованиями микроразработок для всевозможных CMS или того же Magento — на PHP. И я знаком с преуспевающими фрилансерами, берущими порядка 50$ в час, клиенты которых успешно пишут свои блоги, имеют успешные веб-магазины, заточенные под нужды бизнеса. И для выполнения этой работы не нужно даже намёка на высшее образование, только интуитивное логическое мышление и хорошее знакомство с поддерживаемым CMS.
Пока ещё есть. Дальше почти вся такая работа будет забангалорена.
Или не будет. Лично знаком с многими бизнесами, которые пытались радикально экономить, обращаясь к индусам, а потом, после мучительного ада из полувзаимонепонимания, шли на поклон к местным специалистам.
WordPress уже не так популярен как несколько лет назад, да и это не лучшая cms.
У меня есть опыт с Magento, но эту систему чисто как CMS, имхо, использовать — перебор. Так какая — лучшая?
Другое дело, что будь я бек-программистом, то надо было бы знать, к примеру, о списке(так как в некоторых языках можно задать массив только фиксированной длины) или о хеш-таблицах(хотя не факт, надо уметь правильно подобрать хеш-функция, а в готовых решениях уже все продумано).
Бэкенд бэкенду рознь. В PHP массив он же и лист, и словарь. В Perl массив отличается от словаря, но оба не ограничены длинной.
На фронте актуальнее прототипы, всплытия, делегирование, замыкания и тд
Ну, замыкания и в Perl, и в PHP лично мне приходится использовать относительно регулярно. Пока ещё не родилось обобщённого понимания, чтобы выделить класс случаев, когда замыкания удобны. Но в некоторых конкретных задачах самым интуитивным решением бывает именно замыкание. Имхо.
Написанная человеком программа всегда (или, по крайней мере, в обозримом будущем) будет проще, чем человеческий организм. И всегда менее важна, чем человеческий организм — даже когда служит для его защиты, и когда от правильной работы программы зависит человеческая жизнь.
Я не утверждал, что в любые области программирования можно пускать без профильного образования. Я глубоко убеждён, что в области, где от правильной работы программы зависят человеческие жизни, нужно пускать только специалистов, многократно доказавших себя и в прикладных, и в теоретических знаниях, а также в этических убеждениях. И в таких случаях только лишь инженерного образования, имхо, недостаточно. Искренне надеюсь, что даже отличников-студентов не пускают к продакшн-программированию космических кораблей и медицинского оборудования.
Вы серьёзно сравниваете по сложности и важности организм человека с программой? :)
Ну что делать, если факт: в веб, в мобильных приложенях, в десктопных приложениях необходимость в высшей математике настолько экзотика, что бизнесу, если ему вообще когда-нибудь понадобится такой скилл, будет дешевле один раз нанять услуги подходящего специалиста, чем при поиске постоянных кадров резко сузить круг поиска только до дипломированных инженеров (что всё равно не будет гарантией уровеня качества программиста) с риском замедления/остановки бизнес-процессов, убытков и банкротства. И рынок, кстати, это очень хорошо понимает: на нём вакансий по программированию без требований к высшему образованию примерно столько же, сколько с требованиями, если не больше.
AnneSmith
Ваш подход был очень актуален тогда, когда не существовало высокоуровневых языков и мощных инструментов для разработки.
Практика показывает, что огромное количество проектов совершенно не требуют формального высшего образования.
Ваш покорный слуга — самоучка, учившийся в классе с сильным акцентом на математике, физике, с введением в кибернетику, включая архитектуру компьютера и программирование на ассемблере и Паскале. Потом успешно успел всё это забыть, и только после 30 стал заново интересоваться предметом, причём не столько для заработка (хотя и это тоже), сколько из личных исследований некоторых философских вопросов, связанных с логикой и теорией множеств. Сегодня (37 лет) в одной фирме считаюсь экспертом по различным программным системам, реализующих сервисы и бизнес-процессы на 3-х разных языках (Perl, JS, PHP), часть из которых были написаны с участием инженеров ещё в районе 2000-го г. И мне очень часто приходится поддерживать (и исправлять, когда позволяют дедлайны) страшный говнокод, написанный инженерами, который реализует, если не все, то, наверное, большинство из известных антипаттернов — от жуткой смеси презентации с логикой и до божественных функций и классов (там, где используется ООП), повсеместных глобальных переменных, значения которых используются в функциях посторонних модулей, безбожного копирования кода сотни раз и т.д.
Я лично помогал одному парню, который делал проект на PHP для завершения степени по компьютерным наукам. У парня светлая голова, он хорошо шарит в статистике, например, в отличие от меня. А вот курсы по проектированию систем и программированию на Java совсем не помогли ему писать не ужасный спагетти-говнокод, приходилось объяснять вроде бы элементарные вещи.
Так что, высшее техническое образование само по себе не даёт хороших навыков программирования. И, кстати, в моей стране проживания молодёжь, даже заканчивая академическую степень "инженер-программист", зачастую берёт платные годовые курсы в учебных центрах, ориентирующихся на современные требования бизнеса, а не на то, что даёт академия. И, с другой стороны, есть немало людей, которые берут подобные курсы и не имея высшего образования — да, большая часть отсеивается, но некоторые вполне успешно устраиваются на работу и становятся неплохими программистами — по крайней мере, удовлетворяющими большинству требований рынка.
Имхо, для того, чтобы нормально работать программистом, там где не требуется высшей математики, достаточно хорошего школьного образования, логического мышления и готовности к тому, что самостоятельная учёба станет частью жизни (последнее хорошо и вне связи с программированием). А исчисление высказываний/предикатов и какие-то базисные вещи типа оценки сложности алгоритма вполне можно быстро освоить по мере необходимости.
С другой стороны, имхо, если сейчас все резко начнут требовать от программистов высшего образования, то на рынке огромного спроса на программистов образуется дефицит, достаточно серьёзный, чтобы привести к разорению большого множества бизнесов, увеличению безработицы и заметным убыткам в экономике.
Спасибо за отзыв и за ссылку! Ход мысли интересен, буду читать на досуге. Пока просмотрел текст 1-й главы, и уже хочется высказаться (постараюсь быть кратким) на тему, что убедительней — материализм или идеализм.
Лично мои исследования и созерцания по этому вопросу не оставляют места материализму — по крайней мере той его форме, согласно которой материальный мир в той или иной степени похож на его "отражение" в нашем восприятии. Есть две основные схемы рассуждений (в самых общих чертах):
Содержание воспрятия не имеет смысла без самого восприятия.
Квалиа не имеют ни смысла, ни существования вне восприятия, т.е., вне воспринимающего субъекта.
Это легко видеть на примере цвета, звука, запаха и вкуса, причём речь именно о том, что мы видим, слышим и т.д., т.е., о содержании восприятия, а не о физических интерпретациях.
Несколько сложнее это видеть относительно пространства, времени и вообще абстрактных объектов, т.к. в шаблонах нашего мышления с детства объекты безусловно принимаются существующими вне восприятия, при этом отождествляясь с конкретными паттернами последнего.
В итоге, если мы предполагаем, что материальный мир хоть в чём-то совпадает с тем, что является в нашем восприятии, то в этой своей части он имеет воспринимающего субъекта.
Абсурдность допущения, что содержание восприятия находится в мозгу, как в материальном объекте.
То, что мы видим, слышим, и т.д. (далее просто содержание восприятия), существует, когда это происходит, и именно в том виде, как мы его воспринимаем.
Т.е., речь опять о содержании, а не об интерпретациях восприятия.
Где конкретно существует содержание восприятия (не его интерпретация)?
Варианты (строгая дизъюнкция):
В мозгу.
Где-то ещё.
Если в мозгу, то:
Что-то в мозгу (нейроны, синапсы, молекулы… — что-то) окрашивается в цвет, который мы видим, звучит звуком, который мы слышим, имеет вкус, что мы ощущаем, и т.д.
Предположение, что содержание восприятия находится в мозгу, ведёт к очень абсурдным результатам — от звучащих нейронов до пробующих друг друга на вкус нейронов (или любого другого подмножества объектов мозга).
Получилось больше текста, нежели задумывалось, но иначе выразить мысль не вышло, извиняйте.
Disclaimer: господа материалисты, прошу, не серчайте. Мысли из лагеря идеализма, так что, естественно, материализм будет критиковаться. Как говорится, no offence, ничего личного, материалистов я люблю (особенно, если учесть, что все люди, с которыми я знаком — материалисты). Конкретно о времени — в кульминации.
Наверное, большинство людей на планете поражены материализмом головного мозга. Я до сих пор помню некоторые этапы своего детства, когда смотрел на мир ещё непредвзято, наблюдая не более того, что поступало в ощущения — мозаику из цветных форм, какофонию звуков, запахов, вкусов, тактильных ощущений. А потом — обучение общению, садик, школа, и т.д. Хотя, наверное, предрасположенность к материализму начала формироваться ещё задолго до детсада, как раз тогда, когда в мышлении формировались абстракции, позволяющие на лету интерпретировать текущее восприятие репрезентацию системы независимо существующих объектов. Такой способ интерпретации текущих данных восприятия эмпирически оказывается очень прагматичным, т.е., полезным. И возможно поэтому, позже, такая абстракция, как материальный, независимый от восприятия, мир, в котором материя непременно хоть каким-то образом воспроизводит те самые первичные объектные абстракции, — принимается человеком за истину практически без критики. И тут происходит подмена понятий: изначально объектные абстракции появляются в психике, но принимается, как факт, что они являются всего-лишь "отражением" по-настоящему настоящих материальных объектов. И вот так создаётся ситуация, когда физика онтологически нейтральна — совершенно не требует понятия о материи, физикой может заниматься с равным успехом как материалист, так и идеалист, — но именно к её успехам чаще всего почему-то аппелируют материалисты в пользу своих метафизических воззрений.
Ну да, эффективность объектной интерпретации данных восприятия это для каждого дееспособного человека — эмпирически каждый день проверяемый факт. Описания физических моделей в естественном языке чаще всего накладывают онтологические требования, когда утверждается или предполагается существование того или иного объекта, порой, с приставкой "материальный". А что делать, если абсолютное большинство людей, включая и ведущих физиков, материалисты? Да даже идеалисты вынуждены в естественном языке использовать слова и выражения типа "материя", "материальный мир" и тому подобное. Языковая привычка, от которой в наполненном материалистами мире вряд ли возможно отказаться. К счастью, для собственно научных расчётов естественный язык не подходит, да и не нужен, и (внезапно!) оказывается, что для собственно эмпирической науки никакой технической необходимости в существовании материи нет.
Всё это к чему? Да к тому, что вопросы о каком-то независимом существовании пространства и времени, как целого или по отдельности — это не физические, а метафизические, т.е., чисто философские вопросы. Непосредственно на моделирование, эксперимент и расчёты решение этих вопросов не влияет. Но.
Философия (аналитическая, а не воспалённые фантазии всяких Ницше) направляет эмпирическую науку. Философское онтологическое восприятие мира (в своих полюсах — материализм/идеализм) ограничивает множество моделей, которые захочет рассматривать учёный. В этом смысле материализм головного мозга существенно ограничивает множество моделей, которые будут допущены научным сообществом к научному исследованию. Например, очень многие материалисты сводят свою онтологию к этакому механицизму, т.е., считают, что такие субъективные явления, как сознание, квалиа в восприятии, да и само восприятие — просто не существуют или, в лучшем случае рассматриваются как иллюзия. И, кстати, я не понимаю, как у них при этом не возникает когнитивный диссонанс — ведь если, с одной стороны, у них нет ни сознания, ни восприятия, то откуда они что-то знают? Как смогли закончить школу, университет при такой тотальной перцептивной депривации? А если сознание и восприятие — иллюзия, то как они могут полагаться даже на самые научные данные — ведь, в конечном счёте, абсолютно все известные данные поступают человеку через восприятие и сознание? А те, что допускают их существование, как некоторую необычную форму материи, не допускают возможность адекватного их исследования в силу субъективности предмета. В конце концов, естественные интересы учёного-материалиста акцентированы на исследовании именно "внешнего" мира, т.е. той единственной метафизической модели, которая имеет для него ценность. Между тем, не секрет, что "внутренний" мир человека не менее содержателен, чем "внешний". Вполне возможно, что между "внутренним" и "внешним" мирами существуют связи и отношения, которые не могут исследоваться, ни даже мыслиться в материалистической парадигме, в которой всё, что не "внешняя материальная действительность" не считается заслуживающим внимания.
Ух ты, накипело… Короче, имхо, с углублением физики в крайне странный (прямо скажем, какой-то не очень материальный) мир квантовых эффектов с такими приколами, как нарушение принципа локальности и локального реализма, вполне вероятно, что в какой-то момент произойдёт "щелчок", и материальная парадигма начнёт наконец-то "отваливаться", пока не станет маргинальной, уступив место чему-то более прагматичному (не обязательно какому-то виду идеализма, но, хотя бы, ясно озвученной онтологической нейтральности на всех уровнях подготовки учёного, начиная со школы).
К чему всё это в контексте загадки времени? К тому, что нет никакой загадки. Ещё И. Кант проницательно заметил, что для возможности представления нами в восприятии меняющегося в трёхмерном пространстве мира необходима некая интуитивная данность. Это априорно прошитая в нас (т.н. интуитивная) абстракция, которую мы называем пространством. Для восприятия порядков внутреннего состояния необходима интуитивная априорная абстракция времени. Соответственно, он называет пространство "внешним чувством", а время — "внутренним". Пространство и время — это данности нашего восприятия (весьма сложно устроенного, кстати, там есть и вещи покруче — мышление, например), и ожидать их существование где-то за восприятием без очень веских доказательств — это очень и очень не научно.
Время — абстракция. Если хотя бы немного посозерцать это понятие, то вполне понятно, что для существующего субъекта оно характеризуется тремя основными компонентами: "прошедшее" — то, чего уже нет; "будущее" — то, чего ещё нет; "настоящее" — то, что есть. И, собственно, понятно, что конкретное существование происходит в настоящем, в "сейчас", понятие о прошедшем необходимо для соотношения событий в "летописи" памяти друг с другом и с "сейчас", а понятие о будущем — для обзора и планирования возможных изменений. Также понятно, что настоящее это не момент — этакая "точка" на "оси" времени. Настоящее — это многомерное, сложно устроенное пространство восприятия, в котором помимо хитрейшей интерсубъективной синхронизации его подмножества в т.н. "внешний материальный мир", существуют изолированные (по крайней мере, так кажется на этом этапе развития науки) друг от друга области, образующие нас, субъектов, с индивидуальными сознаниями и частным доступом к памяти и мышлению. Содержание настоящего меняется, журнал изменений записывается, субъекты, такие, как мы, имеют к нему ограниченный доступ. Конечно, действует что-то вне нашего восприятия. В противном случае оно всегда было бы предсказуемым. Но это наверняка не та абстракция, о которой все говорят, как о материальном мире. Но это уже совсем другая тема, меня и так как-то слишком занесло… :)
Некоторые люди не находят преимуществ ни в добавлении пустых строк, ни в переносе открывающей скобки на отдельную строку. Кстати, рекомендации PHP-FIG (PSR-1, PSR-2) применительно к ветвлениям и циклам тоже. Хотя, имхо, если уж тратить место на отдельную строку, то хотя бы открывающую скобку туда вставить… :)
А если окружающий код это тоже «if», «else if»...?
Прошу прощения, не вполне точно выразился. Лучше было сказать, что код внутри блоков «if», «else if», «else», «for», «while» и т.д. отделён отступом от строк, инициализирующих блоки, соответственно, «if», «else if», «else», «for», «while» и т.д. Например, бессмысленный кусок кода для иллюстрации:
#!/usr/bin/perl
my @arr = (3, 2, 1);
my %hash = (k1 => 'v1', k2 => 'v2');
if (@arr) {
if (%hash) {
for my $el (@arr) {
keys %hash;
for (my ($key, $val) = each %hash) {
print "$el$key$val\n";
}
}
} else {
print "$_\n" for @arr;
}
} elsif (%hash) {
print "%hash\n";
} else {
print "No luck, screw it!\n";
}
На мой взгляд, отступы достаточно ясно показывают, где ветвления и циклы, а где предложения (или как лучше на русском сказать "statement"?).
В простом коде с одним оператором это выглядит неплохо, а в коде посложнее иногда приходится отделять. Значит читабельность у такого варианта меньше.
Без конкретного примера мне не вполне ясно, о чём тут речь. И кому конкретно приходится отделять. Но если речь о сложных условиях в операторах ветвления — настолько сложных, что за несколько секунд не разобраться, то я вполне согласен с мнением Роберта Мартина в его "Чистом коде", что такое условие следует выносить в функцию, по названию которой будет понятно, о какой проверке речь. Часто бывает нужно не досконально понять условие, а (в терминах Р. Мартина) "прочитать осмысленную историю" на пути к предмету, по-настоящему требующему внимания.
И опять же, лично мне дополнительные пустые строки сами по себе не помогают понять логику того или иного кода. Отступы необходимы, чтобы видеть (а не вычислять) иерархию вложенности блоков. Пустые строки, объединяющие отдельные совокупности предложений по некоторому общему логическому признаку (группы инициализаций, последовательности какого-то вычисления) — бывают полезны для быстрого просмотра кода, хотя ещё полезней часто бывает разбивать длинные простыни на вызовы функций с лаконичными названиями, после чего код читать куда удобнее. И в любом случае, при столкновении со сложным условием лично мне пустые строки не помогут понять его быстрее. Да, есть случаи с многострочными условиями, когда код внутри блока имеет тот же отступ, что и строки условия. Мне это как-то не мешает, б.м., потому, что сталкиваясь с инициализацией блока, сразу ищу открывающую его фигурную скобку (или двоеточие в случае с Python).
Ну и со отдельными скобками как-то посимметричнее выглядит. Особенно с elseif, который с третьего символа начинается.
Что значит "с отдельными скобками"? Когда фигурная скобка открывается на новой строке? Вообще говоря, для разных языков (по крайней мере, для некоторых) существуют в той или иной мере стандартизированные рекомендации по стилю. Например, для PHP есть PSR-1 и PSR-2. Во многих командах также практикуется следовать какому-то общему стилю. Т.е., мы должны понимать, что абсолютно идеального подходящего всем решения попросту нет — Вам удобнее с дополнительными к отступам пустыми строками, а меня это будет отвлекать и раздражать при чтении кода, кому-то хочется видеть открывающие фигурные скобки на отдельной строке, а кому-то отрадно их видеть на последней строке инициализации блока. Такова жизнь.
И у тех, кто не ставит пробелы везде, где позволяет компилятор: между операторами, после запятых в однострочных списках и перед открытием фигурных скобок в объявлениях, циклах и т.д.
Лично мне субъективно удобнее читать первый вариант, без дополнительных пустых строк. Пустыми строками выделяю логически однородные фрагменты кода типа инициализации переменных, вычислений в том или ином контексте. Кроме того, строки, содержащие ключевые слова «if», «else if», «else», «for», «while» и т.д., чаще всего уже отделены от окружающего кода отступом.
В IDE от Jetbrains использую 'Ctrl' вместе со стрелками, ну а для Vim/Emacs, полагаю, вопрос не актуален. Вообще, сравнительно редко использую навигацию влево-вправо по тексту без 'Ctrl', т.к. в большинстве случаев требуется перемещение на n слов, а не букв.
Вы привели два графика (кстати, без ссылок на источники), причём в первом Perl на подъёме, а касательно второго, если зайти на PYPL и посмотреть статистику по странам, то окажется, что в Германии, UK и Франции у перла всё ровно. Но сами способы сбора статистики и её корректной интерпретации вызывают вопросы, и не только у меня.
Зато если без фанатизма покопаться в Google trends, пробуя разные запросы по разным странам, то можно получить более объективную картину, которую хейтеру уже не захочется демонстрировать.
Впрочем, хотите считать, что если язык не в хайпе, то он умирает — дело Ваше.
На графике TIOBE позиции Perl с 2014 года по наши дни явно имеют тенденцию к укреплению. Если так буквально интерпретировать эти данные, то это C и Java надо назвать умирающими языками, причём умирающими стремительно. Кто-то серьёзно считает их умирающими языками?
Регулярно сталкиваюсь со случаями, когда фрилансер выполняет заказ, физически находясь в конторе заказчика. Получается, что фриланс это не всегда удалённая работа.
Я когда-то пробовал превратить Vim в IDE, но не для Haskell, а для Perl, PHP и JS. Сейчас уже не вспомню, по каким конкретно причинам не зашло. В общем — время загрузки, конфликты с уже установленными плагинами, некоторая непредсказуемость поведения, тогда как по удобству, интуитивности и фичерам всё равно до полноценного IDE не дотягивало. Остался на PhpStorm с плагином CamelCade для Perl. Кроме того, я ценю Vim в первую очередь как мощный и быстро доступный универсальный текстовый редактор, и этой цели после загромождения кучей плагинов он как-то перестал активно содействовать. Вполне возможно, что всё это решаемо, но я не гуру, и тогда не было особого желания копаться в потрохах и тратить время на выяснение.
Для Haskell пока не пробовал. Я абсолютный новичок в Haskell. Года четыре назад пытался изучать этот язык — кажется, пробовал Emacs, плагин для Eclipse, и даже Leksah. Последний IDE оказался (на мой взгляд) слишком нестандартным и сырым. Eclipse работал (когда был в настроении), Emacs, емнип, тоже. Но я быстро попал в Cabal hell, поагонизировал пару вечеров и снёс всё к чертям. :)
Недавно узнал о Stack, и как он решает проблему Cabal hell, так что решил попробовать снова. Гугление быстро привело к Atom. Порог вхождения низкий, функциональности для учёбы вполне хватает. Читаю Real World Haskell, доки по Stack — пока всё работает предсказуемо.
Может, стоит снова попробовать… Если решусь — отпишусь о результатах.
А можно подробней? Это или что-то другое? У меня пока что очень неплохо работает Atom с набором пакетов atom-haskell. Причём, установка довольно прямолинейная, практически без бубна, поддерживается stack.
доставляем счастье
Надеюсь, что и зарплаты хорошие.
Вообще, каждому своё. Для интроверта техподдержка может оказаться адом.
До того, как стал работать программистом, поработал 3.5 года в техподдержке.
Первое собеседование в техподдержку большого интернет-провайдера не прошёл. Отсеялся после технического экзамена на групповой динамике. Уже выходя из здания примерно понял промахи, а погуглив, составил стратегию для прохождения следующего собеседования. Язык жестов, улыбаться, хвалить, безграничный оптимизм. И 20 капель валерианки для душевного равновесия.
Полгода в хелпдеске другой крупной фирмы, предоставляющей услуги интернета и кабельного телевидения. Уволили за слишком длинные разговоры с клиентами и общую медлительность в работе с приложениями — что не удивительно, т.к. это был первый раз, когда реально пришлось работать (а не ваньку валять) за компьютером с очень разными интерфейсами.
Два года в той фирме, в которой первый раз провалил собеседование. К концу первого года стал впадать в депрессию: достаточно трёх-четырёх звонков типа "у вас всё плохо", "какие вы плохие", "у меня нет интернета, я вас уничтожу", чтобы задать фоновую атмосферу всему дню. И слишком мало технического вызова. Начал было увольняться, но тут начальника (благослови Бог этого доброго человека) перевели начальствовать над более технически продвинутой командой, а он меня взял без собеседования. Ещё год, и тут я уже взвыл. Чёрная непреодолимая депрессия с чуть-ли не физической невозможностью зайти в здание фирмы, чтобы начать работу. Бросил и стал искать что-то другое.
Год в техподдержке относительно небольшой фирмы, предоставляющей услуги хостинга, регистрации доменных имён и электронной коммерции. В другой фирме предлагали бОльшую зарплату, но я уже пару лет копался в HTML, CSS и JS, так что пошёл в сторону интереса. За первые полгода стал "ведущим инженером поддержки", начал осваиваться с серверной частью и стал писать сценарии из смеси JS с PHP, чтобы автоматизировать проверки сервисов. Ещё через полгода депрессия вернулась, и я подал письмо об увольнении.
Дальше было что-то сверхъестественное: мне предложили перейти на должность интегратора новой CRM, что включало в себя разработку клиентского (в смысле браузера) и серверного кода (PHP) плюс LAMP-менеджмент и всё, что лень делать системщикам. От такого шанса отказываться грех, так что ещё через год мне стали передавать проекты уже систем самой фирмы. Пришлось за две недели (и за последующие два года) изучить Perl, но это того стоило.
Мораль сей басни такова: кому хорошо в поддержке/обслуживании клиентов — и хорошо, особенно, если зарплата радует. А кому нравится решать сложные технические задачи, и/или решать логические задачи и много работать с текстом — такие работы, особенно техподдержка, следует рассматривать в качестве трамплина, дающего возможность прокачать скилл общения с людьми и при удачно выбранной области деятельности — хорошенько практически покопаться в ранее чисто теоретической целевой предметной области, что сильно повышает шансы получить в ней работу джуниора.
Всем успеха. :)
Зачем бросаться в крайности? Мир не чёрно-белый, есть и другие варианты. Не всем быть космонавтами, и не всем этого хочется.
Одна знакомая мне фирма заказала относительно крупный проект у вот такого сеньора с огромным опытом и, соответственно, требованиями к зарплате (порядка 150$ в час). Менеджмент наивно положился на известность, крутость, опыт, ответственность и т.д., и не привлекла к составлению требований своих технических специалистов. В результате проект после сдачи допиливается уже год (или больше), естественно, за дополнительные деньги. Например, везде, где используется SQL, были допущены инъекции. На одной из встреч, на которой уже присутствовали местные программисты, на вопрос о безопасности был получен лаконичный ответ: этого не было в требованиях. Вот вам и сеньор...
А вообще, независимо от этого конкретного случая, в том же Израиле рынок забит требованиями микроразработок для всевозможных CMS или того же Magento — на PHP. И я знаком с преуспевающими фрилансерами, берущими порядка 50$ в час, клиенты которых успешно пишут свои блоги, имеют успешные веб-магазины, заточенные под нужды бизнеса. И для выполнения этой работы не нужно даже намёка на высшее образование, только интуитивное логическое мышление и хорошее знакомство с поддерживаемым CMS.
Или не будет. Лично знаком с многими бизнесами, которые пытались радикально экономить, обращаясь к индусам, а потом, после мучительного ада из полувзаимонепонимания, шли на поклон к местным специалистам.
Не все. Я не устривался по знакомству. Мой хороший знакомый буквально на днях устроился джуниором в разработку не по знакомству.
У меня есть опыт с Magento, но эту систему чисто как CMS, имхо, использовать — перебор. Так какая — лучшая?
Бэкенд бэкенду рознь. В PHP массив он же и лист, и словарь. В Perl массив отличается от словаря, но оба не ограничены длинной.
Ну, замыкания и в Perl, и в PHP лично мне приходится использовать относительно регулярно. Пока ещё не родилось обобщённого понимания, чтобы выделить класс случаев, когда замыкания удобны. Но в некоторых конкретных задачах самым интуитивным решением бывает именно замыкание. Имхо.
Я в шоке.
Написанная человеком программа всегда (или, по крайней мере, в обозримом будущем) будет проще, чем человеческий организм. И всегда менее важна, чем человеческий организм — даже когда служит для его защиты, и когда от правильной работы программы зависит человеческая жизнь.
Я не утверждал, что в любые области программирования можно пускать без профильного образования. Я глубоко убеждён, что в области, где от правильной работы программы зависят человеческие жизни, нужно пускать только специалистов, многократно доказавших себя и в прикладных, и в теоретических знаниях, а также в этических убеждениях. И в таких случаях только лишь инженерного образования, имхо, недостаточно. Искренне надеюсь, что даже отличников-студентов не пускают к продакшн-программированию космических кораблей и медицинского оборудования.
Вы серьёзно сравниваете по сложности и важности организм человека с программой? :)
Ну что делать, если факт: в веб, в мобильных приложенях, в десктопных приложениях необходимость в высшей математике настолько экзотика, что бизнесу, если ему вообще когда-нибудь понадобится такой скилл, будет дешевле один раз нанять услуги подходящего специалиста, чем при поиске постоянных кадров резко сузить круг поиска только до дипломированных инженеров (что всё равно не будет гарантией уровеня качества программиста) с риском замедления/остановки бизнес-процессов, убытков и банкротства. И рынок, кстати, это очень хорошо понимает: на нём вакансий по программированию без требований к высшему образованию примерно столько же, сколько с требованиями, если не больше.
AnneSmith
Ваш подход был очень актуален тогда, когда не существовало высокоуровневых языков и мощных инструментов для разработки.
Практика показывает, что огромное количество проектов совершенно не требуют формального высшего образования.
Ваш покорный слуга — самоучка, учившийся в классе с сильным акцентом на математике, физике, с введением в кибернетику, включая архитектуру компьютера и программирование на ассемблере и Паскале. Потом успешно успел всё это забыть, и только после 30 стал заново интересоваться предметом, причём не столько для заработка (хотя и это тоже), сколько из личных исследований некоторых философских вопросов, связанных с логикой и теорией множеств. Сегодня (37 лет) в одной фирме считаюсь экспертом по различным программным системам, реализующих сервисы и бизнес-процессы на 3-х разных языках (Perl, JS, PHP), часть из которых были написаны с участием инженеров ещё в районе 2000-го г. И мне очень часто приходится поддерживать (и исправлять, когда позволяют дедлайны) страшный говнокод, написанный инженерами, который реализует, если не все, то, наверное, большинство из известных антипаттернов — от жуткой смеси презентации с логикой и до божественных функций и классов (там, где используется ООП), повсеместных глобальных переменных, значения которых используются в функциях посторонних модулей, безбожного копирования кода сотни раз и т.д.
Я лично помогал одному парню, который делал проект на PHP для завершения степени по компьютерным наукам. У парня светлая голова, он хорошо шарит в статистике, например, в отличие от меня. А вот курсы по проектированию систем и программированию на Java совсем не помогли ему писать не ужасный спагетти-говнокод, приходилось объяснять вроде бы элементарные вещи.
Так что, высшее техническое образование само по себе не даёт хороших навыков программирования. И, кстати, в моей стране проживания молодёжь, даже заканчивая академическую степень "инженер-программист", зачастую берёт платные годовые курсы в учебных центрах, ориентирующихся на современные требования бизнеса, а не на то, что даёт академия. И, с другой стороны, есть немало людей, которые берут подобные курсы и не имея высшего образования — да, большая часть отсеивается, но некоторые вполне успешно устраиваются на работу и становятся неплохими программистами — по крайней мере, удовлетворяющими большинству требований рынка.
Имхо, для того, чтобы нормально работать программистом, там где не требуется высшей математики, достаточно хорошего школьного образования, логического мышления и готовности к тому, что самостоятельная учёба станет частью жизни (последнее хорошо и вне связи с программированием). А исчисление высказываний/предикатов и какие-то базисные вещи типа оценки сложности алгоритма вполне можно быстро освоить по мере необходимости.
С другой стороны, имхо, если сейчас все резко начнут требовать от программистов высшего образования, то на рынке огромного спроса на программистов образуется дефицит, достаточно серьёзный, чтобы привести к разорению большого множества бизнесов, увеличению безработицы и заметным убыткам в экономике.
Спасибо за отзыв и за ссылку! Ход мысли интересен, буду читать на досуге. Пока просмотрел текст 1-й главы, и уже хочется высказаться (постараюсь быть кратким) на тему, что убедительней — материализм или идеализм.
Лично мои исследования и созерцания по этому вопросу не оставляют места материализму — по крайней мере той его форме, согласно которой материальный мир в той или иной степени похож на его "отражение" в нашем восприятии. Есть две основные схемы рассуждений (в самых общих чертах):
Получилось больше текста, нежели задумывалось, но иначе выразить мысль не вышло, извиняйте.
Disclaimer: господа материалисты, прошу, не серчайте. Мысли из лагеря идеализма, так что, естественно, материализм будет критиковаться. Как говорится, no offence, ничего личного, материалистов я люблю (особенно, если учесть, что все люди, с которыми я знаком — материалисты). Конкретно о времени — в кульминации.
Наверное, большинство людей на планете поражены материализмом головного мозга. Я до сих пор помню некоторые этапы своего детства, когда смотрел на мир ещё непредвзято, наблюдая не более того, что поступало в ощущения — мозаику из цветных форм, какофонию звуков, запахов, вкусов, тактильных ощущений. А потом — обучение общению, садик, школа, и т.д. Хотя, наверное, предрасположенность к материализму начала формироваться ещё задолго до детсада, как раз тогда, когда в мышлении формировались абстракции, позволяющие на лету интерпретировать текущее восприятие репрезентацию системы независимо существующих объектов. Такой способ интерпретации текущих данных восприятия эмпирически оказывается очень прагматичным, т.е., полезным. И возможно поэтому, позже, такая абстракция, как материальный, независимый от восприятия, мир, в котором материя непременно хоть каким-то образом воспроизводит те самые первичные объектные абстракции, — принимается человеком за истину практически без критики. И тут происходит подмена понятий: изначально объектные абстракции появляются в психике, но принимается, как факт, что они являются всего-лишь "отражением" по-настоящему настоящих материальных объектов. И вот так создаётся ситуация, когда физика онтологически нейтральна — совершенно не требует понятия о материи, физикой может заниматься с равным успехом как материалист, так и идеалист, — но именно к её успехам чаще всего почему-то аппелируют материалисты в пользу своих метафизических воззрений.
Ну да, эффективность объектной интерпретации данных восприятия это для каждого дееспособного человека — эмпирически каждый день проверяемый факт. Описания физических моделей в естественном языке чаще всего накладывают онтологические требования, когда утверждается или предполагается существование того или иного объекта, порой, с приставкой "материальный". А что делать, если абсолютное большинство людей, включая и ведущих физиков, материалисты? Да даже идеалисты вынуждены в естественном языке использовать слова и выражения типа "материя", "материальный мир" и тому подобное. Языковая привычка, от которой в наполненном материалистами мире вряд ли возможно отказаться. К счастью, для собственно научных расчётов естественный язык не подходит, да и не нужен, и (внезапно!) оказывается, что для собственно эмпирической науки никакой технической необходимости в существовании материи нет.
Всё это к чему? Да к тому, что вопросы о каком-то независимом существовании пространства и времени, как целого или по отдельности — это не физические, а метафизические, т.е., чисто философские вопросы. Непосредственно на моделирование, эксперимент и расчёты решение этих вопросов не влияет. Но.
Философия (аналитическая, а не воспалённые фантазии всяких Ницше) направляет эмпирическую науку. Философское онтологическое восприятие мира (в своих полюсах — материализм/идеализм) ограничивает множество моделей, которые захочет рассматривать учёный. В этом смысле материализм головного мозга существенно ограничивает множество моделей, которые будут допущены научным сообществом к научному исследованию. Например, очень многие материалисты сводят свою онтологию к этакому механицизму, т.е., считают, что такие субъективные явления, как сознание, квалиа в восприятии, да и само восприятие — просто не существуют или, в лучшем случае рассматриваются как иллюзия. И, кстати, я не понимаю, как у них при этом не возникает когнитивный диссонанс — ведь если, с одной стороны, у них нет ни сознания, ни восприятия, то откуда они что-то знают? Как смогли закончить школу, университет при такой тотальной перцептивной депривации? А если сознание и восприятие — иллюзия, то как они могут полагаться даже на самые научные данные — ведь, в конечном счёте, абсолютно все известные данные поступают человеку через восприятие и сознание? А те, что допускают их существование, как некоторую необычную форму материи, не допускают возможность адекватного их исследования в силу субъективности предмета. В конце концов, естественные интересы учёного-материалиста акцентированы на исследовании именно "внешнего" мира, т.е. той единственной метафизической модели, которая имеет для него ценность. Между тем, не секрет, что "внутренний" мир человека не менее содержателен, чем "внешний". Вполне возможно, что между "внутренним" и "внешним" мирами существуют связи и отношения, которые не могут исследоваться, ни даже мыслиться в материалистической парадигме, в которой всё, что не "внешняя материальная действительность" не считается заслуживающим внимания.
Ух ты, накипело… Короче, имхо, с углублением физики в крайне странный (прямо скажем, какой-то не очень материальный) мир квантовых эффектов с такими приколами, как нарушение принципа локальности и локального реализма, вполне вероятно, что в какой-то момент произойдёт "щелчок", и материальная парадигма начнёт наконец-то "отваливаться", пока не станет маргинальной, уступив место чему-то более прагматичному (не обязательно какому-то виду идеализма, но, хотя бы, ясно озвученной онтологической нейтральности на всех уровнях подготовки учёного, начиная со школы).
К чему всё это в контексте загадки времени? К тому, что нет никакой загадки. Ещё И. Кант проницательно заметил, что для возможности представления нами в восприятии меняющегося в трёхмерном пространстве мира необходима некая интуитивная данность. Это априорно прошитая в нас (т.н. интуитивная) абстракция, которую мы называем пространством. Для восприятия порядков внутреннего состояния необходима интуитивная априорная абстракция времени. Соответственно, он называет пространство "внешним чувством", а время — "внутренним". Пространство и время — это данности нашего восприятия (весьма сложно устроенного, кстати, там есть и вещи покруче — мышление, например), и ожидать их существование где-то за восприятием без очень веских доказательств — это очень и очень не научно.
Время — абстракция. Если хотя бы немного посозерцать это понятие, то вполне понятно, что для существующего субъекта оно характеризуется тремя основными компонентами: "прошедшее" — то, чего уже нет; "будущее" — то, чего ещё нет; "настоящее" — то, что есть. И, собственно, понятно, что конкретное существование происходит в настоящем, в "сейчас", понятие о прошедшем необходимо для соотношения событий в "летописи" памяти друг с другом и с "сейчас", а понятие о будущем — для обзора и планирования возможных изменений. Также понятно, что настоящее это не момент — этакая "точка" на "оси" времени. Настоящее — это многомерное, сложно устроенное пространство восприятия, в котором помимо хитрейшей интерсубъективной синхронизации его подмножества в т.н. "внешний материальный мир", существуют изолированные (по крайней мере, так кажется на этом этапе развития науки) друг от друга области, образующие нас, субъектов, с индивидуальными сознаниями и частным доступом к памяти и мышлению. Содержание настоящего меняется, журнал изменений записывается, субъекты, такие, как мы, имеют к нему ограниченный доступ. Конечно, действует что-то вне нашего восприятия. В противном случае оно всегда было бы предсказуемым. Но это наверняка не та абстракция, о которой все говорят, как о материальном мире. Но это уже совсем другая тема, меня и так как-то слишком занесло… :)
Некоторые люди не находят преимуществ ни в добавлении пустых строк, ни в переносе открывающей скобки на отдельную строку. Кстати, рекомендации PHP-FIG (PSR-1, PSR-2) применительно к ветвлениям и циклам тоже. Хотя, имхо, если уж тратить место на отдельную строку, то хотя бы открывающую скобку туда вставить… :)
Что доказывают эти примеры? Вот совершенно легко, не перебирая, нашёл примеры противоположного стиля:
Symfony
Laravel
AngularJS
VueJS
Прошу прощения, не вполне точно выразился. Лучше было сказать, что код внутри блоков «if», «else if», «else», «for», «while» и т.д. отделён отступом от строк, инициализирующих блоки, соответственно, «if», «else if», «else», «for», «while» и т.д. Например, бессмысленный кусок кода для иллюстрации:
На мой взгляд, отступы достаточно ясно показывают, где ветвления и циклы, а где предложения (или как лучше на русском сказать "statement"?).
Без конкретного примера мне не вполне ясно, о чём тут речь. И кому конкретно приходится отделять. Но если речь о сложных условиях в операторах ветвления — настолько сложных, что за несколько секунд не разобраться, то я вполне согласен с мнением Роберта Мартина в его "Чистом коде", что такое условие следует выносить в функцию, по названию которой будет понятно, о какой проверке речь. Часто бывает нужно не досконально понять условие, а (в терминах Р. Мартина) "прочитать осмысленную историю" на пути к предмету, по-настоящему требующему внимания.
И опять же, лично мне дополнительные пустые строки сами по себе не помогают понять логику того или иного кода. Отступы необходимы, чтобы видеть (а не вычислять) иерархию вложенности блоков. Пустые строки, объединяющие отдельные совокупности предложений по некоторому общему логическому признаку (группы инициализаций, последовательности какого-то вычисления) — бывают полезны для быстрого просмотра кода, хотя ещё полезней часто бывает разбивать длинные простыни на вызовы функций с лаконичными названиями, после чего код читать куда удобнее. И в любом случае, при столкновении со сложным условием лично мне пустые строки не помогут понять его быстрее. Да, есть случаи с многострочными условиями, когда код внутри блока имеет тот же отступ, что и строки условия. Мне это как-то не мешает, б.м., потому, что сталкиваясь с инициализацией блока, сразу ищу открывающую его фигурную скобку (или двоеточие в случае с Python).
Что значит "с отдельными скобками"? Когда фигурная скобка открывается на новой строке? Вообще говоря, для разных языков (по крайней мере, для некоторых) существуют в той или иной мере стандартизированные рекомендации по стилю. Например, для PHP есть PSR-1 и PSR-2. Во многих командах также практикуется следовать какому-то общему стилю. Т.е., мы должны понимать, что абсолютно идеального подходящего всем решения попросту нет — Вам удобнее с дополнительными к отступам пустыми строками, а меня это будет отвлекать и раздражать при чтении кода, кому-то хочется видеть открывающие фигурные скобки на отдельной строке, а кому-то отрадно их видеть на последней строке инициализации блока. Такова жизнь.
Зато если без фанатизма покопаться в Google trends, пробуя разные запросы по разным странам, то можно получить более объективную картину, которую хейтеру уже не захочется демонстрировать.
Впрочем, хотите считать, что если язык не в хайпе, то он умирает — дело Ваше.
На графике TIOBE позиции Perl с 2014 года по наши дни явно имеют тенденцию к укреплению. Если так буквально интерпретировать эти данные, то это C и Java надо назвать умирающими языками, причём умирающими стремительно. Кто-то серьёзно считает их умирающими языками?
Perl is not dead: It was early web novices that gave it a bad name
Is Perl dead?
The 7 Most In-Demand Programming Languages for 2017
The top 9 Best Programming Languages You Should Learn In 2017
Perl events